From nobody Fri Apr 1 03:50:28 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 A91FC12D5B0; Fri, 1 Apr 2016 03:50:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Justin Dean" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160401105022.17613.14745.idtracker@ietfa.amsl.com> Date: Fri, 01 Apr 2016 03:50:22 -0700 Archived-At: Cc: manet@ietf.org, iesg-secretary@ietf.org, manet-chairs@ietf.org Subject: [manet] Publication has been requested for draft-ietf-manet-credit-window-03 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: Fri, 01 Apr 2016 10:50:22 -0000 Justin Dean has requested publication of draft-ietf-manet-credit-window-03 as Proposed Standard on behalf of the MANET working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-manet-credit-window/ From nobody Tue Apr 5 03:19:04 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 D0BA812D760; Tue, 5 Apr 2016 03:19:03 -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.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160405101903.773.31003.idtracker@ietfa.amsl.com> Date: Tue, 05 Apr 2016 03:19:03 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-aodvv2-14.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, 05 Apr 2016 10:19:04 -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-14.txt Pages : 80 Date : 2016-04-05 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-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-aodvv2-14 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 Apr 5 03:53: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 B0D0912D17B for ; Tue, 5 Apr 2016 03:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 0sw_0BVIRw2j for ; Tue, 5 Apr 2016 03:53:41 -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 2646C12D5A8 for ; Tue, 5 Apr 2016 03:53:41 -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 <1anOc7-0009ri-EF>; Tue, 05 Apr 2016 12:53:39 +0200 Received: from ext176.non-member.tu-haburg.de ([195.37.187.176] helo=[172.16.19.135]) by inpost2.zedat.fu-berlin.de (Exim 4.85) for manet@ietf.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id <1anOc7-001pPD-3n>; Tue, 05 Apr 2016 12:53:39 +0200 From: Lotte Steenbrink Content-Type: multipart/alternative; boundary="Apple-Mail=_1F11438E-0E96-44E8-96CB-ABA2CB65A6C2" Message-Id: <8438BA85-DFC2-4192-84EE-999572C35FD1@fu-berlin.de> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Date: Tue, 5 Apr 2016 12:53:38 +0200 References: <20160405101903.773.31003.idtracker@ietfa.amsl.com> To: Mobile Ad Hoc Networks mailing list In-Reply-To: <20160405101903.773.31003.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3112) X-Originating-IP: 195.37.187.176 X-ZEDAT-Hint: A Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-14.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, 05 Apr 2016 10:53:43 -0000 --Apple-Mail=_1F11438E-0E96-44E8-96CB-ABA2CB65A6C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, just a quick summary of what is and what isn=E2=80=99t included in this = update of the draft: DONE: =E2=80=94=E2=80=94=E2=80=94=E2=80=94 * All JWD! comments (i.e. the critical ones) are resolved * Out of 90 JWD and JWD! comments, 61 are resolved * The revised security considerations [1] were added (with the TODOs = commented out) * The following TODO from [1] was resolved:=20 "This description MUST include the reasons it was either unreasonable or out of scope to attempt to avoid these denial of service attacks." * Section 9 now contains a statement that AODVv2 doesn=E2=80=99t support = RREQs for prefixes, I hope that clears things up for Thomas. TO DO: =E2=80=94=E2=80=94=E2=80=94=E2=80=94=20 * Most notable of the 29 JWDs that are yet to be resolved: + (is there some table that lists routes that are being waited = on? JWD) We decided to add a separate=20 RREP table that lists them and I=E2=80=99ve volunteered to = write text for that, but we=E2=80=99re currently discussing if/how we might solve this without adding yet another table. + We=E2=80=99re currently discussing the approaching the limit = thing. (i.e. (There is no defined behavior here. Approaching the limit? = Section 6.5 outlines which messages are more important but now how to = decide to allow them to be transmitted or not. JWD=20 and (The undefined approaching the limit thing again JWD) etc We=E2=80=99ve already clarified the wording regarding what = the limit is and how to prioritize the message types,=20 what=E2=80=99s left is to define what =E2=80=9Eapproaching=E2=80= =9C means (and whether we need to talk about approaching rather than just saying =E2=80=9Ehere=E2=80=99s what to do when you = actually hit the limit"). + (I don=E2=80=99t want to spam the list with a comprehensive = list of all of them, but if you=E2=80=99re interested in seeing them, please do say so and I=E2=80=99ll send my copy of Justin=E2=80=99= s review containing all TODOs and DONEs to the list) * some TODOs in security considerations (see [1]) * since we're waiting for Chris=E2=80=99 feedback regarding the revised = 5444 multiplexer wording, that hasn=E2=80=99t changed yet. More details can be found in Appendix A. AODVv2 Draft Updates, as well = as the diff, of course. Best regards, Lotte [1] Re: [manet] AODVv2: Security considerations update = https://www.ietf.org/mail-archive/web/manet/current/msg18458.html > Am 05.04.2016 um 12:19 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-14.txt > Pages : 80 > Date : 2016-04-05 >=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-14 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-14 >=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 --Apple-Mail=_1F11438E-0E96-44E8-96CB-ABA2CB65A6C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,
just a quick summary of what is and = what isn=E2=80=99t included in this update of the draft:

DONE:
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=
* All JWD! comments (i.e. the critical ones) are = resolved
* Out of 90 JWD and JWD! comments, 61 are = resolved
* The revised security considerations [1] = were added (with the TODOs commented out)
* The = following TODO from [1] was resolved: 
   "This = description MUST
   include the reasons it was either unreasonable = or out of scope to
   attempt to avoid these denial of service = attacks."
* Section 9 now contains a = statement that AODVv2 doesn=E2=80=99t support RREQs for prefixes, I hope = that clears things up for Thomas.

TO DO:
=E2=80=94=E2=80=94=E2=80=94=E2=80=94 
* Most notable of the 29 JWDs that are yet to be = resolved:
+ (is there = some table that lists routes that are being waited on? JWD) We = decided to add a separate 
    =        RREP table that lists them and I=E2=80=99ve = volunteered to write text for that, but we=E2=80=99re currently = discussing if/how
        =    we might solve this without adding yet another = table.

+ We=E2=80=99= re currently discussing the approaching the limit thing. (i.e.
   (There is no defined = behavior here. Approaching the limit? Section 6.5 outlines which = messages are more important but now how to decide to allow them to be = transmitted or not. JWD 
  and
=   (The undefined approaching the limit thing again JWD) = etc
          =  We=E2=80=99ve already clarified the wording regarding what the = limit is and how to prioritize the message types, 
           what=E2=80=99s left = is to define what =E2=80=9Eapproaching=E2=80=9C means (and whether we = need to talk about approaching rather than
  =          just saying =E2=80=9Ehere=E2=80=99s = what to do when you actually hit the limit").

    + (I = don=E2=80=99t want to spam the list with a comprehensive list of all of = them, but if you=E2=80=99re interested in seeing them,
           please do say so and = I=E2=80=99ll send my copy of Justin=E2=80=99s review containing all = TODOs and DONEs to the list)
* some TODOs in = security considerations (see [1])
* since we're = waiting for Chris=E2=80=99 feedback regarding the revised 5444 = multiplexer wording, that hasn=E2=80=99t changed yet.

More details can be = found in Appendix A.  AODVv2 = Draft Updates, as well as the diff, of course.

Best regards,
Lotte

[1] Re: [manet] AODVv2: Security considerations update https://www.ietf.org/mail-archive/web/manet/current/msg18458.ht= ml


Am 05.04.2016 um 12:19 schrieb internet-drafts@ietf.org:


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
=             &n= bsp;           &nbs= p;Stan Ratliff
=             &n= bsp;           &nbs= p;John Dowdell
=             &n= bsp;           &nbs= p;Lotte Steenbrink
=             &n= bsp;           &nbs= p;Victoria Mercieca
Filename =        : = draft-ietf-manet-aodvv2-14.txt
Pages =           : 80
= Date =            : = 2016-04-05

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-14

A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-14<= br class=3D"">

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/

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

= --Apple-Mail=_1F11438E-0E96-44E8-96CB-ABA2CB65A6C2-- From nobody Tue Apr 5 11:08: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 8C2A512D13D for ; Tue, 5 Apr 2016 11:08:00 -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 ytuXDCptF15n for ; Tue, 5 Apr 2016 11:07:58 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (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 7847612D176 for ; Tue, 5 Apr 2016 11:07:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 3D2D2D404E5; Tue, 5 Apr 2016 11:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1459879678; bh=6o+VjfmHK2HOqXZOUeIsll20SpQduR74jKtGUocjUgY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=XjASeq2ux/yWGiLUSROn7NW1CRCYXInDTI084i7z5Pxpi8mB9tVOQ8RKj8gvBiHtS wgbsTHclTsByk6E0FK/fUKDdhaw7T+hH8Q2lY4Piyscx5Suvb5MKNWtJg7OVwb93lP Te1x0OGypPRzmvhiwSTUh62owgGK7wqAjZ3NYbQ4= X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [192.168.147.111] (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 mailb1.tigertech.net (Postfix) with ESMTPSA id 2C73CD403A7; Tue, 5 Apr 2016 11:07:57 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_487C048E-1C1E-46E5-9F33-89CB3A0470A1" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: ietf@thomasclausen.org In-Reply-To: <8438BA85-DFC2-4192-84EE-999572C35FD1@fu-berlin.de> Date: Tue, 5 Apr 2016 20:07:55 +0200 Message-Id: <04D7135E-8EDF-49DC-8978-3A1132FF3915@thomasclausen.org> References: <20160405101903.773.31003.idtracker@ietfa.amsl.com> <8438BA85-DFC2-4192-84EE-999572C35FD1@fu-berlin.de> To: Lotte Steenbrink X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-14.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, 05 Apr 2016 18:08:00 -0000 --Apple-Mail=_487C048E-1C1E-46E5-9F33-89CB3A0470A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Lotte, Thank you for this update. An impressive amount of changes to the = document, according to RFCdiff, and as I can see from your mail that = there is much more to come, I hope that you forgive me for not jumping = at a blow-by-blow review until a version which the authors themselves = consider stable, is produced. On the point of =E2=80=9Cmuch more to come", there have been quite a few = comments raised by WG participants other than Mr. Dean and Chris (such = as by myself, but not only) =E2=80=94 some of which intersect some of = the below, and for which I do not believe that a satisfactory resolution = has been developed, presented to the WG, and confirmed. In which revision of the I-D do you plan on addressing those? Best, Thomas > On Apr 5, 2016, at 12:53, Lotte Steenbrink = wrote: >=20 > Hi all, > just a quick summary of what is and what isn=E2=80=99t included in = this update of the draft: >=20 > DONE: > =E2=80=94=E2=80=94=E2=80=94=E2=80=94 > * All JWD! comments (i.e. the critical ones) are resolved > * Out of 90 JWD and JWD! comments, 61 are resolved > * The revised security considerations [1] were added (with the TODOs = commented out) > * The following TODO from [1] was resolved:=20 > "This description MUST > include the reasons it was either unreasonable or out of scope to > attempt to avoid these denial of service attacks." > * Section 9 now contains a statement that AODVv2 doesn=E2=80=99t = support RREQs for prefixes, I hope that clears things up for Thomas. >=20 > TO DO: > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=20 > * Most notable of the 29 JWDs that are yet to be resolved: > + (is there some table that lists routes that are being waited = on? JWD) We decided to add a separate=20 > RREP table that lists them and I=E2=80=99ve volunteered to = write text for that, but we=E2=80=99re currently discussing if/how > we might solve this without adding yet another table. >=20 > + We=E2=80=99re currently discussing the approaching the limit = thing. (i.e. > (There is no defined behavior here. Approaching the limit? = Section 6.5 outlines which messages are more important but now how to = decide to allow them to be transmitted or not. JWD=20 > and > (The undefined approaching the limit thing again JWD) etc > We=E2=80=99ve already clarified the wording regarding what = the limit is and how to prioritize the message types,=20 > what=E2=80=99s left is to define what =E2=80=9Eapproaching=E2= =80=9C means (and whether we need to talk about approaching rather than > just saying =E2=80=9Ehere=E2=80=99s what to do when you = actually hit the limit"). >=20 > + (I don=E2=80=99t want to spam the list with a comprehensive = list of all of them, but if you=E2=80=99re interested in seeing them, > please do say so and I=E2=80=99ll send my copy of = Justin=E2=80=99s review containing all TODOs and DONEs to the list) > * some TODOs in security considerations (see [1]) > * since we're waiting for Chris=E2=80=99 feedback regarding the = revised 5444 multiplexer wording, that hasn=E2=80=99t changed yet. >=20 > More details can be found in Appendix A. AODVv2 Draft Updates, as = well as the diff, of course. >=20 > Best regards, > Lotte >=20 > [1] Re: [manet] AODVv2: Security considerations update = https://www.ietf.org/mail-archive/web/manet/current/msg18458.html = >=20 >=20 >> Am 05.04.2016 um 12:19 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-14.txt >> Pages : 80 >> Date : 2016-04-05 >>=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-14 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-14 >>=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 = >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet = --Apple-Mail=_487C048E-1C1E-46E5-9F33-89CB3A0470A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Lotte,

Thank you for this update. An impressive amount of changes to = the document, according to RFCdiff, and as I can see from your mail that = there is much more to come, I hope that you forgive me for not jumping = at a blow-by-blow review until a version which the authors themselves = consider stable, is produced.

On the point of =E2=80=9Cmuch more to = come", there have been quite a few comments raised by WG participants = other than Mr. Dean and Chris  (such as by myself, but not only) = =E2=80=94 some of which intersect some of the below, and for which I do = not believe that a satisfactory resolution has been developed, presented = to the WG, and confirmed.

In which revision of the I-D do you plan on addressing = those?

Best,

Thomas



On = Apr 5, 2016, at 12:53, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:

Hi all,
just a quick summary of what is and = what isn=E2=80=99t included in this update of the draft:

DONE:
=E2=80=94=E2=80=94=E2=80=94=E2=80=94
* = All JWD! comments (i.e. the critical ones) are resolved
* Out of 90 JWD and JWD! comments, 61 are resolved
* The revised security considerations [1] were added (with = the TODOs commented out)
* The following TODO from = [1] was resolved: 
   "This description = MUST
  =  include the reasons it was either unreasonable or out of scope = to
  =  attempt to avoid these denial of service = attacks."
* Section 9 now contains a = statement that AODVv2 doesn=E2=80=99t support RREQs for prefixes, I hope = that clears things up for Thomas.

TO DO:
=E2=80=94=E2=80=94=E2=80=94=E2=80=94 
* Most notable of the 29 JWDs that are yet to be = resolved:
+ (is there = some table that lists routes that are being waited on? JWD) We = decided to add a separate 
    =        RREP table that lists them and I=E2=80=99ve = volunteered to write text for that, but we=E2=80=99re currently = discussing if/how
        =    we might solve this without adding yet another = table.

+ We=E2=80=99= re currently discussing the approaching the limit thing. (i.e.
   (There is no defined = behavior here. Approaching the limit? Section 6.5 outlines which = messages are more important but now how to decide to allow them to be = transmitted or not. JWD 
  and
=   (The undefined approaching the limit thing again JWD) = etc
          =  We=E2=80=99ve already clarified the wording regarding what the = limit is and how to prioritize the message types, 
           what=E2=80=99s left = is to define what =E2=80=9Eapproaching=E2=80=9C means (and whether we = need to talk about approaching rather than
  =          just saying =E2=80=9Ehere=E2=80=99s = what to do when you actually hit the limit").

    + (I = don=E2=80=99t want to spam the list with a comprehensive list of all of = them, but if you=E2=80=99re interested in seeing them,
           please do say so and = I=E2=80=99ll send my copy of Justin=E2=80=99s review containing all = TODOs and DONEs to the list)
* some TODOs in = security considerations (see [1])
* since we're = waiting for Chris=E2=80=99 feedback regarding the revised 5444 = multiplexer wording, that hasn=E2=80=99t changed yet.

More details can be found in Appendix A.  AODVv2 Draft = Updates, as well as the diff, of course.

Best regards,
Lotte

[1] Re: [manet] AODVv2: Security = considerations update https://www.ietf.org/mail-archive/web/manet/current/msg18458.ht= ml


Am 05.04.2016 um 12:19 = schrieb internet-drafts@ietf.org:


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
          &nb= sp;            = ;  Stan Ratliff
          &nb= sp;            = ;  John Dowdell
          &nb= sp;            = ;  Lotte Steenbrink
          &nb= sp;            = ;  Victoria Mercieca
Filename =        : = draft-ietf-manet-aodvv2-14.txt
Pages =           : 80
= Date =            : = 2016-04-05

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-14

A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-14<= br class=3D"">

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/

_______________________________________________
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=_487C048E-1C1E-46E5-9F33-89CB3A0470A1-- From nobody Tue Apr 5 11:17:40 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 E34F212D768; Tue, 5 Apr 2016 11:17:37 -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: <20160405181737.7337.36982.idtracker@ietfa.amsl.com> Date: Tue, 05 Apr 2016 11:17:37 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-03.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, 05 Apr 2016 18:17:38 -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-03.txt Pages : 22 Date : 2016-04-05 Abstract: This document updates the generalized MANET packet/message format, specified in RFC 5444, by providing rules and recommendations for how protocols can use that 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 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-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-rfc5444-usage-03 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 Apr 5 12:08: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 7F3CC12D9AD for ; Tue, 5 Apr 2016 12:08:11 -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 M7p63xrwBJNu for ; Tue, 5 Apr 2016 12:08:05 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 624F012D546 for ; Tue, 5 Apr 2016 12:07:50 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id k1so30197267vkb.0 for ; Tue, 05 Apr 2016 12:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to; bh=S/IQlqqdoM1vUeQx40PinZkR65kSW910VanbErQrRSU=; b=FlPFFpb67SYUBB3h5U7s+ypTx0yqKh+QYGstAVljJHqz0QhIHRZeymIBuIMLYzXQeS dmRgjK2tx5UKqvVmhxPJ9UW59UsxI71ZfUGfaGK2zBUuWoRXzI6MThriPouxbsfjlvhe dXgyzYbzfbi4r1MgQo0F8vD2w58ESMMj8vmH8= 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=S/IQlqqdoM1vUeQx40PinZkR65kSW910VanbErQrRSU=; b=evVzQSDbG6SNX+t26+pQsmbju4x5FyBHkv/68lSy2jEMf4CkAg1C60BX5ZKMDqClu1 600Ps6ia2+oCpZU6V6f7JjICxIQ5tcDTeXwpTPTtBA8W59a2dgNk8YA0c44QJyKYYFsB TgGqTzkpH+rQeV5VcPRebJJVmSFW1mEcOWIr0ICeBnM4I8aRNT0FB/1xT3iG8+seOHEy 8kh+BX40oJ23hUZB/j51SEzKSY71k9CC28PojJa23oUXg7hdboNVIWXsAjRq4CMKw15g oTo689h55XZRJr5KKX+YQz9N4R8NUywz1w6c4L1PbYHGr6gMxAt9G2fKtc6Vooj9tGQK ko1Q== X-Gm-Message-State: AD7BkJLG/EEazE10umUdUnd1uGiDwDqoB4F7E4KEd1L1t6g7vXa5fCyz9INb/lqgGAyoDzQ8NbQfo4mU7Elkrw== MIME-Version: 1.0 X-Received: by 10.31.8.17 with SMTP id 17mr7103208vki.139.1459883261995; Tue, 05 Apr 2016 12:07:41 -0700 (PDT) Received: by 10.31.87.66 with HTTP; Tue, 5 Apr 2016 12:07:41 -0700 (PDT) Date: Tue, 5 Apr 2016 12:07:41 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 05 Apr 2016 19:08:11 -0000 Hi, As you have seen, we have submitted a new revision of 5444-usage. The authors feel comfortable that we have addressed all issues by this version, and would like to ask the WG chairs to issue a WGLC on this document. While it is a fairly short document, given that it is IETF week for some, we'd suggest that a 3-4 week WGLC would be appropriate. Best regards Ulrich From nobody Wed Apr 6 04:40: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 945E312D564 for ; Wed, 6 Apr 2016 04:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.93 X-Spam-Level: X-Spam-Status: No, score=-6.93 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, T_RP_MATCHES_RCVD=-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 REXv01DeDNNd for ; Wed, 6 Apr 2016 04:40:26 -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 EA04112D1B2 for ; Wed, 6 Apr 2016 04:40:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,447,1454976000"; d="scan'208";a="33074214" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 06 Apr 2016 12:40:25 +0100 X-IronPort-AV: E=Sophos;i="5.24,447,1454976000"; d="scan'208";a="112902027" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds016.greenlnk.net with ESMTP; 06 Apr 2016 12:40:24 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0248.002; Wed, 6 Apr 2016 12:40:23 +0100 From: "Dearlove, Christopher (UK)" To: Ulrich Herberg , "manet@ietf.org" Thread-Topic: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 Thread-Index: AQHRj26efzFsMll+IU2A0f8aUpvZOp980SWw Date: Wed, 6 Apr 2016 11:40:23 +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: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 06 Apr 2016 11:40:28 -0000 Obviously +1 to the request for WGLC. With regard to what's changed, technically the only significant thing is to= make it clear that if a protocol delivers a message to the multiplexer, th= e multiplexer must pass it on unchanged to the protocol (another instance o= f, at another router) unchanged. Without that nothing that the protocol its= elf chooses to do with regard to security makes sense. Though the protocol = can alternatively let the multiplexer do the security, 7182 can be implemen= ted in either way. This isn't really new, but it wasn't formally spelled ou= t. It's presented as part of spelling out multiplexer rules more carefully. But what about message optimisation? That's a function of constructing a 54= 44 message, not the multiplexer, and is down to that 5444 includes two thin= gs - packet/message structure (and implicitly, and in pretty much any imple= mentation I would expect to see, a parser and builder for that structure) a= nd the multiplexer. So we took the opportunity to separate out more clearly= a discussion of the two, which we think will be helpful. -- = 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 Ulrich Herberg Sent: 05 April 2016 20:08 To: manet@ietf.org Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 ----------------------! 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. Hi, As you have seen, we have submitted a new revision of 5444-usage. The autho= rs feel comfortable that we have addressed all issues by this version, and = would like to ask the WG chairs to issue a WGLC on this document. While it = is a fairly short document, given that it is IETF week for some, we'd sugge= st that a 3-4 week WGLC would be appropriate. Best regards Ulrich _______________________________________________ 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 Apr 6 07:26:46 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 ED9CF12D0C0 for ; Wed, 6 Apr 2016 07:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, 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 eunRvzRaOGYm for ; Wed, 6 Apr 2016 07:26:42 -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 9A8EA12D62F for ; Wed, 6 Apr 2016 07:26:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 5C249240D75; Wed, 6 Apr 2016 07:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1459952802; bh=q24i7pKF4QWWp9PT3U2LH+xESMBGrH49Tq3eVqHGHI4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=lzo3aNbSy4lwYLe4SHgQsqUJhoxocx9uPjJ4JN7Dfm5k/VUcuqsfoP1wDy6+zApKM CuNh16EfM1AEVIQ/+NXzzGnZvmioZaQPspz4VYsRW5oMNZ6z7t2wYMJz9fGQNQD0nn OCYzBQ3z+RIXBBPeDsWi8AXAR+te8KwsVlGew8Do= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [129.104.73.197] (unknown [129.104.73.197]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 03515245B61; Wed, 6 Apr 2016 07:26:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (13E238) In-Reply-To: Date: Wed, 6 Apr 2016 16:26:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <65192AE5-CA15-49C9-AC0D-D5B1F363523E@thomasclausen.org> References: To: "Dearlove, Christopher (UK)" Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 06 Apr 2016 14:26:45 -0000 > On 06 Apr 2016, at 13:40, Dearlove, Christopher (UK) wrote: >=20 > Obviously +1 to the request for WGLC. >=20 Obviously also +1 from me. Thomas > With regard to what's changed, technically the only significant thing is t= o make it clear that if a protocol delivers a message to the multiplexer, th= e multiplexer must pass it on unchanged to the protocol (another instance of= , at another router) unchanged. Without that nothing that the protocol itsel= f chooses to do with regard to security makes sense. Though the protocol can= alternatively let the multiplexer do the security, 7182 can be implemented i= n either way. This isn't really new, but it wasn't formally spelled out. It'= s presented as part of spelling out multiplexer rules more carefully. >=20 > But what about message optimisation? That's a function of constructing a 5= 444 message, not the multiplexer, and is down to that 5444 includes two thin= gs - packet/message structure (and implicitly, and in pretty much any implem= entation I would expect to see, a parser and builder for that structure) and= the multiplexer. So we took the opportunity to separate out more clearly a d= iscussion of the two, which we think will be helpful. >=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 > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg > Sent: 05 April 2016 20:08 > To: manet@ietf.org > Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 >=20 > ----------------------! WARNING ! ---------------------- This message orig= inates 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 attachm= ents or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. > -------------------------------------------------------- >=20 > *** WARNING *** > EXTERNAL EMAIL -- This message originates from outside our organization. >=20 >=20 > Hi, >=20 > As you have seen, we have submitted a new revision of 5444-usage. The auth= ors feel comfortable that we have addressed all issues by this version, and w= ould like to ask the WG chairs to issue a WGLC on this document. While it is= a fairly short document, given that it is IETF week for some, we'd suggest t= hat a 3-4 week WGLC would be appropriate. >=20 > Best regards > Ulrich >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=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 From nobody Wed Apr 6 10:14: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 405DE12D5F0 for ; Wed, 6 Apr 2016 10:14:47 -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 aNWH1V1-FN6C for ; Wed, 6 Apr 2016 10:14:45 -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 2165112D4FC for ; Wed, 6 Apr 2016 10:14:45 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id e185so67030438vkb.1 for ; Wed, 06 Apr 2016 10:14:45 -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=fPNUNtMiV3+3jiT7wIj8Xc2UPImEcyZqOQKBoG+kkGo=; b=0T9e6REjryt5za4DsT6xYy70i+0rXz8+CecCuz/shTC+ZIELbvhLBjqR8q9Zre9/jG 55Y0DEBgpYhRhgoKF2qXH7IuuoPzyvMKOdKHAOHebzSByTdrTWOKbdjxDB3ajSw218oD ZxUfs8JktkvWQXYVilbVHFFJUtrf23klxqI8stYt7i3QK7RyIMpYUlwoKS0RRM1rdDEf kwpcU+CPtOd4z7t/GZT+NoinNIkl0BPFfz53Tm6TJstOo0P6XZadUPnFZPeraJV9JRFY EBewz9rLL1lYyiXqWdaPTVPS2M1n3OQpTP9aXBN7vk5OSGVhxJhTLpLjr+X74linCDd6 rRpQ== 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=fPNUNtMiV3+3jiT7wIj8Xc2UPImEcyZqOQKBoG+kkGo=; b=cLDYiv9YY//w+HOEad7x91AMh08J7eSd3Umvf5uDEks8dAHp2qLGvj+aRVl3fIefZW Fo9tkXH/G9MxA5w5pWSwCj5NvKXdvHibGzqYqxOZdm2LeNV0NvETIJ1jdYKHr4aB8Mfx RyTQE+ltPNm3FJeuUW55dpxVrQ5B1YJvU6IdcRo1DDxhkJti9yJk2sbjrZSkLwrdoapX ygsLARI+jQ49WCCMSjGgd1Z9BQILCwEH/gcLROw6WQFIFlAXsjQyw1eIFmcCrqF2egQK kVrkC7r9sbMhwCVMyJyBPmACOnI4NPrEtH6im445Ntmb0pkzzBGpGBHNZaOqFuQm92fX f+/Q== X-Gm-Message-State: AD7BkJKa8SpZBgoQpnHf4FAm/3VPA+b7YGlM2hE998jcTNW0XOd0gcKb+fFMHIjOvAgnmSSJQ4IB97BjpsHQJA== MIME-Version: 1.0 X-Received: by 10.159.36.120 with SMTP id 111mr16418186uaq.29.1459962884206; Wed, 06 Apr 2016 10:14:44 -0700 (PDT) Received: by 10.31.62.67 with HTTP; Wed, 6 Apr 2016 10:14:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Apr 2016 13:14:44 -0400 Message-ID: From: Justin Dean To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a1135227419385b052fd41981 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 06 Apr 2016 17:14:47 -0000 --001a1135227419385b052fd41981 Content-Type: text/plain; charset=UTF-8 The chairs agree that a 3 week WGLC is appropriate. Everyone please read the draft early and get comments in early so that they can be addressed within the last call period. Justin On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > Obviously +1 to the request for WGLC. > > With regard to what's changed, technically the only significant thing is > to make it clear that if a protocol delivers a message to the multiplexer, > the multiplexer must pass it on unchanged to the protocol (another instance > of, at another router) unchanged. Without that nothing that the protocol > itself chooses to do with regard to security makes sense. Though the > protocol can alternatively let the multiplexer do the security, 7182 can be > implemented in either way. This isn't really new, but it wasn't formally > spelled out. It's presented as part of spelling out multiplexer rules more > carefully. > > But what about message optimisation? That's a function of constructing a > 5444 message, not the multiplexer, and is down to that 5444 includes two > things - packet/message structure (and implicitly, and in pretty much any > implementation I would expect to see, a parser and builder for that > structure) and the multiplexer. So we took the opportunity to separate out > more clearly a discussion of the two, which we think will be helpful. > > -- > 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 > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg > Sent: 05 April 2016 20:08 > To: manet@ietf.org > Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > ----------------------! WARNING ! ---------------------- This message > originates from outside our organisation, either from an external partner > or from the internet. > Consider carefully whether you should click on any links, open any > attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions > on reporting suspicious email messages. > -------------------------------------------------------- > > *** WARNING *** > EXTERNAL EMAIL -- This message originates from outside our organization. > > > Hi, > > As you have seen, we have submitted a new revision of 5444-usage. The > authors feel comfortable that we have addressed all issues by this version, > and would like to ask the WG chairs to issue a WGLC on this document. While > it is a fairly short document, given that it is IETF week for some, we'd > suggest that a 3-4 week WGLC would be appropriate. > > Best regards > Ulrich > > _______________________________________________ > 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 > --001a1135227419385b052fd41981 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The chairs agree that a 3 week WGLC is appropriate.=C2=A0 = Everyone please read the draft early and get comments in early so that they= can be addressed within the last call period.

Justin

On Wed, = Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) <chris.dear= love@baesystems.com> wrote:
Obviously +1 to the request for WGLC.

With regard to what's changed, technically the only significant thing i= s to make it clear that if a protocol delivers a message to the multiplexer= , the multiplexer must pass it on unchanged to the protocol (another instan= ce of, at another router) unchanged. Without that nothing that the protocol= itself chooses to do with regard to security makes sense. Though the proto= col can alternatively let the multiplexer do the security, 7182 can be impl= emented in either way. This isn't really new, but it wasn't formall= y spelled out. It's presented as part of spelling out multiplexer rules= more carefully.

But what about message optimisation? That's a function of constructing = a 5444 message, not the multiplexer, and is down to that 5444 includes two = things - packet/message structure (and implicitly, and in pretty much any i= mplementation I would expect to see, a parser and builder for that structur= e) and the multiplexer. So we took the opportunity to separate out more cle= arly a discussion of the two, which we think will be helpful.

--
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

-----Original Message-----
From: manet [mailto:manet-bounces= @ietf.org] On Behalf Of Ulrich Herberg
Sent: 05 April 2016 20:08
To: manet@ietf.org
Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

----------------------! 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 instru= ctions on reporting suspicious email messages.
--------------------------------------------------------

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


Hi,

As you have seen, we have submitted a new revision of 5444-usage. The autho= rs feel comfortable that we have addressed all issues by this version, and = would like to ask the WG chairs to issue a WGLC on this document. While it = is a fairly short document, given that it is IETF week for some, we'd s= uggest that a 3-4 week WGLC would be appropriate.

Best regards
Ulrich

_______________________________________________
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

--001a1135227419385b052fd41981-- From nobody Thu Apr 7 08:01: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 91F2F12D147 for ; Thu, 7 Apr 2016 08:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 uHeh1Zkl3uaR for ; Thu, 7 Apr 2016 08:01:48 -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 BD19B12D5DF for ; Thu, 7 Apr 2016 07:49:49 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1aoBFj-001I7n-Le>; Thu, 07 Apr 2016 16:49:47 +0200 Received: from x4e3381aa.dyn.telefonica.de ([78.51.129.170] helo=[192.168.1.2]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id <1aoBFj-001ve3-7o>; Thu, 07 Apr 2016 16:49:47 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_B9E0CF32-8800-4FD6-B819-4778D8BEF6FB" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Lotte Steenbrink In-Reply-To: <04D7135E-8EDF-49DC-8978-3A1132FF3915@thomasclausen.org> Date: Thu, 7 Apr 2016 16:49:46 +0200 Message-Id: References: <20160405101903.773.31003.idtracker@ietfa.amsl.com> <8438BA85-DFC2-4192-84EE-999572C35FD1@fu-berlin.de> <04D7135E-8EDF-49DC-8978-3A1132FF3915@thomasclausen.org> To: Mobile Ad Hoc Networks mailing list X-Mailer: Apple Mail (2.3112) X-Originating-IP: 78.51.129.170 X-ZEDAT-Hint: A Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-14.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, 07 Apr 2016 15:01:55 -0000 --Apple-Mail=_B9E0CF32-8800-4FD6-B819-4778D8BEF6FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Thomas, > Am 05.04.2016 um 20:07 schrieb ietf@thomasclausen.org: >=20 > Lotte, >=20 > Thank you for this update. An impressive amount of changes to the = document, according to RFCdiff, and as I can see from your mail that = there is much more to come, Thanks! I=E2=80=99m glad you=E2=80=99re seeing the progress we=E2=80=99ve = made.=20 > I hope that you forgive me for not jumping at a blow-by-blow review = until a version which the authors themselves consider stable, is = produced. >=20 > On the point of =E2=80=9Cmuch more to come", there have been quite a = few comments raised by WG participants other than Mr. Dean and Chris = (such as by myself, but not only) =E2=80=94 some of which intersect some = of the below, and for which I do not believe that a satisfactory = resolution has been developed, presented to the WG, and confirmed. I=E2=80=99m not quite sure which comments exactly you are referring to? = Your last comments that come to mind are the ones in these threads: https://www.ietf.org/mail-archive/web/manet/current/msg18055.html = https://www.ietf.org/mail-archive/web/manet/current/msg18639.html = You=E2=80=99ve announced to go through the former in your last response = to the latter, but as far as I can see you haven=E2=80=99t gotten round = to doing that and a lot of points you=E2=80=99ve brought up have sparked = ongoing discussions, so I=E2=80=99ve marked most of your comments as = =E2=80=9Cpending=E2=80=93 still in discussion=E2=80=9D in my mind.=20 Regarding the points you brought up that aren=E2=80=99t affected by = this: * Metrics=E2=80=93 we=E2=80=99ve had discussions about this many moons = ago with authors on both sides of the fence. Unfortunately I can=E2=80=99t= remember the counter arguments, and I=E2=80=99m still looking for = records of this conversation=E2=80=A6 I=E2=80=99ll get back to you when = I=E2=80=99ve found out more. * Prefixes & Gateways: I=E2=80=99ve added a sentence to clarify that = AODVv2 doesn=E2=80=99t do RREQs for gateways, I hop that helps? >=20 > In which revision of the I-D do you plan on addressing those? >=20 If the discussions reach a conclusion by then, I=E2=80=99d be glad to = have them addressed by the next revision. Best regards, Lotte > Best, >=20 > Thomas >=20 >=20 >=20 >> On Apr 5, 2016, at 12:53, Lotte Steenbrink = > = wrote: >>=20 >> Hi all, >> just a quick summary of what is and what isn=E2=80=99t included in = this update of the draft: >>=20 >> DONE: >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94 >> * All JWD! comments (i.e. the critical ones) are resolved >> * Out of 90 JWD and JWD! comments, 61 are resolved >> * The revised security considerations [1] were added (with the TODOs = commented out) >> * The following TODO from [1] was resolved:=20 >> "This description MUST >> include the reasons it was either unreasonable or out of scope to >> attempt to avoid these denial of service attacks." >> * Section 9 now contains a statement that AODVv2 doesn=E2=80=99t = support RREQs for prefixes, I hope that clears things up for Thomas. >>=20 >> TO DO: >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=20 >> * Most notable of the 29 JWDs that are yet to be resolved: >> + (is there some table that lists routes that are being waited = on? JWD) We decided to add a separate=20 >> RREP table that lists them and I=E2=80=99ve volunteered to = write text for that, but we=E2=80=99re currently discussing if/how >> we might solve this without adding yet another table. >>=20 >> + We=E2=80=99re currently discussing the approaching the limit = thing. (i.e. >> (There is no defined behavior here. Approaching the limit? = Section 6.5 outlines which messages are more important but now how to = decide to allow them to be transmitted or not. JWD=20 >> and >> (The undefined approaching the limit thing again JWD) etc >> We=E2=80=99ve already clarified the wording regarding what = the limit is and how to prioritize the message types,=20 >> what=E2=80=99s left is to define what =E2=80=9Eapproaching=E2= =80=9C means (and whether we need to talk about approaching rather than >> just saying =E2=80=9Ehere=E2=80=99s what to do when you = actually hit the limit"). >>=20 >> + (I don=E2=80=99t want to spam the list with a comprehensive = list of all of them, but if you=E2=80=99re interested in seeing them, >> please do say so and I=E2=80=99ll send my copy of = Justin=E2=80=99s review containing all TODOs and DONEs to the list) >> * some TODOs in security considerations (see [1]) >> * since we're waiting for Chris=E2=80=99 feedback regarding the = revised 5444 multiplexer wording, that hasn=E2=80=99t changed yet. >>=20 >> More details can be found in Appendix A. AODVv2 Draft Updates, as = well as the diff, of course. >>=20 >> Best regards, >> Lotte >>=20 >> [1] Re: [manet] AODVv2: Security considerations update = https://www.ietf.org/mail-archive/web/manet/current/msg18458.html = >>=20 >>=20 >>> Am 05.04.2016 um 12:19 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-14.txt >>> Pages : 80 >>> Date : 2016-04-05 >>>=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-14 = >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-14 >>>=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 = >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet = --Apple-Mail=_B9E0CF32-8800-4FD6-B819-4778D8BEF6FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Thomas,

Am 05.04.2016 um 20:07 schrieb = ietf@thomasclausen.org:

Lotte,

Thank you for this = update. An impressive amount of changes to the document, according to = RFCdiff, and as I can see from your mail that there is much more to = come,

Thanks!= I=E2=80=99m glad you=E2=80=99re seeing the progress we=E2=80=99ve = made. 

= I hope that you forgive me for not jumping at a blow-by-blow review = until a version which the authors themselves consider stable, is = produced.

On = the point of =E2=80=9Cmuch more to come", there have been quite a few = comments raised by WG participants other than Mr. Dean and Chris =  (such as by myself, but not only) =E2=80=94 some of which = intersect some of the below, and for which I do not believe that a = satisfactory resolution has been developed, presented to the WG, and = confirmed.

I=E2=80=99m not quite sure which comments exactly = you are referring to? Your last comments that come to mind are the ones = in these threads:


You=E2=80=99ve announced to = go through the former in your last response to the latter, but as far as = I can see you haven=E2=80=99t gotten round to doing that and a lot of = points you=E2=80=99ve brought up have sparked ongoing discussions, so = I=E2=80=99ve marked most of your comments as =E2=80=9Cpending=E2=80=93 = still in discussion=E2=80=9D in my mind. 
Regarding the = points you brought up that aren=E2=80=99t affected by = this:

* Metrics=E2=80=93 we=E2=80=99ve= had discussions about this many moons ago with authors on both sides of = the fence. Unfortunately I can=E2=80=99t remember the counter arguments, = and I=E2=80=99m still looking for records of this conversation=E2=80=A6 = I=E2=80=99ll get back to you when I=E2=80=99ve found out = more.
* Prefixes & Gateways: I=E2=80=99= ve added a sentence to clarify that AODVv2 doesn=E2=80=99t do RREQs for = gateways, I hop that helps?


In which = revision of the I-D do you plan on addressing those?


If the discussions reach a conclusion by then, = I=E2=80=99d be glad to have them addressed by the next = revision.

Best = regards,
Lotte

Best,

Thomas



On Apr 5, 2016, at 12:53, Lotte Steenbrink = <lotte.steenbrink@fu-berlin.de> wrote:

Hi all,
just a quick summary of what is and = what isn=E2=80=99t included in this update of the draft:

DONE:
=E2=80=94=E2=80=94=E2=80=94=E2=80=94
* = All JWD! comments (i.e. the critical ones) are resolved
* Out of 90 JWD and JWD! comments, 61 are resolved
* The revised security considerations [1] were added (with = the TODOs commented out)
* The following TODO from = [1] was resolved: 
   "This description = MUST
  =  include the reasons it was either unreasonable or out of scope = to
  =  attempt to avoid these denial of service = attacks."
* Section 9 now contains a = statement that AODVv2 doesn=E2=80=99t support RREQs for prefixes, I hope = that clears things up for Thomas.

TO DO:
=E2=80=94=E2=80=94=E2=80=94=E2=80=94 
* Most notable of the 29 JWDs that are yet to be = resolved:
+ (is there = some table that lists routes that are being waited on? JWD) We = decided to add a separate 
    =        RREP table that lists them and I=E2=80=99ve = volunteered to write text for that, but we=E2=80=99re currently = discussing if/how
        =    we might solve this without adding yet another = table.

+ We=E2=80=99= re currently discussing the approaching the limit thing. (i.e.
   (There is no defined = behavior here. Approaching the limit? Section 6.5 outlines which = messages are more important but now how to decide to allow them to be = transmitted or not. JWD 
  and
=   (The undefined approaching the limit thing again JWD) = etc
          =  We=E2=80=99ve already clarified the wording regarding what the = limit is and how to prioritize the message types, 
           what=E2=80=99s left = is to define what =E2=80=9Eapproaching=E2=80=9C means (and whether we = need to talk about approaching rather than
  =          just saying =E2=80=9Ehere=E2=80=99s = what to do when you actually hit the limit").

    + (I = don=E2=80=99t want to spam the list with a comprehensive list of all of = them, but if you=E2=80=99re interested in seeing them,
           please do say so and = I=E2=80=99ll send my copy of Justin=E2=80=99s review containing all = TODOs and DONEs to the list)
* some TODOs in = security considerations (see [1])
* since we're = waiting for Chris=E2=80=99 feedback regarding the revised 5444 = multiplexer wording, that hasn=E2=80=99t changed yet.

More details can be found in Appendix A.  AODVv2 Draft = Updates, as well as the diff, of course.

Best regards,
Lotte

[1] Re: [manet] AODVv2: Security = considerations update https://www.ietf.org/mail-archive/web/manet/current/msg18458.ht= ml


Am 05.04.2016 um 12:19 = schrieb internet-drafts@ietf.org:


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
          &nb= sp;            = ;  Stan Ratliff
          &nb= sp;            = ;  John Dowdell
          &nb= sp;            = ;  Lotte Steenbrink
          &nb= sp;            = ;  Victoria Mercieca
Filename =        : = draft-ietf-manet-aodvv2-14.txt
Pages =           : 80
= Date =            : = 2016-04-05

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-14

A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-14<= /a>


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/

_______________________________________________
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=_B9E0CF32-8800-4FD6-B819-4778D8BEF6FB-- From nobody Thu Apr 7 09:55: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 4F41412D15E for ; Thu, 7 Apr 2016 09:55:34 -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 QsoqQX9nPir8 for ; Thu, 7 Apr 2016 09:55:31 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 5CE4B12D16E for ; Thu, 7 Apr 2016 09:55:31 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id n3so112979193wmn.0 for ; Thu, 07 Apr 2016 09:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=PldmwaZ8/KH1YUmfBt3esa/DtTwdJ53isVqXR2xkEx4=; b=Mn6iejqtaxZ7gbw402u/WCv9wqhA8VU69RQC3hPv1r0AYiwfNzL5z6Fp+Aih+x8nvS qbAV+wKkg7cMPkeMW+esVMFVw79j2ty9FmdXBLHmw/sT+dfVGPp0FdqoyKV4pRyXlV8p bg0rWbcPOf2kxkaUVOh+ULkVdqNH5VFLSyNkVn8XRQ68qoqIhZ7h6VNsWcdkFaQvZhzH LoG7zJD8ZL8Wri3ztTQBC5jVoCMN3T9zhCQh7ZpBX/Cn7LaxmgeTzNp7NMyN0z6LSnbv D5iE8dWQBnTz1dMsCe49VtVLOk4CRlj2AJJ0k3O8NVuReVWI5/ksj3zmlV1a9UhsGdUd GPIA== 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 :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=PldmwaZ8/KH1YUmfBt3esa/DtTwdJ53isVqXR2xkEx4=; b=lklEilQVwozun4F7vrbRItcmqE/bAOzeHetdk7kvCZbEUtGOSZ6KHHRWyHYuygrGfX hhcYYmTwi8RuYn6wv//958k82AyC2teHekt7WaO1jrgnAxS6gf4PNXQbDYCbS+ElJLCA IoUbRZ/dZeluWAwK0VSc8BXJNUpgjQkm1kETODcAasbeT/OyMJEvb7OU8+LNgftXHtD8 ubeR2nuoSb6vlMcYzSkLdmGejXgZ9pbcYc9Kh98kq5XCZpRdACwrsIS1VLaHYqFNGPE/ LMmjZ/DNuKl0JFJZ4wnC7h1mIRbPxF1ixkhB9+/cIDupJJs1BntdtcFVWRVbgsUz8VuK vy0Q== X-Gm-Message-State: AD7BkJJ9lSuuJiFmWfediioyUTRQ8vsQS1wz7pIBHkLGi+yPZ/9oDnuQl9GsI0NFbKl2LQ== X-Received: by 10.194.71.171 with SMTP id w11mr5273076wju.36.1460048129716; Thu, 07 Apr 2016 09:55:29 -0700 (PDT) Received: from [10.2.92.176] (dab-ntm1-h-12-9.dab.02.net. [82.132.231.88]) by smtp.gmail.com with ESMTPSA id om6sm9319974wjc.40.2016.04.07.09.55.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 09:55:28 -0700 (PDT) References: <20160405101903.773.31003.idtracker@ietfa.amsl.com> <8438BA85-DFC2-4192-84EE-999572C35FD1@fu-berlin.de> <04D7135E-8EDF-49DC-8978-3A1132FF3915@thomasclausen.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1CC95C94-EAB8-4BD6-8AA4-1A738A27A24C Message-Id: X-Mailer: iPhone Mail (13E238) From: Christopher Dearlove Date: Thu, 7 Apr 2016 17:55:24 +0100 To: Lotte Steenbrink Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-14.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, 07 Apr 2016 16:55:34 -0000 --Apple-Mail-1CC95C94-EAB8-4BD6-8AA4-1A738A27A24C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [This time from a subscribed address.] You say you've added a sentence saying AODVv2 doesn't do RREQs for gateways.= What should have happened is a discussion on this list as to why? is that h= ard? does anyone have a clever idea to make it not hard? does anyone need th= at functionality? and so on. For example, here's something that superficially looks like it might work. D= oes it, or does it introduce new problems? I don't know. But this, and likel= y better ideas, just haven't had discussion here - and I fear that the peopl= e who might have the better ideas have departed unheard. So, a router wants a route to a.b.c.d, and sends an RREQ for that (/32, or s= imply omit). Of course any router directly serving that address just replies= . But a router that is serving a.0.0.0/8 could reply with that address. The o= riginating router of course would use standard IP maximum prefix length rule= s. Does that work? Does it help anyone? Could a router reply a.b.c.d/32 and a= .0.0.0/8 in one RREP? Or could it be allowed to reply a.b.c.d/8 as a shortha= nd? And why can't a router request a.b.0.0/16 - and possibly get an a.0.0.0/= 8 reply? Answers to all of those is "I don't know". But we should have been having t= hose discussions. --=20 Christopher Dearlove christopher.dearlove@gmail.com -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 7 Apr 2016, at 15:49, Lotte Steenbrink w= rote: >=20 > Hi Thomas, >=20 >> Am 05.04.2016 um 20:07 schrieb ietf@thomasclausen.org: >>=20 >> Lotte, >>=20 >> Thank you for this update. An impressive amount of changes to the documen= t, according to RFCdiff, and as I can see from your mail that there is much m= ore to come, >=20 > Thanks! I=E2=80=99m glad you=E2=80=99re seeing the progress we=E2=80=99ve m= ade.=20 >=20 >> I hope that you forgive me for not jumping at a blow-by-blow review until= a version which the authors themselves consider stable, is produced. >>=20 >> On the point of =E2=80=9Cmuch more to come", there have been quite a few c= omments raised by WG participants other than Mr. Dean and Chris (such as by= myself, but not only) =E2=80=94 some of which intersect some of the below, a= nd for which I do not believe that a satisfactory resolution has been develo= ped, presented to the WG, and confirmed. >=20 > I=E2=80=99m not quite sure which comments exactly you are referring to? Yo= ur last comments that come to mind are the ones in these threads: >=20 > https://www.ietf.org/mail-archive/web/manet/current/msg18055.html > https://www.ietf.org/mail-archive/web/manet/current/msg18639.html >=20 > You=E2=80=99ve announced to go through the former in your last response to= the latter, but as far as I can see you haven=E2=80=99t gotten round to doi= ng that and a lot of points you=E2=80=99ve brought up have sparked ongoing d= iscussions, so I=E2=80=99ve marked most of your comments as =E2=80=9Cpending= =E2=80=93 still in discussion=E2=80=9D in my mind.=20 > Regarding the points you brought up that aren=E2=80=99t affected by this: >=20 > * Metrics=E2=80=93 we=E2=80=99ve had discussions about this many moons ago= with authors on both sides of the fence. Unfortunately I can=E2=80=99t reme= mber the counter arguments, and I=E2=80=99m still looking for records of thi= s conversation=E2=80=A6 I=E2=80=99ll get back to you when I=E2=80=99ve found= out more. > * Prefixes & Gateways: I=E2=80=99ve added a sentence to clarify that AODVv= 2 doesn=E2=80=99t do RREQs for gateways, I hop that helps? >=20 >>=20 >> In which revision of the I-D do you plan on addressing those? >=20 > If the discussions reach a conclusion by then, I=E2=80=99d be glad to have= them addressed by the next revision. >=20 > Best regards, > Lotte >=20 >> Best, >>=20 >> Thomas >>=20 >>=20 >>=20 >>> On Apr 5, 2016, at 12:53, Lotte Steenbrink wrote: >>>=20 >>> Hi all, >>> just a quick summary of what is and what isn=E2=80=99t included in this u= pdate of the draft: >>>=20 >>> DONE: >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>> * All JWD! comments (i.e. the critical ones) are resolved >>> * Out of 90 JWD and JWD! comments, 61 are resolved >>> * The revised security considerations [1] were added (with the TODOs com= mented out) >>> * The following TODO from [1] was resolved:=20 >>> "This description MUST >>> include the reasons it was either unreasonable or out of scope to >>> attempt to avoid these denial of service attacks." >>> * Section 9 now contains a statement that AODVv2 doesn=E2=80=99t support= RREQs for prefixes, I hope that clears things up for Thomas. >>>=20 >>> TO DO: >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=20 >>> * Most notable of the 29 JWDs that are yet to be resolved: >>> + (is there some table that lists routes that are being waited on? J= WD) We decided to add a separate=20 >>> RREP table that lists them and I=E2=80=99ve volunteered to wr= ite text for that, but we=E2=80=99re currently discussing if/how >>> we might solve this without adding yet another table. >>>=20 >>> + We=E2=80=99re currently discussing the approaching the limit thin= g. (i.e. >>> (There is no defined behavior here. Approaching the limit? Secti= on 6.5 outlines which messages are more important but now how to decide to a= llow them to be transmitted or not. JWD=20 >>> and >>> (The undefined approaching the limit thing again JWD) etc >>> We=E2=80=99ve already clarified the wording regarding what th= e limit is and how to prioritize the message types,=20 >>> what=E2=80=99s left is to define what =E2=80=9Eapproaching=E2= =80=9C means (and whether we need to talk about approaching rather than >>> just saying =E2=80=9Ehere=E2=80=99s what to do when you actua= lly hit the limit"). >>>=20 >>> + (I don=E2=80=99t want to spam the list with a comprehensive list o= f all of them, but if you=E2=80=99re interested in seeing them, >>> please do say so and I=E2=80=99ll send my copy of Justin=E2=80= =99s review containing all TODOs and DONEs to the list) >>> * some TODOs in security considerations (see [1]) >>> * since we're waiting for Chris=E2=80=99 feedback regarding the revised 5= 444 multiplexer wording, that hasn=E2=80=99t changed yet. >>>=20 >>> More details can be found in Appendix A. AODVv2 Draft Updates, as well a= s the diff, of course. >>>=20 >>> Best regards, >>> Lotte >>>=20 >>> [1] Re: [manet] AODVv2: Security considerations update https://www.ietf.= org/mail-archive/web/manet/current/msg18458.html >>>=20 >>>=20 >>>> Am 05.04.2016 um 12:19 schrieb internet-drafts@ietf.org: >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>>> 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 (AO= DVv2) Routing >>>> Authors : Charles E. Perkins >>>> Stan Ratliff >>>> John Dowdell >>>> Lotte Steenbrink >>>> Victoria Mercieca >>>> Filename : draft-ietf-manet-aodvv2-14.txt >>>> Pages : 80 >>>> Date : 2016-04-05 >>>>=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-14 >>>>=20 >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-14 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of submi= ssion >>>> 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 >>>=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-1CC95C94-EAB8-4BD6-8AA4-1A738A27A24C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
[This time f= rom a subscribed address.]

You say you've added a s= entence saying AODVv2 doesn't do RREQs for gateways. What should have happen= ed is a discussion on this list as to why? is that hard? does anyone have a c= lever idea to make it not hard? does anyone need that functionality? and so o= n.

For example, here's something that superficially= looks like it might work. Does it, or does it introduce new problems? I don= 't know. But this, and likely better ideas, just haven't had discussion here= - and I fear that the people who might have the better ideas have departed u= nheard.

So, a router wants a route to a.b.c.d, and s= ends an RREQ for that (/32, or simply omit). Of course any router directly s= erving that address just replies. But a router that is serving a.0.0.0/8 cou= ld reply with that address. The originating router of course would use stand= ard IP maximum prefix length rules. Does that work? Does it help anyone? Cou= ld a router reply a.b.c.d/32 and a.0.0.0/8 in one RREP? Or could it be allow= ed to reply a.b.c.d/8 as a shorthand? And why can't a router request a.b.0.0= /16 - and possibly get an a.0.0.0/8 reply?

Answers t= o all of those is "I don't know".  But we should have been having those= discussions.

-- 
Christopher Dearlove



--  
Christopher Dearlove
On 7 Apr 2016, at 15:49, Lo= tte Steenbrink <lotte.st= eenbrink@fu-berlin.de> wrote:

=
Hi T= homas,

Am 05.04.2016 um 20:07 schrieb ietf@thomasclausen.org:

Lotte,

Thank you for t= his update. An impressive amount of changes to the document, according to RFC= diff, and as I can see from your mail that there is much more to come,
=

Thanks! I=E2=80=99m g= lad you=E2=80=99re seeing the progress we=E2=80=99ve made. 

I hope that you forgive me for not j= umping at a blow-by-blow review until a version which the authors themselves= consider stable, is produced.

On the point of =E2=80=9Cmuch more to come", there have been qu= ite a few comments raised by WG participants other than Mr. Dean and Chris &= nbsp;(such as by myself, but not only) =E2=80=94 some of which intersect som= e of the below, and for which I do not believe that a satisfactory resolutio= n has been developed, presented to the WG, and confirmed.
<= /blockquote>

I=E2=80=99m not quite sure which c= omments exactly you are referring to? Your last comments that come to mind a= re the ones in these threads:

https://www.ietf.org/mail-archive/web/manet/current/msg18055.html

You=E2=80=99ve announced t= o go through the former in your last response to the latter, but as far as I= can see you haven=E2=80=99t gotten round to doing that and a lot of points y= ou=E2=80=99ve brought up have sparked ongoing discussions, so I=E2=80=99ve m= arked most of your comments as =E2=80=9Cpending=E2=80=93 still in discussion= =E2=80=9D in my mind. 
Regarding the points you brought up th= at aren=E2=80=99t affected by this:

* Me= trics=E2=80=93 we=E2=80=99ve had discussions about this many moons ago with a= uthors on both sides of the fence. Unfortunately I can=E2=80=99t remember th= e counter arguments, and I=E2=80=99m still looking for records of this conve= rsation=E2=80=A6 I=E2=80=99ll get back to you when I=E2=80=99ve found out mo= re.
* Prefixes & Gateways: I=E2=80=99ve added a sentenc= e to clarify that AODVv2 doesn=E2=80=99t do RREQs for gateways, I hop that h= elps?


In which revision of the I-D do you plan on addressing tho= se?

=
If the discussions reach a conclusion by then, I=E2= =80=99d be glad to have them addressed by the next revision.

Best regards,
Lotte

Best,

Thomas



On Apr= 5, 2016, at 12:53, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:
<= br class=3D"Apple-interchange-newline">
Hi all,
just a quic= k summary of what is and what isn=E2=80=99t included in this update of the d= raft:

DONE:
=E2=80=94=E2=80=94=E2=80=94=E2=80=94
* All JWD! comments (i.e. the critical ones) are resolved
* Out of 90 JWD and JWD! comments, 61 are resolved
* The revised security considerations [1] were added (with the TODO= s commented out)
* The following TODO from [1] was reso= lved: 
   "This description MUST
   include the reasons it was either u= nreasonable or out of scope to
   attempt to avoid these denial of service attac= ks."
* Section 9 now contains a statement that A= ODVv2 doesn=E2=80=99t support RREQs for prefixes, I hope that clears things u= p for Thomas.

TO DO:
=E2=80=94=E2=80=94=E2=80=94=E2=80=94 
* Most notable of the 29 JWDs that are yet to be resolved:=
+ (is there some table that lists routes t= hat are being waited on? JWD) We decided to add a separate 
           RREP table that l= ists them and I=E2=80=99ve volunteered to write text for that, but we=E2=80=99= re currently discussing if/how
      &nb= sp;    we might solve this without adding yet another table.
=

+ We=E2=80=99re currently di= scussing the approaching the limit thing. (i.e.
   (There is no defined behavior here. Approaching the limit? S= ection 6.5 outlines which messages are more important but now how to decide t= o allow them to be transmitted or not. JWD 
  and
  = (The undefined approaching the limit thing again JWD) etc
           We=E2=80=99ve already clarif= ied the wording regarding what the limit is and how to prioritize the messag= e types, 
           = ;what=E2=80=99s left is to define what =E2=80=9Eapproaching=E2=80=9C means (= and whether we need to talk about approaching rather than
           just saying =E2=80=9Ehere=E2=80=99= s what to do when you actually hit the limit").

    + (I don=E2=80=99t want to spam= the list with a comprehensive list of all of them, but if you=E2=80=99re in= terested in seeing them,
        &n= bsp;  please do say so and I=E2=80=99ll send my copy of Justin=E2=80=99= s review containing all TODOs and DONEs to the list)
* s= ome TODOs in security considerations (see [1])
* since w= e're waiting for Chris=E2=80=99 feedback regarding the revised 5444 multiple= xer wording, that hasn=E2=80=99t changed yet.

More details can be found in Appendix A.  AODVv2 Draft Updates, as w= ell as the diff, of course.

Best regards,
Lotte

[1] Re: [manet] AODVv2: Security considerations upda= te https://ww= w.ietf.org/mail-archive/web/manet/current/msg18458.html

Am 05.04.2016 um 12:19 schr= ieb internet-drafts@ietf.org:


A New Internet-Draft is available from the on-line Internet-Drafts direct= ories.
This draft is a work item of the Mobile Ad-hoc Networks= of the IETF.

     &nb= sp; Title           := Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing
&= nbsp;      Authors     &nb= sp;   : Charles E. Perkins
   &n= bsp;            =          Stan Ratliff
            &= nbsp;            = ;John Dowdell
        =             &nbs= p;    Lotte Steenbrink
   &= nbsp;            = ;         Victoria Mercieca
Filename        : draft-ietf-manet-ao= dvv2-14.txt
Pages        &nbs= p;  : 80
Date       &nb= sp;    : 2016-04-05

Abstrac= t:
  The Ad Hoc On-demand Distance Vector Version 2 (= AODVv2) routing
  protocol is intended for use by mo= bile routers in wireless, multihop
  networks.  = ;AODVv2 determines unicast routes among AODVv2 routers
 &= nbsp;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-14

A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-a= odvv2-14


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

Internet-Drafts are a= lso available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
<= br class=3D"">_______________________________________________
= 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/m= anet


<= div>_______________________________________________
ma= net mailing list
manet@iet= f.org
https://www.ietf.org/mailman/listinfo/manet
= --Apple-Mail-1CC95C94-EAB8-4BD6-8AA4-1A738A27A24C-- From nobody Thu Apr 7 10:49: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 1B12E12D5B7 for ; Thu, 7 Apr 2016 10:49:43 -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 uAC370pbmNDw for ; Thu, 7 Apr 2016 10:49:38 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c: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 2020C12D0DA for ; Thu, 7 Apr 2016 10:49:38 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id t129so22641089vkg.2 for ; Thu, 07 Apr 2016 10:49: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=YpCZh5VlJrtpaceBvdADwhBH6cMZixOb628URw3SdTI=; b=v77tQN8JoAh5w/5y1nR1Y2bUkhAayAAW5LRL41UVIyzXtEk/1X959wI5BVJ135Iw/u eOQmIBrOOXpCEUYkQy609PLzxA/y1KnlE2MPbjPPW4DAzJ8LjAgc2kbGtW2QHhwfKywu O3/400TrX5zHuragXJkJ6XPimVtbYDrYdfZmAcLzUwREHvmcr8k14fsCkJaS6pJ2uN27 hzaJqutCQ+op434BfB5EWRyxnYXWzdOb7bwzFLlw9bggy459xpfoONzoOSYAGs6RVW9T aGM74OmB+mk2QjH0u4RHnZoBrnGC2+yoV90wH2aQV5NT784/wV+Dy1wlcZPlXdYRiTxm PyRg== 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=YpCZh5VlJrtpaceBvdADwhBH6cMZixOb628URw3SdTI=; b=A6DToIzW/hK75axTJx1kmjeZ1q60WczxRwOqZkP6ZYadMF9Fw19T2O0m3851DPLPcd vHP1ZwbXGU1sF20KgbtqF0Mww3Gv686fmQE8z9yYJ4esc0qRDGcDeqpLnu78j/e/h/tW 7GGiq7iVTA+SwXVRQvOuBb0SH8xPejhEWWMS+8VDWGUfwnIe6Z/NiWNczmwtrOr4gqa/ v6ud1ddiLjJoryOCfpEhu54ToX5nkBKENVle6+nIXxomZ2RV6IluC1BU0YwKBxR/1Phb r8Lrjf7XLoWcdebGybvX14SK9ZFE2knAZ40IrWbb3fambIg9r/EGcU/CKauZCXCS3R3X dwiQ== X-Gm-Message-State: AD7BkJLBdT5tU1YR+aBkFbjH0SC4miGoSAAOJMJdVQjx431jiQ+zvExpcPPxveKcn96fFD1kNPf75hW9NGWgPA== MIME-Version: 1.0 X-Received: by 10.176.7.97 with SMTP id h88mr2010648uah.125.1460051377225; Thu, 07 Apr 2016 10:49:37 -0700 (PDT) Received: by 10.159.54.237 with HTTP; Thu, 7 Apr 2016 10:49:37 -0700 (PDT) Received: by 10.159.54.237 with HTTP; Thu, 7 Apr 2016 10:49:37 -0700 (PDT) In-Reply-To: References: <20160405101903.773.31003.idtracker@ietfa.amsl.com> <8438BA85-DFC2-4192-84EE-999572C35FD1@fu-berlin.de> <04D7135E-8EDF-49DC-8978-3A1132FF3915@thomasclausen.org> Date: Thu, 7 Apr 2016 18:49:37 +0100 Message-ID: From: Victoria Mercieca To: Christopher Dearlove Content-Type: multipart/alternative; boundary=94eb2c1231e6b18873052fe8b38d Archived-At: Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-14.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, 07 Apr 2016 17:49:43 -0000 --94eb2c1231e6b18873052fe8b38d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Christopher, On 7 Apr 2016 1:55 pm, "Christopher Dearlove" < christopher.dearlove@gmail.com> wrote: > > [This time from a subscribed address.] > > You say you've added a sentence saying AODVv2 doesn't do RREQs for gateways. What should have happened is a discussion on this list as to why? is that hard? does anyone have a clever idea to make it not hard? does anyone need that functionality? and so on. > > For example, here's something that superficially looks like it might work. Does it, or does it introduce new problems? I don't know. But this, and likely better ideas, just haven't had discussion here - and I fear that the people who might have the better ideas have departed unheard. > > So, a router wants a route to a.b.c.d, and sends an RREQ for that (/32, or simply omit). Of course any router directly serving that address just replies. But a router that is serving a.0.0.0/8 could reply with that address. The originating router of course would use standard IP maximum prefix length rules. Does that work? Does it help anyone? Could a router reply a.b.c.d/32 and a.0.0.0/8 in one RREP? Or could it be allowed to reply a.b.c.d/8 as a shorthand? This is exactly what it does (based on the router client entry corresponding to TargAddr, e.g if router client entry is a.0.0.0/8, then the RREP contains a.b.c.d/8). Everyone receiving the RREP can then install the route to a.0.0.0/8 and therefore avoid a separate RREQ for (as an example) a.b.c.e in future. Similarly an RREQ contains the prefix length associated with the router client entry configured for OrigAddr, and routers processing the RREQ learn the route to OrigAddrs prefix. But you can't intentionally send a RREQ for a prefix because the RREQ is created when there's a packet to send, you know the destination address not the prefix associated with it, so TargAddr is a.b.c.d/32. But even so, you do end up learning a route to a prefix, if TargAddr is part of a router client entry which is a prefix. Kind regards, Victoria. > And why can't a router request a.b.0.0/16 - and possibly get an a.0.0.0/8 reply? > > Answers to all of those is "I don't know". But we should have been having those discussions. > > -- > Christopher Dearlove > christopher.dearlove@gmail.com > > > > -- > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) > On 7 Apr 2016, at 15:49, Lotte Steenbrink wrote: > >> Hi Thomas, >> >>> Am 05.04.2016 um 20:07 schrieb ietf@thomasclausen.org: >>> >>> Lotte, >>> >>> Thank you for this update. An impressive amount of changes to the document, according to RFCdiff, and as I can see from your mail that there is much more to come, >> >> >> Thanks! I=E2=80=99m glad you=E2=80=99re seeing the progress we=E2=80=99v= e made. >> >>> I hope that you forgive me for not jumping at a blow-by-blow review until a version which the authors themselves consider stable, is produced. >>> >>> On the point of =E2=80=9Cmuch more to come", there have been quite a fe= w comments raised by WG participants other than Mr. Dean and Chris (such as by myself, but not only) =E2=80=94 some of which intersect some of the belo= w, and for which I do not believe that a satisfactory resolution has been developed, presented to the WG, and confirmed. >> >> >> I=E2=80=99m not quite sure which comments exactly you are referring to? = Your last comments that come to mind are the ones in these threads: >> >> https://www.ietf.org/mail-archive/web/manet/current/msg18055.html >> https://www.ietf.org/mail-archive/web/manet/current/msg18639.html >> >> You=E2=80=99ve announced to go through the former in your last response = to the latter, but as far as I can see you haven=E2=80=99t gotten round to doing t= hat and a lot of points you=E2=80=99ve brought up have sparked ongoing discussions,= so I=E2=80=99ve marked most of your comments as =E2=80=9Cpending=E2=80=93 still in discussi= on=E2=80=9D in my mind. >> Regarding the points you brought up that aren=E2=80=99t affected by this= : >> >> * Metrics=E2=80=93 we=E2=80=99ve had discussions about this many moons a= go with authors on both sides of the fence. Unfortunately I can=E2=80=99t remember the coun= ter arguments, and I=E2=80=99m still looking for records of this conversation= =E2=80=A6 I=E2=80=99ll get back to you when I=E2=80=99ve found out more. >> * Prefixes & Gateways: I=E2=80=99ve added a sentence to clarify that AOD= Vv2 doesn=E2=80=99t do RREQs for gateways, I hop that helps? >> >>> >>> In which revision of the I-D do you plan on addressing those? >>> >> >> If the discussions reach a conclusion by then, I=E2=80=99d be glad to ha= ve them addressed by the next revision. >> >> Best regards, >> Lotte >> >>> Best, >>> >>> Thomas >>> >>> >>> >>>> On Apr 5, 2016, at 12:53, Lotte Steenbrink < lotte.steenbrink@fu-berlin.de> wrote: >>>> >>>> Hi all, >>>> just a quick summary of what is and what isn=E2=80=99t included in thi= s update of the draft: >>>> >>>> DONE: >>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>>> * All JWD! comments (i.e. the critical ones) are resolved >>>> * Out of 90 JWD and JWD! comments, 61 are resolved >>>> * The revised security considerations [1] were added (with the TODOs commented out) >>>> * The following TODO from [1] was resolved: >>>> "This description MUST >>>> include the reasons it was either unreasonable or out of scope to >>>> attempt to avoid these denial of service attacks." >>>> * Section 9 now contains a statement that AODVv2 doesn=E2=80=99t suppo= rt RREQs for prefixes, I hope that clears things up for Thomas. >>>> >>>> TO DO: >>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>>> * Most notable of the 29 JWDs that are yet to be resolved: >>>> + (is there some table that lists routes that are being waited on? JWD) We decided to add a separate >>>> RREP table that lists them and I=E2=80=99ve volunteered to = write text for that, but we=E2=80=99re currently discussing if/how >>>> we might solve this without adding yet another table. >>>> >>>> + We=E2=80=99re currently discussing the approaching the limit thing. = (i.e. >>>> (There is no defined behavior here. Approaching the limit? Section 6.5 outlines which messages are more important but now how to decide to allow them to be transmitted or not. JWD >>>> and >>>> (The undefined approaching the limit thing again JWD) etc >>>> We=E2=80=99ve already clarified the wording regarding what = the limit is and how to prioritize the message types, >>>> what=E2=80=99s left is to define what =E2=80=9Eapproaching= =E2=80=9C means (and whether we need to talk about approaching rather than >>>> just saying =E2=80=9Ehere=E2=80=99s what to do when you act= ually hit the limit"). >>>> >>>> + (I don=E2=80=99t want to spam the list with a comprehensive list= of all of them, but if you=E2=80=99re interested in seeing them, >>>> please do say so and I=E2=80=99ll send my copy of Justin=E2= =80=99s review containing all TODOs and DONEs to the list) >>>> * some TODOs in security considerations (see [1]) >>>> * since we're waiting for Chris=E2=80=99 feedback regarding the revise= d 5444 multiplexer wording, that hasn=E2=80=99t changed yet. >>>> >>>> More details can be found in Appendix A. AODVv2 Draft Updates, as well as the diff, of course. >>>> >>>> Best regards, >>>> Lotte >>>> >>>> [1] Re: [manet] AODVv2: Security considerations update https://www.ietf.org/mail-archive/web/manet/current/msg18458.html >>>> >>>> >>>>> Am 05.04.2016 um 12:19 schrieb internet-drafts@ietf.org: >>>>> >>>>> >>>>> 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-14.txt >>>>> Pages : 80 >>>>> Date : 2016-04-05 >>>>> >>>>> Abstract: >>>>> The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing >>>>> protocol is intended for use by mobile routers in wireless, multiho= p >>>>> 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-14 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-14 >>>>> >>>>> >>>>> 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/ >>>>> >>>>> _______________________________________________ >>>>> 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 --94eb2c1231e6b18873052fe8b38d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Christopher,

On 7 Apr 2016 1:55 pm, "Christopher Dearlove" <= christopher.dearlove@gmai= l.com> wrote:
>
> [This time from a subscribed address.]
>
> You say you've added a sentence saying AODVv2 doesn't do RREQs= for gateways. What should have happened is a discussion on this list as to= why? is that hard? does anyone have a clever idea to make it not hard? doe= s anyone need that functionality? and so on.
>
> For example, here's something that superficially looks like it mig= ht work. Does it, or does it introduce new problems? I don't know. But = this, and likely better ideas, just haven't had discussion here - and I= fear that the people who might have the better ideas have departed unheard= .
>
> So, a router wants a route to a.b.c.d, and sends an RREQ for that (/32= , or simply omit). Of course any router directly serving that address just = replies. But a router that is serving a.0.0.0/8 could reply with that addre= ss. The originating router of course would use standard IP maximum prefix l= ength rules. Does that work? Does it help anyone? Could a router reply a.b.= c.d/32 and a.0.0.0/8 in one RREP? Or could it be allowed to reply a.b.c.d/8= as a shorthand?

This is exactly what it does (based on the router client ent= ry corresponding to TargAddr, e.g if router client entry is a.0.0.0/8, then= the RREP contains a.b.c.d/8). Everyone receiving the RREP can then install= the route to a.0.0.0/8 and therefore avoid a separate RREQ for (as an exam= ple) a.b.c.e in future. Similarly an RREQ contains the prefix length associ= ated with the router client entry configured for OrigAddr, and routers proc= essing the RREQ learn the route to OrigAddrs prefix.

But you can't intentionally send a RREQ for a prefix bec= ause the RREQ is created when there's a packet to send, you know the de= stination address not the prefix associated with it, so TargAddr is a.b.c.d= /32. But even so, you do end up learning a route to a prefix, if TargAddr i= s part of a router client entry which is a prefix.

Kind regards,
Victoria.

> And why can't a router request a.b.0.0/16 - and pos= sibly get an a.0.0.0/8 reply?
>
> Answers to all of those is "I don't know".=C2=A0 But we = should have been having those discussions.
>
> --=C2=A0
> Christopher Dearlove
> christopher.dearlove= @gmail.com
>
>
>
> -- =C2=A0
> Christopher Dearlove
> christopher.dearlove= @gmail.com (iPhone)
> chris@mnemosyne.demon.c= o.uk (home)
> On 7 Apr 2016, at 15:49, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:
>
>> Hi Thomas,
>>
>>> Am 05.04.2016 um 20:07 schrieb ietf@thomasclausen.org:
>>>
>>> Lotte,
>>>
>>> Thank you for this update. An impressive amount of changes to = the document, according to RFCdiff, and as I can see from your mail that th= ere is much more to come,
>>
>>
>> Thanks! I=E2=80=99m glad you=E2=80=99re seeing the progress we=E2= =80=99ve made.=C2=A0
>>
>>> I hope that you forgive me for not jumping at a blow-by-blow r= eview until a version which the authors themselves consider stable, is prod= uced.
>>>
>>> On the point of =E2=80=9Cmuch more to come", there have b= een quite a few comments raised by WG participants other than Mr. Dean and = Chris =C2=A0(such as by myself, but not only) =E2=80=94 some of which inter= sect some of the below, and for which I do not believe that a satisfactory = resolution has been developed, presented to the WG, and confirmed.
>>
>>
>> I=E2=80=99m not quite sure which comments exactly you are referrin= g to? Your last comments that come to mind are the ones in these threads: >>
>> https://www.ietf.org/mail-archive/web/manet/current/msg18055.ht= ml
>> https://www.ietf.org/mail-archive/web/manet/current/msg18639.ht= ml
>>
>> You=E2=80=99ve announced to go through the former in your last res= ponse to the latter, but as far as I can see you haven=E2=80=99t gotten rou= nd to doing that and a lot of points you=E2=80=99ve brought up have sparked= ongoing discussions, so I=E2=80=99ve marked most of your comments as =E2= =80=9Cpending=E2=80=93 still in discussion=E2=80=9D in my mind.=C2=A0
>> Regarding the points you brought up that aren=E2=80=99t affected b= y this:
>>
>> * Metrics=E2=80=93 we=E2=80=99ve had discussions about this many m= oons ago with authors on both sides of the fence. Unfortunately I can=E2=80= =99t remember the counter arguments, and I=E2=80=99m still looking for reco= rds of this conversation=E2=80=A6 I=E2=80=99ll get back to you when I=E2=80= =99ve found out more.
>> *=C2=A0Prefixes & Gateways: I=E2=80=99ve added a sentence to c= larify that AODVv2 doesn=E2=80=99t do RREQs for gateways, I hop that helps?=
>>
>>>
>>> In which revision of the I-D do you plan on addressing those?<= br> >>>
>>
>> If the discussions reach a conclusion by then, I=E2=80=99d be glad= to have them addressed by the next revision.
>>
>> Best regards,
>> Lotte
>>
>>> Best,
>>>
>>> Thomas
>>>
>>>
>>>
>>>> On Apr 5, 2016, at 12:53, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de>= wrote:
>>>>
>>>> Hi all,
>>>> just a quick summary of what is and what isn=E2=80=99t inc= luded in this update of the draft:
>>>>
>>>> DONE:
>>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94
>>>> * All JWD! comments (i.e. the critical ones) are resolved<= br> >>>> * Out of 90 JWD and JWD! comments, 61 are resolved
>>>> * The revised security considerations [1] were added (with= the TODOs commented out)
>>>> * The following TODO from [1] was resolved:=C2=A0
>>>> =C2=A0 =C2=A0"This description MUST
>>>> =C2=A0 =C2=A0include the reasons it was either unreasonabl= e or out of scope to
>>>> =C2=A0 =C2=A0attempt to avoid these denial of service atta= cks."
>>>> * Section 9 now contains a statement that AODVv2 doesn=E2= =80=99t support RREQs for prefixes, I hope that clears things up for Thomas= .
>>>>
>>>> TO DO:
>>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=C2=A0
>>>> * Most notable of the 29 JWDs that are yet to be resolved:=
>>>> +=C2=A0(is there some table that lists routes that are bei= ng waited on? JWD)=C2=A0We decided to add a separate=C2=A0
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RREP table that l= ists them and I=E2=80=99ve volunteered to write text for that, but we=E2=80= =99re currently discussing if/how
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we might solve th= is without adding yet another table.
>>>>
>>>> + We=E2=80=99re currently discussing the approaching the l= imit thing. (i.e.
>>>> =C2=A0 =C2=A0(There is no defined behavior here. Approachi= ng the limit? Section 6.5 outlines which messages are more important but no= w how to decide to allow them to be transmitted or not. JWD=C2=A0
>>>> =C2=A0=C2=A0and
>>>> =C2=A0=C2=A0(The undefined approaching the limit thing aga= in JWD) etc
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We=E2=80=99ve alr= eady clarified the wording regarding what the limit is and how to prioritiz= e the message types,=C2=A0
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0what=E2=80=99s le= ft is to define what =E2=80=9Eapproaching=E2=80=9C means (and whether we ne= ed to talk about approaching rather than
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0just saying =E2= =80=9Ehere=E2=80=99s what to do when you actually hit the limit").
>>>>
>>>> =C2=A0 =C2=A0 +=C2=A0(I don=E2=80=99t want to spam the lis= t with a comprehensive list of all of them, but if you=E2=80=99re intereste= d in seeing them,
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0please do say so = and I=E2=80=99ll send my copy of Justin=E2=80=99s review containing all TOD= Os and DONEs to the list)
>>>> * some TODOs in security considerations (see [1])
>>>> * since we're waiting for Chris=E2=80=99 feedback rega= rding the revised 5444 multiplexer wording, that hasn=E2=80=99t changed yet= .
>>>>
>>>> More details can be found in=C2=A0Appendix A.=C2=A0 AODVv2= Draft Updates,=C2=A0as well as the diff, of course.
>>>>
>>>> Best regards,
>>>> Lotte
>>>>
>>>> [1] Re: [manet] AODVv2: Security considerations update=C2= =A0https://www.ietf.org/mail-archive/web/manet/current/msg18458.html=
>>>>
>>>>
>>>>> Am 05.04.2016 um 12:19 schrieb=C2=A0internet-drafts@ietf.org:
>>>>>
>>>>>
>>>>> A New Internet-Draft is available from the on-line Int= ernet-Drafts directories.
>>>>> This draft is a work item of the Mobile Ad-hoc Network= s of the IETF.
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Title =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Ad Hoc On-demand Di= stance Vector Version 2 (AODVv2) Routing
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Authors =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Charles E. Perkins
>>>>> =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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Stan Ratliff
>>>>> =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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0John Dowdell
>>>>> =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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Lotte Steenbrink
>>>>> =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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Victoria Mercieca
>>>>> Filename =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: d= raft-ietf-manet-aodvv2-14.txt
>>>>> Pages =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0: 80
>>>>> Date =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0: 2016-04-05
>>>>>
>>>>> Abstract:
>>>>> =C2=A0=C2=A0The Ad Hoc On-demand Distance Vector Versi= on 2 (AODVv2) routing
>>>>> =C2=A0=C2=A0protocol is intended for use by mobile rou= ters in wireless, multihop
>>>>> =C2=A0=C2=A0networks.=C2=A0 AODVv2 determines unicast = routes among AODVv2 routers
>>>>> =C2=A0=C2=A0within 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-14
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-a= odvv2-14
>>>>>
>>>>>
>>>>> 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/
>>>>>
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> manet@ietf.org >>>>> https://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://ww= w.ietf.org/mailman/listinfo/manet
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ie= tf.org/mailman/listinfo/manet

--94eb2c1231e6b18873052fe8b38d-- From nobody Thu Apr 7 13:19: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 A4F8D12D0A8 for ; Thu, 7 Apr 2016 13:19:42 -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 jRfvliCFlxfa for ; Thu, 7 Apr 2016 13:19:37 -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 F313312D1AD for ; Thu, 7 Apr 2016 13:19:36 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id 191so103430476wmq.0 for ; Thu, 07 Apr 2016 13:19: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=/tYmdodrZeeo9jKwYdxO79iLmFLT7QVPcbvLIgCQmZk=; b=QVpHWYOd7ubpbj4hFoIpNHHx6ddlNXm37bS+U/IuxorPx5zt/guHFVcol319iKsHRG 6oTQ1whSGYVCVRJjXLf5VI+KxGtIhwVwTLOaXCizMm6+Qb9ALki8bP+8JeIiAf1C6DEH Eyj4Edj0UKWTPs7+zWWnKve3ZhBavh5DF60T+KZR1Av5GxP3vThsn5HxNlDGRoFhEeZu JOU9NOLDP7O8QzGW9bzqQG467qrWx90pGT01vs+KNnVB6H0+TwGt5ozROR0wJzD7oIaS 3veoMgizvUGP9vitlMEc0uA26Ywr2xo5vScAJot8cpcCWsEPn5Q8aeDBvsjrk4/dEFZm mp7Q== 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=/tYmdodrZeeo9jKwYdxO79iLmFLT7QVPcbvLIgCQmZk=; b=KktwotSC2Qk88roCH7BzXo0eQmxuHWeoyb7sqglAyK7t8nvRz6Y6iid5p+bPBazhsI Hn4QCoi+VnsiHGOX+8nwOu91cckuw/3LC0howcCl54xx2srNoC48cQP1CNQEaL/SsYqx ndTEIfr4B2Z6gUi5VVxTE8NDD+ENNfUu57GpeflmwhtcyY4YrmNq/XgjdKM+7PFIu1Jd FJR+Chx5r89bEU0B/A6Dr+U4qjqbkUjGm2S/BJGu1uX5Mj7C44YDsZ2QUjwINCnfXtCW ZOxMtTf5TmMVo/C4Nz8xLhkPlm3ffNfwrPGV+lrAQAYLWnbaGHpY3qg2qWidBAN2CpPF GhAA== X-Gm-Message-State: AD7BkJK/BW1VB64fmCr932dlUggR5SJQN7YDPNqSeA0v1SbMfbUmE3JVxjUbKzVz20DGjQ== X-Received: by 10.28.218.145 with SMTP id r139mr33451668wmg.52.1460060375512; Thu, 07 Apr 2016 13:19:35 -0700 (PDT) Received: from [10.6.81.255] (82-132-217-162.dab.02.net. [82.132.217.162]) by smtp.gmail.com with ESMTPSA id d1sm30725457wmh.18.2016.04.07.13.19.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 13:19:34 -0700 (PDT) References: <20160405101903.773.31003.idtracker@ietfa.amsl.com> <8438BA85-DFC2-4192-84EE-999572C35FD1@fu-berlin.de> <04D7135E-8EDF-49DC-8978-3A1132FF3915@thomasclausen.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-59966D63-D740-4D06-956C-046964920B2C Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (13E238) From: Christopher Dearlove Date: Thu, 7 Apr 2016 21:19:30 +0100 To: Victoria Mercieca Archived-At: Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-14.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, 07 Apr 2016 20:19:42 -0000 --Apple-Mail-59966D63-D740-4D06-956C-046964920B2C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks, that addresses most of the points I made. Assuming that is that a packet reception for forwarding is the only option y= ou choose to allow. It's perfectly reasonable for an implementation to think= "wouldn't it be sensible to learn about a gateway now for various reasons?"= . Yes, there's the problem of which subnet to look for (0.0.0.0/0 or someth= ing smaller). Yes, I can imagine you don't want to define this now - unless o= f course someone in the WG says they really want it. But I would say, don't c= lose the door on it, even if not doing it now. (There are other possibilities that might be useful one day. An RREQ that lo= oks for more than one address for example - you could trade latency and over= head by combining RREQs.) -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 7 Apr 2016, at 18:49, Victoria Mercieca wrote: >=20 > Hi Christopher, >=20 > On 7 Apr 2016 1:55 pm, "Christopher Dearlove" wrote: > > > > [This time from a subscribed address.] > > > > You say you've added a sentence saying AODVv2 doesn't do RREQs for gatew= ays. What should have happened is a discussion on this list as to why? is th= at hard? does anyone have a clever idea to make it not hard? does anyone nee= d that functionality? and so on. > > > > For example, here's something that superficially looks like it might wor= k. Does it, or does it introduce new problems? I don't know. But this, and l= ikely better ideas, just haven't had discussion here - and I fear that the p= eople who might have the better ideas have departed unheard. > > > > So, a router wants a route to a.b.c.d, and sends an RREQ for that (/32, o= r simply omit). Of course any router directly serving that address just repl= ies. But a router that is serving a.0.0.0/8 could reply with that address. T= he originating router of course would use standard IP maximum prefix length r= ules. Does that work? Does it help anyone? Could a router reply a.b.c.d/32 a= nd a.0.0.0/8 in one RREP? Or could it be allowed to reply a.b.c.d/8 as a sho= rthand? >=20 > This is exactly what it does (based on the router client entry correspondi= ng to TargAddr, e.g if router client entry is a.0.0.0/8, then the RREP conta= ins a.b.c.d/8). Everyone receiving the RREP can then install the route to a.= 0.0.0/8 and therefore avoid a separate RREQ for (as an example) a.b.c.e in f= uture. Similarly an RREQ contains the prefix length associated with the rout= er client entry configured for OrigAddr, and routers processing the RREQ lea= rn the route to OrigAddrs prefix. >=20 > But you can't intentionally send a RREQ for a prefix because the RREQ is c= reated when there's a packet to send, you know the destination address not t= he prefix associated with it, so TargAddr is a.b.c.d/32. But even so, you do= end up learning a route to a prefix, if TargAddr is part of a router client= entry which is a prefix. >=20 > Kind regards, > Victoria. >=20 > > And why can't a router request a.b.0.0/16 - and possibly get an a.0.0.0/= 8 reply? > > > > Answers to all of those is "I don't know". But we should have been havi= ng those discussions. > > > > --=20 > > Christopher Dearlove > > christopher.dearlove@gmail.com > > > > > > > > -- =20 > > Christopher Dearlove > > christopher.dearlove@gmail.com (iPhone) > > chris@mnemosyne.demon.co.uk (home) > > On 7 Apr 2016, at 15:49, Lotte Steenbrink wrote: > > > >> Hi Thomas, > >> > >>> Am 05.04.2016 um 20:07 schrieb ietf@thomasclausen.org: > >>> > >>> Lotte, > >>> > >>> Thank you for this update. An impressive amount of changes to the docu= ment, according to RFCdiff, and as I can see from your mail that there is mu= ch more to come, > >> > >> > >> Thanks! I=E2=80=99m glad you=E2=80=99re seeing the progress we=E2=80=99= ve made.=20 > >> > >>> I hope that you forgive me for not jumping at a blow-by-blow review un= til a version which the authors themselves consider stable, is produced. > >>> > >>> On the point of =E2=80=9Cmuch more to come", there have been quite a f= ew comments raised by WG participants other than Mr. Dean and Chris (such a= s by myself, but not only) =E2=80=94 some of which intersect some of the bel= ow, and for which I do not believe that a satisfactory resolution has been d= eveloped, presented to the WG, and confirmed. > >> > >> > >> I=E2=80=99m not quite sure which comments exactly you are referring to?= Your last comments that come to mind are the ones in these threads: > >> > >> https://www.ietf.org/mail-archive/web/manet/current/msg18055.html > >> https://www.ietf.org/mail-archive/web/manet/current/msg18639.html > >> > >> You=E2=80=99ve announced to go through the former in your last response= to the latter, but as far as I can see you haven=E2=80=99t gotten round to d= oing that and a lot of points you=E2=80=99ve brought up have sparked ongoing= discussions, so I=E2=80=99ve marked most of your comments as =E2=80=9Cpendi= ng=E2=80=93 still in discussion=E2=80=9D in my mind.=20 > >> Regarding the points you brought up that aren=E2=80=99t affected by thi= s: > >> > >> * Metrics=E2=80=93 we=E2=80=99ve had discussions about this many moons a= go with authors on both sides of the fence. Unfortunately I can=E2=80=99t re= member the counter arguments, and I=E2=80=99m still looking for records of t= his conversation=E2=80=A6 I=E2=80=99ll get back to you when I=E2=80=99ve fou= nd out more. > >> * Prefixes & Gateways: I=E2=80=99ve added a sentence to clarify that AO= DVv2 doesn=E2=80=99t do RREQs for gateways, I hop that helps? > >> > >>> > >>> In which revision of the I-D do you plan on addressing those? > >>> > >> > >> If the discussions reach a conclusion by then, I=E2=80=99d be glad to h= ave them addressed by the next revision. > >> > >> Best regards, > >> Lotte > >> > >>> Best, > >>> > >>> Thomas > >>> > >>> > >>> > >>>> On Apr 5, 2016, at 12:53, Lotte Steenbrink wrote: > >>>> > >>>> Hi all, > >>>> just a quick summary of what is and what isn=E2=80=99t included in th= is update of the draft: > >>>> > >>>> DONE: > >>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94 > >>>> * All JWD! comments (i.e. the critical ones) are resolved > >>>> * Out of 90 JWD and JWD! comments, 61 are resolved > >>>> * The revised security considerations [1] were added (with the TODOs c= ommented out) > >>>> * The following TODO from [1] was resolved:=20 > >>>> "This description MUST > >>>> include the reasons it was either unreasonable or out of scope to > >>>> attempt to avoid these denial of service attacks." > >>>> * Section 9 now contains a statement that AODVv2 doesn=E2=80=99t supp= ort RREQs for prefixes, I hope that clears things up for Thomas. > >>>> > >>>> TO DO: > >>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=20 > >>>> * Most notable of the 29 JWDs that are yet to be resolved: > >>>> + (is there some table that lists routes that are being waited on? JW= D) We decided to add a separate=20 > >>>> RREP table that lists them and I=E2=80=99ve volunteered to= write text for that, but we=E2=80=99re currently discussing if/how > >>>> we might solve this without adding yet another table. > >>>> > >>>> + We=E2=80=99re currently discussing the approaching the limit thing.= (i.e. > >>>> (There is no defined behavior here. Approaching the limit? Section= 6.5 outlines which messages are more important but now how to decide to all= ow them to be transmitted or not. JWD=20 > >>>> and > >>>> (The undefined approaching the limit thing again JWD) etc > >>>> We=E2=80=99ve already clarified the wording regarding what= the limit is and how to prioritize the message types,=20 > >>>> what=E2=80=99s left is to define what =E2=80=9Eapproaching= =E2=80=9C means (and whether we need to talk about approaching rather than > >>>> just saying =E2=80=9Ehere=E2=80=99s what to do when you ac= tually hit the limit"). > >>>> > >>>> + (I don=E2=80=99t want to spam the list with a comprehensive lis= t of all of them, but if you=E2=80=99re interested in seeing them, > >>>> please do say so and I=E2=80=99ll send my copy of Justin=E2= =80=99s review containing all TODOs and DONEs to the list) > >>>> * some TODOs in security considerations (see [1]) > >>>> * since we're waiting for Chris=E2=80=99 feedback regarding the revis= ed 5444 multiplexer wording, that hasn=E2=80=99t changed yet. > >>>> > >>>> More details can be found in Appendix A. AODVv2 Draft Updates, as we= ll as the diff, of course. > >>>> > >>>> Best regards, > >>>> Lotte > >>>> > >>>> [1] Re: [manet] AODVv2: Security considerations update https://www.ie= tf.org/mail-archive/web/manet/current/msg18458.html > >>>> > >>>> > >>>>> Am 05.04.2016 um 12:19 schrieb internet-drafts@ietf.org: > >>>>> > >>>>> > >>>>> A New Internet-Draft is available from the on-line Internet-Drafts d= irectories. > >>>>> 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-14.txt > >>>>> Pages : 80 > >>>>> Date : 2016-04-05 > >>>>> > >>>>> Abstract: > >>>>> The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing > >>>>> protocol is intended for use by mobile routers in wireless, multih= op > >>>>> 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-14 > >>>>> > >>>>> A diff from the previous version is available at: > >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-14 > >>>>> > >>>>> > >>>>> Please note that it may take a couple of minutes from the time of su= bmission > >>>>> 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 > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 --Apple-Mail-59966D63-D740-4D06-956C-046964920B2C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks, that addresses most of the poi= nts I made.

Assuming that is that a packet reception for forwarding is the o= nly option you choose to allow. It's perfectly reasonable for an implementat= ion to think "wouldn't it be sensible to learn about a gateway now for vario= us reasons?".  Yes, there's the problem of which subnet to look for (0.= 0.0.0/0 or something smaller). Yes, I can imagine you don't want to define t= his now - unless of course someone in the WG says they really want it. But I= would say, don't close the door on it, even if not doing it now.

(There are= other possibilities that might be useful one day. An RREQ that looks for mo= re than one address for example - you could trade latency and overhead by co= mbining RREQs.)

--  
Christopher Dearlove

On 7 Apr 2016, at 18:49, Vic= toria Mercieca <vmercieca0@gmail.= com> wrote:

Hi Christopher,

On 7 Apr 2016 1:55 pm, "Christopher Dearlove" <christopher.dearlove@gmail.com>= ; wrote:
>
> [This time from a subscribed address.]
>
> You say you've added a sentence saying AODVv2 doesn't do RREQs for gate= ways. What should have happened is a discussion on this list as to why? is t= hat hard? does anyone have a clever idea to make it not hard? does anyone ne= ed that functionality? and so on.
>
> For example, here's something that superficially looks like it might wo= rk. Does it, or does it introduce new problems? I don't know. But this, and l= ikely better ideas, just haven't had discussion here - and I fear that the p= eople who might have the better ideas have departed unheard.
>
> So, a router wants a route to a.b.c.d, and sends an RREQ for that (/32,= or simply omit). Of course any router directly serving that address just re= plies. But a router that is serving a.0.0.0/8 could reply with that address.= The originating router of course would use standard IP maximum prefix lengt= h rules. Does that work? Does it help anyone? Could a router reply a.b.c.d/3= 2 and a.0.0.0/8 in one RREP? Or could it be allowed to reply a.b.c.d/8 as a s= horthand?

This is exactly what it does (based on the router client entr= y corresponding to TargAddr, e.g if router client entry is a.0.0.0/8, then t= he RREP contains a.b.c.d/8). Everyone receiving the RREP can then install th= e route to a.0.0.0/8 and therefore avoid a separate RREQ for (as an example)= a.b.c.e in future. Similarly an RREQ contains the prefix length associated w= ith the router client entry configured for OrigAddr, and routers processing t= he RREQ learn the route to OrigAddrs prefix.

But you can't intentionally send a RREQ for a prefix because t= he RREQ is created when there's a packet to send, you know the destination a= ddress not the prefix associated with it, so TargAddr is a.b.c.d/32. But eve= n so, you do end up learning a route to a prefix, if TargAddr is part of a r= outer client entry which is a prefix.

Kind regards,
Victoria.

> And why can't a router request a.b.0.0/16 - and possibly= get an a.0.0.0/8 reply?
>
> Answers to all of those is "I don't know".  But we should have bee= n having those discussions.
>
> -- 
> Christopher Dearlove
> christopher.dearlove@= gmail.com
>
>
>
> --  
> Christopher Dearlove
> christopher.dearlove@= gmail.com (iPhone)
> chris@mnemosyne.demon.co= .uk (home)
> On 7 Apr 2016, at 15:49, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:
>
>> Hi Thomas,
>>
>>> Am 05.04.2016 um 20:07 schrieb ietf@thomasclausen.org:
>>>
>>> Lotte,
>>>
>>> Thank you for this update. An impressive amount of changes to t= he document, according to RFCdiff, and as I can see from your mail that ther= e is much more to come,
>>
>>
>> Thanks! I=E2=80=99m glad you=E2=80=99re seeing the progress we=E2=80= =99ve made. 
>>
>>> I hope that you forgive me for not jumping at a blow-by-blow re= view until a version which the authors themselves consider stable, is produc= ed.
>>>
>>> On the point of =E2=80=9Cmuch more to come", there have been qu= ite a few comments raised by WG participants other than Mr. Dean and Chris &= nbsp;(such as by myself, but not only) =E2=80=94 some of which intersect som= e of the below, and for which I do not believe that a satisfactory resolutio= n has been developed, presented to the WG, and confirmed.
>>
>>
>> I=E2=80=99m not quite sure which comments exactly you are referring= to? Your last comments that come to mind are the ones in these threads:
= >>
>> https://www.ietf.org/mail-archive/web/manet/current/msg18055.html=
>> https://www.ietf.org/mail-archive/web/manet/current/msg18639.html=
>>
>> You=E2=80=99ve announced to go through the former in your last resp= onse to the latter, but as far as I can see you haven=E2=80=99t gotten round= to doing that and a lot of points you=E2=80=99ve brought up have sparked on= going discussions, so I=E2=80=99ve marked most of your comments as =E2=80=9C= pending=E2=80=93 still in discussion=E2=80=9D in my mind. 
>> Regarding the points you brought up that aren=E2=80=99t affected by= this:
>>
>> * Metrics=E2=80=93 we=E2=80=99ve had discussions about this many mo= ons ago with authors on both sides of the fence. Unfortunately I can=E2=80=99= t remember the counter arguments, and I=E2=80=99m still looking for records o= f this conversation=E2=80=A6 I=E2=80=99ll get back to you when I=E2=80=99ve f= ound out more.
>> * Prefixes & Gateways: I=E2=80=99ve added a sentence to cl= arify that AODVv2 doesn=E2=80=99t do RREQs for gateways, I hop that helps? >>
>>>
>>> In which revision of the I-D do you plan on addressing those? >>>
>>
>> If the discussions reach a conclusion by then, I=E2=80=99d be glad t= o have them addressed by the next revision.
>>
>> Best regards,
>> Lotte
>>
>>> Best,
>>>
>>> Thomas
>>>
>>>
>>>
>>>> On Apr 5, 2016, at 12:53, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> w= rote:
>>>>
>>>> Hi all,
>>>> just a quick summary of what is and what isn=E2=80=99t incl= uded in this update of the draft:
>>>>
>>>> DONE:
>>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94
>>>> * All JWD! comments (i.e. the critical ones) are resolved >>>> * Out of 90 JWD and JWD! comments, 61 are resolved
>>>> * The revised security considerations [1] were added (with t= he TODOs commented out)
>>>> * The following TODO from [1] was resolved: 
>>>>    "This description MUST
>>>>    include the reasons it was either unreasonable= or out of scope to
>>>>    attempt to avoid these denial of service attac= ks."
>>>> * Section 9 now contains a statement that AODVv2 doesn=E2=80= =99t support RREQs for prefixes, I hope that clears things up for Thomas. >>>>
>>>> TO DO:
>>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94 
>>>> * Most notable of the 29 JWDs that are yet to be resolved:<= br> >>>> + (is there some table that lists routes that are bein= g waited on? JWD) We decided to add a separate 
>>>>            RREP table that li= sts them and I=E2=80=99ve volunteered to write text for that, but we=E2=80=99= re currently discussing if/how
>>>>            we might solve thi= s without adding yet another table.
>>>>
>>>> + We=E2=80=99re currently discussing the approaching the li= mit thing. (i.e.
>>>>    (There is no defined behavior here. Approachin= g the limit? Section 6.5 outlines which messages are more important but now h= ow to decide to allow them to be transmitted or not. JWD 
>>>>   and
>>>>   (The undefined approaching the limit thing agai= n JWD) etc
>>>>            We=E2=80=99ve alre= ady clarified the wording regarding what the limit is and how to prioritize t= he message types, 
>>>>            what=E2=80=99s lef= t is to define what =E2=80=9Eapproaching=E2=80=9C means (and whether we need= to talk about approaching rather than
>>>>            just saying =E2=80= =9Ehere=E2=80=99s what to do when you actually hit the limit").
>>>>
>>>>     + (I don=E2=80=99t want to spam the list= with a comprehensive list of all of them, but if you=E2=80=99re interested i= n seeing them,
>>>>            please do say so a= nd I=E2=80=99ll send my copy of Justin=E2=80=99s review containing all TODOs= and DONEs to the list)
>>>> * some TODOs in security considerations (see [1])
>>>> * since we're waiting for Chris=E2=80=99 feedback regarding= the revised 5444 multiplexer wording, that hasn=E2=80=99t changed yet.
>>>>
>>>> More details can be found in Appendix A.  AODVv2 D= raft Updates, as well as the diff, of course.
>>>>
>>>> Best regards,
>>>> Lotte
>>>>
>>>> [1] Re: [manet] AODVv2: Security considerations update = ;https://www.ietf.org/mail-archive/web/manet/current/msg18458.html
= >>>>
>>>>
>>>>> Am 05.04.2016 um 12:19 schrieb internet-drafts@ietf.org:
>>>>>
>>>>>
>>>>> A New Internet-Draft is available from the on-line Inte= rnet-Drafts directories.
>>>>> This draft is a work item of the Mobile Ad-hoc Networks= of the IETF.
>>>>>
>>>>>        Title  &= nbsp;        : Ad Hoc On-demand Dist= ance Vector Version 2 (AODVv2) Routing
>>>>>        Authors  = ;       : Charles E. Perkins
>>>>>          &= nbsp;            = ;   Stan Ratliff
>>>>>          &= nbsp;            = ;   John Dowdell
>>>>>          &= nbsp;            = ;   Lotte Steenbrink
>>>>>          &= nbsp;            = ;   Victoria Mercieca
>>>>> Filename        : dr= aft-ietf-manet-aodvv2-14.txt
>>>>> Pages         &= nbsp; : 80
>>>>> Date         &n= bsp;  : 2016-04-05
>>>>>
>>>>> Abstract:
>>>>>   The Ad Hoc On-demand Distance Vector Versio= n 2 (AODVv2) routing
>>>>>   protocol is intended for use by mobile rout= ers in wireless, multihop
>>>>>   networks.  AODVv2 determines unicast r= outes 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-14
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aod= vv2-14
>>>>>
>>>>>
>>>>> Please note that it may take a couple of minutes from t= he 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://f= tp.ietf.org/internet-drafts/
>>>>>
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> manet@ietf.org >>>>>= https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> htt= ps://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.iet= f.org/mailman/listinfo/manet

= --Apple-Mail-59966D63-D740-4D06-956C-046964920B2C-- From nobody Thu Apr 7 14:15:05 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 4109512D6EC; Thu, 7 Apr 2016 14:15:02 -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: <20160407211502.10137.38569.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 14:15:02 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-22.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: Thu, 07 Apr 2016 21:15:02 -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 : Dynamic Link Exchange Protocol (DLEP) Authors : Stan Ratliff Bo Berry Shawn Jury Darryl Satterwhite Rick Taylor Filename : draft-ietf-manet-dlep-22.txt Pages : 67 Date : 2016-04-07 Abstract: When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-22 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 Thu Apr 7 14:18: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 E955E12D665 for ; Thu, 7 Apr 2016 14:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 T0iF3MqDbLDX for ; Thu, 7 Apr 2016 14:18:39 -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 25A2E12D622 for ; Thu, 7 Apr 2016 14:18:39 -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; Thu, 7 Apr 2016 22:18:15 +0100 From: Rick Taylor To: "manet@ietf.org" Thread-Topic: draft-ietf-manet-dlep-22 submitted Thread-Index: AQHRkRL+F04MDIxdbUK+r54MalYdSw== Date: Thu, 7 Apr 2016 21:18:13 +0000 Message-ID: <1460063893.2056.30.camel@tropicalstormsoftware.com> 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: Subject: [manet] draft-ietf-manet-dlep-22 submitted 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, 07 Apr 2016 21:18:41 -0000 QWxsLA0KDQpXZSBoYXZlIGp1c3Qgc3VibWl0dGVkIERMRVAtMjIuICANCg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLw0KDQpUaGlzIGlzIGFu IHVwZGF0ZSB0byBmaXggbml0cyBhbmQgdHlwb3MuDQoNClRoYW5rcywNCg0KUmljayBUYXlsb3I= From nobody Thu Apr 7 14:50: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 1BEE312D6EA for ; Thu, 7 Apr 2016 14:50:19 -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 9bbFmJ5ieHxj for ; Thu, 7 Apr 2016 14:50:13 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 81B8B12D6FA for ; Thu, 7 Apr 2016 14:50:12 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id 191so105310900wmq.0 for ; Thu, 07 Apr 2016 14:50:12 -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=Asy1rsGhciD3oDgrcTtgNM5Mt/5bvF6S7fBcsP8brSk=; b=tRZr37P14HBljf4OnYCo696xz6/CO+CDAF4XAVSWNCCUqRkgR0gWq6iW4NJFBbVMyo 5RSoy/i/w9WeVoOl0akCq3U0rH7KO64e2Rpb1ArQ9eadEvknMcBHiGqt4AwCUrJGADMY 4maC9Ayd3Um+SOW/fOSnDm467tAxF99DOwXjcAPHnJRj0ASrXtygCMypZfvAUKEJT1cy 45Y2OYSCzUtM/gsRT8k7pOlpj61INRu++ZozqbZ7U7Gs/0+uy+mn9YE7HmUz1INuhl1P T2JjBhTjnxLuPTozQxk8qNMi8Ej+K1e31EwjWj9Ii0sxBEQ9jQrgjAD5S7H9789b01Bv FgUw== 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=Asy1rsGhciD3oDgrcTtgNM5Mt/5bvF6S7fBcsP8brSk=; b=aziHBir8+hGNm7naDhagYLKcmtsZE102e1PbTewElmjxlOgCux+JB1JOpe87KMxnuM PcZe+WaULp637xRe3o4p82GKSaT5+aXC3jKdCk6UU4Ad4odoHF7yei+CjNG90+lBRpPs 2DMwNTBjR2OVQ0Yl+tWIhEm0XPfmtMp7iMgLPBATzGTJVQuQnNmTX5Yd4SgyVDX4y/WU +C+NNfFKj0dohrJu0u60yapls6ZXz2iAN96E0TNhuLwMhlWlzZBWvQosBmDhShvAbQW9 f6lFZ0IZWr8B3W71wqWviunvcFDluNox45c9OV49wy2W9dXVHWDmggSVxQ5FiC1Zrr3B Sv2A== X-Gm-Message-State: AD7BkJL3BzCkowO8Vj/E4krbd5tFtu9DKyUC6MDZERkrVQZ9+8a/x2zbG7ykkZnHEEAGvw== X-Received: by 10.28.136.211 with SMTP id k202mr33848594wmd.93.1460065811025; Thu, 07 Apr 2016 14:50:11 -0700 (PDT) Received: from johns-mbp-4.home (host81-156-153-96.range81-156.btcentralplus.com. [81.156.153.96]) by smtp.gmail.com with ESMTPSA id s10sm7491306wjp.3.2016.04.07.14.50.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 14:50:10 -0700 (PDT) From: John Dowdell Content-Type: multipart/alternative; boundary="Apple-Mail=_FBD59C87-D92D-44E4-9CF6-6BFB5DEB9C33" Message-Id: <19F3ADDE-C054-47FB-B23D-8CCAD574C557@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Thu, 7 Apr 2016 22:50:07 +0100 References: To: Justin Dean , "manet@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 07 Apr 2016 21:50:19 -0000 --Apple-Mail=_FBD59C87-D92D-44E4-9CF6-6BFB5DEB9C33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Justin Just to be clear, when did the last call period start and when does it = finish? Regards John > On 6 Apr 2016, at 18:14, Justin Dean wrote: >=20 > The chairs agree that a 3 week WGLC is appropriate. Everyone please = read the draft early and get comments in early so that they can be = addressed within the last call period. >=20 > Justin >=20 > On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) = > = wrote: > Obviously +1 to the request for WGLC. >=20 > With regard to what's changed, technically the only significant thing = is to make it clear that if a protocol delivers a message to the = multiplexer, the multiplexer must pass it on unchanged to the protocol = (another instance of, at another router) unchanged. Without that nothing = that the protocol itself chooses to do with regard to security makes = sense. Though the protocol can alternatively let the multiplexer do the = security, 7182 can be implemented in either way. This isn't really new, = but it wasn't formally spelled out. It's presented as part of spelling = out multiplexer rules more carefully. >=20 > But what about message optimisation? That's a function of constructing = a 5444 message, not the multiplexer, and is down to that 5444 includes = two things - packet/message structure (and implicitly, and in pretty = much any implementation I would expect to see, a parser and builder for = that structure) and the multiplexer. So we took the opportunity to = separate out more clearly a discussion of the two, which we think will = be helpful. >=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 > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org = ] On Behalf Of Ulrich Herberg > Sent: 05 April 2016 20:08 > To: manet@ietf.org > Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 >=20 > ----------------------! WARNING ! ---------------------- This message = originates from outside our organisation, either from an external = partner or from the internet. > Consider carefully whether you should click on any links, open any = attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for = instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > *** WARNING *** > EXTERNAL EMAIL -- This message originates from outside our = organization. >=20 >=20 > Hi, >=20 > As you have seen, we have submitted a new revision of 5444-usage. The = authors feel comfortable that we have addressed all issues by this = version, and would like to ask the WG chairs to issue a WGLC on this = document. While it is a fairly short document, given that it is IETF = week for some, we'd suggest that a 3-4 week WGLC would be appropriate. >=20 > Best regards > Ulrich >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet = >=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 = >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_FBD59C87-D92D-44E4-9CF6-6BFB5DEB9C33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Justin

Just to be clear, when did the last = call period start and when does it finish?

Regards
John


On = 6 Apr 2016, at 18:14, Justin Dean <bebemaster@gmail.com> wrote:

The chairs agree that a 3 week WGLC is appropriate.  = Everyone please read the draft early and get comments in early so that = they can be addressed within the last call period.

Justin

On Wed, = Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> = wrote:
Obviously +1 to = the request for WGLC.

With regard to what's changed, technically the only significant thing is = to make it clear that if a protocol delivers a message to the = multiplexer, the multiplexer must pass it on unchanged to the protocol = (another instance of, at another router) unchanged. Without that nothing = that the protocol itself chooses to do with regard to security makes = sense. Though the protocol can alternatively let the multiplexer do the = security, 7182 can be implemented in either way. This isn't really new, = but it wasn't formally spelled out. It's presented as part of spelling = out multiplexer rules more carefully.

But what about message optimisation? That's a function of constructing a = 5444 message, not the multiplexer, and is down to that 5444 includes two = things - packet/message structure (and implicitly, and in pretty much = any implementation I would expect to see, a parser and builder for that = structure) and the multiplexer. So we took the opportunity to separate = out more clearly a discussion of the two, which we think will be = helpful.

--
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

-----Original Message-----
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg
Sent: 05 April 2016 20:08
To: manet@ietf.org
Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

----------------------! WARNING ! ---------------------- This message = originates from outside our organisation, either from an external = partner or from the internet.
Consider carefully whether you should click on any links, open any = attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for = instructions on reporting suspicious email messages.
--------------------------------------------------------

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


Hi,

As you have seen, we have submitted a new revision of 5444-usage. The = authors feel comfortable that we have addressed all issues by this = version, and would like to ask the WG chairs to issue a WGLC on this = document. While it is a fairly short document, given that it is IETF = week for some, we'd suggest that a 3-4 week WGLC would be = appropriate.

Best regards
Ulrich

_______________________________________________
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

= --Apple-Mail=_FBD59C87-D92D-44E4-9CF6-6BFB5DEB9C33-- From nobody Thu Apr 7 17:26: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 42C8712D109 for ; Thu, 7 Apr 2016 17:26:44 -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 DzkYrWt_QpgT for ; Thu, 7 Apr 2016 17:26:42 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 BF69C12D0B7 for ; Thu, 7 Apr 2016 17:26:41 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id c4so120210368vkb.3 for ; Thu, 07 Apr 2016 17:26:41 -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=4EFKbSqxur+CXygyx+iQxOf8XAsmRX4JjpdDvZ1VcFU=; b=DtgeEItyvgD3cEkyhiskQm5z6f1i4tKBmpBTxVpJN8V5Nx+FriHjn8BMQmBjnN6pBi qRWFKKlP/pPoQ0HqgUMB7q4s0FJN257NBCPYSJ1fS3tc6T6qImVKsLhjwxTVRVvD7VIW woMcA0HvdZt0+8Zr46QEJEWjVt17ImzHBmhkbEEcNCEZ5bGfBmDKMjI4LpS36xB8n2DZ 3wrMeGiPR8mZfTi8N4Cl1zDuhxg9K8NCtU9JEHbtdEDaAADmwNt1JbONr3TBVY6P1eHR B02LiP0/XZIpkKX4tJD2/HpzZAXfKbfTM2ps0wdNk78LvSkEEx+xZ7YIqneNzT0Sq9ca ZF0g== 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=4EFKbSqxur+CXygyx+iQxOf8XAsmRX4JjpdDvZ1VcFU=; b=BWpof7yswIEXpR8m5MBW/Nw5ydFDIsIpRiPwnAbGXZeEIWmT4EkacnV5hQ8TUeCqh8 1bvSoSckScTJa9gixk7K2Rxp8NnmxdJFGiBocdeWYFD2KgmuH/7V+J/Jk8PxnJ/aZc5b hJXma4N5+ObnCvqYTU6kcImMNeOq7OXXRBDH7InUTe2TN8Xuo7UeFZHU1OS4jmKnZqSs QfzfVs/tNIp7ueXE5JFEJ/QHS+iXptB2PmLiiqugueeUgnxy/VhbcfUexPc7wtjd5MLa dKqtiFKkHOteEk8L8AcGtNa1rsFwfwI6p20/JE/MtdexXMyASHPGr5W2eMSzQUQ7hpnQ N82w== X-Gm-Message-State: AD7BkJI0dYsbnMHqJXEObxfu54IzALth2seSMad86OyR0FaakUa5kzJW0t54uem8fE2rRnRO1u0mejoNIoW0ig== MIME-Version: 1.0 X-Received: by 10.31.33.137 with SMTP id h131mr2876108vkh.24.1460075200684; Thu, 07 Apr 2016 17:26:40 -0700 (PDT) Received: by 10.31.62.67 with HTTP; Thu, 7 Apr 2016 17:26:40 -0700 (PDT) In-Reply-To: <19F3ADDE-C054-47FB-B23D-8CCAD574C557@gmail.com> References: <19F3ADDE-C054-47FB-B23D-8CCAD574C557@gmail.com> Date: Thu, 7 Apr 2016 20:26:40 -0400 Message-ID: From: Justin Dean To: John Dowdell Content-Type: multipart/alternative; boundary=001a113dc8baaead6a052fee3fdd Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 08 Apr 2016 00:26:44 -0000 --001a113dc8baaead6a052fee3fdd Content-Type: text/plain; charset=UTF-8 Last call started on the 6th of Apr and will finish on the 27th of Apr. Justin On Thu, Apr 7, 2016 at 5:50 PM, John Dowdell wrote: > Justin > > Just to be clear, when did the last call period start and when does it > finish? > > Regards > John > > > On 6 Apr 2016, at 18:14, Justin Dean wrote: > > The chairs agree that a 3 week WGLC is appropriate. Everyone please read > the draft early and get comments in early so that they can be addressed > within the last call period. > > Justin > > On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > >> Obviously +1 to the request for WGLC. >> >> With regard to what's changed, technically the only significant thing is >> to make it clear that if a protocol delivers a message to the multiplexer, >> the multiplexer must pass it on unchanged to the protocol (another instance >> of, at another router) unchanged. Without that nothing that the protocol >> itself chooses to do with regard to security makes sense. Though the >> protocol can alternatively let the multiplexer do the security, 7182 can be >> implemented in either way. This isn't really new, but it wasn't formally >> spelled out. It's presented as part of spelling out multiplexer rules more >> carefully. >> >> But what about message optimisation? That's a function of constructing a >> 5444 message, not the multiplexer, and is down to that 5444 includes two >> things - packet/message structure (and implicitly, and in pretty much any >> implementation I would expect to see, a parser and builder for that >> structure) and the multiplexer. So we took the opportunity to separate out >> more clearly a discussion of the two, which we think will be helpful. >> >> -- >> 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 >> >> -----Original Message----- >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg >> Sent: 05 April 2016 20:08 >> To: manet@ietf.org >> Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 >> >> ----------------------! WARNING ! ---------------------- This message >> originates from outside our organisation, either from an external partner >> or from the internet. >> Consider carefully whether you should click on any links, open any >> attachments or reply. >> Follow the 'Report Suspicious Emails' link on IT matters for instructions >> on reporting suspicious email messages. >> -------------------------------------------------------- >> >> *** WARNING *** >> EXTERNAL EMAIL -- This message originates from outside our organization. >> >> >> Hi, >> >> As you have seen, we have submitted a new revision of 5444-usage. The >> authors feel comfortable that we have addressed all issues by this version, >> and would like to ask the WG chairs to issue a WGLC on this document. While >> it is a fairly short document, given that it is IETF week for some, we'd >> suggest that a 3-4 week WGLC would be appropriate. >> >> Best regards >> Ulrich >> >> _______________________________________________ >> 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 > > > --001a113dc8baaead6a052fee3fdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Last call started on the 6th of Apr and will finish o= n the 27th of Apr.

Justin
=
On Thu, Apr 7, 2016 at 5:50 PM, John Dowdell= <john.dowdell.ietf@gmail.com> wrote:
Justin
=

Just to be clear, when did the last call period start a= nd when does it finish?

Regards
John


On 6 Ap= r 2016, at 18:14, Justin Dean <bebemaster@gmail.com> wrote:

The chairs agree that a 3 week WGLC is appropriate.=C2=A0 Everyone= please read the draft early and get comments in early so that they can be = addressed within the last call period.

Justin

On Wed, Apr 6, 2= 016 at 7:40 AM, Dearlove, Christopher (UK) <chris.dearlove@bae= systems.com> wrote:
Obvious= ly +1 to the request for WGLC.

With regard to what's changed, technically the only significant thing i= s to make it clear that if a protocol delivers a message to the multiplexer= , the multiplexer must pass it on unchanged to the protocol (another instan= ce of, at another router) unchanged. Without that nothing that the protocol= itself chooses to do with regard to security makes sense. Though the proto= col can alternatively let the multiplexer do the security, 7182 can be impl= emented in either way. This isn't really new, but it wasn't formall= y spelled out. It's presented as part of spelling out multiplexer rules= more carefully.

But what about message optimisation? That's a function of constructing = a 5444 message, not the multiplexer, and is down to that 5444 includes two = things - packet/message structure (and implicitly, and in pretty much any i= mplementation I would expect to see, a parser and builder for that structur= e) and the multiplexer. So we took the opportunity to separate out more cle= arly a discussion of the two, which we think will be helpful.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________<= br>
T: =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chris.dearlove@baesyst= ems.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 Ulrich Herberg
Sent: 05 April 2016 20:08
To: manet@ietf.org<= br> Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

----------------------! 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 instru= ctions on reporting suspicious email messages.
--------------------------------------------------------

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


Hi,

As you have seen, we have submitted a new revision of 5444-usage. The autho= rs feel comfortable that we have addressed all issues by this version, and = would like to ask the WG chairs to issue a WGLC on this document. While it = is a fairly short document, given that it is IETF week for some, we'd s= uggest that a 3-4 week WGLC would be appropriate.

Best regards
Ulrich

_______________________________________________
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
http= s://www.ietf.org/mailman/listinfo/manet

--001a113dc8baaead6a052fee3fdd-- From nobody Fri Apr 8 02:15: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 7EC7912D684 for ; Fri, 8 Apr 2016 02:15:18 -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 r4NN3w5d2qNF for ; Fri, 8 Apr 2016 02:15:15 -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 017AC12D572 for ; Fri, 8 Apr 2016 02:15:14 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,449,1454976000"; d="scan'208,217"; a="33205868" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 08 Apr 2016 10:15:12 +0100 X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208,217";a="113215395" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 08 Apr 2016 10:15:07 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Fri, 8 Apr 2016 10:15:04 +0100 From: "Dearlove, Christopher (UK)" To: Justin Dean , John Dowdell Thread-Topic: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 Thread-Index: AQHRj26efzFsMll+IU2A0f8aUpvZOp980SWwgABO2gCAAd9GgIAAK70AgACibgA= Date: Fri, 8 Apr 2016 09:15:03 +0000 Message-ID: References: <19F3ADDE-C054-47FB-B23D-8CCAD574C557@gmail.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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923A9EEBGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 08 Apr 2016 09:15:18 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923A9EEBGLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGF0IEp1c3Rpbi4NCg0KSGVyZeKAmXMgYSBjb252ZW5pZW50IHBsYWNlIHRv IG5vdGUgdGhhdCBGcmVkIEJha2VyIGFwcGVhcnMgdG8gYmUgcnVubmluZyBhIHNjcmlwdCB0aGF0 IGVtYWlscyBhbGwgZHJhZnQgYXV0aG9ycyBpZiB0aGUgZHJhZnQgZG9lc27igJl0IGluY2x1ZGUg SVB2NiBleGFtcGxlcy4gKEl04oCZcyBhIHNjcmlwdCB0aGF0IG5lZWRzIGltcHJvdmVtZW50LCBh cyB0aGUgZW1haWwgc3VnZ2VzdHMgdGhhdCB0aGUgYXV0aG9ycyBqdXN0IGhhdmVu4oCZdCBjb25z aWRlcmVkIElQdjYsIHdoaWNoIGlzIHJhdGhlciB1bmxpa2VseSB3aGVuIElQdjYgaXMgZXhwbGlj aXRseSBtZW50aW9uZWQuKQ0KDQpUaGlzIGRyYWZ0IGhhcyBhbiBJUHY0LCBidXQgbm90IGFuIElQ djYgZXhhbXBsZSwgdGhvdWdoIHRoZSBwYXJhZ3JhcGggaXTigJlzIGluIGFsc28gZGlzY3Vzc2Vz IElQdjYuIFBlcnNvbmFsbHkgSSBkb27igJl0IHRoaW5rIHRoYXQgYWRkaW5nIGFuIElQdjYgZXhh bXBsZSBoZWxwcyB3aXRoIHRoZSBwb2ludCB0aGF0IHdhcyBiZWluZyBtYWRlLCBidXQgd2UgcmVz cG9uZGVkIHRvIEZyZWQgc2F5aW5nIHdl4oCZZCBjb25zaWRlciBoaXMgY29tbWVudCAob3IgaGlz IHNjcmlwdOKAmXMgY29tbWVudCkgYXMgcGFydCBvZiBXR0xDIChoZW5jZSB0aGlzIHBvc3Rpbmcs IGFzIG90aGVyd2lzZSBpdCBpcyBvbmx5IGtub3duIHRvIHRoZSBhdXRob3JzLCBjaGFpcnMgZXRj LikgYW5kIHNlZSBpZiB0aGUgV0cgZmVsdCBhbiBJUHY2IGV4YW1wbGUgd2FzIG5lZWRlZC4NCg0K SSB3b3VsZCBzdWdnZXN0IHJlYWRpbmcgdGhlIGNvbnRleHQgb2YgdGhlIGV4YW1wbGUgYmVmb3Jl IHRha2luZyBhIHZpZXcuIFRoZSBhdXRob3JzIHdpbGwgb2YgY291cnNlIGZvbGxvdyBhbnkgcm91 Z2ggY29uc2Vuc3VzLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lw YWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmll cw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hy aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl bXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBU ZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4N Cnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFF IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmds YW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2Vh cmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IG1hbmV0IFttYWls dG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBEZWFuDQpTZW50 OiAwOCBBcHJpbCAyMDE2IDAxOjI3DQpUbzogSm9obiBEb3dkZWxsDQpDYzogbWFuZXRAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFdHTEMgcmVxdWVzdCBmb3IgZHJhZnQtaWV0Zi1tYW5l dC1yZmM1NDQ0LXVzYWdlLTAzDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3Jp Z2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0 ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhl ciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3Ig cmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4g bG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50 cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0Rv Y3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3Bp Y2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFl c3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxp bmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KKioqIFdBUk5JTkcgKioqDQpF WFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3Vy IG9yZ2FuaXphdGlvbi4NCg0KTGFzdCBjYWxsIHN0YXJ0ZWQgb24gdGhlIDZ0aCBvZiBBcHIgYW5k IHdpbGwgZmluaXNoIG9uIHRoZSAyN3RoIG9mIEFwci4NCkp1c3Rpbg0KDQpPbiBUaHUsIEFwciA3 LCAyMDE2IGF0IDU6NTAgUE0sIEpvaG4gRG93ZGVsbCA8am9obi5kb3dkZWxsLmlldGZAZ21haWwu Y29tPG1haWx0bzpqb2huLmRvd2RlbGwuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkp1c3Rpbg0K DQpKdXN0IHRvIGJlIGNsZWFyLCB3aGVuIGRpZCB0aGUgbGFzdCBjYWxsIHBlcmlvZCBzdGFydCBh bmQgd2hlbiBkb2VzIGl0IGZpbmlzaD8NCg0KUmVnYXJkcw0KSm9obg0KDQoNCk9uIDYgQXByIDIw MTYsIGF0IDE4OjE0LCBKdXN0aW4gRGVhbiA8YmViZW1hc3RlckBnbWFpbC5jb208bWFpbHRvOmJl YmVtYXN0ZXJAZ21haWwuY29tPj4gd3JvdGU6DQoNClRoZSBjaGFpcnMgYWdyZWUgdGhhdCBhIDMg d2VlayBXR0xDIGlzIGFwcHJvcHJpYXRlLiAgRXZlcnlvbmUgcGxlYXNlIHJlYWQgdGhlIGRyYWZ0 IGVhcmx5IGFuZCBnZXQgY29tbWVudHMgaW4gZWFybHkgc28gdGhhdCB0aGV5IGNhbiBiZSBhZGRy ZXNzZWQgd2l0aGluIHRoZSBsYXN0IGNhbGwgcGVyaW9kLg0KDQpKdXN0aW4NCg0KT24gV2VkLCBB cHIgNiwgMjAxNiBhdCA3OjQwIEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMu ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu Y29tPj4gd3JvdGU6DQpPYnZpb3VzbHkgKzEgdG8gdGhlIHJlcXVlc3QgZm9yIFdHTEMuDQoNCldp dGggcmVnYXJkIHRvIHdoYXQncyBjaGFuZ2VkLCB0ZWNobmljYWxseSB0aGUgb25seSBzaWduaWZp Y2FudCB0aGluZyBpcyB0byBtYWtlIGl0IGNsZWFyIHRoYXQgaWYgYSBwcm90b2NvbCBkZWxpdmVy cyBhIG1lc3NhZ2UgdG8gdGhlIG11bHRpcGxleGVyLCB0aGUgbXVsdGlwbGV4ZXIgbXVzdCBwYXNz IGl0IG9uIHVuY2hhbmdlZCB0byB0aGUgcHJvdG9jb2wgKGFub3RoZXIgaW5zdGFuY2Ugb2YsIGF0 IGFub3RoZXIgcm91dGVyKSB1bmNoYW5nZWQuIFdpdGhvdXQgdGhhdCBub3RoaW5nIHRoYXQgdGhl IHByb3RvY29sIGl0c2VsZiBjaG9vc2VzIHRvIGRvIHdpdGggcmVnYXJkIHRvIHNlY3VyaXR5IG1h a2VzIHNlbnNlLiBUaG91Z2ggdGhlIHByb3RvY29sIGNhbiBhbHRlcm5hdGl2ZWx5IGxldCB0aGUg bXVsdGlwbGV4ZXIgZG8gdGhlIHNlY3VyaXR5LCA3MTgyIGNhbiBiZSBpbXBsZW1lbnRlZCBpbiBl aXRoZXIgd2F5LiBUaGlzIGlzbid0IHJlYWxseSBuZXcsIGJ1dCBpdCB3YXNuJ3QgZm9ybWFsbHkg c3BlbGxlZCBvdXQuIEl0J3MgcHJlc2VudGVkIGFzIHBhcnQgb2Ygc3BlbGxpbmcgb3V0IG11bHRp cGxleGVyIHJ1bGVzIG1vcmUgY2FyZWZ1bGx5Lg0KDQpCdXQgd2hhdCBhYm91dCBtZXNzYWdlIG9w dGltaXNhdGlvbj8gVGhhdCdzIGEgZnVuY3Rpb24gb2YgY29uc3RydWN0aW5nIGEgNTQ0NCBtZXNz YWdlLCBub3QgdGhlIG11bHRpcGxleGVyLCBhbmQgaXMgZG93biB0byB0aGF0IDU0NDQgaW5jbHVk ZXMgdHdvIHRoaW5ncyAtIHBhY2tldC9tZXNzYWdlIHN0cnVjdHVyZSAoYW5kIGltcGxpY2l0bHks IGFuZCBpbiBwcmV0dHkgbXVjaCBhbnkgaW1wbGVtZW50YXRpb24gSSB3b3VsZCBleHBlY3QgdG8g c2VlLCBhIHBhcnNlciBhbmQgYnVpbGRlciBmb3IgdGhhdCBzdHJ1Y3R1cmUpIGFuZCB0aGUgbXVs dGlwbGV4ZXIuIFNvIHdlIHRvb2sgdGhlIG9wcG9ydHVuaXR5IHRvIHNlcGFyYXRlIG91dCBtb3Jl IGNsZWFybHkgYSBkaXNjdXNzaW9uIG9mIHRoZSB0d28sIHdoaWNoIHdlIHRoaW5rIHdpbGwgYmUg aGVscGZ1bC4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVu Z2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVsOiUyQjQ0JTIwJTI4 MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxt YWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxp ZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93 LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6 Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j ZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJl Z2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXks IEdVMiA3WVANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1hbmV0IFttYWls dG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZz5d IE9uIEJlaGFsZiBPZiBVbHJpY2ggSGVyYmVyZw0KU2VudDogMDUgQXByaWwgMjAxNiAyMDowOA0K VG86IG1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NClN1YmplY3Q6IFttYW5l dF0gV0dMQyByZXF1ZXN0IGZvciBkcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVp dGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuDQpDb25z aWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3Bl biBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91 cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGlu ZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KKioqIFdBUk5JTkcgKioqDQpFWFRFUk5B TCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2Fu aXphdGlvbi4NCg0KDQpIaSwNCg0KQXMgeW91IGhhdmUgc2Vlbiwgd2UgaGF2ZSBzdWJtaXR0ZWQg YSBuZXcgcmV2aXNpb24gb2YgNTQ0NC11c2FnZS4gVGhlIGF1dGhvcnMgZmVlbCBjb21mb3J0YWJs ZSB0aGF0IHdlIGhhdmUgYWRkcmVzc2VkIGFsbCBpc3N1ZXMgYnkgdGhpcyB2ZXJzaW9uLCBhbmQg d291bGQgbGlrZSB0byBhc2sgdGhlIFdHIGNoYWlycyB0byBpc3N1ZSBhIFdHTEMgb24gdGhpcyBk b2N1bWVudC4gV2hpbGUgaXQgaXMgYSBmYWlybHkgc2hvcnQgZG9jdW1lbnQsIGdpdmVuIHRoYXQg aXQgaXMgSUVURiB3ZWVrIGZvciBzb21lLCB3ZSdkIHN1Z2dlc3QgdGhhdCBhIDMtNCB3ZWVrIFdH TEMgd291bGQgYmUgYXBwcm9wcmlhdGUuDQoNCkJlc3QgcmVnYXJkcw0KVWxyaWNoDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5n IGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNClRoaXMgZW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZA0K cmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQNCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5k IG5vdGlmeSB0aGUgc2VuZGVyLg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9y IGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcg0KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8g YW55IG90aGVyIHBlcnNvbi4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYu b3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWFuZXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0 QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0K DQoNCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923A9EEBGLKXM0002VGREEN_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkJh bGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo YW5rcyBmb3IgdGhhdCBKdXN0aW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZXJl4oCZcyBhIGNvbnZlbmllbnQgcGxh Y2UgdG8gbm90ZSB0aGF0IEZyZWQgQmFrZXIgYXBwZWFycyB0byBiZSBydW5uaW5nIGEgc2NyaXB0 IHRoYXQgZW1haWxzIGFsbCBkcmFmdCBhdXRob3JzIGlmIHRoZSBkcmFmdCBkb2VzbuKAmXQgaW5j bHVkZSBJUHY2IGV4YW1wbGVzLiAoSXTigJlzDQogYSBzY3JpcHQgdGhhdCBuZWVkcyBpbXByb3Zl bWVudCwgYXMgdGhlIGVtYWlsIHN1Z2dlc3RzIHRoYXQgdGhlIGF1dGhvcnMganVzdCBoYXZlbuKA mXQgY29uc2lkZXJlZCBJUHY2LCB3aGljaCBpcyByYXRoZXIgdW5saWtlbHkgd2hlbiBJUHY2IGlz IGV4cGxpY2l0bHkgbWVudGlvbmVkLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgZHJhZnQgaGFzIGFuIElQdjQs IGJ1dCBub3QgYW4gSVB2NiBleGFtcGxlLCB0aG91Z2ggdGhlIHBhcmFncmFwaCBpdOKAmXMgaW4g YWxzbyBkaXNjdXNzZXMgSVB2Ni4gUGVyc29uYWxseSBJIGRvbuKAmXQgdGhpbmsgdGhhdCBhZGRp bmcgYW4gSVB2NiBleGFtcGxlIGhlbHBzDQogd2l0aCB0aGUgcG9pbnQgdGhhdCB3YXMgYmVpbmcg bWFkZSwgYnV0IHdlIHJlc3BvbmRlZCB0byBGcmVkIHNheWluZyB3ZeKAmWQgY29uc2lkZXIgaGlz IGNvbW1lbnQgKG9yIGhpcyBzY3JpcHTigJlzIGNvbW1lbnQpIGFzIHBhcnQgb2YgV0dMQyAoaGVu Y2UgdGhpcyBwb3N0aW5nLCBhcyBvdGhlcndpc2UgaXQgaXMgb25seSBrbm93biB0byB0aGUgYXV0 aG9ycywgY2hhaXJzIGV0Yy4pIGFuZCBzZWUgaWYgdGhlIFdHIGZlbHQgYW4gSVB2NiBleGFtcGxl IHdhcw0KIG5lZWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291bGQgc3VnZ2VzdCByZWFkaW5nIHRoZSBjb250 ZXh0IG9mIHRoZSBleGFtcGxlIGJlZm9yZSB0YWtpbmcgYSB2aWV3LiBUaGUgYXV0aG9ycyB3aWxs IG9mIGNvdXJzZSBmb2xsb3cgYW55IHJvdWdoIGNvbnNlbnN1cy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVyIERlYXJsb3ZlPGJy Pg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50 ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7JiM0Mzs0NCAoMCkx MjQ1IDI0MjE5NCAmbmJzcDt8ICZuYnNwOzxiPkU6DQo8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlz LmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwv YT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxi cj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBH cmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0 cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3 dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIi PkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVk IGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1 cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkp1c3RpbiBEZWFuPGJyPg0KPGI+U2VudDo8L2I+IDA4IEFwcmlsIDIwMTYgMDE6Mjc8YnI+ DQo8Yj5Ubzo8L2I+IEpvaG4gRG93ZGVsbDxicj4NCjxiPkNjOjwvYj4gbWFuZXRAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gV0dMQyByZXF1ZXN0IGZvciBkcmFmdC1p ZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpz b2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjti YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9z cGFuPjwvYj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i Y2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFj a2dyb3VuZDp3aGl0ZSI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMz OTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlv biwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFu PjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8 ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sg b24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48 YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9l bT48L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpy ZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzMzMzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxz IHlvdSByZWNlaXZlLA0KIGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lz dGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZs YWdzLnBkZiI+DQpoZXJlPC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVt YWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5l dC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1l bnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9j ZXNzPC9hPi48L3NwYW4+PC9lbT48L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzMzMzk3MiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjEu MHB0IDQuMHB0IDEuMHB0IDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50 ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KjxzdHJvbmc+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPioq DQo8L3NwYW4+PC9zdHJvbmc+PC9zcGFuPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+V0FSTklORw0KPC9zcGFuPjwvc3Ryb25nPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPioqKjwvc3Bhbj48 L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5FWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRl cyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+TGFzdCBjYWxsIHN0YXJ0 ZWQgb24gdGhlIDZ0aCBvZiBBcHIgYW5kIHdpbGwgZmluaXNoIG9uIHRoZSAyN3RoIG9mIEFwci48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdGluPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEFwciA3LCAy MDE2IGF0IDU6NTAgUE0sIEpvaG4gRG93ZGVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvaG4uZG93 ZGVsbC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpvaG4uZG93ZGVsbC5pZXRmQGdt YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5KdXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCB0byBiZSBjbGVhciwgd2hlbiBkaWQgdGhlIGxhc3Qg Y2FsbCBwZXJpb2Qgc3RhcnQgYW5kIHdoZW4gZG9lcyBpdCBmaW5pc2g/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojODg4ODg4Ij5Kb2huPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNiBBcHIgMjAxNiwgYXQgMTg6MTQs IEp1c3RpbiBEZWFuICZsdDs8YSBocmVmPSJtYWlsdG86YmViZW1hc3RlckBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5iZWJlbWFzdGVyQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNoYWlycyBhZ3JlZSB0 aGF0IGEgMyB3ZWVrIFdHTEMgaXMgYXBwcm9wcmlhdGUuJm5ic3A7IEV2ZXJ5b25lIHBsZWFzZSBy ZWFkIHRoZSBkcmFmdCBlYXJseSBhbmQgZ2V0IGNvbW1lbnRzIGluIGVhcmx5IHNvIHRoYXQgdGhl eSBjYW4gYmUgYWRkcmVzc2VkIHdpdGhpbiB0aGUgbGFzdCBjYWxsIHBlcmlvZC48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3RpbjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEFwciA2LCAy MDE2IGF0IDc6NDAgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspICZsdDs8YSBocmVmPSJt YWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJp cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T2J2aW91c2x5ICYjNDM7MSB0byB0aGUgcmVxdWVzdCBmb3Ig V0dMQy48YnI+DQo8YnI+DQpXaXRoIHJlZ2FyZCB0byB3aGF0J3MgY2hhbmdlZCwgdGVjaG5pY2Fs bHkgdGhlIG9ubHkgc2lnbmlmaWNhbnQgdGhpbmcgaXMgdG8gbWFrZSBpdCBjbGVhciB0aGF0IGlm IGEgcHJvdG9jb2wgZGVsaXZlcnMgYSBtZXNzYWdlIHRvIHRoZSBtdWx0aXBsZXhlciwgdGhlIG11 bHRpcGxleGVyIG11c3QgcGFzcyBpdCBvbiB1bmNoYW5nZWQgdG8gdGhlIHByb3RvY29sIChhbm90 aGVyIGluc3RhbmNlIG9mLCBhdCBhbm90aGVyIHJvdXRlcikgdW5jaGFuZ2VkLg0KIFdpdGhvdXQg dGhhdCBub3RoaW5nIHRoYXQgdGhlIHByb3RvY29sIGl0c2VsZiBjaG9vc2VzIHRvIGRvIHdpdGgg cmVnYXJkIHRvIHNlY3VyaXR5IG1ha2VzIHNlbnNlLiBUaG91Z2ggdGhlIHByb3RvY29sIGNhbiBh bHRlcm5hdGl2ZWx5IGxldCB0aGUgbXVsdGlwbGV4ZXIgZG8gdGhlIHNlY3VyaXR5LCA3MTgyIGNh biBiZSBpbXBsZW1lbnRlZCBpbiBlaXRoZXIgd2F5LiBUaGlzIGlzbid0IHJlYWxseSBuZXcsIGJ1 dCBpdCB3YXNuJ3QgZm9ybWFsbHkNCiBzcGVsbGVkIG91dC4gSXQncyBwcmVzZW50ZWQgYXMgcGFy dCBvZiBzcGVsbGluZyBvdXQgbXVsdGlwbGV4ZXIgcnVsZXMgbW9yZSBjYXJlZnVsbHkuPGJyPg0K PGJyPg0KQnV0IHdoYXQgYWJvdXQgbWVzc2FnZSBvcHRpbWlzYXRpb24/IFRoYXQncyBhIGZ1bmN0 aW9uIG9mIGNvbnN0cnVjdGluZyBhIDU0NDQgbWVzc2FnZSwgbm90IHRoZSBtdWx0aXBsZXhlciwg YW5kIGlzIGRvd24gdG8gdGhhdCA1NDQ0IGluY2x1ZGVzIHR3byB0aGluZ3MgLSBwYWNrZXQvbWVz c2FnZSBzdHJ1Y3R1cmUgKGFuZCBpbXBsaWNpdGx5LCBhbmQgaW4gcHJldHR5IG11Y2ggYW55IGlt cGxlbWVudGF0aW9uIEkgd291bGQgZXhwZWN0IHRvIHNlZSwNCiBhIHBhcnNlciBhbmQgYnVpbGRl ciBmb3IgdGhhdCBzdHJ1Y3R1cmUpIGFuZCB0aGUgbXVsdGlwbGV4ZXIuIFNvIHdlIHRvb2sgdGhl IG9wcG9ydHVuaXR5IHRvIHNlcGFyYXRlIG91dCBtb3JlIGNsZWFybHkgYSBkaXNjdXNzaW9uIG9m IHRoZSB0d28sIHdoaWNoIHdlIHRoaW5rIHdpbGwgYmUgaGVscGZ1bC48YnI+DQo8YnI+DQotLTxi cj4NCkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxi cj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KPGJyPg0KVDogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ0JTIw JTI4MCUyOTEyNDUlMjAyNDIxOTQiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzQ0ICgwKTEyNDUgMjQy MTk0PC9hPiAmbmJzcDt8ICZuYnNwO0U6DQo8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVA YmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z LmNvbTwvYT48YnI+DQo8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hl bG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXgg Q00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIiB0YXJn ZXQ9Il9ibGFuayI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9hPjxicj4NCkJBRSBTeXN0ZW1zIEFw cGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFt cDsgV2FsZXMgTm86IDAxMzM3NDUxPGJyPg0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNl YXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDxicj4NCjxicj4NCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogbWFuZXQgW21haWx0bzo8YSBocmVmPSJtYWls dG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0LWJvdW5jZXNA aWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgVWxyaWNoIEhlcmJlcmc8YnI+DQpTZW50OiAwNSBB cHJpbCAyMDE2IDIwOjA4PGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm1hbmV0QGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFttYW5ldF0g V0dMQyByZXF1ZXN0IGZvciBkcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDM8YnI+DQo8 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlv biwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC48 YnI+DQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBs aW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPGJyPg0KRm9sbG93IHRoZSAnUmVw b3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9u cyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy48YnI+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4N CioqKiBXQVJOSU5HICoqKjxicj4NCkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmln aW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCjxicj4NCkhpLDxicj4NCjxicj4NCkFzIHlvdSBoYXZlIHNlZW4sIHdlIGhhdmUg c3VibWl0dGVkIGEgbmV3IHJldmlzaW9uIG9mIDU0NDQtdXNhZ2UuIFRoZSBhdXRob3JzIGZlZWwg Y29tZm9ydGFibGUgdGhhdCB3ZSBoYXZlIGFkZHJlc3NlZCBhbGwgaXNzdWVzIGJ5IHRoaXMgdmVy c2lvbiwgYW5kIHdvdWxkIGxpa2UgdG8gYXNrIHRoZSBXRyBjaGFpcnMgdG8gaXNzdWUgYSBXR0xD IG9uIHRoaXMgZG9jdW1lbnQuIFdoaWxlIGl0IGlzIGEgZmFpcmx5IHNob3J0IGRvY3VtZW50LCBn aXZlbg0KIHRoYXQgaXQgaXMgSUVURiB3ZWVrIGZvciBzb21lLCB3ZSdkIHN1Z2dlc3QgdGhhdCBh IDMtNCB3ZWVrIFdHTEMgd291bGQgYmUgYXBwcm9wcmlhdGUuPGJyPg0KPGJyPg0KQmVzdCByZWdh cmRzPGJyPg0KVWxyaWNoPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t YW5ldDwvYT48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NClRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZDxicj4NCnJlY2lwaWVudCBh bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJy Pg0KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5 IHRoZSBzZW5kZXIuPGJyPg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFu eSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcjxicj4NCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRv IGFueSBvdGhlciBwZXJzb24uPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptYW5l dEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923A9EEBGLKXM0002VGREEN_-- From nobody Fri Apr 8 15:59:00 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 CEA8612D55B for ; Fri, 8 Apr 2016 15:58:58 -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 9SFzZQJBcpng for ; Fri, 8 Apr 2016 15:58:55 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 49B3012D0E1 for ; Fri, 8 Apr 2016 15:58:55 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id n3so38861267wmn.0 for ; Fri, 08 Apr 2016 15:58:55 -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=o+rhaqF4kQ6sk/60Kxoeet3szE9jm7nPJ9ohkUYRrLs=; b=l6fEhZyqVDPIaZ3ZBx5ViNgxhUSkV++Yula0z0vtsLnogtckIsnpXIBgdvP1tcDalO qBid1reuMP96C3kLGnyXreKMMYEtg7bCo9tTJjJ7WfCToK7mUo2ZyTWioZrWDkX+EBeb Dbhbko5v0OEdnJCO81rQJEEINuUXw+CgUU/taYQe7Nl77fZNeVCwsn2IrhVZsZyZoeF8 xNs3e9XAObN00q/jnt3VTXHasqjQPkowrmHVyx5cn5V+pgdOxaT7bfxjwbA8Hshxj4hR 0+pGE0jiplDbiRSVVIvNCkGNu/fYzcNgVWuD/0Jl4TdYDkrDyvRWEMDAKW2QTq/tvYSI dc0g== 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=o+rhaqF4kQ6sk/60Kxoeet3szE9jm7nPJ9ohkUYRrLs=; b=PkRDS8IkkEyQ/tMAtfQ7KhHST1mmYH433qFmWH0ACVvNZa2g42+4UPLbtpqZUFlYgv S50+cnN+d6mg5vIvFoEwYCRdtCthop+0fW43Bs/n5lLOTS7B1BmRg1e6mhR4ChIc5mXM 5PxvjMvIucWVYLe2BebqZLmke3ruHQj3qRHeOTTkN8c70ImZQaUDZRbXtN+huxC7SSyC aXwVFfcmkwccCd1Z5BzXsyW5HOFnM0plJMDrwAMg/kzyrRqOGGBIZCITW7dCV6rlV5Tc z+bbcTRN9vQNzkTtjBC9I7MMy07uicT+IhgyoV51n/1BGEnqYP/fvlTCqyeDZjP2G8kt scZw== X-Gm-Message-State: AD7BkJLFlc2pGqAlPNwaK77XnC4XIb5BW1sbYrMs/BdGf+87cSAcJ0bNj9ayzjgeZF/+B4LdGK/GIxv+nhmOoQ== MIME-Version: 1.0 X-Received: by 10.28.54.208 with SMTP id y77mr5909528wmh.17.1460156333757; Fri, 08 Apr 2016 15:58:53 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.153.166 with HTTP; Fri, 8 Apr 2016 15:58:53 -0700 (PDT) In-Reply-To: References: <19F3ADDE-C054-47FB-B23D-8CCAD574C557@gmail.com> Date: Sat, 9 Apr 2016 00:58:53 +0200 X-Google-Sender-Auth: R__eHoI4rU--HqYpYnlge2Jxxpo Message-ID: From: Jiazi YI To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a1143543097198005300123ea Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 08 Apr 2016 22:58:59 -0000 --001a1143543097198005300123ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The only IPv4-specific example that I found is the one in "6.1. Address Block Compression" section (please indicate if I missed any other points). In my personal opinion, it's quite straightforward and not necessarily adding an IPv6-specific one. Well, of course, if there were people who really care, adding one won't hurt either :) regards Jiazi On Fri, Apr 8, 2016 at 11:15 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > Thanks for that Justin. > > > > Here=E2=80=99s a convenient place to note that Fred Baker appears to be r= unning a > script that emails all draft authors if the draft doesn=E2=80=99t include= IPv6 > examples. (It=E2=80=99s a script that needs improvement, as the email sug= gests that > the authors just haven=E2=80=99t considered IPv6, which is rather unlikel= y when > IPv6 is explicitly mentioned.) > > > > This draft has an IPv4, but not an IPv6 example, though the paragraph it= =E2=80=99s > in also discusses IPv6. Personally I don=E2=80=99t think that adding an I= Pv6 > example helps with the point that was being made, but we responded to Fre= d > saying we=E2=80=99d consider his comment (or his script=E2=80=99s comment= ) as part of WGLC > (hence this posting, as otherwise it is only known to the authors, chairs > etc.) and see if the WG felt an IPv6 example was needed. > > > > I would suggest reading the context of the example before taking a view. > The authors will of course follow any rough consensus. > > > > *-- * > > > > > *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:* 08 April 2016 01:27 > *To:* John Dowdell > *Cc:* manet@ietf.org > *Subject:* Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > > > > > **** 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. > > > > Last call started on the 6th of Apr and will finish on the 27th of Apr. > > Justin > > > > On Thu, Apr 7, 2016 at 5:50 PM, John Dowdell > wrote: > > Justin > > > > Just to be clear, when did the last call period start and when does it > finish? > > > > Regards > > John > > > > > > On 6 Apr 2016, at 18:14, Justin Dean wrote: > > > > The chairs agree that a 3 week WGLC is appropriate. Everyone please read > the draft early and get comments in early so that they can be addressed > within the last call period. > > > > Justin > > > > On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > Obviously +1 to the request for WGLC. > > With regard to what's changed, technically the only significant thing is > to make it clear that if a protocol delivers a message to the multiplexer= , > the multiplexer must pass it on unchanged to the protocol (another instan= ce > of, at another router) unchanged. Without that nothing that the protocol > itself chooses to do with regard to security makes sense. Though the > protocol can alternatively let the multiplexer do the security, 7182 can = be > implemented in either way. This isn't really new, but it wasn't formally > spelled out. It's presented as part of spelling out multiplexer rules mor= e > carefully. > > But what about message optimisation? That's a function of constructing a > 5444 message, not the multiplexer, and is down to that 5444 includes two > things - packet/message structure (and implicitly, and in pretty much any > implementation I would expect to see, a parser and builder for that > structure) and the multiplexer. So we took the opportunity to separate ou= t > more clearly a discussion of the two, which we think will be helpful. > > -- > 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 > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg > Sent: 05 April 2016 20:08 > To: manet@ietf.org > Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > ----------------------! WARNING ! ---------------------- This message > originates from outside our organisation, either from an external partner > or from the internet. > Consider carefully whether you should click on any links, open any > attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions > on reporting suspicious email messages. > -------------------------------------------------------- > > *** WARNING *** > EXTERNAL EMAIL -- This message originates from outside our organization. > > > > Hi, > > As you have seen, we have submitted a new revision of 5444-usage. The > authors feel comfortable that we have addressed all issues by this versio= n, > and would like to ask the WG chairs to issue a WGLC on this document. Whi= le > it is a fairly short document, given that it is IETF week for some, we'd > suggest that a 3-4 week WGLC would be appropriate. > > Best regards > Ulrich > > _______________________________________________ > 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 > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a1143543097198005300123ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The only IPv4-specific example that I found is the one in = "6.1.=C2=A0 Address Block Compression" section (please indicate i= f I missed any other points).=C2=A0

In my personal opini= on, it's quite straightforward and not necessarily adding an IPv6-speci= fic one.=C2=A0
Well, of course, if there were people who really c= are, adding one won't hurt either :)

regards

Jiazi



On Fri, Apr 8, 2016 a= t 11:15 AM, Dearlove, Christopher (UK) <chris.dearlove@baesyst= ems.com> wrote:

Thanks for that Justin.

=C2=A0

Here=E2=80=99s a convenie= nt place to note that Fred Baker appears to be running a script that emails= all draft authors if the draft doesn=E2=80=99t include IPv6 examples. (It= =E2=80=99s a script that needs improvement, as the email suggests that the authors ju= st haven=E2=80=99t considered IPv6, which is rather unlikely when IPv6 is e= xplicitly mentioned.)

=C2=A0

This draft has an IPv4, b= ut not an IPv6 example, though the paragraph it=E2=80=99s in also discusses= IPv6. Personally I don=E2=80=99t think that adding an IPv6 example helps with the point that was being made, but we responded to Fred saying we=E2= =80=99d consider his comment (or his script=E2=80=99s comment) as part of W= GLC (hence this posting, as otherwise it is only known to the authors, chai= rs etc.) and see if the WG felt an IPv6 example was needed.

=C2=A0

I would suggest reading t= he context of the example before taking a view. The authors will of course = follow any rough consensus.

=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: manet [mailto:manet-bounces@ietf.org] On Behalf Of Justin Dean
Sent: 08 April 2016 01:27
To: John Dowdell
Cc: manet@ietf.o= rg
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage= -03

=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.
For 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.=

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

=C2=A0

Last call started on = the 6th of Apr and will finish on the 27th of Apr.

Justin

=C2=A0

On Thu, Apr 7, 2016 at 5:50 PM, John Dowdell <john.dowdell.= ietf@gmail.com> wrote:

Justin

=C2=A0

Just to be clear, when did the last call period star= t and when does it finish?

=C2=A0

Regards

John

=C2=A0

=C2=A0

On 6 Apr 2016, at 18:14, Justin Dean <bebemaster@gmail.com>= wrote:

=C2=A0

The chairs agree that a 3 week WGLC is appropriate.= =C2=A0 Everyone please read the draft early and get comments in early so th= at they can be addressed within the last call period.

=C2=A0

Justin

=C2=A0

On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christophe= r (UK) <chris.dearlove@baesystems.com> wrote:

Obviously +1 to the request for WGLC.

With regard to what's changed, technically the only significant thing i= s to make it clear that if a protocol delivers a message to the multiplexer= , the multiplexer must pass it on unchanged to the protocol (another instan= ce of, at another router) unchanged. Without that nothing that the protocol itself chooses to do with regard to= security makes sense. Though the protocol can alternatively let the multip= lexer do the security, 7182 can be implemented in either way. This isn'= t really new, but it wasn't formally spelled out. It's presented as part of spelling out multiplexer rules = more carefully.

But what about message optimisation? That's a function of constructing = a 5444 message, not the multiplexer, and is down to that 5444 includes two = things - packet/message structure (and implicitly, and in pretty much any i= mplementation I would expect to see, a parser and builder for that structure) and the multiplexer. So we took t= he opportunity to separate out more clearly a discussion of the two, which = we think will be helpful.

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

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN.
www.baesystems.c= om/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 Ulrich Herberg
Sent: 05 April 2016 20:08
To: manet@ietf.org<= br> Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

----------------------! 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 instru= ctions on reporting suspicious email messages.
--------------------------------------------------------

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



Hi,

As you have seen, we have submitted a new revision of 5444-usage. The autho= rs feel comfortable that we have addressed all issues by this version, and = would like to ask the WG chairs to issue a WGLC on this document. While it = is a fairly short document, given that it is IETF week for some, we'd suggest that a 3-4 week WGLC would= be appropriate.

Best regards
Ulrich

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://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
h= ttps://www.ietf.org/mailman/listinfo/manet

=C2=A0

_______________________________________________
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


--001a1143543097198005300123ea-- From nobody Fri Apr 8 20:21:03 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 3446112D701; Fri, 8 Apr 2016 20:21:02 -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: <20160409032102.23101.34750.idtracker@ietfa.amsl.com> Date: Fri, 08 Apr 2016 20:21:02 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-rfc6779bis-05.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: Sat, 09 Apr 2016 03:21:02 -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-05.txt Pages : 71 Date : 2016-04-08 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 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-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-rfc6779bis-05 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 Sun Apr 10 08:49:42 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 3C30812B01F; Sun, 10 Apr 2016 08:49:40 -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: <20160410154940.10332.91090.idtracker@ietfa.amsl.com> Date: Sun, 10 Apr 2016 08:49:40 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-credit-window-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: Sun, 10 Apr 2016 15:49:40 -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 : Credit Windowing extension for DLEP Author : Stan Ratliff Filename : draft-ietf-manet-credit-window-04.txt Pages : 12 Date : 2016-04-10 Abstract: This draft describes an extension to the DLEP protocol to provide a credit-windowing scheme analogous to that in RFC5578 for destination- specific flow control. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-credit-window/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-credit-window-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-credit-window-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 Sun Apr 10 08:52: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 DF17512B02B for ; Sun, 10 Apr 2016 08:52:09 -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 DKNr1xNBGyzJ for ; Sun, 10 Apr 2016 08:52:08 -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 D2DB612B019 for ; Sun, 10 Apr 2016 08:52:07 -0700 (PDT) Received: by mail-ig0-x235.google.com with SMTP id kb1so65800073igb.0 for ; Sun, 10 Apr 2016 08:52:07 -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=/Qmclkf92W1lzBiUK02X+6mvbyhisGl1aMxdyX3luD8=; b=e52EHW5WhsDbksBT7XzXJqo0mNqbKbmi7S6FTkUnTcFsEMEPZQyBSb0WWZi0RndIoE oNu83A43umd6V1iZIk6ERSxe6xsaF4iS3fkkFFhMsZo6yAZWLX/qmIPZka2LlufMCipD wenG6Eg6W1gGMDE/b+zWyRQopuvma31O2na8A4ni2fMDvp3+XQ4V3fmUNRqCXK5zBZFg Pcb+gCkXtkNg5rpmWacZHX+LxszRxXyNAPHpb0WPby/5hvOUhEfgidEvyYNwD//2Gie8 ZvrARVkvbhEH644X7irII2mRzMA04y/QLLeEwaedwIgvy+X9na7D4qODfTi4M4VqaEWM 2SAA== 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=/Qmclkf92W1lzBiUK02X+6mvbyhisGl1aMxdyX3luD8=; b=CUmFYhR1SxJVXAIaJwtpNpvXDOZGhW3E/y0EiqLfbffGL9Y2v9oveK4p7lwOnk1Ly1 CAzeYGp/ACvL2cUzCHrcfMwHr9OGgl4+gvlTLsMq4PxdHxTs6TNWJCjnoJ+cdnMZOYkz Dhc2m1VVkt27zvvq2oST8KGSv7XhF9Wrn5NOaH9NBSlQnfx2N/z2G10Q4t+rM+i4xV8L GFr/vW3bC9xsDPp6DHbFu45NsDblR90h7rNL0m0/W6a7v7cByPjxYtGtQBev8XOU4Riz VPO0NghEQE5moew5gSPRRQcHCTaaA2warABvj8lm/42CSzY4z5QAR1SYaznYb1SeZWhF fzmg== X-Gm-Message-State: AD7BkJKJWL/24KUN/Tdm15UDQ52lsaQgkLEEx2N88AKzhDc03KajbD+lYJCgq1vlD1ke0+NAVstjz4GTfcv59w== MIME-Version: 1.0 X-Received: by 10.50.73.133 with SMTP id l5mr13728840igv.69.1460303527198; Sun, 10 Apr 2016 08:52:07 -0700 (PDT) Received: by 10.79.96.1 with HTTP; Sun, 10 Apr 2016 08:52:07 -0700 (PDT) In-Reply-To: <20160410154940.10332.91090.idtracker@ietfa.amsl.com> References: <20160410154940.10332.91090.idtracker@ietfa.amsl.com> Date: Sun, 10 Apr 2016 11:52:07 -0400 Message-ID: From: Stan Ratliff To: MANET IETF Content-Type: multipart/alternative; boundary=089e0129483a00c8cf0530236953 Archived-At: Subject: [manet] Fwd: I-D Action: draft-ietf-manet-credit-window-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: Sun, 10 Apr 2016 15:52:10 -0000 --089e0129483a00c8cf0530236953 Content-Type: text/plain; charset=UTF-8 Hello WG, As you can see, I've posted DLEP credit-window 04. This posting just addresses issues from the 'idnits' tool prior to the AD reviews. Regards, Stan ---------- Forwarded message ---------- From: Date: Sun, Apr 10, 2016 at 11:49 AM Subject: [manet] I-D Action: draft-ietf-manet-credit-window-04.txt To: i-d-announce@ietf.org Cc: manet@ietf.org 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 : Credit Windowing extension for DLEP Author : Stan Ratliff Filename : draft-ietf-manet-credit-window-04.txt Pages : 12 Date : 2016-04-10 Abstract: This draft describes an extension to the DLEP protocol to provide a credit-windowing scheme analogous to that in RFC5578 for destination- specific flow control. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-credit-window/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-credit-window-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-credit-window-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/ _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --089e0129483a00c8cf0530236953 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello WG,

As you can see, I&#= 39;ve posted DLEP credit-window 04. This posting just addresses issues from= the 'idnits' tool prior to the AD reviews.

Regards,<= br>
Stan

--= -------- Forwarded message ----------
From: <in= ternet-drafts@ietf.org>
Date: Sun, Apr 10, 2016 at 11:49 A= M
Subject: [manet] I-D Action: draft-ietf-manet-credit-window-04.txt
= To: i-d-announce@ietf.org
C= c: manet@ietf.org



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.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Credit Windowing extension for DLEP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Stan= Ratliff
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-manet-credit-window-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 12
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-04-10

Abstract:
=C2=A0 =C2=A0This draft describes an extension to the DLEP protocol to prov= ide a
=C2=A0 =C2=A0credit-windowing scheme analogous to that in RFC5578 for desti= nation-
=C2=A0 =C2=A0specific flow control.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-ietf-manet-credit-window/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-= manet-credit-window-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-manet-credit-window-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

--089e0129483a00c8cf0530236953-- From nobody Wed Apr 13 16:59: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 C2B8612D5FF for ; Wed, 13 Apr 2016 16:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.715 X-Spam-Level: X-Spam-Status: No, score=-3.715 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, 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 nOV9VibjwYB2 for ; Wed, 13 Apr 2016 16:59:49 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB0C12DABD for ; Wed, 13 Apr 2016 16:59:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=BDksNomuRFHOaN6hyBtSVb8VQXhIGKID8I/fa+CMnpq/TqkqFlAQy2USlZDZ9n/M; h=Received:From:Subject:To:Message-ID:Date:User-Agent:MIME-Version:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.67]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1aqUhA-0001mZ-Ty for manet@ietf.org; Wed, 13 Apr 2016 19:59:41 -0400 From: Charlie Perkins To: Mobile Ad Hoc Networks mailing list Message-ID: <570EDD6A.8070605@earthlink.net> Date: Wed, 13 Apr 2016 16:59:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020501050606070904050709" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac73f6f4d7153363a40a595d71136941498350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: [manet] draft-ietf-manet-rfc5444-usage-03 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, 13 Apr 2016 23:59:51 -0000 This is a multi-part message in MIME format. --------------020501050606070904050709 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello folks, This is not a short document. It is not easy to read. I have only read halfway through it. Among the first problems with the draft, keeping in mind that I have not finished it: * It should be no more than Informational, and more likely Experimental owing to the next point. * The protocols that somehow manage to conform to this formulation of correctness are written by the authors themselves. Thus, it seems unrealistic to imagine that the restrictions actually allow general-purpose routing protocol designs. * It is improper for adherence to one simple parser design to constrain protocol design for such a wide class of routing problems as are represented by ad hoc networks. * As practiced to date, RFC 5444 has inhibited the use of default values for system parameters. In the document this is exhibited as a feature which is erroneously claimed to be required for future extensibility. * The document requires the protocol to know about MTU but discussion on the list inhibits the protocol from knowing about MTU. * The document disallows the protocol from specifying crucial parameters such as time allowable for aggregation of control messages. * Addresses are presumed to be included in a message for no particular reason unless described by yet another address TLV. This increases message size on the speculation that the protocol will want to be used with other unrelated protocols in the future. In normal protocol design, addresses are put into a message for reasons that are specific to the message. On average, the design of the multiplexer is presumed to be the highest priority and the design of the routing protocol a distinctly less important matter. Moreover, the multiplexer design is subservient to whatever is easiest for the container designers to parse. This is putting the cart before the horse. I will try to finish reading the draft soon, but I think that Last Call for this document is premature at best. I would strongly suggest that it be delayed until the current two major [manet] items can be finished. Regards, Charlie P. --------------020501050606070904050709 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hello folks,

This is not a short document.  It is not easy to read.

I have only read halfway through it.  Among the first problems with the draft, keeping in mind that I have not finished it:
  • It should be no more than Informational, and more likely Experimental owing to the next point.
  • The protocols that somehow manage to conform to this formulation of correctness are written by the authors themselves.  Thus, it seems unrealistic to imagine that the restrictions actually allow general-purpose routing protocol designs.
  • It is improper for adherence to one simple parser design to constrain protocol design for such a wide class of routing problems as are represented by ad hoc networks.
  • As practiced to date, RFC 5444 has inhibited the use of default values for system parameters.   In the document this is exhibited as a feature which is erroneously claimed to be required for future extensibility.
  • The document requires the protocol to know about MTU but discussion on the list inhibits the protocol from knowing about MTU.
  • The document disallows the protocol from specifying crucial parameters such as time allowable for  aggregation of control messages.
  • Addresses are presumed to be included in a message for no particular reason unless described by yet another address TLV.  This increases message size on the speculation that the protocol will want to be used with other unrelated protocols in the future.  In normal protocol design, addresses are put into a message for reasons that are specific to the message.
On average, the design of the multiplexer is presumed to be the highest priority and the design of the routing protocol a distinctly less important matter.  Moreover, the multiplexer design is subservient to whatever is easiest for the container designers to parse.  This is putting the cart before the horse.

I will try to finish reading the draft soon, but I think that Last Call for this document is premature at best.  I would strongly suggest that it be delayed until the current two major [manet] items can be finished.

Regards,
Charlie P.

--------------020501050606070904050709-- From nobody Thu Apr 14 02:10:00 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 904F812D834 for ; Thu, 14 Apr 2016 02:09:58 -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 11nNnbhpyb0Q for ; Thu, 14 Apr 2016 02:09:56 -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 B2F6212D66E for ; Thu, 14 Apr 2016 02:09:55 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,484,1454976000"; d="scan'208,217"; a="60658991" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 14 Apr 2016 10:09:10 +0100 X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="scan'208,217";a="113947142" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 14 Apr 2016 10:09:08 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Thu, 14 Apr 2016 10:09:09 +0100 From: "Dearlove, Christopher (UK)" To: Charlie Perkins , "Mobile Ad Hoc Networks mailing list" Thread-Topic: [manet] draft-ietf-manet-rfc5444-usage-03 Thread-Index: AQHRleCay/2tOcZafEiNXhaBb3Hay5+JJpaw Date: Thu, 14 Apr 2016 09:09:07 +0000 Message-ID: References: <570EDD6A.8070605@earthlink.net> In-Reply-To: <570EDD6A.8070605@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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ACE98GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] draft-ietf-manet-rfc5444-usage-03 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, 14 Apr 2016 09:09:58 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ACE98GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Q2hhcmxpZQ0KPiBUaGlzIGlzIG5vdCBhIHNob3J0IGRvY3VtZW50LiAgSXQgaXMgbm90IGVhc3kg dG8gcmVhZC4NCg0KSWYgeW91IGhhdmUgYW55IHNwZWNpZmljIG9ic2VydmF0aW9ucywgcGxlYXNl IGxldCB1cyBoYXZlIHRoZW0uDQoNCj4gSSBoYXZlIG9ubHkgcmVhZCBoYWxmd2F5IHRocm91Z2gg aXQuICBBbW9uZyB0aGUgZmlyc3QgcHJvYmxlbXMgd2l0aCB0aGUgZHJhZnQsIGtlZXBpbmcgaW4g bWluZCB0aGF0IEkgaGF2ZSBub3QgZmluaXNoZWQgaXQ6DQoNCiAgKiAgIEl0IHNob3VsZCBiZSBu byBtb3JlIHRoYW4gSW5mb3JtYXRpb25hbCwgYW5kIG1vcmUgbGlrZWx5IEV4cGVyaW1lbnRhbCBv d2luZyB0byB0aGUgbmV4dCBwb2ludC4NClRoaXMgaXMgZW50aXJlbHkgd3JvbmcuIFRoZSBkb2N1 bWVudCBpcyBub3QgSW5mb3JtYXRpb25hbCwgaXQgc3BlY2lmaWVzIHJ1bGVzLiBJdCBoYXMgYWJz b2x1dGVseSBubyBuZWVkIHRvIGJlIEV4cGVyaW1lbnRhbCBhcyBpdCBoYXMgYSBsYXJnZSBhbW91 bnQgb2YgZXhwZXJpZW5jZSwgd2l0aCBhIHJlYWN0aXZlIHByb3RvY29sIGFzIHdlbGwgYXMgcHJv YWN0aXZlLCBiZWhpbmQgaXQsIGFuZCBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgcnVubmluZyBjb2Rl Lg0KSXQgd2FzIGFsc28gYWNjZXB0ZWQgYXMgYSBXRyBpdGVtIGFzIGludGVuZGVkIGZvciBQcm9w b3NlZCBTdGFuZGFyZC4NCg0KICAqICAgVGhlIHByb3RvY29scyB0aGF0IHNvbWVob3cgbWFuYWdl IHRvIGNvbmZvcm0gdG8gdGhpcyBmb3JtdWxhdGlvbiBvZiBjb3JyZWN0bmVzcyBhcmUgd3JpdHRl biBieSB0aGUgYXV0aG9ycyB0aGVtc2VsdmVzLiAgVGh1cywgaXQgc2VlbXMgdW5yZWFsaXN0aWMg dG8gaW1hZ2luZSB0aGF0IHRoZSByZXN0cmljdGlvbnMgYWN0dWFsbHkgYWxsb3cgZ2VuZXJhbC1w dXJwb3NlIHJvdXRpbmcgcHJvdG9jb2wgZGVzaWducy4NCknigJltIG5vdCBzdXJlIGhvdyB0byBy ZXNwb25kIHRvIHRoaXMuIEl04oCZcyB3cml0dGVuIGJ5IHRoZSBwZW9wbGUgd2l0aCB0aGUgbW9z dCBleHBlcmllbmNlIG9mIFJGQyA1NDQ0LCBhdCBsZWFzdCBvbmUgb2Ygd2hvbSBmb3IgYSByZWFj dGl2ZSBwcm90b2NvbCBhcyB3ZWxsIGFzIE5IRFAgYW5kIE9MU1J2Mi4gSXTigJlzIGJ1aWx0IG9u IGNvbGxlY3RpdmVseSBkZWNhZGVzIG9mIGV4cGVyaWVuY2UsIGFuZCBhbGwgb2YgdGhlIGNvLWF1 dGhvcnMgaGF2ZSBpbXBsZW1lbnRlZCBSRkMgNTQ0NCBhbmQgcHJvdG9jb2xzIHVzaW5nIGl0LCBz b21lIG1vcmUgdGhhbiBvbmNlLiBUaGUgaWRlYSB0aGF0IHRoaXMgbWFrZXMgdXMgdW5zdWl0ZWQg aXMgb25lIEkgZG8gbm90IHVuZGVyc3RhbmQuDQoNCiAgKiAgIEl0IGlzIGltcHJvcGVyIGZvciBh ZGhlcmVuY2UgdG8gb25lIHNpbXBsZSBwYXJzZXIgZGVzaWduIHRvIGNvbnN0cmFpbiBwcm90b2Nv bCBkZXNpZ24gZm9yIHN1Y2ggYSB3aWRlIGNsYXNzIG9mIHJvdXRpbmcgcHJvYmxlbXMgYXMgYXJl IHJlcHJlc2VudGVkIGJ5IGFkIGhvYyBuZXR3b3Jrcy4NClNvcnJ5LCB5b3UgYXJlIHdlbGwgb3V0 IG9mIGxpbmUgdGhlcmUuIFRoaXMgd2FzIGEgV0cgZGVjaXNpb24sIHNwZWNpZmllZCBpbiBSRkMg NTQ5OC4gQSBkb2N1bWVudCB3cml0dGVuIGJ5IHlvdXIgdGhlbiBEWU1PIGNvLWF1dGhvciBJYW4g Q2hha2VyZXMgKGFsc28gV0cgY2hhaXIpIGFuZCBhZ3JlZWQgYnkgdGhlIFdHLiBJdCB3YXNu4oCZ dCBmb2lzdGVkIG9uIHlvdSBieSB0aGUgYXV0aG9ycyAtIHF1aXRlIHRoZSByZXZlcnNlLCB3ZSBo YWQgbWFraW5nIGl0IHdvcmsgYXMgYSBnZW5lcmljIHNwZWNpZmljYXRpb24gcHV0IG9udG8gdXMu DQoNCiAgKiAgIEFzIHByYWN0aWNlZCB0byBkYXRlLCBSRkMgNTQ0NCBoYXMgaW5oaWJpdGVkIHRo ZSB1c2Ugb2YgZGVmYXVsdCB2YWx1ZXMgZm9yIHN5c3RlbSBwYXJhbWV0ZXJzLiAgIEluIHRoZSBk b2N1bWVudCB0aGlzIGlzIGV4aGliaXRlZCBhcyBhIGZlYXR1cmUgd2hpY2ggaXMgZXJyb25lb3Vz bHkgY2xhaW1lZCB0byBiZSByZXF1aXJlZCBmb3IgZnV0dXJlIGV4dGVuc2liaWxpdHkuDQpJIGRv buKAmXQga25vdyB3aGF0IHlvdSBhcmUgdGFsa2luZyBhYm91dCBoZXJlLiBSRkMgNTQ0NCBpc27i gJl0IGNvbmNlcm5lZCB3aXRoIHN5c3RlbSBwYXJhbWV0ZXJzLiBXaGF04oCZcyBjbGFpbWVkIHRv IGJlIHVzZWZ1bCBmb3IgZXh0ZW5zaWJpbGl0eSBpcyB0aGF0IHdoaWNoIGlzIGFscmVhZHkgZXhw ZXJpZW5jZWQgdG8gYmUgdXNlZnVsIGZvciBleHRlbnNpYmlsaXR5LCBhbmQgZXhhbXBsZXMgZ2l2 ZW4uDQoNCiAgKiAgIFRoZSBkb2N1bWVudCByZXF1aXJlcyB0aGUgcHJvdG9jb2wgdG8ga25vdyBh Ym91dCBNVFUgYnV0IGRpc2N1c3Npb24gb24gdGhlIGxpc3QgaW5oaWJpdHMgdGhlIHByb3RvY29s IGZyb20ga25vd2luZyBhYm91dCBNVFUuDQpFdmVuIGlmIHNvbWVvbmUgb24gdGhlIGxpc3Qgc2Fp ZCB0aGF0IHRoZSBwcm90b2NvbCBpcyBpbmhpYml0ZWQgZnJvbSBrbm93aW5nIGFib3V0IE1UVSwg dGhhdOKAmXMgbm90IHJlbGV2YW50LiBEb2VzIHRoaXMgZG9jdW1lbnQgc2F5IHRoYXQ/IE5vLiBC dXQgSSBhbHNvIGRvbuKAmXQgcmVjYWxsIGFueW9uZSBzYXlpbmcgdGhhdC4gQW55IHByb3RvY29s IChvciBldmVuIG1hbnkgYXBwbGljYXRpb25zKSB0aGF0IHJ1biBkaXJlY3RseSBvciBpbmRpcmVj dGx5IG92ZXIgSVAgbmVlZCB0byBoYXZlIHNvbWUgaWRlYSBhYm91dCBNVFUsIHBvc3NpYmx5IHdp dGggcnVsZXMgb2YgdGh1bWIgYXMgdG8gaG93IG11Y2ggdG8gc3VidHJhY3QgZHVlIHRvIGV4cGVj dGVkIGhlYWRlcnMuIFRoaXMgaXMgbm8gZGlmZmVyZW50Lg0KDQogICogICBUaGUgZG9jdW1lbnQg ZGlzYWxsb3dzIHRoZSBwcm90b2NvbCBmcm9tIHNwZWNpZnlpbmcgY3J1Y2lhbCBwYXJhbWV0ZXJz IHN1Y2ggYXMgdGltZSBhbGxvd2FibGUgZm9yICBhZ2dyZWdhdGlvbiBvZiBjb250cm9sIG1lc3Nh Z2VzLg0KVGhhdCBpcyBleGFjdGx5IGJhY2t3YXJkcy4gRnJvbSBTZWN0aW9uIDQuMg0KICAgbyAg VGhlIG11bHRpcGxleGVyIE1BWSBkZWxheSBtZXNzYWdlcyBicmllZmx5IGluIG9yZGVyIHRvIGFz c2VtYmxlDQogICAgICBtb3JlIGVmZmljaWVudCBwYWNrZXRzLiAgSXQgU0hPVUxEIHJlc3BlY3Qg YW55IGNvbnN0cmFpbnRzIG9uIHN1Y2gNCiAgICAgIGRlbGF5cyByZXF1ZXN0ZWQgYnkgdGhlIHBy b3RvY29sLg0KSWYgeW91IHdhbnQgdG8gYXJndWUgdGhhdCB0aGUgU0hPVUxEIG91Z2h0IHRvIGJl IGEgTVVTVCB0aGVuIGZpbmUsIEnigJlkIGhhdmUgc29tZSBzeW1wYXRoeSB3aXRoIHRoYXQsIGJ1 dCB3ZSB3ZXJlIHRyeWluZyBub3QgdG8gb3Zlcmx5IGNvbnN0cmFpbi4gQnV0IHRoYXQgdGhlIHBy b3RvY29sIGNhbiBpbmZvcm0gdGhlIG11bHRpcGxleGVyIGlzIGNsZWFybHkgdGhlcmUuDQoNCiAg KiAgIEFkZHJlc3NlcyBhcmUgcHJlc3VtZWQgdG8gYmUgaW5jbHVkZWQgaW4gYSBtZXNzYWdlIGZv ciBubyBwYXJ0aWN1bGFyIHJlYXNvbiB1bmxlc3MgZGVzY3JpYmVkIGJ5IHlldCBhbm90aGVyIGFk ZHJlc3MgVExWLiAgVGhpcyBpbmNyZWFzZXMgbWVzc2FnZSBzaXplIG9uIHRoZSBzcGVjdWxhdGlv biB0aGF0IHRoZSBwcm90b2NvbCB3aWxsIHdhbnQgdG8gYmUgdXNlZCB3aXRoIG90aGVyIHVucmVs YXRlZCBwcm90b2NvbHMgaW4gdGhlIGZ1dHVyZS4gIEluIG5vcm1hbCBwcm90b2NvbCBkZXNpZ24s IGFkZHJlc3NlcyBhcmUgcHV0IGludG8gYSBtZXNzYWdlIGZvciByZWFzb25zIHRoYXQgYXJlIHNw ZWNpZmljIHRvIHRoZSBtZXNzYWdlLg0KWWVzLCB0aGlzIGlzIGEgZGVzaWduIGZlYXR1cmUgdGhh dCBpcyBoaWdobHkgZGVzaXJhYmxlIGZvciBleHRlbnNpYmlsaXR5LiBUaGF04oCZcyB0aGUgZXhw ZXJpZW5jZSBvZiBhIGxvdCBvZiB0aW1lIHdvcmtpbmcgd2l0aCBhIHByb3RvY29sIChPTFNSKSB3 aXRob3V0IHRoYXQsIGFuZCB0aGlzLiBJIGNhbiBhbHJlYWR5IHNlZSBob3cgcG9zc2libGUgZXh0 ZW5zaW9ucyB0byBBT0RWdjIgY291bGQgdXNlIHRoaXMgZnJlZWRvbS4gV2hpbGUgYnl0ZXMgZG8g bWF0dGVyLCBzbyBkb2VzIGV4dGVuc2liaWxpdHkuDQpGcmFua2x5LCB3aGF0IHByb3RvY29scyBu ZWVkIGlzIHRvIGdvIGluIG9uZSBkaXJlY3Rpb24gb3IgdGhlIG90aGVyLiBPbmUgZGlyZWN0aW9u IGlzIGEgdGlnaHRseSBvcHRpbWlzZWQgdWx0cmEtY29tcGFjdCBtZXNzYWdlIGZvciB2ZXJ5IHNw ZWNpZmljIHVzZSwgaW4gcGFydGljdWxhciBmb3Igc3lzdGVtcyBiYXNlZCBvbiBtaWNyb2NvbnRy b2xsZXJzIGFuZCB2ZXJ5IGNvbnN0cmFpbmVkIHdpcmVsZXNzIGxpbmtzLiBJdOKAmXMgcXVpdGUg b3BlbiB0byB5b3UgdG8gY3JlYXRlIGEgc2VwYXJhdGUgbWVzc2FnZSBzdHJ1Y3R1cmUgZm9yIHRo YXQuIFlvdeKAmXJlIGFscmVhZHkgcGFydCB3YXkgdGhlcmUgd2l0aCBmaXJzdCBzcGVjaWZ5aW5n IHdoYXTigJlzIGluIGEgbWVzc2FnZSwgdGhlbiBob3cgdGhhdOKAmXMgcmVwcmVzZW50ZWQgaW4g UkZDIDU0NDQuIEluIGFuIGlkZWFsIHdvcmxkIHdl4oCZZCBoYXZlIGRvbmUgdGhlIHNhbWUgZm9y IE9MU1J2Mi4gVGhlIG90aGVyIGRpcmVjdGlvbiwgd2hpbGUgbm90IG9ibGl2aW91cyB0byBlZmZp Y2llbmN5IGNvbmNlcm5zLCBpcyBwcmVwYXJlZCB0byBhZGQgYSBmZXcgb2N0ZXRzIChhbmQgd2Ug YXJlIHRhbGtpbmcgYSBsb3cgc2luZ2xlIGZpZ3VyZSBudW1iZXIpIHRvIGFsbG93IGV4dGVuc2li aWxpdHkuIEV2ZW4gdGhlIGF1dGhvcnMgbWlzc2VkIHNvbWUgZXh0ZW5zaWJpbGl0eSBvcHRpb25z IGJhY2sgaW4gZWFybGllciBkYXlzLCB3aG9ldmVyIGl0IHdhcyB0aGF0IGluc2lzdGVkIG9uIGEg cGVyLW1lc3NhZ2UgYWRkcmVzcyBsZW5ndGgsIHJhdGhlciB0aGFuIGluaGVyaXRpbmcgZnJvbSB3 aGF0ZXZlciBJUCBzdGFjayB5b3Ugd2VyZSBydW5uaW5nIG9uLCB3YXMgcmlnaHQuDQpBbiBhcHBl bmRpeCAob3IgcHJvYmFibHkgaW4gbGlnaHQgb2YgdGltZXNjYWxlcykgc2VwYXJhdGUgZHJhZnQg b24gYW4gdWx0cmEtY29tcGFjdCByZXByZXNlbnRhdGlvbiBvZiBBT0RWdjIsIGV4cGxpY2l0bHkg bm90IGludGVuZGVkIHRvIGJlIGV4dGVuc2libGUsIHdvdWxkIGJlIGludGVyZXN0aW5nLCBhbmQg bWlnaHQgZmluZCBzb21lIGFwcGxpY2F0aW9uLg0KPiBPbiBhdmVyYWdlLCB0aGUgZGVzaWduIG9m IHRoZSBtdWx0aXBsZXhlciBpcyBwcmVzdW1lZCB0byBiZSB0aGUgaGlnaGVzdCBwcmlvcml0eSBh bmQgdGhlIGRlc2lnbiBvZiB0aGUgcm91dGluZyBwcm90b2NvbCBhIGRpc3RpbmN0bHkgbGVzcyBp bXBvcnRhbnQgbWF0dGVyLiAgTW9yZW92ZXIsIHRoZSBtdWx0aXBsZXhlciBkZXNpZ24gaXMgc3Vi c2VydmllbnQgdG8gd2hhdGV2ZXIgaXMgZWFzaWVzdCBmb3IgdGhlIGNvbnRhaW5lciBkZXNpZ25l cnMgdG8gcGFyc2UuICBUaGlzIGlzIHB1dHRpbmcgdGhlIGNhcnQgYmVmb3JlIHRoZSBob3JzZS4N ClRoZSBtdWx0aXBsZXhlciBpcyBpbiBwbGFjZSwgdGhhdOKAmXMgUkZDIDU0OTguIFRoaXMgaXNu 4oCZdCBuZXcuIFRoZSBob3JzZSBpcyBhbHJlYWR5IGluIGZyb250IG9mIHRoZSBjYXJ0Lg0KDQo+ IEkgd2lsbCB0cnkgdG8gZmluaXNoIHJlYWRpbmcgdGhlIGRyYWZ0IHNvb24sIGJ1dCBJIHRoaW5r IHRoYXQgTGFzdCBDYWxsIGZvciB0aGlzIGRvY3VtZW50IGlzIHByZW1hdHVyZSBhdCBiZXN0LiAg SSB3b3VsZCBzdHJvbmdseSBzdWdnZXN0IHRoYXQgaXQgYmUgZGVsYXllZCB1bnRpbCB0aGUgY3Vy cmVudCB0d28gbWFqb3IgW21hbmV0XSBpdGVtcyBjYW4gYmUgZmluaXNoZWQuDQpUaGF04oCZcyBj b21wbGV0ZWx5IHVuYWNjZXB0YWJsZS4gV2hvIGtub3dzIGhvdyBsb25nIHlvdSBhcmUgZ29pbmcg dG8gY29udGludWUgdG8gd29yayBvbiBBT0RWdjIgb3V0IG9mIHNpZ2h0IG9mIHRoaXMgV0cuIEFu ZCB0aGlzIHJlYWxseSBpcyB0aGUgY2FydCBiZWZvcmUgdGhlIGhvcnNlLiBZb3VyIGNvLWF1dGhv cnMgb2YgQU9EVnYyIHJlcXVlc3RlZCBmdXJ0aGVyIGNsYXJpZmljYXRpb24gb2YgUkZDIDU0NDQs IGFuZCB3ZSBwdXQgaW4gdGhlIHdvcmsgdG8gZG8gdGhhdC4gQ2xhcmlmeWluZyB0aGUgYmFzZSBi ZWZvcmUgYnVpbGRpbmcgb24gaXQgaXMgdGhlIHJpZ2h0IG9yZGVyLg0KQWxzbywgd2h5IHR3byBX RyBkb2N1bWVudHM/IFRoZSBvbmx5IG90aGVyIHNpZ25pZmljYW50IGRvY3VtZW50IGlzIERMRVAs IHdoaWNoIGlzIGJvdGggaW5kZXBlbmRlbnQgb2YgdGhpcyAoaXQgZG9lc27igJl0IHVzZSA1NDQ0 IC0gYW5kIHRoYXTigJlzIGJlY2F1c2UgaXTigJlzIG5vdCBhIE1BTkVUIHJvdXRpbmcgcHJvdG9j b2wpIGFuZCBhbHJlYWR5IG91dCBvZiB0aGUgZ2F0ZS4NCg0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKVGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkCnJl Y2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5v dGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55 IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBv dGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ACE98GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6OTE0MDUzNTY3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTk1NTkz NjMxMDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DaGFybGllPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZn dDsgPC9zcGFuPlRoaXMgaXMgbm90IGEgc2hvcnQgZG9jdW1lbnQuJm5ic3A7IEl0IGlzIG5vdCBl YXN5IHRvIHJlYWQuPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgeW91 IGhhdmUgYW55IHNwZWNpZmljIG9ic2VydmF0aW9ucywgcGxlYXNlIGxldCB1cyBoYXZlIHRoZW0u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDsgPC9zcGFuPkkgaGF2ZSBvbmx5IHJlYWQgaGFsZndh eSB0aHJvdWdoIGl0LiZuYnNwOyBBbW9uZyB0aGUgZmlyc3QgcHJvYmxlbXMgd2l0aCB0aGUgZHJh ZnQsIGtlZXBpbmcgaW4gbWluZCB0aGF0IEkgaGF2ZSBub3QgZmluaXNoZWQgaXQ6PG86cD48L286 cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj4NCkl0IHNob3VsZCBiZSBubyBtb3JlIHRoYW4gSW5mb3JtYXRpb25h bCwgYW5kIG1vcmUgbGlrZWx5IEV4cGVyaW1lbnRhbCBvd2luZyB0byB0aGUgbmV4dCBwb2ludC48 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgaXMgZW50aXJlbHkgd3JvbmcuIFRo ZSBkb2N1bWVudCBpcyBub3QgSW5mb3JtYXRpb25hbCwgaXQgc3BlY2lmaWVzIHJ1bGVzLiBJdCBo YXMgYWJzb2x1dGVseQ0KIG5vIG5lZWQgdG8gYmUgRXhwZXJpbWVudGFsIGFzIGl0IGhhcyBhIGxh cmdlIGFtb3VudCBvZiBleHBlcmllbmNlLCB3aXRoIGEgcmVhY3RpdmUgcHJvdG9jb2wgYXMgd2Vs bCBhcyBwcm9hY3RpdmUsIGJlaGluZCBpdCwgYW5kIG11bHRpcGxlIGluc3RhbmNlcyBvZiBydW5u aW5nIGNvZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgd2FzIGFsc28gYWNj ZXB0ZWQgYXMgYSBXRyBpdGVtIGFzIGludGVuZGVkIGZvciBQcm9wb3NlZCBTdGFuZGFyZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRoZSBwcm90b2NvbHMgdGhhdCBzb21laG93 IG1hbmFnZSB0byBjb25mb3JtIHRvIHRoaXMgZm9ybXVsYXRpb24gb2YgY29ycmVjdG5lc3MgYXJl IHdyaXR0ZW4gYnkgdGhlIGF1dGhvcnMgdGhlbXNlbHZlcy4mbmJzcDsgVGh1cywgaXQgc2VlbXMg dW5yZWFsaXN0aWMgdG8gaW1hZ2luZSB0aGF0IHRoZSByZXN0cmljdGlvbnMgYWN0dWFsbHkgYWxs b3cgZ2VuZXJhbC1wdXJwb3NlIHJvdXRpbmcgcHJvdG9jb2wgZGVzaWducy48bzpwPjwvbzpwPjwv bGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJltIG5vdCBzdXJlIGhvdyB0byByZXNwb25kIHRvIHRoaXMu IEl04oCZcyB3cml0dGVuIGJ5IHRoZSBwZW9wbGUgd2l0aCB0aGUgbW9zdCBleHBlcmllbmNlIG9m IFJGQyA1NDQ0LA0KIGF0IGxlYXN0IG9uZSBvZiB3aG9tIGZvciBhIHJlYWN0aXZlIHByb3RvY29s IGFzIHdlbGwgYXMgTkhEUCBhbmQgT0xTUnYyLiBJdOKAmXMgYnVpbHQgb24gY29sbGVjdGl2ZWx5 IGRlY2FkZXMgb2YgZXhwZXJpZW5jZSwgYW5kIGFsbCBvZiB0aGUgY28tYXV0aG9ycyBoYXZlIGlt cGxlbWVudGVkIFJGQyA1NDQ0IGFuZCBwcm90b2NvbHMgdXNpbmcgaXQsIHNvbWUgbW9yZSB0aGFu IG9uY2UuIFRoZSBpZGVhIHRoYXQgdGhpcyBtYWtlcyB1cyB1bnN1aXRlZA0KIGlzIG9uZSBJIGRv IG5vdCB1bmRlcnN0YW5kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSXQgaXMg aW1wcm9wZXIgZm9yIGFkaGVyZW5jZSB0byBvbmUgc2ltcGxlIHBhcnNlciBkZXNpZ24gdG8gY29u c3RyYWluIHByb3RvY29sIGRlc2lnbiBmb3Igc3VjaCBhIHdpZGUgY2xhc3Mgb2Ygcm91dGluZyBw cm9ibGVtcyBhcyBhcmUgcmVwcmVzZW50ZWQgYnkgYWQgaG9jIG5ldHdvcmtzLjxvOnA+PC9vOnA+ PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+U29ycnksIHlvdSBhcmUgd2VsbCBvdXQgb2YgbGluZSB0aGVy ZS4gVGhpcyB3YXMgYSBXRyBkZWNpc2lvbiwgc3BlY2lmaWVkIGluIFJGQyA1NDk4LiBBIGRvY3Vt ZW50DQogd3JpdHRlbiBieSB5b3VyIHRoZW4gRFlNTyBjby1hdXRob3IgSWFuIENoYWtlcmVzIChh bHNvIFdHIGNoYWlyKSBhbmQgYWdyZWVkIGJ5IHRoZSBXRy4gSXQgd2FzbuKAmXQgZm9pc3RlZCBv biB5b3UgYnkgdGhlIGF1dGhvcnMgLSBxdWl0ZSB0aGUgcmV2ZXJzZSwgd2UgaGFkIG1ha2luZyBp dCB3b3JrIGFzIGEgZ2VuZXJpYyBzcGVjaWZpY2F0aW9uIHB1dCBvbnRvIHVzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQXMgcHJhY3RpY2VkIHRvIGRhdGUsIFJGQyA1NDQ0IGhh cyBpbmhpYml0ZWQgdGhlIHVzZSBvZiBkZWZhdWx0IHZhbHVlcyBmb3Igc3lzdGVtIHBhcmFtZXRl cnMuJm5ic3A7Jm5ic3A7IEluIHRoZSBkb2N1bWVudCB0aGlzIGlzIGV4aGliaXRlZCBhcyBhIGZl YXR1cmUgd2hpY2ggaXMgZXJyb25lb3VzbHkgY2xhaW1lZCB0byBiZSByZXF1aXJlZCBmb3IgZnV0 dXJlIGV4dGVuc2liaWxpdHkuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRvbuKA mXQga25vdyB3aGF0IHlvdSBhcmUgdGFsa2luZyBhYm91dCBoZXJlLiBSRkMgNTQ0NCBpc27igJl0 IGNvbmNlcm5lZCB3aXRoIHN5c3RlbSBwYXJhbWV0ZXJzLiBXaGF04oCZcw0KIGNsYWltZWQgdG8g YmUgdXNlZnVsIGZvciBleHRlbnNpYmlsaXR5IGlzIHRoYXQgd2hpY2ggaXMgYWxyZWFkeSBleHBl cmllbmNlZCB0byBiZSB1c2VmdWwgZm9yIGV4dGVuc2liaWxpdHksIGFuZCBleGFtcGxlcyBnaXZl bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRoZSBkb2N1bWVudCByZXF1aXJl cyB0aGUgcHJvdG9jb2wgdG8ga25vdyBhYm91dCBNVFUgYnV0IGRpc2N1c3Npb24gb24gdGhlIGxp c3QgaW5oaWJpdHMgdGhlIHByb3RvY29sIGZyb20ga25vd2luZyBhYm91dCBNVFUuPG86cD48L286 cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FdmVuIGlmIHNvbWVvbmUgb24gdGhlIGxpc3Qgc2FpZCB0 aGF0IHRoZSBwcm90b2NvbCBpcyBpbmhpYml0ZWQgZnJvbSBrbm93aW5nIGFib3V0IE1UVSwgdGhh dOKAmXMgbm90DQogcmVsZXZhbnQuIERvZXMgdGhpcyBkb2N1bWVudCBzYXkgdGhhdD8gTm8uIEJ1 dCBJIGFsc28gZG9u4oCZdCByZWNhbGwgYW55b25lIHNheWluZyB0aGF0LiBBbnkgcHJvdG9jb2wg KG9yIGV2ZW4gbWFueSBhcHBsaWNhdGlvbnMpIHRoYXQgcnVuIGRpcmVjdGx5IG9yIGluZGlyZWN0 bHkgb3ZlciBJUCBuZWVkIHRvIGhhdmUgc29tZSBpZGVhIGFib3V0IE1UVSwgcG9zc2libHkgd2l0 aCBydWxlcyBvZiB0aHVtYiBhcyB0byBob3cgbXVjaCB0byBzdWJ0cmFjdA0KIGR1ZSB0byBleHBl Y3RlZCBoZWFkZXJzLiBUaGlzIGlzIG5vIGRpZmZlcmVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMx RjQ5N0Q7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUg ZG9jdW1lbnQgZGlzYWxsb3dzIHRoZSBwcm90b2NvbCBmcm9tIHNwZWNpZnlpbmcgY3J1Y2lhbCBw YXJhbWV0ZXJzIHN1Y2ggYXMgdGltZSBhbGxvd2FibGUgZm9yJm5ic3A7IGFnZ3JlZ2F0aW9uIG9m IGNvbnRyb2wgbWVzc2FnZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhhdCBpcyBleGFjdGx5IGJhY2t3YXJkcy4gRnJvbSBTZWN0aW9uIDQuMjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25l Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBUaGUgbXVs dGlwbGV4ZXIgTUFZIGRlbGF5IG1lc3NhZ2VzIGJyaWVmbHkgaW4gb3JkZXIgdG8gYXNzZW1ibGU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1h dXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IG1vcmUgZWZmaWNpZW50IHBhY2tldHMuJm5ic3A7IEl0IFNIT1VMRCBy ZXNwZWN0IGFueSBjb25zdHJhaW50cyBvbiBzdWNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWxheXMgcmVx dWVzdGVkIGJ5IHRoZSBwcm90b2NvbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J ZiB5b3Ugd2FudCB0byBhcmd1ZSB0aGF0IHRoZSBTSE9VTEQgb3VnaHQgdG8gYmUgYSBNVVNUIHRo ZW4gZmluZSwgSeKAmWQgaGF2ZSBzb21lIHN5bXBhdGh5IHdpdGggdGhhdCwNCiBidXQgd2Ugd2Vy ZSB0cnlpbmcgbm90IHRvIG92ZXJseSBjb25zdHJhaW4uIEJ1dCB0aGF0IHRoZSBwcm90b2NvbCBj YW4gaW5mb3JtIHRoZSBtdWx0aXBsZXhlciBpcyBjbGVhcmx5IHRoZXJlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQWRkcmVzc2VzIGFyZSBwcmVzdW1lZCB0byBiZSBpbmNsdWRl ZCBpbiBhIG1lc3NhZ2UgZm9yIG5vIHBhcnRpY3VsYXIgcmVhc29uIHVubGVzcyBkZXNjcmliZWQg YnkgeWV0IGFub3RoZXIgYWRkcmVzcyBUTFYuJm5ic3A7IFRoaXMgaW5jcmVhc2VzIG1lc3NhZ2Ug c2l6ZSBvbiB0aGUgc3BlY3VsYXRpb24gdGhhdCB0aGUgcHJvdG9jb2wgd2lsbCB3YW50IHRvIGJl IHVzZWQgd2l0aCBvdGhlciB1bnJlbGF0ZWQgcHJvdG9jb2xzIGluIHRoZSBmdXR1cmUuJm5ic3A7 IEluDQogbm9ybWFsIHByb3RvY29sIGRlc2lnbiwgYWRkcmVzc2VzIGFyZSBwdXQgaW50byBhIG1l c3NhZ2UgZm9yIHJlYXNvbnMgdGhhdCBhcmUgc3BlY2lmaWMgdG8gdGhlIG1lc3NhZ2UuPG86cD48 L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMsIHRoaXMgaXMgYSBkZXNpZ24gZmVhdHVyZSB0 aGF0IGlzIGhpZ2hseSBkZXNpcmFibGUgZm9yIGV4dGVuc2liaWxpdHkuIFRoYXTigJlzIHRoZSBl eHBlcmllbmNlIG9mDQogYSBsb3Qgb2YgdGltZSB3b3JraW5nIHdpdGggYSBwcm90b2NvbCAoT0xT Uikgd2l0aG91dCB0aGF0LCBhbmQgdGhpcy4gSSBjYW4gYWxyZWFkeSBzZWUgaG93IHBvc3NpYmxl IGV4dGVuc2lvbnMgdG8gQU9EVnYyIGNvdWxkIHVzZSB0aGlzIGZyZWVkb20uIFdoaWxlIGJ5dGVz IGRvIG1hdHRlciwgc28gZG9lcyBleHRlbnNpYmlsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkZyYW5rbHksIHdoYXQgcHJvdG9jb2xzIG5lZWQgaXMgdG8gZ28gaW4gb25lIGRp cmVjdGlvbiBvciB0aGUgb3RoZXIuIE9uZSBkaXJlY3Rpb24gaXMgYSB0aWdodGx5IG9wdGltaXNl ZA0KIHVsdHJhLWNvbXBhY3QgbWVzc2FnZSBmb3IgdmVyeSBzcGVjaWZpYyB1c2UsIGluIHBhcnRp Y3VsYXIgZm9yIHN5c3RlbXMgYmFzZWQgb24gbWljcm9jb250cm9sbGVycyBhbmQgdmVyeSBjb25z dHJhaW5lZCB3aXJlbGVzcyBsaW5rcy4gSXTigJlzIHF1aXRlIG9wZW4gdG8geW91IHRvIGNyZWF0 ZSBhIHNlcGFyYXRlIG1lc3NhZ2Ugc3RydWN0dXJlIGZvciB0aGF0LiBZb3XigJlyZSBhbHJlYWR5 IHBhcnQgd2F5IHRoZXJlIHdpdGggZmlyc3Qgc3BlY2lmeWluZw0KIHdoYXTigJlzIGluIGEgbWVz c2FnZSwgdGhlbiBob3cgdGhhdOKAmXMgcmVwcmVzZW50ZWQgaW4gUkZDIDU0NDQuIEluIGFuIGlk ZWFsIHdvcmxkIHdl4oCZZCBoYXZlIGRvbmUgdGhlIHNhbWUgZm9yIE9MU1J2Mi4gVGhlIG90aGVy IGRpcmVjdGlvbiwgd2hpbGUgbm90IG9ibGl2aW91cyB0byBlZmZpY2llbmN5IGNvbmNlcm5zLCBp cyBwcmVwYXJlZCB0byBhZGQgYSBmZXcgb2N0ZXRzIChhbmQgd2UgYXJlIHRhbGtpbmcgYSBsb3cg c2luZ2xlIGZpZ3VyZSBudW1iZXIpDQogdG8gYWxsb3cgZXh0ZW5zaWJpbGl0eS4gRXZlbiB0aGUg YXV0aG9ycyBtaXNzZWQgc29tZSBleHRlbnNpYmlsaXR5IG9wdGlvbnMgYmFjayBpbiBlYXJsaWVy IGRheXMsIHdob2V2ZXIgaXQgd2FzIHRoYXQgaW5zaXN0ZWQgb24gYSBwZXItbWVzc2FnZSBhZGRy ZXNzIGxlbmd0aCwgcmF0aGVyIHRoYW4gaW5oZXJpdGluZyBmcm9tIHdoYXRldmVyIElQIHN0YWNr IHlvdSB3ZXJlIHJ1bm5pbmcgb24sIHdhcyByaWdodC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5BbiBhcHBlbmRpeCAob3IgcHJvYmFibHkgaW4gbGlnaHQgb2YgdGltZXNjYWxlcykg c2VwYXJhdGUgZHJhZnQgb24gYW4gdWx0cmEtY29tcGFjdCByZXByZXNlbnRhdGlvbg0KIG9mIEFP RFZ2MiwgZXhwbGljaXRseSBub3QgaW50ZW5kZWQgdG8gYmUgZXh0ZW5zaWJsZSwgd291bGQgYmUg aW50ZXJlc3RpbmcsIGFuZCBtaWdodCBmaW5kIHNvbWUgYXBwbGljYXRpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0OyA8L3NwYW4+DQpPbiBhdmVyYWdl LCB0aGUgZGVzaWduIG9mIHRoZSBtdWx0aXBsZXhlciBpcyBwcmVzdW1lZCB0byBiZSB0aGUgaGln aGVzdCBwcmlvcml0eSBhbmQgdGhlIGRlc2lnbiBvZiB0aGUgcm91dGluZyBwcm90b2NvbCBhIGRp c3RpbmN0bHkgbGVzcyBpbXBvcnRhbnQgbWF0dGVyLiZuYnNwOyBNb3Jlb3ZlciwgdGhlIG11bHRp cGxleGVyIGRlc2lnbiBpcyBzdWJzZXJ2aWVudCB0byB3aGF0ZXZlciBpcyBlYXNpZXN0IGZvciB0 aGUgY29udGFpbmVyIGRlc2lnbmVycyB0bw0KIHBhcnNlLiZuYnNwOyBUaGlzIGlzIHB1dHRpbmcg dGhlIGNhcnQgYmVmb3JlIHRoZSBob3JzZS48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhlIG11bHRpcGxleGVyIGlzIGluIHBsYWNlLCB0aGF04oCZcyBSRkMgNTQ5OC4gVGhpcyBpc27i gJl0IG5ldy4gVGhlIGhvcnNlIGlzIGFscmVhZHkgaW4gZnJvbnQgb2YgdGhlIGNhcnQuPC9zcGFu Pjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7IDwvc3Bhbj5JIHdp bGwgdHJ5IHRvIGZpbmlzaCByZWFkaW5nIHRoZSBkcmFmdCBzb29uLCBidXQgSSB0aGluayB0aGF0 IExhc3QgQ2FsbCBmb3IgdGhpcyBkb2N1bWVudCBpcyBwcmVtYXR1cmUgYXQgYmVzdC4mbmJzcDsg SSB3b3VsZCBzdHJvbmdseSBzdWdnZXN0IHRoYXQgaXQgYmUgZGVsYXllZCB1bnRpbCB0aGUgY3Vy cmVudCB0d28gbWFqb3IgW21hbmV0XSBpdGVtcyBjYW4gYmUgZmluaXNoZWQuPHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYXTigJlzIGNvbXBsZXRlbHkgdW5hY2NlcHRhYmxlLiBXaG8g a25vd3MgaG93IGxvbmcgeW91IGFyZSBnb2luZyB0byBjb250aW51ZSB0byB3b3JrIG9uIEFPRFZ2 MiBvdXQgb2Ygc2lnaHQgb2YgdGhpcyBXRy4gQW5kIHRoaXMNCiByZWFsbHkgaXMgdGhlIGNhcnQg YmVmb3JlIHRoZSBob3JzZS4gWW91ciBjby1hdXRob3JzIG9mIEFPRFZ2MiByZXF1ZXN0ZWQgZnVy dGhlciBjbGFyaWZpY2F0aW9uIG9mIFJGQyA1NDQ0LCBhbmQgd2UgcHV0IGluIHRoZSB3b3JrIHRv IGRvIHRoYXQuIENsYXJpZnlpbmcgdGhlIGJhc2UgYmVmb3JlIGJ1aWxkaW5nIG9uIGl0IGlzIHRo ZSByaWdodCBvcmRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5BbHNvLCB3aHkgdHdvIFdHIGRvY3VtZW50cz8gVGhlIG9ubHkgb3Ro ZXIgc2lnbmlmaWNhbnQgZG9jdW1lbnQgaXMgRExFUCwgd2hpY2ggaXMgYm90aCBpbmRlcGVuZGVu dCBvZiB0aGlzIChpdCBkb2VzbuKAmXQgdXNlIDU0NDQNCiAtIGFuZCB0aGF04oCZcyBiZWNhdXNl IGl04oCZcyBub3QgYSBNQU5FVCByb3V0aW5nIHByb3RvY29sKSBhbmQgYWxyZWFkeSBvdXQgb2Yg dGhlIGdhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cD4qKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKjxicj4KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRp YWwgdG8gdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVn ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IHBsZWFzZSBkZWxl dGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPgpZb3Ugc2hv dWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9y PGJyPgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4KKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKio8L3A+PC9ib2R5Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ACE98GLKXM0002VGREEN_-- From nobody Fri Apr 15 07:19: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 5C6C312D110 for ; Fri, 15 Apr 2016 07:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 FtuQ27NX8SgA for ; Fri, 15 Apr 2016 07:19:01 -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 6AC0C12D6A1 for ; Fri, 15 Apr 2016 07:19:01 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1ar4aJ-001huS-Oj>; Fri, 15 Apr 2016 16:18:59 +0200 Received: from ext176.non-member.tu-haburg.de ([195.37.187.176] helo=[172.16.19.135]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id <1ar4aJ-0045dy-Bi>; Fri, 15 Apr 2016 16:18:59 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_3079EDD6-B4C3-44D4-9EA9-6D7B87525D9C" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Lotte Steenbrink In-Reply-To: Date: Fri, 15 Apr 2016 16:18:58 +0200 Message-Id: References: To: "manet@ietf.org" X-Mailer: Apple Mail (2.3112) X-Originating-IP: 195.37.187.176 X-ZEDAT-Hint: A Archived-At: Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 15 Apr 2016 14:19:06 -0000 --Apple-Mail=_3079EDD6-B4C3-44D4-9EA9-6D7B87525D9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, sparked by the recently started WGLC, I=E2=80=99ve reviewed the current = revision of the draft. I=E2=80=99d like to offer the working group my = perspective as someone who doesn=E2=80=99t have decades of protocol = and/or packet format design under their belt (i.e. some things might not = be obvious to me that are obvious to others), but also as someone who = has worked with RFC 5444 when implementing a routing protocol (AODVv2), = updating the packet format of a routing protocol (AODVv2 again) and = (partially) implementing my own RFC5444 builder/parser. Overall, I think the document is easy to read and follow. To me, it = contains valuable information and guidance and in some cases prevents = people from shooting themselves in the foot. I=E2=80=99m really happy this document exists and I=E2=80=99d like it to = move forward soon, but I do feel that it is still lacking in some areas, = which is why I was a bit surprised to see it go to Last Call all of a = sudden. First, some nitpicks and comments: * from 1.2.1 = . Packet/Message Format: [=E2=80=A6] a packet transmission following a successful packet reception is by design of a new packet that may include all, some, or none of the received messages [...] I=E2=80=99m not a native speaker, but that =E2=80=9Eof=E2=80=9C seems = out of place... * Regarding 4.2 = . Packets and Messages: this section talks a lot about how the multiplexer operates, so I think = it=E2=80=99d be helpful if its title reflected that.=20 * from 4.4 = . Addresses Require Attributes: An unmodified extension to NHDP would ignore such addresses, as required, as it does not support that specialized purpose. At first glance, (to me) this reads as =E2=80=9EAll addresses that are = associated with an unknown TLV are ignored=E2=80=9C, which is obviously = nonsense (but quite panic-inducing :D). I=E2=80=99d propose to reword it = to something along the lines of=20 An unmodified extension to NHDP would not consider this address to be of a neighbor, as it is lacking a LINK_STATUS or OTHER_NEIGHB TLV. Also, I don=E2=80=99t quite get where you=E2=80=99re going with the last = paragraph of that section (=E2=80=9CThese restrictions do not, however, = mean that added information is completely ignored for purposes of the base protocol.=E2=80=9D)... * regarding the maps in 4.5 = . Information Representation: I=E2=80=99m afraid I just don=E2=80=99t really understand the purpose of = this section and the mapping notation. I=E2=80=99m assuming that the = maps are supposed to offer a way of describing how a TLV relates to a = message or an address?=20 If so, why does it only mention extension types, but not the basis = types? Or is it supposed to be used something like this: BASE_TLV Message:=20 (base_tlv_extension_type_1) -> (2 octets, "value a when condition x is = met") (base_tlv_extension_type_2) -> (2 octets, "value b when condition y is = met") ? Also, I don=E2=80=99t quite get how this would be used in future = protocol specifications? Or aid in implementing RFC5444 parsers? An example or a clarification would be very helpful. * regarding 4.6 = . TLVs: In general, it=E2=80=99s not clear everywhere in the section whether = you=E2=80=99re talking to RFC5444 parser/builder implementors or = protocol designers.=20 A protocol SHOULD use an efficient representation, but this is a quality of implementation issue. I=E2=80=99m not sure where you=E2=80=99re going with the last part of = that sentence? I=E2=80=99d reword it to something like =E2=80=9EA = protocol SHOULD use an efficient representation, avoiding unnecessarily = verbose use of TLVs and extension types. However, the final arrangement = in a message- or addressTLV block is a quality of implementation = issue=E2=80=9C (in case that=E2=80=99s what you meant). And then: A protocol MUST recognize any permitted representation of the information; even if it chooses to (for example) only use multivalue TLVs, it MUST recognize single value TLVs (and vice versa). =E2=80=A6 I thought protocols weren=E2=80=99t supposed to specify = whether a TLV is arranged (for example) as a multivalue TLV?! And so, = since a protocol shouldn't be concerned with multivalue TLVs and the = like, wouldn=E2=80=99t it be the *RFC5444 implementation* that MUST = recognize any permitted representation? Or is this paragraph really just = a complicated way of saying =E2=80=9Eas a protocol designer, make sure = to not specify/rely on things like (for example) multivalue TLVs, since = your messages have to work with *any* representation=E2=80=9C? If so, I = think that should be done in a less complicated fashion (see below). * regarding 5 = .= Structure: Since this section talks a lot about flags, it=E2=80=99d be nice if its = title represented that. Maybe consider renaming it to =E2=80=9EStructure = and Flags=E2=80=9C or so? * from 6.1 = . Address Block Compression: Compression of addresses in an Address Block considers addresses to consist of a Head, a Mid, and a Tail, where all addresses in an Address Block have the same Head and Tail, but different Mids. I=E2=80=99d find this sentence easier to read if it started with = =E2=80=9CCompression of addresses in an Address Block is possible when = addresses consist of a Head, a Mid [=E2=80=A6]=E2=80=9D. * from 6.1 = . Address Block Compression: Putting addresses into a message efficiently also has to include: Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that would be a = =E2=80=9Emay=E2=80=9C. Multiple Adress Blocks and/or reordering don=E2=80=99= t increase efficiency in all possible cases... * from 6.2 = . TLVs: [...] This is even possible if the MPR TLV specified in OLSRv2 [RFC7181 ] is added; = but it is not possible, in general, if the LINK_METRIC TLV is also added. Why is it not possible for the latter? If that could be explained/hinted = at in a half sentence, I think it=E2=80=99d be helpful information to = have in the draft. In a typical case where a LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with enough addresses, sorted appropriately, two single value TLVs can be more efficient than one multivalue TLV. Same thing: why? * regarding the second paragraph from 6.3 = . TLV Values, i.e. =20 This approach was specified in [RFC7188 = ], and required for protocols that extend [RFC6130 ] and = [RFC7181 ]. It is here RECOMMENDED = that this approach is followed when defining any Address Block TLV that may be used by a protocol using [RFC5444 = ]. The term =E2=80=9Ethis approach=E2=80=9C confused me, since I initially = thought it meant =E2=80=9Ethe approach is to use UNSPECIFIED in a way = that makes sense=E2=80=9C rather than =E2=80=9Ethe approach is to use = UNSPECIFIED=E2=80=9C. Maybe that could be reworded to something along = the lines of=20 The UNSPECIFIED TLV and its usage was specified in [RFC7188]=E2=80=A6=20 ? * regarding 6.3 = . TLV Values: The second paragraph is a bit confusing and seems to explaing roghly the = same things as the fourth paragraphs. I=E2=80=99d propose to merge the = second into the fourth. * from 6.4 = . Automation: The possible gain depends on the efficiency of the original message creation, the term =E2=80=9Ethe original message creation=E2=80=9C seems a bit = ambiguous=E2=80=93 does this refer to the message as created by an = RFC5444 message builder implementation? Additionally, I'm concerned about two things that *aren=E2=80=99t* in = the draft: * Some of the AODVv2 co-authors and me have asked for a list of =E2=80=9E= as a protocol, you can set all of these fields of a message, but please = leave the rest alone=E2=80=9C, which would=E2=80=99ve saved us many = hours of discussions (and Henning a lot of time spent explaining these = things=E2=80=A6). These requests have been met with a refusal to specify = a concrete API, as such an effort is dependent on outside factors such = as programming language or software architecture. I agree with this = notion, but a programming-language dependent API is not what we=E2=80=99ve= asked for. I=E2=80=99ve tried to supply a sketch of what I did ask for = in [1], but unfortunately I didn=E2=80=99t get an answer (and as far as = I can see it, the draft wasn=E2=80=99t changed either). I still think = that such a list, in whatever form, would be very helpful for future = Internet-Draft authors and I also think this request is in accordance = with the intentions stated in 1.1 History and Purpose, and I think it = should be included in the document. =20 * As the exact rules for using/setting the hop count & hop-limit fields = are currently being discussed w/ regard to AODVv2 in another thread = [2]=E2=80=93 should a definitive answer to that question be part of = 5444-usage? Best regards, Lotte [1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.html = [2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.html=20 > Am 06.04.2016 um 19:14 schrieb Justin Dean : >=20 > The chairs agree that a 3 week WGLC is appropriate. Everyone please = read the draft early and get comments in early so that they can be = addressed within the last call period. >=20 > Justin >=20 > On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) = > = wrote: > Obviously +1 to the request for WGLC. >=20 > With regard to what's changed, technically the only significant thing = is to make it clear that if a protocol delivers a message to the = multiplexer, the multiplexer must pass it on unchanged to the protocol = (another instance of, at another router) unchanged. Without that nothing = that the protocol itself chooses to do with regard to security makes = sense. Though the protocol can alternatively let the multiplexer do the = security, 7182 can be implemented in either way. This isn't really new, = but it wasn't formally spelled out. It's presented as part of spelling = out multiplexer rules more carefully. >=20 > But what about message optimisation? That's a function of constructing = a 5444 message, not the multiplexer, and is down to that 5444 includes = two things - packet/message structure (and implicitly, and in pretty = much any implementation I would expect to see, a parser and builder for = that structure) and the multiplexer. So we took the opportunity to = separate out more clearly a discussion of the two, which we think will = be helpful. >=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 > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org = ] On Behalf Of Ulrich Herberg > Sent: 05 April 2016 20:08 > To: manet@ietf.org > Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 >=20 > ----------------------! WARNING ! ---------------------- This message = originates from outside our organisation, either from an external = partner or from the internet. > Consider carefully whether you should click on any links, open any = attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for = instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > *** WARNING *** > EXTERNAL EMAIL -- This message originates from outside our = organization. >=20 >=20 > Hi, >=20 > As you have seen, we have submitted a new revision of 5444-usage. The = authors feel comfortable that we have addressed all issues by this = version, and would like to ask the WG chairs to issue a WGLC on this = document. While it is a fairly short document, given that it is IETF = week for some, we'd suggest that a 3-4 week WGLC would be appropriate. >=20 > Best regards > Ulrich >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet = >=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 = >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_3079EDD6-B4C3-44D4-9EA9-6D7B87525D9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

sparked = by the recently started WGLC, I=E2=80=99ve reviewed the current revision = of the draft. I=E2=80=99d like to offer the working group my perspective = as someone who doesn=E2=80=99t have decades of protocol and/or packet = format design under their belt (i.e. some things might not be obvious to = me that are obvious to others), but also as someone who has worked with = RFC 5444 when implementing a routing protocol (AODVv2), updating the = packet format of a routing protocol (AODVv2 again) and (partially) = implementing my own RFC5444 builder/parser.

Overall, I think the document is easy = to read and follow. To me, it contains valuable information and guidance = and in some cases prevents people from shooting themselves in the = foot.
I=E2=80=99m really happy this document exists = and I=E2=80=99d like it to move forward soon, but I do feel that it is = still lacking in some areas, which is why I was a bit surprised to see = it go to Last Call all of a sudden.

First, some nitpicks and = comments:

* = from 1.2.1. Packet/Message Format:

      [=E2=80=A6] a packet
      transmission =
following a successful packet reception is by design
      of a new packet that may include all, some, or none of the
      received messages [...]

I=E2=80=99m not a native = speaker, but that =E2=80=9Eof=E2=80=9C seems out of = place...

*= Regarding 4.2. Packets and Messages:
this section talks a lot about how the multiplexer operates, = so I think it=E2=80=99d be helpful if its title reflected = that. 

* = from 4.4. Addresses Require = Attributes:

   An unmodified =
extension to NHDP would ignore such addresses,
   as required, as it does not support that specialized =
purpose.

At first glance, (to me) this reads as =E2=80=9EAll addresses = that are associated with an unknown TLV are ignored=E2=80=9C, which is = obviously nonsense (but quite panic-inducing :D). I=E2=80=99d propose to = reword it to something along the lines of 
   An unmodified =
extension to NHDP would not consider this
   address to be of a neighbor, as it is =
lacking a LINK_STATUS
  =
 or OTHER_NEIGHB TLV.

Also, I = don=E2=80=99t quite = get where you=E2=80=99re= going with the last paragraph of that section (=E2=80=9CThese restrictions do not, = however, mean that added information is
   completely ignored for purposes of the =
base protocol.=E2=80=9D)...

* regarding the maps in 4.5. Information = Representation:
I=E2=80=99m afraid I just = don=E2=80=99t really understand the purpose of this section and the = mapping notation. I=E2=80=99m assuming that the maps are supposed to = offer a way of describing how a TLV relates to a message or an = address? 
If so, why does it only mention = extension types, but not the basis types? Or is it supposed to be used = something like this:

BASE_TLV

Message: 
(base_tlv_extension_type_1) = -> (2 octets, "value a when condition x is met")
(base_tlv_extension_type_2) = -> (2 octets, "value b when condition y is met")

? Also, I don=E2=80=99t = quite get how this would be used in future protocol specifications? Or = aid in implementing RFC5444 parsers?
An example or = a clarification would be very helpful.

* regarding 4.6. TLVs:
In general, it=E2=80=99s not clear everywhere in the = section whether you=E2=80=99re talking to RFC5444 parser/builder implementors or protocol = designers. 

   A protocol =
SHOULD use an efficient
   representation, but this is a quality of implementation =
issue.

I=E2=80=99= m not sure where you=E2=80=99re going with the last part of that = sentence? I=E2=80=99d reword it to something like =E2=80=9EA protocol = SHOULD use an efficient representation, avoiding unnecessarily verbose = use of TLVs and extension types. However, the final arrangement in a = message- or addressTLV block is  a quality of implementation = issue=E2=80=9C (in case that=E2=80=99s what you meant).

And then:

   A
   protocol MUST recognize any permitted representation of the
   information; even if it chooses to (for example) only use multivalue
   TLVs, it MUST recognize single value TLVs (and vice versa).

=E2=80=A6 I thought = protocols weren=E2=80=99t supposed to specify whether a TLV is arranged = (for example) as a multivalue TLV?! And so, since a protocol shouldn't = be concerned with multivalue TLVs and the like, wouldn=E2=80=99t it be = the *RFC5444 implementation* that MUST recognize any permitted = representation? Or is this paragraph really just a complicated way of = saying =E2=80=9Eas a protocol designer, make sure to not specify/rely on = things like (for example) multivalue TLVs, since your messages have to = work with *any* representation=E2=80=9C? If so, I think that should be = done in a less complicated fashion (see below).

* regarding 5. Structure:
Since this section talks a lot = about flags, it=E2=80=99d be nice if its title represented that. Maybe consider = renaming it to =E2=80=9EStructure and Flags=E2=80=9C or so?

* from 6.1. Address Block = Compression:

   Compression of =
addresses in an Address Block considers addresses to
   consist of a Head, a Mid, and a Tail, where all addresses in an
   Address Block have the same Head and Tail, but different =
Mids.


I=E2=80=99d find this sentence easier = to read if it started with =E2=80=9CCompression of addresses in an = Address Block is possible when addresses consist of a Head, a Mid = [=E2=80=A6]=E2=80=9D.

* from 6.1. Address Block = Compression:

   Putting addresses into a message =
efficiently also has to include:

Why= =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that would be a =E2=80=9Emay=E2= =80=9C. Multiple Adress Blocks and/or reordering don=E2=80=99t increase = efficiency in all possible cases...

* from 6.2. TLVs:
      [...] This is even =
possible if the MPR TLV specified in
      OLSRv2 [RFC7181] is added; but it is not possible, in =
general, if

      the LINK_METRIC =
TLV is also added.

Why is it not possible for the latter? If that could be = explained/hinted at in a half sentence, I think it=E2=80=99d be helpful = information to have in the draft.

      In a typical case where a
      LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with
      enough addresses, sorted appropriately, two single value TLVs can
      be more efficient than one multivalue TLV.

Same thing: why?

* regarding the second = paragraph from 6.3. TLV Values, i.e.
   
   This approach was =
specified in [RFC7188], and required for protocols
   that extend [RFC6130] and [RFC7181].  It is here RECOMMENDED that
   this approach is followed when defining any Address Block TLV that
   may be used by a protocol using [RFC5444].

The term =E2=80=9Ethis approach=E2=80=9C = confused me, since I initially  thought it meant =E2=80=9Ethe = approach is to use UNSPECIFIED in a way that makes sense=E2=80=9C rather = than =E2=80=9Ethe approach is to use UNSPECIFIED=E2=80=9C. Maybe that = could be reworded to something along the lines of 
The UNSPECIFIED TLV and its = usage was specified in [RFC7188]=E2=80=A6 
?

* = regarding 6.3. TLV Values:
The second = paragraph is a bit confusing and seems to explaing roghly the same = things as the fourth paragraphs. I=E2=80=99d propose to merge the second into = the fourth.

* from 6.4. Automation:

   The possible gain =
depends on the efficiency
   of the original message creation,

the term =E2=80=9Ethe original = message creation=E2=80=9C seems a bit ambiguous=E2=80=93 does this refer = to the message as created by an RFC5444 message builder = implementation?

Additionally, I'm concerned about two things that *aren=E2=80=99= t* in the draft:

*  Some of the AODVv2 co-authors and me have asked for a = list of =E2=80=9Eas a protocol, you can set all of these fields of a = message, but please leave the rest alone=E2=80=9C, which would=E2=80=99ve = saved us many hours of discussions (and Henning a lot of time spent = explaining these things=E2=80=A6). These requests have been met with a = refusal to specify a concrete API, as such an effort is dependent on = outside factors such as programming language or software architecture. I = agree with this notion, but a programming-language dependent API is not = what we=E2=80=99ve asked for. I=E2=80=99ve tried to supply a sketch of = what I did ask for in [1], but unfortunately I didn=E2=80=99t get an = answer (and as far as I can see it, the draft wasn=E2=80=99t changed = either). I still think that such a list, in whatever form, would be very = helpful for future Internet-Draft authors and I also think this request = is in accordance with the intentions stated in 1.1 History and Purpose, and I think it should = be included in the document.  

* As the exact rules for using/setting the hop count & = hop-limit fields are currently being discussed w/ regard to AODVv2 in = another thread [2]=E2=80=93 should a definitive answer to that question = be part of 5444-usage?


Best regards,
Lotte

[1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.ht= ml
[2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.ht= ml 


Am 06.04.2016 um 19:14 schrieb Justin Dean = <bebemaster@gmail.com>:

The chairs agree that a 3 week WGLC is appropriate.  = Everyone please read the draft early and get comments in early so that = they can be addressed within the last call period.

Justin

On Wed, = Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> = wrote:
Obviously +1 to = the request for WGLC.

With regard to what's changed, technically the only significant thing is = to make it clear that if a protocol delivers a message to the = multiplexer, the multiplexer must pass it on unchanged to the protocol = (another instance of, at another router) unchanged. Without that nothing = that the protocol itself chooses to do with regard to security makes = sense. Though the protocol can alternatively let the multiplexer do the = security, 7182 can be implemented in either way. This isn't really new, = but it wasn't formally spelled out. It's presented as part of spelling = out multiplexer rules more carefully.

But what about message optimisation? That's a function of constructing a = 5444 message, not the multiplexer, and is down to that 5444 includes two = things - packet/message structure (and implicitly, and in pretty much = any implementation I would expect to see, a parser and builder for that = structure) and the multiplexer. So we took the opportunity to separate = out more clearly a discussion of the two, which we think will be = helpful.

--
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

-----Original Message-----
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg
Sent: 05 April 2016 20:08
To: manet@ietf.org
Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

----------------------! WARNING ! ---------------------- This message = originates from outside our organisation, either from an external = partner or from the internet.
Consider carefully whether you should click on any links, open any = attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for = instructions on reporting suspicious email messages.
--------------------------------------------------------

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


Hi,

As you have seen, we have submitted a new revision of 5444-usage. The = authors feel comfortable that we have addressed all issues by this = version, and would like to ask the WG chairs to issue a WGLC on this = document. While it is a fairly short document, given that it is IETF = week for some, we'd suggest that a 3-4 week WGLC would be = appropriate.

Best regards
Ulrich

_______________________________________________
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

= --Apple-Mail=_3079EDD6-B4C3-44D4-9EA9-6D7B87525D9C-- From nobody Fri Apr 15 10:50: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 B69AF12DAD3 for ; Fri, 15 Apr 2016 10:50:05 -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 qerH38SgpPkx for ; Fri, 15 Apr 2016 10:50:03 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 6ECA112DA8C for ; Fri, 15 Apr 2016 10:50:02 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id y144so8007402wmd.0 for ; Fri, 15 Apr 2016 10:50:02 -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=x4hD4my0uobpjbnNFRGcBQ7xyNFkI8GO4Nq1Tfev0lM=; b=AeHa0HzlCHQYSx7Onkq//X9DRjRyrzwd6cbhlkRDTGJxhcGAoaV46ZxtL/2BGydq2A ZqLU5DJQGWp1yni8gF8QeD98ZYp0oMC8Y/2NKkZ40mi7RqYIfG26seB0nSDmkscb1yPJ +0hJECeTkQjqjeYL7n0zFeFj5iPUNTSYozrY/SG17H5Ude+Wf4STFPM53ioPG9A+ZMGk X9jzRQGNh0KAHGUVbtHFcW6+qRX6hv/ElGUMyRkNMlb2ejIhiALszciYTgrXFijgry5b o9pRcb6d72cKlY+2saIh2dqj6n4Xi/ubDOEKT9d5a2yhtLoNzoaujwKcdX0444MzjrIp IIng== 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=x4hD4my0uobpjbnNFRGcBQ7xyNFkI8GO4Nq1Tfev0lM=; b=FUy/leex8xV2rp3Zt1nD+qObh2NOjqxml8IHtozOv1H9qNSr7+SY2J9yVXXoOzoYgU r7I2+3VGxhIxjjWz0H8Q6dupKoxUriU0PP+KZKr6w/0ryY9kKWduwb7RNepK672kNhyE YSPZX5a3UTOK1Tj19u9q4nRsEB0sY1n5HCNFVhqhKu54d0RpwtZe3rNzeMK4Dbd2CVuk S26fy924hJj87a1Xb6MVolReGkGBGTa+89ixck35T9xc/Er/gsei7HpCqSWZPZBxNbQy 6qK4/8BTF9IYr+hfVwhE0/4w5O35Hcj59JBKAz+oXg6wDNEdBzB9C9F8bukO7/qfDkg3 ZWtg== X-Gm-Message-State: AOPr4FU6pJ8UZlRz6PpF0S8LORLJc8P5FQL47cG85uAKQ/r1mdIQC1NXUWU4nQ6CONOQ+g== X-Received: by 10.194.16.8 with SMTP id b8mr22898264wjd.51.1460742600937; Fri, 15 Apr 2016 10:50:00 -0700 (PDT) Received: from [10.2.93.92] (dab-hlw1-w-1-3.dab.02.net. [82.132.232.9]) by smtp.gmail.com with ESMTPSA id i201sm12609672wmf.23.2016.04.15.10.49.59 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2016 10:49:59 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-F9675B70-9302-48D1-BE79-D0F3F4E71308 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (13E238) From: Christopher Dearlove Date: Fri, 15 Apr 2016 18:49:54 +0100 To: Lotte Steenbrink Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 15 Apr 2016 17:50:05 -0000 --Apple-Mail-F9675B70-9302-48D1-BE79-D0F3F4E71308 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A few immediate comments inline below. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 15 Apr 2016, at 15:18, Lotte Steenbrink = wrote: >=20 > Hi all, >=20 > sparked by the recently started WGLC, I=E2=80=99ve reviewed the current re= vision of the draft. I=E2=80=99d like to offer the working group my perspect= ive as someone who doesn=E2=80=99t have decades of protocol and/or packet fo= rmat design under their belt (i.e. some things might not be obvious to me th= at are obvious to others), but also as someone who has worked with RFC 5444 w= hen implementing a routing protocol (AODVv2), updating the packet format of a= routing protocol (AODVv2 again) and (partially) implementing my own RFC5444= builder/parser. >=20 > Overall, I think the document is easy to read and follow. To me, it contai= ns valuable information and guidance and in some cases prevents people from s= hooting themselves in the foot. > I=E2=80=99m really happy this document exists and I=E2=80=99d like it to m= ove forward soon, but I do feel that it is still lacking in some areas, whic= h is why I was a bit surprised to see it go to Last Call all of a sudden. Not really. The authors had said what they intended to say, no one was comme= nting, time for WGLC. > First, some nitpicks and comments: >=20 > * from 1.2.1. Packet/Message Format: >=20 > [=E2=80=A6] a packet > transmission following a successful packet reception is by design > of a new packet that may include all, some, or none of the > received messages [...] >=20 > I=E2=80=99m not a native speaker, but that =E2=80=9Eof=E2=80=9C seems out o= f place... I am a native speaker, and no, it's not. Some would repeat it after each of a= ll, some and none, and I might sometimes. But it really doesn't matter which= of the two styles we pick, the RFC Editor may well change to the other. > * Regarding 4.2. Packets and Messages: > this section talks a lot about how the multiplexer operates, so I think it= =E2=80=99d be helpful if its title reflected that.=20 I'm of two opinions on that. On the one hand it is, as its title suggests, a= bout the packet and message level, as opposed to lower levels, and its title= contrasts with that if 4.3 for that reason. On the other hand you are right= , it does have much about the multiplexer. A title covering all three woukd s= tart getting cumbersome. Will take this one away to think about. > * from 4.4. Addresses Require Attributes: >=20 > An unmodified extension to NHDP would ignore such addresses, > as required, as it does not support that specialized purpose. >=20 > At first glance, (to me) this reads as =E2=80=9EAll addresses that are ass= ociated with an unknown TLV are ignored=E2=80=9C, which is obviously nonsens= e (but quite panic-inducing :D). I=E2=80=99d propose to reword it to somethi= ng along the lines of=20 > An unmodified extension to NHDP would not consider this > address to be of a neighbor, as it is lacking a LINK_STATUS > or OTHER_NEIGHB TLV. I take your point, but I think that if the address ends up with no relevant a= ssociated TLVs then it is ignored is also a point. I dare say we can wordsmi= th something. > Also, I don=E2=80=99t quite get where you=E2=80=99re going with the last p= aragraph of that section (=E2=80=9CThese restrictions do not, however, mean t= hat added information is > completely ignored for purposes of the base protocol.=E2=80=9D)... Read on, the rest of the paragraph describes the case where not. But we migh= t telegraph that better in the opening sentence. > * regarding the maps in 4.5. Information Representation: > I=E2=80=99m afraid I just don=E2=80=99t really understand the purpose of t= his section and the mapping notation. I=E2=80=99m assuming that the maps are= supposed to offer a way of describing how a TLV relates to a message or an a= ddress?=20 > If so, why does it only mention extension types, but not the basis types? It says extended types, meaning the combination of the two. But full type wo= uld be better, as almost defined in 5444. In fact I think we should add a co= mment to the notation section. (5444 uses a symbolic name rather than the ph= rase.) > Or is it supposed to be used something like this: >=20 > BASE_TLV >=20 > Message:=20 > (base_tlv_extension_type_1) -> (2 octets, "value a when condition x is met= ") > (base_tlv_extension_type_2) -> (2 octets, "value b when condition y is met= ") >=20 > ? Also, I don=E2=80=99t quite get how this would be used in future protoco= l specifications? Or aid in implementing RFC5444 parsers? > An example or a clarification would be very helpful. It's a way of looking at things. But not the only one, it goes on to discuss= variants. I think it mostly comes under heading of if useful use it, if not= skip it. We'll take another look, but I don't think this will ever be eleme= ntary. > * regarding 4.6. TLVs: > In general, it=E2=80=99s not clear everywhere in the section whether you=E2= =80=99re talking to RFC5444 parser/builder implementors or protocol designer= s.=20 >=20 > A protocol SHOULD use an efficient > representation, but this is a quality of implementation issue. >=20 > I=E2=80=99m not sure where you=E2=80=99re going with the last part of that= sentence? I=E2=80=99d reword it to something like =E2=80=9EA protocol SHOUL= D use an efficient representation, avoiding unnecessarily verbose use of TLV= s and extension types. However, the final arrangement in a message- or addre= ssTLV block is a quality of implementation issue=E2=80=9C (in case that=E2=80= =99s what you meant). No, you're considering the protocol design. This is considering the protocol= object that implements the protocol. There isn't a one to one mapping from i= nformation to representation, it's up to the implementation to do it efficie= ntly. Different implementations of the same protocol specification may do be= tter or worse here. (Trivial case, an implementation could choose to never c= ompress addresses. Bad idea, but legal.) > And then: >=20 > A > protocol MUST recognize any permitted representation of the > information; even if it chooses to (for example) only use multivalue > TLVs, it MUST recognize single value TLVs (and vice versa). >=20 > =E2=80=A6 I thought protocols weren=E2=80=99t supposed to specify whether a= TLV is arranged (for example) as a multivalue TLV?! Implementation again, not design. > And so, since a protocol shouldn't be concerned with multivalue TLVs and t= he like, wouldn=E2=80=99t it be the *RFC5444 implementation* that MUST recog= nize any permitted representation? You're assuming that there is an RFC 5444 implementation. That's the same wa= y to work if you plan to implement more than one protocol. But nothing says y= ou have to do it that way. The architecture defined by 5498 admits of the mu= ltiplexer and protocols, and thus these are rules on the protocol. If protoc= ols delegate all their common work to something (parser/creator) then it inh= erits those restrictions, but that's not defined, and we can't assume it. > Or is this paragraph really just a complicated way of saying =E2=80=9Eas a= protocol designer, make sure to not specify/rely on things like (for exampl= e) multivalue TLVs, since your messages have to work with *any* representati= on=E2=80=9C? If so, I think that should be done in a less complicated fashio= n (see below). >=20 > * regarding 5. Structure: > Since this section talks a lot about flags, it=E2=80=99d be nice if its ti= tle represented that. Maybe consider renaming it to =E2=80=9EStructure and Fl= ags=E2=80=9C or so? I mostly don't agree. Structure is the subject, flags are a detail. > * from 6.1. Address Block Compression: >=20 > Compression of addresses in an Address Block considers addresses to > consist of a Head, a Mid, and a Tail, where all addresses in an > Address Block have the same Head and Tail, but different Mids. >=20 >=20 > I=E2=80=99d find this sentence easier to read if it started with =E2=80=9C= Compression of addresses in an Address Block is possible when addresses cons= ist of a Head, a Mid [=E2=80=A6]=E2=80=9D. No. That's missing the point and misleading. Addresses are always considered= to have the head/mid/tail format. Compression is possible if either the hea= d or tail (or both) is non-empty. > * from 6.1. Address Block Compression: >=20 > Putting addresses into a message efficiently also has to include: >=20 > Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that would be a =E2=80=9Em= ay=E2=80=9C. Multiple Adress Blocks and/or reordering don=E2=80=99t increase= efficiency in all possible cases... I think that's the wrong change. Rather "include" should be "consider". > * from 6.2. TLVs: > [...] This is even possible if the MPR TLV specified in > OLSRv2 [RFC7181] is added; but it is not possible, in general, if > the LINK_METRIC TLV is also added. >=20 > Why is it not possible for the latter? If that could be explained/hinted a= t in a half sentence, I think it=E2=80=99d be helpful information to have in= the draft. That's very hard, and not just because it's a negative. It's really an obser= vation that motivates the duscussion. A half sentence would I think confuse m= ore than it enlightens (it's because you have too many constraints to satisf= y at once - I doubt that helped). > In a typical case where a > LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with > enough addresses, sorted appropriately, two single value TLVs can > be more efficient than one multivalue TLV. >=20 > Same thing: why? Here I think this should be obvious to anyone who has looked at 5444. > * regarding the second paragraph from 6.3. TLV Values, i.e. > =20 > This approach was specified in [RFC7188], and required for protocols > that extend [RFC6130] and [RFC7181]. It is here RECOMMENDED that > this approach is followed when defining any Address Block TLV that > may be used by a protocol using [RFC5444]. >=20 > The term =E2=80=9Ethis approach=E2=80=9C confused me, since I initially t= hought it meant =E2=80=9Ethe approach is to use UNSPECIFIED in a way that ma= kes sense=E2=80=9C rather than =E2=80=9Ethe approach is to use UNSPECIFIED=E2= =80=9C. Maybe that could be reworded to something along the lines of=20 > The UNSPECIFIED TLV and its usage was specified in [RFC7188]=E2=80=A6=20 > ? No. There is no UNSPECIFIED TLV. There is a recommendation to include an UNS= PECIFIED value in a TLV. But really, we've described this once in 7188, it's= there to read. > * regarding 6.3. TLV Values: > The second paragraph is a bit confusing and seems to explaing roghly the s= ame things as the fourth paragraphs. I=E2=80=99d propose to merge the second= into the fourth. I'm not sure I exactly agree, but the ordering in that section could be impr= oved. > * from 6.4. Automation: >=20 > The possible gain depends on the efficiency > of the original message creation, >=20 > the term =E2=80=9Ethe original message creation=E2=80=9C seems a bit ambig= uous=E2=80=93 does this refer to the message as created by an RFC5444 messag= e builder implementation? Yes. > Additionally, I'm concerned about two things that *aren=E2=80=99t* in the d= raft: >=20 > * Some of the AODVv2 co-authors and me have asked for a list of =E2=80=9E= as a protocol, you can set all of these fields of a message, but please leav= e the rest alone=E2=80=9C, which would=E2=80=99ve saved us many hours of dis= cussions (and Henning a lot of time spent explaining these things=E2=80=A6).= These requests have been met with a refusal to specify a concrete API, as s= uch an effort is dependent on outside factors such as programming language o= r software architecture. I agree with this notion, but a programming-languag= e dependent API is not what we=E2=80=99ve asked for. I=E2=80=99ve tried to s= upply a sketch of what I did ask for in [1], but unfortunately I didn=E2=80=99= t get an answer (and as far as I can see it, the draft wasn=E2=80=99t change= d either). I still think that such a list, in whatever form, would be very h= elpful for future Internet-Draft authors and I also think this request is in= accordance with the intentions stated in 1.1 History and Purpose, and I thi= nk it should be included in the document. No. There are many reasons why we're just not touching this one. One is that language independence is a mirage. How you go about things is co= mpletely different in, for example an object oriented language than one that= isn't. Section 4.5 shows that there are quite different ways of doing thing= s even given a decision to use a map approach, and there are other approache= s than that. It would be wrong and beyond our competence to suggest one of t= hese as "best". There's reasons the IETF doesn't do this, and that's one. Plus, frankly, the work it would take is beyond what we choose to spend. > * As the exact rules for using/setting the hop count & hop-limit fields ar= e currently being discussed w/ regard to AODVv2 in another thread [2]=E2=80=93= should a definitive answer to that question be part of 5444-usage? You don't want that. Because if we did specify that you'd find yourself more= constrained than you want to be. There is a design intent described in 5444= , but it assumes immutable messages. Which you don't want. Really, we're doi= ng you a favour by not imposing on you. > Best regards, > Lotte >=20 > [1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.html > [2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.html=20 >=20 >=20 >> Am 06.04.2016 um 19:14 schrieb Justin Dean : >>=20 >> The chairs agree that a 3 week WGLC is appropriate. Everyone please read= the draft early and get comments in early so that they can be addressed wit= hin the last call period. >>=20 >> Justin >>=20 >>> On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) wrote: >>> Obviously +1 to the request for WGLC. >>>=20 >>> With regard to what's changed, technically the only significant thing is= to make it clear that if a protocol delivers a message to the multiplexer, t= he multiplexer must pass it on unchanged to the protocol (another instance o= f, at another router) unchanged. Without that nothing that the protocol itse= lf chooses to do with regard to security makes sense. Though the protocol ca= n alternatively let the multiplexer do the security, 7182 can be implemented= in either way. This isn't really new, but it wasn't formally spelled out. I= t's presented as part of spelling out multiplexer rules more carefully. >>>=20 >>> But what about message optimisation? That's a function of constructing a= 5444 message, not the multiplexer, and is down to that 5444 includes two th= ings - packet/message structure (and implicitly, and in pretty much any impl= ementation I would expect to see, a parser and builder for that structure) a= nd the multiplexer. So we took the opportunity to separate out more clearly a= discussion of the two, which we think will be helpful. >>>=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 >>> -----Original Message----- >>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg >>> Sent: 05 April 2016 20:08 >>> To: manet@ietf.org >>> Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 >>>=20 >>> ----------------------! WARNING ! ---------------------- This message or= iginates from outside our organisation, either from an external partner or f= rom the internet. >>> Consider carefully whether you should click on any links, open any attac= hments or reply. >>> Follow the 'Report Suspicious Emails' link on IT matters for instruction= s on reporting suspicious email messages. >>> -------------------------------------------------------- >>>=20 >>> *** WARNING *** >>> EXTERNAL EMAIL -- This message originates from outside our organization.= >>>=20 >>>=20 >>> Hi, >>>=20 >>> As you have seen, we have submitted a new revision of 5444-usage. The au= thors feel comfortable that we have addressed all issues by this version, an= d would like to ask the WG chairs to issue a WGLC on this document. While it= is a fairly short document, given that it is IETF week for some, we'd sugge= st that a 3-4 week WGLC would be appropriate. >>>=20 >>> Best regards >>> Ulrich >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=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 >>=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-F9675B70-9302-48D1-BE79-D0F3F4E71308 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
A few immediate comments inline below.=

--  
Christopher Dearlove
=

On 15 Apr 2016, at 15:18, Lotte Steenbrin= k <lotte.steenbrink@fu-b= erlin.de> wrote:

Hi all,

sparked by the recently started WGL= C, I=E2=80=99ve reviewed the current revision of the draft. I=E2=80=99d like= to offer the working group my perspective as someone who doesn=E2=80=99t ha= ve decades of protocol and/or packet format design under their belt (i.e. so= me things might not be obvious to me that are obvious to others), but also a= s someone who has worked with RFC 5444 when implementing a routing protocol (= AODVv2), updating the packet format of a routing protocol (AODVv2 again) and= (partially) implementing my own RFC5444 builder/parser.

Overall, I think the document is easy= to read and follow. To me, it contains valuable information and guidance an= d in some cases prevents people from shooting themselves in the foot.
<= div class=3D"">I=E2=80=99m really happy this document exists and I=E2=80=99d= like it to move forward soon, but I do feel that it is still lacking in som= e areas, which is why I was a bit surprised to see it go to Last Call all of= a sudden.

Not really. The= authors had said what they intended to say, no one was commenting, time for= WGLC.

First, some nitpicks and comments:

* from 1.2.1. Packet/Message Format:
   =
   [=E2=80=A6] a packet
    =
  transmission following a successful packet reception is by design
      of a new packet that may include all, some, or none of the
      received messages [...]
I=E2=80=99m not a native speaker, but that= =E2=80=9Eof=E2=80=9C seems out of place...

I am a native speaker, and no, it's not. Some would repea= t it after each of all, some and none, and I might sometimes. But it really d= oesn't matter which of the two styles we pick, the RFC Editor may well chang= e to the other.

* Regarding 4.2. Packets and Messages:
this section talk= s a lot about how the multiplexer operates, so I think it=E2=80=99d be helpf= ul if its title reflected that. 
I'm of two opinions on that. On the one hand it is, as its title sugg= ests, about the packet and message level, as opposed to lower levels, and it= s title contrasts with that if 4.3 for that reason. On the other hand you ar= e right, it does have much about the multiplexer. A title covering all three= woukd start getting cumbersome. Will take this one away to think about.

* f= rom 4.4. Addresses Requir= e Attributes:

An unmodified extension to NHDP would i= gnore such addresses, as required, as it does not support that specialized purpose.

At first glance, (to me= ) this reads as =E2=80=9EAll addresses that are associated with an unknown T= LV are ignored=E2=80=9C, which is obviously nonsense (but quite panic-induci= ng :D). I=E2=80=99d propose to reword it to something along the lines of&nbs= p;
   An unmodifi=
ed extension to NHDP would not consider this
   address to be of a neighbor, as it is lacking a LINK_STATUS
   or OTHER_NEIGHB TLV.

I take your point, but I think that= if the address ends up with no relevant associated TLVs then it is ignored i= s also a point. I dare say we can wordsmith something.

Also, I don=E2=80=99t quite get where you=E2=80=99re going with the last paragraph of that section (=E2=80=9C<= /span>These restrictions do not,= however, mean that added information is
   completely ignored for purposes of the base protocol.=E2=80=9D)...

Read on, the rest of the paragraph describes the case wh= ere not. But we might telegraph that better in the opening sentence.

* regarding= the maps in 4.= 5. Informa= tion Representation:
I=E2=80=99m afraid I just d= on=E2=80=99t really understand the purpose of this section and the mapping n= otation. I=E2=80=99m assuming that the maps are supposed to offer a way of d= escribing how a TLV relates to a message or an address? 
If so, why does it only mention extension types, but not the basis ty= pes?

It says extended types, meaning t= he combination of the two. But full type would be better, as almost defined i= n 5444. In fact I think we should add a comment to the notation section. (54= 44 uses a symbolic name rather than the phrase.)

Or is it supposed to be used so= mething like this:

BASE_TLV

=
Message: 
(base_tlv_extension_type_= 1) -> (2 octets, "value a when condition x is met")
(base_tlv_extension_type_2) -> (= 2 octets, "value b when condition y is met")
? Also, I don=E2=80=99t quite get how this= would be used in future protocol specifications? Or aid in implementing RFC= 5444 parsers?
An example or a clarification would be ve= ry helpful.

It's a way of looking at t= hings. But not the only one, it goes on to discuss variants. I think it most= ly comes under heading of if useful use it, if not skip it. We'll take anoth= er look, but I don't think this will ever be elementary.

* regarding 4.6. TLVs:
In general, it=E2=80=99= s not clear everywhere in the sec= tion whether you=E2=80=99r= e talking to RFC5444 parser/builder implementors or protocol designers. = ;

   A protocol SHOULD use an efficient
   representation, but this is a quality of implementation issue.

I=E2=80=99m not sure where yo= u=E2=80=99re going with the last part of that sentence? I=E2=80=99d reword i= t to something like =E2=80=9EA protocol SHOULD use an efficient representati= on, avoiding unnecessarily verbose use of TLVs and extension types. However,= the final arrangement in a message- or addressTLV block is  a quality o= f implementation issue=E2=80=9C (in case that=E2=80=99s what you meant).

No, you're considering the protoco= l design. This is considering the protocol object that implements the protoc= ol. There isn't a one to one mapping from information to representation, it'= s up to the implementation to do it efficiently. Different implementations o= f the same protocol specification may do better or worse here. (Trivial case= , an implementation could choose to never compress addresses. Bad idea, but l= egal.)

And then:

   A
   protocol MUST recognize any permitted representation of the
   information; even if it chooses to (for example) only use multivalue
   TLVs, it MUST recognize single value TLVs (and vice versa).

=E2=80=A6 I thought protocols w= eren=E2=80=99t supposed to specify whether a TLV is arranged (for example) a= s a multivalue TLV?!

Implementa= tion again, not design.

And so, since a protocol shouldn't be con= cerned with multivalue TLVs and the like, wouldn=E2=80=99t it be the *RFC544= 4 implementation* that MUST recognize any permitted representation?

You're assuming that there is an R= FC 5444 implementation. That's the same way to work if you plan to implement= more than one protocol. But nothing says you have to do it that way. The ar= chitecture defined by 5498 admits of the multiplexer and protocols, and thus= these are rules on the protocol. If protocols delegate all their common wor= k to something (parser/creator) then it inherits those restrictions, but tha= t's not defined, and we can't assume it.

=
Or is this paragraph really j= ust a complicated way of saying =E2=80=9Eas a protocol designer, make sure t= o not specify/rely on things like (for example) multivalue TLVs, since your m= essages have to work with *any* representation=E2=80=9C? If so, I think that= should be done in a less complicated fashion (see below).

* regarding 5. Structure:
Since this section talks a lot about f= lags, it=E2=80=99d be nice= if its title represented that. Maybe consider renaming it to =E2= =80=9EStructure and Flags=E2=80=9C or so?

I mostly don't a= gree. Structure is the subject, flags are a detail.

* from 6.1. Address Block Compression:
= 
   Compression of addresses in an Address Block considers addresses to=

   consist of a Head, a Mid, and a Tail, where all addresses in an
   Address Block have the same Head and Tail, but different Mids.


I=E2=80=99d find this sentence easier to read if it started wi= th =E2=80=9CCompression of addresses in an Address Block is possible when ad= dresses consist of a Head, a Mid [=E2=80=A6]=E2=80=9D.

No. That's missing the point and misleading. Addresses are= always considered to have the head/mid/tail format. Compression is possible= if either the head or tail (or both) is non-empty.

* from 6.1. Address Block Compression:

Putting addresses into a message effic= iently also has to include:

Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99= d think that would be a =E2=80=9Emay=E2=80=9C. Multiple Adress Blocks and/or= reordering don=E2=80=99t increase efficiency in all possible cases...
=

I think that's the wrong change. Rather "i= nclude" should be "consider".

* from 6.2. TLVs:
      [...] This is even possible if the MPR TLV specified in
      OLSRv2 [RFC71=
81] is added; but it is not possible, in general, if

      the LINK_METRIC TLV is als=
o added.

Why= is it not possible for the latter? If that could be explained/hinted at in a= half sentence, I think it=E2=80=99d be helpful information to have in the d= raft.

That's very hard, and not just b= ecause it's a negative. It's really an observation that motivates the duscus= sion. A half sentence would I think confuse more than it enlightens (it's be= cause you have too many constraints to satisfy at once - I doubt that helped= ).

<= pre class=3D"newpage" style=3D"font-size: 13px; margin-top: 0px; margin-bott= om: 0px; page-break-before: always;"> In a typical case where a LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with enough addresses, sorted appropriately, two single value TLVs can be more efficient than one multivalue TLV.

Same thing: why?

Here I think this should be obvious to anyone who has looke= d at 5444.

* regarding the second paragraph from 6.3. TLV Values, i.e.
   
   This approach was specified in [RFC7188], and requi=
red for protocols
   that extend [RFC6130] and [RFC7181].  It is here RECOMMENDED that
   this approach is followed when defining any Address Block TLV that
   may be used by a protocol using [RFC5444].

The term =E2=80=9Ethis approach=E2=80=9C confused me, since I initially &= nbsp;thought it meant =E2=80=9Ethe approach is to use UNSPECIFIED in a way t= hat makes sense=E2=80=9C rather than =E2=80=9Ethe approach is to use UNSPECI= FIED=E2=80=9C. Maybe that could be reworded to something along the lines of&= nbsp;
The UNSPECIFIED= TLV and its usage was specified in [RFC7188]=E2=80=A6 
?

No. There is no UNSPEC= IFIED TLV. There is a recommendation to include an UNSPECIFIED value in a TL= V. But really, we've described this once in 7188, it's there to read.<= div>
* regardin= g 6.3. TLV Values:<= /div>
The second p= aragraph is a bit confusing and seems to explaing roghly the same things as t= he fourth paragraphs. I=E2=80=99d propose to merge the second into the fourth.

I'm not sure I exactly agree, but the ordering in tha= t section could be improved.

* from 6.4. Automation:

   The possible gain depends on t=
he efficiency
   of the original message creation,

the term =E2=80=9Ethe original message creation=E2=80= =9C seems a bit ambiguous=E2=80=93 does this refer to the message as created= by an RFC5444 message builder implementation?
=
Yes.

Additionally, I'm concerned about two things that *aren=E2=80=99t*= in the draft:

* &= nbsp;Some of the AODVv2 co-authors and me have asked for a list of =E2=80=9E= as a protocol, you can set all of these fields of a message, but please leav= e the rest alone=E2=80=9C, which would=E2=80=99ve saved us many hours of dis= cussions (and Henning a lot of time spent explaining these things=E2=80=A6).= These requests have been met with a refusal to specify a concrete API, as s= uch an effort is dependent on outside factors such as programming language o= r software architecture. I agree with this notion, but a programming-languag= e dependent API is not what we=E2=80=99ve asked for. I=E2=80=99ve tried to s= upply a sketch of what I did ask for in [1], but unfortunately I didn=E2=80=99= t get an answer (and as far as I can see it, the draft wasn=E2=80=99t change= d either). I still think that such a list, in whatever form, would be very h= elpful for future Internet-Draft authors and I also think this request is in= accordance with the intentions stated in 1.1 History and Purpose, and I think it should be included in= the document.

No. There are many rea= sons why we're just not touching this one.

One is t= hat language independence is a mirage. How you go about things is completely= different in, for example an object oriented language than one that isn't. S= ection 4.5 shows that there are quite different ways of doing things even gi= ven a decision to use a map approach, and there are other approaches than th= at. It would be wrong and beyond our competence to suggest one of these as "= best". There's reasons the IETF doesn't do this, and that's one.
<= br>
Plus, frankly, the work it would take is beyond what we choose= to spend.

* As the exact rules for using/setting the hop count & hop-limit f= ields are currently being discussed w/ regard to AODVv2 in another thread [2= ]=E2=80=93 should a definitive answer to that question be part of 5444-usage= ?

You don't want that. Because if we d= id specify that you'd find yourself more constrained than you want to be. Th= ere is a design intent described in 5444, but it assumes immutable messages.= Which you don't want. Really, we're doing you a favour by not imposing on y= ou.

= Best regards,
Lotte

[1] https://www.ietf.org/mail-archi= ve/web/manet/current/msg18082.html
[2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.html =


Am 06.04.= 2016 um 19:14 schrieb Justin Dean <bebemaster@gmail.com>:

The chairs agree tha= t a 3 week WGLC is appropriate.  Everyone please read the draft early a= nd get comments in early so that they can be addressed within the last call p= eriod.

Justin

On Wed= , Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
Obviously +1 to the request for WGLC.

With regard to what's changed, technically the only significant thing is to m= ake it clear that if a protocol delivers a message to the multiplexer, the m= ultiplexer must pass it on unchanged to the protocol (another instance of, a= t another router) unchanged. Without that nothing that the protocol itself c= hooses to do with regard to security makes sense. Though the protocol can al= ternatively let the multiplexer do the security, 7182 can be implemented in e= ither way. This isn't really new, but it wasn't formally spelled out. It's p= resented as part of spelling out multiplexer rules more carefully.

But what about message optimisation? That's a function of constructing a 544= 4 message, not the multiplexer, and is down to that 5444 includes two things= - packet/message structure (and implicitly, and in pretty much any implemen= tation I would expect to see, a parser and builder for that structure) and t= he multiplexer. So we took the opportunity to separate out more clearly a di= scussion of the two, which we think will be helpful.

--
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

-----Original Message-----
From: manet [mailto:man= et-bounces@ietf.org] On Behalf Of Ulrich Herberg
Sent: 05 April 2016 20:08
To: manet@ietf.org
Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

----------------------! WARNING ! ---------------------- This message origin= ates from outside our organisation, either from an external partner or from t= he internet.
Consider carefully whether you should click on any links, open any attachmen= ts or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on= reporting suspicious email messages.
--------------------------------------------------------

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


Hi,

As you have seen, we have submitted a new revision of 5444-usage. The author= s feel comfortable that we have addressed all issues by this version, and wo= uld like to ask the WG chairs to issue a WGLC on this document. While it is a= fairly short document, given that it is IETF week for some, we'd suggest th= at a 3-4 week WGLC would be appropriate.

Best regards
Ulrich

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet<= br class=3D"">

****************************************************************= ****
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<= br class=3D"">

_______________________________________________
manet mailing l= ist
manet@ietf.or= g
= https://www.ietf.org/mailman/listinfo/manet

= _______________________________________________
manet mailin= g list
manet@ietf.org<= /span>
http= s://www.ietf.org/mailman/listinfo/manet
= --Apple-Mail-F9675B70-9302-48D1-BE79-D0F3F4E71308-- From nobody Fri Apr 15 11:37: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 91D5312DFFA for ; Fri, 15 Apr 2016 11:37:14 -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 PokTNVcrhhxK for ; Fri, 15 Apr 2016 11:37:10 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 8340712DFAD for ; Fri, 15 Apr 2016 11:37:10 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id u185so143064568iod.3 for ; Fri, 15 Apr 2016 11:37: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=yfSBqO2NWXsKAaJAyMRhbtw2fB8cFSq6CMEdH5dMYP4=; b=Mg8CXbbWHfQcPaOyRMDNKmDxWM17aOnVX1PpXo47iE2DIqzTRz5CpvOXUUU7Vu+GHv +ByzZRmMbUeKSCvQHo3CfJC9bCC8I86bQlKfVfx0h/kxlaOSzw2YL8QMdoww6uqTGOta Ku0RyQsPeQYwzzW/+p677UZfWPOPXZcM5Z5d7zcwgRyYKjCJj8mvyDXXIm7Shh3dA4fe P6AWpATmPpgvbXx2v0RgquNuIRDohqdAAcP2BKBtBo+03QWgbAMvHPObKfydPsn3LeE5 ZMQHne4CjfCIzBwvftJyaIxSNn7CCMySPMpRDhiW/LtfD19+At4v8kRNKPSqnQ6VStQh /fyg== 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=yfSBqO2NWXsKAaJAyMRhbtw2fB8cFSq6CMEdH5dMYP4=; b=bjLZ+iNugUi4+BSvufgbKqNege1U+87OImy5jklhPmMNysjRG+3lKctocNmKR+cEjE MieJRUpz4QT/pKbps4jfvx/XygSteCpVCfPSeoW2V86btwOT+HmsyPENOCsfyS42LKGQ VB0d5PXpVetHPEaT8fJViXcGBqZYtzjFDOarNjx2jezefBV6X4BPK1asj4uFh2eWsRgD zFDrMxptzogCNGRtsRUOIw6NMC0pSptLHF0wVXrOZK7nD5qGXCLVmYZWJ/8Vv8YA+w0N diTR206xRccNuznxNhTKpOTDaHLzCFj1DLbtEFnZp8hLINB2311Lb0vWjAYgN+GfzG5k crIg== X-Gm-Message-State: AOPr4FXLqVWIGYWaLomznpZIB+HFIZidGhJzayJJElmoRDa53+WD1fRnXMU8GG16lUH2Dtsc0qbKKG/Cit2NDw== MIME-Version: 1.0 X-Received: by 10.107.173.69 with SMTP id w66mr26609866ioe.182.1460745429819; Fri, 15 Apr 2016 11:37:09 -0700 (PDT) Received: by 10.79.96.1 with HTTP; Fri, 15 Apr 2016 11:37:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Apr 2016 14:37:09 -0400 Message-ID: From: Stan Ratliff To: Christopher Dearlove Content-Type: multipart/alternative; boundary=001a114464f473ad4e05308a4c39 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 15 Apr 2016 18:37:14 -0000 --001a114464f473ad4e05308a4c39 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My main concern addressed inline... On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlove < christopher.dearlove@gmail.com> wrote: > A few immediate comments inline below. > > -- > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) > > On 15 Apr 2016, at 15:18, Lotte Steenbrink > wrote: > > Hi all, > > sparked by the recently started WGLC, I=E2=80=99ve reviewed the current r= evision > of the draft. I=E2=80=99d like to offer the working group my perspective = as someone > who doesn=E2=80=99t have decades of protocol and/or packet format design = under > their belt (i.e. some things might not be obvious to me that are obvious = to > others), but also as someone who has worked with RFC 5444 when implementi= ng > a routing protocol (AODVv2), updating the packet format of a routing > protocol (AODVv2 again) and (partially) implementing my own RFC5444 > builder/parser. > > Overall, I think the document is easy to read and follow. To me, it > contains valuable information and guidance and in some cases prevents > people from shooting themselves in the foot. > I=E2=80=99m really happy this document exists and I=E2=80=99d like it to = move forward > soon, but I do feel that it is still lacking in some areas, which is why = I > was a bit surprised to see it go to Last Call all of a sudden. > > > Not really. The authors had said what they intended to say, no one was > commenting, time for WGLC. > > First, some nitpicks and comments: > > * from 1.2.1 > . > Packet/Message Format: > > [=E2=80=A6] a packet > > transmission following a successful packet reception is by design > of a new packet that may include all, some, or none of the > received messages [...] > > > I=E2=80=99m not a native speaker, but that =E2=80=9Eof=E2=80=9C seems out= of place... > > > I am a native speaker, and no, it's not. Some would repeat it after each > of all, some and none, and I might sometimes. But it really doesn't matte= r > which of the two styles we pick, the RFC Editor may well change to the > other. > > * Regarding 4.2 > . > Packets and Messages: > this section talks a lot about how the multiplexer operates, so I think > it=E2=80=99d be helpful if its title reflected that. > > > I'm of two opinions on that. On the one hand it is, as its title suggests= , > about the packet and message level, as opposed to lower levels, and its > title contrasts with that if 4.3 for that reason. On the other hand you a= re > right, it does have much about the multiplexer. A title covering all thre= e > woukd start getting cumbersome. Will take this one away to think about. > > * from 4.4 > . > Addresses Require Attributes: > > An unmodified extension to NHDP would ignore such addresses, > as required, as it does not support that specialized purpose. > > > At first glance, (to me) this reads as =E2=80=9EAll addresses that are as= sociated > with an unknown TLV are ignored=E2=80=9C, which is obviously nonsense (bu= t quite > panic-inducing :D). I=E2=80=99d propose to reword it to something along t= he lines > of > > An unmodified extension to NHDP would not consider this > > address to be of a neighbor, as it is lacking a LINK_STATUS > > or OTHER_NEIGHB TLV. > > > I take your point, but I think that if the address ends up with no > relevant associated TLVs then it is ignored is also a point. I dare say w= e > can wordsmith something. > > Also, I don=E2=80=99t quite get where you=E2=80=99re going with the last = paragraph of > that section (=E2=80=9CThese restrictions do not, however, mean that adde= d > information is > > completely ignored for purposes of the base protocol.=E2=80=9D)... > > > Read on, the rest of the paragraph describes the case where not. But we > might telegraph that better in the opening sentence. > > * regarding the maps in 4.5 > . > Information Representation: > I=E2=80=99m afraid I just don=E2=80=99t really understand the purpose of = this section and > the mapping notation. I=E2=80=99m assuming that the maps are supposed to = offer a > way of describing how a TLV relates to a message or an address? > If so, why does it only mention extension types, but not the basis types? > > > It says extended types, meaning the combination of the two. But full type > would be better, as almost defined in 5444. In fact I think we should add= a > comment to the notation section. (5444 uses a symbolic name rather than t= he > phrase.) > > Or is it supposed to be used something like this: > > *BASE_TLV* > > Message: > (base_tlv_extension_type_1) -> (2 octets, "value a when condition x is > met") > (base_tlv_extension_type_2) -> (2 octets, "value b when condition y is > met") > > ? Also, I don=E2=80=99t quite get how this would be used in future protoc= ol > specifications? Or aid in implementing RFC5444 parsers? > An example or a clarification would be very helpful. > > > It's a way of looking at things. But not the only one, it goes on to > discuss variants. I think it mostly comes under heading of if useful use > it, if not skip it. We'll take another look, but I don't think this will > ever be elementary. > > * regarding 4.6 > . > TLVs: > In general, it=E2=80=99s not clear everywhere in the section whether you= =E2=80=99re > talking to RFC5444 parser/builder implementors or protocol designers. > > A protocol SHOULD use an efficient > representation, but this is a quality of implementation issue. > > > I=E2=80=99m not sure where you=E2=80=99re going with the last part of tha= t sentence? I=E2=80=99d > reword it to something like =E2=80=9EA protocol SHOULD use an efficient > representation, avoiding unnecessarily verbose use of TLVs and extension > types. However, the final arrangement in a message- or addressTLV block i= s > a quality of implementation issue=E2=80=9C (in case that=E2=80=99s what = you meant). > > > No, you're considering the protocol design. This is considering the > protocol object that implements the protocol. There isn't a one to one > mapping from information to representation, it's up to the implementation > to do it efficiently. Different implementations of the same protocol > specification may do better or worse here. (Trivial case, an implementati= on > could choose to never compress addresses. Bad idea, but legal.) > > And then: > > A > protocol MUST recognize any permitted representation of the > information; even if it chooses to (for example) only use multivalue > TLVs, it MUST recognize single value TLVs (and vice versa). > > > =E2=80=A6 I thought protocols weren=E2=80=99t supposed to specify whether= a TLV is > arranged (for example) as a multivalue TLV?! > > > Implementation again, not design. > > And so, since a protocol shouldn't be concerned with multivalue TLVs and > the like, wouldn=E2=80=99t it be the *RFC5444 implementation* that MUST r= ecognize > any permitted representation? > > > You're assuming that there is an RFC 5444 implementation. That's the same > way to work if you plan to implement more than one protocol. But nothing > says you have to do it that way. The architecture defined by 5498 admits = of > the multiplexer and protocols, and thus these are rules on the protocol. = If > protocols delegate all their common work to something (parser/creator) th= en > it inherits those restrictions, but that's not defined, and we can't assu= me > it. > > Or is this paragraph really just a complicated way of saying =E2=80=9Eas = a > protocol designer, make sure to not specify/rely on things like (for > example) multivalue TLVs, since your messages have to work with *any* > representation=E2=80=9C? If so, I think that should be done in a less com= plicated > fashion (see below). > > * regarding 5 > = . > Structure: > Since this section talks a lot about flags, it=E2=80=99d be nice if its t= itle > represented that. Maybe consider renaming it to =E2=80=9EStructure and Fl= ags=E2=80=9C or > so? > > > I mostly don't agree. Structure is the subject, flags are a detail. > > * from 6.1 > . > Address Block Compression: > > Compression of addresses in an Address Block considers addresses to > consist of a Head, a Mid, and a Tail, where all addresses in an > Address Block have the same Head and Tail, but different Mids. > > > > I=E2=80=99d find this sentence easier to read if it started with =E2=80= =9CCompression of > addresses in an Address Block is possible when addresses consist of a Hea= d, > a Mid [=E2=80=A6]=E2=80=9D. > > > No. That's missing the point and misleading. Addresses are always > considered to have the head/mid/tail format. Compression is possible if > either the head or tail (or both) is non-empty. > > * from 6.1 > . > Address Block Compression: > > > Putting addresses into a message efficiently also has to include: > > > Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that would be a =E2=80=9E= may=E2=80=9C. Multiple Adress Blocks > and/or reordering don=E2=80=99t increase efficiency in all possible cases= ... > > > I think that's the wrong change. Rather "include" should be "consider". > > * from 6.2 > . > TLVs: > > [...] This is even possible if the MPR TLV specified in > OLSRv2 [RFC7181 ] is added; bu= t it is not possible, in general, if > > the LINK_METRIC TLV is also added. > > > Why is it not possible for the latter? If that could be explained/hinted > at in a half sentence, I think it=E2=80=99d be helpful information to hav= e in the > draft. > > > That's very hard, and not just because it's a negative. It's really an > observation that motivates the duscussion. A half sentence would I think > confuse more than it enlightens (it's because you have too many constrain= ts > to satisfy at once - I doubt that helped). > > In a typical case where a > LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with > enough addresses, sorted appropriately, two single value TLVs can > be more efficient than one multivalue TLV. > > > Same thing: why? > > > Here I think this should be obvious to anyone who has looked at 5444. > > * regarding the second paragraph from 6.3 > . > TLV Values, i.e. > > > > This approach was specified in [RFC7188 ], and required for protocols > that extend [RFC6130 ] and [RFC71= 81 ]. It is here RECOMMENDED that > this approach is followed when defining any Address Block TLV that > may be used by a protocol using [RFC5444 ]. > > > The term =E2=80=9Ethis approach=E2=80=9C confused me, since I initially = thought it meant > =E2=80=9Ethe approach is to use UNSPECIFIED in a way that makes sense=E2= =80=9C rather than > =E2=80=9Ethe approach is to use UNSPECIFIED=E2=80=9C. Maybe that could be= reworded to > something along the lines of > The UNSPECIFIED TLV and its usage was specified in [RFC7188]=E2=80=A6 > ? > > > No. There is no UNSPECIFIED TLV. There is a recommendation to include an > UNSPECIFIED value in a TLV. But really, we've described this once in 7188= , > it's there to read. > > * regarding 6.3 > . > TLV Values: > The second paragraph is a bit confusing and seems to explaing roghly the > same things as the fourth paragraphs. I=E2=80=99d propose to merge the se= cond > into the fourth. > > > I'm not sure I exactly agree, but the ordering in that section could be > improved. > > * from 6.4 > . > Automation: > > The possible gain depends on the efficiency > of the original message creation, > > > the term =E2=80=9Ethe original message creation=E2=80=9C seems a bit ambi= guous=E2=80=93 does this > refer to the message as created by an RFC5444 message builder > implementation? > > > Yes. > > Additionally, I'm concerned about two things that *aren=E2=80=99t* in the= draft: > > * Some of the AODVv2 co-authors and me have asked for a list of =E2=80= =9Eas a > protocol, you can set all of these fields of a message, but please leave > the rest alone=E2=80=9C, which would=E2=80=99ve saved us many hours of di= scussions (and > Henning a lot of time spent explaining these things=E2=80=A6). These requ= ests have > been met with a refusal to specify a concrete API, as such an effort is > dependent on outside factors such as programming language or software > architecture. I agree with this notion, but a programming-language > dependent API is not what we=E2=80=99ve asked for. I=E2=80=99ve tried to = supply a sketch of > what I did ask for in [1], but unfortunately I didn=E2=80=99t get an answ= er (and as > far as I can see it, the draft wasn=E2=80=99t changed either). I still th= ink that > such a list, in whatever form, would be very helpful for future > Internet-Draft authors and I also think this request is in accordance wit= h > the intentions stated in 1.1 History and Purpose, and I think it should > be included in the document. > > > No. There are many reasons why we're just not touching this one. > > One is that language independence is a mirage. How you go about things is > completely different in, for example an object oriented language than one > that isn't. Section 4.5 shows that there are quite different ways of doin= g > things even given a decision to use a map approach, and there are other > approaches than that. It would be wrong and beyond our competence to > suggest one of these as "best". There's reasons the IETF doesn't do this, > and that's one. > > Plus, frankly, the work it would take is beyond what we choose to spend. > I'm confused (which is an altogether too common occurrence these days). I get that we don't want to specify an API. But I think the discussion about fields a protocol can and can't touch in a messages is a good thing - and it's one spot where I, too, find the document wanting. To paraphrase something I've said before, I believe that RFC 5444 changes the relationship that a routing protocol has with an "interface". I'm not commenting on whether or not that's a good thing, or a bad thing - just that it does change the relationship. This change has been at the root of some of the long-running discussions as to whether protocols under development were RFC 5444 compliant or not. The goal of this document being to eliminate (it's a goal, probably not reachable) those discussions, I'd like to see that information in the document in some form. I'm interested in seeing this document progress, and eventually be published. I think it will help future protocol designers to better use RFC 5444. But I would like to see *something* along the lines of what Lotte is requesting, as I think it will improve the doc. Regards, Stan > > * As the exact rules for using/setting the hop count & hop-limit fields > are currently being discussed w/ regard to AODVv2 in another thread [2]= =E2=80=93 > should a definitive answer to that question be part of 5444-usage? > > > You don't want that. Because if we did specify that you'd find yourself > more constrained than you want to be. There is a design intent described = in > 5444, but it assumes immutable messages. Which you don't want. Really, > we're doing you a favour by not imposing on you. > > Best regards, > Lotte > > [1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.html > [2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.html > > > Am 06.04.2016 um 19:14 schrieb Justin Dean : > > The chairs agree that a 3 week WGLC is appropriate. Everyone please read > the draft early and get comments in early so that they can be addressed > within the last call period. > > Justin > > On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > >> Obviously +1 to the request for WGLC. >> >> With regard to what's changed, technically the only significant thing is >> to make it clear that if a protocol delivers a message to the multiplexe= r, >> the multiplexer must pass it on unchanged to the protocol (another insta= nce >> of, at another router) unchanged. Without that nothing that the protocol >> itself chooses to do with regard to security makes sense. Though the >> protocol can alternatively let the multiplexer do the security, 7182 can= be >> implemented in either way. This isn't really new, but it wasn't formally >> spelled out. It's presented as part of spelling out multiplexer rules mo= re >> carefully. >> >> But what about message optimisation? That's a function of constructing a >> 5444 message, not the multiplexer, and is down to that 5444 includes two >> things - packet/message structure (and implicitly, and in pretty much an= y >> implementation I would expect to see, a parser and builder for that >> structure) and the multiplexer. So we took the opportunity to separate o= ut >> more clearly a discussion of the two, which we think will be helpful. >> >> -- >> 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 >> >> -----Original Message----- >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg >> Sent: 05 April 2016 20:08 >> To: manet@ietf.org >> Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 >> >> ----------------------! WARNING ! ---------------------- This message >> originates from outside our organisation, either from an external partne= r >> or from the internet. >> Consider carefully whether you should click on any links, open any >> attachments or reply. >> Follow the 'Report Suspicious Emails' link on IT matters for instruction= s >> on reporting suspicious email messages. >> -------------------------------------------------------- >> >> *** WARNING *** >> EXTERNAL EMAIL -- This message originates from outside our organization. >> >> >> Hi, >> >> As you have seen, we have submitted a new revision of 5444-usage. The >> authors feel comfortable that we have addressed all issues by this versi= on, >> and would like to ask the WG chairs to issue a WGLC on this document. Wh= ile >> it is a fairly short document, given that it is IETF week for some, we'd >> suggest that a 3-4 week WGLC would be appropriate. >> >> Best regards >> Ulrich >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 > > --001a114464f473ad4e05308a4c39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My main concern addressed inline...


On Fri, Apr 15, 2016 at 1:49 PM= , Christopher Dearlove <christopher.dearlove@gmail.com>= ; wrote:
A = few immediate comments inline below.

-- =C2=A0
Christopher Dearl= ove

On 15 Apr 2016, at 15:18, Lotte Steenbri= nk <l= otte.steenbrink@fu-berlin.de> wrote:

Hi all,

sparked by the recently started WGLC, I= =E2=80=99ve reviewed the current revision of the draft. I=E2=80=99d like to= offer the working group my perspective as someone who doesn=E2=80=99t have= decades of protocol and/or packet format design under their belt (i.e. som= e things might not be obvious to me that are obvious to others), but also a= s someone who has worked with RFC 5444 when implementing a routing protocol= (AODVv2), updating the packet format of a routing protocol (AODVv2 again) = and (partially) implementing my own RFC5444 builder/parser.

<= /div>
Overall, I think the document is easy to read and follow. To me, = it contains valuable information and guidance and in some cases prevents pe= ople from shooting themselves in the foot.
I=E2=80=99m really hap= py this document exists and I=E2=80=99d like it to move forward soon, but I= do feel that it is still lacking in some areas, which is why I was a bit s= urprised to see it go to Last Call all of a sudden.

Not really. The authors had said what they inten= ded to say, no one was commenting, time for WGLC.

First, some nitpicks and comments:
=

* from=C2=A01.2.1. Packet/Message Format:

     =C2=A0[=E2=
=80=A6] a packet
      transmission following a successful packet reception is by =
design
      of a new packet that may include all, some, or none of the
      received messages [...]

I=E2=80= =99m not a native speaker, but that =E2=80=9Eof=E2=80=9C seems out of place= ...

I am a native speake= r, and no, it's not. Some would repeat it after each of all, some and n= one, and I might sometimes. But it really doesn't matter which of the t= wo styles we pick, the RFC Editor may well change to the other.
<= br>
* Regarding=C2=A04.2. Packets and Messages:
this section talks a lot about how the multiplexer operates, so I think i= t=E2=80=99d be helpful if its title reflected that.=C2=A0
=

I'm of two opinions on that. On the one han= d it is, as its title suggests, about the packet and message level, as oppo= sed to lower levels, and its title contrasts with that if 4.3 for that reas= on. On the other hand you are right, it does have much about the multiplexe= r. A title covering all three woukd start getting cumbersome. Will take thi= s one away to think about.

* from=C2=A04.4. Addr= esses Require Attributes:

   An unmodified extension to NHDP would ignore su=
ch addresses,
   as required, as it does not support that specialized purpose.
=
At first glance, (to me) this reads as =E2=80=9EAll ad= dresses that are associated with an unknown TLV are ignored=E2=80=9C, which= is obviously nonsense (but quite panic-inducing :D). I=E2=80=99d propose t= o reword it to something along the lines of=C2=A0
   An unmodified extension =
to NHDP would not consider this
   address to be of a neighbor, as it is lacking a=
 LINK_STATUS
   or OTHER_NEIGHB TLV.

=
I take your point, but I think that if the address ends up with no re= levant associated TLVs then it is ignored is also a point. I dare say we ca= n wordsmith something.

Also, I don=E2=80=99t quite get where you=E2=80=99re going with the last paragraph of that section (=E2=80=9CThese restrictions do not, however, mean that added= information is
   completely ignored for purposes of the base protocol.=E2=80=9D)...

Read on, the rest of the paragraph describes the case where not= . But we might telegraph that better in the opening sentence.
* regarding the maps in=C2=A04.5. Information Representation:
I=E2=80=99m afraid I just don=E2=80=99t really understand th= e purpose of this section and the mapping notation. I=E2=80=99m assuming th= at the maps are supposed to offer a way of describing how a TLV relates to = a message or an address?=C2=A0
If so, why does it only mention ex= tension types, but not the basis types?

It says extended types, meaning the combination of the two. But full ty= pe would be better, as almost defined in 5444. In fact I think we should ad= d a comment to the notation section. (5444 uses a symbolic name rather than= the phrase.)

Or is it su= pposed to be used something like this:

BASE_TLV

Message:=C2=A0
(base_tlv_extension_type_1) -> (2 octets, "value = a when condition x is met")
(b= ase_tlv_extension_type_2) -> (2 octets, "value b when condition y i= s met")

? Also, I don=E2=80=99t quite = get how this would be used in future protocol specifications? Or aid in imp= lementing RFC5444 parsers?
An example or a clarification would be= very helpful.

It's a way of loo= king at things. But not the only one, it goes on to discuss variants. I thi= nk it mostly comes under heading of if useful use it, if not skip it. We= 9;ll take another look, but I don't think this will ever be elementary.=

* regarding=C2=A04.6. TLVs:
In general, it=E2=80=99s not clear everywhere in the section whether you=E2=80=99re talking to RFC5444 parser/builder implemento= rs or protocol designers.=C2=A0

   A protocol SHOULD u=
se an efficient
   representation, but this is a quality of implementation issue.

I=E2=80=99m not sure where you=E2=80=99re going with the la= st part of that sentence? I=E2=80=99d reword it to something like =E2=80=9E= A protocol SHOULD use an efficient representation, avoiding unnecessarily v= erbose use of TLVs and extension types. However, the final arrangement in a= message- or addressTLV block is =C2=A0a quality of implementation issue=E2= =80=9C (in case that=E2=80=99s what you meant).

No, you're considering the protocol design. This is c= onsidering the protocol object that implements the protocol. There isn'= t a one to one mapping from information to representation, it's up to t= he implementation to do it efficiently. Different implementations of the sa= me protocol specification may do better or worse here. (Trivial case, an im= plementation could choose to never compress addresses. Bad idea, but legal.= )

And then:
=
   A
   protocol MUST recognize any permitted representation of the
   information; even if it chooses to (for example) only use multivalue
   TLVs, it MUST recognize single value TLVs (and vice versa).
=E2=80=A6 I thought protocols weren=E2=80=99t supposed to spec= ify whether a TLV is arranged (for example) as a multivalue TLV?!

Implementation again, not design.
=

And so, since a protocol = shouldn't be concerned with multivalue TLVs and the like, wouldn=E2=80= =99t it be the *RFC5444 implementation* that MUST recognize any permitted r= epresentation?

You're= assuming that there is an RFC 5444 implementation. That's the same way= to work if you plan to implement more than one protocol. But nothing says = you have to do it that way. The architecture defined by 5498 admits of the = multiplexer and protocols, and thus these are rules on the protocol. If pro= tocols delegate all their common work to something (parser/creator) then it= inherits those restrictions, but that's not defined, and we can't = assume it.

Or is this par= agraph really just a complicated way of saying =E2=80=9Eas a protocol desig= ner, make sure to not specify/rely on things like (for example) multivalue = TLVs, since your messages have to work with *any* representation=E2=80=9C? = If so, I think that should be done in a less complicated fashion (see below= ).

* regarding=C2=A05. Structure:
Since this section talks a lot about flags, it=E2=80=99d be nice if its title represented that. Maybe consid= er renaming it to=C2=A0=E2=80=9EStructure and Flags=E2=80=9C=C2=A0or so?

=
I mostly don't agree. Structure is the subject, flags are a detai= l.

* from=C2=A06.1. Address Block Compression:=

= 
   Comp=
ression of addresses in an Address Block considers addresses to
   consist of a Head, a Mid, and a Tail, where all addresses in an
   Address Block have the same Head and Tail, but different Mids.


I=E2=80=99d find this sentence easier = to read if it started with =E2=80=9CCompression of addresses in an Address = Block is possible when addresses consist of a Head, a Mid [=E2=80=A6]=E2=80= =9D.

No. That's missing the poin= t and misleading. Addresses are always considered to have the head/mid/tail= format. Compression is possible if either the head or tail (or both) is no= n-empty.

* from=C2=A06.1<= span style=3D"font-size:1em;font-weight:bold">. Address Block Compression:<= /span>

   Putting addresses into a message efficiently also has to include:

=
Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that would be a = =E2=80=9Emay=E2=80=9C. Multiple Adress Blocks and/or reordering don=E2=80= =99t increase efficiency in all possible cases...
<= div>
I think that's the wrong change. Rather "include&quo= t; should be "consider".

=
* from=C2=A06.2. T= LVs:
      [...] This is even possible if the MPR TLV specified in
      OLSRv2 [RFC7181] is added; but it is not possible, in general, if

      =
the LINK_METRIC TLV is also added.

Why is it= not possible for the latter? If that could be explained/hinted at in a hal= f sentence, I think it=E2=80=99d be helpful information to have in the draf= t.

That's very hard, and not jus= t because it's a negative. It's really an observation that motivate= s the duscussion. A half sentence would I think confuse more than it enligh= tens (it's because you have too many constraints to satisfy at once - I= doubt that helped).

In a typic= al case where a LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with enough addresses, sorted appropriately, two single value TLVs can be more efficient than one multivalue TLV.

=
Same thing: why?

Here I think t= his should be obvious to anyone who has looked at 5444.

* regarding the second paragraph from=C2=A0<= a name=3D"m_-648935726582295764_section-6.3" href=3D"https://tools.ietf.org= /html/draft-ietf-manet-rfc5444-usage-03#section-6.3" style=3D"font-size:1em= ;font-weight:bold;color:black;text-decoration:none" target=3D"_blank">6.3. TLV Values, i.e.<= /div>
  =
=C2=A0
=
   This approach was specified in [RFC7188], and req=
uired for protocols
   that extend [RFC6130] and [RFC7181].  It is here RECOMMENDED that
   this approach is followed when defining any Address Block TLV that
   may be used by a protocol using [RFC5444].

The term =E2=80= =9Ethis approach=E2=80=9C confused me, since I initially =C2=A0thought it m= eant =E2=80=9Ethe approach is to use UNSPECIFIED in a way that makes sense= =E2=80=9C rather than =E2=80=9Ethe approach is to use UNSPECIFIED=E2=80=9C.= Maybe that could be reworded to something along the lines of=C2=A0
The UNSPECIFIED TLV and its usage was specified i= n [RFC7188]=E2=80=A6=C2=A0
?
=
No. There is no UNSPECIFIED TLV. There is a recommendation to inc= lude an UNSPECIFIED value in a TLV. But really, we've described this on= ce in 7188, it's there to read.

* regarding=C2=A06.3. TLV Values:
The second = paragraph is a bit confusing and seems to explaing roghly the same things a= s the fourth paragraphs. I=E2=80=99d p= ropose to merge the second into the fourth.
=

I'm not sure I exactly agree, but the ordering in that s= ection could be improved.

* from=C2=A06.4. Automation= :

   The possible gain depends on the efficiency
   of the original message creation,

the ter= m =E2=80=9Ethe original message creation=E2=80=9C seems a bit ambiguous=E2= =80=93 does this refer to the message as created by an RFC5444 message buil= der implementation?

Yes.
<= br>
Additionally, I'm concerned abou= t two things that *aren=E2=80=99t* in the draft:

*= =C2=A0Some of the AODVv2 co-authors and me have asked for a list of =E2=80= =9Eas a protocol, you can set all of these fields of a message, but please = leave the rest alone=E2=80=9C, which would=E2=80=99ve saved us many hours o= f discussions (and Henning a lot of time spent explaining these things=E2= =80=A6). These requests have been met with a refusal to specify a concrete = API, as such an effort is dependent on outside factors such as programming = language or software architecture. I agree with this notion, but a programm= ing-language dependent API is not what we=E2=80=99ve asked for. I=E2=80=99v= e tried to supply a sketch of what I did ask for in [1], but unfortunately = I didn=E2=80=99t get an answer (and as far as I can see it, the draft wasn= =E2=80=99t changed either). I still think that such a list, in whatever for= m, would be very helpful for future Internet-Draft authors and I also think= this request is in accordance with the intentions stated in=C2=A01.1 History and Purpose,=C2=A0and I think it should be= included in the document.

No. There= are many reasons why we're just not touching this one.

<= /div>
One is that language independence is a mirage. How you go about t= hings is completely different in, for example an object oriented language t= han one that isn't. Section 4.5 shows that there are quite different wa= ys of doing things even given a decision to use a map approach, and there a= re other approaches than that. It would be wrong and beyond our competence = to suggest one of these as "best". There's reasons the IETF d= oesn't do this, and that's one.

Plus, fran= kly, the work it would take is beyond what we choose to spend.
<= /div>


<Speaking as a WG P= articipant>

I'm confused (which is an altog= ether too common occurrence these days). I get that we don't want to sp= ecify an API. But I think the discussion about fields a protocol can and ca= n't touch in a messages is a good thing - and it's one spot where I= , too, find the document wanting.=C2=A0

To paraphr= ase something I've said before, I believe that RFC 5444 changes the rel= ationship that a routing protocol has with an "interface". I'= m not commenting on whether or not that's a good thing, or a bad thing = - just that it does change the relationship. This change has been at the ro= ot of some of the long-running discussions as to whether protocols under de= velopment were RFC 5444 compliant or not. The goal of this document being t= o eliminate (it's a goal, probably not reachable) those discussions, I&= #39;d like to see that information in the document in some form.=C2=A0

I'm interested in seeing this document progress, a= nd eventually be published. I think it will help future protocol designers = to better use RFC 5444. But I would like to see *something* along the lines= of what Lotte is requesting, as I think it will improve the doc.=C2=A0

Regards,
Stan

=C2= =A0

* As the exact rules for using/setting the= hop count & hop-limit fields are currently being discussed w/ regard t= o AODVv2 in another thread [2]=E2=80=93 should a definitive answer to that = question be part of 5444-usage?

You = don't want that. Because if we did specify that you'd find yourself= more constrained than you want to be. There is a design intent described i= n 5444, but it assumes immutable messages. Which you don't want. Really= , we're doing you a favour by not imposing on you.

Best regards,
Lotte

<= /div>


Am= 06.04.2016 um 19:14 schrieb Justin Dean <bebemaster@gmail.com>:

The chairs agree that a 3 week WGLC is appropriate.=C2=A0 Eve= ryone please read the draft early and get comments in early so that they ca= n be addressed within the last call period.

Justin
=

On Wed, Apr= 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) <chris.dearlov= e@baesystems.com> wrote:
Ob= viously +1 to the request for WGLC.

With regard to what's changed, technically the only significant thing i= s to make it clear that if a protocol delivers a message to the multiplexer= , the multiplexer must pass it on unchanged to the protocol (another instan= ce of, at another router) unchanged. Without that nothing that the protocol= itself chooses to do with regard to security makes sense. Though the proto= col can alternatively let the multiplexer do the security, 7182 can be impl= emented in either way. This isn't really new, but it wasn't formall= y spelled out. It's presented as part of spelling out multiplexer rules= more carefully.

But what about message optimisation? That's a function of constructing = a 5444 message, not the multiplexer, and is down to that 5444 includes two = things - packet/message structure (and implicitly, and in pretty much any i= mplementation I would expect to see, a parser and builder for that structur= e) and the multiplexer. So we took the opportunity to separate out more cle= arly a discussion of the two, which we think will be helpful.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________<= br>
T: =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chris.dearlove@baesyst= ems.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 Ulrich Herberg
Sent: 05 April 2016 20:08
To: manet@ietf.org<= br> Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

----------------------! 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 instru= ctions on reporting suspicious email messages.
--------------------------------------------------------

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


Hi,

As you have seen, we have submitted a new revision of 5444-usage. The autho= rs feel comfortable that we have addressed all issues by this version, and = would like to ask the WG chairs to issue a WGLC on this document. While it = is a fairly short document, given that it is IETF week for some, we'd s= uggest that a 3-4 week WGLC would be appropriate.

Best regards
Ulrich

_______________________________________________
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
http= s://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


--001a114464f473ad4e05308a4c39-- From nobody Fri Apr 15 13:11: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 2EC5212DBB3 for ; Fri, 15 Apr 2016 13:11:34 -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 RCTLaTGu2Pu7 for ; Fri, 15 Apr 2016 13:11:28 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 144DF12DBF9 for ; Fri, 15 Apr 2016 13:11:28 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id n3so8846453wmn.1 for ; Fri, 15 Apr 2016 13:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=A+Sr6WE8/L7/SSty3uEUt428WmRzMzO6kpBndf1Q+8k=; b=mq1Ze4/fBLneySE2pq/nLIciUu8GimpAaQ5KtJvizYe5m5EHBXyeXOZHhQBR3wQMox 8UO5GIsg4hqwHkM+Zqau4Du7qhjeXx37kcmmhbpOOp7bwL6EHg18qwI8SDTb4cYQVNpB xfpzdSzn+7kfrQOLipKrIcbTH1udEbFIuMgl8lNK4gMQsVUkiHRZRTaid9e4wBVqvzO0 vlpHBPJZcN2W2m4NVyT0l4W5/DvsHIXNy1qe9GkHHokSIzfXHeKyCu1Vu7E9s5V2pSH4 6MOlF57zH9GU07N+HO6E3DWkC7SJ8GGqllk2kwTRAsQKzKfG74lacNhxUTEpiiTzoe1d ipVg== 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 :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=A+Sr6WE8/L7/SSty3uEUt428WmRzMzO6kpBndf1Q+8k=; b=bU1m4g5i5hyCpF00+jnsN6sVxPekAi2tRGGcWkf6jiUhaUH0H8CokaufAjjz/HMF/B BXj7KDGv5q2P74QmwP74lnzblshTT+JVPTuLr2j+Q9qGq1hE7rrZbEMoWlfDcbYDyqek Ktl+bX155LiEW9BCuB8lc2Qb4YXh7bMlQ85vurqfP8IZTwNFGa1sb8YlyNCTR/ulZ6oj zN9Jv19JkPa1MWbQQGi4Y6bjF1cyEi9vfWdw0B555jE9O+yhgG/g5Xx4NZH1kaqqwRAy qWXDeJuEgQMBOo5i0yhHPT7vHWSUteeQWNaULF26wjZ0rftqH0MhIb6i0TVogANZjk3J Y5Xg== X-Gm-Message-State: AOPr4FV8IfLW7cMpZZqcaSG7IDxbz15jUb0A701UY/yMQ4kekgFu8Avt15+XHiUEUL1lXA== X-Received: by 10.194.107.74 with SMTP id ha10mr23858615wjb.24.1460751086491; Fri, 15 Apr 2016 13:11:26 -0700 (PDT) Received: from [10.2.93.92] (dab-hlw1-w-1-3.dab.02.net. [82.132.232.9]) by smtp.gmail.com with ESMTPSA id om6sm50417163wjc.40.2016.04.15.13.11.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2016 13:11:25 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-2A210C7F-E66D-43DB-A3A8-48F53DF31737 Message-Id: X-Mailer: iPhone Mail (13E238) From: Christopher Dearlove Date: Fri, 15 Apr 2016 21:11:20 +0100 To: Stan Ratliff Archived-At: Cc: "manet@ietf.org" , Christopher Dearlove Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 15 Apr 2016 20:11:34 -0000 --Apple-Mail-2A210C7F-E66D-43DB-A3A8-48F53DF31737 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don't understand what you mean by the concept of "fields the protocol can a= nd can't touch". When a protocol creates a message from scratch it's not constrained in any w= ay I'd describe in such terms. So I assume you mean when it receives a messa= ge and then sends a similar message. There are two cases there. Unchanged (with the special exceptions for hop co= unt and limit) and not unchanged. The former is better, and there's really n= othing more to say. So let's consider the latter. Really it's not the same message, it's a brand= new message. That's a useful way to look at it from a security perspective,= because it tells you that end to end authentication isn't going to work. An= d what are the restrictions on brand new messages? The same as on any new me= ssage. OK, you might say, true but does that mean I can add this, remove that, chan= ge the hop data? Yes. But is that a good idea? No. But maybe you are forced i= nto it. But that it's inherently not good suggests the corollary that if you= must, do the minimum and make it trackable. But that's not a 5444 requireme= nt, just good practice. It does break 7182 message ICVs, so don't use them. We could, hypothetically, have someone create an extension or alternative to= 7182 that defined aggregated signatures. Then we'd have rules on what you c= ould change. But that would belong there. If you think those would be good, t= hen again you would want make minimal changes, and mainly only of certain ty= pes. What types? There I can't help you as I don't have a candidate. The summary? Don't change if you don't have to. That's recommended. If you m= ust change you're on your own (with the same restrictions as new messages). A= dvice like "as little as possible" is good, but that's not actually 5444 adv= ice. And don't use 7182 message ICVs. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 15 Apr 2016, at 19:37, Stan Ratliff wrote: >=20 > My main concern addressed inline... >=20 >=20 >> On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlove wrote: >> A few immediate comments inline below. >>=20 >> -- =20 >> Christopher Dearlove >> christopher.dearlove@gmail.com (iPhone) >> chris@mnemosyne.demon.co.uk (home) >>=20 >>> On 15 Apr 2016, at 15:18, Lotte Steenbrink wrote: >>>=20 >>> Hi all, >>>=20 >>> sparked by the recently started WGLC, I=E2=80=99ve reviewed the current r= evision of the draft. I=E2=80=99d like to offer the working group my perspec= tive as someone who doesn=E2=80=99t have decades of protocol and/or packet f= ormat design under their belt (i.e. some things might not be obvious to me t= hat are obvious to others), but also as someone who has worked with RFC 5444= when implementing a routing protocol (AODVv2), updating the packet format o= f a routing protocol (AODVv2 again) and (partially) implementing my own RFC5= 444 builder/parser. >>>=20 >>> Overall, I think the document is easy to read and follow. To me, it cont= ains valuable information and guidance and in some cases prevents people fro= m shooting themselves in the foot. >>> I=E2=80=99m really happy this document exists and I=E2=80=99d like it to= move forward soon, but I do feel that it is still lacking in some areas, wh= ich is why I was a bit surprised to see it go to Last Call all of a sudden. >>=20 >> Not really. The authors had said what they intended to say, no one was co= mmenting, time for WGLC. >>=20 >>> First, some nitpicks and comments: >>>=20 >>> * from 1.2.1. Packet/Message Format: >>>=20 >>> [=E2=80=A6] a packet >>> transmission following a successful packet reception is by design >>> of a new packet that may include all, some, or none of the >>> received messages [...] >>>=20 >>> I=E2=80=99m not a native speaker, but that =E2=80=9Eof=E2=80=9C seems ou= t of place... >>=20 >> I am a native speaker, and no, it's not. Some would repeat it after each o= f all, some and none, and I might sometimes. But it really doesn't matter wh= ich of the two styles we pick, the RFC Editor may well change to the other. >>=20 >>> * Regarding 4.2. Packets and Messages: >>> this section talks a lot about how the multiplexer operates, so I think i= t=E2=80=99d be helpful if its title reflected that.=20 >>=20 >> I'm of two opinions on that. On the one hand it is, as its title suggests= , about the packet and message level, as opposed to lower levels, and its ti= tle contrasts with that if 4.3 for that reason. On the other hand you are ri= ght, it does have much about the multiplexer. A title covering all three wou= kd start getting cumbersome. Will take this one away to think about. >>=20 >>> * from 4.4. Addresses Require Attributes: >>>=20 >>> An unmodified extension to NHDP would ignore such addresses, >>> as required, as it does not support that specialized purpose. >>>=20 >>> At first glance, (to me) this reads as =E2=80=9EAll addresses that are a= ssociated with an unknown TLV are ignored=E2=80=9C, which is obviously nonse= nse (but quite panic-inducing :D). I=E2=80=99d propose to reword it to somet= hing along the lines of=20 >>> An unmodified extension to NHDP would not consider this >>> address to be of a neighbor, as it is lacking a LINK_STATUS >>> or OTHER_NEIGHB TLV. >>=20 >> I take your point, but I think that if the address ends up with no releva= nt associated TLVs then it is ignored is also a point. I dare say we can wor= dsmith something. >>=20 >>> Also, I don=E2=80=99t quite get where you=E2=80=99re going with the last= paragraph of that section (=E2=80=9CThese restrictions do not, however, mea= n that added information is >>> completely ignored for purposes of the base protocol.=E2=80=9D)... >>=20 >> Read on, the rest of the paragraph describes the case where not. But we m= ight telegraph that better in the opening sentence. >>=20 >>> * regarding the maps in 4.5. Information Representation: >>> I=E2=80=99m afraid I just don=E2=80=99t really understand the purpose of= this section and the mapping notation. I=E2=80=99m assuming that the maps a= re supposed to offer a way of describing how a TLV relates to a message or a= n address?=20 >>> If so, why does it only mention extension types, but not the basis types= ? >>=20 >> It says extended types, meaning the combination of the two. But full type= would be better, as almost defined in 5444. In fact I think we should add a= comment to the notation section. (5444 uses a symbolic name rather than the= phrase.) >>=20 >>> Or is it supposed to be used something like this: >>>=20 >>> BASE_TLV >>>=20 >>> Message:=20 >>> (base_tlv_extension_type_1) -> (2 octets, "value a when condition x is m= et") >>> (base_tlv_extension_type_2) -> (2 octets, "value b when condition y is m= et") >>>=20 >>> ? Also, I don=E2=80=99t quite get how this would be used in future proto= col specifications? Or aid in implementing RFC5444 parsers? >>> An example or a clarification would be very helpful. >>=20 >> It's a way of looking at things. But not the only one, it goes on to disc= uss variants. I think it mostly comes under heading of if useful use it, if n= ot skip it. We'll take another look, but I don't think this will ever be ele= mentary. >>=20 >>> * regarding 4.6. TLVs: >>> In general, it=E2=80=99s not clear everywhere in the section whether you= =E2=80=99re talking to RFC5444 parser/builder implementors or protocol desig= ners.=20 >>>=20 >>> A protocol SHOULD use an efficient >>> representation, but this is a quality of implementation issue. >>>=20 >>> I=E2=80=99m not sure where you=E2=80=99re going with the last part of th= at sentence? I=E2=80=99d reword it to something like =E2=80=9EA protocol SHO= ULD use an efficient representation, avoiding unnecessarily verbose use of T= LVs and extension types. However, the final arrangement in a message- or add= ressTLV block is a quality of implementation issue=E2=80=9C (in case that=E2= =80=99s what you meant). >>=20 >> No, you're considering the protocol design. This is considering the proto= col object that implements the protocol. There isn't a one to one mapping fr= om information to representation, it's up to the implementation to do it eff= iciently. Different implementations of the same protocol specification may d= o better or worse here. (Trivial case, an implementation could choose to nev= er compress addresses. Bad idea, but legal.) >>=20 >>> And then: >>>=20 >>> A >>> protocol MUST recognize any permitted representation of the >>> information; even if it chooses to (for example) only use multivalue >>> TLVs, it MUST recognize single value TLVs (and vice versa). >>>=20 >>> =E2=80=A6 I thought protocols weren=E2=80=99t supposed to specify whethe= r a TLV is arranged (for example) as a multivalue TLV?! >>=20 >> Implementation again, not design. >>=20 >>> And so, since a protocol shouldn't be concerned with multivalue TLVs and= the like, wouldn=E2=80=99t it be the *RFC5444 implementation* that MUST rec= ognize any permitted representation? >>=20 >> You're assuming that there is an RFC 5444 implementation. That's the same= way to work if you plan to implement more than one protocol. But nothing sa= ys you have to do it that way. The architecture defined by 5498 admits of th= e multiplexer and protocols, and thus these are rules on the protocol. If pr= otocols delegate all their common work to something (parser/creator) then it= inherits those restrictions, but that's not defined, and we can't assume it= . >>=20 >>> Or is this paragraph really just a complicated way of saying =E2=80=9Eas= a protocol designer, make sure to not specify/rely on things like (for exam= ple) multivalue TLVs, since your messages have to work with *any* representa= tion=E2=80=9C? If so, I think that should be done in a less complicated fash= ion (see below). >>>=20 >>> * regarding 5. Structure: >>> Since this section talks a lot about flags, it=E2=80=99d be nice if its t= itle represented that. Maybe consider renaming it to =E2=80=9EStructure and = Flags=E2=80=9C or so? >>=20 >> I mostly don't agree. Structure is the subject, flags are a detail. >>=20 >>> * from 6.1. Address Block Compression: >>>=20 >>> Compression of addresses in an Address Block considers addresses to >>> consist of a Head, a Mid, and a Tail, where all addresses in an >>> Address Block have the same Head and Tail, but different Mids. >>>=20 >>>=20 >>> I=E2=80=99d find this sentence easier to read if it started with =E2=80=9C= Compression of addresses in an Address Block is possible when addresses cons= ist of a Head, a Mid [=E2=80=A6]=E2=80=9D. >>=20 >> No. That's missing the point and misleading. Addresses are always conside= red to have the head/mid/tail format. Compression is possible if either the h= ead or tail (or both) is non-empty. >>=20 >>> * from 6.1. Address Block Compression: >>>=20 >>> Putting addresses into a message efficiently also has to include: >>>=20 >>> Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that would be a =E2=80=9E= may=E2=80=9C. Multiple Adress Blocks and/or reordering don=E2=80=99t increas= e efficiency in all possible cases... >>=20 >> I think that's the wrong change. Rather "include" should be "consider". >>=20 >>> * from 6.2. TLVs: >>> [...] This is even possible if the MPR TLV specified in >>> OLSRv2 [RFC7181] is added; but it is not possible, in general, if >>> the LINK_METRIC TLV is also added. >>>=20 >>> Why is it not possible for the latter? If that could be explained/hinted= at in a half sentence, I think it=E2=80=99d be helpful information to have i= n the draft. >>=20 >> That's very hard, and not just because it's a negative. It's really an ob= servation that motivates the duscussion. A half sentence would I think confu= se more than it enlightens (it's because you have too many constraints to sa= tisfy at once - I doubt that helped). >>=20 >>> In a typical case where a >>> LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with >>> enough addresses, sorted appropriately, two single value TLVs can >>> be more efficient than one multivalue TLV. >>>=20 >>> Same thing: why? >>=20 >> Here I think this should be obvious to anyone who has looked at 5444. >>=20 >>> * regarding the second paragraph from 6.3. TLV Values, i.e. >>> =20 >>> This approach was specified in [RFC7188], and required for protocols >>> that extend [RFC6130] and [RFC7181]. It is here RECOMMENDED that >>> this approach is followed when defining any Address Block TLV that >>> may be used by a protocol using [RFC5444]. >>>=20 >>> The term =E2=80=9Ethis approach=E2=80=9C confused me, since I initially = thought it meant =E2=80=9Ethe approach is to use UNSPECIFIED in a way that m= akes sense=E2=80=9C rather than =E2=80=9Ethe approach is to use UNSPECIFIED=E2= =80=9C. Maybe that could be reworded to something along the lines of=20 >>> The UNSPECIFIED TLV and its usage was specified in [RFC7188]=E2=80=A6=20= >>> ? >>=20 >> No. There is no UNSPECIFIED TLV. There is a recommendation to include an U= NSPECIFIED value in a TLV. But really, we've described this once in 7188, it= 's there to read. >>=20 >>> * regarding 6.3. TLV Values: >>> The second paragraph is a bit confusing and seems to explaing roghly the= same things as the fourth paragraphs. I=E2=80=99d propose to merge the seco= nd into the fourth. >>=20 >> I'm not sure I exactly agree, but the ordering in that section could be i= mproved. >>=20 >>> * from 6.4. Automation: >>>=20 >>> The possible gain depends on the efficiency >>> of the original message creation, >>>=20 >>> the term =E2=80=9Ethe original message creation=E2=80=9C seems a bit amb= iguous=E2=80=93 does this refer to the message as created by an RFC5444 mess= age builder implementation? >>=20 >> Yes. >>=20 >>> Additionally, I'm concerned about two things that *aren=E2=80=99t* in th= e draft: >>>=20 >>> * Some of the AODVv2 co-authors and me have asked for a list of =E2=80=9E= as a protocol, you can set all of these fields of a message, but please leav= e the rest alone=E2=80=9C, which would=E2=80=99ve saved us many hours of dis= cussions (and Henning a lot of time spent explaining these things=E2=80=A6).= These requests have been met with a refusal to specify a concrete API, as s= uch an effort is dependent on outside factors such as programming language o= r software architecture. I agree with this notion, but a programming-languag= e dependent API is not what we=E2=80=99ve asked for. I=E2=80=99ve tried to s= upply a sketch of what I did ask for in [1], but unfortunately I didn=E2=80=99= t get an answer (and as far as I can see it, the draft wasn=E2=80=99t change= d either). I still think that such a list, in whatever form, would be very h= elpful for future Internet-Draft authors and I also think this request is in= accordance with the intentions stated in 1.1 History and Purpose, and I thi= nk it should be included in the document. >>=20 >> No. There are many reasons why we're just not touching this one. >>=20 >> One is that language independence is a mirage. How you go about things is= completely different in, for example an object oriented language than one t= hat isn't. Section 4.5 shows that there are quite different ways of doing th= ings even given a decision to use a map approach, and there are other approa= ches than that. It would be wrong and beyond our competence to suggest one o= f these as "best". There's reasons the IETF doesn't do this, and that's one.= >>=20 >> Plus, frankly, the work it would take is beyond what we choose to spend. >=20 >=20 > >=20 > I'm confused (which is an altogether too common occurrence these days). I g= et that we don't want to specify an API. But I think the discussion about fi= elds a protocol can and can't touch in a messages is a good thing - and it's= one spot where I, too, find the document wanting.=20 >=20 > To paraphrase something I've said before, I believe that RFC 5444 changes t= he relationship that a routing protocol has with an "interface". I'm not com= menting on whether or not that's a good thing, or a bad thing - just that it= does change the relationship. This change has been at the root of some of t= he long-running discussions as to whether protocols under development were R= FC 5444 compliant or not. The goal of this document being to eliminate (it's= a goal, probably not reachable) those discussions, I'd like to see that inf= ormation in the document in some form.=20 >=20 > I'm interested in seeing this document progress, and eventually be publish= ed. I think it will help future protocol designers to better use RFC 5444. B= ut I would like to see *something* along the lines of what Lotte is requesti= ng, as I think it will improve the doc.=20 >=20 > Regards, > Stan >=20 > =20 >>=20 >>> * As the exact rules for using/setting the hop count & hop-limit fields a= re currently being discussed w/ regard to AODVv2 in another thread [2]=E2=80= =93 should a definitive answer to that question be part of 5444-usage? >>=20 >> You don't want that. Because if we did specify that you'd find yourself m= ore constrained than you want to be. There is a design intent described in 5= 444, but it assumes immutable messages. Which you don't want. Really, we're d= oing you a favour by not imposing on you. >>=20 >>> Best regards, >>> Lotte >>>=20 >>> [1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.html >>> [2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.html=20= >>>=20 >>>=20 >>>> Am 06.04.2016 um 19:14 schrieb Justin Dean : >>>>=20 >>>> The chairs agree that a 3 week WGLC is appropriate. Everyone please re= ad the draft early and get comments in early so that they can be addressed w= ithin the last call period. >>>>=20 >>>> Justin >>>>=20 >>>>> On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) wrote: >>>>> Obviously +1 to the request for WGLC. >>>>>=20 >>>>> With regard to what's changed, technically the only significant thing i= s to make it clear that if a protocol delivers a message to the multiplexer,= the multiplexer must pass it on unchanged to the protocol (another instance= of, at another router) unchanged. Without that nothing that the protocol it= self chooses to do with regard to security makes sense. Though the protocol c= an alternatively let the multiplexer do the security, 7182 can be implemente= d in either way. This isn't really new, but it wasn't formally spelled out. I= t's presented as part of spelling out multiplexer rules more carefully. >>>>>=20 >>>>> But what about message optimisation? That's a function of constructing= a 5444 message, not the multiplexer, and is down to that 5444 includes two t= hings - packet/message structure (and implicitly, and in pretty much any imp= lementation I would expect to see, a parser and builder for that structure) a= nd the multiplexer. So we took the opportunity to separate out more clearly a= discussion of the two, which we think will be helpful. >>>>>=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 Ba= ddow, 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 >>>>> -----Original Message----- >>>>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herber= g >>>>> Sent: 05 April 2016 20:08 >>>>> To: manet@ietf.org >>>>> Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 >>>>>=20 >>>>> ----------------------! WARNING ! ---------------------- This message o= riginates from outside our organisation, either from an external partner or f= rom the internet. >>>>> Consider carefully whether you should click on any links, open any att= achments or reply. >>>>> Follow the 'Report Suspicious Emails' link on IT matters for instructi= ons on reporting suspicious email messages. >>>>> -------------------------------------------------------- >>>>>=20 >>>>> *** WARNING *** >>>>> EXTERNAL EMAIL -- This message originates from outside our organizatio= n. >>>>>=20 >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> As you have seen, we have submitted a new revision of 5444-usage. The a= uthors feel comfortable that we have addressed all issues by this version, a= nd would like to ask the WG chairs to issue a WGLC on this document. While i= t is a fairly short document, given that it is IETF week for some, we'd sugg= est that a 3-4 week WGLC would be appropriate. >>>>>=20 >>>>> Best regards >>>>> Ulrich >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=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 >>>>=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 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail-2A210C7F-E66D-43DB-A3A8-48F53DF31737 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I don't unde= rstand what you mean by the concept of "fields the protocol can and can't to= uch".

When a protocol creates a message from scratc= h it's not constrained in any way I'd describe in such terms. So I assume yo= u mean when it receives a message and then sends a similar message.

There are two cases there. Unchanged (with the special exce= ptions for hop count and limit) and not unchanged. The former is better, and= there's really nothing more to say.

So let's consi= der the latter. Really it's not the same message, it's a brand new message. T= hat's a useful way to look at it from a security perspective, because it tel= ls you that end to end authentication isn't going to work. And what are the r= estrictions on brand new messages? The same as on any new message.

OK, you might say, true but does that mean I can add this, r= emove that, change the hop data? Yes. But is that a good idea? No. But maybe= you are forced into it. But that it's inherently not good suggests the coro= llary that if you must, do the minimum and make it trackable. But that's not= a 5444 requirement, just good practice. It does break 7182 message ICVs, so= don't use them.

We could, hypothetically, have som= eone create an extension or alternative to 7182 that defined aggregated sign= atures. Then we'd have rules on what you could change. But that would belong= there. If you think those would be good, then again you would want make min= imal changes, and mainly only of certain types. What types? There I can't he= lp you as I don't have a candidate.

The summary? Do= n't change if you don't have to. That's recommended. If you must change you'= re on your own (with the same restrictions as new messages). Advice like "as= little as possible" is good, but that's not actually 5444 advice. And don't= use 7182 message ICVs.

--  
Christopher Dearlove



-- &n= bsp;
Christopher Dearlove
On 15 Apr 2016, at 19:37, Stan Ratliff <ratliffstan@gmail.com> wrote:

My main concern addressed inline...

On Fri, Apr 1= 5, 2016 at 1:49 PM, Christopher Dearlove <christopher.dearlove@= gmail.com> wrote:
A few immediate comments inline below.

--  
Chris= topher Dearlove

On 15 Apr 2016, at 15:18, Lotte S= teenbrink <lotte.steenbrink@fu-berlin.de> wrote:

Hi all,

sparked by the recently started WGLC,= I=E2=80=99ve reviewed the current revision of the draft. I=E2=80=99d like t= o offer the working group my perspective as someone who doesn=E2=80=99t have= decades of protocol and/or packet format design under their belt (i.e. some= things might not be obvious to me that are obvious to others), but also as s= omeone who has worked with RFC 5444 when implementing a routing protocol (AO= DVv2), updating the packet format of a routing protocol (AODVv2 again) and (= partially) implementing my own RFC5444 builder/parser.

<= div>Overall, I think the document is easy to read and follow. To me, it cont= ains valuable information and guidance and in some cases prevents people fro= m shooting themselves in the foot.
I=E2=80=99m really happy this d= ocument exists and I=E2=80=99d like it to move forward soon, but I do feel t= hat it is still lacking in some areas, which is why I was a bit surprised to= see it go to Last Call all of a sudden.
=
Not really. The authors had said what they intended to say, n= o one was commenting, time for WGLC.

First, some nitpicks and comments:

=
* from 1.2.1. Pack= et/Message Format:

      [=E2=80=A6] a packet
<= pre style=3D"font-size:13px;margin-top:0px;margin-bottom:0px"> transmis= sion following a successful packet reception is by design of a new packet that may include all, some, or none of the received messages [...]

I=E2=80=99= m not a native speaker, but that =E2=80=9Eof=E2=80=9C seems out of place...<= /div>

I am a native speaker, an= d no, it's not. Some would repeat it after each of all, some and none, and I= might sometimes. But it really doesn't matter which of the two styles we pi= ck, the RFC Editor may well change to the other.

* Regarding 4.2. Packets and Messages:
this section talks a= lot about how the multiplexer operates, so I think it=E2=80=99d be helpful i= f its title reflected that. 

I'm of two opinions on that. On the one hand it is, as its title suggests= , about the packet and message level, as opposed to lower levels, and its ti= tle contrasts with that if 4.3 for that reason. On the other hand you are ri= ght, it does have much about the multiplexer. A title covering all three wou= kd start getting cumbersome. Will take this one away to think about.

* from 4.4. Addresses Require Attributes:
<= div>
An unmodified= extension to NHDP would ignore such addresses, as required, as it does not support that specialized purpose.
<= br>
At first glance, (to me) this reads as =E2=80=9EAll addr= esses that are associated with an unknown TLV are ignored=E2=80=9C, which is= obviously nonsense (but quite panic-inducing :D). I=E2=80=99d propose to re= word it to something along the lines of 
   An unmodified extension to NHD=
P would not consider this
   address to be of a neighbor, as it is lacking a LINK_ST=
ATUS
   o=
r OTHER_NEIGHB TLV.

I tak= e your point, but I think that if the address ends up with no relevant assoc= iated TLVs then it is ignored is also a point. I dare say we can wordsmith s= omething.

Also, I don=E2=80=99t qui= te get where you=E2=80=99re going with t= he last paragraph of that section (=E2=80=9CThese restrictions do not, however, mean that added information is
   c=
ompletely ignored for purposes of the base protocol.=E2=80=9D)...

Read on, t= he rest of the paragraph describes the case where not. But we might telegrap= h that better in the opening sentence.

* regarding the maps in 4.5. Information Representation:
I=E2=80=99m afra= id I just don=E2=80=99t really understand the purpose of this section and th= e mapping notation. I=E2=80=99m assuming that the maps are supposed to offer= a way of describing how a TLV relates to a message or an address? 
If so, why does it only mention extension types, but not the basis ty= pes?

It says extended types, meaning t= he combination of the two. But full type would be better, as almost defined i= n 5444. In fact I think we should add a comment to the notation section. (54= 44 uses a symbolic name rather than the phrase.)

Or is it supposed to be used something like this:

BASE_TLV

Messag= e: 
(base_tlv_extension_type_1)= -> (2 octets, "value a when condition x is met")
(base_tlv_extension_type_2) -> (2 octets, "value b when c= ondition y is met")

? Also, I don=E2=80=99t q= uite get how this would be used in future protocol specifications? Or aid in= implementing RFC5444 parsers?
An example or a clarification would= be very helpful.

It's a way of looki= ng at things. But not the only one, it goes on to discuss variants. I think i= t mostly comes under heading of if useful use it, if not skip it. We'll take= another look, but I don't think this will ever be elementary.
* regarding 4.6. TLVs:
In general, it=E2=80=99s not clear e= verywhere in the section whether you=E2=80=99re talking to RFC5444 parser/builder implementors or protocol designer= s. 

   A protocol SHOULD use an efficient
   representation, but this is a quality of implementation issue.
=
I=E2=80=99m not sure where you=E2=80=99re going with the last= part of that sentence? I=E2=80=99d reword it to something like =E2=80=9EA p= rotocol SHOULD use an efficient representation, avoiding unnecessarily verbo= se use of TLVs and extension types. However, the final arrangement in a mess= age- or addressTLV block is  a quality of implementation issue=E2=80=9C= (in case that=E2=80=99s what you meant).

No, you're considering the protocol design. This is considering t= he protocol object that implements the protocol. There isn't a one to one ma= pping from information to representation, it's up to the implementation to d= o it efficiently. Different implementations of the same protocol specificati= on may do better or worse here. (Trivial case, an implementation could choos= e to never compress addresses. Bad idea, but legal.)

And then:

   A
   protocol MUST recognize any permitted representation of the
   information; even if it chooses to (for example) only use multivalue
   TLVs, it MUST recognize single value TLVs (and vice versa).
=E2=80=A6 I thought protocols weren=E2=80=99t supposed to specif= y whether a TLV is arranged (for example) as a multivalue TLV?!
<= /div>

Implementation again, not design.

And so, since a protocol shoul= dn't be concerned with multivalue TLVs and the like, wouldn=E2=80=99t it be t= he *RFC5444 implementation* that MUST recognize any permitted representation= ?

You're assuming that the= re is an RFC 5444 implementation. That's the same way to work if you plan to= implement more than one protocol. But nothing says you have to do it that w= ay. The architecture defined by 5498 admits of the multiplexer and protocols= , and thus these are rules on the protocol. If protocols delegate all their c= ommon work to something (parser/creator) then it inherits those restrictions= , but that's not defined, and we can't assume it.

Or is this paragraph really just a complicated way of s= aying =E2=80=9Eas a protocol designer, make sure to not specify/rely on thin= gs like (for example) multivalue TLVs, since your messages have to work with= *any* representation=E2=80=9C? If so, I think that should be done in a less= complicated fashion (see below).

* regarding=  5= . Structure:
Since this section talks a lot about flags, i= t=E2=80=99d be nice if its title repres= ented that. Maybe consider renaming it to =E2=80=9EStructure and= Flags=E2=80=9C or so?
=

I mostly don't agree. Structure is the subject, f= lags are a detail.

* from&= nbsp;6.= 1. Address Block Compress= ion:

   Compression of addresses in an Address Block considers addresses to
   consist of a Head, a Mid, and a Tail, where all addresses in an
   Address Block have the same Head and Tail, but different Mids.
=

I=E2=80=99d find this sentence easier to= read if it started with =E2=80=9CCompression of addresses in an Address Blo= ck is possible when addresses consist of a Head, a Mid [=E2=80=A6]=E2=80=9D.=

No. That's missing the point and mis= leading. Addresses are always considered to have the head/mid/tail format. C= ompression is possible if either the head or tail (or both) is non-empty.

* from 6.1. Address Block Compression:

Putting addr= esses into a message efficiently also has to include:

Why =E2=80= =9Ehas to=E2=80=9C? I=E2=80=99d think that would be a =E2=80=9Emay=E2=80=9C.= Multiple Adress Blocks and/or reordering don=E2=80=99t increase efficiency i= n all possible cases...

I think that'= s the wrong change. Rather "include" should be "consider".

* from 6.2. TLVs:
      [...] This is even possible if the MPR TLV=
 specified in
      OLSRv2 [RFC7181] is added; but it is not possible, in general, if

      t=
he LINK_METRIC TLV is also added.

Why is it n= ot possible for the latter? If that could be explained/hinted at in a half s= entence, I think it=E2=80=99d be helpful information to have in the draft.

That's very hard, and not just because= it's a negative. It's really an observation that motivates the duscussion. A= half sentence would I think confuse more than it enlightens (it's because y= ou have too many constraints to satisfy at once - I doubt that helped).

      In a typical case where a
      LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with
      enough addresses, sorted appropriately, two single value TLVs can
      be more efficient than one multivalue TLV.

<= div>Same thing: why?

Here I think thi= s should be obvious to anyone who has looked at 5444.

* regarding the second paragraph from 6.3. TLV Values, i.e.
   
   This ap=
proach was specified in [RFC7188], and required for pr=
otocols
   that extend [RFC6130] and [RFC7181].  It is here RECOMMENDED that
   this approach is followed when defining any Address Block TLV that
   may be used by a protocol using [RFC5444].

The term =E2=80=9Et= his approach=E2=80=9C confused me, since I initially  thought it meant =E2= =80=9Ethe approach is to use UNSPECIFIED in a way that makes sense=E2=80=9C r= ather than =E2=80=9Ethe approach is to use UNSPECIFIED=E2=80=9C. Maybe that c= ould be reworded to something along the lines of 
The UNSPECIFIED TLV and its usage was specified in [RFC7188]=E2=80= =A6 
?

No. Ther= e is no UNSPECIFIED TLV. There is a recommendation to include an UNSPECIFIED= value in a TLV. But really, we've described this once in 7188, it's there t= o read.

* regarding <= a name=3D"m_-648935726582295764_section-6.3" href=3D"https://tools.ietf.org/= html/draft-ietf-manet-rfc5444-usage-03#section-6.3" style=3D"font-size:1em;f= ont-weight:bold;color:black;text-decoration:none" target=3D"_blank">6.3<= span style=3D"font-size:1em;font-weight:bold">. TLV Values:
The second paragraph is a bit confusing and s= eems to explaing roghly the same things as the fourth paragraphs. I=E2= =80=99d propose to merge the second into the f= ourth.

I'm not sure I exactly a= gree, but the ordering in that section could be improved.

* from 6.4. Automation:

   The possible gain depends on the efficiency
   of the original message creation,

the term= =E2=80=9Ethe original message creation=E2=80=9C seems a bit ambiguous=E2=80= =93 does this refer to the message as created by an RFC5444 message builder i= mplementation?

Yes.

Additionally, I'm concerned about two thing= s that *aren=E2=80=99t* in the draft:

*  Some o= f the AODVv2 co-authors and me have asked for a list of =E2=80=9Eas a protoc= ol, you can set all of these fields of a message, but please leave the rest a= lone=E2=80=9C, which would=E2=80=99ve saved us many hours of discussions (an= d Henning a lot of time spent explaining these things=E2=80=A6). These reque= sts have been met with a refusal to specify a concrete API, as such an effor= t is dependent on outside factors such as programming language or software a= rchitecture. I agree with this notion, but a programming-language dependent A= PI is not what we=E2=80=99ve asked for. I=E2=80=99ve tried to supply a sketc= h of what I did ask for in [1], but unfortunately I didn=E2=80=99t get an an= swer (and as far as I can see it, the draft wasn=E2=80=99t changed either). I= still think that such a list, in whatever form, would be very helpful for f= uture Internet-Draft authors and I also think this request is in accordance w= ith the intentions stated in 1.1 History and Pur= pose, and I think it should be included in the document.

No. There are many reasons why we're just no= t touching this one.

One is that language independe= nce is a mirage. How you go about things is completely different in, for exa= mple an object oriented language than one that isn't. Section 4.5 shows that= there are quite different ways of doing things even given a decision to use= a map approach, and there are other approaches than that. It would be wrong= and beyond our competence to suggest one of these as "best". There's reason= s the IETF doesn't do this, and that's one.

Plus, f= rankly, the work it would take is beyond what we choose to spend.


<Speaking as a WG P= articipant>

I'm confused (which is an altogether= too common occurrence these days). I get that we don't want to specify an A= PI. But I think the discussion about fields a protocol can and can't touch i= n a messages is a good thing - and it's one spot where I, too, find the docu= ment wanting. 

To paraphrase something I've sa= id before, I believe that RFC 5444 changes the relationship that a routing p= rotocol has with an "interface". I'm not commenting on whether or not that's= a good thing, or a bad thing - just that it does change the relationship. T= his change has been at the root of some of the long-running discussions as t= o whether protocols under development were RFC 5444 compliant or not. The go= al of this document being to eliminate (it's a goal, probably not reachable)= those discussions, I'd like to see that information in the document in some= form. 

I'm interested in seeing this document= progress, and eventually be published. I think it will help future protocol= designers to better use RFC 5444. But I would like to see *something* along= the lines of what Lotte is requesting, as I think it will improve the doc.&= nbsp;

Regards,
Stan

<= div> 
* As the exact rules for using/setting= the hop count & hop-limit fields are currently being discussed w/ regar= d to AODVv2 in another thread [2]=E2=80=93 should a definitive answer to tha= t question be part of 5444-usage?

You= don't want that. Because if we did specify that you'd find yourself more co= nstrained than you want to be. There is a design intent described in 5444, b= ut it assumes immutable messages. Which you don't want. Really, we're doing y= ou a favour by not imposing on you.

=
Best regards,
Lotte

[1] https://www.ietf.org/mail-archive/web/manet/current/msg1808= 2.html

=
Am 06.04.2016 um 19:14 schrieb= Justin Dean <b= ebemaster@gmail.com>:

The chairs agree= that a 3 week WGLC is appropriate.  Everyone please read the draft ear= ly and get comments in early so that they can be addressed within the last c= all period.

Justin
=
On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Chr= istopher (UK) <chris.dearlove@baesystems.com> wrot= e:
Obviously +1 to the request for WGLC.
With regard to what's changed, technically the only significant thing is to m= ake it clear that if a protocol delivers a message to the multiplexer, the m= ultiplexer must pass it on unchanged to the protocol (another instance of, a= t another router) unchanged. Without that nothing that the protocol itself c= hooses to do with regard to security makes sense. Though the protocol can al= ternatively let the multiplexer do the security, 7182 can be implemented in e= ither way. This isn't really new, but it wasn't formally spelled out. It's p= resented as part of spelling out multiplexer rules more carefully.

But what about message optimisation? That's a function of constructing a 544= 4 message, not the multiplexer, and is down to that 5444 includes two things= - packet/message structure (and implicitly, and in pretty much any implemen= tation I would expect to see, a parser and builder for that structure) and t= he multiplexer. So we took the opportunity to separate out more clearly a di= scussion of the two, which we think will be helpful.

--
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

-----Original Message-----
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg
Sent: 05 April 2016 20:08
To: manet@ietf.org Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

----------------------! WARNING ! ---------------------- This message origin= ates from outside our organisation, either from an external partner or from t= he internet.
Consider carefully whether you should click on any links, open any attachmen= ts or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on= reporting suspicious email messages.
--------------------------------------------------------

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


Hi,

As you have seen, we have submitted a new revision of 5444-usage. The author= s feel comfortable that we have addressed all issues by this version, and wo= uld like to ask the WG chairs to issue a WGLC on this document. While it is a= fairly short document, given that it is IETF week for some, we'd suggest th= at a 3-4 week WGLC would be appropriate.

Best regards
Ulrich

_______________________________________________
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

______________________________= _________________
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-2A210C7F-E66D-43DB-A3A8-48F53DF31737-- From nobody Fri Apr 15 13:38: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 9A51D12DCE5 for ; Fri, 15 Apr 2016 13:38:32 -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=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 WBeY2qDzcl8e for ; Fri, 15 Apr 2016 13:38:31 -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 BFEA612DE27 for ; Fri, 15 Apr 2016 13:31:20 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id e185so160584457vkb.1 for ; Fri, 15 Apr 2016 13:31:20 -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=mJ2XJWYf6rolh8tMRF8DiLOT4wlUU/4ETyKkOky30nM=; b=XDmUJEwXx6CQOA5ediQtXYBlHXNk/a+mXWYxoH/UfrjETUQY516R7I+8lCuCcls72+ OtT4Em/8NUlOrhUl47Od7nmL7j2xGS05mfcZEWzrEinjpnOFr5eLskJMbNGsLxbAA7eY CSjjLUAokjvzTD6acr01kn4RW3FCZlNSGAX2Tp2+4HqTZDNEDzkOZrCig8sYAyqyw4NS 0dAETjk3JTCf/c/4CDaGchUNUjCJVRyPxii/S18jrAdvKfoxKyVIo57mxsmuhLyc12f/ LsWjO2pWY+qHWGKNK2xZexe6zvNdIe3KFpAlOcV7r88ErB4znIgh3iZ0+03vQ+96BbXz tZGQ== 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=mJ2XJWYf6rolh8tMRF8DiLOT4wlUU/4ETyKkOky30nM=; b=Oc/OyIS/tcYNduEm9FAS2veO1dyC2Oo+WK5Rrya0bB8yPHRFoPTvqPSmqa1Wdox+Yv P2SKFO8u/jC1BzuswlZmE0NlbudhNaVR4FSyJ48/x76jUSn0s5aFWfMovUW0BGuhNDxm 9vjRf/zY3skQXBvRE0rNGNoXVK6Nf+xSMwJXm6bd7GcznX075mZjjb7wK7P+CGtpWBnb v4AIiAJqUA29/BrkiazUnm88DKzw2+iNd9NNire2RJXRvfSle3jg1Q609G0tpWpTb3jA uPxbmvqdbGdl6a4FfreT8UT85adlv7sGQHPZU0++0LQ0CH9g6THeyTNTTVCsN/bM+rKQ Cc2A== X-Gm-Message-State: AOPr4FXamxMqH/a6b89lBbu3wdlgVdjo8y/u2siQ8FaKaMR45/qR3bcqXq1HDqDuQsgF3VKPvaYFXr9zI+Qh6A== MIME-Version: 1.0 X-Received: by 10.159.37.180 with SMTP id 49mr12037343uaf.148.1460752279724; Fri, 15 Apr 2016 13:31:19 -0700 (PDT) Received: by 10.176.68.65 with HTTP; Fri, 15 Apr 2016 13:31:19 -0700 (PDT) Date: Fri, 15 Apr 2016 21:31:19 +0100 Message-ID: From: Victoria Mercieca To: manet Content-Type: multipart/alternative; boundary=001a113934f2bce67405308be400 Archived-At: Subject: [manet] Metric TLV for 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: Fri, 15 Apr 2016 20:38:33 -0000 --001a113934f2bce67405308be400 Content-Type: text/plain; charset=UTF-8 Hi everyone, The AODVv2 author team are discussing, amongst other things, our metric TLV, and would appreciate your input. Currently our draft defines a new PATH_METRIC TLV, where we use the type extension to indicate MetricType and the value length varies dependent on metric type. There have been a couple of suggestions of alternatives. 1) Recent suggestions that metric fields in general should use 32 bits. If we go ahead with this, we alter our current metric TLV very slightly, still using Type, Type Extension for indicating MetricType, Length, and Value fields, but with length set to 32 bits for every metric type. 32 bits seems like overkill for a hopcount metric, and suitability for other metric types may vary. 2) Other suggestions that we re-use the LINK_METRIC TLV used by OLSRv2. It has a value length of 16 bits total. If we do use that, I believe we could still use extension type to indicate MetricType like we are currently with our own TLV. I don't believe its a big change to the AODVv2 draft either. We would need define how to set the 'kind' and 'direction' bits for AODVv2 metrics, since ours are accumulated route metrics, rather than link or neighbor metrics. We would love to hear the opinions of the working group on this topic. Any preferences or alternative suggestions? Kind regards, Vicky. --001a113934f2bce67405308be400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi everyone,

The AODVv2 author team are= discussing, amongst other things, our metric TLV, and would appreciate you= r input. Currently our draft defines a new PATH_METRIC TLV, where we use th= e type extension to indicate MetricType and the value length varies depende= nt on metric type.

There have been a couple of sug= gestions of alternatives.

1) Recent suggestions that metric fields in general should use 32 b= its. If we go ahead with this, we alter our current metric TLV very slightl= y, still using Type, Type Extension for indicating MetricType, Length, and = Value fields, but with length set to 32 bits for every metric type. 32 bits= seems like overkill for a hopcount metric, and suitability for other metri= c types may vary.

2) Other suggestions that we re-use the LINK_METRIC T= LV used by OLSRv2. It has a value length of 16 bits total. If we do use tha= t, I believe we could still use extension type to indicate MetricType like = we are currently with our own TLV. I don't believe its a big change to = the AODVv2 draft either.=C2=A0We would nee= d define how to set the 'kind' and 'direction' bits for AOD= Vv2 metrics, since ours are accumulated route metrics, rather than link or = neighbor metrics.

We= would love to hear the opinions of the working group on this topic. Any pr= eferences or alternative suggestions?

Kind regards,
Vicky.

--001a113934f2bce67405308be400-- From nobody Fri Apr 15 13:54: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 D38C912D136 for ; Fri, 15 Apr 2016 13:54:55 -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 RNAZraefFhug for ; Fri, 15 Apr 2016 13:54:54 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 D892312D0A7 for ; Fri, 15 Apr 2016 13:54:53 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id e190so159248897lfe.0 for ; Fri, 15 Apr 2016 13:54:53 -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=tcrANficmVi06nfYckKk+UNiNNNp8pzzDOyu/PEhYwE=; b=b8rgWsi+QrA0tc7W4cPu3s8PeqdRS9OCjsHOuVhxssIETH9Jhcm0+S/o6yhKvFFRGF gblUVoOnb+LelJ3aUwxfrf5NJlqxIaY/3Vqs67kqNdlKlHyxNXQ4iSVZp+7rRiy5TupI Nvnv7WayMhJX1BanxTTLZlgr6YVd4/uTmNg20nJR3AKnKmz89slacHpKN69J/5Vsa28T ssABJOYj4Q9jQV7Zm0mb2AgfT0NoaDSqIz0zR54ZYRCum04sBc0yxmuZuStySobq5uj6 skCBy30g25+tjjcH3AvCE2WipEOEs/yruZUmYWLKPvemSPjyYyJhXjvoKmQPwau0UQI7 co7Q== 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=tcrANficmVi06nfYckKk+UNiNNNp8pzzDOyu/PEhYwE=; b=JUmJ0JY0ApLoMs9h41RzgZ0n/tJxIfl/y9Aky4ltrls1EsBD6GpRKPy+5qfSD+VP2+ GNupQHn5bgFwFq3dPzFGhA2vhg6T3PQgfrt8IHuJIge08WADBzPqxEIZ8r09AXJJ4XLb L9fxpW9Vq7zd2WP9A0i6JWzrOV2TBYsAyQ6yaY+wd5Ivks24WapMveFHF27JKA13vm+z mkfwVsnGsCwbAmh6dAQk/NJTpQEqHqC8dlxWxzmvKELYAlaBH44lr5pGiBz6TVvswazf iqr+vgLAA2E2/HEh8lblc5ZMV6SGWBlwoCdSoid0gzBAKP23Z7x1VQwN6ZK6T9yTHSM6 MFXQ== X-Gm-Message-State: AOPr4FWp4lTHUtW9GADQAP4qNYmXwpFEuQhiA8COfgHalrXCBCpdh0B0csj8D5LFOSkSPuUUdCGUQLg1zZDK4Q== X-Received: by 10.112.162.169 with SMTP id yb9mr9644796lbb.70.1460753692073; Fri, 15 Apr 2016 13:54:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.30 with HTTP; Fri, 15 Apr 2016 13:54:22 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Fri, 15 Apr 2016 22:54:22 +0200 Message-ID: To: Victoria Mercieca Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: manet Subject: Re: [manet] Metric TLV for 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: Fri, 15 Apr 2016 20:54:56 -0000 On Fri, Apr 15, 2016 at 10:31 PM, Victoria Mercieca wrote: > Hi everyone, > > The AODVv2 author team are discussing, amongst other things, our metric TLV, > and would appreciate your input. Currently our draft defines a new > PATH_METRIC TLV, where we use the type extension to indicate MetricType and > the value length varies dependent on metric type. > > There have been a couple of suggestions of alternatives. > > 1) Recent suggestions that metric fields in general should use 32 bits. If > we go ahead with this, we alter our current metric TLV very slightly, still > using Type, Type Extension for indicating MetricType, Length, and Value > fields, but with length set to 32 bits for every metric type. 32 bits seems > like overkill for a hopcount metric, and suitability for other metric types > may vary. 32 bit would also have the same range as the "path cost" of OLSRv2... > 2) Other suggestions that we re-use the LINK_METRIC TLV used by OLSRv2. It > has a value length of 16 bits total. If we do use that, I believe we could > still use extension type to indicate MetricType like we are currently with > our own TLV. I don't believe its a big change to the AODVv2 draft either. We > would need define how to set the 'kind' and 'direction' bits for AODVv2 > metrics, since ours are accumulated route metrics, rather than link or > neighbor metrics. This doesn't work because the LINK_METRIC TLV has an exponential encoding. It is not really useful for path metrics. Henning Rogge From nobody Fri Apr 15 14:07: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 5DA0912E402 for ; Fri, 15 Apr 2016 14:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, 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 lEO-Ue9cCkqI for ; Fri, 15 Apr 2016 14:07:19 -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 E6C8F12E3FA for ; Fri, 15 Apr 2016 14:07:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: "'Henning Rogge'" , "'Victoria Mercieca'" References: In-Reply-To: Date: Fri, 15 Apr 2016 17:07:16 -0400 Message-ID: <017401d1975a$caa09f30$5fe1dd90$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKbubd7pmJana75zkeiQuoqQ2sl/AHv10xFnefC8YA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'manet' Subject: Re: [manet] Metric TLV for 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: Fri, 15 Apr 2016 21:07:20 -0000 Henning: Can you explain why OLSRv2 used exponential encoding for a link? I'm trying to compare this with the ISIS/OSPF link metrics and the TE metrics. Sue -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: Friday, April 15, 2016 4:54 PM To: Victoria Mercieca Cc: manet Subject: Re: [manet] Metric TLV for AODVv2 On Fri, Apr 15, 2016 at 10:31 PM, Victoria Mercieca wrote: > Hi everyone, > > The AODVv2 author team are discussing, amongst other things, our > metric TLV, and would appreciate your input. Currently our draft > defines a new PATH_METRIC TLV, where we use the type extension to > indicate MetricType and the value length varies dependent on metric type. > > There have been a couple of suggestions of alternatives. > > 1) Recent suggestions that metric fields in general should use 32 > bits. If we go ahead with this, we alter our current metric TLV very > slightly, still using Type, Type Extension for indicating MetricType, > Length, and Value fields, but with length set to 32 bits for every > metric type. 32 bits seems like overkill for a hopcount metric, and > suitability for other metric types may vary. 32 bit would also have the same range as the "path cost" of OLSRv2... > 2) Other suggestions that we re-use the LINK_METRIC TLV used by > OLSRv2. It has a value length of 16 bits total. If we do use that, I > believe we could still use extension type to indicate MetricType like > we are currently with our own TLV. I don't believe its a big change to > the AODVv2 draft either. We would need define how to set the 'kind' > and 'direction' bits for AODVv2 metrics, since ours are accumulated > route metrics, rather than link or neighbor metrics. This doesn't work because the LINK_METRIC TLV has an exponential encoding. It is not really useful for path metrics. Henning Rogge _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From nobody Fri Apr 15 14: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 2A8D812DB17 for ; Fri, 15 Apr 2016 14:10:13 -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 20bztdGde-QH for ; Fri, 15 Apr 2016 14:10:11 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 79F9D12DB5F for ; Fri, 15 Apr 2016 14:10:11 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id e190so159620972lfe.0 for ; Fri, 15 Apr 2016 14:10:11 -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=uTqhT0LvhBvfoQje8I0cfNL4E3Khn1bAEoC+NJQ341Q=; b=GwAQ48MNyGKFTzwYYmYR4aQgLG11pyoIptzBKlEqlemm/RI8gPoFn52l8mxEQiRs1u mw6GcBpjfdzCgD1NhihLF4WpIFcqdnEdKpvq4NBRdRP2BAxOIljGRtgh21xVGXbb4A8I f9SbxSPvad6WLExQ+5jVVU/2H1N6bqkytjRuh8rZshKneRy7UJyBCL+9DMr+hqGQ9/cx KAX1qT8l3irDDbSithM/fn4D3SHPcsu+YyI/aPqaIW2yznDyoXKOzjpH4bxYDSujR2qt xl9DSQZFXXAXMjrkWMKlA6DlmXWPP+PKVPONvi5dEGQUvU7ffXLLa9N5e9AL4r1i72cf TzkA== 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=uTqhT0LvhBvfoQje8I0cfNL4E3Khn1bAEoC+NJQ341Q=; b=Tz/seVB/Hgk0hbsHRFQf5eNBmizAYOVF0lWOyP6EZInQyPiVlxpiUyUXr/h10FQfJb 95NH2ibSIbMx0SBprNCKCMZ0XOlAn+WqzfPY9yWn9yYPUcBpt2nKmNxVUp3PV1qG/zj+ CoEL+KHmCT/G6SqmvupzHBVYgtLsZOcGoyLpo8NnKz9OS1kOLE1f1RQhnUBNgbUVdyHe VgUowGrsBcfYCi9WKQvz/KKne5CcFqq5+BRNiP3HmXD4FGrCZAnHdzHSAb84UuqtVUG0 c085ZfF9ot1X3HfeFLC0ez0Wkfr8e663Q7EzrtRl8wvyeBgZ0hh1QoHPPcv4XT147sfJ 4Zdw== X-Gm-Message-State: AOPr4FVqelim3zhnEYx0YpZgqElnQDXrQoRaL1Aa2HAlS0kPL2txx2gmvXPu+4VHhv+NQ41l/OY/Mdu5ioyrQw== X-Received: by 10.25.27.12 with SMTP id b12mr9520547lfb.92.1460754609467; Fri, 15 Apr 2016 14:10:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.30 with HTTP; Fri, 15 Apr 2016 14:09:39 -0700 (PDT) In-Reply-To: <017401d1975a$caa09f30$5fe1dd90$@ndzh.com> References: <017401d1975a$caa09f30$5fe1dd90$@ndzh.com> From: Henning Rogge Date: Fri, 15 Apr 2016 23:09:39 +0200 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: manet , Victoria Mercieca Subject: Re: [manet] Metric TLV for 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: Fri, 15 Apr 2016 21:10:13 -0000 On Fri, Apr 15, 2016 at 11:07 PM, Susan Hares wrote: > Henning: > > Can you explain why OLSRv2 used exponential encoding for a link? I'm trying > to compare this with the ISIS/OSPF link metrics and the TE metrics. https://tools.ietf.org/html/rfc7181#section-6.2 The OLSRv2 metric encoding use an 8 bit mantissa and a 4 bit exponent. That works well for a Link State protocol, but not for Distance Vector ones. Henning Rogge From nobody Fri Apr 15 14:15: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 5AD0012D81E for ; Fri, 15 Apr 2016 14:15:06 -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 32PkcIs0nmVX for ; Fri, 15 Apr 2016 14:15:03 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c: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 04BE712D695 for ; Fri, 15 Apr 2016 14:15:03 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id v188so47049585wme.1 for ; Fri, 15 Apr 2016 14:15:02 -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=ndFokkf11OVpjp4a5lqb8ZQRAnggYMjcUds6vLP58L4=; b=wDH8QU3UauOVlo57+kI7t1lkBA5rqwQLlg3loLKFAY8LoaCqP6ciuwNN/rtzOifvUl Z5EPtWNjXgLR9w3hjUKvtW38jg9BTNyEH3Lsc50ehfZ3pVMyLRC9zZ6/67u3aaaISzZy dWlOkm4lQ4qnmZWqQB8LHBzVlxbv9h074aPL2iuvWy8/dI60K4ix5gSe9iJWiZ0YFWEf zOauk7o3cPOkVzCw5s/Zo127r1MRNslLhlM9nyflgc1IH60wuHWECDTaHG/1cnA+vIDX aM8nWNFf1tG0oHhZ2f/yZhyBn0pR2C7PgyaslSN3CiE1aH8xtkqmNU4sXvshHuVZiPXm DBJQ== 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=ndFokkf11OVpjp4a5lqb8ZQRAnggYMjcUds6vLP58L4=; b=WgUCopQaAxLVgnFZMlBgpXi2GG8uRA653MikS3pNPprfoU1S6okBaOTxjwNBCexrv5 yh6TKv7uYNwt9G2oMCPRkSpxvKvoQG/89Lq8F7O3DSLsGTJgK7PN1mtHRuDDCIKzICyi PfVh868ChN/Oy9J11jzbRifVGZdB73Kde7ziuEmHA4yoDPAjon7uMRpLuwIap4ji6kC5 o+JRoiEB6f1We0AanxqWfWOE2RjSd9Osd6Z1UgDBrwtGeLKLyU/w287lL0gEO9a4D8aE eEyl1Bnz117HIgHLkg+i7HZ6/HG6NXAlqaBjG6BYdroCaRA2Bg++hJ0lIGVQ8Yta9d1T XSXQ== X-Gm-Message-State: AOPr4FWueZt4ktvwqemH2ZzdlgwO0/9XReU2GI39n+mFas9Dw5rgBNCZ9G3YvuROJOujDQ== X-Received: by 10.28.129.208 with SMTP id c199mr6640540wmd.75.1460754901533; Fri, 15 Apr 2016 14:15:01 -0700 (PDT) Received: from [10.2.93.92] (dab-hlw1-w-1-3.dab.02.net. [82.132.232.9]) by smtp.gmail.com with ESMTPSA id u3sm40080996wmg.15.2016.04.15.14.15.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2016 14:15:00 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-8AA40310-A1C4-4DC2-AD44-020F757454D7 Content-Transfer-Encoding: 7bit Message-Id: <70D6C054-3F73-4C1A-9189-33939F88C37A@gmail.com> X-Mailer: iPhone Mail (13E238) From: Christopher Dearlove Date: Fri, 15 Apr 2016 22:14:56 +0100 To: Victoria Mercieca Archived-At: Cc: manet Subject: Re: [manet] Metric TLV for 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: Fri, 15 Apr 2016 21:15:06 -0000 --Apple-Mail-8AA40310-A1C4-4DC2-AD44-020F757454D7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I'm not going to jump in with a suggestion right now, but rather to summaris= e what I think are the key features of the OLSRv2 metric. First, the 16 bit value field is, as you've noted, 4 flag bits and 12 data b= its. I'll consider those in turn and then other aspects. The 4 flag bits are specified with link state in mind. The incoming/outgoing= is obviously straightforward. (If bidirectional - though I don't believe th= at is reliable - just set both.) But link/neighbour are neither route, so re= interpretation would be needed. The 12 bits are a compressed form of a 28 bit representation. Why 28? Becaus= e accumulating 255 (or even 256) of them can't exceed 32 bits. So the OLSRv2= usage is to send compressed link metrics that are expanded, summed exactly a= nd used locally. You never need to convert a 32 but value back to compressed= representation. But now you would have to sum and convert back. That poses three problems. T= he first is range, 28 bits is now a bit odd. But quite usable. The second is= overflow. Which I suggest saturates at maximum. The third is rounding. The s= um of two representable values is not, in general, representable. So you nee= d a well-defined rounding rule. Not hard, but needed. Assuming you're over all that, what about someone who says we don't need two= octet a for hop count. Here I refer you to 7188 which has ruled (currently o= nly mandated for NHDP/OLSRv2) for what if TLV value fields are short. If you= adopted those, you could use one octet values, and for hop count just one v= alue. Except that doesn't play nicely with the route metric ideas above, so i= t doesn't work for you. Never mind, worth trying. But note that going back t= o two octets, we can represent all values from 1 to 256 exactly, hence hop c= ount exactly, without rounding issues, if you use 1 (coded as 0) as your one= metric value. (Actually some other values work too, but ignore them.) Now what about meaning? Well, so far reserved are just 8 values for administ= rative definition. There are good reasons to want those. (It was increased t= o 8 in MT btw.) Even Henning's draft (going for an AUTH48 record Henning?) d= oesn't reserve a code point. We didn't reserve code points for specific meanings (delay, bandwidth etc.) f= or a variety of reasons. And any reservations would need careful thought. Bu= t the whole point of the OLSRv2 design was to never need to know about alloc= ations within OLSRv2. (Of course whatever process, probably cross-layer, tha= t comes up with values needs to know. But no OLSRv2 code would need to chang= e if code point 57 were allocated tomorrow as delay in nanofortnights.) Anyway, as I said, not coming down any way in particular here. Just indicati= ng factors I think matter, and if you pick this route need answers. (All ans= wers are possible.) Of course other routes have their own questions. (And something to seriously consider if using another approach is the protoc= ol-specific TLV type space.) --=20 Christopher Dearlove > On 15 Apr 2016, at 21:31, Victoria Mercieca wrote: >=20 > Hi everyone, >=20 > The AODVv2 author team are discussing, amongst other things, our metric TL= V, and would appreciate your input. Currently our draft defines a new PATH_M= ETRIC TLV, where we use the type extension to indicate MetricType and the va= lue length varies dependent on metric type. >=20 > There have been a couple of suggestions of alternatives. >=20 > 1) Recent suggestions that metric fields in general should use 32 bits. If= we go ahead with this, we alter our current metric TLV very slightly, still= using Type, Type Extension for indicating MetricType, Length, and Value fie= lds, but with length set to 32 bits for every metric type. 32 bits seems lik= e overkill for a hopcount metric, and suitability for other metric types may= vary. >=20 > 2) Other suggestions that we re-use the LINK_METRIC TLV used by OLSRv2. It= has a value length of 16 bits total. If we do use that, I believe we could s= till use extension type to indicate MetricType like we are currently with ou= r own TLV. I don't believe its a big change to the AODVv2 draft either. We w= ould need define how to set the 'kind' and 'direction' bits for AODVv2 metri= cs, since ours are accumulated route metrics, rather than link or neighbor m= etrics. >=20 > We would love to hear the opinions of the working group on this topic. Any= preferences or alternative suggestions? >=20 > Kind regards, > Vicky. >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-8AA40310-A1C4-4DC2-AD44-020F757454D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I'm not going to jump in with a sugges= tion right now, but rather to summarise what I think are the key features of= the OLSRv2 metric.

First, the 16 bit value field is, as you've noted, 4 fl= ag bits and 12 data bits. I'll consider those in turn and then other aspects= .

The 4 flag bits are specified with link state in mind. The incoming/outgo= ing is obviously straightforward. (If bidirectional - though I don't believe= that is reliable - just set both.) But link/neighbour are neither route, so= reinterpretation would be needed.

<= /div>
The 12 bits are a compressed form of a 2= 8 bit representation. Why 28? Because accumulating 255 (or even 256) of them= can't exceed 32 bits. So the OLSRv2 usage is to send compressed link metric= s that are expanded, summed exactly and used locally. You never need to conv= ert a 32 but value back to compressed representation.

But now you would hav= e to sum and convert back. That poses three problems. The first is range, 28= bits is now a bit odd. But quite usable. The second is overflow. Which I su= ggest saturates at maximum. The third is rounding. The sum of two representa= ble values is not, in general, representable. So you need a well-defined rou= nding rule. Not hard, but needed.

Assuming you're over all that, what about= someone who says we don't need two octet a for hop count. Here I refer you t= o 7188 which has ruled (currently only mandated for NHDP/OLSRv2) for what if= TLV value fields are short. If you adopted those, you could use one octet v= alues, and for hop count just one value. Except that doesn't play nicely wit= h the route metric ideas above, so it doesn't work for you. Never mind, wort= h trying. But note that going back to two octets, we can represent all value= s from 1 to 256 exactly, hence hop count exactly, without rounding issues, i= f you use 1 (coded as 0) as your one metric value. (Actually some other valu= es work too, but ignore them.)

Now what about meaning? Well, so far reserve= d are just 8 values for administrative definition. There are good reasons to= want those. (It was increased to 8 in MT btw.) Even Henning's draft (going f= or an AUTH48 record Henning?) doesn't reserve a code point.

We didn't reser= ve code points for specific meanings (delay, bandwidth etc.) for a variety o= f reasons. And any reservations would need careful thought. But the whole po= int of the OLSRv2 design was to never need to know about allocations within O= LSRv2. (Of course whatever process, probably cross-layer, that comes up with= values needs to know. But no OLSRv2 code would need to change if code point= 57 were allocated tomorrow as delay in nanofortnights.)

Anyway, as I said,= not coming down any way in particular here. Just indicating factors I think= matter, and if you pick this route need answers. (All answers are possible.= ) Of course other routes have their own questions.

(And something to seriou= sly consider if using another approach is the protocol-specific TLV type spa= ce.)

-- 
Christopher Dearlove

On 15 Apr 2= 016, at 21:31, Victoria Mercieca <vmercieca0@gmail.com> wrote:

=
Hi everyone,

The AODVv2 author team= are discussing, amongst other things, our metric TLV, and would appreciate y= our input. Currently our draft defines a new PATH_METRIC TLV, where we use t= he type extension to indicate MetricType and the value length varies depende= nt on metric type.

There have been a couple of sugg= estions of alternatives.

1) Recent suggestions that metric fields in general should use 32 bits= . If we go ahead with this, we alter our current metric TLV very slightly, s= till using Type, Type Extension for indicating MetricType, Length, and Value= fields, but with length set to 32 bits for every metric type. 32 bits seems= like overkill for a hopcount metric, and suitability for other metric types= may vary.

2) Other suggestions that we re-use the LINK_METRIC TLV used b= y OLSRv2. It has a value length of 16 bits total. If we do use that, I belie= ve we could still use extension type to indicate MetricType like we are curr= ently with our own TLV. I don't believe its a big change to the AODVv2 draft= either. We would need define how to s= et the 'kind' and 'direction' bits for AODVv2 metrics, since ours are accumu= lated route metrics, rather than link or neighbor metrics.

We would love to hear the opinions of the w= orking group on this topic. Any preferences or alternative suggestions?
Kind regards,
Vicky.


____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-8AA40310-A1C4-4DC2-AD44-020F757454D7-- From nobody Fri Apr 15 14:18: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 8A8E912E4AF for ; Fri, 15 Apr 2016 14:18:28 -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 RL184aiLas0C for ; Fri, 15 Apr 2016 14:18:26 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 7EA7912E4A1 for ; Fri, 15 Apr 2016 14:18:26 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id l6so9139912wml.3 for ; Fri, 15 Apr 2016 14:18:26 -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=do/wvmlIARl7QAlvuooWsIhSSLZFTnnqsC4PMdLsfyw=; b=v1s2xTARRiqvO0m5hNvj5+zcI8JogiYm29g/dk+iREwFn4pEeYYR3fu68jOl3O4gz0 rD4a3q7TGSOAQ015iaqU6qo7ZAWdfLGafCo6C0ak16B0xwFYrCuYtb7gOBtGAzKT1g4x eAmScCTFwNHYDlWtp9Hnc4tmGbaCI2KVUqmYxQBnhEkNXKNxOZNUqb9J7a1nO5hOv1zp oTsga1UOTaPxtrVUVH+G5nvjF4SwC6rsulXw5ZRlePG17V2i/qpyv/B2Pq266bCNeFO+ da8WiV65yKIkkDYOqjErgU71Ie2ymv5yd8d+1gf69UBtSsujPkUjLYTXOhDqB+yHOHgv 5G4w== 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=do/wvmlIARl7QAlvuooWsIhSSLZFTnnqsC4PMdLsfyw=; b=TZv8hZLgsptyGwMcgrBlzPgW6xbAeTFGxsxdQVexI3vfcrCYc5mkeV2gBfKvlAFvUf Epp+nW57ELkz/cBO06iORxEYYzyYK0nEfI+SbZaGLgG94ibWqRAwsT6b66WX2vADhqTp zKxeNAnlBTIyHzn33yL61ZxQr2cu3qavGvxxMZXPIkcqYGnUPI4PN0UX+RqRHPgWoDnm pfbzw+L4jcYmmCZ39whcWq87BNVMn1dWmhsnqhKSoQ3NZFNVqbQV6rB8BumQwBgcCGtQ RzukDaQdjd5H6aqMWzqSXcNBp6p5w5VbfrnJPW6i7DisMJWKMs7Ho17yiWr/XMkMd8KX y4ww== X-Gm-Message-State: AOPr4FWu6phAlEYoBc6jwTrcmMd7b0QiR0J1MbI+DsOLfSlU5SBa3PWCN+NXEJr4pxNSSg== X-Received: by 10.194.158.98 with SMTP id wt2mr23326747wjb.102.1460755105109; Fri, 15 Apr 2016 14:18:25 -0700 (PDT) Received: from [10.2.93.92] (dab-hlw1-w-1-3.dab.02.net. [82.132.232.9]) by smtp.gmail.com with ESMTPSA id a1sm50586558wje.43.2016.04.15.14.18.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2016 14:18:23 -0700 (PDT) References: <017401d1975a$caa09f30$5fe1dd90$@ndzh.com> Mime-Version: 1.0 (1.0) In-Reply-To: <017401d1975a$caa09f30$5fe1dd90$@ndzh.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (13E238) From: Christopher Dearlove Date: Fri, 15 Apr 2016 22:18:19 +0100 To: Susan Hares Archived-At: Cc: manet , Victoria Mercieca Subject: Re: [manet] Metric TLV for 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: Fri, 15 Apr 2016 21:18:28 -0000 See RFC 7185. But in short, because it worked and was compact. As Henning has said, it's d= esigned for link metrics, see my other posting. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 15 Apr 2016, at 22:07, Susan Hares wrote: >=20 > Henning:=20 >=20 > Can you explain why OLSRv2 used exponential encoding for a link? I'm tryi= ng > to compare this with the ISIS/OSPF link metrics and the TE metrics.=20 >=20 > Sue=20 >=20 > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge > Sent: Friday, April 15, 2016 4:54 PM > To: Victoria Mercieca > Cc: manet > Subject: Re: [manet] Metric TLV for AODVv2 >=20 > On Fri, Apr 15, 2016 at 10:31 PM, Victoria Mercieca = > wrote: >> Hi everyone, >>=20 >> The AODVv2 author team are discussing, amongst other things, our=20 >> metric TLV, and would appreciate your input. Currently our draft=20 >> defines a new PATH_METRIC TLV, where we use the type extension to=20 >> indicate MetricType and the value length varies dependent on metric type.= >>=20 >> There have been a couple of suggestions of alternatives. >>=20 >> 1) Recent suggestions that metric fields in general should use 32=20 >> bits. If we go ahead with this, we alter our current metric TLV very=20 >> slightly, still using Type, Type Extension for indicating MetricType,=20 >> Length, and Value fields, but with length set to 32 bits for every=20 >> metric type. 32 bits seems like overkill for a hopcount metric, and=20 >> suitability for other metric types may vary. >=20 > 32 bit would also have the same range as the "path cost" of OLSRv2... >=20 >> 2) Other suggestions that we re-use the LINK_METRIC TLV used by=20 >> OLSRv2. It has a value length of 16 bits total. If we do use that, I=20 >> believe we could still use extension type to indicate MetricType like=20 >> we are currently with our own TLV. I don't believe its a big change to=20= >> the AODVv2 draft either. We would need define how to set the 'kind'=20 >> and 'direction' bits for AODVv2 metrics, since ours are accumulated=20 >> route metrics, rather than link or neighbor metrics. >=20 > This doesn't work because the LINK_METRIC TLV has an exponential encoding.= > It is not really useful for path metrics. >=20 > Henning Rogge >=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 From nobody Fri Apr 15 14:18: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 C775F12D61E for ; Fri, 15 Apr 2016 14:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, 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 XDCIKV6W0Iit for ; Fri, 15 Apr 2016 14:18:54 -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 BE68912D71C for ; Fri, 15 Apr 2016 14:18:53 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: "'Henning Rogge'" References: <017401d1975a$caa09f30$5fe1dd90$@ndzh.com> In-Reply-To: Date: Fri, 15 Apr 2016 17:18:51 -0400 Message-ID: <000001d1975c$68eaf8b0$3ac0ea10$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKbubd7pmJana75zkeiQuoqQ2sl/AHv10xFAcIcYJQCKrtTDZ3IX5Jg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'manet' , 'Victoria Mercieca' Subject: Re: [manet] Metric TLV for 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: Fri, 15 Apr 2016 21:18:55 -0000 Henning:=20 Thanks for the explanation and the pointer. It will help me dig into = the TE links for Distance vector/Path Vector (BGP) versus link-state.=20 Sue=20 -----Original Message----- From: Henning Rogge [mailto:hrogge@gmail.com]=20 Sent: Friday, April 15, 2016 5:10 PM To: Susan Hares Cc: Victoria Mercieca; manet Subject: Re: [manet] Metric TLV for AODVv2 On Fri, Apr 15, 2016 at 11:07 PM, Susan Hares wrote: > Henning: > > Can you explain why OLSRv2 used exponential encoding for a link? I'm=20 > trying to compare this with the ISIS/OSPF link metrics and the TE = metrics. https://tools.ietf.org/html/rfc7181#section-6.2 The OLSRv2 metric encoding use an 8 bit mantissa and a 4 bit exponent. That works well for a Link State protocol, but not for Distance Vector = ones. Henning Rogge From nobody Fri Apr 15 14:20: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 C951312D71C for ; Fri, 15 Apr 2016 14:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, 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 9PqNiQEtefYp for ; Fri, 15 Apr 2016 14:20:06 -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 0AC9A12D09E for ; Fri, 15 Apr 2016 14:20:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: "'Christopher Dearlove'" References: <017401d1975a$caa09f30$5fe1dd90$@ndzh.com> In-Reply-To: Date: Fri, 15 Apr 2016 17:20:03 -0400 Message-ID: <000801d1975c$939b50f0$bad1f2d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKbubd7pmJana75zkeiQuoqQ2sl/AHv10xFAcIcYJQCsrTLip3EIEpA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'manet' , 'Victoria Mercieca' Subject: Re: [manet] Metric TLV for 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: Fri, 15 Apr 2016 21:20:07 -0000 Chris: Thanks for this posting and the other posting. It was very helpful on a Friday evening. Sue -----Original Message----- From: Christopher Dearlove [mailto:christopher.dearlove@gmail.com] Sent: Friday, April 15, 2016 5:18 PM To: Susan Hares Cc: Henning Rogge; Victoria Mercieca; manet Subject: Re: [manet] Metric TLV for AODVv2 See RFC 7185. But in short, because it worked and was compact. As Henning has said, it's designed for link metrics, see my other posting. -- Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 15 Apr 2016, at 22:07, Susan Hares wrote: > > Henning: > > Can you explain why OLSRv2 used exponential encoding for a link? I'm > trying to compare this with the ISIS/OSPF link metrics and the TE metrics. > > Sue > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge > Sent: Friday, April 15, 2016 4:54 PM > To: Victoria Mercieca > Cc: manet > Subject: Re: [manet] Metric TLV for AODVv2 > > On Fri, Apr 15, 2016 at 10:31 PM, Victoria Mercieca > > wrote: >> Hi everyone, >> >> The AODVv2 author team are discussing, amongst other things, our >> metric TLV, and would appreciate your input. Currently our draft >> defines a new PATH_METRIC TLV, where we use the type extension to >> indicate MetricType and the value length varies dependent on metric type. >> >> There have been a couple of suggestions of alternatives. >> >> 1) Recent suggestions that metric fields in general should use 32 >> bits. If we go ahead with this, we alter our current metric TLV very >> slightly, still using Type, Type Extension for indicating MetricType, >> Length, and Value fields, but with length set to 32 bits for every >> metric type. 32 bits seems like overkill for a hopcount metric, and >> suitability for other metric types may vary. > > 32 bit would also have the same range as the "path cost" of OLSRv2... > >> 2) Other suggestions that we re-use the LINK_METRIC TLV used by >> OLSRv2. It has a value length of 16 bits total. If we do use that, I >> believe we could still use extension type to indicate MetricType like >> we are currently with our own TLV. I don't believe its a big change >> to the AODVv2 draft either. We would need define how to set the 'kind' >> and 'direction' bits for AODVv2 metrics, since ours are accumulated >> route metrics, rather than link or neighbor metrics. > > This doesn't work because the LINK_METRIC TLV has an exponential encoding. > It is not really useful for path metrics. > > Henning Rogge > > _______________________________________________ > 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 From nobody Fri Apr 15 14:21: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 943BB12D577 for ; Fri, 15 Apr 2016 14:21: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, 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 xp3FomMLeWC4 for ; Fri, 15 Apr 2016 14:21:18 -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 2422112D9CD for ; Fri, 15 Apr 2016 14:21:18 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id v188so47197907wme.1 for ; Fri, 15 Apr 2016 14:21:18 -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=96f1RHk7Xlt8Rs+DMChU1tFthGahJ0+obmGWa9efQ7A=; b=w/7t+wpGt47SXzAdqjh5sD4+z0gqgo4DLti5gr9ucT+K9mbmV5I2yCuf6ZQyCSMtr1 x7MI8KfZCsA9thap2tbgsq1UrnoWWx61aMP8F70U2V2XDVGayHhX+mVqEKL7nbuWjD0l WYAvsD5pq0Ki3dnQKwokcopvP47s+kyxaDlhlEzE6HkR89Kv06FZOVMuhVJ6WyeDJWkR zcfFVjymN3JvPyXXOIo8aIbIwMZ1yFt1W9dorYJCr7L4CsOEVwQqUp/T12KP/SWz0m2w 9TpW78VOVw88ZljHoa7yFjiY1PfW3e8GW0fXJASLE/HLLSbINzWTVp8hvOiY8JvbYwqg N8kQ== 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=96f1RHk7Xlt8Rs+DMChU1tFthGahJ0+obmGWa9efQ7A=; b=NteMBzL11/MIbFLDbrnhg8t7A1ha2WmDAAz1Bh7q+O6vJi6Nh2ZAJzAOmftAVbWF6c GNYNIzPeky1uE1Yuh1TRRCjqZ9itqozi6XRYmV5N0usk5wE0qqC8PwjFYm5OJHewHDwm gKg2dtnsPPBT+mFVoktiWFU22dgeCQ2RGTI1WTG4vkjTHdafBTOh2g6BrdEF8Prnc7i8 VVpQeVus9D/rRovyG1fN2j1HtIxkccnNi/X3f8LmjotKUgxguexPBYtIW8ACjI0SqRqy ISF840x4FlvwC7Y69a5BK6ulSflcD/Na3kL4ZDzjYwDAh950q5PIvTLzZV0udqYNJijN t2DA== X-Gm-Message-State: AOPr4FVFJItQ69ELdcW3iEGYg+OEKoCSF7aFJf0pSu7GYirY7PKo7mrnLNc+cV3eokNwkQ== X-Received: by 10.194.95.198 with SMTP id dm6mr25292849wjb.136.1460755276732; Fri, 15 Apr 2016 14:21:16 -0700 (PDT) Received: from [10.2.93.92] (dab-hlw1-w-1-3.dab.02.net. [82.132.232.9]) by smtp.gmail.com with ESMTPSA id j71sm13348907wmj.21.2016.04.15.14.21.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2016 14:21:16 -0700 (PDT) References: <017401d1975a$caa09f30$5fe1dd90$@ndzh.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8B641049-8808-4AC2-978A-81C129F9CACC@gmail.com> X-Mailer: iPhone Mail (13E238) From: Christopher Dearlove Date: Fri, 15 Apr 2016 22:21:11 +0100 To: Henning Rogge Archived-At: Cc: manet , Victoria Mercieca Subject: Re: [manet] Metric TLV for 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: Fri, 15 Apr 2016 21:21:21 -0000 That's the what. We wrote a whole RFC on the why, as I indicated 7185. --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 15 Apr 2016, at 22:09, Henning Rogge wrote: >=20 >> On Fri, Apr 15, 2016 at 11:07 PM, Susan Hares wrote: >> Henning: >>=20 >> Can you explain why OLSRv2 used exponential encoding for a link? I'm try= ing >> to compare this with the ISIS/OSPF link metrics and the TE metrics. >=20 > https://tools.ietf.org/html/rfc7181#section-6.2 >=20 > The OLSRv2 metric encoding use an 8 bit mantissa and a 4 bit exponent. >=20 > That works well for a Link State protocol, but not for Distance Vector one= s. >=20 > Henning Rogge >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Fri Apr 15 14:25: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 E475612DBA7 for ; Fri, 15 Apr 2016 14:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, 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 LJqAHDnV68I1 for ; Fri, 15 Apr 2016 14:25:44 -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 A7C9612DA4F for ; Fri, 15 Apr 2016 14:25:44 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: "'Christopher Dearlove'" , "'Henning Rogge'" References: <017401d1975a$caa09f30$5fe1dd90$@ndzh.com> <8B641049-8808-4AC2-978A-81C129F9CACC@gmail.com> In-Reply-To: <8B641049-8808-4AC2-978A-81C129F9CACC@gmail.com> Date: Fri, 15 Apr 2016 17:25:43 -0400 Message-ID: <001701d1975d$5e404cc0$1ac0e640$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKbubd7pmJana75zkeiQuoqQ2sl/AHv10xFAcIcYJQCKrtTDQLb2eQAnbGC5GA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'manet' , 'Victoria Mercieca' Subject: Re: [manet] Metric TLV for 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: Fri, 15 Apr 2016 21:25:46 -0000 Christopher: Thanks for the reference to the why. I'll look into RFC7185 this weekend. Sue -----Original Message----- From: Christopher Dearlove [mailto:christopher.dearlove@gmail.com] Sent: Friday, April 15, 2016 5:21 PM To: Henning Rogge Cc: Susan Hares; manet; Victoria Mercieca Subject: Re: [manet] Metric TLV for AODVv2 That's the what. We wrote a whole RFC on the why, as I indicated 7185. -- Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 15 Apr 2016, at 22:09, Henning Rogge wrote: > >> On Fri, Apr 15, 2016 at 11:07 PM, Susan Hares wrote: >> Henning: >> >> Can you explain why OLSRv2 used exponential encoding for a link? I'm >> trying to compare this with the ISIS/OSPF link metrics and the TE metrics. > > https://tools.ietf.org/html/rfc7181#section-6.2 > > The OLSRv2 metric encoding use an 8 bit mantissa and a 4 bit exponent. > > That works well for a Link State protocol, but not for Distance Vector ones. > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Sat Apr 16 02:57: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 7C53912DE30 for ; Sat, 16 Apr 2016 02:57:19 -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 vSz_PCSKY7rA for ; Sat, 16 Apr 2016 02:57: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 BA2C112DE26 for ; Sat, 16 Apr 2016 02:57:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 3B8E0240495; Sat, 16 Apr 2016 02:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1460800637; bh=/kuJrxsroZTKucfAb8roeRrrADSp9cNzb4bgg1sANL8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Ih/8pkD4U3p/O0RKCdDA6Cv6qD7bvVfnpgiTGJNQ6wdqUQkVuJ/WB9kaw2f1pHdQG jRI+s5kBCQrirJhokMUw/yZAH6B4z3qJG3G7Q6iq9HLpzJTfddVi/Dl2Zp0+H39I92 ecUrq2YrYWeMx8N+AkXXjW/kqJjgHVNJqkVoqkm0= 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 3960224028F; Sat, 16 Apr 2016 02:57:16 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-8AEE7C66-AC4F-4ABE-AC6D-465D8886C0C0 Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Sat, 16 Apr 2016 11:57:13 +0200 Content-Transfer-Encoding: 7bit Message-Id: <0486747C-2C70-4B9E-A41E-4C6B4B462F56@thomasclausen.org> References: To: Victoria Mercieca Archived-At: Cc: manet Subject: Re: [manet] Metric TLV for 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: Sat, 16 Apr 2016 09:57:19 -0000 --Apple-Mail-8AEE7C66-AC4F-4ABE-AC6D-465D8886C0C0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Victoria, all, On these matters, I am generally in favor of letting actual experience guide= the decision process.=20 Thus in order to inform that decision process (eg in order to understand if 3= 2 bits are too many/few, if the exponential nature of the encoding of the LI= NK_METRIC TLV would work, etc.), it might help to know something about what m= etrics are used in actual (i.e. outside the controlled confines of a lab, an= d not in a network simulator) AODV (v1/v2) deployments?=20 I would assume that part of the experiment that was RFC3561 would have been t= o understand if not the "kind" of metrics to use (i.e. not if ETT/ETX/DAT/* i= s better/worse, which likely would be heavily media/environment dependent) t= hen at least the range and nature of metrics values that would be useful? Most, if not all, published work I've seen has referred to hop-count in ns2 -= both of which are a poor approximation (on this matter) of what to expect i= n the real world. So, what's actually being used in "real world" deployments, and what lessons= can be drawn from that? Best, Thomas --=20 Thomas Heide Clausen http://www.thomasclausen.org > On 15 avr. 2016, at 22:31, Victoria Mercieca wrote:= >=20 > Hi everyone, >=20 > The AODVv2 author team are discussing, amongst other things, our metric TL= V, and would appreciate your input. Currently our draft defines a new PATH_M= ETRIC TLV, where we use the type extension to indicate MetricType and the va= lue length varies dependent on metric type. >=20 > There have been a couple of suggestions of alternatives. >=20 > 1) Recent suggestions that metric fields in general should use 32 bits. If= we go ahead with this, we alter our current metric TLV very slightly, still= using Type, Type Extension for indicating MetricType, Length, and Value fie= lds, but with length set to 32 bits for every metric type. 32 bits seems lik= e overkill for a hopcount metric, and suitability for other metric types may= vary. >=20 > 2) Other suggestions that we re-use the LINK_METRIC TLV used by OLSRv2. It= has a value length of 16 bits total. If we do use that, I believe we could s= till use extension type to indicate MetricType like we are currently with ou= r own TLV. I don't believe its a big change to the AODVv2 draft either. We w= ould need define how to set the 'kind' and 'direction' bits for AODVv2 metri= cs, since ours are accumulated route metrics, rather than link or neighbor m= etrics. >=20 > We would love to hear the opinions of the working group on this topic. Any= preferences or alternative suggestions? >=20 > Kind regards, > Vicky. >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-8AEE7C66-AC4F-4ABE-AC6D-465D8886C0C0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Victoria, all,

On these matters, I am= generally in favor of letting actual experience guide the decision process.=  

Thus in order to inform that decision process (eg in order to unders= tand if 32 bits are too many/few, if the exponential nature of the encoding o= f the LINK_METRIC TLV would work, etc.), it might help to know something abo= ut what metrics are used in actual (i.e. outside the controlled confines of a= lab, and not in a network simulator) AODV (v1/v2) deployments? 
<= div id=3D"AppleMailSignature">
I wou= ld assume that part of the experiment that was RFC3561 would have been to un= derstand if not the "kind" of metrics to use (i.e. not if ETT/ETX/DAT/* is b= etter/worse, which likely would be heavily media/environment dependent) then= at least the range and nature of metrics values that would be useful?
=

Most= , if not all, published work I've seen has referred to hop-count in ns2 - bo= th of which are a poor approximation (on this matter) of what to expect in t= he real world.

So, what's actually being used in "real world" deployments, a= nd what lessons can be drawn from that?
=
Best,

Thomas

-- 
Thomas Heide Clausen
http://www.thomasclausen.org

On 15 avr. 2016, at 22:31, Victoria Mercieca <= vmercieca0@gmail.com> wrote:<= br>
Hi everyone,
The AODVv2 author team are discussing, amongst other things= , our metric TLV, and would appreciate your input. Currently our draft defin= es a new PATH_METRIC TLV, where we use the type extension to indicate Metric= Type and the value length varies dependent on metric type.

There have been a couple of suggestions of alternatives.
<= br>
1) Recent suggestions that met= ric fields in general should use 32 bits. If we go ahead with this, we alter= our current metric TLV very slightly, still using Type, Type Extension for i= ndicating MetricType, Length, and Value fields, but with length set to 32 bi= ts for every metric type. 32 bits seems like overkill for a hopcount metric,= and suitability for other metric types may vary.

2) Other suggestions th= at we re-use the LINK_METRIC TLV used by OLSRv2. It has a value length of 16= bits total. If we do use that, I believe we could still use extension type t= o indicate MetricType like we are currently with our own TLV. I don't believ= e its a big change to the AODVv2 draft either. We would need define how to set the 'kind' and 'direction' bits for= AODVv2 metrics, since ours are accumulated route metrics, rather than link o= r neighbor metrics.

We w= ould love to hear the opinions of the working group on this topic. Any prefe= rences or alternative suggestions?

Kind regards,
Vicky.
=

=

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-8AEE7C66-AC4F-4ABE-AC6D-465D8886C0C0-- From nobody Sat Apr 16 11:08: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 DCDE512DDEF for ; Sat, 16 Apr 2016 11:08:43 -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 PzeZt5OPM0Kp for ; Sat, 16 Apr 2016 11:08:39 -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 C853012DEE2 for ; Sat, 16 Apr 2016 11:08:38 -0700 (PDT) Received: by mail-ig0-x22e.google.com with SMTP id gy3so43542160igb.0 for ; Sat, 16 Apr 2016 11:08: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=KPIeWrl/+86+jxKOnsjugX+o6hO3/ZMiepL1afsTYe4=; b=FtLTe2YrRHDgsI4Dz56ctszG1DjE2vJUvwyV6ud68dIaBk4Cjj4qyPPqMMy1O0g5NI HjWhnd3zCIHMQkwUBY29mvGE52II0n+ipVFy0OlChmIbsSImq6NSsRePiIEvC8gC+0yF 1apg7kBpGfU1YTxkrs98H35wW84O3ZoOS8f/d1GkEfFJyBW55lLnZ0beZemf/byMYkCm 3VkUCkwe9EN56WZtgwDBYvgHLnHbbKfREKKFHTHFX6mleqX+8rdDKBzj9Va9ndIdr0HI 1/Jxobhx5lvc/7KXsZJZ9EforZ96DgwFOZZKk7Rcchmb8rYiFwI4bxYdtQt+KhVEPLfE MFkg== 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=KPIeWrl/+86+jxKOnsjugX+o6hO3/ZMiepL1afsTYe4=; b=VjigMFnUkRfWq6YG5Rrn9YGXWny5ueYnbeh5YmFvoJ8joFZv1GY/aZZ685J9OlAh/x t31ROucieN5M+Jm04parwmObm2Om5x+xI1tAtLtzrgT40w3cgEVVvWM+KtFgj/Di66xF 52tGTWfRnlsqXDVnDPqICI7Fg6UkJBBs4dvsPdVFqLLiII5gSSeyPrNTfR9dUMyYmwNH Myq8v9KyqgECQwontPs8fA3RKUByvoh8/rDmDW9SSf9G7+aDF79sU3JUNgwxTDpk7brv xcPyPxHYM8VZU5ILgpNWhqvTw4GMa22gZO+0zNqtgCrcCnKfzu3wJZT6hudq5S9OO4Xn 50Dw== X-Gm-Message-State: AOPr4FVMyapC3Lrq5lVbua6MKSEfribk4O+WKtfpyAFjEGTXJ8nY73hYqYn2W36+q81K/euFNxfYCjJr+/UZMA== MIME-Version: 1.0 X-Received: by 10.50.73.133 with SMTP id l5mr11309861igv.69.1460830118033; Sat, 16 Apr 2016 11:08:38 -0700 (PDT) Received: by 10.79.72.68 with HTTP; Sat, 16 Apr 2016 11:08:37 -0700 (PDT) In-Reply-To: <45DFA343-1FDD-4EB9-9291-AB3A830A3CD9@mnemosyne.demon.co.uk> References: <45DFA343-1FDD-4EB9-9291-AB3A830A3CD9@mnemosyne.demon.co.uk> Date: Sat, 16 Apr 2016 14:08:37 -0400 Message-ID: From: Stan Ratliff To: Christopher Dearlove Content-Type: multipart/alternative; boundary=089e0129483a4345fd05309e0434 Archived-At: Cc: "manet@ietf.org" , Christopher Dearlove Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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: Sat, 16 Apr 2016 18:08:44 -0000 --089e0129483a4345fd05309e0434 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 15, 2016 at 3:27 PM, Christopher Dearlove < chris@mnemosyne.demon.co.uk> wrote: > I don't understand what you mean by the concept of "fields the protocol > can and can't touch". > CAVEAT: I am speaking here as a Working Group participant. With that understood: TTL is a great example, since that discussion blew the mailing list up a few months ago. I'm *not* saying manipulating TTL is a good thing for a protocol to try - in truth, I think it's pretty "hacky". But the notion was floated, and in the context of that discussion, it may will have worked. The opposition on-list was fast, and pretty forceful. I've said before - 5444, especially with the multiplexer, changes the relationship between a routing protocol and an interface. I think the document should have some type of "overview" section which discusses these differences, in order to frame the issue for someone coming along who hasn't been a part of the 5444 mail discussion. I'm talking about the type of overview that goes something like this: "Use of RFC 5444 with the multiplexer feature imposes design requirements on the protocol. The actual transport mechanism is abstracted from the protocol. For example, routing protocols are not aware of precisely when a message is sent. A good example of operation in this model is [BGP], utilizing the [TCP] transport. This is opposed to a protocol such as [OSPF], which is capable of sending traffic with its own IP type. Since the transport is abstracted, protocols are not presented with "packets", and are not capable of manipulating data items in packet headers (e.g. data items at the IP and/or MAC layers)." As Lou Berger put it to me in the context of DLEP - "You want an engineer to be able to pick up this document, with no prior exposure to the topic, and code an interoperable implementation." I think this type of an overview, setting basic ground rules, would help. I've also contended for a while now that 5444, with the mux, effectively forces an architecture on implementers - in the Linux world, that architecture is a 5444 parser as an independent process, with IPC mechanisms to the routing protocol(s) it is servicing. The 5444 parser itself "owns" the transport (the socket). The usage document *strongly infers* that. I believe we should concretely state it, so we don't have to answer the question over and over again. Regards, Stan > > When a protocol creates a message from scratch it's not constrained in an= y > way I'd describe in such terms. So I assume you mean when it receives a > message and then sends a similar message. > > There are two cases there. Unchanged (with the special exceptions for hop > count and limit) and not unchanged. The former is better, and there's > really nothing more to say. > > So let's consider the latter. Really it's not the same message, it's a > brand new message. That's a useful way to look at it from a security > perspective, because it tells you that end to end authentication isn't > going to work. And what are the restrictions on brand new messages? The > same as on any new message. > > OK, you might say, true but does that mean I can add this, remove that, > change the hop data? Yes. But is that a good idea? No. But maybe you are > forced into it. But that it's inherently not good suggests the corollary > that if you must, do the minimum and make it trackable. But that's not a > 5444 requirement, just good practice. It does break 7182 message ICVs, so > don't use them. > > We could, hypothetically, have someone create an extension or alternative > to 7182 that defined aggregated signatures. Then we'd have rules on what > you could change. But that would belong there. If you think those would b= e > good, then again you would want make minimal changes, and mainly only of > certain types. What types? There I can't help you as I don't have a > candidate. > > The summary? Don't change if you don't have to. That's recommended. If yo= u > must change you're on your own (with the same restrictions as new > messages). Advice like "as little as possible" is good, but that's not > actually 5444 advice. And don't use 7182 message ICVs. > > -- > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) > > On 15 Apr 2016, at 19:37, Stan Ratliff wrote: > > My main concern addressed inline... > > > On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlove < > christopher.dearlove@gmail.com> wrote: > >> A few immediate comments inline below. >> >> -- >> Christopher Dearlove >> christopher.dearlove@gmail.com (iPhone) >> chris@mnemosyne.demon.co.uk (home) >> >> On 15 Apr 2016, at 15:18, Lotte Steenbrink >> wrote: >> >> Hi all, >> >> sparked by the recently started WGLC, I=E2=80=99ve reviewed the current = revision >> of the draft. I=E2=80=99d like to offer the working group my perspective= as someone >> who doesn=E2=80=99t have decades of protocol and/or packet format design= under >> their belt (i.e. some things might not be obvious to me that are obvious= to >> others), but also as someone who has worked with RFC 5444 when implement= ing >> a routing protocol (AODVv2), updating the packet format of a routing >> protocol (AODVv2 again) and (partially) implementing my own RFC5444 >> builder/parser. >> >> Overall, I think the document is easy to read and follow. To me, it >> contains valuable information and guidance and in some cases prevents >> people from shooting themselves in the foot. >> I=E2=80=99m really happy this document exists and I=E2=80=99d like it to= move forward >> soon, but I do feel that it is still lacking in some areas, which is why= I >> was a bit surprised to see it go to Last Call all of a sudden. >> >> >> Not really. The authors had said what they intended to say, no one was >> commenting, time for WGLC. >> >> First, some nitpicks and comments: >> >> * from 1.2.1 >> . >> Packet/Message Format: >> >> [=E2=80=A6] a packet >> >> transmission following a successful packet reception is by design >> of a new packet that may include all, some, or none of the >> received messages [...] >> >> >> I=E2=80=99m not a native speaker, but that =E2=80=9Eof=E2=80=9C seems ou= t of place... >> >> >> I am a native speaker, and no, it's not. Some would repeat it after each >> of all, some and none, and I might sometimes. But it really doesn't matt= er >> which of the two styles we pick, the RFC Editor may well change to the >> other. >> >> * Regarding 4.2 >> . >> Packets and Messages: >> this section talks a lot about how the multiplexer operates, so I think >> it=E2=80=99d be helpful if its title reflected that. >> >> >> I'm of two opinions on that. On the one hand it is, as its title >> suggests, about the packet and message level, as opposed to lower levels= , >> and its title contrasts with that if 4.3 for that reason. On the other h= and >> you are right, it does have much about the multiplexer. A title covering >> all three woukd start getting cumbersome. Will take this one away to thi= nk >> about. >> >> * from 4.4 >> . >> Addresses Require Attributes: >> >> An unmodified extension to NHDP would ignore such addresses, >> as required, as it does not support that specialized purpose. >> >> >> At first glance, (to me) this reads as =E2=80=9EAll addresses that are a= ssociated >> with an unknown TLV are ignored=E2=80=9C, which is obviously nonsense (b= ut quite >> panic-inducing :D). I=E2=80=99d propose to reword it to something along = the lines >> of >> >> An unmodified extension to NHDP would not consider this >> >> address to be of a neighbor, as it is lacking a LINK_STATUS >> >> or OTHER_NEIGHB TLV. >> >> >> I take your point, but I think that if the address ends up with no >> relevant associated TLVs then it is ignored is also a point. I dare say = we >> can wordsmith something. >> >> Also, I don=E2=80=99t quite get where you=E2=80=99re going with the last= paragraph of >> that section (=E2=80=9CThese restrictions do not, however, mean that add= ed >> information is >> >> completely ignored for purposes of the base protocol.=E2=80=9D)... >> >> >> Read on, the rest of the paragraph describes the case where not. But we >> might telegraph that better in the opening sentence. >> >> * regarding the maps in 4.5 >> . >> Information Representation: >> I=E2=80=99m afraid I just don=E2=80=99t really understand the purpose of= this section and >> the mapping notation. I=E2=80=99m assuming that the maps are supposed to= offer a >> way of describing how a TLV relates to a message or an address? >> If so, why does it only mention extension types, but not the basis types= ? >> >> >> It says extended types, meaning the combination of the two. But full typ= e >> would be better, as almost defined in 5444. In fact I think we should ad= d a >> comment to the notation section. (5444 uses a symbolic name rather than = the >> phrase.) >> >> Or is it supposed to be used something like this: >> >> *BASE_TLV* >> >> Message: >> (base_tlv_extension_type_1) -> (2 octets, "value a when condition x is >> met") >> (base_tlv_extension_type_2) -> (2 octets, "value b when condition y is >> met") >> >> ? Also, I don=E2=80=99t quite get how this would be used in future proto= col >> specifications? Or aid in implementing RFC5444 parsers? >> An example or a clarification would be very helpful. >> >> >> It's a way of looking at things. But not the only one, it goes on to >> discuss variants. I think it mostly comes under heading of if useful use >> it, if not skip it. We'll take another look, but I don't think this will >> ever be elementary. >> >> * regarding 4.6 >> . >> TLVs: >> In general, it=E2=80=99s not clear everywhere in the section whether you= =E2=80=99re >> talking to RFC5444 parser/builder implementors or protocol designers. >> >> A protocol SHOULD use an efficient >> representation, but this is a quality of implementation issue. >> >> >> I=E2=80=99m not sure where you=E2=80=99re going with the last part of th= at sentence? I=E2=80=99d >> reword it to something like =E2=80=9EA protocol SHOULD use an efficient >> representation, avoiding unnecessarily verbose use of TLVs and extension >> types. However, the final arrangement in a message- or addressTLV block = is >> a quality of implementation issue=E2=80=9C (in case that=E2=80=99s what= you meant). >> >> >> No, you're considering the protocol design. This is considering the >> protocol object that implements the protocol. There isn't a one to one >> mapping from information to representation, it's up to the implementatio= n >> to do it efficiently. Different implementations of the same protocol >> specification may do better or worse here. (Trivial case, an implementat= ion >> could choose to never compress addresses. Bad idea, but legal.) >> >> And then: >> >> A >> protocol MUST recognize any permitted representation of the >> information; even if it chooses to (for example) only use multivalue >> TLVs, it MUST recognize single value TLVs (and vice versa). >> >> >> =E2=80=A6 I thought protocols weren=E2=80=99t supposed to specify whethe= r a TLV is >> arranged (for example) as a multivalue TLV?! >> >> >> Implementation again, not design. >> >> And so, since a protocol shouldn't be concerned with multivalue TLVs and >> the like, wouldn=E2=80=99t it be the *RFC5444 implementation* that MUST = recognize >> any permitted representation? >> >> >> You're assuming that there is an RFC 5444 implementation. That's the sam= e >> way to work if you plan to implement more than one protocol. But nothing >> says you have to do it that way. The architecture defined by 5498 admits= of >> the multiplexer and protocols, and thus these are rules on the protocol.= If >> protocols delegate all their common work to something (parser/creator) t= hen >> it inherits those restrictions, but that's not defined, and we can't ass= ume >> it. >> >> Or is this paragraph really just a complicated way of saying =E2=80=9Eas= a >> protocol designer, make sure to not specify/rely on things like (for >> example) multivalue TLVs, since your messages have to work with *any* >> representation=E2=80=9C? If so, I think that should be done in a less co= mplicated >> fashion (see below). >> >> * regarding 5 >> . >> Structure: >> Since this section talks a lot about flags, it=E2=80=99d be nice if its = title >> represented that. Maybe consider renaming it to =E2=80=9EStructure and F= lags=E2=80=9C or >> so? >> >> >> I mostly don't agree. Structure is the subject, flags are a detail. >> >> * from 6.1 >> . >> Address Block Compression: >> >> Compression of addresses in an Address Block considers addresses to >> consist of a Head, a Mid, and a Tail, where all addresses in an >> Address Block have the same Head and Tail, but different Mids. >> >> >> >> I=E2=80=99d find this sentence easier to read if it started with =E2=80= =9CCompression of >> addresses in an Address Block is possible when addresses consist of a He= ad, >> a Mid [=E2=80=A6]=E2=80=9D. >> >> >> No. That's missing the point and misleading. Addresses are always >> considered to have the head/mid/tail format. Compression is possible if >> either the head or tail (or both) is non-empty. >> >> * from 6.1 >> . >> Address Block Compression: >> >> >> Putting addresses into a message efficiently also has to include: >> >> >> Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that would be a =E2=80= =9Emay=E2=80=9C. Multiple Adress Blocks >> and/or reordering don=E2=80=99t increase efficiency in all possible case= s... >> >> >> I think that's the wrong change. Rather "include" should be "consider". >> >> * from 6.2 >> . >> TLVs: >> >> [...] This is even possible if the MPR TLV specified in >> OLSRv2 [RFC7181 ] is added; b= ut it is not possible, in general, if >> >> the LINK_METRIC TLV is also added. >> >> >> Why is it not possible for the latter? If that could be explained/hinted >> at in a half sentence, I think it=E2=80=99d be helpful information to ha= ve in the >> draft. >> >> >> That's very hard, and not just because it's a negative. It's really an >> observation that motivates the duscussion. A half sentence would I think >> confuse more than it enlightens (it's because you have too many constrai= nts >> to satisfy at once - I doubt that helped). >> >> In a typical case where a >> LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with >> enough addresses, sorted appropriately, two single value TLVs can >> be more efficient than one multivalue TLV. >> >> >> Same thing: why? >> >> >> Here I think this should be obvious to anyone who has looked at 5444. >> >> * regarding the second paragraph from 6.3 >> . >> TLV Values, i.e. >> >> >> >> This approach was specified in [RFC7188 ], and required for protocols >> that extend [RFC6130 ] and [RFC7= 181 ]. It is here RECOMMENDED that >> this approach is followed when defining any Address Block TLV that >> may be used by a protocol using [RFC5444 ]. >> >> >> The term =E2=80=9Ethis approach=E2=80=9C confused me, since I initially = thought it meant >> =E2=80=9Ethe approach is to use UNSPECIFIED in a way that makes sense=E2= =80=9C rather than >> =E2=80=9Ethe approach is to use UNSPECIFIED=E2=80=9C. Maybe that could b= e reworded to >> something along the lines of >> The UNSPECIFIED TLV and its usage was specified in [RFC7188]=E2=80=A6 >> ? >> >> >> No. There is no UNSPECIFIED TLV. There is a recommendation to include an >> UNSPECIFIED value in a TLV. But really, we've described this once in 718= 8, >> it's there to read. >> >> * regarding 6.3 >> . >> TLV Values: >> The second paragraph is a bit confusing and seems to explaing roghly the >> same things as the fourth paragraphs. I=E2=80=99d propose to merge the s= econd >> into the fourth. >> >> >> I'm not sure I exactly agree, but the ordering in that section could be >> improved. >> >> * from 6.4 >> . >> Automation: >> >> The possible gain depends on the efficiency >> of the original message creation, >> >> >> the term =E2=80=9Ethe original message creation=E2=80=9C seems a bit amb= iguous=E2=80=93 does this >> refer to the message as created by an RFC5444 message builder >> implementation? >> >> >> Yes. >> >> Additionally, I'm concerned about two things that *aren=E2=80=99t* in th= e draft: >> >> * Some of the AODVv2 co-authors and me have asked for a list of =E2=80= =9Eas a >> protocol, you can set all of these fields of a message, but please leave >> the rest alone=E2=80=9C, which would=E2=80=99ve saved us many hours of d= iscussions (and >> Henning a lot of time spent explaining these things=E2=80=A6). These req= uests have >> been met with a refusal to specify a concrete API, as such an effort is >> dependent on outside factors such as programming language or software >> architecture. I agree with this notion, but a programming-language >> dependent API is not what we=E2=80=99ve asked for. I=E2=80=99ve tried to= supply a sketch of >> what I did ask for in [1], but unfortunately I didn=E2=80=99t get an ans= wer (and as >> far as I can see it, the draft wasn=E2=80=99t changed either). I still t= hink that >> such a list, in whatever form, would be very helpful for future >> Internet-Draft authors and I also think this request is in accordance wi= th >> the intentions stated in 1.1 History and Purpose, and I think it should >> be included in the document. >> >> >> No. There are many reasons why we're just not touching this one. >> >> One is that language independence is a mirage. How you go about things i= s >> completely different in, for example an object oriented language than on= e >> that isn't. Section 4.5 shows that there are quite different ways of doi= ng >> things even given a decision to use a map approach, and there are other >> approaches than that. It would be wrong and beyond our competence to >> suggest one of these as "best". There's reasons the IETF doesn't do this= , >> and that's one. >> >> Plus, frankly, the work it would take is beyond what we choose to spend. >> > > > > > I'm confused (which is an altogether too common occurrence these days). I > get that we don't want to specify an API. But I think the discussion abou= t > fields a protocol can and can't touch in a messages is a good thing - and > it's one spot where I, too, find the document wanting. > > To paraphrase something I've said before, I believe that RFC 5444 changes > the relationship that a routing protocol has with an "interface". I'm not > commenting on whether or not that's a good thing, or a bad thing - just > that it does change the relationship. This change has been at the root of > some of the long-running discussions as to whether protocols under > development were RFC 5444 compliant or not. The goal of this document bei= ng > to eliminate (it's a goal, probably not reachable) those discussions, I'd > like to see that information in the document in some form. > > I'm interested in seeing this document progress, and eventually be > published. I think it will help future protocol designers to better use R= FC > 5444. But I would like to see *something* along the lines of what Lotte i= s > requesting, as I think it will improve the doc. > > Regards, > Stan > > > >> >> * As the exact rules for using/setting the hop count & hop-limit fields >> are currently being discussed w/ regard to AODVv2 in another thread [2]= =E2=80=93 >> should a definitive answer to that question be part of 5444-usage? >> >> >> You don't want that. Because if we did specify that you'd find yourself >> more constrained than you want to be. There is a design intent described= in >> 5444, but it assumes immutable messages. Which you don't want. Really, >> we're doing you a favour by not imposing on you. >> >> Best regards, >> Lotte >> >> [1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.html >> [2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.html >> >> >> Am 06.04.2016 um 19:14 schrieb Justin Dean : >> >> The chairs agree that a 3 week WGLC is appropriate. Everyone please rea= d >> the draft early and get comments in early so that they can be addressed >> within the last call period. >> >> Justin >> >> On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) < >> chris.dearlove@baesystems.com> wrote: >> >>> Obviously +1 to the request for WGLC. >>> >>> With regard to what's changed, technically the only significant thing i= s >>> to make it clear that if a protocol delivers a message to the multiplex= er, >>> the multiplexer must pass it on unchanged to the protocol (another inst= ance >>> of, at another router) unchanged. Without that nothing that the protoco= l >>> itself chooses to do with regard to security makes sense. Though the >>> protocol can alternatively let the multiplexer do the security, 7182 ca= n be >>> implemented in either way. This isn't really new, but it wasn't formall= y >>> spelled out. It's presented as part of spelling out multiplexer rules m= ore >>> carefully. >>> >>> But what about message optimisation? That's a function of constructing = a >>> 5444 message, not the multiplexer, and is down to that 5444 includes tw= o >>> things - packet/message structure (and implicitly, and in pretty much a= ny >>> implementation I would expect to see, a parser and builder for that >>> structure) and the multiplexer. So we took the opportunity to separate = out >>> more clearly a discussion of the two, which we think will be helpful. >>> >>> -- >>> 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 >>> >>> -----Original Message----- >>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg >>> Sent: 05 April 2016 20:08 >>> To: manet@ietf.org >>> Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 >>> >>> ----------------------! WARNING ! ---------------------- This message >>> originates from outside our organisation, either from an external partn= er >>> or from the internet. >>> Consider carefully whether you should click on any links, open any >>> attachments or reply. >>> Follow the 'Report Suspicious Emails' link on IT matters for >>> instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>> >>> *** WARNING *** >>> EXTERNAL EMAIL -- This message originates from outside our organization= . >>> >>> >>> Hi, >>> >>> As you have seen, we have submitted a new revision of 5444-usage. The >>> authors feel comfortable that we have addressed all issues by this vers= ion, >>> and would like to ask the WG chairs to issue a WGLC on this document. W= hile >>> it is a fairly short document, given that it is IETF week for some, we'= d >>> suggest that a 3-4 week WGLC would be appropriate. >>> >>> Best regards >>> Ulrich >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 >> >> > --089e0129483a4345fd05309e0434 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 15, 2016 at 3:27 PM, Christopher Dearlove <chris= @mnemosyne.demon.co.uk> wrote:
I don't understand what y= ou mean by the concept of "fields the protocol can and can't touch= ".


CAVEAT: I am speaki= ng here as a Working Group participant. With that understood:
=C2=A0

TTL is a great example, since that discussion bl= ew the mailing list up a few months ago. I'm *not* saying manipulating = TTL is a good thing for a protocol to try - in truth, I think it's pret= ty "hacky". But the notion was floated, and in the context of tha= t discussion, it may will have worked. The opposition on-list was fast, and= pretty forceful.

I've said before - 5444, especiall= y with the multiplexer, changes the relationship between a routing protocol= and an interface. I think the document should have some type of "over= view" section which discusses these differences, in order to frame the= issue for someone coming along who hasn't been a part of the 5444 mail= discussion.

I'm talking about the type of overview = that goes something like this:

"Use of RFC 5444 wit= h the multiplexer feature imposes design requirements on the protocol. The = actual transport mechanism is abstracted from the protocol. For example, ro= uting protocols are not aware of precisely when a message is sent. A good e= xample of operation in this model is [BGP], utilizing the [TCP] transport. = This is opposed to a protocol such as [OSPF], which is capable of sending t= raffic with its own IP type. Since the transport is abstracted, protocols a= re not presented with "packets", and are not capable of manipulat= ing data items in packet headers (e.g. data items at the IP and/or MAC laye= rs)."

As Lou Berger put it to me in the context of DLEP - "= ;You want an=20 engineer to be able to pick up this document, with no prior exposure to=20 the topic, and code an interoperable implementation."=C2=A0 I think th= is type of an overview, setting basic ground rules, would help.

I've also contended for a while now that 5444, with the mux, eff= ectively forces an architecture on implementers - in the Linux world, that = architecture is a 5444 parser as an independent process, with IPC mechanism= s to the routing protocol(s) it is servicing. The 5444 parser itself "= owns" the transport (the socket). The usage document *strongly infers*= that. I believe we should concretely state it, so we don't have to ans= wer the question over and over again.

Regards,
=
Stan



=C2=A0

When a protoco= l creates a message from scratch it's not constrained in any way I'= d describe in such terms. So I assume you mean when it receives a message a= nd then sends a similar message.

There are two cas= es there. Unchanged (with the special exceptions for hop count and limit) a= nd not unchanged. The former is better, and there's really nothing more= to say.

So let's consider the latter. Really = it's not the same message, it's a brand new message. That's a u= seful way to look at it from a security perspective, because it tells you t= hat end to end authentication isn't going to work. And what are the res= trictions on brand new messages? The same as on any new message.
=
OK, you might say, true but does that mean I can add this, r= emove that, change the hop data? Yes. But is that a good idea? No. But mayb= e you are forced into it. But that it's inherently not good suggests th= e corollary that if you must, do the minimum and make it trackable. But tha= t's not a 5444 requirement, just good practice. It does break 7182 mess= age ICVs, so don't use them.

We could, hypothe= tically, have someone create an extension or alternative to 7182 that defin= ed aggregated signatures. Then we'd have rules on what you could change= . But that would belong there. If you think those would be good, then again= you would want make minimal changes, and mainly only of certain types. Wha= t types? There I can't help you as I don't have a candidate.
<= div>
The summary? Don't change if you don't have to. = That's recommended. If you must change you're on your own (with the= same restrictions as new messages). Advice like "as little as possibl= e" is good, but that's not actually 5444 advice. And don't use= 7182 message ICVs.

-- =C2=A0
Christopher Dearlove

On 15 Apr 2016, at 19:37, Stan Ratliff <ratliffstan@gmail.com> = wrote:

My main= concern addressed inline...


On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlove <= span dir=3D"ltr"><christopher.dearlove@gmail.com> wrote:
A few i= mmediate comments inline below.

-- =C2=A0
Hi all,

sparked by the recently started WGLC, I=E2=80= =99ve reviewed the current revision of the draft. I=E2=80=99d like to offer= the working group my perspective as someone who doesn=E2=80=99t have decad= es of protocol and/or packet format design under their belt (i.e. some thin= gs might not be obvious to me that are obvious to others), but also as some= one who has worked with RFC 5444 when implementing a routing protocol (AODV= v2), updating the packet format of a routing protocol (AODVv2 again) and (p= artially) implementing my own RFC5444 builder/parser.

<= div>Overall, I think the document is easy to read and follow. To me, it con= tains valuable information and guidance and in some cases prevents people f= rom shooting themselves in the foot.
I=E2=80=99m really happy thi= s document exists and I=E2=80=99d like it to move forward soon, but I do fe= el that it is still lacking in some areas, which is why I was a bit surpris= ed to see it go to Last Call all of a sudden.

Not really. The authors had said what they intended to= say, no one was commenting, time for WGLC.

First, some nitpicks and comments:
<= br>
* from=C2=A01.2.1. Packet/Message Format:

= 
 =
    =C2=A0[=E2=80=A6] a packet
      transmission following a successful packet re=
ception is by design
      of a new packet that may include all, some, or none of the
      received messages [...]

I=E2=80= =99m not a native speaker, but that =E2=80=9Eof=E2=80=9C seems out of place= ...

I am a native speake= r, and no, it's not. Some would repeat it after each of all, some and n= one, and I might sometimes. But it really doesn't matter which of the t= wo styles we pick, the RFC Editor may well change to the other.
<= br>
* Regarding=C2=A04.2. Packets and Mes= sages:
this section talks a lot about how the multiplexer = operates, so I think it=E2=80=99d be helpful if its title reflected that.= =C2=A0

I'm of two opinions= on that. On the one hand it is, as its title suggests, about the packet an= d message level, as opposed to lower levels, and its title contrasts with t= hat if 4.3 for that reason. On the other hand you are right, it does have m= uch about the multiplexer. A title covering all three woukd start getting c= umbersome. Will take this one away to think about.

* from=C2=A04.4. Addresses Require Attributes:

   A=
n unmodified extension to NHDP would ignore such addresses,
   as required, as it does not support that specialized purpose.
=
At first glance, (to me) this reads as =E2=80=9EAll ad= dresses that are associated with an unknown TLV are ignored=E2=80=9C, which= is obviously nonsense (but quite panic-inducing :D). I=E2=80=99d propose t= o reword it to something along the lines of=C2=A0
   An unmodified extension =
to NHDP would not consider this
   address to be of a neighbor, as it is lacking a=
 LINK_STATUS
   or OTHER_NEIGHB TLV.

=
I take your point, but I think that if the address ends up with no re= levant associated TLVs then it is ignored is also a point. I dare say we ca= n wordsmith something.

Also, I don=E2=80=99t quite get where you=E2=80=99re going with the last paragraph of that section (=E2=80=9CThese restrictions do not, however, mean that added= information is
   completely ignored for purposes of the base protocol.=E2=80=9D)...

Read on, the rest of the paragraph describes the case where not= . But we might telegraph that better in the opening sentence.
* regarding the maps in=C2=A04.5. Informa= tion Representation:
I=E2=80=99m afraid I just don=E2=80= =99t really understand the purpose of this section and the mapping notation= . I=E2=80=99m assuming that the maps are supposed to offer a way of describ= ing how a TLV relates to a message or an address?=C2=A0
If so, wh= y does it only mention extension types, but not the basis types?

It says extended types, meaning the combinatio= n of the two. But full type would be better, as almost defined in 5444. In = fact I think we should add a comment to the notation section. (5444 uses a = symbolic name rather than the phrase.)

Or is it supposed to be used something like this:
<= br>
BASE_TLV

Message:=C2= =A0
(base_tlv_extension_type_1) -&g= t; (2 octets, "value a when condition x is met")
(base_tlv_extension_type_2) -> (2 octets, "= value b when condition y is met")

? Al= so, I don=E2=80=99t quite get how this would be used in future protocol spe= cifications? Or aid in implementing RFC5444 parsers?
An example o= r a clarification would be very helpful.

<= /div>It's a way of looking at things. But not the only one, it goes on = to discuss variants. I think it mostly comes under heading of if useful use= it, if not skip it. We'll take another look, but I don't think thi= s will ever be elementary.

* regarding=C2=A04.6. TLVs:
In g= eneral, it=E2=80=99s not clear everywh= ere in the section whether you=E2=80=99re talking to RFC5444 parser/builder implementors or protocol designers.= =C2=A0

   A protocol SHOULD use an efficient
   representation, but this is a quality of implementation issue.

I=E2=80=99m not sure where you=E2=80=99re going with the la= st part of that sentence? I=E2=80=99d reword it to something like =E2=80=9E= A protocol SHOULD use an efficient representation, avoiding unnecessarily v= erbose use of TLVs and extension types. However, the final arrangement in a= message- or addressTLV block is =C2=A0a quality of implementation issue=E2= =80=9C (in case that=E2=80=99s what you meant).

No, you're considering the protocol design. This is c= onsidering the protocol object that implements the protocol. There isn'= t a one to one mapping from information to representation, it's up to t= he implementation to do it efficiently. Different implementations of the sa= me protocol specification may do better or worse here. (Trivial case, an im= plementation could choose to never compress addresses. Bad idea, but legal.= )

And then:
=
   A
   protocol MUST recognize any permitted representation of the
   information; even if it chooses to (for example) only use multivalue
   TLVs, it MUST recognize single value TLVs (and vice versa).
=E2=80=A6 I thought protocols weren=E2=80=99t supposed to spec= ify whether a TLV is arranged (for example) as a multivalue TLV?!

Implementation again, not design.
=

And so, since a protocol = shouldn't be concerned with multivalue TLVs and the like, wouldn=E2=80= =99t it be the *RFC5444 implementation* that MUST recognize any permitted r= epresentation?

You're= assuming that there is an RFC 5444 implementation. That's the same way= to work if you plan to implement more than one protocol. But nothing says = you have to do it that way. The architecture defined by 5498 admits of the = multiplexer and protocols, and thus these are rules on the protocol. If pro= tocols delegate all their common work to something (parser/creator) then it= inherits those restrictions, but that's not defined, and we can't = assume it.

Or is this par= agraph really just a complicated way of saying =E2=80=9Eas a protocol desig= ner, make sure to not specify/rely on things like (for example) multivalue = TLVs, since your messages have to work with *any* representation=E2=80=9C? = If so, I think that should be done in a less complicated fashion (see below= ).

* regarding=C2=A05. Structure:
Since this section talks a lot about flags, it=E2=80=99d be nice if its title represen= ted that. Maybe consider renaming it to=C2=A0=E2=80=9EStructure and = Flags=E2=80=9C=C2=A0or so?
=

I mostly don't agree. Structure is the subj= ect, flags are a detail.

= * from=C2=A06.1. Address Block Compression:

   Compression of addresses in an Addr=
ess Block considers addresses to
   consist of a Head, a Mid, and a Tail, where all addresses in an
   Address Block have the same Head and Tail, but different Mids.


I=E2=80=99d find this sentence easier = to read if it started with =E2=80=9CCompression of addresses in an Address = Block is possible when addresses consist of a Head, a Mid [=E2=80=A6]=E2=80= =9D.

No. That's missing the poin= t and misleading. Addresses are always considered to have the head/mid/tail= format. Compression is possible if either the head or tail (or both) is no= n-empty.

* from=C2=A06.1. Addre= ss Block Compression:

   Putting addresses into a message efficiently al=
so has to include:

Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d = think that would be a =E2=80=9Emay=E2=80=9C. Multiple Adress Blocks and/or = reordering don=E2=80=99t increase efficiency in all possible cases...
=

I think that's the wrong change. Rath= er "include" should be "consider".

* from=C2=A06.2. TLVs:
      [...] This is ev=
en possible if the MPR TLV specified in
      OLSRv2 [RFC7181] is added; but it is not possible, in general, if

      =
the LINK_METRIC TLV is also added.

Why is it= not possible for the latter? If that could be explained/hinted at in a hal= f sentence, I think it=E2=80=99d be helpful information to have in the draf= t.

That's very hard, and not jus= t because it's a negative. It's really an observation that motivate= s the duscussion. A half sentence would I think confuse more than it enligh= tens (it's because you have too many constraints to satisfy at once - I= doubt that helped).

In a typic= al case where a LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with enough addresses, sorted appropriately, two single value TLVs can be more efficient than one multivalue TLV.

=
Same thing: why?

Here I think t= his should be obvious to anyone who has looked at 5444.

* regarding the second paragraph from=C2=A0<= a name=3D"m_6567571615122782722_m_-648935726582295764_section-6.3" href=3D"= https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.3" = style=3D"font-size:1em;font-weight:bold;color:black;text-decoration:none" t= arget=3D"_blank">6.3. TL= V Values, i.e.
  =C2=A0
   This approach was specified in [RFC7188], and required for protocols
   that extend [RFC6130] and [RFC7181].  It is here RECOMMENDED that
   this approach is followed when defining any Address Block TLV that
   may be used by a protocol using [RFC5444].

The term =E2=80= =9Ethis approach=E2=80=9C confused me, since I initially =C2=A0thought it m= eant =E2=80=9Ethe approach is to use UNSPECIFIED in a way that makes sense= =E2=80=9C rather than =E2=80=9Ethe approach is to use UNSPECIFIED=E2=80=9C.= Maybe that could be reworded to something along the lines of=C2=A0
The UNSPECIFIED TLV and its usage was specified i= n [RFC7188]=E2=80=A6=C2=A0
?
=
No. There is no UNSPECIFIED TLV. There is a recommendation to inc= lude an UNSPECIFIED value in a TLV. But really, we've described this on= ce in 7188, it's there to read.

* regarding=C2=A06.3. TLV Values:
The second paragraph is a bit confusing and seems to explaing ro= ghly the same things as the fourth paragraphs. I=E2=80=99d propose to merge the second into the fourth.

I'm not sure I exactly agree, but = the ordering in that section could be improved.

* from=C2=A06.4. Automation:

   The possible gain depends =
on the efficiency
   of the original message creation,

the ter= m =E2=80=9Ethe original message creation=E2=80=9C seems a bit ambiguous=E2= =80=93 does this refer to the message as created by an RFC5444 message buil= der implementation?

Yes.
<= br>
Additionally, I'm concerned abou= t two things that *aren=E2=80=99t* in the draft:

*= =C2=A0Some of the AODVv2 co-authors and me have asked for a list of =E2=80= =9Eas a protocol, you can set all of these fields of a message, but please = leave the rest alone=E2=80=9C, which would=E2=80=99ve saved us many hours o= f discussions (and Henning a lot of time spent explaining these things=E2= =80=A6). These requests have been met with a refusal to specify a concrete = API, as such an effort is dependent on outside factors such as programming = language or software architecture. I agree with this notion, but a programm= ing-language dependent API is not what we=E2=80=99ve asked for. I=E2=80=99v= e tried to supply a sketch of what I did ask for in [1], but unfortunately = I didn=E2=80=99t get an answer (and as far as I can see it, the draft wasn= =E2=80=99t changed either). I still think that such a list, in whatever for= m, would be very helpful for future Internet-Draft authors and I also think= this request is in accordance with the intentions stated in=C2=A01.1 History and Purpose,=C2=A0and I think it should be= included in the document.

No. There= are many reasons why we're just not touching this one.

<= /div>
One is that language independence is a mirage. How you go about t= hings is completely different in, for example an object oriented language t= han one that isn't. Section 4.5 shows that there are quite different wa= ys of doing things even given a decision to use a map approach, and there a= re other approaches than that. It would be wrong and beyond our competence = to suggest one of these as "best". There's reasons the IETF d= oesn't do this, and that's one.

Plus, fran= kly, the work it would take is beyond what we choose to spend.
<= /div>


<Speaking as a WG P= articipant>

I'm confused (which is an altog= ether too common occurrence these days). I get that we don't want to sp= ecify an API. But I think the discussion about fields a protocol can and ca= n't touch in a messages is a good thing - and it's one spot where I= , too, find the document wanting.=C2=A0

To paraphr= ase something I've said before, I believe that RFC 5444 changes the rel= ationship that a routing protocol has with an "interface". I'= m not commenting on whether or not that's a good thing, or a bad thing = - just that it does change the relationship. This change has been at the ro= ot of some of the long-running discussions as to whether protocols under de= velopment were RFC 5444 compliant or not. The goal of this document being t= o eliminate (it's a goal, probably not reachable) those discussions, I&= #39;d like to see that information in the document in some form.=C2=A0

I'm interested in seeing this document progress, a= nd eventually be published. I think it will help future protocol designers = to better use RFC 5444. But I would like to see *something* along the lines= of what Lotte is requesting, as I think it will improve the doc.=C2=A0

Regards,
Stan

=C2= =A0

* As the exact rules fo= r using/setting the hop count & hop-limit fields are currently being di= scussed w/ regard to AODVv2 in another thread [2]=E2=80=93 should a definit= ive answer to that question be part of 5444-usage?
=

You don't want that. Because if we did specify that you&= #39;d find yourself more constrained than you want to be. There is a design= intent described in 5444, but it assumes immutable messages. Which you don= 't want. Really, we're doing you a favour by not imposing on you.



Am 06.04.2016 um 19:14 schrieb Justin Dean <bebemaster@gmail.com>= :

The chairs agree that a 3 week WGLC is app= ropriate.=C2=A0 Everyone please read the draft early and get comments in ea= rly so that they can be addressed within the last call period.

Justin

On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
Obviously +1 to the request for WGLC.
With regard to what's changed, technically the only significant thing i= s to make it clear that if a protocol delivers a message to the multiplexer= , the multiplexer must pass it on unchanged to the protocol (another instan= ce of, at another router) unchanged. Without that nothing that the protocol= itself chooses to do with regard to security makes sense. Though the proto= col can alternatively let the multiplexer do the security, 7182 can be impl= emented in either way. This isn't really new, but it wasn't formall= y spelled out. It's presented as part of spelling out multiplexer rules= more carefully.

But what about message optimisation? That's a function of constructing = a 5444 message, not the multiplexer, and is down to that 5444 includes two = things - packet/message structure (and implicitly, and in pretty much any i= mplementation I would expect to see, a parser and builder for that structur= e) and the multiplexer. So we took the opportunity to separate out more cle= arly a discussion of the two, which we think will be helpful.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________<= br>
T: =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chris.dearlove@baesyst= ems.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 Ulrich Herberg
Sent: 05 April 2016 20:08
To: manet@ietf.org<= br> Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

----------------------! 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 instru= ctions on reporting suspicious email messages.
--------------------------------------------------------

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


Hi,

As you have seen, we have submitted a new revision of 5444-usage. The autho= rs feel comfortable that we have addressed all issues by this version, and = would like to ask the WG chairs to issue a WGLC on this document. While it = is a fairly short document, given that it is IETF week for some, we'd s= uggest that a 3-4 week WGLC would be appropriate.

Best regards
Ulrich

_______________________________________________
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
http= s://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



--089e0129483a4345fd05309e0434-- From nobody Sun Apr 17 23:02:32 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 64FB112DA04 for ; Sun, 17 Apr 2016 23:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.715 X-Spam-Level: X-Spam-Status: No, score=-3.715 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, 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 Ls4XTN2w_hlf for ; Sun, 17 Apr 2016 23:02:29 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id DE38912D9E7 for ; Sun, 17 Apr 2016 23:02:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=hhtIoTMhYG477SFQjhCrBdKIeoC+rURSQywxJIYbZE3EifgMJSYjChf1PaITrjj5; 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-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1as2G9-0001Cj-SC; Mon, 18 Apr 2016 02:02:10 -0400 To: "Dearlove, Christopher (UK)" , Mobile Ad Hoc Networks mailing list References: <570EDD6A.8070605@earthlink.net> From: Charlie Perkins Message-ID: <57147860.5020805@earthlink.net> Date: Sun, 17 Apr 2016 23:02:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090407050408020200090205" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7dc7c6a49e299e763f7c54ca5bb26549e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [manet] draft-ietf-manet-rfc5444-usage-03 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, 18 Apr 2016 06:02:31 -0000 This is a multi-part message in MIME format. --------------090407050408020200090205 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Chris, I can't fully respond right now but a few points: On 4/14/2016 2:09 AM, Dearlove, Christopher (UK) wrote: > > * It is improper for adherence to one simple parser design to > constrain protocol design for such a wide class of routing > problems as are represented by ad hoc networks. > > Sorry, you are well out of line there. This was a WG decision, > specified in RFC 5498. A document written by your then DYMO co-author > Ian Chakeres (also WG chair) and agreed by the WG. It wasn’t foisted > on you by the authors - quite the reverse, we had making it work as a > generic specification put onto us. > Ian has told me more than once that he is *very very* surprised at some of the restrictions that have been legislated as a result of RFC 5498. Speaking for myself, when that was happening I somehow imagined that it would be better to have the address aggregation facilities, but I didn't realize the costs. Maybe when the WG accepted this document, it was not clear how costly that decision would be. > > * The document requires the protocol to know about MTU but > discussion on the list inhibits the protocol from knowing about MTU. > > Even if someone on the list said that the protocol is inhibited from > knowing about MTU, that’s not relevant. Does this document say that? > No. But I also don’t recall anyone saying that. Any protocol (or even > many applications) that run directly or indirectly over IP need to > have some idea about MTU, possibly with rules of thumb as to how much > to subtract due to expected headers. This is no different. > Somebody asked to remove all mention of MTU from AODVv2. I argued that we had to have it but lost the argument. > * The document disallows the protocol from specifying crucial > parameters such as time allowable for aggregation of control > messages. > > That is exactly backwards. From Section 4.2 > > o The multiplexer MAY delay messages briefly in order to assemble > > more efficient packets. It SHOULD respect any constraints on such > > delays requested by the protocol. > > If you want to argue that the SHOULD ought to be a MUST then fine, I’d > have some sympathy with that, but we were trying not to overly > constrain. But that the protocol can inform the multiplexer is clearly > there. > If the protocol says something about delay, that MUST be respected. Regarding "exactly backwards" -- I wish I could count how many SHOULDs have been converted to "MUSTs" based on the theory that implementers don't give a darn about SHOULDs. Believe me, I do know the RFC 2119 definitions, but I lose every such argument. However, even if implementers really really did respect the meaning of SHOULD, in this case it would still have to be MUST. > * Addresses are presumed to be included in a message for no > particular reason unless described by yet another address TLV. > This increases message size on the speculation that the protocol > will want to be used with other unrelated protocols in the > future. In normal protocol design, addresses are put into a > message for reasons that are specific to the message. > > Yes, this is a design feature that is highly desirable for > extensibility. That’s the experience of a lot of time working with a > protocol (OLSR) without that, and this. I can already see how possible > extensions to AODVv2 could use this freedom. While bytes do matter, so > does extensibility. > > Frankly, what protocols need is to go in one direction or the other. > One direction is a tightly optimised ultra-compact message for very > specific use, in particular for systems based on microcontrollers and > very constrained wireless links. It’s quite open to you to create a > separate message structure for that. You’re already part way there > with first specifying what’s in a message, then how that’s represented > in RFC 5444. In an ideal world we’d have done the same for OLSRv2. The > other direction, while not oblivious to efficiency concerns, is > prepared to add a few octets (and we are talking a low single figure > number) to allow extensibility. Even the authors missed some > extensibility options back in earlier days, whoever it was that > insisted on a per-message address length, rather than inheriting from > whatever IP stack you were running on, was right. > > An appendix (or probably in light of timescales) separate draft on an > ultra-compact representation of AODVv2, explicitly not intended to be > extensible, would be interesting, and might find some application. > Heading down that path we're going to have to specify every protocol twice. I thought it would be better to avoid having the extra bytes in the first place. Besides that there are simple ways to enable both economical size and extensibility. But one sentence rings in my mind containing the words "Hell No". I'm not clear on that part about restricting to a per-message address length, but it's not a big deal for most protocols and not for AODVv2, so we could talk about that later if ever. > > The multiplexer is in place, that’s RFC 5498. This isn’t new. The > horse is already in front of the cart. > Well, it does not have to be. > > >I will try to finish reading the draft soon, but I think that Last > Call for this document is premature at best. I would strongly suggest > that it be delayed until the current two major [manet] items can be > finished. > > That’s completely unacceptable. Who knows how long you are going to > continue to work on AODVv2 out of sight of this WG. And this really is > the cart before the horse. Your co-authors of AODVv2 requested further > clarification of RFC 5444, and we put in the work to do that. > Clarifying the base before building on it is the right order. > We're trying to resolve the very few remaining comments. I would think that something as far reaching as this usage document could take a good while. I'd hate to have that front of finishing AODVv2. > Also, why two WG documents? The only other significant document is > DLEP, which is both independent of this (it doesn’t use 5444 - and > that’s because it’s not a MANET routing protocol) and already out of > the gate. > > O.K. I thought it was still under discussion... Regards, Charlie P. --------------090407050408020200090205 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello Chris,

I can't fully respond right now but a few points:

On 4/14/2016 2:09 AM, Dearlove, Christopher (UK) wrote:

  • It is improper for adherence to one simple parser design to constrain protocol design for such a wide class of routing problems as are represented by ad hoc networks.

Sorry, you are well out of line there. This was a WG decision, specified in RFC 5498. A document written by your then DYMO co-author Ian Chakeres (also WG chair) and agreed by the WG. It wasn’t foisted on you by the authors - quite the reverse, we had making it work as a generic specification put onto us.


Ian has told me more than once that he is *very very* surprised at some of the restrictions that have been legislated as a result of RFC 5498.  Speaking for myself, when that was happening I somehow imagined that it would be better to have the address aggregation facilities, but I didn't realize the costs.

Maybe when the WG accepted this document, it was not clear how costly that decision would be.


  • The document requires the protocol to know about MTU but discussion on the list inhibits the protocol from knowing about MTU.

Even if someone on the list said that the protocol is inhibited from knowing about MTU, that’s not relevant. Does this document say that? No. But I also don’t recall anyone saying that. Any protocol (or even many applications) that run directly or indirectly over IP need to have some idea about MTU, possibly with rules of thumb as to how much to subtract due to expected headers. This is no different.


Somebody asked to remove all mention of MTU from AODVv2.  I argued that we had to have it but lost the argument.


  • The document disallows the protocol from specifying crucial parameters such as time allowable for  aggregation of control messages.

That is exactly backwards. From Section 4.2

   o  The multiplexer MAY delay messages briefly in order to assemble

      more efficient packets.  It SHOULD respect any constraints on such

      delays requested by the protocol.

If you want to argue that the SHOULD ought to be a MUST then fine, I’d have some sympathy with that, but we were trying not to overly constrain. But that the protocol can inform the multiplexer is clearly there.


If the protocol says something about delay, that MUST be respected.

Regarding "exactly backwards" -- I wish I could count how many SHOULDs have been converted to "MUSTs" based on the theory that implementers don't give a darn about SHOULDs.  Believe me, I do know the RFC 2119 definitions, but I lose every such argument.

However, even if implementers really really did respect the meaning of SHOULD, in this case it would still have to be MUST.


  • Addresses are presumed to be included in a message for no particular reason unless described by yet another address TLV.  This increases message size on the speculation that the protocol will want to be used with other unrelated protocols in the future.  In normal protocol design, addresses are put into a message for reasons that are specific to the message.

Yes, this is a design feature that is highly desirable for extensibility. That’s the experience of a lot of time working with a protocol (OLSR) without that, and this. I can already see how possible extensions to AODVv2 could use this freedom. While bytes do matter, so does extensibility.

Frankly, what protocols need is to go in one direction or the other. One direction is a tightly optimised ultra-compact message for very specific use, in particular for systems based on microcontrollers and very constrained wireless links. It’s quite open to you to create a separate message structure for that. You’re already part way there with first specifying what’s in a message, then how that’s represented in RFC 5444. In an ideal world we’d have done the same for OLSRv2. The other direction, while not oblivious to efficiency concerns, is prepared to add a few octets (and we are talking a low single figure number) to allow extensibility. Even the authors missed some extensibility options back in earlier days, whoever it was that insisted on a per-message address length, rather than inheriting from whatever IP stack you were running on, was right.

An appendix (or probably in light of timescales) separate draft on an ultra-compact representation of AODVv2, explicitly not intended to be extensible, would be interesting, and might find some application.


Heading down that path we're going to have to specify every protocol twice.  I thought it would be better to avoid having the extra bytes in the first place.  Besides that there are simple ways to enable both economical size and extensibility.  But one sentence rings in my mind containing the words "Hell No".

I'm not clear on that part about restricting to a per-message address length, but it's not a big deal for most protocols and not for AODVv2, so we could talk about that later if ever.


The multiplexer is in place, that’s RFC 5498. This isn’t new. The horse is already in front of the cart.


Well, it does not have to be.


> I will try to finish reading the draft soon, but I think that Last Call for this document is premature at best.  I would strongly suggest that it be delayed until the current two major [manet] items can be finished.

That’s completely unacceptable. Who knows how long you are going to continue to work on AODVv2 out of sight of this WG. And this really is the cart before the horse. Your co-authors of AODVv2 requested further clarification of RFC 5444, and we put in the work to do that. Clarifying the base before building on it is the right order.


We're trying to resolve the very few remaining comments.  I would think that something as far reaching as this usage document could take a good while.  I'd hate to have that front of finishing AODVv2.

Also, why two WG documents? The only other significant document is DLEP, which is both independent of this (it doesn’t use 5444 - and that’s because it’s not a MANET routing protocol) and already out of the gate.

 


O.K. I thought it was still under discussion...

Regards,
Charlie P.

--------------090407050408020200090205-- From nobody Mon Apr 18 01:52:51 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 4234312DE4E for ; Mon, 18 Apr 2016 01:52:50 -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 WnOppRXs9Ag9 for ; Mon, 18 Apr 2016 01:52:45 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [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 D426112DDCB for ; Mon, 18 Apr 2016 01:52:44 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,501,1454976000"; d="scan'208,217"; a="61671858" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 18 Apr 2016 09:52:43 +0100 X-IronPort-AV: E=Sophos;i="5.24,501,1454976000"; d="scan'208,217";a="114361148" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 18 Apr 2016 09:52:42 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 09:52:42 +0100 From: "Dearlove, Christopher (UK)" To: Stan Ratliff , Christopher Dearlove Thread-Topic: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 Thread-Index: AQHRj26efzFsMll+IU2A0f8aUpvZOp980SWwgABO2gCADfPgAIAAOu8AgAANM4CAAZs2zoACiJ1w Date: Mon, 18 Apr 2016 08:52:41 +0000 Message-ID: References: <45DFA343-1FDD-4EB9-9291-AB3A830A3CD9@mnemosyne.demon.co.uk> 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD7B9GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 18 Apr 2016 08:52:50 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD7B9GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IGJlbGlldmUgd2UgY2FuIG9yIHNob3VsZCBzdWdnZXN0IGFuIGltcGxlbWVudGF0 aW9uLiBUaGF04oCZcyBub3Qgd2hhdCB0aGUgSUVURiBkb2VzLCBhbmQgaXQgd291bGQgYmUgYSBo YXJkLCBwcm9iYWJseSBpbXBvc3NpYmxlLCBzZWxsLCB0byB0aGUgSUVTRy4gVGhhdCB0aGUgb2J2 aW91cyBpbXBsZW1lbnRhdGlvbiBlbXBsb3lzIGFuIGluZGVwZW5kZW50IHBhcnNlciBpcyBhbHJl YWR5IHNhaWQgLSBpdCBtYXkgYmUgYXBwcm9wcmlhdGUgdG8gc3RyZW5ndGhlbiB0aGUgd29yZHMs IGJ1dCB0aGlzIHNlY29uZCBJ4oCZbSBub3Qgc3VyZSBpZiB0aGF04oCZcyBuZWVkZWQgKG5vdCBn b3QgdGltZSB0byBjaGVjayBjdXJyZW50IHdvcmRpbmcpLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVh cmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50 ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkx MjQ1IDI0MjE5NCAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNo cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs bGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1z Zm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJh ZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRl ZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVk IE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQ DQoNCkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFN0YW4gUmF0bGlmZg0KU2VudDogMTYgQXByaWwgMjAxNiAxOTowOQ0KVG86IENocmlzdG9w aGVyIERlYXJsb3ZlDQpDYzogbWFuZXRAaWV0Zi5vcmc7IENocmlzdG9waGVyIERlYXJsb3ZlDQpT dWJqZWN0OiBSZTogW21hbmV0XSBXR0xDIHJlcXVlc3QgZm9yIGRyYWZ0LWlldGYtbWFuZXQtcmZj NTQ0NC11c2FnZS0wMw0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0 ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFs IHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91 IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5 Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sg b3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0 LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVu dHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3Vz LCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3Rl bXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIw V2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCioqKiBXQVJOSU5HICoqKg0KRVhURVJO QUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdh bml6YXRpb24uDQoNCg0KDQpPbiBGcmksIEFwciAxNSwgMjAxNiBhdCAzOjI3IFBNLCBDaHJpc3Rv cGhlciBEZWFybG92ZSA8Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrPG1haWx0bzpjaHJpc0Bt bmVtb3N5bmUuZGVtb24uY28udWs+PiB3cm90ZToNCkkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHlv dSBtZWFuIGJ5IHRoZSBjb25jZXB0IG9mICJmaWVsZHMgdGhlIHByb3RvY29sIGNhbiBhbmQgY2Fu J3QgdG91Y2giLg0KDQpDQVZFQVQ6IEkgYW0gc3BlYWtpbmcgaGVyZSBhcyBhIFdvcmtpbmcgR3Jv dXAgcGFydGljaXBhbnQuIFdpdGggdGhhdCB1bmRlcnN0b29kOg0KDQoNClRUTCBpcyBhIGdyZWF0 IGV4YW1wbGUsIHNpbmNlIHRoYXQgZGlzY3Vzc2lvbiBibGV3IHRoZSBtYWlsaW5nIGxpc3QgdXAg YSBmZXcgbW9udGhzIGFnby4gSSdtICpub3QqIHNheWluZyBtYW5pcHVsYXRpbmcgVFRMIGlzIGEg Z29vZCB0aGluZyBmb3IgYSBwcm90b2NvbCB0byB0cnkgLSBpbiB0cnV0aCwgSSB0aGluayBpdCdz IHByZXR0eSAiaGFja3kiLiBCdXQgdGhlIG5vdGlvbiB3YXMgZmxvYXRlZCwgYW5kIGluIHRoZSBj b250ZXh0IG9mIHRoYXQgZGlzY3Vzc2lvbiwgaXQgbWF5IHdpbGwgaGF2ZSB3b3JrZWQuIFRoZSBv cHBvc2l0aW9uIG9uLWxpc3Qgd2FzIGZhc3QsIGFuZCBwcmV0dHkgZm9yY2VmdWwuDQpJJ3ZlIHNh aWQgYmVmb3JlIC0gNTQ0NCwgZXNwZWNpYWxseSB3aXRoIHRoZSBtdWx0aXBsZXhlciwgY2hhbmdl cyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gYSByb3V0aW5nIHByb3RvY29sIGFuZCBhbiBpbnRl cmZhY2UuIEkgdGhpbmsgdGhlIGRvY3VtZW50IHNob3VsZCBoYXZlIHNvbWUgdHlwZSBvZiAib3Zl cnZpZXciIHNlY3Rpb24gd2hpY2ggZGlzY3Vzc2VzIHRoZXNlIGRpZmZlcmVuY2VzLCBpbiBvcmRl ciB0byBmcmFtZSB0aGUgaXNzdWUgZm9yIHNvbWVvbmUgY29taW5nIGFsb25nIHdobyBoYXNuJ3Qg YmVlbiBhIHBhcnQgb2YgdGhlIDU0NDQgbWFpbCBkaXNjdXNzaW9uLg0KSSdtIHRhbGtpbmcgYWJv dXQgdGhlIHR5cGUgb2Ygb3ZlcnZpZXcgdGhhdCBnb2VzIHNvbWV0aGluZyBsaWtlIHRoaXM6DQoi VXNlIG9mIFJGQyA1NDQ0IHdpdGggdGhlIG11bHRpcGxleGVyIGZlYXR1cmUgaW1wb3NlcyBkZXNp Z24gcmVxdWlyZW1lbnRzIG9uIHRoZSBwcm90b2NvbC4gVGhlIGFjdHVhbCB0cmFuc3BvcnQgbWVj aGFuaXNtIGlzIGFic3RyYWN0ZWQgZnJvbSB0aGUgcHJvdG9jb2wuIEZvciBleGFtcGxlLCByb3V0 aW5nIHByb3RvY29scyBhcmUgbm90IGF3YXJlIG9mIHByZWNpc2VseSB3aGVuIGEgbWVzc2FnZSBp cyBzZW50LiBBIGdvb2QgZXhhbXBsZSBvZiBvcGVyYXRpb24gaW4gdGhpcyBtb2RlbCBpcyBbQkdQ XSwgdXRpbGl6aW5nIHRoZSBbVENQXSB0cmFuc3BvcnQuIFRoaXMgaXMgb3Bwb3NlZCB0byBhIHBy b3RvY29sIHN1Y2ggYXMgW09TUEZdLCB3aGljaCBpcyBjYXBhYmxlIG9mIHNlbmRpbmcgdHJhZmZp YyB3aXRoIGl0cyBvd24gSVAgdHlwZS4gU2luY2UgdGhlIHRyYW5zcG9ydCBpcyBhYnN0cmFjdGVk LCBwcm90b2NvbHMgYXJlIG5vdCBwcmVzZW50ZWQgd2l0aCAicGFja2V0cyIsIGFuZCBhcmUgbm90 IGNhcGFibGUgb2YgbWFuaXB1bGF0aW5nIGRhdGEgaXRlbXMgaW4gcGFja2V0IGhlYWRlcnMgKGUu Zy4gZGF0YSBpdGVtcyBhdCB0aGUgSVAgYW5kL29yIE1BQyBsYXllcnMpLiINCg0KQXMgTG91IEJl cmdlciBwdXQgaXQgdG8gbWUgaW4gdGhlIGNvbnRleHQgb2YgRExFUCAtICJZb3Ugd2FudCBhbiBl bmdpbmVlciB0byBiZSBhYmxlIHRvIHBpY2sgdXAgdGhpcyBkb2N1bWVudCwgd2l0aCBubyBwcmlv ciBleHBvc3VyZSB0byB0aGUgdG9waWMsIGFuZCBjb2RlIGFuIGludGVyb3BlcmFibGUgaW1wbGVt ZW50YXRpb24uIiAgSSB0aGluayB0aGlzIHR5cGUgb2YgYW4gb3ZlcnZpZXcsIHNldHRpbmcgYmFz aWMgZ3JvdW5kIHJ1bGVzLCB3b3VsZCBoZWxwLg0KSSd2ZSBhbHNvIGNvbnRlbmRlZCBmb3IgYSB3 aGlsZSBub3cgdGhhdCA1NDQ0LCB3aXRoIHRoZSBtdXgsIGVmZmVjdGl2ZWx5IGZvcmNlcyBhbiBh cmNoaXRlY3R1cmUgb24gaW1wbGVtZW50ZXJzIC0gaW4gdGhlIExpbnV4IHdvcmxkLCB0aGF0IGFy Y2hpdGVjdHVyZSBpcyBhIDU0NDQgcGFyc2VyIGFzIGFuIGluZGVwZW5kZW50IHByb2Nlc3MsIHdp dGggSVBDIG1lY2hhbmlzbXMgdG8gdGhlIHJvdXRpbmcgcHJvdG9jb2wocykgaXQgaXMgc2Vydmlj aW5nLiBUaGUgNTQ0NCBwYXJzZXIgaXRzZWxmICJvd25zIiB0aGUgdHJhbnNwb3J0ICh0aGUgc29j a2V0KS4gVGhlIHVzYWdlIGRvY3VtZW50ICpzdHJvbmdseSBpbmZlcnMqIHRoYXQuIEkgYmVsaWV2 ZSB3ZSBzaG91bGQgY29uY3JldGVseSBzdGF0ZSBpdCwgc28gd2UgZG9uJ3QgaGF2ZSB0byBhbnN3 ZXIgdGhlIHF1ZXN0aW9uIG92ZXIgYW5kIG92ZXIgYWdhaW4uDQpSZWdhcmRzLA0KU3Rhbg0KDQoN Cg0KDQpXaGVuIGEgcHJvdG9jb2wgY3JlYXRlcyBhIG1lc3NhZ2UgZnJvbSBzY3JhdGNoIGl0J3Mg bm90IGNvbnN0cmFpbmVkIGluIGFueSB3YXkgSSdkIGRlc2NyaWJlIGluIHN1Y2ggdGVybXMuIFNv IEkgYXNzdW1lIHlvdSBtZWFuIHdoZW4gaXQgcmVjZWl2ZXMgYSBtZXNzYWdlIGFuZCB0aGVuIHNl bmRzIGEgc2ltaWxhciBtZXNzYWdlLg0KDQpUaGVyZSBhcmUgdHdvIGNhc2VzIHRoZXJlLiBVbmNo YW5nZWQgKHdpdGggdGhlIHNwZWNpYWwgZXhjZXB0aW9ucyBmb3IgaG9wIGNvdW50IGFuZCBsaW1p dCkgYW5kIG5vdCB1bmNoYW5nZWQuIFRoZSBmb3JtZXIgaXMgYmV0dGVyLCBhbmQgdGhlcmUncyBy ZWFsbHkgbm90aGluZyBtb3JlIHRvIHNheS4NCg0KU28gbGV0J3MgY29uc2lkZXIgdGhlIGxhdHRl ci4gUmVhbGx5IGl0J3Mgbm90IHRoZSBzYW1lIG1lc3NhZ2UsIGl0J3MgYSBicmFuZCBuZXcgbWVz c2FnZS4gVGhhdCdzIGEgdXNlZnVsIHdheSB0byBsb29rIGF0IGl0IGZyb20gYSBzZWN1cml0eSBw ZXJzcGVjdGl2ZSwgYmVjYXVzZSBpdCB0ZWxscyB5b3UgdGhhdCBlbmQgdG8gZW5kIGF1dGhlbnRp Y2F0aW9uIGlzbid0IGdvaW5nIHRvIHdvcmsuIEFuZCB3aGF0IGFyZSB0aGUgcmVzdHJpY3Rpb25z IG9uIGJyYW5kIG5ldyBtZXNzYWdlcz8gVGhlIHNhbWUgYXMgb24gYW55IG5ldyBtZXNzYWdlLg0K DQpPSywgeW91IG1pZ2h0IHNheSwgdHJ1ZSBidXQgZG9lcyB0aGF0IG1lYW4gSSBjYW4gYWRkIHRo aXMsIHJlbW92ZSB0aGF0LCBjaGFuZ2UgdGhlIGhvcCBkYXRhPyBZZXMuIEJ1dCBpcyB0aGF0IGEg Z29vZCBpZGVhPyBOby4gQnV0IG1heWJlIHlvdSBhcmUgZm9yY2VkIGludG8gaXQuIEJ1dCB0aGF0 IGl0J3MgaW5oZXJlbnRseSBub3QgZ29vZCBzdWdnZXN0cyB0aGUgY29yb2xsYXJ5IHRoYXQgaWYg eW91IG11c3QsIGRvIHRoZSBtaW5pbXVtIGFuZCBtYWtlIGl0IHRyYWNrYWJsZS4gQnV0IHRoYXQn cyBub3QgYSA1NDQ0IHJlcXVpcmVtZW50LCBqdXN0IGdvb2QgcHJhY3RpY2UuIEl0IGRvZXMgYnJl YWsgNzE4MiBtZXNzYWdlIElDVnMsIHNvIGRvbid0IHVzZSB0aGVtLg0KDQpXZSBjb3VsZCwgaHlw b3RoZXRpY2FsbHksIGhhdmUgc29tZW9uZSBjcmVhdGUgYW4gZXh0ZW5zaW9uIG9yIGFsdGVybmF0 aXZlIHRvIDcxODIgdGhhdCBkZWZpbmVkIGFnZ3JlZ2F0ZWQgc2lnbmF0dXJlcy4gVGhlbiB3ZSdk IGhhdmUgcnVsZXMgb24gd2hhdCB5b3UgY291bGQgY2hhbmdlLiBCdXQgdGhhdCB3b3VsZCBiZWxv bmcgdGhlcmUuIElmIHlvdSB0aGluayB0aG9zZSB3b3VsZCBiZSBnb29kLCB0aGVuIGFnYWluIHlv dSB3b3VsZCB3YW50IG1ha2UgbWluaW1hbCBjaGFuZ2VzLCBhbmQgbWFpbmx5IG9ubHkgb2YgY2Vy dGFpbiB0eXBlcy4gV2hhdCB0eXBlcz8gVGhlcmUgSSBjYW4ndCBoZWxwIHlvdSBhcyBJIGRvbid0 IGhhdmUgYSBjYW5kaWRhdGUuDQoNClRoZSBzdW1tYXJ5PyBEb24ndCBjaGFuZ2UgaWYgeW91IGRv bid0IGhhdmUgdG8uIFRoYXQncyByZWNvbW1lbmRlZC4gSWYgeW91IG11c3QgY2hhbmdlIHlvdSdy ZSBvbiB5b3VyIG93biAod2l0aCB0aGUgc2FtZSByZXN0cmljdGlvbnMgYXMgbmV3IG1lc3NhZ2Vz KS4gQWR2aWNlIGxpa2UgImFzIGxpdHRsZSBhcyBwb3NzaWJsZSIgaXMgZ29vZCwgYnV0IHRoYXQn cyBub3QgYWN0dWFsbHkgNTQ0NCBhZHZpY2UuIEFuZCBkb24ndCB1c2UgNzE4MiBtZXNzYWdlIElD VnMuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KY2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21h aWwuY29tPG1haWx0bzpjaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb20+IChpUGhvbmUpDQpj aHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWs8bWFpbHRvOmNocmlzQG1uZW1vc3luZS5kZW1vbi5j by51az4gKGhvbWUpDQoNCk9uIDE1IEFwciAyMDE2LCBhdCAxOTozNywgU3RhbiBSYXRsaWZmIDxy YXRsaWZmc3RhbkBnbWFpbC5jb208bWFpbHRvOnJhdGxpZmZzdGFuQGdtYWlsLmNvbT4+IHdyb3Rl Og0KTXkgbWFpbiBjb25jZXJuIGFkZHJlc3NlZCBpbmxpbmUuLi4NCg0KDQpPbiBGcmksIEFwciAx NSwgMjAxNiBhdCAxOjQ5IFBNLCBDaHJpc3RvcGhlciBEZWFybG92ZSA8Y2hyaXN0b3BoZXIuZGVh cmxvdmVAZ21haWwuY29tPG1haWx0bzpjaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb20+PiB3 cm90ZToNCkEgZmV3IGltbWVkaWF0ZSBjb21tZW50cyBpbmxpbmUgYmVsb3cuDQoNCi0tDQpDaHJp c3RvcGhlciBEZWFybG92ZQ0KY2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tPG1haWx0bzpj aHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb20+IChpUGhvbmUpDQpjaHJpc0BtbmVtb3N5bmUu ZGVtb24uY28udWs8bWFpbHRvOmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51az4gKGhvbWUpDQoN Ck9uIDE1IEFwciAyMDE2LCBhdCAxNToxOCwgTG90dGUgU3RlZW5icmluayA8bG90dGUuc3RlZW5i cmlua0BmdS1iZXJsaW4uZGU8bWFpbHRvOmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRlPj4g d3JvdGU6DQpIaSBhbGwsDQoNCnNwYXJrZWQgYnkgdGhlIHJlY2VudGx5IHN0YXJ0ZWQgV0dMQywg SeKAmXZlIHJldmlld2VkIHRoZSBjdXJyZW50IHJldmlzaW9uIG9mIHRoZSBkcmFmdC4gSeKAmWQg bGlrZSB0byBvZmZlciB0aGUgd29ya2luZyBncm91cCBteSBwZXJzcGVjdGl2ZSBhcyBzb21lb25l IHdobyBkb2VzbuKAmXQgaGF2ZSBkZWNhZGVzIG9mIHByb3RvY29sIGFuZC9vciBwYWNrZXQgZm9y bWF0IGRlc2lnbiB1bmRlciB0aGVpciBiZWx0IChpLmUuIHNvbWUgdGhpbmdzIG1pZ2h0IG5vdCBi ZSBvYnZpb3VzIHRvIG1lIHRoYXQgYXJlIG9idmlvdXMgdG8gb3RoZXJzKSwgYnV0IGFsc28gYXMg c29tZW9uZSB3aG8gaGFzIHdvcmtlZCB3aXRoIFJGQyA1NDQ0IHdoZW4gaW1wbGVtZW50aW5nIGEg cm91dGluZyBwcm90b2NvbCAoQU9EVnYyKSwgdXBkYXRpbmcgdGhlIHBhY2tldCBmb3JtYXQgb2Yg YSByb3V0aW5nIHByb3RvY29sIChBT0RWdjIgYWdhaW4pIGFuZCAocGFydGlhbGx5KSBpbXBsZW1l bnRpbmcgbXkgb3duIFJGQzU0NDQgYnVpbGRlci9wYXJzZXIuDQoNCk92ZXJhbGwsIEkgdGhpbmsg dGhlIGRvY3VtZW50IGlzIGVhc3kgdG8gcmVhZCBhbmQgZm9sbG93LiBUbyBtZSwgaXQgY29udGFp bnMgdmFsdWFibGUgaW5mb3JtYXRpb24gYW5kIGd1aWRhbmNlIGFuZCBpbiBzb21lIGNhc2VzIHBy ZXZlbnRzIHBlb3BsZSBmcm9tIHNob290aW5nIHRoZW1zZWx2ZXMgaW4gdGhlIGZvb3QuDQpJ4oCZ bSByZWFsbHkgaGFwcHkgdGhpcyBkb2N1bWVudCBleGlzdHMgYW5kIEnigJlkIGxpa2UgaXQgdG8g bW92ZSBmb3J3YXJkIHNvb24sIGJ1dCBJIGRvIGZlZWwgdGhhdCBpdCBpcyBzdGlsbCBsYWNraW5n IGluIHNvbWUgYXJlYXMsIHdoaWNoIGlzIHdoeSBJIHdhcyBhIGJpdCBzdXJwcmlzZWQgdG8gc2Vl IGl0IGdvIHRvIExhc3QgQ2FsbCBhbGwgb2YgYSBzdWRkZW4uDQoNCk5vdCByZWFsbHkuIFRoZSBh dXRob3JzIGhhZCBzYWlkIHdoYXQgdGhleSBpbnRlbmRlZCB0byBzYXksIG5vIG9uZSB3YXMgY29t bWVudGluZywgdGltZSBmb3IgV0dMQy4NCg0KDQpGaXJzdCwgc29tZSBuaXRwaWNrcyBhbmQgY29t bWVudHM6DQoNCiogZnJvbSAxLjIuMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tMS4yLjE+LiBQYWNrZXQvTWVzc2Fn ZSBGb3JtYXQ6DQoNCg0KICAgICAgW+KApl0gYSBwYWNrZXQNCg0KICAgICAgdHJhbnNtaXNzaW9u IGZvbGxvd2luZyBhIHN1Y2Nlc3NmdWwgcGFja2V0IHJlY2VwdGlvbiBpcyBieSBkZXNpZ24NCg0K ICAgICAgb2YgYSBuZXcgcGFja2V0IHRoYXQgbWF5IGluY2x1ZGUgYWxsLCBzb21lLCBvciBub25l IG9mIHRoZQ0KDQogICAgICByZWNlaXZlZCBtZXNzYWdlcyBbLi4uXQ0KDQpJ4oCZbSBub3QgYSBu YXRpdmUgc3BlYWtlciwgYnV0IHRoYXQg4oCeb2bigJwgc2VlbXMgb3V0IG9mIHBsYWNlLi4uDQoN CkkgYW0gYSBuYXRpdmUgc3BlYWtlciwgYW5kIG5vLCBpdCdzIG5vdC4gU29tZSB3b3VsZCByZXBl YXQgaXQgYWZ0ZXIgZWFjaCBvZiBhbGwsIHNvbWUgYW5kIG5vbmUsIGFuZCBJIG1pZ2h0IHNvbWV0 aW1lcy4gQnV0IGl0IHJlYWxseSBkb2Vzbid0IG1hdHRlciB3aGljaCBvZiB0aGUgdHdvIHN0eWxl cyB3ZSBwaWNrLCB0aGUgUkZDIEVkaXRvciBtYXkgd2VsbCBjaGFuZ2UgdG8gdGhlIG90aGVyLg0K DQoNCiogUmVnYXJkaW5nIDQuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNC4yPi4gUGFja2V0cyBhbmQgTWVzc2Fn ZXM6DQp0aGlzIHNlY3Rpb24gdGFsa3MgYSBsb3QgYWJvdXQgaG93IHRoZSBtdWx0aXBsZXhlciBv cGVyYXRlcywgc28gSSB0aGluayBpdOKAmWQgYmUgaGVscGZ1bCBpZiBpdHMgdGl0bGUgcmVmbGVj dGVkIHRoYXQuDQoNCkknbSBvZiB0d28gb3BpbmlvbnMgb24gdGhhdC4gT24gdGhlIG9uZSBoYW5k IGl0IGlzLCBhcyBpdHMgdGl0bGUgc3VnZ2VzdHMsIGFib3V0IHRoZSBwYWNrZXQgYW5kIG1lc3Nh Z2UgbGV2ZWwsIGFzIG9wcG9zZWQgdG8gbG93ZXIgbGV2ZWxzLCBhbmQgaXRzIHRpdGxlIGNvbnRy YXN0cyB3aXRoIHRoYXQgaWYgNC4zIGZvciB0aGF0IHJlYXNvbi4gT24gdGhlIG90aGVyIGhhbmQg eW91IGFyZSByaWdodCwgaXQgZG9lcyBoYXZlIG11Y2ggYWJvdXQgdGhlIG11bHRpcGxleGVyLiBB IHRpdGxlIGNvdmVyaW5nIGFsbCB0aHJlZSB3b3VrZCBzdGFydCBnZXR0aW5nIGN1bWJlcnNvbWUu IFdpbGwgdGFrZSB0aGlzIG9uZSBhd2F5IHRvIHRoaW5rIGFib3V0Lg0KDQoNCiogZnJvbSA0LjQ8 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2Fn ZS0wMyNzZWN0aW9uLTQuND4uIEFkZHJlc3NlcyBSZXF1aXJlIEF0dHJpYnV0ZXM6DQoNCg0KICAg QW4gdW5tb2RpZmllZCBleHRlbnNpb24gdG8gTkhEUCB3b3VsZCBpZ25vcmUgc3VjaCBhZGRyZXNz ZXMsDQoNCiAgIGFzIHJlcXVpcmVkLCBhcyBpdCBkb2VzIG5vdCBzdXBwb3J0IHRoYXQgc3BlY2lh bGl6ZWQgcHVycG9zZS4NCg0KQXQgZmlyc3QgZ2xhbmNlLCAodG8gbWUpIHRoaXMgcmVhZHMgYXMg 4oCeQWxsIGFkZHJlc3NlcyB0aGF0IGFyZSBhc3NvY2lhdGVkIHdpdGggYW4gdW5rbm93biBUTFYg YXJlIGlnbm9yZWTigJwsIHdoaWNoIGlzIG9idmlvdXNseSBub25zZW5zZSAoYnV0IHF1aXRlIHBh bmljLWluZHVjaW5nIDpEKS4gSeKAmWQgcHJvcG9zZSB0byByZXdvcmQgaXQgdG8gc29tZXRoaW5n IGFsb25nIHRoZSBsaW5lcyBvZg0KDQogICBBbiB1bm1vZGlmaWVkIGV4dGVuc2lvbiB0byBOSERQ IHdvdWxkIG5vdCBjb25zaWRlciB0aGlzDQoNCiAgIGFkZHJlc3MgdG8gYmUgb2YgYSBuZWlnaGJv ciwgYXMgaXQgaXMgbGFja2luZyBhIExJTktfU1RBVFVTDQoNCiAgIG9yIE9USEVSX05FSUdIQiBU TFYuDQoNCkkgdGFrZSB5b3VyIHBvaW50LCBidXQgSSB0aGluayB0aGF0IGlmIHRoZSBhZGRyZXNz IGVuZHMgdXAgd2l0aCBubyByZWxldmFudCBhc3NvY2lhdGVkIFRMVnMgdGhlbiBpdCBpcyBpZ25v cmVkIGlzIGFsc28gYSBwb2ludC4gSSBkYXJlIHNheSB3ZSBjYW4gd29yZHNtaXRoIHNvbWV0aGlu Zy4NCg0KDQpBbHNvLCBJIGRvbuKAmXQgcXVpdGUgZ2V0IHdoZXJlIHlvdeKAmXJlIGdvaW5nIHdp dGggdGhlIGxhc3QgcGFyYWdyYXBoIG9mIHRoYXQgc2VjdGlvbiAo4oCcVGhlc2UgcmVzdHJpY3Rp b25zIGRvIG5vdCwgaG93ZXZlciwgbWVhbiB0aGF0IGFkZGVkIGluZm9ybWF0aW9uIGlzDQoNCiAg IGNvbXBsZXRlbHkgaWdub3JlZCBmb3IgcHVycG9zZXMgb2YgdGhlIGJhc2UgcHJvdG9jb2wu4oCd KS4uLg0KDQpSZWFkIG9uLCB0aGUgcmVzdCBvZiB0aGUgcGFyYWdyYXBoIGRlc2NyaWJlcyB0aGUg Y2FzZSB3aGVyZSBub3QuIEJ1dCB3ZSBtaWdodCB0ZWxlZ3JhcGggdGhhdCBiZXR0ZXIgaW4gdGhl IG9wZW5pbmcgc2VudGVuY2UuDQoNCg0KKiByZWdhcmRpbmcgdGhlIG1hcHMgaW4gNC41PGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMj c2VjdGlvbi00LjU+LiBJbmZvcm1hdGlvbiBSZXByZXNlbnRhdGlvbjoNCknigJltIGFmcmFpZCBJ IGp1c3QgZG9u4oCZdCByZWFsbHkgdW5kZXJzdGFuZCB0aGUgcHVycG9zZSBvZiB0aGlzIHNlY3Rp b24gYW5kIHRoZSBtYXBwaW5nIG5vdGF0aW9uLiBJ4oCZbSBhc3N1bWluZyB0aGF0IHRoZSBtYXBz IGFyZSBzdXBwb3NlZCB0byBvZmZlciBhIHdheSBvZiBkZXNjcmliaW5nIGhvdyBhIFRMViByZWxh dGVzIHRvIGEgbWVzc2FnZSBvciBhbiBhZGRyZXNzPw0KSWYgc28sIHdoeSBkb2VzIGl0IG9ubHkg bWVudGlvbiBleHRlbnNpb24gdHlwZXMsIGJ1dCBub3QgdGhlIGJhc2lzIHR5cGVzPw0KDQpJdCBz YXlzIGV4dGVuZGVkIHR5cGVzLCBtZWFuaW5nIHRoZSBjb21iaW5hdGlvbiBvZiB0aGUgdHdvLiBC dXQgZnVsbCB0eXBlIHdvdWxkIGJlIGJldHRlciwgYXMgYWxtb3N0IGRlZmluZWQgaW4gNTQ0NC4g SW4gZmFjdCBJIHRoaW5rIHdlIHNob3VsZCBhZGQgYSBjb21tZW50IHRvIHRoZSBub3RhdGlvbiBz ZWN0aW9uLiAoNTQ0NCB1c2VzIGEgc3ltYm9saWMgbmFtZSByYXRoZXIgdGhhbiB0aGUgcGhyYXNl LikNCg0KDQpPciBpcyBpdCBzdXBwb3NlZCB0byBiZSB1c2VkIHNvbWV0aGluZyBsaWtlIHRoaXM6 DQoNCkJBU0VfVExWDQoNCk1lc3NhZ2U6DQooYmFzZV90bHZfZXh0ZW5zaW9uX3R5cGVfMSkgLT4g KDIgb2N0ZXRzLCAidmFsdWUgYSB3aGVuIGNvbmRpdGlvbiB4IGlzIG1ldCIpDQooYmFzZV90bHZf ZXh0ZW5zaW9uX3R5cGVfMikgLT4gKDIgb2N0ZXRzLCAidmFsdWUgYiB3aGVuIGNvbmRpdGlvbiB5 IGlzIG1ldCIpDQoNCj8gQWxzbywgSSBkb27igJl0IHF1aXRlIGdldCBob3cgdGhpcyB3b3VsZCBi ZSB1c2VkIGluIGZ1dHVyZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucz8gT3IgYWlkIGluIGltcGxl bWVudGluZyBSRkM1NDQ0IHBhcnNlcnM/DQpBbiBleGFtcGxlIG9yIGEgY2xhcmlmaWNhdGlvbiB3 b3VsZCBiZSB2ZXJ5IGhlbHBmdWwuDQoNCkl0J3MgYSB3YXkgb2YgbG9va2luZyBhdCB0aGluZ3Mu IEJ1dCBub3QgdGhlIG9ubHkgb25lLCBpdCBnb2VzIG9uIHRvIGRpc2N1c3MgdmFyaWFudHMuIEkg dGhpbmsgaXQgbW9zdGx5IGNvbWVzIHVuZGVyIGhlYWRpbmcgb2YgaWYgdXNlZnVsIHVzZSBpdCwg aWYgbm90IHNraXAgaXQuIFdlJ2xsIHRha2UgYW5vdGhlciBsb29rLCBidXQgSSBkb24ndCB0aGlu ayB0aGlzIHdpbGwgZXZlciBiZSBlbGVtZW50YXJ5Lg0KDQoNCiogcmVnYXJkaW5nIDQuNjxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAz I3NlY3Rpb24tNC42Pi4gVExWczoNCkluIGdlbmVyYWwsIGl04oCZcyBub3QgY2xlYXIgZXZlcnl3 aGVyZSBpbiB0aGUgc2VjdGlvbiB3aGV0aGVyIHlvdeKAmXJlIHRhbGtpbmcgdG8gUkZDNTQ0NCBw YXJzZXIvYnVpbGRlciBpbXBsZW1lbnRvcnMgb3IgcHJvdG9jb2wgZGVzaWduZXJzLg0KDQoNCiAg IEEgcHJvdG9jb2wgU0hPVUxEIHVzZSBhbiBlZmZpY2llbnQNCg0KICAgcmVwcmVzZW50YXRpb24s IGJ1dCB0aGlzIGlzIGEgcXVhbGl0eSBvZiBpbXBsZW1lbnRhdGlvbiBpc3N1ZS4NCg0KSeKAmW0g bm90IHN1cmUgd2hlcmUgeW914oCZcmUgZ29pbmcgd2l0aCB0aGUgbGFzdCBwYXJ0IG9mIHRoYXQg c2VudGVuY2U/IEnigJlkIHJld29yZCBpdCB0byBzb21ldGhpbmcgbGlrZSDigJ5BIHByb3RvY29s IFNIT1VMRCB1c2UgYW4gZWZmaWNpZW50IHJlcHJlc2VudGF0aW9uLCBhdm9pZGluZyB1bm5lY2Vz c2FyaWx5IHZlcmJvc2UgdXNlIG9mIFRMVnMgYW5kIGV4dGVuc2lvbiB0eXBlcy4gSG93ZXZlciwg dGhlIGZpbmFsIGFycmFuZ2VtZW50IGluIGEgbWVzc2FnZS0gb3IgYWRkcmVzc1RMViBibG9jayBp cyAgYSBxdWFsaXR5IG9mIGltcGxlbWVudGF0aW9uIGlzc3Vl4oCcIChpbiBjYXNlIHRoYXTigJlz IHdoYXQgeW91IG1lYW50KS4NCg0KTm8sIHlvdSdyZSBjb25zaWRlcmluZyB0aGUgcHJvdG9jb2wg ZGVzaWduLiBUaGlzIGlzIGNvbnNpZGVyaW5nIHRoZSBwcm90b2NvbCBvYmplY3QgdGhhdCBpbXBs ZW1lbnRzIHRoZSBwcm90b2NvbC4gVGhlcmUgaXNuJ3QgYSBvbmUgdG8gb25lIG1hcHBpbmcgZnJv bSBpbmZvcm1hdGlvbiB0byByZXByZXNlbnRhdGlvbiwgaXQncyB1cCB0byB0aGUgaW1wbGVtZW50 YXRpb24gdG8gZG8gaXQgZWZmaWNpZW50bHkuIERpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgb2Yg dGhlIHNhbWUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBtYXkgZG8gYmV0dGVyIG9yIHdvcnNlIGhl cmUuIChUcml2aWFsIGNhc2UsIGFuIGltcGxlbWVudGF0aW9uIGNvdWxkIGNob29zZSB0byBuZXZl ciBjb21wcmVzcyBhZGRyZXNzZXMuIEJhZCBpZGVhLCBidXQgbGVnYWwuKQ0KDQoNCkFuZCB0aGVu Og0KDQoNCiAgIEENCg0KICAgcHJvdG9jb2wgTVVTVCByZWNvZ25pemUgYW55IHBlcm1pdHRlZCBy ZXByZXNlbnRhdGlvbiBvZiB0aGUNCg0KICAgaW5mb3JtYXRpb247IGV2ZW4gaWYgaXQgY2hvb3Nl cyB0byAoZm9yIGV4YW1wbGUpIG9ubHkgdXNlIG11bHRpdmFsdWUNCg0KICAgVExWcywgaXQgTVVT VCByZWNvZ25pemUgc2luZ2xlIHZhbHVlIFRMVnMgKGFuZCB2aWNlIHZlcnNhKS4NCg0K4oCmIEkg dGhvdWdodCBwcm90b2NvbHMgd2VyZW7igJl0IHN1cHBvc2VkIHRvIHNwZWNpZnkgd2hldGhlciBh IFRMViBpcyBhcnJhbmdlZCAoZm9yIGV4YW1wbGUpIGFzIGEgbXVsdGl2YWx1ZSBUTFY/IQ0KDQpJ bXBsZW1lbnRhdGlvbiBhZ2Fpbiwgbm90IGRlc2lnbi4NCg0KDQpBbmQgc28sIHNpbmNlIGEgcHJv dG9jb2wgc2hvdWxkbid0IGJlIGNvbmNlcm5lZCB3aXRoIG11bHRpdmFsdWUgVExWcyBhbmQgdGhl IGxpa2UsIHdvdWxkbuKAmXQgaXQgYmUgdGhlICpSRkM1NDQ0IGltcGxlbWVudGF0aW9uKiB0aGF0 IE1VU1QgcmVjb2duaXplIGFueSBwZXJtaXR0ZWQgcmVwcmVzZW50YXRpb24/DQoNCllvdSdyZSBh c3N1bWluZyB0aGF0IHRoZXJlIGlzIGFuIFJGQyA1NDQ0IGltcGxlbWVudGF0aW9uLiBUaGF0J3Mg dGhlIHNhbWUgd2F5IHRvIHdvcmsgaWYgeW91IHBsYW4gdG8gaW1wbGVtZW50IG1vcmUgdGhhbiBv bmUgcHJvdG9jb2wuIEJ1dCBub3RoaW5nIHNheXMgeW91IGhhdmUgdG8gZG8gaXQgdGhhdCB3YXku IFRoZSBhcmNoaXRlY3R1cmUgZGVmaW5lZCBieSA1NDk4IGFkbWl0cyBvZiB0aGUgbXVsdGlwbGV4 ZXIgYW5kIHByb3RvY29scywgYW5kIHRodXMgdGhlc2UgYXJlIHJ1bGVzIG9uIHRoZSBwcm90b2Nv bC4gSWYgcHJvdG9jb2xzIGRlbGVnYXRlIGFsbCB0aGVpciBjb21tb24gd29yayB0byBzb21ldGhp bmcgKHBhcnNlci9jcmVhdG9yKSB0aGVuIGl0IGluaGVyaXRzIHRob3NlIHJlc3RyaWN0aW9ucywg YnV0IHRoYXQncyBub3QgZGVmaW5lZCwgYW5kIHdlIGNhbid0IGFzc3VtZSBpdC4NCg0KDQpPciBp cyB0aGlzIHBhcmFncmFwaCByZWFsbHkganVzdCBhIGNvbXBsaWNhdGVkIHdheSBvZiBzYXlpbmcg 4oCeYXMgYSBwcm90b2NvbCBkZXNpZ25lciwgbWFrZSBzdXJlIHRvIG5vdCBzcGVjaWZ5L3JlbHkg b24gdGhpbmdzIGxpa2UgKGZvciBleGFtcGxlKSBtdWx0aXZhbHVlIFRMVnMsIHNpbmNlIHlvdXIg bWVzc2FnZXMgaGF2ZSB0byB3b3JrIHdpdGggKmFueSogcmVwcmVzZW50YXRpb27igJw/IElmIHNv LCBJIHRoaW5rIHRoYXQgc2hvdWxkIGJlIGRvbmUgaW4gYSBsZXNzIGNvbXBsaWNhdGVkIGZhc2hp b24gKHNlZSBiZWxvdykuDQoNCiogcmVnYXJkaW5nIDU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTU+LiBTdHJ1Y3R1 cmU6DQpTaW5jZSB0aGlzIHNlY3Rpb24gdGFsa3MgYSBsb3QgYWJvdXQgZmxhZ3MsIGl04oCZZCBi ZSBuaWNlIGlmIGl0cyB0aXRsZSByZXByZXNlbnRlZCB0aGF0LiBNYXliZSBjb25zaWRlciByZW5h bWluZyBpdCB0byDigJ5TdHJ1Y3R1cmUgYW5kIEZsYWdz4oCcIG9yIHNvPw0KDQpJIG1vc3RseSBk b24ndCBhZ3JlZS4gU3RydWN0dXJlIGlzIHRoZSBzdWJqZWN0LCBmbGFncyBhcmUgYSBkZXRhaWwu DQoNCg0KKiBmcm9tIDYuMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1t YW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi4xPi4gQWRkcmVzcyBCbG9jayBDb21wcmVz c2lvbjoNCg0KDQogICBDb21wcmVzc2lvbiBvZiBhZGRyZXNzZXMgaW4gYW4gQWRkcmVzcyBCbG9j ayBjb25zaWRlcnMgYWRkcmVzc2VzIHRvDQoNCiAgIGNvbnNpc3Qgb2YgYSBIZWFkLCBhIE1pZCwg YW5kIGEgVGFpbCwgd2hlcmUgYWxsIGFkZHJlc3NlcyBpbiBhbg0KDQogICBBZGRyZXNzIEJsb2Nr IGhhdmUgdGhlIHNhbWUgSGVhZCBhbmQgVGFpbCwgYnV0IGRpZmZlcmVudCBNaWRzLg0KDQoNCkni gJlkIGZpbmQgdGhpcyBzZW50ZW5jZSBlYXNpZXIgdG8gcmVhZCBpZiBpdCBzdGFydGVkIHdpdGgg 4oCcQ29tcHJlc3Npb24gb2YgYWRkcmVzc2VzIGluIGFuIEFkZHJlc3MgQmxvY2sgaXMgcG9zc2li bGUgd2hlbiBhZGRyZXNzZXMgY29uc2lzdCBvZiBhIEhlYWQsIGEgTWlkIFvigKZd4oCdLg0KDQpO by4gVGhhdCdzIG1pc3NpbmcgdGhlIHBvaW50IGFuZCBtaXNsZWFkaW5nLiBBZGRyZXNzZXMgYXJl IGFsd2F5cyBjb25zaWRlcmVkIHRvIGhhdmUgdGhlIGhlYWQvbWlkL3RhaWwgZm9ybWF0LiBDb21w cmVzc2lvbiBpcyBwb3NzaWJsZSBpZiBlaXRoZXIgdGhlIGhlYWQgb3IgdGFpbCAob3IgYm90aCkg aXMgbm9uLWVtcHR5Lg0KDQoNCiogZnJvbSA2LjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTYuMT4uIEFkZHJlc3Mg QmxvY2sgQ29tcHJlc3Npb246DQoNCg0KDQogICBQdXR0aW5nIGFkZHJlc3NlcyBpbnRvIGEgbWVz c2FnZSBlZmZpY2llbnRseSBhbHNvIGhhcyB0byBpbmNsdWRlOg0KDQoNCldoeSDigJ5oYXMgdG/i gJw/IEnigJlkIHRoaW5rIHRoYXQgd291bGQgYmUgYSDigJ5tYXnigJwuIE11bHRpcGxlIEFkcmVz cyBCbG9ja3MgYW5kL29yIHJlb3JkZXJpbmcgZG9u4oCZdCBpbmNyZWFzZSBlZmZpY2llbmN5IGlu IGFsbCBwb3NzaWJsZSBjYXNlcy4uLg0KDQpJIHRoaW5rIHRoYXQncyB0aGUgd3JvbmcgY2hhbmdl LiBSYXRoZXIgImluY2x1ZGUiIHNob3VsZCBiZSAiY29uc2lkZXIiLg0KDQoNCiogZnJvbSA2LjI8 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2Fn ZS0wMyNzZWN0aW9uLTYuMj4uIFRMVnM6DQoNCiAgICAgIFsuLi5dIFRoaXMgaXMgZXZlbiBwb3Nz aWJsZSBpZiB0aGUgTVBSIFRMViBzcGVjaWZpZWQgaW4NCg0KICAgICAgT0xTUnYyIFtSRkM3MTgx PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTgxPl0gaXMgYWRkZWQ7IGJ1dCBpdCBp cyBub3QgcG9zc2libGUsIGluIGdlbmVyYWwsIGlmDQoNCiAgICAgIHRoZSBMSU5LX01FVFJJQyBU TFYgaXMgYWxzbyBhZGRlZC4NCg0KV2h5IGlzIGl0IG5vdCBwb3NzaWJsZSBmb3IgdGhlIGxhdHRl cj8gSWYgdGhhdCBjb3VsZCBiZSBleHBsYWluZWQvaGludGVkIGF0IGluIGEgaGFsZiBzZW50ZW5j ZSwgSSB0aGluayBpdOKAmWQgYmUgaGVscGZ1bCBpbmZvcm1hdGlvbiB0byBoYXZlIGluIHRoZSBk cmFmdC4NCg0KVGhhdCdzIHZlcnkgaGFyZCwgYW5kIG5vdCBqdXN0IGJlY2F1c2UgaXQncyBhIG5l Z2F0aXZlLiBJdCdzIHJlYWxseSBhbiBvYnNlcnZhdGlvbiB0aGF0IG1vdGl2YXRlcyB0aGUgZHVz Y3Vzc2lvbi4gQSBoYWxmIHNlbnRlbmNlIHdvdWxkIEkgdGhpbmsgY29uZnVzZSBtb3JlIHRoYW4g aXQgZW5saWdodGVucyAoaXQncyBiZWNhdXNlIHlvdSBoYXZlIHRvbyBtYW55IGNvbnN0cmFpbnRz IHRvIHNhdGlzZnkgYXQgb25jZSAtIEkgZG91YnQgdGhhdCBoZWxwZWQpLg0KDQoNCg0KICAgICAg SW4gYSB0eXBpY2FsIGNhc2Ugd2hlcmUgYQ0KDQogICAgICBMSU5LX1NUQVRVUyBUTFYgdXNlcyBv bmx5IHRoZSBWYWx1ZXMgSEVBUkQgYW5kIFNZTU1FVFJJQywgd2l0aA0KDQogICAgICBlbm91Z2gg YWRkcmVzc2VzLCBzb3J0ZWQgYXBwcm9wcmlhdGVseSwgdHdvIHNpbmdsZSB2YWx1ZSBUTFZzIGNh bg0KDQogICAgICBiZSBtb3JlIGVmZmljaWVudCB0aGFuIG9uZSBtdWx0aXZhbHVlIFRMVi4NCg0K U2FtZSB0aGluZzogd2h5Pw0KDQpIZXJlIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgb2J2aW91cyB0 byBhbnlvbmUgd2hvIGhhcyBsb29rZWQgYXQgNTQ0NC4NCg0KDQoqIHJlZ2FyZGluZyB0aGUgc2Vj b25kIHBhcmFncmFwaCBmcm9tIDYuMzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi4zPi4gVExWIFZhbHVlcywgaS5l Lg0KDQoNCg0KICAgVGhpcyBhcHByb2FjaCB3YXMgc3BlY2lmaWVkIGluIFtSRkM3MTg4PGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTg4Pl0sIGFuZCByZXF1aXJlZCBmb3IgcHJvdG9j b2xzDQoNCiAgIHRoYXQgZXh0ZW5kIFtSRkM2MTMwPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM2MTMwPl0gYW5kIFtSRkM3MTgxPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3 MTgxPl0uICBJdCBpcyBoZXJlIFJFQ09NTUVOREVEIHRoYXQNCg0KICAgdGhpcyBhcHByb2FjaCBp cyBmb2xsb3dlZCB3aGVuIGRlZmluaW5nIGFueSBBZGRyZXNzIEJsb2NrIFRMViB0aGF0DQoNCiAg IG1heSBiZSB1c2VkIGJ5IGEgcHJvdG9jb2wgdXNpbmcgW1JGQzU0NDQ8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzU0NDQ+XS4NCg0KVGhlIHRlcm0g4oCedGhpcyBhcHByb2FjaOKAnCBj b25mdXNlZCBtZSwgc2luY2UgSSBpbml0aWFsbHkgIHRob3VnaHQgaXQgbWVhbnQg4oCedGhlIGFw cHJvYWNoIGlzIHRvIHVzZSBVTlNQRUNJRklFRCBpbiBhIHdheSB0aGF0IG1ha2VzIHNlbnNl4oCc IHJhdGhlciB0aGFuIOKAnnRoZSBhcHByb2FjaCBpcyB0byB1c2UgVU5TUEVDSUZJRUTigJwuIE1h eWJlIHRoYXQgY291bGQgYmUgcmV3b3JkZWQgdG8gc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBv Zg0KVGhlIFVOU1BFQ0lGSUVEIFRMViBhbmQgaXRzIHVzYWdlIHdhcyBzcGVjaWZpZWQgaW4gW1JG QzcxODhd4oCmDQo/DQoNCk5vLiBUaGVyZSBpcyBubyBVTlNQRUNJRklFRCBUTFYuIFRoZXJlIGlz IGEgcmVjb21tZW5kYXRpb24gdG8gaW5jbHVkZSBhbiBVTlNQRUNJRklFRCB2YWx1ZSBpbiBhIFRM Vi4gQnV0IHJlYWxseSwgd2UndmUgZGVzY3JpYmVkIHRoaXMgb25jZSBpbiA3MTg4LCBpdCdzIHRo ZXJlIHRvIHJlYWQuDQoNCg0KKiByZWdhcmRpbmcgNi4zPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi02LjM+LiBUTFYg VmFsdWVzOg0KVGhlIHNlY29uZCBwYXJhZ3JhcGggaXMgYSBiaXQgY29uZnVzaW5nIGFuZCBzZWVt cyB0byBleHBsYWluZyByb2dobHkgdGhlIHNhbWUgdGhpbmdzIGFzIHRoZSBmb3VydGggcGFyYWdy YXBocy4gSeKAmWQgcHJvcG9zZSB0byBtZXJnZSB0aGUgc2Vjb25kIGludG8gdGhlIGZvdXJ0aC4N Cg0KSSdtIG5vdCBzdXJlIEkgZXhhY3RseSBhZ3JlZSwgYnV0IHRoZSBvcmRlcmluZyBpbiB0aGF0 IHNlY3Rpb24gY291bGQgYmUgaW1wcm92ZWQuDQoNCg0KKiBmcm9tIDYuNDxodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24t Ni40Pi4gQXV0b21hdGlvbjoNCg0KDQogICBUaGUgcG9zc2libGUgZ2FpbiBkZXBlbmRzIG9uIHRo ZSBlZmZpY2llbmN5DQoNCiAgIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlIGNyZWF0aW9uLA0KDQp0 aGUgdGVybSDigJ50aGUgb3JpZ2luYWwgbWVzc2FnZSBjcmVhdGlvbuKAnCBzZWVtcyBhIGJpdCBh bWJpZ3VvdXPigJMgZG9lcyB0aGlzIHJlZmVyIHRvIHRoZSBtZXNzYWdlIGFzIGNyZWF0ZWQgYnkg YW4gUkZDNTQ0NCBtZXNzYWdlIGJ1aWxkZXIgaW1wbGVtZW50YXRpb24/DQoNClllcy4NCg0KDQpB ZGRpdGlvbmFsbHksIEknbSBjb25jZXJuZWQgYWJvdXQgdHdvIHRoaW5ncyB0aGF0ICphcmVu4oCZ dCogaW4gdGhlIGRyYWZ0Og0KDQoqICBTb21lIG9mIHRoZSBBT0RWdjIgY28tYXV0aG9ycyBhbmQg bWUgaGF2ZSBhc2tlZCBmb3IgYSBsaXN0IG9mIOKAnmFzIGEgcHJvdG9jb2wsIHlvdSBjYW4gc2V0 IGFsbCBvZiB0aGVzZSBmaWVsZHMgb2YgYSBtZXNzYWdlLCBidXQgcGxlYXNlIGxlYXZlIHRoZSBy ZXN0IGFsb25l4oCcLCB3aGljaCB3b3VsZOKAmXZlIHNhdmVkIHVzIG1hbnkgaG91cnMgb2YgZGlz Y3Vzc2lvbnMgKGFuZCBIZW5uaW5nIGEgbG90IG9mIHRpbWUgc3BlbnQgZXhwbGFpbmluZyB0aGVz ZSB0aGluZ3PigKYpLiBUaGVzZSByZXF1ZXN0cyBoYXZlIGJlZW4gbWV0IHdpdGggYSByZWZ1c2Fs IHRvIHNwZWNpZnkgYSBjb25jcmV0ZSBBUEksIGFzIHN1Y2ggYW4gZWZmb3J0IGlzIGRlcGVuZGVu dCBvbiBvdXRzaWRlIGZhY3RvcnMgc3VjaCBhcyBwcm9ncmFtbWluZyBsYW5ndWFnZSBvciBzb2Z0 d2FyZSBhcmNoaXRlY3R1cmUuIEkgYWdyZWUgd2l0aCB0aGlzIG5vdGlvbiwgYnV0IGEgcHJvZ3Jh bW1pbmctbGFuZ3VhZ2UgZGVwZW5kZW50IEFQSSBpcyBub3Qgd2hhdCB3ZeKAmXZlIGFza2VkIGZv ci4gSeKAmXZlIHRyaWVkIHRvIHN1cHBseSBhIHNrZXRjaCBvZiB3aGF0IEkgZGlkIGFzayBmb3Ig aW4gWzFdLCBidXQgdW5mb3J0dW5hdGVseSBJIGRpZG7igJl0IGdldCBhbiBhbnN3ZXIgKGFuZCBh cyBmYXIgYXMgSSBjYW4gc2VlIGl0LCB0aGUgZHJhZnQgd2FzbuKAmXQgY2hhbmdlZCBlaXRoZXIp LiBJIHN0aWxsIHRoaW5rIHRoYXQgc3VjaCBhIGxpc3QsIGluIHdoYXRldmVyIGZvcm0sIHdvdWxk IGJlIHZlcnkgaGVscGZ1bCBmb3IgZnV0dXJlIEludGVybmV0LURyYWZ0IGF1dGhvcnMgYW5kIEkg YWxzbyB0aGluayB0aGlzIHJlcXVlc3QgaXMgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBpbnRlbnRp b25zIHN0YXRlZCBpbiAxLjEgSGlzdG9yeSBhbmQgUHVycG9zZSwgYW5kIEkgdGhpbmsgaXQgc2hv dWxkIGJlIGluY2x1ZGVkIGluIHRoZSBkb2N1bWVudC4NCg0KTm8uIFRoZXJlIGFyZSBtYW55IHJl YXNvbnMgd2h5IHdlJ3JlIGp1c3Qgbm90IHRvdWNoaW5nIHRoaXMgb25lLg0KDQpPbmUgaXMgdGhh dCBsYW5ndWFnZSBpbmRlcGVuZGVuY2UgaXMgYSBtaXJhZ2UuIEhvdyB5b3UgZ28gYWJvdXQgdGhp bmdzIGlzIGNvbXBsZXRlbHkgZGlmZmVyZW50IGluLCBmb3IgZXhhbXBsZSBhbiBvYmplY3Qgb3Jp ZW50ZWQgbGFuZ3VhZ2UgdGhhbiBvbmUgdGhhdCBpc24ndC4gU2VjdGlvbiA0LjUgc2hvd3MgdGhh dCB0aGVyZSBhcmUgcXVpdGUgZGlmZmVyZW50IHdheXMgb2YgZG9pbmcgdGhpbmdzIGV2ZW4gZ2l2 ZW4gYSBkZWNpc2lvbiB0byB1c2UgYSBtYXAgYXBwcm9hY2gsIGFuZCB0aGVyZSBhcmUgb3RoZXIg YXBwcm9hY2hlcyB0aGFuIHRoYXQuIEl0IHdvdWxkIGJlIHdyb25nIGFuZCBiZXlvbmQgb3VyIGNv bXBldGVuY2UgdG8gc3VnZ2VzdCBvbmUgb2YgdGhlc2UgYXMgImJlc3QiLiBUaGVyZSdzIHJlYXNv bnMgdGhlIElFVEYgZG9lc24ndCBkbyB0aGlzLCBhbmQgdGhhdCdzIG9uZS4NCg0KUGx1cywgZnJh bmtseSwgdGhlIHdvcmsgaXQgd291bGQgdGFrZSBpcyBiZXlvbmQgd2hhdCB3ZSBjaG9vc2UgdG8g c3BlbmQuDQoNCg0KPFNwZWFraW5nIGFzIGEgV0cgUGFydGljaXBhbnQ+DQoNCkknbSBjb25mdXNl ZCAod2hpY2ggaXMgYW4gYWx0b2dldGhlciB0b28gY29tbW9uIG9jY3VycmVuY2UgdGhlc2UgZGF5 cykuIEkgZ2V0IHRoYXQgd2UgZG9uJ3Qgd2FudCB0byBzcGVjaWZ5IGFuIEFQSS4gQnV0IEkgdGhp bmsgdGhlIGRpc2N1c3Npb24gYWJvdXQgZmllbGRzIGEgcHJvdG9jb2wgY2FuIGFuZCBjYW4ndCB0 b3VjaCBpbiBhIG1lc3NhZ2VzIGlzIGEgZ29vZCB0aGluZyAtIGFuZCBpdCdzIG9uZSBzcG90IHdo ZXJlIEksIHRvbywgZmluZCB0aGUgZG9jdW1lbnQgd2FudGluZy4NCg0KVG8gcGFyYXBocmFzZSBz b21ldGhpbmcgSSd2ZSBzYWlkIGJlZm9yZSwgSSBiZWxpZXZlIHRoYXQgUkZDIDU0NDQgY2hhbmdl cyB0aGUgcmVsYXRpb25zaGlwIHRoYXQgYSByb3V0aW5nIHByb3RvY29sIGhhcyB3aXRoIGFuICJp bnRlcmZhY2UiLiBJJ20gbm90IGNvbW1lbnRpbmcgb24gd2hldGhlciBvciBub3QgdGhhdCdzIGEg Z29vZCB0aGluZywgb3IgYSBiYWQgdGhpbmcgLSBqdXN0IHRoYXQgaXQgZG9lcyBjaGFuZ2UgdGhl IHJlbGF0aW9uc2hpcC4gVGhpcyBjaGFuZ2UgaGFzIGJlZW4gYXQgdGhlIHJvb3Qgb2Ygc29tZSBv ZiB0aGUgbG9uZy1ydW5uaW5nIGRpc2N1c3Npb25zIGFzIHRvIHdoZXRoZXIgcHJvdG9jb2xzIHVu ZGVyIGRldmVsb3BtZW50IHdlcmUgUkZDIDU0NDQgY29tcGxpYW50IG9yIG5vdC4gVGhlIGdvYWwg b2YgdGhpcyBkb2N1bWVudCBiZWluZyB0byBlbGltaW5hdGUgKGl0J3MgYSBnb2FsLCBwcm9iYWJs eSBub3QgcmVhY2hhYmxlKSB0aG9zZSBkaXNjdXNzaW9ucywgSSdkIGxpa2UgdG8gc2VlIHRoYXQg aW5mb3JtYXRpb24gaW4gdGhlIGRvY3VtZW50IGluIHNvbWUgZm9ybS4NCg0KSSdtIGludGVyZXN0 ZWQgaW4gc2VlaW5nIHRoaXMgZG9jdW1lbnQgcHJvZ3Jlc3MsIGFuZCBldmVudHVhbGx5IGJlIHB1 Ymxpc2hlZC4gSSB0aGluayBpdCB3aWxsIGhlbHAgZnV0dXJlIHByb3RvY29sIGRlc2lnbmVycyB0 byBiZXR0ZXIgdXNlIFJGQyA1NDQ0LiBCdXQgSSB3b3VsZCBsaWtlIHRvIHNlZSAqc29tZXRoaW5n KiBhbG9uZyB0aGUgbGluZXMgb2Ygd2hhdCBMb3R0ZSBpcyByZXF1ZXN0aW5nLCBhcyBJIHRoaW5r IGl0IHdpbGwgaW1wcm92ZSB0aGUgZG9jLg0KDQpSZWdhcmRzLA0KU3Rhbg0KDQoNCg0KDQoqIEFz IHRoZSBleGFjdCBydWxlcyBmb3IgdXNpbmcvc2V0dGluZyB0aGUgaG9wIGNvdW50ICYgaG9wLWxp bWl0IGZpZWxkcyBhcmUgY3VycmVudGx5IGJlaW5nIGRpc2N1c3NlZCB3LyByZWdhcmQgdG8gQU9E VnYyIGluIGFub3RoZXIgdGhyZWFkIFsyXeKAkyBzaG91bGQgYSBkZWZpbml0aXZlIGFuc3dlciB0 byB0aGF0IHF1ZXN0aW9uIGJlIHBhcnQgb2YgNTQ0NC11c2FnZT8NCg0KWW91IGRvbid0IHdhbnQg dGhhdC4gQmVjYXVzZSBpZiB3ZSBkaWQgc3BlY2lmeSB0aGF0IHlvdSdkIGZpbmQgeW91cnNlbGYg bW9yZSBjb25zdHJhaW5lZCB0aGFuIHlvdSB3YW50IHRvIGJlLiBUaGVyZSBpcyBhIGRlc2lnbiBp bnRlbnQgZGVzY3JpYmVkIGluIDU0NDQsIGJ1dCBpdCBhc3N1bWVzIGltbXV0YWJsZSBtZXNzYWdl cy4gV2hpY2ggeW91IGRvbid0IHdhbnQuIFJlYWxseSwgd2UncmUgZG9pbmcgeW91IGEgZmF2b3Vy IGJ5IG5vdCBpbXBvc2luZyBvbiB5b3UuDQoNCg0KQmVzdCByZWdhcmRzLA0KTG90dGUNCg0KWzFd IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cx ODA4Mi5odG1sDQpbMl0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5l dC9jdXJyZW50L21zZzE4Njc0Lmh0bWwNCg0KDQpBbSAwNi4wNC4yMDE2IHVtIDE5OjE0IHNjaHJp ZWIgSnVzdGluIERlYW4gPGJlYmVtYXN0ZXJAZ21haWwuY29tPG1haWx0bzpiZWJlbWFzdGVyQGdt YWlsLmNvbT4+Og0KDQpUaGUgY2hhaXJzIGFncmVlIHRoYXQgYSAzIHdlZWsgV0dMQyBpcyBhcHBy b3ByaWF0ZS4gIEV2ZXJ5b25lIHBsZWFzZSByZWFkIHRoZSBkcmFmdCBlYXJseSBhbmQgZ2V0IGNv bW1lbnRzIGluIGVhcmx5IHNvIHRoYXQgdGhleSBjYW4gYmUgYWRkcmVzc2VkIHdpdGhpbiB0aGUg bGFzdCBjYWxsIHBlcmlvZC4NCg0KSnVzdGluDQoNCk9uIFdlZCwgQXByIDYsIDIwMTYgYXQgNzo0 MCBBTSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgPGNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl bXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4+IHdyb3RlOg0KT2J2 aW91c2x5ICsxIHRvIHRoZSByZXF1ZXN0IGZvciBXR0xDLg0KDQpXaXRoIHJlZ2FyZCB0byB3aGF0 J3MgY2hhbmdlZCwgdGVjaG5pY2FsbHkgdGhlIG9ubHkgc2lnbmlmaWNhbnQgdGhpbmcgaXMgdG8g bWFrZSBpdCBjbGVhciB0aGF0IGlmIGEgcHJvdG9jb2wgZGVsaXZlcnMgYSBtZXNzYWdlIHRvIHRo ZSBtdWx0aXBsZXhlciwgdGhlIG11bHRpcGxleGVyIG11c3QgcGFzcyBpdCBvbiB1bmNoYW5nZWQg dG8gdGhlIHByb3RvY29sIChhbm90aGVyIGluc3RhbmNlIG9mLCBhdCBhbm90aGVyIHJvdXRlcikg dW5jaGFuZ2VkLiBXaXRob3V0IHRoYXQgbm90aGluZyB0aGF0IHRoZSBwcm90b2NvbCBpdHNlbGYg Y2hvb3NlcyB0byBkbyB3aXRoIHJlZ2FyZCB0byBzZWN1cml0eSBtYWtlcyBzZW5zZS4gVGhvdWdo IHRoZSBwcm90b2NvbCBjYW4gYWx0ZXJuYXRpdmVseSBsZXQgdGhlIG11bHRpcGxleGVyIGRvIHRo ZSBzZWN1cml0eSwgNzE4MiBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gZWl0aGVyIHdheS4gVGhpcyBp c24ndCByZWFsbHkgbmV3LCBidXQgaXQgd2Fzbid0IGZvcm1hbGx5IHNwZWxsZWQgb3V0LiBJdCdz IHByZXNlbnRlZCBhcyBwYXJ0IG9mIHNwZWxsaW5nIG91dCBtdWx0aXBsZXhlciBydWxlcyBtb3Jl IGNhcmVmdWxseS4NCg0KQnV0IHdoYXQgYWJvdXQgbWVzc2FnZSBvcHRpbWlzYXRpb24/IFRoYXQn cyBhIGZ1bmN0aW9uIG9mIGNvbnN0cnVjdGluZyBhIDU0NDQgbWVzc2FnZSwgbm90IHRoZSBtdWx0 aXBsZXhlciwgYW5kIGlzIGRvd24gdG8gdGhhdCA1NDQ0IGluY2x1ZGVzIHR3byB0aGluZ3MgLSBw YWNrZXQvbWVzc2FnZSBzdHJ1Y3R1cmUgKGFuZCBpbXBsaWNpdGx5LCBhbmQgaW4gcHJldHR5IG11 Y2ggYW55IGltcGxlbWVudGF0aW9uIEkgd291bGQgZXhwZWN0IHRvIHNlZSwgYSBwYXJzZXIgYW5k IGJ1aWxkZXIgZm9yIHRoYXQgc3RydWN0dXJlKSBhbmQgdGhlIG11bHRpcGxleGVyLiBTbyB3ZSB0 b29rIHRoZSBvcHBvcnR1bml0eSB0byBzZXBhcmF0ZSBvdXQgbW9yZSBjbGVhcmx5IGEgZGlzY3Vz c2lvbiBvZiB0aGUgdHdvLCB3aGljaCB3ZSB0aGluayB3aWxsIGJlIGhlbHBmdWwuDQoNCi0tDQpD aHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3Rl bXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0 PiAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJs b3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwg Q2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNz ZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMu Y29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0 ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTog U3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgVWxy aWNoIEhlcmJlcmcNClNlbnQ6IDA1IEFwcmlsIDIwMTYgMjA6MDgNClRvOiBtYW5ldEBpZXRmLm9y ZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbWFuZXRdIFdHTEMgcmVxdWVzdCBm b3IgZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmln aW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRl cm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdo ZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRz IG9yIHJlcGx5Lg0KRm9sbG93IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9u IElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFp bCBtZXNzYWdlcy4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNCioqKiBXQVJOSU5HICoqKg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBt ZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb24uDQoNCg0KSGks DQoNCkFzIHlvdSBoYXZlIHNlZW4sIHdlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHJldmlzaW9uIG9m IDU0NDQtdXNhZ2UuIFRoZSBhdXRob3JzIGZlZWwgY29tZm9ydGFibGUgdGhhdCB3ZSBoYXZlIGFk ZHJlc3NlZCBhbGwgaXNzdWVzIGJ5IHRoaXMgdmVyc2lvbiwgYW5kIHdvdWxkIGxpa2UgdG8gYXNr IHRoZSBXRyBjaGFpcnMgdG8gaXNzdWUgYSBXR0xDIG9uIHRoaXMgZG9jdW1lbnQuIFdoaWxlIGl0 IGlzIGEgZmFpcmx5IHNob3J0IGRvY3VtZW50LCBnaXZlbiB0aGF0IGl0IGlzIElFVEYgd2VlayBm b3Igc29tZSwgd2UnZCBzdWdnZXN0IHRoYXQgYSAzLTQgd2VlayBXR0xDIHdvdWxkIGJlIGFwcHJv cHJpYXRlLg0KDQpCZXN0IHJlZ2FyZHMNClVscmljaA0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRm Lm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21hbmV0DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGll bnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRl ci4NCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3Ig ZGlzY2xvc2Ugb3INCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24u DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBt YWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFu ZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWls dG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21hbmV0DQoNCg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD7B9GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsInNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1HQjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCBiZWxpZXZlIHdlIGNhbiBvciBzaG91bGQgc3VnZ2Vz dCBhbiBpbXBsZW1lbnRhdGlvbi4gVGhhdOKAmXMgbm90IHdoYXQgdGhlIElFVEYgZG9lcywgYW5k IGl0IHdvdWxkIGJlIGEgaGFyZCwgcHJvYmFibHkgaW1wb3NzaWJsZSwgc2VsbCwgdG8gdGhlIElF U0cuIFRoYXQNCiB0aGUgb2J2aW91cyBpbXBsZW1lbnRhdGlvbiBlbXBsb3lzIGFuIGluZGVwZW5k ZW50IHBhcnNlciBpcyBhbHJlYWR5IHNhaWQgLSBpdCBtYXkgYmUgYXBwcm9wcmlhdGUgdG8gc3Ry ZW5ndGhlbiB0aGUgd29yZHMsIGJ1dCB0aGlzIHNlY29uZCBJ4oCZbSBub3Qgc3VyZSBpZiB0aGF0 4oCZcyBuZWVkZWQgKG5vdCBnb3QgdGltZSB0byBjaGVjayBjdXJyZW50IHdvcmRpbmcpLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9vOnA+PC9zcGFu PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3Bo ZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3Rl bXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+ PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5U PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJz cDsmIzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wgJm5ic3A7PGI+RToNCjwvYj48YSBocmVm PSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj M0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNo bm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+ DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHlsZT0iY29s b3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxi cj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdpc3Rl cmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIg N1lQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+U3RhbiBSYXRsaWZmPGJyPg0KPGI+U2VudDo8L2I+IDE2IEFwcmls IDIwMTYgMTk6MDk8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KPGI+ Q2M6PC9iPiBtYW5ldEBpZXRmLm9yZzsgQ2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFttYW5ldF0gV0dMQyByZXF1ZXN0IGZvciBkcmFmdC1pZXRmLW1hbmV0LXJm YzU0NDQtdXNhZ2UtMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAx LjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFs aWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0 ZSI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1l c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZy b20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtz LCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48L3NwYW4+PC9p PjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFn czwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzMzMzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZl LA0KIGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93 d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiI+DQpo ZXJlPC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz MzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3Bp Y2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lz dGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmcl MjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3Nw YW4+PC9lbT48L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3 MiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjEuMHB0IDQuMHB0IDEu MHB0IDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFs aWduOmNlbnRlciI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPioqDQo8L3NwYW4+PC9z dHJvbmc+PC9zcGFuPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V0FSTklORw0K PC9zcGFuPjwvc3Ryb25nPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPioqKjwvc3Bhbj48L3N0cm9uZz48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5FWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNp ZGUgb3VyIG9yZ2FuaXphdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBcHIgMTUsIDIw MTYgYXQgMzoyNyBQTSwgQ2hyaXN0b3BoZXIgRGVhcmxvdmUgJmx0OzxhIGhyZWY9Im1haWx0bzpj aHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWsiIHRhcmdldD0iX2JsYW5rIj5jaHJpc0BtbmVtb3N5 bmUuZGVtb24uY28udWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgeW91IG1lYW4g YnkgdGhlIGNvbmNlcHQgb2YgJnF1b3Q7ZmllbGRzIHRoZSBwcm90b2NvbCBjYW4gYW5kIGNhbid0 IHRvdWNoJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q0FWRUFUOiBJ IGFtIHNwZWFraW5nIGhlcmUgYXMgYSBXb3JraW5nIEdyb3VwIHBhcnRpY2lwYW50LiBXaXRoIHRo YXQgdW5kZXJzdG9vZDoNCjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRU TCBpcyBhIGdyZWF0IGV4YW1wbGUsIHNpbmNlIHRoYXQgZGlzY3Vzc2lvbiBibGV3IHRoZSBtYWls aW5nIGxpc3QgdXAgYSBmZXcgbW9udGhzIGFnby4gSSdtICpub3QqIHNheWluZyBtYW5pcHVsYXRp bmcgVFRMIGlzIGEgZ29vZCB0aGluZyBmb3IgYSBwcm90b2NvbCB0byB0cnkgLSBpbiB0cnV0aCwg SSB0aGluayBpdCdzIHByZXR0eSAmcXVvdDtoYWNreSZxdW90Oy4gQnV0IHRoZQ0KIG5vdGlvbiB3 YXMgZmxvYXRlZCwgYW5kIGluIHRoZSBjb250ZXh0IG9mIHRoYXQgZGlzY3Vzc2lvbiwgaXQgbWF5 IHdpbGwgaGF2ZSB3b3JrZWQuIFRoZSBvcHBvc2l0aW9uIG9uLWxpc3Qgd2FzIGZhc3QsIGFuZCBw cmV0dHkgZm9yY2VmdWwuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSd2ZSBzYWlkIGJlZm9y ZSAtIDU0NDQsIGVzcGVjaWFsbHkgd2l0aCB0aGUgbXVsdGlwbGV4ZXIsIGNoYW5nZXMgdGhlIHJl bGF0aW9uc2hpcCBiZXR3ZWVuIGEgcm91dGluZyBwcm90b2NvbCBhbmQgYW4gaW50ZXJmYWNlLiBJ IHRoaW5rIHRoZSBkb2N1bWVudCBzaG91bGQgaGF2ZSBzb21lIHR5cGUgb2YgJnF1b3Q7b3ZlcnZp ZXcmcXVvdDsgc2VjdGlvbiB3aGljaCBkaXNjdXNzZXMNCiB0aGVzZSBkaWZmZXJlbmNlcywgaW4g b3JkZXIgdG8gZnJhbWUgdGhlIGlzc3VlIGZvciBzb21lb25lIGNvbWluZyBhbG9uZyB3aG8gaGFz bid0IGJlZW4gYSBwYXJ0IG9mIHRoZSA1NDQ0IG1haWwgZGlzY3Vzc2lvbi4NCjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij5JJ20gdGFsa2luZyBhYm91dCB0aGUgdHlwZSBvZiBvdmVydmlldyB0aGF0 IGdvZXMgc29tZXRoaW5nIGxpa2UgdGhpczoNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mcXVv dDtVc2Ugb2YgUkZDIDU0NDQgd2l0aCB0aGUgbXVsdGlwbGV4ZXIgZmVhdHVyZSBpbXBvc2VzIGRl c2lnbiByZXF1aXJlbWVudHMgb24gdGhlIHByb3RvY29sLiBUaGUgYWN0dWFsIHRyYW5zcG9ydCBt ZWNoYW5pc20gaXMgYWJzdHJhY3RlZCBmcm9tIHRoZSBwcm90b2NvbC4gRm9yIGV4YW1wbGUsIHJv dXRpbmcgcHJvdG9jb2xzIGFyZSBub3QgYXdhcmUgb2YgcHJlY2lzZWx5DQogd2hlbiBhIG1lc3Nh Z2UgaXMgc2VudC4gQSBnb29kIGV4YW1wbGUgb2Ygb3BlcmF0aW9uIGluIHRoaXMgbW9kZWwgaXMg W0JHUF0sIHV0aWxpemluZyB0aGUgW1RDUF0gdHJhbnNwb3J0LiBUaGlzIGlzIG9wcG9zZWQgdG8g YSBwcm90b2NvbCBzdWNoIGFzIFtPU1BGXSwgd2hpY2ggaXMgY2FwYWJsZSBvZiBzZW5kaW5nIHRy YWZmaWMgd2l0aCBpdHMgb3duIElQIHR5cGUuIFNpbmNlIHRoZSB0cmFuc3BvcnQgaXMgYWJzdHJh Y3RlZCwgcHJvdG9jb2xzDQogYXJlIG5vdCBwcmVzZW50ZWQgd2l0aCAmcXVvdDtwYWNrZXRzJnF1 b3Q7LCBhbmQgYXJlIG5vdCBjYXBhYmxlIG9mIG1hbmlwdWxhdGluZyBkYXRhIGl0ZW1zIGluIHBh Y2tldCBoZWFkZXJzIChlLmcuIGRhdGEgaXRlbXMgYXQgdGhlIElQIGFuZC9vciBNQUMgbGF5ZXJz KS4mcXVvdDs8YnI+DQo8YnI+DQpBcyBMb3UgQmVyZ2VyIHB1dCBpdCB0byBtZSBpbiB0aGUgY29u dGV4dCBvZiBETEVQIC0gJnF1b3Q7WW91IHdhbnQgYW4gZW5naW5lZXIgdG8gYmUgYWJsZSB0byBw aWNrIHVwIHRoaXMgZG9jdW1lbnQsIHdpdGggbm8gcHJpb3IgZXhwb3N1cmUgdG8gdGhlIHRvcGlj LCBhbmQgY29kZSBhbiBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9uLiZxdW90OyZuYnNwOyBJ IHRoaW5rIHRoaXMgdHlwZSBvZiBhbiBvdmVydmlldywgc2V0dGluZyBiYXNpYyBncm91bmQgcnVs ZXMsIHdvdWxkDQogaGVscC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSd2ZSBhbHNvIGNvbnRl bmRlZCBmb3IgYSB3aGlsZSBub3cgdGhhdCA1NDQ0LCB3aXRoIHRoZSBtdXgsIGVmZmVjdGl2ZWx5 IGZvcmNlcyBhbiBhcmNoaXRlY3R1cmUgb24gaW1wbGVtZW50ZXJzIC0gaW4gdGhlIExpbnV4IHdv cmxkLCB0aGF0IGFyY2hpdGVjdHVyZSBpcyBhIDU0NDQgcGFyc2VyIGFzIGFuIGluZGVwZW5kZW50 IHByb2Nlc3MsIHdpdGggSVBDIG1lY2hhbmlzbXMNCiB0byB0aGUgcm91dGluZyBwcm90b2NvbChz KSBpdCBpcyBzZXJ2aWNpbmcuIFRoZSA1NDQ0IHBhcnNlciBpdHNlbGYgJnF1b3Q7b3ducyZxdW90 OyB0aGUgdHJhbnNwb3J0ICh0aGUgc29ja2V0KS4gVGhlIHVzYWdlIGRvY3VtZW50ICpzdHJvbmds eSBpbmZlcnMqIHRoYXQuIEkgYmVsaWV2ZSB3ZSBzaG91bGQgY29uY3JldGVseSBzdGF0ZSBpdCwg c28gd2UgZG9uJ3QgaGF2ZSB0byBhbnN3ZXIgdGhlIHF1ZXN0aW9uIG92ZXIgYW5kIG92ZXIgYWdh aW4uDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlN0YW48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPldoZW4gYSBwcm90b2NvbCBjcmVhdGVzIGEgbWVzc2FnZSBmcm9t IHNjcmF0Y2ggaXQncyBub3QgY29uc3RyYWluZWQgaW4gYW55IHdheSBJJ2QgZGVzY3JpYmUgaW4g c3VjaCB0ZXJtcy4gU28gSSBhc3N1bWUgeW91IG1lYW4gd2hlbiBpdCByZWNlaXZlcyBhIG1lc3Nh Z2UgYW5kIHRoZW4gc2VuZHMgYSBzaW1pbGFyIG1lc3NhZ2UuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSB0d28gY2FzZXMgdGhl cmUuIFVuY2hhbmdlZCAod2l0aCB0aGUgc3BlY2lhbCBleGNlcHRpb25zIGZvciBob3AgY291bnQg YW5kIGxpbWl0KSBhbmQgbm90IHVuY2hhbmdlZC4gVGhlIGZvcm1lciBpcyBiZXR0ZXIsIGFuZCB0 aGVyZSdzIHJlYWxseSBub3RoaW5nIG1vcmUgdG8gc2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBsZXQncyBjb25zaWRlciB0aGUgbGF0 dGVyLiBSZWFsbHkgaXQncyBub3QgdGhlIHNhbWUgbWVzc2FnZSwgaXQncyBhIGJyYW5kIG5ldyBt ZXNzYWdlLiBUaGF0J3MgYSB1c2VmdWwgd2F5IHRvIGxvb2sgYXQgaXQgZnJvbSBhIHNlY3VyaXR5 IHBlcnNwZWN0aXZlLCBiZWNhdXNlIGl0IHRlbGxzIHlvdSB0aGF0IGVuZCB0byBlbmQgYXV0aGVu dGljYXRpb24gaXNuJ3QgZ29pbmcgdG8gd29yay4gQW5kIHdoYXQgYXJlDQogdGhlIHJlc3RyaWN0 aW9ucyBvbiBicmFuZCBuZXcgbWVzc2FnZXM/IFRoZSBzYW1lIGFzIG9uIGFueSBuZXcgbWVzc2Fn ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T0ssIHlvdSBtaWdodCBzYXksIHRydWUgYnV0IGRvZXMgdGhhdCBtZWFuIEkgY2FuIGFkZCB0aGlz LCByZW1vdmUgdGhhdCwgY2hhbmdlIHRoZSBob3AgZGF0YT8gWWVzLiBCdXQgaXMgdGhhdCBhIGdv b2QgaWRlYT8gTm8uIEJ1dCBtYXliZSB5b3UgYXJlIGZvcmNlZCBpbnRvIGl0LiBCdXQgdGhhdCBp dCdzIGluaGVyZW50bHkgbm90IGdvb2Qgc3VnZ2VzdHMgdGhlIGNvcm9sbGFyeSB0aGF0IGlmIHlv dSBtdXN0LA0KIGRvIHRoZSBtaW5pbXVtIGFuZCBtYWtlIGl0IHRyYWNrYWJsZS4gQnV0IHRoYXQn cyBub3QgYSA1NDQ0IHJlcXVpcmVtZW50LCBqdXN0IGdvb2QgcHJhY3RpY2UuIEl0IGRvZXMgYnJl YWsgNzE4MiBtZXNzYWdlIElDVnMsIHNvIGRvbid0IHVzZSB0aGVtLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBjb3VsZCwgaHlwb3RoZXRp Y2FsbHksIGhhdmUgc29tZW9uZSBjcmVhdGUgYW4gZXh0ZW5zaW9uIG9yIGFsdGVybmF0aXZlIHRv IDcxODIgdGhhdCBkZWZpbmVkIGFnZ3JlZ2F0ZWQgc2lnbmF0dXJlcy4gVGhlbiB3ZSdkIGhhdmUg cnVsZXMgb24gd2hhdCB5b3UgY291bGQgY2hhbmdlLiBCdXQgdGhhdCB3b3VsZCBiZWxvbmcgdGhl cmUuIElmIHlvdSB0aGluayB0aG9zZSB3b3VsZCBiZSBnb29kLCB0aGVuIGFnYWluDQogeW91IHdv dWxkIHdhbnQgbWFrZSBtaW5pbWFsIGNoYW5nZXMsIGFuZCBtYWlubHkgb25seSBvZiBjZXJ0YWlu IHR5cGVzLiBXaGF0IHR5cGVzPyBUaGVyZSBJIGNhbid0IGhlbHAgeW91IGFzIEkgZG9uJ3QgaGF2 ZSBhIGNhbmRpZGF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIHN1bW1hcnk/IERvbid0IGNoYW5nZSBpZiB5b3UgZG9uJ3QgaGF2ZSB0 by4gVGhhdCdzIHJlY29tbWVuZGVkLiBJZiB5b3UgbXVzdCBjaGFuZ2UgeW91J3JlIG9uIHlvdXIg b3duICh3aXRoIHRoZSBzYW1lIHJlc3RyaWN0aW9ucyBhcyBuZXcgbWVzc2FnZXMpLiBBZHZpY2Ug bGlrZSAmcXVvdDthcyBsaXR0bGUgYXMgcG9zc2libGUmcXVvdDsgaXMgZ29vZCwgYnV0IHRoYXQn cyBub3QgYWN0dWFsbHkgNTQ0NCBhZHZpY2UuIEFuZA0KIGRvbid0IHVzZSA3MTgyIG1lc3NhZ2Ug SUNWcy48YnI+DQo8YnI+DQotLSAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5DaHJpc3RvcGhlciBEZWFybG92ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOmNocmlzdG9waGVy LmRlYXJsb3ZlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdG9waGVyLmRlYXJsb3Zl QGdtYWlsLmNvbTwvYT4gKGlQaG9uZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzpjaHJpc0BtbmVtb3N5bmUuZGVtb24u Y28udWsiIHRhcmdldD0iX2JsYW5rIj5jaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWs8L2E+ICho b21lKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDE1IEFwciAyMDE2 LCBhdCAxOTozNywgU3RhbiBSYXRsaWZmICZsdDs8YSBocmVmPSJtYWlsdG86cmF0bGlmZnN0YW5A Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmF0bGlmZnN0YW5AZ21haWwuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5NeSBtYWluIGNvbmNlcm4gYWRkcmVzc2VkIGlubGluZS4uLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgQXByIDE1LCAyMDE2IGF0IDE6NDkgUE0sIENo cmlzdG9waGVyIERlYXJsb3ZlICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0b3BoZXIuZGVhcmxv dmVAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkEgZmV3IGltbWVkaWF0ZSBjb21tZW50cyBpbmxpbmUgYmVsb3cuPGJyPg0K PGJyPg0KLS0gJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzpjaHJpc3RvcGhlci5kZWFybG92ZUBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb208 L2E+IChpUGhvbmUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBocmVmPSJtYWlsdG86Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrIiB0YXJn ZXQ9Il9ibGFuayI+Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrPC9hPiAoaG9tZSk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAxNSBBcHIgMjAxNiwgYXQgMTU6MTgs IExvdHRlIFN0ZWVuYnJpbmsgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3R0ZS5zdGVlbmJyaW5rQGZ1 LWJlcmxpbi5kZSIgdGFyZ2V0PSJfYmxhbmsiPmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRl PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5zcGFya2VkIGJ5IHRoZSByZWNlbnRseSBzdGFydGVkIFdHTEMsIEnigJl2ZSByZXZpZXdlZCB0 aGUgY3VycmVudCByZXZpc2lvbiBvZiB0aGUgZHJhZnQuIEnigJlkIGxpa2UgdG8gb2ZmZXIgdGhl IHdvcmtpbmcgZ3JvdXAgbXkgcGVyc3BlY3RpdmUgYXMgc29tZW9uZSB3aG8gZG9lc27igJl0IGhh dmUgZGVjYWRlcyBvZiBwcm90b2NvbCBhbmQvb3IgcGFja2V0IGZvcm1hdCBkZXNpZ24gdW5kZXIg dGhlaXIgYmVsdCAoaS5lLg0KIHNvbWUgdGhpbmdzIG1pZ2h0IG5vdCBiZSBvYnZpb3VzIHRvIG1l IHRoYXQgYXJlIG9idmlvdXMgdG8gb3RoZXJzKSwgYnV0IGFsc28gYXMgc29tZW9uZSB3aG8gaGFz IHdvcmtlZCB3aXRoIFJGQyA1NDQ0IHdoZW4gaW1wbGVtZW50aW5nIGEgcm91dGluZyBwcm90b2Nv bCAoQU9EVnYyKSwgdXBkYXRpbmcgdGhlIHBhY2tldCBmb3JtYXQgb2YgYSByb3V0aW5nIHByb3Rv Y29sIChBT0RWdjIgYWdhaW4pIGFuZCAocGFydGlhbGx5KSBpbXBsZW1lbnRpbmcNCiBteSBvd24g UkZDNTQ0NCBidWlsZGVyL3BhcnNlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T3ZlcmFsbCwgSSB0aGluayB0aGUgZG9jdW1lbnQgaXMgZWFz eSB0byByZWFkIGFuZCBmb2xsb3cuIFRvIG1lLCBpdCBjb250YWlucyB2YWx1YWJsZSBpbmZvcm1h dGlvbiBhbmQgZ3VpZGFuY2UgYW5kIGluIHNvbWUgY2FzZXMgcHJldmVudHMgcGVvcGxlIGZyb20g c2hvb3RpbmcgdGhlbXNlbHZlcyBpbiB0aGUgZm9vdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIHJlYWxseSBoYXBweSB0aGlzIGRvY3Vt ZW50IGV4aXN0cyBhbmQgSeKAmWQgbGlrZSBpdCB0byBtb3ZlIGZvcndhcmQgc29vbiwgYnV0IEkg ZG8gZmVlbCB0aGF0IGl0IGlzIHN0aWxsIGxhY2tpbmcgaW4gc29tZSBhcmVhcywgd2hpY2ggaXMg d2h5IEkgd2FzIGEgYml0IHN1cnByaXNlZCB0byBzZWUgaXQgZ28gdG8gTGFzdCBDYWxsIGFsbCBv ZiBhIHN1ZGRlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdCByZWFsbHkuIFRoZSBh dXRob3JzIGhhZCBzYWlkIHdoYXQgdGhleSBpbnRlbmRlZCB0byBzYXksIG5vIG9uZSB3YXMgY29t bWVudGluZywgdGltZSBmb3IgV0dMQy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpcnN0LCBzb21lIG5pdHBp Y2tzIGFuZCBjb21tZW50czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+KiBmcm9tJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTEuMi4xIiB0 YXJnZXQ9Il9ibGFuayI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlv bjpub25lIj4xLjIuMTwvc3Bhbj48L2I+PC9hPjxiPi4gUGFja2V0L01lc3NhZ2UgRm9ybWF0PC9i Pjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7W+KApl0gYSBwYWNrZXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHJhbnNtaXNzaW9uIGZvbGxvd2luZyBhIHN1Y2Nl c3NmdWwgcGFja2V0IHJlY2VwdGlvbiBpcyBieSBkZXNpZ248bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb2YgYSBuZXcgcGFja2V0IHRoYXQgbWF5 IGluY2x1ZGUgYWxsLCBzb21lLCBvciBub25lIG9mIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZWNlaXZlZCBtZXNzYWdlcyBbLi4uXTxv OnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5J4oCZbSBub3QgYSBuYXRpdmUgc3BlYWtlciwgYnV0IHRoYXQg4oCeb2bigJwgc2VlbXMg b3V0IG9mIHBsYWNlLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBhIG5hdGl2ZSBzcGVha2VyLCBhbmQg bm8sIGl0J3Mgbm90LiBTb21lIHdvdWxkIHJlcGVhdCBpdCBhZnRlciBlYWNoIG9mIGFsbCwgc29t ZSBhbmQgbm9uZSwgYW5kIEkgbWlnaHQgc29tZXRpbWVzLiBCdXQgaXQgcmVhbGx5IGRvZXNuJ3Qg bWF0dGVyIHdoaWNoIG9mIHRoZSB0d28gc3R5bGVzIHdlIHBpY2ssIHRoZSBSRkMgRWRpdG9yIG1h eSB3ZWxsIGNoYW5nZSB0byB0aGUgb3RoZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogUmVnYXJkaW5nJm5ic3A7PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0 NC11c2FnZS0wMyNzZWN0aW9uLTQuMiIgdGFyZ2V0PSJfYmxhbmsiPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+NC4yPC9zcGFuPjwvYj48L2E+PGI+LiBQ YWNrZXRzIGFuZCBNZXNzYWdlczo8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj50aGlzIHNlY3Rpb24gdGFsa3MgYSBsb3QgYWJvdXQgaG93IHRo ZSBtdWx0aXBsZXhlciBvcGVyYXRlcywgc28gSSB0aGluayBpdOKAmWQgYmUgaGVscGZ1bCBpZiBp dHMgdGl0bGUgcmVmbGVjdGVkIHRoYXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBvZiB0d28gb3BpbmlvbnMg b24gdGhhdC4gT24gdGhlIG9uZSBoYW5kIGl0IGlzLCBhcyBpdHMgdGl0bGUgc3VnZ2VzdHMsIGFi b3V0IHRoZSBwYWNrZXQgYW5kIG1lc3NhZ2UgbGV2ZWwsIGFzIG9wcG9zZWQgdG8gbG93ZXIgbGV2 ZWxzLCBhbmQgaXRzIHRpdGxlIGNvbnRyYXN0cyB3aXRoIHRoYXQgaWYgNC4zIGZvciB0aGF0IHJl YXNvbi4gT24gdGhlIG90aGVyIGhhbmQgeW91IGFyZSByaWdodCwgaXQgZG9lcw0KIGhhdmUgbXVj aCBhYm91dCB0aGUgbXVsdGlwbGV4ZXIuIEEgdGl0bGUgY292ZXJpbmcgYWxsIHRocmVlIHdvdWtk IHN0YXJ0IGdldHRpbmcgY3VtYmVyc29tZS4gV2lsbCB0YWtlIHRoaXMgb25lIGF3YXkgdG8gdGhp bmsgYWJvdXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiogZnJvbSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi00LjQi IHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPjQuNDwvc3Bhbj48L2I+PC9hPjxiPi4gQWRkcmVzc2VzIFJlcXVpcmUgQXR0cmli dXRlczo8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5i c3A7IEFuIHVubW9kaWZpZWQgZXh0ZW5zaW9uIHRvIE5IRFAgd291bGQgaWdub3JlIHN1Y2ggYWRk cmVzc2VzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhcyByZXF1aXJlZCwg YXMgaXQgZG9lcyBub3Qgc3VwcG9ydCB0aGF0IHNwZWNpYWxpemVkIHB1cnBvc2UuPG86cD48L286 cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQgZmlyc3Qg Z2xhbmNlLCAodG8gbWUpIHRoaXMgcmVhZHMgYXMg4oCeQWxsIGFkZHJlc3NlcyB0aGF0IGFyZSBh c3NvY2lhdGVkIHdpdGggYW4gdW5rbm93biBUTFYgYXJlIGlnbm9yZWTigJwsIHdoaWNoIGlzIG9i dmlvdXNseSBub25zZW5zZSAoYnV0IHF1aXRlIHBhbmljLWluZHVjaW5nIDpEKS4gSeKAmWQgcHJv cG9zZSB0byByZXdvcmQgaXQgdG8gc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgQW4gdW5tb2Rp ZmllZCBleHRlbnNpb24gdG8gTkhEUCB3b3VsZCBub3QgY29uc2lkZXIgdGhpczxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhZGRyZXNzIHRvIGJlIG9mIGEgbmVpZ2hib3IsIGFz IGl0IGlzIGxhY2tpbmcgYSBMSU5LX1NUQVRVUzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyBvciBPVEhFUl9ORUlHSEIgVExWLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGFrZSB5b3VyIHBvaW50LCBi dXQgSSB0aGluayB0aGF0IGlmIHRoZSBhZGRyZXNzIGVuZHMgdXAgd2l0aCBubyByZWxldmFudCBh c3NvY2lhdGVkIFRMVnMgdGhlbiBpdCBpcyBpZ25vcmVkIGlzIGFsc28gYSBwb2ludC4gSSBkYXJl IHNheSB3ZSBjYW4gd29yZHNtaXRoIHNvbWV0aGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCBJIGRvbuKAmXQgcXVpdGUg Z2V0IHdoZXJlIHlvdeKAmXJlIGdvaW5nIHdpdGggdGhlIGxhc3QgcGFyYWdyYXBoIG9mIHRoYXQg c2VjdGlvbiAo4oCcPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRoZXNlIHJlc3RyaWN0 aW9ucyBkbyBub3QsIGhvd2V2ZXIsIG1lYW4gdGhhdCBhZGRlZCBpbmZvcm1hdGlvbiBpczwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgY29tcGxldGVseSBp Z25vcmVkIGZvciBwdXJwb3NlcyBvZiB0aGUgYmFzZSBwcm90b2NvbC7igJ0pLi4uPG86cD48L286 cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWFkIG9uLCB0aGUgcmVz dCBvZiB0aGUgcGFyYWdyYXBoIGRlc2NyaWJlcyB0aGUgY2FzZSB3aGVyZSBub3QuIEJ1dCB3ZSBt aWdodCB0ZWxlZ3JhcGggdGhhdCBiZXR0ZXIgaW4gdGhlIG9wZW5pbmcgc2VudGVuY2UuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBy ZWdhcmRpbmcgdGhlIG1hcHMgaW4mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNC41IiB0YXJn ZXQ9Il9ibGFuayI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpu b25lIj40LjU8L3NwYW4+PC9iPjwvYT48Yj4uIEluZm9ybWF0aW9uIFJlcHJlc2VudGF0aW9uOjwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkni gJltIGFmcmFpZCBJIGp1c3QgZG9u4oCZdCByZWFsbHkgdW5kZXJzdGFuZCB0aGUgcHVycG9zZSBv ZiB0aGlzIHNlY3Rpb24gYW5kIHRoZSBtYXBwaW5nIG5vdGF0aW9uLiBJ4oCZbSBhc3N1bWluZyB0 aGF0IHRoZSBtYXBzIGFyZSBzdXBwb3NlZCB0byBvZmZlciBhIHdheSBvZiBkZXNjcmliaW5nIGhv dyBhIFRMViByZWxhdGVzIHRvIGEgbWVzc2FnZSBvciBhbiBhZGRyZXNzPyZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgc28sIHdoeSBk b2VzIGl0IG9ubHkgbWVudGlvbiBleHRlbnNpb24gdHlwZXMsIGJ1dCBub3QgdGhlIGJhc2lzIHR5 cGVzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SXQgc2F5cyBleHRlbmRlZCB0eXBlcywgbWVhbmluZyB0aGUgY29tYmluYXRpb24gb2YgdGhl IHR3by4gQnV0IGZ1bGwgdHlwZSB3b3VsZCBiZSBiZXR0ZXIsIGFzIGFsbW9zdCBkZWZpbmVkIGlu IDU0NDQuIEluIGZhY3QgSSB0aGluayB3ZSBzaG91bGQgYWRkIGEgY29tbWVudCB0byB0aGUgbm90 YXRpb24gc2VjdGlvbi4gKDU0NDQgdXNlcyBhIHN5bWJvbGljIG5hbWUgcmF0aGVyIHRoYW4gdGhl IHBocmFzZS4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T3IgaXMgaXQgc3VwcG9zZWQgdG8gYmUgdXNlZCBzb21ldGhpbmcgbGlrZSB0 aGlzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+QkFTRV9UTFY8L3NwYW4+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+TWVzc2FnZTombmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+KGJhc2VfdGx2X2V4dGVuc2lvbl90eXBlXzEpIC0m Z3Q7ICgyIG9jdGV0cywgJnF1b3Q7dmFsdWUgYSB3aGVuIGNvbmRpdGlvbiB4IGlzIG1ldCZxdW90 Oyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+KGJhc2VfdGx2X2V4dGVuc2lv bl90eXBlXzIpIC0mZ3Q7ICgyIG9jdGV0cywgJnF1b3Q7dmFsdWUgYiB3aGVuIGNvbmRpdGlvbiB5 IGlzIG1ldCZxdW90Oyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPj8gQWxzbywgSSBkb27igJl0IHF1aXRlIGdldCBob3cgdGhpcyB3 b3VsZCBiZSB1c2VkIGluIGZ1dHVyZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucz8gT3IgYWlkIGlu IGltcGxlbWVudGluZyBSRkM1NDQ0IHBhcnNlcnM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbiBleGFtcGxlIG9yIGEgY2xhcmlmaWNhdGlvbiB3 b3VsZCBiZSB2ZXJ5IGhlbHBmdWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCdzIGEgd2F5IG9mIGxvb2tpbmcgYXQgdGhpbmdzLiBCdXQg bm90IHRoZSBvbmx5IG9uZSwgaXQgZ29lcyBvbiB0byBkaXNjdXNzIHZhcmlhbnRzLiBJIHRoaW5r IGl0IG1vc3RseSBjb21lcyB1bmRlciBoZWFkaW5nIG9mIGlmIHVzZWZ1bCB1c2UgaXQsIGlmIG5v dCBza2lwIGl0LiBXZSdsbCB0YWtlIGFub3RoZXIgbG9vaywgYnV0IEkgZG9uJ3QgdGhpbmsgdGhp cyB3aWxsIGV2ZXIgYmUgZWxlbWVudGFyeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIHJlZ2FyZGluZyZuYnNwOzxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2Ut MDMjc2VjdGlvbi00LjYiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjQuNjwvc3Bhbj48L2I+PC9hPjxiPi4gVExWczo8L2I+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBn ZW5lcmFsLCBpdOKAmXMgbm90IGNsZWFyIGV2ZXJ5d2hlcmUgaW4gdGhlIHNlY3Rpb24gd2hldGhl ciB5b3XigJlyZSB0YWxraW5nIHRvIFJGQzU0NDQgcGFyc2VyL2J1aWxkZXIgaW1wbGVtZW50b3Jz IG9yIHByb3RvY29sIGRlc2lnbmVycy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgQSBwcm90b2NvbCBTSE9VTEQgdXNlIGFuIGVmZmljaWVu dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyByZXByZXNlbnRhdGlvbiwgYnV0 IHRoaXMgaXMgYSBxdWFsaXR5IG9mIGltcGxlbWVudGF0aW9uIGlzc3VlLjxvOnA+PC9vOnA+PC9w cmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBub3Qgc3VyZSB3aGVyZSB5 b3XigJlyZSBnb2luZyB3aXRoIHRoZSBsYXN0IHBhcnQgb2YgdGhhdCBzZW50ZW5jZT8gSeKAmWQg cmV3b3JkIGl0IHRvIHNvbWV0aGluZyBsaWtlIOKAnkEgcHJvdG9jb2wgU0hPVUxEIHVzZSBhbiBl ZmZpY2llbnQgcmVwcmVzZW50YXRpb24sIGF2b2lkaW5nIHVubmVjZXNzYXJpbHkgdmVyYm9zZSB1 c2Ugb2YgVExWcyBhbmQgZXh0ZW5zaW9uIHR5cGVzLiBIb3dldmVyLCB0aGUgZmluYWwNCiBhcnJh bmdlbWVudCBpbiBhIG1lc3NhZ2UtIG9yIGFkZHJlc3NUTFYgYmxvY2sgaXMgJm5ic3A7YSBxdWFs aXR5IG9mIGltcGxlbWVudGF0aW9uIGlzc3Vl4oCcIChpbiBjYXNlIHRoYXTigJlzIHdoYXQgeW91 IG1lYW50KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Tm8sIHlvdSdyZSBjb25zaWRlcmluZyB0aGUgcHJvdG9jb2wgZGVzaWdu LiBUaGlzIGlzIGNvbnNpZGVyaW5nIHRoZSBwcm90b2NvbCBvYmplY3QgdGhhdCBpbXBsZW1lbnRz IHRoZSBwcm90b2NvbC4gVGhlcmUgaXNuJ3QgYSBvbmUgdG8gb25lIG1hcHBpbmcgZnJvbSBpbmZv cm1hdGlvbiB0byByZXByZXNlbnRhdGlvbiwgaXQncyB1cCB0byB0aGUgaW1wbGVtZW50YXRpb24g dG8gZG8gaXQgZWZmaWNpZW50bHkuIERpZmZlcmVudA0KIGltcGxlbWVudGF0aW9ucyBvZiB0aGUg c2FtZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIG1heSBkbyBiZXR0ZXIgb3Igd29yc2UgaGVyZS4g KFRyaXZpYWwgY2FzZSwgYW4gaW1wbGVtZW50YXRpb24gY291bGQgY2hvb3NlIHRvIG5ldmVyIGNv bXByZXNzIGFkZHJlc3Nlcy4gQmFkIGlkZWEsIGJ1dCBsZWdhbC4pPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIHRoZW46PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEE8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgcHJvdG9jb2wgTVVTVCByZWNvZ25pemUgYW55IHBl cm1pdHRlZCByZXByZXNlbnRhdGlvbiBvZiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgaW5mb3JtYXRpb247IGV2ZW4gaWYgaXQgY2hvb3NlcyB0byAoZm9yIGV4YW1wbGUp IG9ubHkgdXNlIG11bHRpdmFsdWU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg VExWcywgaXQgTVVTVCByZWNvZ25pemUgc2luZ2xlIHZhbHVlIFRMVnMgKGFuZCB2aWNlIHZlcnNh KS48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCmIEkg dGhvdWdodCBwcm90b2NvbHMgd2VyZW7igJl0IHN1cHBvc2VkIHRvIHNwZWNpZnkgd2hldGhlciBh IFRMViBpcyBhcnJhbmdlZCAoZm9yIGV4YW1wbGUpIGFzIGEgbXVsdGl2YWx1ZSBUTFY/ITxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JbXBsZW1lbnRhdGlvbiBhZ2Fpbiwgbm90IGRlc2lnbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIHNvLCBzaW5j ZSBhIHByb3RvY29sIHNob3VsZG4ndCBiZSBjb25jZXJuZWQgd2l0aCBtdWx0aXZhbHVlIFRMVnMg YW5kIHRoZSBsaWtlLCB3b3VsZG7igJl0IGl0IGJlIHRoZSAqUkZDNTQ0NCBpbXBsZW1lbnRhdGlv biogdGhhdCBNVVNUIHJlY29nbml6ZSBhbnkgcGVybWl0dGVkIHJlcHJlc2VudGF0aW9uPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+WW91J3JlIGFzc3VtaW5nIHRoYXQgdGhlcmUgaXMgYW4gUkZDIDU0NDQgaW1wbGVt ZW50YXRpb24uIFRoYXQncyB0aGUgc2FtZSB3YXkgdG8gd29yayBpZiB5b3UgcGxhbiB0byBpbXBs ZW1lbnQgbW9yZSB0aGFuIG9uZSBwcm90b2NvbC4gQnV0IG5vdGhpbmcgc2F5cyB5b3UgaGF2ZSB0 byBkbyBpdCB0aGF0IHdheS4gVGhlIGFyY2hpdGVjdHVyZSBkZWZpbmVkIGJ5IDU0OTggYWRtaXRz IG9mIHRoZSBtdWx0aXBsZXhlcg0KIGFuZCBwcm90b2NvbHMsIGFuZCB0aHVzIHRoZXNlIGFyZSBy dWxlcyBvbiB0aGUgcHJvdG9jb2wuIElmIHByb3RvY29scyBkZWxlZ2F0ZSBhbGwgdGhlaXIgY29t bW9uIHdvcmsgdG8gc29tZXRoaW5nIChwYXJzZXIvY3JlYXRvcikgdGhlbiBpdCBpbmhlcml0cyB0 aG9zZSByZXN0cmljdGlvbnMsIGJ1dCB0aGF0J3Mgbm90IGRlZmluZWQsIGFuZCB3ZSBjYW4ndCBh c3N1bWUgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T3IgaXMgdGhpcyBwYXJhZ3JhcGggcmVhbGx5IGp1c3QgYSBjb21wbGljYXRl ZCB3YXkgb2Ygc2F5aW5nIOKAnmFzIGEgcHJvdG9jb2wgZGVzaWduZXIsIG1ha2Ugc3VyZSB0byBu b3Qgc3BlY2lmeS9yZWx5IG9uIHRoaW5ncyBsaWtlIChmb3IgZXhhbXBsZSkgbXVsdGl2YWx1ZSBU TFZzLCBzaW5jZSB5b3VyIG1lc3NhZ2VzIGhhdmUgdG8gd29yayB3aXRoICphbnkqIHJlcHJlc2Vu dGF0aW9u4oCcPyBJZiBzbywgSSB0aGluaw0KIHRoYXQgc2hvdWxkIGJlIGRvbmUgaW4gYSBsZXNz IGNvbXBsaWNhdGVkIGZhc2hpb24gKHNlZSBiZWxvdykuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiByZWdhcmRpbmcmbmJzcDs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1 NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNSIgdGFyZ2V0PSJfYmxhbmsiPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+NTwvc3Bhbj48L2I+PC9hPjxiPi4gU3Ry dWN0dXJlOjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNpbmNlIHRoaXMgc2VjdGlvbiB0YWxrcyBhIGxvdCBhYm91dCBmbGFncywgaXTigJlk IGJlIG5pY2UgaWYgaXRzIHRpdGxlIHJlcHJlc2VudGVkIHRoYXQuIE1heWJlIGNvbnNpZGVyIHJl bmFtaW5nIGl0IHRvJm5ic3A74oCeU3RydWN0dXJlIGFuZCBGbGFnc+KAnCZuYnNwO29yIHNvPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBt b3N0bHkgZG9uJ3QgYWdyZWUuIFN0cnVjdHVyZSBpcyB0aGUgc3ViamVjdCwgZmxhZ3MgYXJlIGEg ZGV0YWlsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiogZnJvbSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi02LjEiIHRhcmdldD0i X2JsYW5rIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUi PjYuMTwvc3Bhbj48L2I+PC9hPjxiPi4gQWRkcmVzcyBCbG9jayBDb21wcmVzc2lvbjo8L2I+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IENvbXByZXNz aW9uIG9mIGFkZHJlc3NlcyBpbiBhbiBBZGRyZXNzIEJsb2NrIGNvbnNpZGVycyBhZGRyZXNzZXMg dG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY29uc2lzdCBvZiBhIEhlYWQs IGEgTWlkLCBhbmQgYSBUYWlsLCB3aGVyZSBhbGwgYWRkcmVzc2VzIGluIGFuPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEFkZHJlc3MgQmxvY2sgaGF2ZSB0aGUgc2FtZSBIZWFk IGFuZCBUYWlsLCBidXQgZGlmZmVyZW50IE1pZHMuPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZZCBmaW5kIHRoaXMgc2VudGVuY2Ug ZWFzaWVyIHRvIHJlYWQgaWYgaXQgc3RhcnRlZCB3aXRoIOKAnENvbXByZXNzaW9uIG9mIGFkZHJl c3NlcyBpbiBhbiBBZGRyZXNzIEJsb2NrIGlzIHBvc3NpYmxlIHdoZW4gYWRkcmVzc2VzIGNvbnNp c3Qgb2YgYSBIZWFkLCBhIE1pZCBb4oCmXeKAnS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vLiBUaGF0J3MgbWlzc2luZyB0aGUgcG9pbnQg YW5kIG1pc2xlYWRpbmcuIEFkZHJlc3NlcyBhcmUgYWx3YXlzIGNvbnNpZGVyZWQgdG8gaGF2ZSB0 aGUgaGVhZC9taWQvdGFpbCBmb3JtYXQuIENvbXByZXNzaW9uIGlzIHBvc3NpYmxlIGlmIGVpdGhl ciB0aGUgaGVhZCBvciB0YWlsIChvciBib3RoKSBpcyBub24tZW1wdHkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBmcm9tJm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZj NTQ0NC11c2FnZS0wMyNzZWN0aW9uLTYuMSIgdGFyZ2V0PSJfYmxhbmsiPjxiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+Ni4xPC9zcGFuPjwvYj48L2E+PGI+ LiBBZGRyZXNzIEJsb2NrIENvbXByZXNzaW9uOjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFB1 dHRpbmcgYWRkcmVzc2VzIGludG8gYSBtZXNzYWdlIGVmZmljaWVudGx5IGFsc28gaGFzIHRvIGlu Y2x1ZGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoeSDigJ5oYXMgdG/igJw/IEnigJlk IHRoaW5rIHRoYXQgd291bGQgYmUgYSDigJ5tYXnigJwuIE11bHRpcGxlIEFkcmVzcyBCbG9ja3Mg YW5kL29yIHJlb3JkZXJpbmcgZG9u4oCZdCBpbmNyZWFzZSBlZmZpY2llbmN5IGluIGFsbCBwb3Nz aWJsZSBjYXNlcy4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSB0aGluayB0aGF0J3MgdGhlIHdyb25nIGNoYW5nZS4gUmF0aGVyICZxdW90 O2luY2x1ZGUmcXVvdDsgc2hvdWxkIGJlICZxdW90O2NvbnNpZGVyJnF1b3Q7LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogZnJvbSZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0 LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi02LjIiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjYuMjwvc3Bhbj48L2I+PC9h PjxiPi4gVExWczo8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbLi4uXSBUaGlzIGlzIGV2ZW4gcG9zc2libGUgaWYg dGhlIE1QUiBUTFYgc3BlY2lmaWVkIGluPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9MU1J2MiBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzcxODEiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iJnF1b3Q7VGhlIE9wdGlt aXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgUHJvdG9jb2wgdmVyc2lvbiAyJnF1b3Q7Ij5SRkM3MTgx PC9hPl0gaXMgYWRkZWQ7IGJ1dCBpdCBpcyBub3QgcG9zc2libGUsIGluIGdlbmVyYWwsIGlmPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBM SU5LX01FVFJJQyBUTFYgaXMgYWxzbyBhZGRlZC48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaHkgaXMgaXQgbm90IHBvc3NpYmxlIGZvciB0 aGUgbGF0dGVyPyBJZiB0aGF0IGNvdWxkIGJlIGV4cGxhaW5lZC9oaW50ZWQgYXQgaW4gYSBoYWxm IHNlbnRlbmNlLCBJIHRoaW5rIGl04oCZZCBiZSBoZWxwZnVsIGluZm9ybWF0aW9uIHRvIGhhdmUg aW4gdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhdCdzIHZlcnkgaGFyZCwgYW5kIG5vdCBqdXN0IGJlY2F1c2UgaXQncyBh IG5lZ2F0aXZlLiBJdCdzIHJlYWxseSBhbiBvYnNlcnZhdGlvbiB0aGF0IG1vdGl2YXRlcyB0aGUg ZHVzY3Vzc2lvbi4gQSBoYWxmIHNlbnRlbmNlIHdvdWxkIEkgdGhpbmsgY29uZnVzZSBtb3JlIHRo YW4gaXQgZW5saWdodGVucyAoaXQncyBiZWNhdXNlIHlvdSBoYXZlIHRvbyBtYW55IGNvbnN0cmFp bnRzIHRvIHNhdGlzZnkgYXQgb25jZQ0KIC0gSSBkb3VidCB0aGF0IGhlbHBlZCkuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSW4gYSB0eXBpY2FsIGNhc2Ugd2hlcmUgYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMSU5LX1NUQVRVUyBUTFYgdXNlcyBvbmx5 IHRoZSBWYWx1ZXMgSEVBUkQgYW5kIFNZTU1FVFJJQywgd2l0aDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbm91Z2ggYWRkcmVzc2VzLCBzb3J0 ZWQgYXBwcm9wcmlhdGVseSwgdHdvIHNpbmdsZSB2YWx1ZSBUTFZzIGNhbjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiZSBtb3JlIGVmZmljaWVu dCB0aGFuIG9uZSBtdWx0aXZhbHVlIFRMVi48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TYW1lIHRoaW5nOiB3aHk/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlIEkgdGhpbmsgdGhp cyBzaG91bGQgYmUgb2J2aW91cyB0byBhbnlvbmUgd2hvIGhhcyBsb29rZWQgYXQgNTQ0NC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4q IHJlZ2FyZGluZyB0aGUgc2Vjb25kIHBhcmFncmFwaCBmcm9tJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNz ZWN0aW9uLTYuMyIgdGFyZ2V0PSJfYmxhbmsiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazt0 ZXh0LWRlY29yYXRpb246bm9uZSI+Ni4zPC9zcGFuPjwvYj48L2E+PGI+LiBUTFYgVmFsdWVzPC9i PiwgaS5lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsgJm5ic3A7 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoaXMgYXBwcm9hY2ggd2FzIHNw ZWNpZmllZCBpbiBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcxODgi IHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iQy4gYW5kIFQuIENsYXVzZW4iPlJGQzcxODg8L2E+XSwg YW5kIHJlcXVpcmVkIGZvciBwcm90b2NvbHM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsgdGhhdCBleHRlbmQgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM2MTMwIiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IiZxdW90O01vYmlsZSBBZCBIb2MgTmV0d29y ayAoTUFORVQpIE5laWdoYm9yaG9vZCBEaXNjb3ZlcnkgUHJvdG9jb2wgKE5IRFApJnF1b3Q7Ij5S RkM2MTMwPC9hPl0gYW5kIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzE4MSIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtUaGUgT3B0aW1pemVkIExpbmsgU3Rh dGUgUm91dGluZyBQcm90b2NvbCB2ZXJzaW9uIDImcXVvdDsiPlJGQzcxODE8L2E+XS4mbmJzcDsg SXQgaXMgaGVyZSBSRUNPTU1FTkRFRCB0aGF0PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IHRoaXMgYXBwcm9hY2ggaXMgZm9sbG93ZWQgd2hlbiBkZWZpbmluZyBhbnkgQWRkcmVz cyBCbG9jayBUTFYgdGhhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBtYXkg YmUgdXNlZCBieSBhIHByb3RvY29sIHVzaW5nIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNTQ0NCIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtHZW5lcmFsaXpl ZCBNQU5FVCBQYWNrZXQvTWVzc2FnZSBGb3JtYXQmcXVvdDsiPlJGQzU0NDQ8L2E+XS48bzpwPjwv bzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdGVy bSDigJ50aGlzIGFwcHJvYWNo4oCcIGNvbmZ1c2VkIG1lLCBzaW5jZSBJIGluaXRpYWxseSAmbmJz cDt0aG91Z2h0IGl0IG1lYW50IOKAnnRoZSBhcHByb2FjaCBpcyB0byB1c2UgVU5TUEVDSUZJRUQg aW4gYSB3YXkgdGhhdCBtYWtlcyBzZW5zZeKAnCByYXRoZXIgdGhhbiDigJ50aGUgYXBwcm9hY2gg aXMgdG8gdXNlIFVOU1BFQ0lGSUVE4oCcLiBNYXliZSB0aGF0IGNvdWxkIGJlIHJld29yZGVkIHRv IHNvbWV0aGluZyBhbG9uZyB0aGUNCiBsaW5lcyBvZiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNvdXJpZXIiPlRoZSBVTlNQRUNJRklFRCBUTFYgYW5kIGl0cyB1c2FnZSB3YXMgc3BlY2lmaWVk IGluIFtSRkM3MTg4XeKApjwvc3Bhbj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vLiBUaGVyZSBpcyBubyBVTlNQRUNJRklFRCBUTFYu IFRoZXJlIGlzIGEgcmVjb21tZW5kYXRpb24gdG8gaW5jbHVkZSBhbiBVTlNQRUNJRklFRCB2YWx1 ZSBpbiBhIFRMVi4gQnV0IHJlYWxseSwgd2UndmUgZGVzY3JpYmVkIHRoaXMgb25jZSBpbiA3MTg4 LCBpdCdzIHRoZXJlIHRvIHJlYWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiByZWdhcmRpbmcmbmJzcDs8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3Nl Y3Rpb24tNi4zIiB0YXJnZXQ9Il9ibGFuayI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3Rl eHQtZGVjb3JhdGlvbjpub25lIj42LjM8L3NwYW4+PC9iPjwvYT48Yj4uIFRMViBWYWx1ZXM6PC9i PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IHNlY29uZCBwYXJhZ3JhcGggaXMgYSBiaXQgY29uZnVzaW5nIGFuZCBzZWVtcyB0byBleHBsYWlu ZyByb2dobHkgdGhlIHNhbWUgdGhpbmdzIGFzIHRoZSBmb3VydGggcGFyYWdyYXBocy4gSeKAmWQg cHJvcG9zZSB0byBtZXJnZSB0aGUgc2Vjb25kIGludG8gdGhlIGZvdXJ0aC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBub3Qgc3VyZSBJ IGV4YWN0bHkgYWdyZWUsIGJ1dCB0aGUgb3JkZXJpbmcgaW4gdGhhdCBzZWN0aW9uIGNvdWxkIGJl IGltcHJvdmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiogZnJvbSZuYnNwOzxhIG5hbWU9Im1fNjU2NzU3MTYxNTEyMjc4MjcyMl9t Xy02NDg5MzU3MjY1ODIyOTUiPjwvYT48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi40IiB0YXJnZXQ9 Il9ibGFuayI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25l Ij42LjQ8L3NwYW4+PC9iPjwvYT48Yj4uIEF1dG9tYXRpb246PC9iPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGUgcG9zc2libGUgZ2FpbiBkZXBl bmRzIG9uIHRoZSBlZmZpY2llbmN5PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlIGNyZWF0aW9uLDxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSB0ZXJtIOKAnnRoZSBvcmlnaW5h bCBtZXNzYWdlIGNyZWF0aW9u4oCcIHNlZW1zIGEgYml0IGFtYmlndW91c+KAkyBkb2VzIHRoaXMg cmVmZXIgdG8gdGhlIG1lc3NhZ2UgYXMgY3JlYXRlZCBieSBhbiBSRkM1NDQ0IG1lc3NhZ2UgYnVp bGRlciBpbXBsZW1lbnRhdGlvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlllcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZGRpdGlvbmFsbHksIEknbSBjb25jZXJuZWQgYWJv dXQgdHdvIHRoaW5ncyB0aGF0ICphcmVu4oCZdCogaW4gdGhlIGRyYWZ0OjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qICZuYnNwO1NvbWUgb2Yg dGhlIEFPRFZ2MiBjby1hdXRob3JzIGFuZCBtZSBoYXZlIGFza2VkIGZvciBhIGxpc3Qgb2Yg4oCe YXMgYSBwcm90b2NvbCwgeW91IGNhbiBzZXQgYWxsIG9mIHRoZXNlIGZpZWxkcyBvZiBhIG1lc3Nh Z2UsIGJ1dCBwbGVhc2UgbGVhdmUgdGhlIHJlc3QgYWxvbmXigJwsIHdoaWNoIHdvdWxk4oCZdmUg c2F2ZWQgdXMgbWFueSBob3VycyBvZiBkaXNjdXNzaW9ucyAoYW5kIEhlbm5pbmcgYSBsb3Qgb2Yg dGltZQ0KIHNwZW50IGV4cGxhaW5pbmcgdGhlc2UgdGhpbmdz4oCmKS4gVGhlc2UgcmVxdWVzdHMg aGF2ZSBiZWVuIG1ldCB3aXRoIGEgcmVmdXNhbCB0byBzcGVjaWZ5IGEgY29uY3JldGUgQVBJLCBh cyBzdWNoIGFuIGVmZm9ydCBpcyBkZXBlbmRlbnQgb24gb3V0c2lkZSBmYWN0b3JzIHN1Y2ggYXMg cHJvZ3JhbW1pbmcgbGFuZ3VhZ2Ugb3Igc29mdHdhcmUgYXJjaGl0ZWN0dXJlLiBJIGFncmVlIHdp dGggdGhpcyBub3Rpb24sIGJ1dCBhIHByb2dyYW1taW5nLWxhbmd1YWdlDQogZGVwZW5kZW50IEFQ SSBpcyBub3Qgd2hhdCB3ZeKAmXZlIGFza2VkIGZvci4gSeKAmXZlIHRyaWVkIHRvIHN1cHBseSBh IHNrZXRjaCBvZiB3aGF0IEkgZGlkIGFzayBmb3IgaW4gWzFdLCBidXQgdW5mb3J0dW5hdGVseSBJ IGRpZG7igJl0IGdldCBhbiBhbnN3ZXIgKGFuZCBhcyBmYXIgYXMgSSBjYW4gc2VlIGl0LCB0aGUg ZHJhZnQgd2FzbuKAmXQgY2hhbmdlZCBlaXRoZXIpLiBJIHN0aWxsIHRoaW5rIHRoYXQgc3VjaCBh IGxpc3QsIGluIHdoYXRldmVyIGZvcm0sDQogd291bGQgYmUgdmVyeSBoZWxwZnVsIGZvciBmdXR1 cmUgSW50ZXJuZXQtRHJhZnQgYXV0aG9ycyBhbmQgSSBhbHNvIHRoaW5rIHRoaXMgcmVxdWVzdCBp cyBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIGludGVudGlvbnMgc3RhdGVkIGluJm5ic3A7PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPjEuMSBIaXN0b3J5IGFuZCBQdXJwb3NlLCZuYnNw Ozwvc3Bhbj5hbmQgSSB0aGluayBpdCBzaG91bGQgYmUgaW5jbHVkZWQgaW4gdGhlIGRvY3VtZW50 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Tm8uIFRoZXJlIGFyZSBtYW55IHJlYXNvbnMgd2h5IHdlJ3JlIGp1c3Qgbm90IHRvdWNoaW5nIHRo aXMgb25lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbmUgaXMgdGhhdCBsYW5ndWFnZSBpbmRlcGVuZGVuY2UgaXMgYSBtaXJhZ2UuIEhvdyB5 b3UgZ28gYWJvdXQgdGhpbmdzIGlzIGNvbXBsZXRlbHkgZGlmZmVyZW50IGluLCBmb3IgZXhhbXBs ZSBhbiBvYmplY3Qgb3JpZW50ZWQgbGFuZ3VhZ2UgdGhhbiBvbmUgdGhhdCBpc24ndC4gU2VjdGlv biA0LjUgc2hvd3MgdGhhdCB0aGVyZSBhcmUgcXVpdGUgZGlmZmVyZW50IHdheXMgb2YgZG9pbmcg dGhpbmdzIGV2ZW4gZ2l2ZW4NCiBhIGRlY2lzaW9uIHRvIHVzZSBhIG1hcCBhcHByb2FjaCwgYW5k IHRoZXJlIGFyZSBvdGhlciBhcHByb2FjaGVzIHRoYW4gdGhhdC4gSXQgd291bGQgYmUgd3Jvbmcg YW5kIGJleW9uZCBvdXIgY29tcGV0ZW5jZSB0byBzdWdnZXN0IG9uZSBvZiB0aGVzZSBhcyAmcXVv dDtiZXN0JnF1b3Q7LiBUaGVyZSdzIHJlYXNvbnMgdGhlIElFVEYgZG9lc24ndCBkbyB0aGlzLCBh bmQgdGhhdCdzIG9uZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UGx1cywgZnJhbmtseSwgdGhlIHdvcmsgaXQgd291bGQgdGFrZSBpcyBiZXlv bmQgd2hhdCB3ZSBjaG9vc2UgdG8gc3BlbmQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtTcGVha2luZyBh cyBhIFdHIFBhcnRpY2lwYW50Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gY29uZnVzZWQgKHdoaWNoIGlzIGFuIGFsdG9nZXRoZXIg dG9vIGNvbW1vbiBvY2N1cnJlbmNlIHRoZXNlIGRheXMpLiBJIGdldCB0aGF0IHdlIGRvbid0IHdh bnQgdG8gc3BlY2lmeSBhbiBBUEkuIEJ1dCBJIHRoaW5rIHRoZSBkaXNjdXNzaW9uIGFib3V0IGZp ZWxkcyBhIHByb3RvY29sIGNhbiBhbmQgY2FuJ3QgdG91Y2ggaW4gYSBtZXNzYWdlcyBpcyBhIGdv b2QgdGhpbmcgLSBhbmQgaXQncyBvbmUgc3BvdA0KIHdoZXJlIEksIHRvbywgZmluZCB0aGUgZG9j dW1lbnQgd2FudGluZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VG8gcGFyYXBocmFzZSBzb21ldGhpbmcgSSd2ZSBzYWlkIGJlZm9y ZSwgSSBiZWxpZXZlIHRoYXQgUkZDIDU0NDQgY2hhbmdlcyB0aGUgcmVsYXRpb25zaGlwIHRoYXQg YSByb3V0aW5nIHByb3RvY29sIGhhcyB3aXRoIGFuICZxdW90O2ludGVyZmFjZSZxdW90Oy4gSSdt IG5vdCBjb21tZW50aW5nIG9uIHdoZXRoZXIgb3Igbm90IHRoYXQncyBhIGdvb2QgdGhpbmcsIG9y IGEgYmFkIHRoaW5nIC0ganVzdCB0aGF0IGl0IGRvZXMgY2hhbmdlDQogdGhlIHJlbGF0aW9uc2hp cC4gVGhpcyBjaGFuZ2UgaGFzIGJlZW4gYXQgdGhlIHJvb3Qgb2Ygc29tZSBvZiB0aGUgbG9uZy1y dW5uaW5nIGRpc2N1c3Npb25zIGFzIHRvIHdoZXRoZXIgcHJvdG9jb2xzIHVuZGVyIGRldmVsb3Bt ZW50IHdlcmUgUkZDIDU0NDQgY29tcGxpYW50IG9yIG5vdC4gVGhlIGdvYWwgb2YgdGhpcyBkb2N1 bWVudCBiZWluZyB0byBlbGltaW5hdGUgKGl0J3MgYSBnb2FsLCBwcm9iYWJseSBub3QgcmVhY2hh YmxlKSB0aG9zZSBkaXNjdXNzaW9ucywNCiBJJ2QgbGlrZSB0byBzZWUgdGhhdCBpbmZvcm1hdGlv biBpbiB0aGUgZG9jdW1lbnQgaW4gc29tZSBmb3JtLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gaW50ZXJlc3RlZCBpbiBzZWVp bmcgdGhpcyBkb2N1bWVudCBwcm9ncmVzcywgYW5kIGV2ZW50dWFsbHkgYmUgcHVibGlzaGVkLiBJ IHRoaW5rIGl0IHdpbGwgaGVscCBmdXR1cmUgcHJvdG9jb2wgZGVzaWduZXJzIHRvIGJldHRlciB1 c2UgUkZDIDU0NDQuIEJ1dCBJIHdvdWxkIGxpa2UgdG8gc2VlICpzb21ldGhpbmcqIGFsb25nIHRo ZSBsaW5lcyBvZiB3aGF0IExvdHRlIGlzIHJlcXVlc3RpbmcsIGFzIEkgdGhpbmsNCiBpdCB3aWxs IGltcHJvdmUgdGhlIGRvYy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0YW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+KiBBcyB0aGUgZXhhY3QgcnVsZXMgZm9yIHVzaW5nL3NldHRpbmcgdGhlIGhvcCBjb3Vu dCAmYW1wOyBob3AtbGltaXQgZmllbGRzIGFyZSBjdXJyZW50bHkgYmVpbmcgZGlzY3Vzc2VkIHcv IHJlZ2FyZCB0byBBT0RWdjIgaW4gYW5vdGhlciB0aHJlYWQgWzJd4oCTIHNob3VsZCBhIGRlZmlu aXRpdmUgYW5zd2VyIHRvIHRoYXQgcXVlc3Rpb24gYmUgcGFydCBvZiA1NDQ0LXVzYWdlPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGRv bid0IHdhbnQgdGhhdC4gQmVjYXVzZSBpZiB3ZSBkaWQgc3BlY2lmeSB0aGF0IHlvdSdkIGZpbmQg eW91cnNlbGYgbW9yZSBjb25zdHJhaW5lZCB0aGFuIHlvdSB3YW50IHRvIGJlLiBUaGVyZSBpcyBh IGRlc2lnbiBpbnRlbnQgZGVzY3JpYmVkIGluIDU0NDQsIGJ1dCBpdCBhc3N1bWVzIGltbXV0YWJs ZSBtZXNzYWdlcy4gV2hpY2ggeW91IGRvbid0IHdhbnQuIFJlYWxseSwgd2UncmUgZG9pbmcgeW91 IGENCiBmYXZvdXIgYnkgbm90IGltcG9zaW5nIG9uIHlvdS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Mb3R0ZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMV0mbmJz cDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1 cnJlbnQvbXNnMTgwODIuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cxODA4Mi5odG1sPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WzJdIDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cx ODY3NC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTg2NzQuaHRtbDwvYT4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFtIDA2LjA0LjIwMTYgdW0gMTk6MTQgc2NocmllYiBKdXN0aW4gRGVhbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJlYmVtYXN0ZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmViZW1h c3RlckBnbWFpbC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSBjaGFpcnMgYWdyZWUgdGhhdCBhIDMgd2VlayBXR0xDIGlzIGFwcHJv cHJpYXRlLiZuYnNwOyBFdmVyeW9uZSBwbGVhc2UgcmVhZCB0aGUgZHJhZnQgZWFybHkgYW5kIGdl dCBjb21tZW50cyBpbiBlYXJseSBzbyB0aGF0IHRoZXkgY2FuIGJlIGFkZHJlc3NlZCB3aXRoaW4g dGhlIGxhc3QgY2FsbCBwZXJpb2QuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5KdXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBcHIgNiwgMjAxNiBhdCA3OjQwIEFNLCBEZWFybG92ZSwg Q2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9idmlv dXNseSAmIzQzOzEgdG8gdGhlIHJlcXVlc3QgZm9yIFdHTEMuPGJyPg0KPGJyPg0KV2l0aCByZWdh cmQgdG8gd2hhdCdzIGNoYW5nZWQsIHRlY2huaWNhbGx5IHRoZSBvbmx5IHNpZ25pZmljYW50IHRo aW5nIGlzIHRvIG1ha2UgaXQgY2xlYXIgdGhhdCBpZiBhIHByb3RvY29sIGRlbGl2ZXJzIGEgbWVz c2FnZSB0byB0aGUgbXVsdGlwbGV4ZXIsIHRoZSBtdWx0aXBsZXhlciBtdXN0IHBhc3MgaXQgb24g dW5jaGFuZ2VkIHRvIHRoZSBwcm90b2NvbCAoYW5vdGhlciBpbnN0YW5jZSBvZiwgYXQgYW5vdGhl ciByb3V0ZXIpIHVuY2hhbmdlZC4NCiBXaXRob3V0IHRoYXQgbm90aGluZyB0aGF0IHRoZSBwcm90 b2NvbCBpdHNlbGYgY2hvb3NlcyB0byBkbyB3aXRoIHJlZ2FyZCB0byBzZWN1cml0eSBtYWtlcyBz ZW5zZS4gVGhvdWdoIHRoZSBwcm90b2NvbCBjYW4gYWx0ZXJuYXRpdmVseSBsZXQgdGhlIG11bHRp cGxleGVyIGRvIHRoZSBzZWN1cml0eSwgNzE4MiBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gZWl0aGVy IHdheS4gVGhpcyBpc24ndCByZWFsbHkgbmV3LCBidXQgaXQgd2Fzbid0IGZvcm1hbGx5DQogc3Bl bGxlZCBvdXQuIEl0J3MgcHJlc2VudGVkIGFzIHBhcnQgb2Ygc3BlbGxpbmcgb3V0IG11bHRpcGxl eGVyIHJ1bGVzIG1vcmUgY2FyZWZ1bGx5Ljxicj4NCjxicj4NCkJ1dCB3aGF0IGFib3V0IG1lc3Nh Z2Ugb3B0aW1pc2F0aW9uPyBUaGF0J3MgYSBmdW5jdGlvbiBvZiBjb25zdHJ1Y3RpbmcgYSA1NDQ0 IG1lc3NhZ2UsIG5vdCB0aGUgbXVsdGlwbGV4ZXIsIGFuZCBpcyBkb3duIHRvIHRoYXQgNTQ0NCBp bmNsdWRlcyB0d28gdGhpbmdzIC0gcGFja2V0L21lc3NhZ2Ugc3RydWN0dXJlIChhbmQgaW1wbGlj aXRseSwgYW5kIGluIHByZXR0eSBtdWNoIGFueSBpbXBsZW1lbnRhdGlvbiBJIHdvdWxkIGV4cGVj dCB0byBzZWUsDQogYSBwYXJzZXIgYW5kIGJ1aWxkZXIgZm9yIHRoYXQgc3RydWN0dXJlKSBhbmQg dGhlIG11bHRpcGxleGVyLiBTbyB3ZSB0b29rIHRoZSBvcHBvcnR1bml0eSB0byBzZXBhcmF0ZSBv dXQgbW9yZSBjbGVhcmx5IGEgZGlzY3Vzc2lvbiBvZiB0aGUgdHdvLCB3aGljaCB3ZSB0aGluayB3 aWxsIGJlIGhlbHBmdWwuPGJyPg0KPGJyPg0KLS08YnI+DQpDaHJpc3RvcGhlciBEZWFybG92ZTxi cj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIElu dGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjxicj4N ClQ6ICZuYnNwOzxhIGhyZWY9InRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0IiB0YXJn ZXQ9Il9ibGFuayI+JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NDwvYT4gJm5ic3A7fCAmbmJzcDtFOg0K PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9i bGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+PGJyPg0KPGJyPg0KQkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBH cmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0 cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5iYWVzeXN0ZW1z LmNvbS9haTwvYT48YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVk PGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTxicj4N ClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJy ZXksIEdVMiA3WVA8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZy b206IG1hbmV0IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5tYW5ldC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9m IFVscmljaCBIZXJiZXJnPGJyPg0KU2VudDogMDUgQXByaWwgMjAxNiAyMDowODxicj4NClRvOiA8 YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRm Lm9yZzwvYT48YnI+DQpTdWJqZWN0OiBbbWFuZXRdIFdHTEMgcmVxdWVzdCBmb3IgZHJhZnQtaWV0 Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0 ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFs IHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuPGJyPg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdo ZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRz IG9yIHJlcGx5Ljxicj4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGlu ayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMg ZW1haWwgbWVzc2FnZXMuPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQoqKiogV0FSTklORyAqKio8YnI+DQpFWFRF Uk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9y Z2FuaXphdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQpIaSw8YnI+DQo8 YnI+DQpBcyB5b3UgaGF2ZSBzZWVuLCB3ZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyByZXZpc2lvbiBv ZiA1NDQ0LXVzYWdlLiBUaGUgYXV0aG9ycyBmZWVsIGNvbWZvcnRhYmxlIHRoYXQgd2UgaGF2ZSBh ZGRyZXNzZWQgYWxsIGlzc3VlcyBieSB0aGlzIHZlcnNpb24sIGFuZCB3b3VsZCBsaWtlIHRvIGFz ayB0aGUgV0cgY2hhaXJzIHRvIGlzc3VlIGEgV0dMQyBvbiB0aGlzIGRvY3VtZW50LiBXaGlsZSBp dCBpcyBhIGZhaXJseSBzaG9ydCBkb2N1bWVudCwgZ2l2ZW4NCiB0aGF0IGl0IGlzIElFVEYgd2Vl ayBmb3Igc29tZSwgd2UnZCBzdWdnZXN0IHRoYXQgYSAzLTQgd2VlayBXR0xDIHdvdWxkIGJlIGFw cHJvcHJpYXRlLjxicj4NCjxicj4NCkJlc3QgcmVnYXJkczxicj4NClVscmljaDxicj4NCjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFu ZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kio8YnI+DQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0 byB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4NCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRl IGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj4NCllvdSBzaG91 bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8 YnI+DQpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4NCioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWFuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5l dDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD7B9GLKXM0002VGREEN_-- From nobody Mon Apr 18 02:08: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 344C312E0E4 for ; Mon, 18 Apr 2016 02:08:27 -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 YeVw1XZ8_UDY for ; Mon, 18 Apr 2016 02:08:25 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [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 7002512E0E5 for ; Mon, 18 Apr 2016 02:08:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,501,1454976000"; d="scan'208";a="61681502" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 18 Apr 2016 10:07:44 +0100 X-IronPort-AV: E=Sophos;i="5.24,501,1454976000"; d="scan'208";a="114365996" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 18 Apr 2016 10:07:44 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 10:07:44 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: RFC 5444 usage - one specific point. Thread-Index: AdGZUYEwrOFrZPQQR8i4HCwA3Y0EVA== Date: Mon, 18 Apr 2016 09:07:43 +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: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [manet] RFC 5444 usage - one specific point. 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, 18 Apr 2016 09:08:27 -0000 So far I see one specific point for WG agreement - anything else is editori= al. (Editorial matters, but it's not changing rules, so I'm trying here to = address one specific rule issue.) Some comments have clearly overlooked thi= s, but whether to telegraph it further (e.g. mention in non-normative intro= duction) is back to editorial. The draft currently says: =A0=A0 o=A0 The multiplexer MAY delay messages briefly in order to assemble =A0=A0=A0=A0=A0 more efficient packets.=A0 It SHOULD respect any constraint= s on such =A0=A0=A0=A0=A0 delays requested by the protocol. Should we change that SHOULD to a MUST? Obviously IETF-style we don't run v= otes as such, but what are people's opinions? As I see it: Argument for MUST: If the protocol has strong requirements the multiplexer = needs to respect those. Argument for SHOULD: But the protocol might make an impossible demand, such= as zero delay when we all know nothing has zero delay. SHOULD isn't MAY, i= t needs to do its best. Possible third course, something like (open to wordsmithing - I considered = putting the caveat at the end, for example). o The multiplexer MAY delay messages briefly in order to assemble more efficient packets. It MUST, as far as possible, respect any constraints on such delays requested by the protocol. Argument against third course, we've seen before that anything that include= s wording like that is open to IESG not being happy. On balance, I think SHOULD is appropriate, assuming SHOULD is interpreted a= s it should be - do this unless there really is a good reason not to. But I= could live with any of the three (if allowed). (If there aren't any strong views, I think we will stick with what's there.) We can see what the rough consensus over WGLC is on this one. -- = 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 ******************************************************************** 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 Mon Apr 18 02:19:31 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 05DE012D120 for ; Mon, 18 Apr 2016 02:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 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, 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 dtPAoTHbSFXH for ; Mon, 18 Apr 2016 02:19:26 -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 6F02A12B055 for ; Mon, 18 Apr 2016 02:19:25 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,501,1454976000"; d="scan'208,217"; a="33725374" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 18 Apr 2016 10:19:22 +0100 X-IronPort-AV: E=Sophos;i="5.24,501,1454976000"; d="scan'208,217";a="114368630" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 18 Apr 2016 10:19:22 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 10:19:22 +0100 From: "Dearlove, Christopher (UK)" To: Charlie Perkins , "Mobile Ad Hoc Networks mailing list" Thread-Topic: [manet] draft-ietf-manet-rfc5444-usage-03 Thread-Index: AQHRleCay/2tOcZafEiNXhaBb3Hay5+JJpawgAYMkwCAAEUZ0A== Date: Mon, 18 Apr 2016 09:19:21 +0000 Message-ID: References: <570EDD6A.8070605@earthlink.net> <57147860.5020805@earthlink.net> In-Reply-To: <57147860.5020805@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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD7FAGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] draft-ietf-manet-rfc5444-usage-03 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, 18 Apr 2016 09:19:29 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD7FAGLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 V2l0aCByZWdhcmQgdG8gTVRVLCBhcyBJIHNhaWQgSSBkb27igJl0IHJlY2FsbCBhbnkgc3VjaCBj b21tZW50LiBBIHZhZ3VlIHNvbWVvbmUgYXNrZWQgZG9lc27igJl0IGFkdmFuY2UgdXMuIEl0IGlz IG9mIGNvdXJzZSBwb3NzaWJsZSB0byBBT0RWdjIgdG8gdHJ5IHRvIGFidXNlIE1UVSwgYnV0IHNp bXBseSBrbm93aW5nIGl0IGlzbuKAmXQgYW4gYWJ1c2UuDQoNClJlYWxpc3RpY2FsbHksIHdoYXTi gJlzIEFPRFZ2MuKAmXMgaW50ZXJhY3Rpb24gd2l0aCBNVFUsIGdpdmVuIHRoZSBtdWx0aXBsZXhl cj8gRG9u4oCZdCBwcm9kdWNlIG1lc3NhZ2VzIHRoYXQsIHRvZ2V0aGVyIHdpdGggYWxsIHRoZSBv dGhlciBoZWFkZXJzIGV4cGVjdGVkIChJUCwgVURQLCA1NDQ0KSB3aWxsIGV4Y2VlZCBNVFUuIElz IHRoZXJlIGEgcG9zc2libGUgTVRVIC0gZXZlbiBvbmVzIEnigJl2ZSBjb21lIGFjcm9zcyBhcyBs b3cgYXMgNjAwIGJ5dGVzIC0gYW5kIGEgcG9zc2libGUgQU9EVnYyIG1lc3NhZ2UgdGhhdCBpcyBl dmVuIGNsb3NlIHRvIHRoYXQ/IChUaGUgbXVsdGlwbGV4ZXIgdGhlbiBoYXMgaXRzIG93biBpc3N1 ZXMgaW4gZGVjaWRpbmcgaG93IHRvIGdyb3VwIG1lc3NhZ2VzIGluIHBhY2tldHMuIEJ1dCB0aGF0 4oCZcyBpdHMgcHJvYmxlbS4gQW5kIG5vdCBoYXJkLiBZZXMsIEFPRFZ2MiBjb3VsZCBhbHNvIHJl cXVlc3QgY2VydGFpbiBtZXNzYWdlcyBiZSBrZXB0IHRvZ2V0aGVyIC0gZXhjZXB0IEkgZG9u4oCZ dCB0aGluayBpdCBkb2VzIC0gYnV0IHRoZSBtdWx0aXBsZXhlciBjb3VsZCBpZ25vcmUgdGhhdCBp ZiBpdCBoYXMgdG8uKQ0KDQpBcyBmb3IgdGhlIGlkZWEgdGhhdCBBT0RWdjIgaXMgY2xvc2VyIHRv IGJlaW5nIGZpbmlzaGVkIHRoYXQgdGhpcyBkcmFmdCwgdGhhdOKAmXMganVzdCBub3QgcmVtb3Rl bHkgcGxhdXNpYmxlLiBXZeKAmXJlIGluIExDIGhlcmUuIFdlIGRvbuKAmXQgaGF2ZSBhbiBBT0RW djIgZHJhZnQgdGhhdCBtYWtlIExDIGV2ZW4gYSBxdWVzdGlvbi4gQW5kIHRoZSBjb250aW51aW5n IHByYWN0aWNlIG9mIHRoZSBhdXRob3JzIGRpc2N1c3NpbmcgYWxtb3N0IGV2ZXJ5dGhpbmcgb2Zm IGxpc3QgdGhlbiBqdXN0IOKAnGhlcmXigJlzIGEgbmV3IGRyYWZ04oCdIHdpdGggdmVyeSBmZXcg Y29tbWVudHMgbWFrZXMgcHJvcGVyIGhhbmRsaW5nIG9mIHRoZSBkb2N1bWVudCBieSB0aGUgV0cg cmVhbGx5IGhhcmQsIG9yIHdvcnNlLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlv ciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExh Ym9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAg fCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3Zl QGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hl bG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXgg Q00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29t L2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJl ZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3Vy cmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IENo YXJsaWUgUGVya2lucyBbbWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0XQ0KU2Vu dDogMTggQXByaWwgMjAxNiAwNzowMg0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBN b2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdA0KU3ViamVjdDogUmU6IFttYW5ldF0g ZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzDQoNCg0KKioqIFdBUk5JTkcgKioqDQpU aGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0 aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBj YXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkg YXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFn cyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sg aGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0 eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhl IGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9p bnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMv RG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KSGVs bG8gQ2hyaXMsDQoNCkkgY2FuJ3QgZnVsbHkgcmVzcG9uZCByaWdodCBub3cgYnV0IGEgZmV3IHBv aW50czoNCk9uIDQvMTQvMjAxNiAyOjA5IEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSB3 cm90ZToNCg0KDQogICogICBJdCBpcyBpbXByb3BlciBmb3IgYWRoZXJlbmNlIHRvIG9uZSBzaW1w bGUgcGFyc2VyIGRlc2lnbiB0byBjb25zdHJhaW4gcHJvdG9jb2wgZGVzaWduIGZvciBzdWNoIGEg d2lkZSBjbGFzcyBvZiByb3V0aW5nIHByb2JsZW1zIGFzIGFyZSByZXByZXNlbnRlZCBieSBhZCBo b2MgbmV0d29ya3MuDQpTb3JyeSwgeW91IGFyZSB3ZWxsIG91dCBvZiBsaW5lIHRoZXJlLiBUaGlz IHdhcyBhIFdHIGRlY2lzaW9uLCBzcGVjaWZpZWQgaW4gUkZDIDU0OTguIEEgZG9jdW1lbnQgd3Jp dHRlbiBieSB5b3VyIHRoZW4gRFlNTyBjby1hdXRob3IgSWFuIENoYWtlcmVzIChhbHNvIFdHIGNo YWlyKSBhbmQgYWdyZWVkIGJ5IHRoZSBXRy4gSXQgd2FzbuKAmXQgZm9pc3RlZCBvbiB5b3UgYnkg dGhlIGF1dGhvcnMgLSBxdWl0ZSB0aGUgcmV2ZXJzZSwgd2UgaGFkIG1ha2luZyBpdCB3b3JrIGFz IGEgZ2VuZXJpYyBzcGVjaWZpY2F0aW9uIHB1dCBvbnRvIHVzLg0KDQpJYW4gaGFzIHRvbGQgbWUg bW9yZSB0aGFuIG9uY2UgdGhhdCBoZSBpcyAqdmVyeSB2ZXJ5KiBzdXJwcmlzZWQgYXQgc29tZSBv ZiB0aGUgcmVzdHJpY3Rpb25zIHRoYXQgaGF2ZSBiZWVuIGxlZ2lzbGF0ZWQgYXMgYSByZXN1bHQg b2YgUkZDIDU0OTguICBTcGVha2luZyBmb3IgbXlzZWxmLCB3aGVuIHRoYXQgd2FzIGhhcHBlbmlu ZyBJIHNvbWVob3cgaW1hZ2luZWQgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gaGF2ZSB0aGUg YWRkcmVzcyBhZ2dyZWdhdGlvbiBmYWNpbGl0aWVzLCBidXQgSSBkaWRuJ3QgcmVhbGl6ZSB0aGUg Y29zdHMuDQoNCk1heWJlIHdoZW4gdGhlIFdHIGFjY2VwdGVkIHRoaXMgZG9jdW1lbnQsIGl0IHdh cyBub3QgY2xlYXIgaG93IGNvc3RseSB0aGF0IGRlY2lzaW9uIHdvdWxkIGJlLg0KDQoNCg0KDQog ICogICBUaGUgZG9jdW1lbnQgcmVxdWlyZXMgdGhlIHByb3RvY29sIHRvIGtub3cgYWJvdXQgTVRV IGJ1dCBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IGluaGliaXRzIHRoZSBwcm90b2NvbCBmcm9tIGtu b3dpbmcgYWJvdXQgTVRVLg0KRXZlbiBpZiBzb21lb25lIG9uIHRoZSBsaXN0IHNhaWQgdGhhdCB0 aGUgcHJvdG9jb2wgaXMgaW5oaWJpdGVkIGZyb20ga25vd2luZyBhYm91dCBNVFUsIHRoYXTigJlz IG5vdCByZWxldmFudC4gRG9lcyB0aGlzIGRvY3VtZW50IHNheSB0aGF0PyBOby4gQnV0IEkgYWxz byBkb27igJl0IHJlY2FsbCBhbnlvbmUgc2F5aW5nIHRoYXQuIEFueSBwcm90b2NvbCAob3IgZXZl biBtYW55IGFwcGxpY2F0aW9ucykgdGhhdCBydW4gZGlyZWN0bHkgb3IgaW5kaXJlY3RseSBvdmVy IElQIG5lZWQgdG8gaGF2ZSBzb21lIGlkZWEgYWJvdXQgTVRVLCBwb3NzaWJseSB3aXRoIHJ1bGVz IG9mIHRodW1iIGFzIHRvIGhvdyBtdWNoIHRvIHN1YnRyYWN0IGR1ZSB0byBleHBlY3RlZCBoZWFk ZXJzLiBUaGlzIGlzIG5vIGRpZmZlcmVudC4NCg0KU29tZWJvZHkgYXNrZWQgdG8gcmVtb3ZlIGFs bCBtZW50aW9uIG9mIE1UVSBmcm9tIEFPRFZ2Mi4gIEkgYXJndWVkIHRoYXQgd2UgaGFkIHRvIGhh dmUgaXQgYnV0IGxvc3QgdGhlIGFyZ3VtZW50Lg0KDQoNCg0KDQogICogICBUaGUgZG9jdW1lbnQg ZGlzYWxsb3dzIHRoZSBwcm90b2NvbCBmcm9tIHNwZWNpZnlpbmcgY3J1Y2lhbCBwYXJhbWV0ZXJz IHN1Y2ggYXMgdGltZSBhbGxvd2FibGUgZm9yICBhZ2dyZWdhdGlvbiBvZiBjb250cm9sIG1lc3Nh Z2VzLg0KVGhhdCBpcyBleGFjdGx5IGJhY2t3YXJkcy4gRnJvbSBTZWN0aW9uIDQuMg0KICAgbyAg VGhlIG11bHRpcGxleGVyIE1BWSBkZWxheSBtZXNzYWdlcyBicmllZmx5IGluIG9yZGVyIHRvIGFz c2VtYmxlDQogICAgICBtb3JlIGVmZmljaWVudCBwYWNrZXRzLiAgSXQgU0hPVUxEIHJlc3BlY3Qg YW55IGNvbnN0cmFpbnRzIG9uIHN1Y2gNCiAgICAgIGRlbGF5cyByZXF1ZXN0ZWQgYnkgdGhlIHBy b3RvY29sLg0KSWYgeW91IHdhbnQgdG8gYXJndWUgdGhhdCB0aGUgU0hPVUxEIG91Z2h0IHRvIGJl IGEgTVVTVCB0aGVuIGZpbmUsIEnigJlkIGhhdmUgc29tZSBzeW1wYXRoeSB3aXRoIHRoYXQsIGJ1 dCB3ZSB3ZXJlIHRyeWluZyBub3QgdG8gb3Zlcmx5IGNvbnN0cmFpbi4gQnV0IHRoYXQgdGhlIHBy b3RvY29sIGNhbiBpbmZvcm0gdGhlIG11bHRpcGxleGVyIGlzIGNsZWFybHkgdGhlcmUuDQoNCklm IHRoZSBwcm90b2NvbCBzYXlzIHNvbWV0aGluZyBhYm91dCBkZWxheSwgdGhhdCBNVVNUIGJlIHJl c3BlY3RlZC4NCg0KUmVnYXJkaW5nICJleGFjdGx5IGJhY2t3YXJkcyIgLS0gSSB3aXNoIEkgY291 bGQgY291bnQgaG93IG1hbnkgU0hPVUxEcyBoYXZlIGJlZW4gY29udmVydGVkIHRvICJNVVNUcyIg YmFzZWQgb24gdGhlIHRoZW9yeSB0aGF0IGltcGxlbWVudGVycyBkb24ndCBnaXZlIGEgZGFybiBh Ym91dCBTSE9VTERzLiAgQmVsaWV2ZSBtZSwgSSBkbyBrbm93IHRoZSBSRkMgMjExOSBkZWZpbml0 aW9ucywgYnV0IEkgbG9zZSBldmVyeSBzdWNoIGFyZ3VtZW50Lg0KDQpIb3dldmVyLCBldmVuIGlm IGltcGxlbWVudGVycyByZWFsbHkgcmVhbGx5IGRpZCByZXNwZWN0IHRoZSBtZWFuaW5nIG9mIFNI T1VMRCwgaW4gdGhpcyBjYXNlIGl0IHdvdWxkIHN0aWxsIGhhdmUgdG8gYmUgTVVTVC4NCg0KDQoN Cg0KICAqICAgQWRkcmVzc2VzIGFyZSBwcmVzdW1lZCB0byBiZSBpbmNsdWRlZCBpbiBhIG1lc3Nh Z2UgZm9yIG5vIHBhcnRpY3VsYXIgcmVhc29uIHVubGVzcyBkZXNjcmliZWQgYnkgeWV0IGFub3Ro ZXIgYWRkcmVzcyBUTFYuICBUaGlzIGluY3JlYXNlcyBtZXNzYWdlIHNpemUgb24gdGhlIHNwZWN1 bGF0aW9uIHRoYXQgdGhlIHByb3RvY29sIHdpbGwgd2FudCB0byBiZSB1c2VkIHdpdGggb3RoZXIg dW5yZWxhdGVkIHByb3RvY29scyBpbiB0aGUgZnV0dXJlLiAgSW4gbm9ybWFsIHByb3RvY29sIGRl c2lnbiwgYWRkcmVzc2VzIGFyZSBwdXQgaW50byBhIG1lc3NhZ2UgZm9yIHJlYXNvbnMgdGhhdCBh cmUgc3BlY2lmaWMgdG8gdGhlIG1lc3NhZ2UuDQpZZXMsIHRoaXMgaXMgYSBkZXNpZ24gZmVhdHVy ZSB0aGF0IGlzIGhpZ2hseSBkZXNpcmFibGUgZm9yIGV4dGVuc2liaWxpdHkuIFRoYXTigJlzIHRo ZSBleHBlcmllbmNlIG9mIGEgbG90IG9mIHRpbWUgd29ya2luZyB3aXRoIGEgcHJvdG9jb2wgKE9M U1IpIHdpdGhvdXQgdGhhdCwgYW5kIHRoaXMuIEkgY2FuIGFscmVhZHkgc2VlIGhvdyBwb3NzaWJs ZSBleHRlbnNpb25zIHRvIEFPRFZ2MiBjb3VsZCB1c2UgdGhpcyBmcmVlZG9tLiBXaGlsZSBieXRl cyBkbyBtYXR0ZXIsIHNvIGRvZXMgZXh0ZW5zaWJpbGl0eS4NCkZyYW5rbHksIHdoYXQgcHJvdG9j b2xzIG5lZWQgaXMgdG8gZ28gaW4gb25lIGRpcmVjdGlvbiBvciB0aGUgb3RoZXIuIE9uZSBkaXJl Y3Rpb24gaXMgYSB0aWdodGx5IG9wdGltaXNlZCB1bHRyYS1jb21wYWN0IG1lc3NhZ2UgZm9yIHZl cnkgc3BlY2lmaWMgdXNlLCBpbiBwYXJ0aWN1bGFyIGZvciBzeXN0ZW1zIGJhc2VkIG9uIG1pY3Jv Y29udHJvbGxlcnMgYW5kIHZlcnkgY29uc3RyYWluZWQgd2lyZWxlc3MgbGlua3MuIEl04oCZcyBx dWl0ZSBvcGVuIHRvIHlvdSB0byBjcmVhdGUgYSBzZXBhcmF0ZSBtZXNzYWdlIHN0cnVjdHVyZSBm b3IgdGhhdC4gWW914oCZcmUgYWxyZWFkeSBwYXJ0IHdheSB0aGVyZSB3aXRoIGZpcnN0IHNwZWNp Znlpbmcgd2hhdOKAmXMgaW4gYSBtZXNzYWdlLCB0aGVuIGhvdyB0aGF04oCZcyByZXByZXNlbnRl ZCBpbiBSRkMgNTQ0NC4gSW4gYW4gaWRlYWwgd29ybGQgd2XigJlkIGhhdmUgZG9uZSB0aGUgc2Ft ZSBmb3IgT0xTUnYyLiBUaGUgb3RoZXIgZGlyZWN0aW9uLCB3aGlsZSBub3Qgb2JsaXZpb3VzIHRv IGVmZmljaWVuY3kgY29uY2VybnMsIGlzIHByZXBhcmVkIHRvIGFkZCBhIGZldyBvY3RldHMgKGFu ZCB3ZSBhcmUgdGFsa2luZyBhIGxvdyBzaW5nbGUgZmlndXJlIG51bWJlcikgdG8gYWxsb3cgZXh0 ZW5zaWJpbGl0eS4gRXZlbiB0aGUgYXV0aG9ycyBtaXNzZWQgc29tZSBleHRlbnNpYmlsaXR5IG9w dGlvbnMgYmFjayBpbiBlYXJsaWVyIGRheXMsIHdob2V2ZXIgaXQgd2FzIHRoYXQgaW5zaXN0ZWQg b24gYSBwZXItbWVzc2FnZSBhZGRyZXNzIGxlbmd0aCwgcmF0aGVyIHRoYW4gaW5oZXJpdGluZyBm cm9tIHdoYXRldmVyIElQIHN0YWNrIHlvdSB3ZXJlIHJ1bm5pbmcgb24sIHdhcyByaWdodC4NCkFu IGFwcGVuZGl4IChvciBwcm9iYWJseSBpbiBsaWdodCBvZiB0aW1lc2NhbGVzKSBzZXBhcmF0ZSBk cmFmdCBvbiBhbiB1bHRyYS1jb21wYWN0IHJlcHJlc2VudGF0aW9uIG9mIEFPRFZ2MiwgZXhwbGlj aXRseSBub3QgaW50ZW5kZWQgdG8gYmUgZXh0ZW5zaWJsZSwgd291bGQgYmUgaW50ZXJlc3Rpbmcs IGFuZCBtaWdodCBmaW5kIHNvbWUgYXBwbGljYXRpb24uDQoNCkhlYWRpbmcgZG93biB0aGF0IHBh dGggd2UncmUgZ29pbmcgdG8gaGF2ZSB0byBzcGVjaWZ5IGV2ZXJ5IHByb3RvY29sIHR3aWNlLiAg SSB0aG91Z2h0IGl0IHdvdWxkIGJlIGJldHRlciB0byBhdm9pZCBoYXZpbmcgdGhlIGV4dHJhIGJ5 dGVzIGluIHRoZSBmaXJzdCBwbGFjZS4gIEJlc2lkZXMgdGhhdCB0aGVyZSBhcmUgc2ltcGxlIHdh eXMgdG8gZW5hYmxlIGJvdGggZWNvbm9taWNhbCBzaXplIGFuZCBleHRlbnNpYmlsaXR5LiAgQnV0 IG9uZSBzZW50ZW5jZSByaW5ncyBpbiBteSBtaW5kIGNvbnRhaW5pbmcgdGhlIHdvcmRzICJIZWxs IE5vIi4NCg0KSSdtIG5vdCBjbGVhciBvbiB0aGF0IHBhcnQgYWJvdXQgcmVzdHJpY3RpbmcgdG8g YSBwZXItbWVzc2FnZSBhZGRyZXNzIGxlbmd0aCwgYnV0IGl0J3Mgbm90IGEgYmlnIGRlYWwgZm9y IG1vc3QgcHJvdG9jb2xzIGFuZCBub3QgZm9yIEFPRFZ2Miwgc28gd2UgY291bGQgdGFsayBhYm91 dCB0aGF0IGxhdGVyIGlmIGV2ZXIuDQoNCg0KDQpUaGUgbXVsdGlwbGV4ZXIgaXMgaW4gcGxhY2Us IHRoYXTigJlzIFJGQyA1NDk4LiBUaGlzIGlzbuKAmXQgbmV3LiBUaGUgaG9yc2UgaXMgYWxyZWFk eSBpbiBmcm9udCBvZiB0aGUgY2FydC4NCg0KV2VsbCwgaXQgZG9lcyBub3QgaGF2ZSB0byBiZS4N Cg0KDQoNCj4gSSB3aWxsIHRyeSB0byBmaW5pc2ggcmVhZGluZyB0aGUgZHJhZnQgc29vbiwgYnV0 IEkgdGhpbmsgdGhhdCBMYXN0IENhbGwgZm9yIHRoaXMgZG9jdW1lbnQgaXMgcHJlbWF0dXJlIGF0 IGJlc3QuICBJIHdvdWxkIHN0cm9uZ2x5IHN1Z2dlc3QgdGhhdCBpdCBiZSBkZWxheWVkIHVudGls IHRoZSBjdXJyZW50IHR3byBtYWpvciBbbWFuZXRdIGl0ZW1zIGNhbiBiZSBmaW5pc2hlZC4NClRo YXTigJlzIGNvbXBsZXRlbHkgdW5hY2NlcHRhYmxlLiBXaG8ga25vd3MgaG93IGxvbmcgeW91IGFy ZSBnb2luZyB0byBjb250aW51ZSB0byB3b3JrIG9uIEFPRFZ2MiBvdXQgb2Ygc2lnaHQgb2YgdGhp cyBXRy4gQW5kIHRoaXMgcmVhbGx5IGlzIHRoZSBjYXJ0IGJlZm9yZSB0aGUgaG9yc2UuIFlvdXIg Y28tYXV0aG9ycyBvZiBBT0RWdjIgcmVxdWVzdGVkIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbiBvZiBS RkMgNTQ0NCwgYW5kIHdlIHB1dCBpbiB0aGUgd29yayB0byBkbyB0aGF0LiBDbGFyaWZ5aW5nIHRo ZSBiYXNlIGJlZm9yZSBidWlsZGluZyBvbiBpdCBpcyB0aGUgcmlnaHQgb3JkZXIuDQoNCldlJ3Jl IHRyeWluZyB0byByZXNvbHZlIHRoZSB2ZXJ5IGZldyByZW1haW5pbmcgY29tbWVudHMuICBJIHdv dWxkIHRoaW5rIHRoYXQgc29tZXRoaW5nIGFzIGZhciByZWFjaGluZyBhcyB0aGlzIHVzYWdlIGRv Y3VtZW50IGNvdWxkIHRha2UgYSBnb29kIHdoaWxlLiAgSSdkIGhhdGUgdG8gaGF2ZSB0aGF0IGZy b250IG9mIGZpbmlzaGluZyBBT0RWdjIuDQoNCg0KQWxzbywgd2h5IHR3byBXRyBkb2N1bWVudHM/ IFRoZSBvbmx5IG90aGVyIHNpZ25pZmljYW50IGRvY3VtZW50IGlzIERMRVAsIHdoaWNoIGlzIGJv dGggaW5kZXBlbmRlbnQgb2YgdGhpcyAoaXQgZG9lc27igJl0IHVzZSA1NDQ0IC0gYW5kIHRoYXTi gJlzIGJlY2F1c2UgaXTigJlzIG5vdCBhIE1BTkVUIHJvdXRpbmcgcHJvdG9jb2wpIGFuZCBhbHJl YWR5IG91dCBvZiB0aGUgZ2F0ZS4NCg0KDQpPLksuIEkgdGhvdWdodCBpdCB3YXMgc3RpbGwgdW5k ZXIgZGlzY3Vzc2lvbi4uLg0KDQpSZWdhcmRzLA0KQ2hhcmxpZSBQLg0KKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKVGhp cyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVu ZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0g YW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBm b3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRv IGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD7FAGLKXM0002VGREEN_ 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 emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5 NzM0ODY0NTk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDczNzE4OTI2O30NCkBsaXN0IGww OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMzE1NDQ4 OTI1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjAyOTYyNTU0Njt9DQpAbGlzdCBsMTpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTQzMTEyMjY3NjsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTY1MzIxMzA4NDt9DQpAbGlzdCBsMjpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIx Ni4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTQ4MTExNTEwNjsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTEyNzgzMDYzNDg7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206 MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1HQiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPldpdGggcmVnYXJkIHRvIE1UVSwgYXMgSSBzYWlkIEkgZG9u4oCZdCByZWNhbGwgYW55IHN1 Y2ggY29tbWVudC4gQSB2YWd1ZSBzb21lb25lIGFza2VkIGRvZXNu4oCZdCBhZHZhbmNlIHVzLiBJ dCBpcyBvZiBjb3Vyc2UgcG9zc2libGUgdG8gQU9EVnYyIHRvIHRyeSB0byBhYnVzZQ0KIE1UVSwg YnV0IHNpbXBseSBrbm93aW5nIGl0IGlzbuKAmXQgYW4gYWJ1c2UuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWFsaXN0 aWNhbGx5LCB3aGF04oCZcyBBT0RWdjLigJlzIGludGVyYWN0aW9uIHdpdGggTVRVLCBnaXZlbiB0 aGUgbXVsdGlwbGV4ZXI/IERvbuKAmXQgcHJvZHVjZSBtZXNzYWdlcyB0aGF0LCB0b2dldGhlciB3 aXRoIGFsbCB0aGUgb3RoZXIgaGVhZGVycyBleHBlY3RlZCAoSVAsIFVEUCwNCiA1NDQ0KSB3aWxs IGV4Y2VlZCBNVFUuIElzIHRoZXJlIGEgcG9zc2libGUgTVRVIC0gZXZlbiBvbmVzIEnigJl2ZSBj b21lIGFjcm9zcyBhcyBsb3cgYXMgNjAwIGJ5dGVzIC0gYW5kIGEgcG9zc2libGUgQU9EVnYyIG1l c3NhZ2UgdGhhdCBpcyBldmVuIGNsb3NlIHRvIHRoYXQ/IChUaGUgbXVsdGlwbGV4ZXIgdGhlbiBo YXMgaXRzIG93biBpc3N1ZXMgaW4gZGVjaWRpbmcgaG93IHRvIGdyb3VwIG1lc3NhZ2VzIGluIHBh Y2tldHMuIEJ1dCB0aGF04oCZcyBpdHMNCiBwcm9ibGVtLiBBbmQgbm90IGhhcmQuIFllcywgQU9E VnYyIGNvdWxkIGFsc28gcmVxdWVzdCBjZXJ0YWluIG1lc3NhZ2VzIGJlIGtlcHQgdG9nZXRoZXIg LSBleGNlcHQgSSBkb27igJl0IHRoaW5rIGl0IGRvZXMgLSBidXQgdGhlIG11bHRpcGxleGVyIGNv dWxkIGlnbm9yZSB0aGF0IGlmIGl0IGhhcyB0by4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBmb3IgdGhlIGlkZWEg dGhhdCBBT0RWdjIgaXMgY2xvc2VyIHRvIGJlaW5nIGZpbmlzaGVkIHRoYXQgdGhpcyBkcmFmdCwg dGhhdOKAmXMganVzdCBub3QgcmVtb3RlbHkgcGxhdXNpYmxlLiBXZeKAmXJlIGluIExDIGhlcmUu IFdlIGRvbuKAmXQgaGF2ZSBhbiBBT0RWdjIgZHJhZnQNCiB0aGF0IG1ha2UgTEMgZXZlbiBhIHF1 ZXN0aW9uLiBBbmQgdGhlIGNvbnRpbnVpbmcgcHJhY3RpY2Ugb2YgdGhlIGF1dGhvcnMgZGlzY3Vz c2luZyBhbG1vc3QgZXZlcnl0aGluZyBvZmYgbGlzdCB0aGVuIGp1c3Qg4oCcaGVyZeKAmXMgYSBu ZXcgZHJhZnTigJ0gd2l0aCB2ZXJ5IGZldyBjb21tZW50cyBtYWtlcyBwcm9wZXIgaGFuZGxpbmcg b2YgdGhlIGRvY3VtZW50IGJ5IHRoZSBXRyByZWFsbHkgaGFyZCwgb3Igd29yc2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9vOnA+PC9z cGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0 b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3 RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdE Ij5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAm bmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wgJm5ic3A7PGI+RToNCjwvYj48YSBo cmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3Zl QGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBU ZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48 YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHlsZT0i Y29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRl ZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdp c3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBH VTIgN1lQPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBDaGFybGllIFBlcmtpbnMgW21h aWx0bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiAx OCBBcHJpbCAyMDE2IDA3OjAyPGJyPg0KPGI+VG86PC9iPiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIg KFVLKTsgTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3Q8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFttYW5ldF0gZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0 O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tn cm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+ KioqIFdBUk5JTkcgKioqPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVz IGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBw YXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1 bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFj aG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9y bWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0 cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5 b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJl Zj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkv c3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48 L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVt PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZv bGxvdw0KPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdv cmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNp b3VzJTIwRW1haWxzLnBkZiI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48 L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5IZWxsbyBDaHJpcyw8YnI+DQo8YnI+DQpJIGNhbid0IGZ1bGx5 IHJlc3BvbmQgcmlnaHQgbm93IGJ1dCBhIGZldyBwb2ludHM6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNC8xNC8yMDE2IDI6MDkgQU0sIERlYXJsb3ZlLCBD aHJpc3RvcGhlciAoVUspIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSXQg aXMgaW1wcm9wZXIgZm9yIGFkaGVyZW5jZSB0byBvbmUgc2ltcGxlIHBhcnNlciBkZXNpZ24gdG8g Y29uc3RyYWluIHByb3RvY29sIGRlc2lnbiBmb3Igc3VjaCBhIHdpZGUgY2xhc3Mgb2Ygcm91dGlu ZyBwcm9ibGVtcyBhcyBhcmUgcmVwcmVzZW50ZWQgYnkgYWQgaG9jIG5ldHdvcmtzLjxvOnA+PC9v OnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Tb3JyeSwgeW91IGFyZSB3ZWxs IG91dCBvZiBsaW5lIHRoZXJlLiBUaGlzIHdhcyBhIFdHIGRlY2lzaW9uLCBzcGVjaWZpZWQgaW4g UkZDIDU0OTguIEEgZG9jdW1lbnQgd3JpdHRlbiBieSB5b3VyIHRoZW4gRFlNTyBjby1hdXRob3Ig SWFuIENoYWtlcmVzIChhbHNvIFdHIGNoYWlyKSBhbmQgYWdyZWVkIGJ5IHRoZQ0KIFdHLiBJdCB3 YXNu4oCZdCBmb2lzdGVkIG9uIHlvdSBieSB0aGUgYXV0aG9ycyAtIHF1aXRlIHRoZSByZXZlcnNl LCB3ZSBoYWQgbWFraW5nIGl0IHdvcmsgYXMgYSBnZW5lcmljIHNwZWNpZmljYXRpb24gcHV0IG9u dG8gdXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCklhbiBoYXMgdG9sZCBtZSBtb3JlIHRoYW4gb25jZSB0aGF0IGhlIGlz ICp2ZXJ5IHZlcnkqIHN1cnByaXNlZCBhdCBzb21lIG9mIHRoZSByZXN0cmljdGlvbnMgdGhhdCBo YXZlIGJlZW4gbGVnaXNsYXRlZCBhcyBhIHJlc3VsdCBvZiBSRkMgNTQ5OC4mbmJzcDsgU3BlYWtp bmcgZm9yIG15c2VsZiwgd2hlbiB0aGF0IHdhcyBoYXBwZW5pbmcgSSBzb21laG93IGltYWdpbmVk IHRoYXQgaXQgd291bGQgYmUgYmV0dGVyIHRvIGhhdmUgdGhlIGFkZHJlc3MgYWdncmVnYXRpb24N CiBmYWNpbGl0aWVzLCBidXQgSSBkaWRuJ3QgcmVhbGl6ZSB0aGUgY29zdHMuPGJyPg0KPGJyPg0K TWF5YmUgd2hlbiB0aGUgV0cgYWNjZXB0ZWQgdGhpcyBkb2N1bWVudCwgaXQgd2FzIG5vdCBjbGVh ciBob3cgY29zdGx5IHRoYXQgZGVjaXNpb24gd291bGQgYmUuPGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwyIGxldmVsMSBsZm8yIj4NClRoZSBkb2N1bWVudCByZXF1aXJlcyB0aGUgcHJvdG9jb2wgdG8g a25vdyBhYm91dCBNVFUgYnV0IGRpc2N1c3Npb24gb24gdGhlIGxpc3QgaW5oaWJpdHMgdGhlIHBy b3RvY29sIGZyb20ga25vd2luZyBhYm91dCBNVFUuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkV2ZW4gaWYgc29tZW9uZSBvbiB0aGUgbGlzdCBzYWlkIHRoYXQg dGhlIHByb3RvY29sIGlzIGluaGliaXRlZCBmcm9tIGtub3dpbmcgYWJvdXQgTVRVLCB0aGF04oCZ cyBub3QgcmVsZXZhbnQuIERvZXMgdGhpcyBkb2N1bWVudCBzYXkgdGhhdD8gTm8uIEJ1dCBJIGFs c28gZG9u4oCZdCByZWNhbGwgYW55b25lIHNheWluZw0KIHRoYXQuIEFueSBwcm90b2NvbCAob3Ig ZXZlbiBtYW55IGFwcGxpY2F0aW9ucykgdGhhdCBydW4gZGlyZWN0bHkgb3IgaW5kaXJlY3RseSBv dmVyIElQIG5lZWQgdG8gaGF2ZSBzb21lIGlkZWEgYWJvdXQgTVRVLCBwb3NzaWJseSB3aXRoIHJ1 bGVzIG9mIHRodW1iIGFzIHRvIGhvdyBtdWNoIHRvIHN1YnRyYWN0IGR1ZSB0byBleHBlY3RlZCBo ZWFkZXJzLiBUaGlzIGlzIG5vIGRpZmZlcmVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KU29tZWJvZHkgYXNrZWQgdG8gcmVtb3ZlIGFsbCBtZW50 aW9uIG9mIE1UVSBmcm9tIEFPRFZ2Mi4mbmJzcDsgSSBhcmd1ZWQgdGhhdCB3ZSBoYWQgdG8gaGF2 ZSBpdCBidXQgbG9zdCB0aGUgYXJndW1lbnQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQpUaGUgZG9jdW1lbnQgZGlzYWxsb3dzIHRoZSBw cm90b2NvbCBmcm9tIHNwZWNpZnlpbmcgY3J1Y2lhbCBwYXJhbWV0ZXJzIHN1Y2ggYXMgdGltZSBh bGxvd2FibGUgZm9yJm5ic3A7IGFnZ3JlZ2F0aW9uIG9mIGNvbnRyb2wgbWVzc2FnZXMuPG86cD48 L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYXQgaXMgZXhhY3RseSBi YWNrd2FyZHMuIEZyb20gU2VjdGlvbiA0LjI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVGhlIG11bHRpcGxleGVyIE1BWSBkZWxheSBt ZXNzYWdlcyBicmllZmx5IGluIG9yZGVyIHRvIGFzc2VtYmxlPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtb3JlIGVm ZmljaWVudCBwYWNrZXRzLiZuYnNwOyBJdCBTSE9VTEQgcmVzcGVjdCBhbnkgY29uc3RyYWludHMg b24gc3VjaDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVsYXlzIHJlcXVlc3RlZCBieSB0aGUgcHJvdG9jb2wuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHlvdSB3YW50IHRvIGFyZ3Vl IHRoYXQgdGhlIFNIT1VMRCBvdWdodCB0byBiZSBhIE1VU1QgdGhlbiBmaW5lLCBJ4oCZZCBoYXZl IHNvbWUgc3ltcGF0aHkgd2l0aCB0aGF0LCBidXQgd2Ugd2VyZSB0cnlpbmcgbm90IHRvIG92ZXJs eSBjb25zdHJhaW4uIEJ1dCB0aGF0IHRoZSBwcm90b2NvbCBjYW4gaW5mb3JtDQogdGhlIG11bHRp cGxleGVyIGlzIGNsZWFybHkgdGhlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCklmIHRoZSBwcm90b2NvbCBzYXlzIHNvbWV0aGluZyBhYm91dCBk ZWxheSwgdGhhdCBNVVNUIGJlIHJlc3BlY3RlZC48YnI+DQo8YnI+DQpSZWdhcmRpbmcgJnF1b3Q7 ZXhhY3RseSBiYWNrd2FyZHMmcXVvdDsgLS0gSSB3aXNoIEkgY291bGQgY291bnQgaG93IG1hbnkg U0hPVUxEcyBoYXZlIGJlZW4gY29udmVydGVkIHRvICZxdW90O01VU1RzJnF1b3Q7IGJhc2VkIG9u IHRoZSB0aGVvcnkgdGhhdCBpbXBsZW1lbnRlcnMgZG9uJ3QgZ2l2ZSBhIGRhcm4gYWJvdXQgU0hP VUxEcy4mbmJzcDsgQmVsaWV2ZSBtZSwgSSBkbyBrbm93IHRoZSBSRkMgMjExOSBkZWZpbml0aW9u cywgYnV0IEkgbG9zZSBldmVyeSBzdWNoIGFyZ3VtZW50Ljxicj4NCjxicj4NCkhvd2V2ZXIsIGV2 ZW4gaWYgaW1wbGVtZW50ZXJzIHJlYWxseSByZWFsbHkgZGlkIHJlc3BlY3QgdGhlIG1lYW5pbmcg b2YgU0hPVUxELCBpbiB0aGlzIGNhc2UgaXQgd291bGQgc3RpbGwgaGF2ZSB0byBiZSBNVVNULjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjx1bCB0eXBlPSJk aXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzQiPg0K QWRkcmVzc2VzIGFyZSBwcmVzdW1lZCB0byBiZSBpbmNsdWRlZCBpbiBhIG1lc3NhZ2UgZm9yIG5v IHBhcnRpY3VsYXIgcmVhc29uIHVubGVzcyBkZXNjcmliZWQgYnkgeWV0IGFub3RoZXIgYWRkcmVz cyBUTFYuJm5ic3A7IFRoaXMgaW5jcmVhc2VzIG1lc3NhZ2Ugc2l6ZSBvbiB0aGUgc3BlY3VsYXRp b24gdGhhdCB0aGUgcHJvdG9jb2wgd2lsbCB3YW50IHRvIGJlIHVzZWQgd2l0aCBvdGhlciB1bnJl bGF0ZWQgcHJvdG9jb2xzIGluIHRoZSBmdXR1cmUuJm5ic3A7IEluDQogbm9ybWFsIHByb3RvY29s IGRlc2lnbiwgYWRkcmVzc2VzIGFyZSBwdXQgaW50byBhIG1lc3NhZ2UgZm9yIHJlYXNvbnMgdGhh dCBhcmUgc3BlY2lmaWMgdG8gdGhlIG1lc3NhZ2UuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlllcywgdGhpcyBpcyBhIGRlc2lnbiBmZWF0dXJlIHRoYXQgaXMg aGlnaGx5IGRlc2lyYWJsZSBmb3IgZXh0ZW5zaWJpbGl0eS4gVGhhdOKAmXMgdGhlIGV4cGVyaWVu Y2Ugb2YgYSBsb3Qgb2YgdGltZSB3b3JraW5nIHdpdGggYSBwcm90b2NvbCAoT0xTUikgd2l0aG91 dCB0aGF0LCBhbmQgdGhpcy4gSSBjYW4gYWxyZWFkeQ0KIHNlZSBob3cgcG9zc2libGUgZXh0ZW5z aW9ucyB0byBBT0RWdjIgY291bGQgdXNlIHRoaXMgZnJlZWRvbS4gV2hpbGUgYnl0ZXMgZG8gbWF0 dGVyLCBzbyBkb2VzIGV4dGVuc2liaWxpdHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkZyYW5rbHksIHdoYXQgcHJvdG9jb2xzIG5lZWQgaXMgdG8gZ28gaW4gb25lIGRp cmVjdGlvbiBvciB0aGUgb3RoZXIuIE9uZSBkaXJlY3Rpb24gaXMgYSB0aWdodGx5IG9wdGltaXNl ZCB1bHRyYS1jb21wYWN0IG1lc3NhZ2UgZm9yIHZlcnkgc3BlY2lmaWMgdXNlLCBpbiBwYXJ0aWN1 bGFyIGZvciBzeXN0ZW1zDQogYmFzZWQgb24gbWljcm9jb250cm9sbGVycyBhbmQgdmVyeSBjb25z dHJhaW5lZCB3aXJlbGVzcyBsaW5rcy4gSXTigJlzIHF1aXRlIG9wZW4gdG8geW91IHRvIGNyZWF0 ZSBhIHNlcGFyYXRlIG1lc3NhZ2Ugc3RydWN0dXJlIGZvciB0aGF0LiBZb3XigJlyZSBhbHJlYWR5 IHBhcnQgd2F5IHRoZXJlIHdpdGggZmlyc3Qgc3BlY2lmeWluZyB3aGF04oCZcyBpbiBhIG1lc3Nh Z2UsIHRoZW4gaG93IHRoYXTigJlzIHJlcHJlc2VudGVkIGluIFJGQyA1NDQ0LiBJbiBhbiBpZGVh bA0KIHdvcmxkIHdl4oCZZCBoYXZlIGRvbmUgdGhlIHNhbWUgZm9yIE9MU1J2Mi4gVGhlIG90aGVy IGRpcmVjdGlvbiwgd2hpbGUgbm90IG9ibGl2aW91cyB0byBlZmZpY2llbmN5IGNvbmNlcm5zLCBp cyBwcmVwYXJlZCB0byBhZGQgYSBmZXcgb2N0ZXRzIChhbmQgd2UgYXJlIHRhbGtpbmcgYSBsb3cg c2luZ2xlIGZpZ3VyZSBudW1iZXIpIHRvIGFsbG93IGV4dGVuc2liaWxpdHkuIEV2ZW4gdGhlIGF1 dGhvcnMgbWlzc2VkIHNvbWUgZXh0ZW5zaWJpbGl0eSBvcHRpb25zDQogYmFjayBpbiBlYXJsaWVy IGRheXMsIHdob2V2ZXIgaXQgd2FzIHRoYXQgaW5zaXN0ZWQgb24gYSBwZXItbWVzc2FnZSBhZGRy ZXNzIGxlbmd0aCwgcmF0aGVyIHRoYW4gaW5oZXJpdGluZyBmcm9tIHdoYXRldmVyIElQIHN0YWNr IHlvdSB3ZXJlIHJ1bm5pbmcgb24sIHdhcyByaWdodC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+QW4gYXBwZW5kaXggKG9yIHByb2JhYmx5IGluIGxpZ2h0IG9mIHRpbWVz Y2FsZXMpIHNlcGFyYXRlIGRyYWZ0IG9uIGFuIHVsdHJhLWNvbXBhY3QgcmVwcmVzZW50YXRpb24g b2YgQU9EVnYyLCBleHBsaWNpdGx5IG5vdCBpbnRlbmRlZCB0byBiZSBleHRlbnNpYmxlLCB3b3Vs ZCBiZSBpbnRlcmVzdGluZywgYW5kDQogbWlnaHQgZmluZCBzb21lIGFwcGxpY2F0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpIZWFkaW5nIGRv d24gdGhhdCBwYXRoIHdlJ3JlIGdvaW5nIHRvIGhhdmUgdG8gc3BlY2lmeSBldmVyeSBwcm90b2Nv bCB0d2ljZS4mbmJzcDsgSSB0aG91Z2h0IGl0IHdvdWxkIGJlIGJldHRlciB0byBhdm9pZCBoYXZp bmcgdGhlIGV4dHJhIGJ5dGVzIGluIHRoZSBmaXJzdCBwbGFjZS4mbmJzcDsgQmVzaWRlcyB0aGF0 IHRoZXJlIGFyZSBzaW1wbGUgd2F5cyB0byBlbmFibGUgYm90aCBlY29ub21pY2FsIHNpemUgYW5k IGV4dGVuc2liaWxpdHkuJm5ic3A7IEJ1dCBvbmUgc2VudGVuY2UNCiByaW5ncyBpbiBteSBtaW5k IGNvbnRhaW5pbmcgdGhlIHdvcmRzICZxdW90O0hlbGwgTm8mcXVvdDsuPGJyPg0KPGJyPg0KSSdt IG5vdCBjbGVhciBvbiB0aGF0IHBhcnQgYWJvdXQgcmVzdHJpY3RpbmcgdG8gYSBwZXItbWVzc2Fn ZSBhZGRyZXNzIGxlbmd0aCwgYnV0IGl0J3Mgbm90IGEgYmlnIGRlYWwgZm9yIG1vc3QgcHJvdG9j b2xzIGFuZCBub3QgZm9yIEFPRFZ2Miwgc28gd2UgY291bGQgdGFsayBhYm91dCB0aGF0IGxhdGVy IGlmIGV2ZXIuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhlIG11bHRpcGxleGVyIGlzIGluIHBsYWNlLCB0aGF04oCZcyBSRkMgNTQ5OC4gVGhp cyBpc27igJl0IG5ldy4gVGhlIGhvcnNlIGlzIGFscmVhZHkgaW4gZnJvbnQgb2YgdGhlIGNhcnQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCldlbGws IGl0IGRvZXMgbm90IGhhdmUgdG8gYmUuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQomZ3Q7IEkgd2lsbCB0cnkgdG8g ZmluaXNoIHJlYWRpbmcgdGhlIGRyYWZ0IHNvb24sIGJ1dCBJIHRoaW5rIHRoYXQgTGFzdCBDYWxs IGZvciB0aGlzIGRvY3VtZW50IGlzIHByZW1hdHVyZSBhdCBiZXN0LiZuYnNwOyBJIHdvdWxkIHN0 cm9uZ2x5IHN1Z2dlc3QgdGhhdCBpdCBiZSBkZWxheWVkIHVudGlsIHRoZSBjdXJyZW50IHR3byBt YWpvciBbbWFuZXRdIGl0ZW1zIGNhbiBiZSBmaW5pc2hlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VGhhdOKAmXMgY29tcGxldGVseSB1bmFjY2VwdGFibGUuIFdobyBr bm93cyBob3cgbG9uZyB5b3UgYXJlIGdvaW5nIHRvIGNvbnRpbnVlIHRvIHdvcmsgb24gQU9EVnYy IG91dCBvZiBzaWdodCBvZiB0aGlzIFdHLiBBbmQgdGhpcyByZWFsbHkgaXMgdGhlIGNhcnQgYmVm b3JlIHRoZSBob3JzZS4gWW91ciBjby1hdXRob3JzDQogb2YgQU9EVnYyIHJlcXVlc3RlZCBmdXJ0 aGVyIGNsYXJpZmljYXRpb24gb2YgUkZDIDU0NDQsIGFuZCB3ZSBwdXQgaW4gdGhlIHdvcmsgdG8g ZG8gdGhhdC4gQ2xhcmlmeWluZyB0aGUgYmFzZSBiZWZvcmUgYnVpbGRpbmcgb24gaXQgaXMgdGhl IHJpZ2h0IG9yZGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQpXZSdyZSB0cnlpbmcgdG8gcmVzb2x2ZSB0aGUgdmVyeSBmZXcgcmVtYWluaW5nIGNv bW1lbnRzLiZuYnNwOyBJIHdvdWxkIHRoaW5rIHRoYXQgc29tZXRoaW5nIGFzIGZhciByZWFjaGlu ZyBhcyB0aGlzIHVzYWdlIGRvY3VtZW50IGNvdWxkIHRha2UgYSBnb29kIHdoaWxlLiZuYnNwOyBJ J2QgaGF0ZSB0byBoYXZlIHRoYXQgZnJvbnQgb2YgZmluaXNoaW5nIEFPRFZ2Mi48YnI+DQo8YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFs c28sIHdoeSB0d28gV0cgZG9jdW1lbnRzPyBUaGUgb25seSBvdGhlciBzaWduaWZpY2FudCBkb2N1 bWVudCBpcyBETEVQLCB3aGljaCBpcyBib3RoIGluZGVwZW5kZW50IG9mIHRoaXMgKGl0IGRvZXNu 4oCZdCB1c2UgNTQ0NCAtIGFuZCB0aGF04oCZcyBiZWNhdXNlIGl04oCZcyBub3QgYSBNQU5FVCBy b3V0aW5nIHByb3RvY29sKQ0KIGFuZCBhbHJlYWR5IG91dCBvZiB0aGUgZ2F0ZS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KTy5LLiBJIHRob3VnaHQgaXQgd2FzIHN0aWxsIHVuZGVyIGRpc2N1c3Npb24uLi48YnI+DQo8 YnI+DQpSZWdhcmRzLDxicj4NCkNoYXJsaWUgUC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHA+ KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKio8YnI+ClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlk ZW50aWFsIHRvIHRoZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2 aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBwbGVhc2Ug ZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj4KWW91 IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9z ZSBvcjxicj4KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+ CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqPC9wPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD7FAGLKXM0002VGREEN_-- From nobody Mon Apr 18 02:21: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 6FCFD12DA36 for ; Mon, 18 Apr 2016 02:21:36 -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 lmX0fN8IZwwH for ; Mon, 18 Apr 2016 02:21:30 -0700 (PDT) Received: from mail-qg0-x242.google.com (mail-qg0-x242.google.com [IPv6:2607:f8b0:400d:c04::242]) (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 6732612D9AC for ; Mon, 18 Apr 2016 02:21:30 -0700 (PDT) Received: by mail-qg0-x242.google.com with SMTP id 7so16292067qgj.0 for ; Mon, 18 Apr 2016 02:21:30 -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=pctyTQaYqicpqMlk6JQNGW3Rt1qu/Qnzg8wLY+nyQfU=; b=twsVshpK6nMWUD5BiYhzPvJFCoBMjhJUm/MIqSt80ezZ6v2L1dAYlJuM/iQesu3ZT9 clX0y6wxIpW5FaUR5j37B5CVYUTgiPW5Xdwi/N+RfEHV2MhcFc63sqq4RXuWTuMxzFo1 WZV1LD51JLs/gPTXFOMne/iXD+HkYa0nBc88bineBqAymtsmK3EPiTi+1jbFKvno/gvk R6J8tdrVvjXfbIFwljbYmcltAqpmUYi/D62AMZrCrp26uXg/cea5GcS4EJPi1rRKtTz9 rxBiH12NdinF5+o8U8s8dhnVo4/BABaslie+IXr60sRESFj2ZlD3XSsfFdRdPzdHdpZx PlGw== 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=pctyTQaYqicpqMlk6JQNGW3Rt1qu/Qnzg8wLY+nyQfU=; b=gfsJUyLr4Rvi4jyxlAMOcx5YPEXcf3joVeWqRMAbPS5FiD/NXMWwgcJwh48OpEIR8Y UsAsaHOLkjnMjA+7wyjz8wpDYnWSW2JfIZ97vNcNAErprT8nCd/tAe21uVPpSPpWcWF+ V25rACr59noOAhFjxnlUdUXf/bFn0iQOG+vNHidI5G+utrrnD8RKOdGUVrhfJ64P2bR2 +syuL4NVZvLT+e/EisiQQEG9FXrsGcjI16FgXiFvIAk2b4D1jk9OsNtYQBPpKZBa4l8y D2uAuHF+IolV5cXSvamKlmkLmozffbVOM5BSSHzAe5Wx9sp7i/2a9LN9QK1qW1SBgWud Z4Vw== X-Gm-Message-State: AOPr4FUwmUAcRTyl7uQwkOEJT01Rj8V9nFgkw2sJ5sFXYpjgAoHaTuD67nx7emCTbgF6hFvflGIPV/6EwtnsGQ== MIME-Version: 1.0 X-Received: by 10.140.169.132 with SMTP id p126mr43248666qhp.71.1460971289446; Mon, 18 Apr 2016 02:21:29 -0700 (PDT) Received: by 10.140.43.131 with HTTP; Mon, 18 Apr 2016 02:21:29 -0700 (PDT) In-Reply-To: References: <45DFA343-1FDD-4EB9-9291-AB3A830A3CD9@mnemosyne.demon.co.uk> Date: Mon, 18 Apr 2016 11:21:29 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a113b31b2bc14f40530bee2dc Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" , Christopher Dearlove Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 18 Apr 2016 09:21:36 -0000 --001a113b31b2bc14f40530bee2dc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Chris, IMO the use of 5444 is for implementation purpose or information. So, I agree with Stan's comment, that this draft is important to progress, but would nice to add in the draft some examples of use cases of OLSRv2 and AODVv2 both routing-protocols, or examples of implementation. This will help the use of 5444 because I think these protocols use 5444 differently because they have different purposes/advantages. Thanks, AB On Mon, Apr 18, 2016 at 10:52 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > I don=E2=80=99t believe we can or should suggest an implementation. That= =E2=80=99s not > what the IETF does, and it would be a hard, probably impossible, sell, to > the IESG. That the obvious implementation employs an independent parser i= s > already said - it may be appropriate to strengthen the words, but this > second I=E2=80=99m not sure if that=E2=80=99s needed (not got time to che= ck current > wording). > > > > *-- * > > > > > *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 *Stan Ratliff > *Sent:* 16 April 2016 19:09 > *To:* Christopher Dearlove > *Cc:* manet@ietf.org; Christopher Dearlove > *Subject:* Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > > > > > **** 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 Fri, Apr 15, 2016 at 3:27 PM, Christopher Dearlove < > chris@mnemosyne.demon.co.uk> wrote: > > I don't understand what you mean by the concept of "fields the protocol > can and can't touch". > > > > CAVEAT: I am speaking here as a Working Group participant. With that > understood: > > > > > TTL is a great example, since that discussion blew the mailing list up a > few months ago. I'm *not* saying manipulating TTL is a good thing for a > protocol to try - in truth, I think it's pretty "hacky". But the notion w= as > floated, and in the context of that discussion, it may will have worked. > The opposition on-list was fast, and pretty forceful. > > I've said before - 5444, especially with the multiplexer, changes the > relationship between a routing protocol and an interface. I think the > document should have some type of "overview" section which discusses thes= e > differences, in order to frame the issue for someone coming along who > hasn't been a part of the 5444 mail discussion. > > I'm talking about the type of overview that goes something like this: > > "Use of RFC 5444 with the multiplexer feature imposes design requirements > on the protocol. The actual transport mechanism is abstracted from the > protocol. For example, routing protocols are not aware of precisely when = a > message is sent. A good example of operation in this model is [BGP], > utilizing the [TCP] transport. This is opposed to a protocol such as > [OSPF], which is capable of sending traffic with its own IP type. Since t= he > transport is abstracted, protocols are not presented with "packets", and > are not capable of manipulating data items in packet headers (e.g. data > items at the IP and/or MAC layers)." > > As Lou Berger put it to me in the context of DLEP - "You want an engineer > to be able to pick up this document, with no prior exposure to the topic, > and code an interoperable implementation." I think this type of an > overview, setting basic ground rules, would help. > > I've also contended for a while now that 5444, with the mux, effectively > forces an architecture on implementers - in the Linux world, that > architecture is a 5444 parser as an independent process, with IPC > mechanisms to the routing protocol(s) it is servicing. The 5444 parser > itself "owns" the transport (the socket). The usage document *strongly > infers* that. I believe we should concretely state it, so we don't have t= o > answer the question over and over again. > > Regards, > > Stan > > > > > > > When a protocol creates a message from scratch it's not constrained in an= y > way I'd describe in such terms. So I assume you mean when it receives a > message and then sends a similar message. > > > > There are two cases there. Unchanged (with the special exceptions for hop > count and limit) and not unchanged. The former is better, and there's > really nothing more to say. > > > > So let's consider the latter. Really it's not the same message, it's a > brand new message. That's a useful way to look at it from a security > perspective, because it tells you that end to end authentication isn't > going to work. And what are the restrictions on brand new messages? The > same as on any new message. > > > > OK, you might say, true but does that mean I can add this, remove that, > change the hop data? Yes. But is that a good idea? No. But maybe you are > forced into it. But that it's inherently not good suggests the corollary > that if you must, do the minimum and make it trackable. But that's not a > 5444 requirement, just good practice. It does break 7182 message ICVs, so > don't use them. > > > > We could, hypothetically, have someone create an extension or alternative > to 7182 that defined aggregated signatures. Then we'd have rules on what > you could change. But that would belong there. If you think those would b= e > good, then again you would want make minimal changes, and mainly only of > certain types. What types? There I can't help you as I don't have a > candidate. > > > > The summary? Don't change if you don't have to. That's recommended. If yo= u > must change you're on your own (with the same restrictions as new > messages). Advice like "as little as possible" is good, but that's not > actually 5444 advice. And don't use 7182 message ICVs. > > -- > > Christopher Dearlove > > christopher.dearlove@gmail.com (iPhone) > > chris@mnemosyne.demon.co.uk (home) > > > On 15 Apr 2016, at 19:37, Stan Ratliff wrote: > > My main concern addressed inline... > > > > > > On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlove < > christopher.dearlove@gmail.com> wrote: > > A few immediate comments inline below. > > -- > > Christopher Dearlove > > christopher.dearlove@gmail.com (iPhone) > > chris@mnemosyne.demon.co.uk (home) > > > On 15 Apr 2016, at 15:18, Lotte Steenbrink > wrote: > > Hi all, > > > > sparked by the recently started WGLC, I=E2=80=99ve reviewed the current r= evision > of the draft. I=E2=80=99d like to offer the working group my perspective = as someone > who doesn=E2=80=99t have decades of protocol and/or packet format design = under > their belt (i.e. some things might not be obvious to me that are obvious = to > others), but also as someone who has worked with RFC 5444 when implementi= ng > a routing protocol (AODVv2), updating the packet format of a routing > protocol (AODVv2 again) and (partially) implementing my own RFC5444 > builder/parser. > > > > Overall, I think the document is easy to read and follow. To me, it > contains valuable information and guidance and in some cases prevents > people from shooting themselves in the foot. > > I=E2=80=99m really happy this document exists and I=E2=80=99d like it to = move forward > soon, but I do feel that it is still lacking in some areas, which is why = I > was a bit surprised to see it go to Last Call all of a sudden. > > > > Not really. The authors had said what they intended to say, no one was > commenting, time for WGLC. > > > > First, some nitpicks and comments: > > > > * from *1.2.1* > *. > Packet/Message Format*: > > > > [=E2=80=A6] a packet > > transmission following a successful packet reception is by design > > of a new packet that may include all, some, or none of the > > received messages [...] > > > > I=E2=80=99m not a native speaker, but that =E2=80=9Eof=E2=80=9C seems out= of place... > > > > I am a native speaker, and no, it's not. Some would repeat it after each > of all, some and none, and I might sometimes. But it really doesn't matte= r > which of the two styles we pick, the RFC Editor may well change to the > other. > > > > * Regarding *4.2* > *. > Packets and Messages:* > > this section talks a lot about how the multiplexer operates, so I think > it=E2=80=99d be helpful if its title reflected that. > > > > I'm of two opinions on that. On the one hand it is, as its title suggests= , > about the packet and message level, as opposed to lower levels, and its > title contrasts with that if 4.3 for that reason. On the other hand you a= re > right, it does have much about the multiplexer. A title covering all thre= e > woukd start getting cumbersome. Will take this one away to think about. > > > > * from *4.4* > *. > Addresses Require Attributes:* > > > > An unmodified extension to NHDP would ignore such addresses, > > as required, as it does not support that specialized purpose. > > > > At first glance, (to me) this reads as =E2=80=9EAll addresses that are as= sociated > with an unknown TLV are ignored=E2=80=9C, which is obviously nonsense (bu= t quite > panic-inducing :D). I=E2=80=99d propose to reword it to something along t= he lines > of > > An unmodified extension to NHDP would not consider this > > address to be of a neighbor, as it is lacking a LINK_STATUS > > or OTHER_NEIGHB TLV. > > > > I take your point, but I think that if the address ends up with no > relevant associated TLVs then it is ignored is also a point. I dare say w= e > can wordsmith something. > > > > Also, I don=E2=80=99t quite get where you=E2=80=99re going with the last = paragraph of that > section (=E2=80=9CThese restrictions do not, however, mean that added inf= ormation > is > > completely ignored for purposes of the base protocol.=E2=80=9D)... > > > > Read on, the rest of the paragraph describes the case where not. But we > might telegraph that better in the opening sentence. > > > > * regarding the maps in *4.5* > *. > Information Representation:* > > I=E2=80=99m afraid I just don=E2=80=99t really understand the purpose of = this section and > the mapping notation. I=E2=80=99m assuming that the maps are supposed to = offer a > way of describing how a TLV relates to a message or an address? > > If so, why does it only mention extension types, but not the basis types? > > > > It says extended types, meaning the combination of the two. But full type > would be better, as almost defined in 5444. In fact I think we should add= a > comment to the notation section. (5444 uses a symbolic name rather than t= he > phrase.) > > > > Or is it supposed to be used something like this: > > > > *BASE_TLV* > > > > Message: > > (base_tlv_extension_type_1) -> (2 octets, "value a when condition x is > met") > > (base_tlv_extension_type_2) -> (2 octets, "value b when condition y is > met") > > > > ? Also, I don=E2=80=99t quite get how this would be used in future protoc= ol > specifications? Or aid in implementing RFC5444 parsers? > > An example or a clarification would be very helpful. > > > > It's a way of looking at things. But not the only one, it goes on to > discuss variants. I think it mostly comes under heading of if useful use > it, if not skip it. We'll take another look, but I don't think this will > ever be elementary. > > > > * regarding *4.6* > *. > TLVs:* > > In general, it=E2=80=99s not clear everywhere in the section whether you= =E2=80=99re > talking to RFC5444 parser/builder implementors or protocol designers. > > > > A protocol SHOULD use an efficient > > representation, but this is a quality of implementation issue. > > > > I=E2=80=99m not sure where you=E2=80=99re going with the last part of tha= t sentence? I=E2=80=99d > reword it to something like =E2=80=9EA protocol SHOULD use an efficient > representation, avoiding unnecessarily verbose use of TLVs and extension > types. However, the final arrangement in a message- or addressTLV block i= s > a quality of implementation issue=E2=80=9C (in case that=E2=80=99s what = you meant). > > > > No, you're considering the protocol design. This is considering the > protocol object that implements the protocol. There isn't a one to one > mapping from information to representation, it's up to the implementation > to do it efficiently. Different implementations of the same protocol > specification may do better or worse here. (Trivial case, an implementati= on > could choose to never compress addresses. Bad idea, but legal.) > > > > And then: > > > > A > > protocol MUST recognize any permitted representation of the > > information; even if it chooses to (for example) only use multivalue > > TLVs, it MUST recognize single value TLVs (and vice versa). > > > > =E2=80=A6 I thought protocols weren=E2=80=99t supposed to specify whether= a TLV is > arranged (for example) as a multivalue TLV?! > > > > Implementation again, not design. > > > > And so, since a protocol shouldn't be concerned with multivalue TLVs and > the like, wouldn=E2=80=99t it be the *RFC5444 implementation* that MUST r= ecognize > any permitted representation? > > > > You're assuming that there is an RFC 5444 implementation. That's the same > way to work if you plan to implement more than one protocol. But nothing > says you have to do it that way. The architecture defined by 5498 admits = of > the multiplexer and protocols, and thus these are rules on the protocol. = If > protocols delegate all their common work to something (parser/creator) th= en > it inherits those restrictions, but that's not defined, and we can't assu= me > it. > > > > Or is this paragraph really just a complicated way of saying =E2=80=9Eas = a > protocol designer, make sure to not specify/rely on things like (for > example) multivalue TLVs, since your messages have to work with *any* > representation=E2=80=9C? If so, I think that should be done in a less com= plicated > fashion (see below). > > > > * regarding *5* > = *. > Structure:* > > Since this section talks a lot about flags, it=E2=80=99d be nice if its t= itle > represented that. Maybe consider renaming it to =E2=80=9EStructure and Fl= ags=E2=80=9C or so? > > > > I mostly don't agree. Structure is the subject, flags are a detail. > > > > * from *6.1* > *. > Address Block Compression:* > > > > Compression of addresses in an Address Block considers addresses to > > consist of a Head, a Mid, and a Tail, where all addresses in an > > Address Block have the same Head and Tail, but different Mids. > > > > > > I=E2=80=99d find this sentence easier to read if it started with =E2=80= =9CCompression of > addresses in an Address Block is possible when addresses consist of a Hea= d, > a Mid [=E2=80=A6]=E2=80=9D. > > > > No. That's missing the point and misleading. Addresses are always > considered to have the head/mid/tail format. Compression is possible if > either the head or tail (or both) is non-empty. > > > > * from *6.1* > *. > Address Block Compression:* > > > > Putting addresses into a message efficiently also has to include: > > > > Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that would be a =E2=80=9E= may=E2=80=9C. Multiple Adress Blocks > and/or reordering don=E2=80=99t increase efficiency in all possible cases= ... > > > > I think that's the wrong change. Rather "include" should be "consider". > > > > * from *6.2* > *. > TLVs:* > > [...] This is even possible if the MPR TLV specified in > > OLSRv2 [RFC7181 ] is added; bu= t it is not possible, in general, if > > the LINK_METRIC TLV is also added. > > > > Why is it not possible for the latter? If that could be explained/hinted > at in a half sentence, I think it=E2=80=99d be helpful information to hav= e in the > draft. > > > > That's very hard, and not just because it's a negative. It's really an > observation that motivates the duscussion. A half sentence would I think > confuse more than it enlightens (it's because you have too many constrain= ts > to satisfy at once - I doubt that helped). > > > > In a typical case where a > > LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with > > enough addresses, sorted appropriately, two single value TLVs can > > be more efficient than one multivalue TLV. > > > > Same thing: why? > > > > Here I think this should be obvious to anyone who has looked at 5444. > > > > * regarding the second paragraph from *6.3* > *. > TLV Values*, i.e. > > > > This approach was specified in [RFC7188 ], and required for protocols > > that extend [RFC6130 ] and [RFC71= 81 ]. It is here RECOMMENDED that > > this approach is followed when defining any Address Block TLV that > > may be used by a protocol using [RFC5444 ]. > > > > The term =E2=80=9Ethis approach=E2=80=9C confused me, since I initially = thought it meant > =E2=80=9Ethe approach is to use UNSPECIFIED in a way that makes sense=E2= =80=9C rather than > =E2=80=9Ethe approach is to use UNSPECIFIED=E2=80=9C. Maybe that could be= reworded to > something along the lines of > > The UNSPECIFIED TLV and its usage was specified in [RFC7188]=E2=80=A6 > > ? > > > > No. There is no UNSPECIFIED TLV. There is a recommendation to include an > UNSPECIFIED value in a TLV. But really, we've described this once in 7188= , > it's there to read. > > > > * regarding *6.3* > *. > TLV Values:* > > The second paragraph is a bit confusing and seems to explaing roghly the > same things as the fourth paragraphs. I=E2=80=99d propose to merge the se= cond into > the fourth. > > > > I'm not sure I exactly agree, but the ordering in that section could be > improved. > > > > * from *6.4* > *. > Automation:* > > > > The possible gain depends on the efficiency > > of the original message creation, > > > > the term =E2=80=9Ethe original message creation=E2=80=9C seems a bit ambi= guous=E2=80=93 does this > refer to the message as created by an RFC5444 message builder > implementation? > > > > Yes. > > > > Additionally, I'm concerned about two things that *aren=E2=80=99t* in the= draft: > > > > * Some of the AODVv2 co-authors and me have asked for a list of =E2=80= =9Eas a > protocol, you can set all of these fields of a message, but please leave > the rest alone=E2=80=9C, which would=E2=80=99ve saved us many hours of di= scussions (and > Henning a lot of time spent explaining these things=E2=80=A6). These requ= ests have > been met with a refusal to specify a concrete API, as such an effort is > dependent on outside factors such as programming language or software > architecture. I agree with this notion, but a programming-language > dependent API is not what we=E2=80=99ve asked for. I=E2=80=99ve tried to = supply a sketch of > what I did ask for in [1], but unfortunately I didn=E2=80=99t get an answ= er (and as > far as I can see it, the draft wasn=E2=80=99t changed either). I still th= ink that > such a list, in whatever form, would be very helpful for future > Internet-Draft authors and I also think this request is in accordance wit= h > the intentions stated in 1.1 History and Purpose, and I think it should > be included in the document. > > > > No. There are many reasons why we're just not touching this one. > > > > One is that language independence is a mirage. How you go about things is > completely different in, for example an object oriented language than one > that isn't. Section 4.5 shows that there are quite different ways of doin= g > things even given a decision to use a map approach, and there are other > approaches than that. It would be wrong and beyond our competence to > suggest one of these as "best". There's reasons the IETF doesn't do this, > and that's one. > > > > Plus, frankly, the work it would take is beyond what we choose to spend. > > > > > > > > > > I'm confused (which is an altogether too common occurrence these days). I > get that we don't want to specify an API. But I think the discussion abou= t > fields a protocol can and can't touch in a messages is a good thing - and > it's one spot where I, too, find the document wanting. > > > > To paraphrase something I've said before, I believe that RFC 5444 changes > the relationship that a routing protocol has with an "interface". I'm not > commenting on whether or not that's a good thing, or a bad thing - just > that it does change the relationship. This change has been at the root of > some of the long-running discussions as to whether protocols under > development were RFC 5444 compliant or not. The goal of this document bei= ng > to eliminate (it's a goal, probably not reachable) those discussions, I'd > like to see that information in the document in some form. > > > > I'm interested in seeing this document progress, and eventually be > published. I think it will help future protocol designers to better use R= FC > 5444. But I would like to see *something* along the lines of what Lotte i= s > requesting, as I think it will improve the doc. > > > > Regards, > > Stan > > > > > > > > * As the exact rules for using/setting the hop count & hop-limit fields > are currently being discussed w/ regard to AODVv2 in another thread [2]= =E2=80=93 > should a definitive answer to that question be part of 5444-usage? > > > > You don't want that. Because if we did specify that you'd find yourself > more constrained than you want to be. There is a design intent described = in > 5444, but it assumes immutable messages. Which you don't want. Really, > we're doing you a favour by not imposing on you. > > > > Best regards, > > Lotte > > > > [1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.html > > [2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.html > > > > > > Am 06.04.2016 um 19:14 schrieb Justin Dean : > > > > The chairs agree that a 3 week WGLC is appropriate. Everyone please read > the draft early and get comments in early so that they can be addressed > within the last call period. > > > > Justin > > > > On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > Obviously +1 to the request for WGLC. > > With regard to what's changed, technically the only significant thing is > to make it clear that if a protocol delivers a message to the multiplexer= , > the multiplexer must pass it on unchanged to the protocol (another instan= ce > of, at another router) unchanged. Without that nothing that the protocol > itself chooses to do with regard to security makes sense. Though the > protocol can alternatively let the multiplexer do the security, 7182 can = be > implemented in either way. This isn't really new, but it wasn't formally > spelled out. It's presented as part of spelling out multiplexer rules mor= e > carefully. > > But what about message optimisation? That's a function of constructing a > 5444 message, not the multiplexer, and is down to that 5444 includes two > things - packet/message structure (and implicitly, and in pretty much any > implementation I would expect to see, a parser and builder for that > structure) and the multiplexer. So we took the opportunity to separate ou= t > more clearly a discussion of the two, which we think will be helpful. > > -- > 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 > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg > Sent: 05 April 2016 20:08 > To: manet@ietf.org > Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > ----------------------! WARNING ! ---------------------- This message > originates from outside our organisation, either from an external partner > or from the internet. > Consider carefully whether you should click on any links, open any > attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions > on reporting suspicious email messages. > -------------------------------------------------------- > > *** WARNING *** > EXTERNAL EMAIL -- This message originates from outside our organization. > > > > Hi, > > As you have seen, we have submitted a new revision of 5444-usage. The > authors feel comfortable that we have addressed all issues by this versio= n, > and would like to ask the WG chairs to issue a WGLC on this document. Whi= le > it is a fairly short document, given that it is IETF week for some, we'd > suggest that a 3-4 week WGLC would be appropriate. > > Best regards > Ulrich > > _______________________________________________ > 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 > > > > _______________________________________________ > 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 > > --001a113b31b2bc14f40530bee2dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Chris,

IMO the use of 5444 is fo= r implementation purpose or information. So, I agree with Stan's commen= t, that this draft is important to progress, but would nice to add in the d= raft some examples of use cases of OLSRv2 and AODVv2 both routing-protocols= , or examples of implementation. This will help the use of 5444 because I t= hink these protocols use 5444 differently because they have different purpo= ses/advantages. Thanks,

AB


On Mon, Apr 18, 2016 at 10:52 AM, D= earlove, Christopher (UK) <chris.dearlove@baesystems.com&g= t; wrote:

I don=E2=80=99t believe w= e can or should suggest an implementation. That=E2=80=99s not what the IETF= does, and it would be a hard, probably impossible, sell, to the IESG. That the obvious implementation employs an independent parser is already said -= it may be appropriate to strengthen the words, but this second I=E2=80=99m= not sure if that=E2=80=99s needed (not got time to check current wording).=

=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: manet [mailto:manet-bounces@ietf.org] On Behalf Of Stan Ratliff
Sent: 16 April 2016 19:09
To: Christopher Dearlove
Cc: manet@ietf.o= rg; Christopher Dearlove
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage= -03

=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>

*** WARNING ***


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

=C2=A0

=C2=A0

=C2=A0

On Fri, Apr 15, 2016 at 3:27 PM, Christopher Dearlov= e <chri= s@mnemosyne.demon.co.uk> wrote:

I don't understand what you mean by the concept = of "fields the protocol can and can't touch".

=C2=A0<= /p>

CAVEAT: I am speaking here as a Working Group partic= ipant. With that understood:
=C2=A0

=C2=A0

TTL is a great exampl= e, since that discussion blew the mailing list up a few months ago. I'm= *not* saying manipulating TTL is a good thing for a protocol to try - in t= ruth, I think it's pretty "hacky". But the notion was floated, and in the context of that discussion, it may will hav= e worked. The opposition on-list was fast, and pretty forceful.

I've said before = - 5444, especially with the multiplexer, changes the relationship between a= routing protocol and an interface. I think the document should have some t= ype of "overview" section which discusses these differences, in order to frame the issue for someone coming along wh= o hasn't been a part of the 5444 mail discussion.

I'm talking about= the type of overview that goes something like this:

"Use of RFC 5444= with the multiplexer feature imposes design requirements on the protocol. = The actual transport mechanism is abstracted from the protocol. For example= , routing protocols are not aware of precisely when a message is sent. A good example of operation in this model is [BGP]= , utilizing the [TCP] transport. This is opposed to a protocol such as [OSP= F], which is capable of sending traffic with its own IP type. Since the tra= nsport is abstracted, protocols are not presented with "packets", and are not capable of manipul= ating data items in packet headers (e.g. data items at the IP and/or MAC la= yers)."

As Lou Berger put it to me in the context of DLEP - "You want an engin= eer to be able to pick up this document, with no prior exposure to the topi= c, and code an interoperable implementation."=C2=A0 I think this type = of an overview, setting basic ground rules, would help.

I've also contend= ed for a while now that 5444, with the mux, effectively forces an architect= ure on implementers - in the Linux world, that architecture is a 5444 parse= r as an independent process, with IPC mechanisms to the routing protocol(s) it is servicing. The 5444 parser itself "o= wns" the transport (the socket). The usage document *strongly infers* = that. I believe we should concretely state it, so we don't have to answ= er the question over and over again.

Regards,

Stan


=C2=A0

=C2=A0

When a protocol creates a message from scratch it= 9;s not constrained in any way I'd describe in such terms. So I assume = you mean when it receives a message and then sends a similar message.

=C2=A0

There are two cases there. Unchanged (with the speci= al exceptions for hop count and limit) and not unchanged. The former is bet= ter, and there's really nothing more to say.

=C2=A0

So let's consider the latter. Really it's no= t the same message, it's a brand new message. That's a useful way t= o look at it from a security perspective, because it tells you that end to = end authentication isn't going to work. And what are the restrictions on brand new messages? The same as on any new message.=

=C2=A0

OK, you might say, true but does that mean I can add= this, remove that, change the hop data? Yes. But is that a good idea? No. = But maybe you are forced into it. But that it's inherently not good sug= gests the corollary that if you must, do the minimum and make it trackable. But that's not a 5444 requiremen= t, just good practice. It does break 7182 message ICVs, so don't use th= em.

=C2=A0

We could, hypothetically, have someone create an ext= ension or alternative to 7182 that defined aggregated signatures. Then we&#= 39;d have rules on what you could change. But that would belong there. If y= ou think those would be good, then again you would want make minimal changes, and mainly only of certain types. Wha= t types? There I can't help you as I don't have a candidate.=

=C2=A0

The summary? Don't change if you don't have = to. That's recommended. If you must change you're on your own (with= the same restrictions as new messages). Advice like "as little as pos= sible" is good, but that's not actually 5444 advice. And don't use 7182 message ICVs.

-- =C2=A0

Christopher Dearlove


On 15 Apr 2016, at 19:37, Stan Ratliff <ratliffstan@gmail.com> wrote:

My main concern addressed inline...

=C2=A0

=C2=A0

On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlov= e <c= hristopher.dearlove@gmail.com> wrote:

A few immediate comments inline below.

-- =C2=A0

Christopher Dearlove


On 15 Apr 2016, at 15:18, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de>= ; wrote:

Hi all,

=C2=A0

sparked by the recently started WGLC, I=E2=80=99ve r= eviewed the current revision of the draft. I=E2=80=99d like to offer the wo= rking group my perspective as someone who doesn=E2=80=99t have decades of p= rotocol and/or packet format design under their belt (i.e. some things might not be obvious to me that are obvious to others), but al= so as someone who has worked with RFC 5444 when implementing a routing prot= ocol (AODVv2), updating the packet format of a routing protocol (AODVv2 aga= in) and (partially) implementing my own RFC5444 builder/parser.

=C2=A0

Overall, I think the document is easy to read and fo= llow. To me, it contains valuable information and guidance and in some case= s prevents people from shooting themselves in the foot.

I=E2=80=99m really happy this document exists and I= =E2=80=99d like it to move forward soon, but I do feel that it is still lac= king in some areas, which is why I was a bit surprised to see it go to Last= Call all of a sudden.

=C2=A0

Not really. The authors had said what they intended = to say, no one was commenting, time for WGLC.



First, some nitpicks and comments:

=C2=A0

* from=C2=A01.2.1. Packet/= Message Format:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0[=E2=80=A6] a packet

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 transmission following a successful pac=
ket reception is by design


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of a new packet that may include all, s=
ome, or none of the


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 received messages [...]

=C2=A0

I=E2=80=99m not a native speaker, but that =E2=80=9E= of=E2=80=9C seems out of place...

=C2=A0

I am a native speaker, and no, it's not. Some wo= uld repeat it after each of all, some and none, and I might sometimes. But = it really doesn't matter which of the two styles we pick, the RFC Edito= r may well change to the other.



* Regarding=C2=A04.2. Packet= s and Messages:

this section talks a lot about how the multiplexer o= perates, so I think it=E2=80=99d be helpful if its title reflected that.=C2= =A0

=C2=A0

I'm of two opinions on that. On the one hand it = is, as its title suggests, about the packet and message level, as opposed t= o lower levels, and its title contrasts with that if 4.3 for that reason. O= n the other hand you are right, it does have much about the multiplexer. A title covering all three woukd start ge= tting cumbersome. Will take this one away to think about.



* from=C2=A04.4. Addresses R= equire Attributes:

=C2=A0

=C2=A0=C2=A0 An unmodified extension to NHDP would ignore such address=
es,
=C2=A0=C2=A0 as required, as it does not support that specialized purp=
ose.

=C2=A0

At first glance, (to me) this reads as =E2=80=9EAll = addresses that are associated with an unknown TLV are ignored=E2=80=9C, whi= ch is obviously nonsense (but quite panic-inducing :D). I=E2=80=99d propose= to reword it to something along the lines of=C2=A0

=C2=A0=C2=A0 An unmodified extension to NHDP would not consider this
=C2=A0=C2=A0 address to be of a neighbor, as it is lacking a LINK_STAT=
US
=C2=A0=C2=A0 or OTHER_NEIGHB TLV.

=C2=A0

I take your point, but I think that if the address e= nds up with no relevant associated TLVs then it is ignored is also a point.= I dare say we can wordsmith something.



Also, I don=E2=80=99t quite get where you=E2=80=99re= going with the last paragraph of that section (=E2=80=9CThese restrictions do not, however, mean that added informat= ion is

=C2=A0=C2=A0 completely ignored for purposes of the base protocol.=E2=
=80=9D)...

=C2=A0

Read on, the rest of the paragraph describes the cas= e where not. But we might telegraph that better in the opening sentence.=



Or is it supposed to be used something like this:=

=C2=A0

BASE_TLV

=C2=A0

Message:=C2=A0

(base_tlv_extens= ion_type_1) -> (2 octets, "value a when condition x is met")

(base_tlv_extens= ion_type_2) -> (2 octets, "value b when condition y is met")

=C2=A0

? Also, I don=E2=80=99t quite get how this would be = used in future protocol specifications? Or aid in implementing RFC5444 pars= ers?

An example or a clarification would be very helpful.=

=C2=A0

It's a way of looking at things. But not the onl= y one, it goes on to discuss variants. I think it mostly comes under headin= g of if useful use it, if not skip it. We'll take another look, but I d= on't think this will ever be elementary.



* regarding=C2=A04.6. TLVs:<= /b>

In general, it=E2=80=99s not clear everywhere in the= section whether you=E2=80=99re talking to RFC5444 parser/builder implement= ors or protocol designers.=C2=A0

=C2=A0

=C2=A0=C2=A0 A protocol SHOULD use an efficient
=C2=A0=C2=A0 representation, but this is a quality of implementation i=
ssue.

=C2=A0

I=E2=80=99m not sure where you=E2=80=99re going with= the last part of that sentence? I=E2=80=99d reword it to something like = =E2=80=9EA protocol SHOULD use an efficient representation, avoiding unnece= ssarily verbose use of TLVs and extension types. However, the final arrangement in a message- or addressTLV block is =C2=A0a quality of implem= entation issue=E2=80=9C (in case that=E2=80=99s what you meant).<= /u>

=C2=A0

No, you're considering the protocol design. This= is considering the protocol object that implements the protocol. There isn= 't a one to one mapping from information to representation, it's up= to the implementation to do it efficiently. Different implementations of the same protocol specification may do better or worse = here. (Trivial case, an implementation could choose to never compress addre= sses. Bad idea, but legal.)



And then:

=C2=A0

=C2=A0=C2=A0 A
=C2=A0=C2=A0 protocol MUST recognize any permitted representation of t=
he
=C2=A0=C2=A0 information; even if it chooses to (for example) only use=
 multivalue
=C2=A0=C2=A0 TLVs, it MUST recognize single value TLVs (and vice versa=
).

=C2=A0

=E2=80=A6 I thought protocols weren=E2=80=99t suppos= ed to specify whether a TLV is arranged (for example) as a multivalue TLV?!=

=C2=A0

Implementation again, not design.



And so, since a protocol shouldn't be concerned = with multivalue TLVs and the like, wouldn=E2=80=99t it be the *RFC5444 impl= ementation* that MUST recognize any permitted representation?=

=C2=A0

You're assuming that there is an RFC 5444 implem= entation. That's the same way to work if you plan to implement more tha= n one protocol. But nothing says you have to do it that way. The architectu= re defined by 5498 admits of the multiplexer and protocols, and thus these are rules on the protocol. If protocols dele= gate all their common work to something (parser/creator) then it inherits t= hose restrictions, but that's not defined, and we can't assume it.<= u>



Or is this paragraph really just a complicated way o= f saying =E2=80=9Eas a protocol designer, make sure to not specify/rely on = things like (for example) multivalue TLVs, since your messages have to work= with *any* representation=E2=80=9C? If so, I think that should be done in a less complicated fashion (see below).

=C2=A0

* regarding=C2=A05. Structure:=

Since this section talks a lot about flags, it=E2=80= =99d be nice if its title represented that. Maybe consider renaming it to= =C2=A0=E2=80=9EStructure and Flags=E2=80=9C=C2=A0or so?

=C2=A0

I mostly don't agree. Structure is the subject, = flags are a detail.



* from=C2=A06.1. Address Blo= ck Compression:

=C2=A0

=C2=A0=C2=A0 Compression of addresses in an Address Block considers ad=
dresses to
=C2=A0=C2=A0 consist of a Head, a Mid, and a Tail, where all addresses=
 in an
=C2=A0=C2=A0 Address Block have the same Head and Tail, but different =
Mids.

=C2=A0

=C2=A0

I=E2=80=99d find this sentence easier to read if it = started with =E2=80=9CCompression of addresses in an Address Block is possi= ble when addresses consist of a Head, a Mid [=E2=80=A6]=E2=80=9D.=

=C2=A0

No. That's missing the point and misleading. Add= resses are always considered to have the head/mid/tail format. Compression = is possible if either the head or tail (or both) is non-empty.



* from=C2=A06.1. Address Blo= ck Compression:

=C2=A0
=C2=A0=C2=A0 Putting addresses into a message efficiently also has to =
include:
=C2=A0

Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that= would be a =E2=80=9Emay=E2=80=9C. Multiple Adress Blocks and/or reordering= don=E2=80=99t increase efficiency in all possible cases...

=C2=A0

I think that's the wrong change. Rather "in= clude" should be "consider".



* from=C2=A06.2. TLVs:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [...] This is even possible if the MPR =
TLV specified in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OLSRv2 [RFC7181] is added; but it is not poss=
ible, in general, if
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the LINK_METRIC TLV is also added.

=C2=A0

Why is it not possible for the latter? If that could= be explained/hinted at in a half sentence, I think it=E2=80=99d be helpful= information to have in the draft.

=C2=A0

That's very hard, and not just because it's = a negative. It's really an observation that motivates the duscussion. A= half sentence would I think confuse more than it enlightens (it's beca= use you have too many constraints to satisfy at once - I doubt that helped).



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In a typical case where a=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LINK_STATUS TLV uses only the Values HE=
ARD and SYMMETRIC, with
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enough addresses, sorted appropriately,=
 two single value TLVs can
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 be more efficient than one multivalue T=
LV.

=C2=A0

Same thing: why?

=C2=A0

Here I think this should be obvious to anyone who ha= s looked at 5444.



* regarding the second paragraph from=C2=A06= .3. TLV Values, i.e.

=C2=A0 =C2=A0
=C2=A0=C2=A0 This approach was specified in [RFC718=
8], and required for protocols
=C2=A0=C2=A0 that extend [RFC6130] and [RFC7181].=C2=A0 It is her=
e RECOMMENDED that
=C2=A0=C2=A0 this approach is followed when defining any Address Block=
 TLV that
=C2=A0=C2=A0 may be used by a protocol using [RFC5444].

=C2=A0

The term =E2=80=9Ethis approach=E2=80=9C confused me= , since I initially =C2=A0thought it meant =E2=80=9Ethe approach is to use = UNSPECIFIED in a way that makes sense=E2=80=9C rather than =E2=80=9Ethe app= roach is to use UNSPECIFIED=E2=80=9C. Maybe that could be reworded to somet= hing along the lines of=C2=A0

The UNSPECIFIED = TLV and its usage was specified in [RFC7188]=E2=80=A6=C2=A0

?

=C2=A0

No. There is no UNSPECIFIED TLV. There is a recommen= dation to include an UNSPECIFIED value in a TLV. But really, we've desc= ribed this once in 7188, it's there to read.



* regarding=C2=A06.3. TLV Va= lues:

The second paragraph is a bit confusing and seems to= explaing roghly the same things as the fourth paragraphs. I=E2=80=99d prop= ose to merge the second into the fourth.

=C2=A0

I'm not sure I exactly agree, but the ordering i= n that section could be improved.



* from=C2=A06.4. Automa= tion:

=C2=A0

=C2=A0=C2=A0 The possible gain depends on the efficiency=

=C2=A0=C2=A0 of the original message creation,

=C2=A0

the term =E2=80=9Ethe original message creation=E2= =80=9C seems a bit ambiguous=E2=80=93 does this refer to the message as cre= ated by an RFC5444 message builder implementation?

=C2=A0

Yes.



Additionally, I'm concerned about two things tha= t *aren=E2=80=99t* in the draft:

=C2=A0

* =C2=A0Some of the AODVv2 co-authors and me have as= ked for a list of =E2=80=9Eas a protocol, you can set all of these fields o= f a message, but please leave the rest alone=E2=80=9C, which would=E2=80=99= ve saved us many hours of discussions (and Henning a lot of time spent explaining these things=E2=80=A6). These requests have been met with= a refusal to specify a concrete API, as such an effort is dependent on out= side factors such as programming language or software architecture. I agree= with this notion, but a programming-language dependent API is not what we=E2=80=99ve asked for. I=E2=80=99ve tried to s= upply a sketch of what I did ask for in [1], but unfortunately I didn=E2=80= =99t get an answer (and as far as I can see it, the draft wasn=E2=80=99t ch= anged either). I still think that such a list, in whatever form, would be very helpful for future Internet-Draft authors and I also think t= his request is in accordance with the intentions stated in=C2=A01.1 History and Purpose,=C2=A0and I think i= t should be included in the document.

=C2=A0

No. There are many reasons why we're just not to= uching this one.

=C2=A0

One is that language independence is a mirage. How y= ou go about things is completely different in, for example an object orient= ed language than one that isn't. Section 4.5 shows that there are quite= different ways of doing things even given a decision to use a map approach, and there are other approaches than that= . It would be wrong and beyond our competence to suggest one of these as &q= uot;best". There's reasons the IETF doesn't do this, and that&= #39;s one.

=C2=A0

Plus, frankly, the work it would take is beyond what= we choose to spend.

=C2=A0

=C2=A0

<Speaking as a WG Participant>

=C2=A0

I'm confused (which is an altogether too common = occurrence these days). I get that we don't want to specify an API. But= I think the discussion about fields a protocol can and can't touch in = a messages is a good thing - and it's one spot where I, too, find the document wanting.=C2=A0

=C2=A0

To paraphrase something I've said before, I beli= eve that RFC 5444 changes the relationship that a routing protocol has with= an "interface". I'm not commenting on whether or not that= 9;s a good thing, or a bad thing - just that it does change the relationship. This change has been at the root of some of the long-run= ning discussions as to whether protocols under development were RFC 5444 co= mpliant or not. The goal of this document being to eliminate (it's a go= al, probably not reachable) those discussions, I'd like to see that information in the document in some form.=C2=A0

=C2=A0

I'm interested in seeing this document progress,= and eventually be published. I think it will help future protocol designer= s to better use RFC 5444. But I would like to see *something* along the lin= es of what Lotte is requesting, as I think it will improve the doc.=C2=A0

=C2=A0

Regards,

Stan

=C2=A0

=C2=A0



* As the exact rules for using/setting the hop count= & hop-limit fields are currently being discussed w/ regard to AODVv2 i= n another thread [2]=E2=80=93 should a definitive answer to that question b= e part of 5444-usage?

=C2=A0

You don't want that. Because if we did specify t= hat you'd find yourself more constrained than you want to be. There is = a design intent described in 5444, but it assumes immutable messages. Which= you don't want. Really, we're doing you a favour by not imposing on you.



=C2=A0

=C2=A0

Am 06.04.2016 um 19:14 schrieb Justin Dean <bebemaster@gmail.com>:

=C2=A0

The chairs agree that a 3 week WGLC is appropriate.= =C2=A0 Everyone please read the draft early and get comments in early so th= at they can be addressed within the last call period.

=C2=A0

Justin

=C2=A0

On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christophe= r (UK) <chris.dearlove@baesystems.com> wrote:

Obviously +1 to the request for WGLC.

With regard to what's changed, technically the only significant thing i= s to make it clear that if a protocol delivers a message to the multiplexer= , the multiplexer must pass it on unchanged to the protocol (another instan= ce of, at another router) unchanged. Without that nothing that the protocol itself chooses to do with regard to= security makes sense. Though the protocol can alternatively let the multip= lexer do the security, 7182 can be implemented in either way. This isn'= t really new, but it wasn't formally spelled out. It's presented as part of spelling out multiplexer rules = more carefully.

But what about message optimisation? That's a function of constructing = a 5444 message, not the multiplexer, and is down to that 5444 includes two = things - packet/message structure (and implicitly, and in pretty much any i= mplementation I would expect to see, a parser and builder for that structure) and the multiplexer. So we took t= he opportunity to separate out more clearly a discussion of the two, which = we think will be helpful.

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

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN.
www.baesystems.c= om/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 Ulrich Herberg
Sent: 05 April 2016 20:08
To: manet@ietf.org<= br> Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

----------------------! 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 instru= ctions on reporting suspicious email messages.
--------------------------------------------------------

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



Hi,

As you have seen, we have submitted a new revision of 5444-usage. The autho= rs feel comfortable that we have addressed all issues by this version, and = would like to ask the WG chairs to issue a WGLC on this document. While it = is a fairly short document, given that it is IETF week for some, we'd suggest that a 3-4 week WGLC would= be appropriate.

Best regards
Ulrich

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://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
h= ttps://www.ietf.org/mailman/listinfo/manet

=C2=A0

_______________________________________________
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


--001a113b31b2bc14f40530bee2dc-- From nobody Mon Apr 18 02:37: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 9584212DCDF for ; Mon, 18 Apr 2016 02:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.915 X-Spam-Level: X-Spam-Status: No, score=-7.915 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] 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 85a5sAJdrMAw for ; Mon, 18 Apr 2016 02:37:09 -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 A3E2012DC87 for ; Mon, 18 Apr 2016 02:37:08 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,501,1454976000"; d="scan'208,217"; a="33727763" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 18 Apr 2016 10:37:06 +0100 X-IronPort-AV: E=Sophos;i="5.24,501,1454976000"; d="scan'208,217";a="114373372" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 18 Apr 2016 10:37:07 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 10:37:06 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 Thread-Index: AQHRj26efzFsMll+IU2A0f8aUpvZOp980SWwgABO2gCADfPgAIAAOu8AgAANM4CAAZs2zoACiJ1w///364CAABQz4A== Date: Mon, 18 Apr 2016 09:37:06 +0000 Message-ID: References: <45DFA343-1FDD-4EB9-9291-AB3A830A3CD9@mnemosyne.demon.co.uk> 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD87DGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" , Christopher Dearlove Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 18 Apr 2016 09:37:13 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD87DGLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VXNlIGNhc2VzIG9mIHJvdXRpbmcgcHJvdG9jb2xzIGFyZW7igJl0IHRoZSBwb2ludCwgdGhpcyBp cyBhYm91dCB0aGUgbGF5ZXIgdGhleSB1c2UuDQoNClVzZSBjYXNlcyBvZiB0aGF0LCB3ZSBoYXZl IHNvbWUgdmVyeSBmdWxseSB3b3JrZWQgb3V0IGV4YW1wbGVzIC0gUkZDIDYxMzAsIFJGQyA2NjIx LCBSRkMgNzE4MSwgYW5kLCBpZiB5b3Ugd2FudCBhIHJlYWN0aXZlIGV4YW1wbGUsIHdoYXTigJlz IHF1b3RlZCBhcyBbRzk5MDNdIGluIHRoZSBkcmFmdC4NCg0KQnV0IHdoYXTigJlzIHdhbnRlZCBo ZXJlIGlzIG9mIGNvdXJzZSB0byB1c2UgdGhvc2UgdG8gbWFrZSBzcGVjaWZpYyBwb2ludHMuIFdo aWNoIHdlIGRvIGluIHZhcmlvdXMgcGxhY2VzLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUN ClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdl bmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0 MjE5NCAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j ZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwg RXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3Rl bXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVn aXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmlj ZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZy b206IEFiZHVzc2FsYW0gQmFyeXVuIFttYWlsdG86YWJkdXNzYWxhbWJhcnl1bkBnbWFpbC5jb21d DQpTZW50OiAxOCBBcHJpbCAyMDE2IDEwOjIxDQpUbzogRGVhcmxvdmUsIENocmlzdG9waGVyIChV SykNCkNjOiBTdGFuIFJhdGxpZmY7IENocmlzdG9waGVyIERlYXJsb3ZlOyBDaHJpc3RvcGhlciBE ZWFybG92ZTsgbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFdHTEMgcmVxdWVz dCBmb3IgZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzDQoNCg0KKioqIFdBUk5JTkcg KioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlv biwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25z aWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3Bl biBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJl ZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwg Y2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9z ZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZl ZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0 dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3Rs aWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+ Lg0KSGkgQ2hyaXMsDQpJTU8gdGhlIHVzZSBvZiA1NDQ0IGlzIGZvciBpbXBsZW1lbnRhdGlvbiBw dXJwb3NlIG9yIGluZm9ybWF0aW9uLiBTbywgSSBhZ3JlZSB3aXRoIFN0YW4ncyBjb21tZW50LCB0 aGF0IHRoaXMgZHJhZnQgaXMgaW1wb3J0YW50IHRvIHByb2dyZXNzLCBidXQgd291bGQgbmljZSB0 byBhZGQgaW4gdGhlIGRyYWZ0IHNvbWUgZXhhbXBsZXMgb2YgdXNlIGNhc2VzIG9mIE9MU1J2MiBh bmQgQU9EVnYyIGJvdGggcm91dGluZy1wcm90b2NvbHMsIG9yIGV4YW1wbGVzIG9mIGltcGxlbWVu dGF0aW9uLiBUaGlzIHdpbGwgaGVscCB0aGUgdXNlIG9mIDU0NDQgYmVjYXVzZSBJIHRoaW5rIHRo ZXNlIHByb3RvY29scyB1c2UgNTQ0NCBkaWZmZXJlbnRseSBiZWNhdXNlIHRoZXkgaGF2ZSBkaWZm ZXJlbnQgcHVycG9zZXMvYWR2YW50YWdlcy4gVGhhbmtzLA0KQUINCg0KDQpPbiBNb24sIEFwciAx OCwgMjAxNiBhdCAxMDo1MiBBTSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgPGNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNv bT4+IHdyb3RlOg0KSSBkb27igJl0IGJlbGlldmUgd2UgY2FuIG9yIHNob3VsZCBzdWdnZXN0IGFu IGltcGxlbWVudGF0aW9uLiBUaGF04oCZcyBub3Qgd2hhdCB0aGUgSUVURiBkb2VzLCBhbmQgaXQg d291bGQgYmUgYSBoYXJkLCBwcm9iYWJseSBpbXBvc3NpYmxlLCBzZWxsLCB0byB0aGUgSUVTRy4g VGhhdCB0aGUgb2J2aW91cyBpbXBsZW1lbnRhdGlvbiBlbXBsb3lzIGFuIGluZGVwZW5kZW50IHBh cnNlciBpcyBhbHJlYWR5IHNhaWQgLSBpdCBtYXkgYmUgYXBwcm9wcmlhdGUgdG8gc3RyZW5ndGhl biB0aGUgd29yZHMsIGJ1dCB0aGlzIHNlY29uZCBJ4oCZbSBub3Qgc3VyZSBpZiB0aGF04oCZcyBu ZWVkZWQgKG5vdCBnb3QgdGltZSB0byBjaGVjayBjdXJyZW50IHdvcmRpbmcpLg0KDQotLQ0KQ2hy aXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1z IEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K VDogICs0NCAoMCkxMjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4g IHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENo ZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4 IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNv bS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1 cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBt YW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0LWJvdW5jZXNA aWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgU3RhbiBSYXRsaWZmDQpTZW50OiAxNiBBcHJpbCAyMDE2 IDE5OjA5DQpUbzogQ2hyaXN0b3BoZXIgRGVhcmxvdmUNCkNjOiBtYW5ldEBpZXRmLm9yZzxtYWls dG86bWFuZXRAaWV0Zi5vcmc+OyBDaHJpc3RvcGhlciBEZWFybG92ZQ0KU3ViamVjdDogUmU6IFtt YW5ldF0gV0dMQyByZXF1ZXN0IGZvciBkcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMN Cg0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lk ZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRo ZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sg b24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1h dGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1h aWxzIHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVt cy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdz LnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxv dyB0aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdv cmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNp b3VzJTIwRW1haWxzLnBkZj4uDQoqKiogV0FSTklORyAqKioNCg0KRVhURVJOQUwgRU1BSUwgLS0g VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb24uDQoN Cg0KDQpPbiBGcmksIEFwciAxNSwgMjAxNiBhdCAzOjI3IFBNLCBDaHJpc3RvcGhlciBEZWFybG92 ZSA8Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrPG1haWx0bzpjaHJpc0BtbmVtb3N5bmUuZGVt b24uY28udWs+PiB3cm90ZToNCkkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFuIGJ5IHRo ZSBjb25jZXB0IG9mICJmaWVsZHMgdGhlIHByb3RvY29sIGNhbiBhbmQgY2FuJ3QgdG91Y2giLg0K DQpDQVZFQVQ6IEkgYW0gc3BlYWtpbmcgaGVyZSBhcyBhIFdvcmtpbmcgR3JvdXAgcGFydGljaXBh bnQuIFdpdGggdGhhdCB1bmRlcnN0b29kOg0KDQoNClRUTCBpcyBhIGdyZWF0IGV4YW1wbGUsIHNp bmNlIHRoYXQgZGlzY3Vzc2lvbiBibGV3IHRoZSBtYWlsaW5nIGxpc3QgdXAgYSBmZXcgbW9udGhz IGFnby4gSSdtICpub3QqIHNheWluZyBtYW5pcHVsYXRpbmcgVFRMIGlzIGEgZ29vZCB0aGluZyBm b3IgYSBwcm90b2NvbCB0byB0cnkgLSBpbiB0cnV0aCwgSSB0aGluayBpdCdzIHByZXR0eSAiaGFj a3kiLiBCdXQgdGhlIG5vdGlvbiB3YXMgZmxvYXRlZCwgYW5kIGluIHRoZSBjb250ZXh0IG9mIHRo YXQgZGlzY3Vzc2lvbiwgaXQgbWF5IHdpbGwgaGF2ZSB3b3JrZWQuIFRoZSBvcHBvc2l0aW9uIG9u LWxpc3Qgd2FzIGZhc3QsIGFuZCBwcmV0dHkgZm9yY2VmdWwuDQpJJ3ZlIHNhaWQgYmVmb3JlIC0g NTQ0NCwgZXNwZWNpYWxseSB3aXRoIHRoZSBtdWx0aXBsZXhlciwgY2hhbmdlcyB0aGUgcmVsYXRp b25zaGlwIGJldHdlZW4gYSByb3V0aW5nIHByb3RvY29sIGFuZCBhbiBpbnRlcmZhY2UuIEkgdGhp bmsgdGhlIGRvY3VtZW50IHNob3VsZCBoYXZlIHNvbWUgdHlwZSBvZiAib3ZlcnZpZXciIHNlY3Rp b24gd2hpY2ggZGlzY3Vzc2VzIHRoZXNlIGRpZmZlcmVuY2VzLCBpbiBvcmRlciB0byBmcmFtZSB0 aGUgaXNzdWUgZm9yIHNvbWVvbmUgY29taW5nIGFsb25nIHdobyBoYXNuJ3QgYmVlbiBhIHBhcnQg b2YgdGhlIDU0NDQgbWFpbCBkaXNjdXNzaW9uLg0KSSdtIHRhbGtpbmcgYWJvdXQgdGhlIHR5cGUg b2Ygb3ZlcnZpZXcgdGhhdCBnb2VzIHNvbWV0aGluZyBsaWtlIHRoaXM6DQoiVXNlIG9mIFJGQyA1 NDQ0IHdpdGggdGhlIG11bHRpcGxleGVyIGZlYXR1cmUgaW1wb3NlcyBkZXNpZ24gcmVxdWlyZW1l bnRzIG9uIHRoZSBwcm90b2NvbC4gVGhlIGFjdHVhbCB0cmFuc3BvcnQgbWVjaGFuaXNtIGlzIGFi c3RyYWN0ZWQgZnJvbSB0aGUgcHJvdG9jb2wuIEZvciBleGFtcGxlLCByb3V0aW5nIHByb3RvY29s cyBhcmUgbm90IGF3YXJlIG9mIHByZWNpc2VseSB3aGVuIGEgbWVzc2FnZSBpcyBzZW50LiBBIGdv b2QgZXhhbXBsZSBvZiBvcGVyYXRpb24gaW4gdGhpcyBtb2RlbCBpcyBbQkdQXSwgdXRpbGl6aW5n IHRoZSBbVENQXSB0cmFuc3BvcnQuIFRoaXMgaXMgb3Bwb3NlZCB0byBhIHByb3RvY29sIHN1Y2gg YXMgW09TUEZdLCB3aGljaCBpcyBjYXBhYmxlIG9mIHNlbmRpbmcgdHJhZmZpYyB3aXRoIGl0cyBv d24gSVAgdHlwZS4gU2luY2UgdGhlIHRyYW5zcG9ydCBpcyBhYnN0cmFjdGVkLCBwcm90b2NvbHMg YXJlIG5vdCBwcmVzZW50ZWQgd2l0aCAicGFja2V0cyIsIGFuZCBhcmUgbm90IGNhcGFibGUgb2Yg bWFuaXB1bGF0aW5nIGRhdGEgaXRlbXMgaW4gcGFja2V0IGhlYWRlcnMgKGUuZy4gZGF0YSBpdGVt cyBhdCB0aGUgSVAgYW5kL29yIE1BQyBsYXllcnMpLiINCg0KQXMgTG91IEJlcmdlciBwdXQgaXQg dG8gbWUgaW4gdGhlIGNvbnRleHQgb2YgRExFUCAtICJZb3Ugd2FudCBhbiBlbmdpbmVlciB0byBi ZSBhYmxlIHRvIHBpY2sgdXAgdGhpcyBkb2N1bWVudCwgd2l0aCBubyBwcmlvciBleHBvc3VyZSB0 byB0aGUgdG9waWMsIGFuZCBjb2RlIGFuIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb24uIiAg SSB0aGluayB0aGlzIHR5cGUgb2YgYW4gb3ZlcnZpZXcsIHNldHRpbmcgYmFzaWMgZ3JvdW5kIHJ1 bGVzLCB3b3VsZCBoZWxwLg0KSSd2ZSBhbHNvIGNvbnRlbmRlZCBmb3IgYSB3aGlsZSBub3cgdGhh dCA1NDQ0LCB3aXRoIHRoZSBtdXgsIGVmZmVjdGl2ZWx5IGZvcmNlcyBhbiBhcmNoaXRlY3R1cmUg b24gaW1wbGVtZW50ZXJzIC0gaW4gdGhlIExpbnV4IHdvcmxkLCB0aGF0IGFyY2hpdGVjdHVyZSBp cyBhIDU0NDQgcGFyc2VyIGFzIGFuIGluZGVwZW5kZW50IHByb2Nlc3MsIHdpdGggSVBDIG1lY2hh bmlzbXMgdG8gdGhlIHJvdXRpbmcgcHJvdG9jb2wocykgaXQgaXMgc2VydmljaW5nLiBUaGUgNTQ0 NCBwYXJzZXIgaXRzZWxmICJvd25zIiB0aGUgdHJhbnNwb3J0ICh0aGUgc29ja2V0KS4gVGhlIHVz YWdlIGRvY3VtZW50ICpzdHJvbmdseSBpbmZlcnMqIHRoYXQuIEkgYmVsaWV2ZSB3ZSBzaG91bGQg Y29uY3JldGVseSBzdGF0ZSBpdCwgc28gd2UgZG9uJ3QgaGF2ZSB0byBhbnN3ZXIgdGhlIHF1ZXN0 aW9uIG92ZXIgYW5kIG92ZXIgYWdhaW4uDQpSZWdhcmRzLA0KU3Rhbg0KDQoNCg0KV2hlbiBhIHBy b3RvY29sIGNyZWF0ZXMgYSBtZXNzYWdlIGZyb20gc2NyYXRjaCBpdCdzIG5vdCBjb25zdHJhaW5l ZCBpbiBhbnkgd2F5IEknZCBkZXNjcmliZSBpbiBzdWNoIHRlcm1zLiBTbyBJIGFzc3VtZSB5b3Ug bWVhbiB3aGVuIGl0IHJlY2VpdmVzIGEgbWVzc2FnZSBhbmQgdGhlbiBzZW5kcyBhIHNpbWlsYXIg bWVzc2FnZS4NCg0KVGhlcmUgYXJlIHR3byBjYXNlcyB0aGVyZS4gVW5jaGFuZ2VkICh3aXRoIHRo ZSBzcGVjaWFsIGV4Y2VwdGlvbnMgZm9yIGhvcCBjb3VudCBhbmQgbGltaXQpIGFuZCBub3QgdW5j aGFuZ2VkLiBUaGUgZm9ybWVyIGlzIGJldHRlciwgYW5kIHRoZXJlJ3MgcmVhbGx5IG5vdGhpbmcg bW9yZSB0byBzYXkuDQoNClNvIGxldCdzIGNvbnNpZGVyIHRoZSBsYXR0ZXIuIFJlYWxseSBpdCdz IG5vdCB0aGUgc2FtZSBtZXNzYWdlLCBpdCdzIGEgYnJhbmQgbmV3IG1lc3NhZ2UuIFRoYXQncyBh IHVzZWZ1bCB3YXkgdG8gbG9vayBhdCBpdCBmcm9tIGEgc2VjdXJpdHkgcGVyc3BlY3RpdmUsIGJl Y2F1c2UgaXQgdGVsbHMgeW91IHRoYXQgZW5kIHRvIGVuZCBhdXRoZW50aWNhdGlvbiBpc24ndCBn b2luZyB0byB3b3JrLiBBbmQgd2hhdCBhcmUgdGhlIHJlc3RyaWN0aW9ucyBvbiBicmFuZCBuZXcg bWVzc2FnZXM/IFRoZSBzYW1lIGFzIG9uIGFueSBuZXcgbWVzc2FnZS4NCg0KT0ssIHlvdSBtaWdo dCBzYXksIHRydWUgYnV0IGRvZXMgdGhhdCBtZWFuIEkgY2FuIGFkZCB0aGlzLCByZW1vdmUgdGhh dCwgY2hhbmdlIHRoZSBob3AgZGF0YT8gWWVzLiBCdXQgaXMgdGhhdCBhIGdvb2QgaWRlYT8gTm8u IEJ1dCBtYXliZSB5b3UgYXJlIGZvcmNlZCBpbnRvIGl0LiBCdXQgdGhhdCBpdCdzIGluaGVyZW50 bHkgbm90IGdvb2Qgc3VnZ2VzdHMgdGhlIGNvcm9sbGFyeSB0aGF0IGlmIHlvdSBtdXN0LCBkbyB0 aGUgbWluaW11bSBhbmQgbWFrZSBpdCB0cmFja2FibGUuIEJ1dCB0aGF0J3Mgbm90IGEgNTQ0NCBy ZXF1aXJlbWVudCwganVzdCBnb29kIHByYWN0aWNlLiBJdCBkb2VzIGJyZWFrIDcxODIgbWVzc2Fn ZSBJQ1ZzLCBzbyBkb24ndCB1c2UgdGhlbS4NCg0KV2UgY291bGQsIGh5cG90aGV0aWNhbGx5LCBo YXZlIHNvbWVvbmUgY3JlYXRlIGFuIGV4dGVuc2lvbiBvciBhbHRlcm5hdGl2ZSB0byA3MTgyIHRo YXQgZGVmaW5lZCBhZ2dyZWdhdGVkIHNpZ25hdHVyZXMuIFRoZW4gd2UnZCBoYXZlIHJ1bGVzIG9u IHdoYXQgeW91IGNvdWxkIGNoYW5nZS4gQnV0IHRoYXQgd291bGQgYmVsb25nIHRoZXJlLiBJZiB5 b3UgdGhpbmsgdGhvc2Ugd291bGQgYmUgZ29vZCwgdGhlbiBhZ2FpbiB5b3Ugd291bGQgd2FudCBt YWtlIG1pbmltYWwgY2hhbmdlcywgYW5kIG1haW5seSBvbmx5IG9mIGNlcnRhaW4gdHlwZXMuIFdo YXQgdHlwZXM/IFRoZXJlIEkgY2FuJ3QgaGVscCB5b3UgYXMgSSBkb24ndCBoYXZlIGEgY2FuZGlk YXRlLg0KDQpUaGUgc3VtbWFyeT8gRG9uJ3QgY2hhbmdlIGlmIHlvdSBkb24ndCBoYXZlIHRvLiBU aGF0J3MgcmVjb21tZW5kZWQuIElmIHlvdSBtdXN0IGNoYW5nZSB5b3UncmUgb24geW91ciBvd24g KHdpdGggdGhlIHNhbWUgcmVzdHJpY3Rpb25zIGFzIG5ldyBtZXNzYWdlcykuIEFkdmljZSBsaWtl ICJhcyBsaXR0bGUgYXMgcG9zc2libGUiIGlzIGdvb2QsIGJ1dCB0aGF0J3Mgbm90IGFjdHVhbGx5 IDU0NDQgYWR2aWNlLiBBbmQgZG9uJ3QgdXNlIDcxODIgbWVzc2FnZSBJQ1ZzLg0KDQotLQ0KQ2hy aXN0b3BoZXIgRGVhcmxvdmUNCmNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNvbTxtYWlsdG86 Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tPiAoaVBob25lKQ0KY2hyaXNAbW5lbW9zeW5l LmRlbW9uLmNvLnVrPG1haWx0bzpjaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWs+IChob21lKQ0K DQpPbiAxNSBBcHIgMjAxNiwgYXQgMTk6MzcsIFN0YW4gUmF0bGlmZiA8cmF0bGlmZnN0YW5AZ21h aWwuY29tPG1haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb20+PiB3cm90ZToNCk15IG1haW4gY29u Y2VybiBhZGRyZXNzZWQgaW5saW5lLi4uDQoNCg0KT24gRnJpLCBBcHIgMTUsIDIwMTYgYXQgMTo0 OSBQTSwgQ2hyaXN0b3BoZXIgRGVhcmxvdmUgPGNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNv bTxtYWlsdG86Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tPj4gd3JvdGU6DQpBIGZldyBp bW1lZGlhdGUgY29tbWVudHMgaW5saW5lIGJlbG93Lg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxv dmUNCmNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNvbTxtYWlsdG86Y2hyaXN0b3BoZXIuZGVh cmxvdmVAZ21haWwuY29tPiAoaVBob25lKQ0KY2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrPG1h aWx0bzpjaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWs+IChob21lKQ0KDQpPbiAxNSBBcHIgMjAx NiwgYXQgMTU6MTgsIExvdHRlIFN0ZWVuYnJpbmsgPGxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGlu LmRlPG1haWx0bzpsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZT4+IHdyb3RlOg0KSGkgYWxs LA0KDQpzcGFya2VkIGJ5IHRoZSByZWNlbnRseSBzdGFydGVkIFdHTEMsIEnigJl2ZSByZXZpZXdl ZCB0aGUgY3VycmVudCByZXZpc2lvbiBvZiB0aGUgZHJhZnQuIEnigJlkIGxpa2UgdG8gb2ZmZXIg dGhlIHdvcmtpbmcgZ3JvdXAgbXkgcGVyc3BlY3RpdmUgYXMgc29tZW9uZSB3aG8gZG9lc27igJl0 IGhhdmUgZGVjYWRlcyBvZiBwcm90b2NvbCBhbmQvb3IgcGFja2V0IGZvcm1hdCBkZXNpZ24gdW5k ZXIgdGhlaXIgYmVsdCAoaS5lLiBzb21lIHRoaW5ncyBtaWdodCBub3QgYmUgb2J2aW91cyB0byBt ZSB0aGF0IGFyZSBvYnZpb3VzIHRvIG90aGVycyksIGJ1dCBhbHNvIGFzIHNvbWVvbmUgd2hvIGhh cyB3b3JrZWQgd2l0aCBSRkMgNTQ0NCB3aGVuIGltcGxlbWVudGluZyBhIHJvdXRpbmcgcHJvdG9j b2wgKEFPRFZ2MiksIHVwZGF0aW5nIHRoZSBwYWNrZXQgZm9ybWF0IG9mIGEgcm91dGluZyBwcm90 b2NvbCAoQU9EVnYyIGFnYWluKSBhbmQgKHBhcnRpYWxseSkgaW1wbGVtZW50aW5nIG15IG93biBS RkM1NDQ0IGJ1aWxkZXIvcGFyc2VyLg0KDQpPdmVyYWxsLCBJIHRoaW5rIHRoZSBkb2N1bWVudCBp cyBlYXN5IHRvIHJlYWQgYW5kIGZvbGxvdy4gVG8gbWUsIGl0IGNvbnRhaW5zIHZhbHVhYmxlIGlu Zm9ybWF0aW9uIGFuZCBndWlkYW5jZSBhbmQgaW4gc29tZSBjYXNlcyBwcmV2ZW50cyBwZW9wbGUg ZnJvbSBzaG9vdGluZyB0aGVtc2VsdmVzIGluIHRoZSBmb290Lg0KSeKAmW0gcmVhbGx5IGhhcHB5 IHRoaXMgZG9jdW1lbnQgZXhpc3RzIGFuZCBJ4oCZZCBsaWtlIGl0IHRvIG1vdmUgZm9yd2FyZCBz b29uLCBidXQgSSBkbyBmZWVsIHRoYXQgaXQgaXMgc3RpbGwgbGFja2luZyBpbiBzb21lIGFyZWFz LCB3aGljaCBpcyB3aHkgSSB3YXMgYSBiaXQgc3VycHJpc2VkIHRvIHNlZSBpdCBnbyB0byBMYXN0 IENhbGwgYWxsIG9mIGEgc3VkZGVuLg0KDQpOb3QgcmVhbGx5LiBUaGUgYXV0aG9ycyBoYWQgc2Fp ZCB3aGF0IHRoZXkgaW50ZW5kZWQgdG8gc2F5LCBubyBvbmUgd2FzIGNvbW1lbnRpbmcsIHRpbWUg Zm9yIFdHTEMuDQoNCkZpcnN0LCBzb21lIG5pdHBpY2tzIGFuZCBjb21tZW50czoNCg0KKiBmcm9t IDEuMi4xPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0 NDQtdXNhZ2UtMDMjc2VjdGlvbi0xLjIuMT4uIFBhY2tldC9NZXNzYWdlIEZvcm1hdDoNCg0KDQog ICAgICBb4oCmXSBhIHBhY2tldA0KDQogICAgICB0cmFuc21pc3Npb24gZm9sbG93aW5nIGEgc3Vj Y2Vzc2Z1bCBwYWNrZXQgcmVjZXB0aW9uIGlzIGJ5IGRlc2lnbg0KDQogICAgICBvZiBhIG5ldyBw YWNrZXQgdGhhdCBtYXkgaW5jbHVkZSBhbGwsIHNvbWUsIG9yIG5vbmUgb2YgdGhlDQoNCiAgICAg IHJlY2VpdmVkIG1lc3NhZ2VzIFsuLi5dDQoNCknigJltIG5vdCBhIG5hdGl2ZSBzcGVha2VyLCBi dXQgdGhhdCDigJ5vZuKAnCBzZWVtcyBvdXQgb2YgcGxhY2UuLi4NCg0KSSBhbSBhIG5hdGl2ZSBz cGVha2VyLCBhbmQgbm8sIGl0J3Mgbm90LiBTb21lIHdvdWxkIHJlcGVhdCBpdCBhZnRlciBlYWNo IG9mIGFsbCwgc29tZSBhbmQgbm9uZSwgYW5kIEkgbWlnaHQgc29tZXRpbWVzLiBCdXQgaXQgcmVh bGx5IGRvZXNuJ3QgbWF0dGVyIHdoaWNoIG9mIHRoZSB0d28gc3R5bGVzIHdlIHBpY2ssIHRoZSBS RkMgRWRpdG9yIG1heSB3ZWxsIGNoYW5nZSB0byB0aGUgb3RoZXIuDQoNCiogUmVnYXJkaW5nIDQu MjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVz YWdlLTAzI3NlY3Rpb24tNC4yPi4gUGFja2V0cyBhbmQgTWVzc2FnZXM6DQp0aGlzIHNlY3Rpb24g dGFsa3MgYSBsb3QgYWJvdXQgaG93IHRoZSBtdWx0aXBsZXhlciBvcGVyYXRlcywgc28gSSB0aGlu ayBpdOKAmWQgYmUgaGVscGZ1bCBpZiBpdHMgdGl0bGUgcmVmbGVjdGVkIHRoYXQuDQoNCkknbSBv ZiB0d28gb3BpbmlvbnMgb24gdGhhdC4gT24gdGhlIG9uZSBoYW5kIGl0IGlzLCBhcyBpdHMgdGl0 bGUgc3VnZ2VzdHMsIGFib3V0IHRoZSBwYWNrZXQgYW5kIG1lc3NhZ2UgbGV2ZWwsIGFzIG9wcG9z ZWQgdG8gbG93ZXIgbGV2ZWxzLCBhbmQgaXRzIHRpdGxlIGNvbnRyYXN0cyB3aXRoIHRoYXQgaWYg NC4zIGZvciB0aGF0IHJlYXNvbi4gT24gdGhlIG90aGVyIGhhbmQgeW91IGFyZSByaWdodCwgaXQg ZG9lcyBoYXZlIG11Y2ggYWJvdXQgdGhlIG11bHRpcGxleGVyLiBBIHRpdGxlIGNvdmVyaW5nIGFs bCB0aHJlZSB3b3VrZCBzdGFydCBnZXR0aW5nIGN1bWJlcnNvbWUuIFdpbGwgdGFrZSB0aGlzIG9u ZSBhd2F5IHRvIHRoaW5rIGFib3V0Lg0KDQoqIGZyb20gNC40PGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi00LjQ+LiBB ZGRyZXNzZXMgUmVxdWlyZSBBdHRyaWJ1dGVzOg0KDQoNCiAgIEFuIHVubW9kaWZpZWQgZXh0ZW5z aW9uIHRvIE5IRFAgd291bGQgaWdub3JlIHN1Y2ggYWRkcmVzc2VzLA0KDQogICBhcyByZXF1aXJl ZCwgYXMgaXQgZG9lcyBub3Qgc3VwcG9ydCB0aGF0IHNwZWNpYWxpemVkIHB1cnBvc2UuDQoNCkF0 IGZpcnN0IGdsYW5jZSwgKHRvIG1lKSB0aGlzIHJlYWRzIGFzIOKAnkFsbCBhZGRyZXNzZXMgdGhh dCBhcmUgYXNzb2NpYXRlZCB3aXRoIGFuIHVua25vd24gVExWIGFyZSBpZ25vcmVk4oCcLCB3aGlj aCBpcyBvYnZpb3VzbHkgbm9uc2Vuc2UgKGJ1dCBxdWl0ZSBwYW5pYy1pbmR1Y2luZyA6RCkuIEni gJlkIHByb3Bvc2UgdG8gcmV3b3JkIGl0IHRvIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YN Cg0KICAgQW4gdW5tb2RpZmllZCBleHRlbnNpb24gdG8gTkhEUCB3b3VsZCBub3QgY29uc2lkZXIg dGhpcw0KDQogICBhZGRyZXNzIHRvIGJlIG9mIGEgbmVpZ2hib3IsIGFzIGl0IGlzIGxhY2tpbmcg YSBMSU5LX1NUQVRVUw0KDQogICBvciBPVEhFUl9ORUlHSEIgVExWLg0KDQpJIHRha2UgeW91ciBw b2ludCwgYnV0IEkgdGhpbmsgdGhhdCBpZiB0aGUgYWRkcmVzcyBlbmRzIHVwIHdpdGggbm8gcmVs ZXZhbnQgYXNzb2NpYXRlZCBUTFZzIHRoZW4gaXQgaXMgaWdub3JlZCBpcyBhbHNvIGEgcG9pbnQu IEkgZGFyZSBzYXkgd2UgY2FuIHdvcmRzbWl0aCBzb21ldGhpbmcuDQoNCkFsc28sIEkgZG9u4oCZ dCBxdWl0ZSBnZXQgd2hlcmUgeW914oCZcmUgZ29pbmcgd2l0aCB0aGUgbGFzdCBwYXJhZ3JhcGgg b2YgdGhhdCBzZWN0aW9uICjigJxUaGVzZSByZXN0cmljdGlvbnMgZG8gbm90LCBob3dldmVyLCBt ZWFuIHRoYXQgYWRkZWQgaW5mb3JtYXRpb24gaXMNCg0KICAgY29tcGxldGVseSBpZ25vcmVkIGZv ciBwdXJwb3NlcyBvZiB0aGUgYmFzZSBwcm90b2NvbC7igJ0pLi4uDQoNClJlYWQgb24sIHRoZSBy ZXN0IG9mIHRoZSBwYXJhZ3JhcGggZGVzY3JpYmVzIHRoZSBjYXNlIHdoZXJlIG5vdC4gQnV0IHdl IG1pZ2h0IHRlbGVncmFwaCB0aGF0IGJldHRlciBpbiB0aGUgb3BlbmluZyBzZW50ZW5jZS4NCg0K KiByZWdhcmRpbmcgdGhlIG1hcHMgaW4gNC41PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi00LjU+LiBJbmZvcm1hdGlv biBSZXByZXNlbnRhdGlvbjoNCknigJltIGFmcmFpZCBJIGp1c3QgZG9u4oCZdCByZWFsbHkgdW5k ZXJzdGFuZCB0aGUgcHVycG9zZSBvZiB0aGlzIHNlY3Rpb24gYW5kIHRoZSBtYXBwaW5nIG5vdGF0 aW9uLiBJ4oCZbSBhc3N1bWluZyB0aGF0IHRoZSBtYXBzIGFyZSBzdXBwb3NlZCB0byBvZmZlciBh IHdheSBvZiBkZXNjcmliaW5nIGhvdyBhIFRMViByZWxhdGVzIHRvIGEgbWVzc2FnZSBvciBhbiBh ZGRyZXNzPw0KSWYgc28sIHdoeSBkb2VzIGl0IG9ubHkgbWVudGlvbiBleHRlbnNpb24gdHlwZXMs IGJ1dCBub3QgdGhlIGJhc2lzIHR5cGVzPw0KDQpJdCBzYXlzIGV4dGVuZGVkIHR5cGVzLCBtZWFu aW5nIHRoZSBjb21iaW5hdGlvbiBvZiB0aGUgdHdvLiBCdXQgZnVsbCB0eXBlIHdvdWxkIGJlIGJl dHRlciwgYXMgYWxtb3N0IGRlZmluZWQgaW4gNTQ0NC4gSW4gZmFjdCBJIHRoaW5rIHdlIHNob3Vs ZCBhZGQgYSBjb21tZW50IHRvIHRoZSBub3RhdGlvbiBzZWN0aW9uLiAoNTQ0NCB1c2VzIGEgc3lt Ym9saWMgbmFtZSByYXRoZXIgdGhhbiB0aGUgcGhyYXNlLikNCg0KT3IgaXMgaXQgc3VwcG9zZWQg dG8gYmUgdXNlZCBzb21ldGhpbmcgbGlrZSB0aGlzOg0KDQpCQVNFX1RMVg0KDQpNZXNzYWdlOg0K KGJhc2VfdGx2X2V4dGVuc2lvbl90eXBlXzEpIC0+ICgyIG9jdGV0cywgInZhbHVlIGEgd2hlbiBj b25kaXRpb24geCBpcyBtZXQiKQ0KKGJhc2VfdGx2X2V4dGVuc2lvbl90eXBlXzIpIC0+ICgyIG9j dGV0cywgInZhbHVlIGIgd2hlbiBjb25kaXRpb24geSBpcyBtZXQiKQ0KDQo/IEFsc28sIEkgZG9u 4oCZdCBxdWl0ZSBnZXQgaG93IHRoaXMgd291bGQgYmUgdXNlZCBpbiBmdXR1cmUgcHJvdG9jb2wg c3BlY2lmaWNhdGlvbnM/IE9yIGFpZCBpbiBpbXBsZW1lbnRpbmcgUkZDNTQ0NCBwYXJzZXJzPw0K QW4gZXhhbXBsZSBvciBhIGNsYXJpZmljYXRpb24gd291bGQgYmUgdmVyeSBoZWxwZnVsLg0KDQpJ dCdzIGEgd2F5IG9mIGxvb2tpbmcgYXQgdGhpbmdzLiBCdXQgbm90IHRoZSBvbmx5IG9uZSwgaXQg Z29lcyBvbiB0byBkaXNjdXNzIHZhcmlhbnRzLiBJIHRoaW5rIGl0IG1vc3RseSBjb21lcyB1bmRl ciBoZWFkaW5nIG9mIGlmIHVzZWZ1bCB1c2UgaXQsIGlmIG5vdCBza2lwIGl0LiBXZSdsbCB0YWtl IGFub3RoZXIgbG9vaywgYnV0IEkgZG9uJ3QgdGhpbmsgdGhpcyB3aWxsIGV2ZXIgYmUgZWxlbWVu dGFyeS4NCg0KKiByZWdhcmRpbmcgNC42PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi00LjY+LiBUTFZzOg0KSW4gZ2Vu ZXJhbCwgaXTigJlzIG5vdCBjbGVhciBldmVyeXdoZXJlIGluIHRoZSBzZWN0aW9uIHdoZXRoZXIg eW914oCZcmUgdGFsa2luZyB0byBSRkM1NDQ0IHBhcnNlci9idWlsZGVyIGltcGxlbWVudG9ycyBv ciBwcm90b2NvbCBkZXNpZ25lcnMuDQoNCg0KICAgQSBwcm90b2NvbCBTSE9VTEQgdXNlIGFuIGVm ZmljaWVudA0KDQogICByZXByZXNlbnRhdGlvbiwgYnV0IHRoaXMgaXMgYSBxdWFsaXR5IG9mIGlt cGxlbWVudGF0aW9uIGlzc3VlLg0KDQpJ4oCZbSBub3Qgc3VyZSB3aGVyZSB5b3XigJlyZSBnb2lu ZyB3aXRoIHRoZSBsYXN0IHBhcnQgb2YgdGhhdCBzZW50ZW5jZT8gSeKAmWQgcmV3b3JkIGl0IHRv IHNvbWV0aGluZyBsaWtlIOKAnkEgcHJvdG9jb2wgU0hPVUxEIHVzZSBhbiBlZmZpY2llbnQgcmVw cmVzZW50YXRpb24sIGF2b2lkaW5nIHVubmVjZXNzYXJpbHkgdmVyYm9zZSB1c2Ugb2YgVExWcyBh bmQgZXh0ZW5zaW9uIHR5cGVzLiBIb3dldmVyLCB0aGUgZmluYWwgYXJyYW5nZW1lbnQgaW4gYSBt ZXNzYWdlLSBvciBhZGRyZXNzVExWIGJsb2NrIGlzICBhIHF1YWxpdHkgb2YgaW1wbGVtZW50YXRp b24gaXNzdWXigJwgKGluIGNhc2UgdGhhdOKAmXMgd2hhdCB5b3UgbWVhbnQpLg0KDQpObywgeW91 J3JlIGNvbnNpZGVyaW5nIHRoZSBwcm90b2NvbCBkZXNpZ24uIFRoaXMgaXMgY29uc2lkZXJpbmcg dGhlIHByb3RvY29sIG9iamVjdCB0aGF0IGltcGxlbWVudHMgdGhlIHByb3RvY29sLiBUaGVyZSBp c24ndCBhIG9uZSB0byBvbmUgbWFwcGluZyBmcm9tIGluZm9ybWF0aW9uIHRvIHJlcHJlc2VudGF0 aW9uLCBpdCdzIHVwIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiB0byBkbyBpdCBlZmZpY2llbnRseS4g RGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyBvZiB0aGUgc2FtZSBwcm90b2NvbCBzcGVjaWZpY2F0 aW9uIG1heSBkbyBiZXR0ZXIgb3Igd29yc2UgaGVyZS4gKFRyaXZpYWwgY2FzZSwgYW4gaW1wbGVt ZW50YXRpb24gY291bGQgY2hvb3NlIHRvIG5ldmVyIGNvbXByZXNzIGFkZHJlc3Nlcy4gQmFkIGlk ZWEsIGJ1dCBsZWdhbC4pDQoNCkFuZCB0aGVuOg0KDQoNCiAgIEENCg0KICAgcHJvdG9jb2wgTVVT VCByZWNvZ25pemUgYW55IHBlcm1pdHRlZCByZXByZXNlbnRhdGlvbiBvZiB0aGUNCg0KICAgaW5m b3JtYXRpb247IGV2ZW4gaWYgaXQgY2hvb3NlcyB0byAoZm9yIGV4YW1wbGUpIG9ubHkgdXNlIG11 bHRpdmFsdWUNCg0KICAgVExWcywgaXQgTVVTVCByZWNvZ25pemUgc2luZ2xlIHZhbHVlIFRMVnMg KGFuZCB2aWNlIHZlcnNhKS4NCg0K4oCmIEkgdGhvdWdodCBwcm90b2NvbHMgd2VyZW7igJl0IHN1 cHBvc2VkIHRvIHNwZWNpZnkgd2hldGhlciBhIFRMViBpcyBhcnJhbmdlZCAoZm9yIGV4YW1wbGUp IGFzIGEgbXVsdGl2YWx1ZSBUTFY/IQ0KDQpJbXBsZW1lbnRhdGlvbiBhZ2Fpbiwgbm90IGRlc2ln bi4NCg0KQW5kIHNvLCBzaW5jZSBhIHByb3RvY29sIHNob3VsZG4ndCBiZSBjb25jZXJuZWQgd2l0 aCBtdWx0aXZhbHVlIFRMVnMgYW5kIHRoZSBsaWtlLCB3b3VsZG7igJl0IGl0IGJlIHRoZSAqUkZD NTQ0NCBpbXBsZW1lbnRhdGlvbiogdGhhdCBNVVNUIHJlY29nbml6ZSBhbnkgcGVybWl0dGVkIHJl cHJlc2VudGF0aW9uPw0KDQpZb3UncmUgYXNzdW1pbmcgdGhhdCB0aGVyZSBpcyBhbiBSRkMgNTQ0 NCBpbXBsZW1lbnRhdGlvbi4gVGhhdCdzIHRoZSBzYW1lIHdheSB0byB3b3JrIGlmIHlvdSBwbGFu IHRvIGltcGxlbWVudCBtb3JlIHRoYW4gb25lIHByb3RvY29sLiBCdXQgbm90aGluZyBzYXlzIHlv dSBoYXZlIHRvIGRvIGl0IHRoYXQgd2F5LiBUaGUgYXJjaGl0ZWN0dXJlIGRlZmluZWQgYnkgNTQ5 OCBhZG1pdHMgb2YgdGhlIG11bHRpcGxleGVyIGFuZCBwcm90b2NvbHMsIGFuZCB0aHVzIHRoZXNl IGFyZSBydWxlcyBvbiB0aGUgcHJvdG9jb2wuIElmIHByb3RvY29scyBkZWxlZ2F0ZSBhbGwgdGhl aXIgY29tbW9uIHdvcmsgdG8gc29tZXRoaW5nIChwYXJzZXIvY3JlYXRvcikgdGhlbiBpdCBpbmhl cml0cyB0aG9zZSByZXN0cmljdGlvbnMsIGJ1dCB0aGF0J3Mgbm90IGRlZmluZWQsIGFuZCB3ZSBj YW4ndCBhc3N1bWUgaXQuDQoNCk9yIGlzIHRoaXMgcGFyYWdyYXBoIHJlYWxseSBqdXN0IGEgY29t cGxpY2F0ZWQgd2F5IG9mIHNheWluZyDigJ5hcyBhIHByb3RvY29sIGRlc2lnbmVyLCBtYWtlIHN1 cmUgdG8gbm90IHNwZWNpZnkvcmVseSBvbiB0aGluZ3MgbGlrZSAoZm9yIGV4YW1wbGUpIG11bHRp dmFsdWUgVExWcywgc2luY2UgeW91ciBtZXNzYWdlcyBoYXZlIHRvIHdvcmsgd2l0aCAqYW55KiBy ZXByZXNlbnRhdGlvbuKAnD8gSWYgc28sIEkgdGhpbmsgdGhhdCBzaG91bGQgYmUgZG9uZSBpbiBh IGxlc3MgY29tcGxpY2F0ZWQgZmFzaGlvbiAoc2VlIGJlbG93KS4NCg0KKiByZWdhcmRpbmcgNTxo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdl LTAzI3NlY3Rpb24tNT4uIFN0cnVjdHVyZToNClNpbmNlIHRoaXMgc2VjdGlvbiB0YWxrcyBhIGxv dCBhYm91dCBmbGFncywgaXTigJlkIGJlIG5pY2UgaWYgaXRzIHRpdGxlIHJlcHJlc2VudGVkIHRo YXQuIE1heWJlIGNvbnNpZGVyIHJlbmFtaW5nIGl0IHRvIOKAnlN0cnVjdHVyZSBhbmQgRmxhZ3Pi gJwgb3Igc28/DQoNCkkgbW9zdGx5IGRvbid0IGFncmVlLiBTdHJ1Y3R1cmUgaXMgdGhlIHN1Ympl Y3QsIGZsYWdzIGFyZSBhIGRldGFpbC4NCg0KKiBmcm9tIDYuMTxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi4xPi4g QWRkcmVzcyBCbG9jayBDb21wcmVzc2lvbjoNCg0KDQogICBDb21wcmVzc2lvbiBvZiBhZGRyZXNz ZXMgaW4gYW4gQWRkcmVzcyBCbG9jayBjb25zaWRlcnMgYWRkcmVzc2VzIHRvDQoNCiAgIGNvbnNp c3Qgb2YgYSBIZWFkLCBhIE1pZCwgYW5kIGEgVGFpbCwgd2hlcmUgYWxsIGFkZHJlc3NlcyBpbiBh bg0KDQogICBBZGRyZXNzIEJsb2NrIGhhdmUgdGhlIHNhbWUgSGVhZCBhbmQgVGFpbCwgYnV0IGRp ZmZlcmVudCBNaWRzLg0KDQoNCknigJlkIGZpbmQgdGhpcyBzZW50ZW5jZSBlYXNpZXIgdG8gcmVh ZCBpZiBpdCBzdGFydGVkIHdpdGgg4oCcQ29tcHJlc3Npb24gb2YgYWRkcmVzc2VzIGluIGFuIEFk ZHJlc3MgQmxvY2sgaXMgcG9zc2libGUgd2hlbiBhZGRyZXNzZXMgY29uc2lzdCBvZiBhIEhlYWQs IGEgTWlkIFvigKZd4oCdLg0KDQpOby4gVGhhdCdzIG1pc3NpbmcgdGhlIHBvaW50IGFuZCBtaXNs ZWFkaW5nLiBBZGRyZXNzZXMgYXJlIGFsd2F5cyBjb25zaWRlcmVkIHRvIGhhdmUgdGhlIGhlYWQv bWlkL3RhaWwgZm9ybWF0LiBDb21wcmVzc2lvbiBpcyBwb3NzaWJsZSBpZiBlaXRoZXIgdGhlIGhl YWQgb3IgdGFpbCAob3IgYm90aCkgaXMgbm9uLWVtcHR5Lg0KDQoqIGZyb20gNi4xPGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2Vj dGlvbi02LjE+LiBBZGRyZXNzIEJsb2NrIENvbXByZXNzaW9uOg0KDQoNCg0KICAgUHV0dGluZyBh ZGRyZXNzZXMgaW50byBhIG1lc3NhZ2UgZWZmaWNpZW50bHkgYWxzbyBoYXMgdG8gaW5jbHVkZToN Cg0KDQpXaHkg4oCeaGFzIHRv4oCcPyBJ4oCZZCB0aGluayB0aGF0IHdvdWxkIGJlIGEg4oCebWF5 4oCcLiBNdWx0aXBsZSBBZHJlc3MgQmxvY2tzIGFuZC9vciByZW9yZGVyaW5nIGRvbuKAmXQgaW5j cmVhc2UgZWZmaWNpZW5jeSBpbiBhbGwgcG9zc2libGUgY2FzZXMuLi4NCg0KSSB0aGluayB0aGF0 J3MgdGhlIHdyb25nIGNoYW5nZS4gUmF0aGVyICJpbmNsdWRlIiBzaG91bGQgYmUgImNvbnNpZGVy Ii4NCg0KKiBmcm9tIDYuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1t YW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi4yPi4gVExWczoNCg0KICAgICAgWy4uLl0g VGhpcyBpcyBldmVuIHBvc3NpYmxlIGlmIHRoZSBNUFIgVExWIHNwZWNpZmllZCBpbg0KDQogICAg ICBPTFNSdjIgW1JGQzcxODE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcxODE+XSBp cyBhZGRlZDsgYnV0IGl0IGlzIG5vdCBwb3NzaWJsZSwgaW4gZ2VuZXJhbCwgaWYNCg0KICAgICAg dGhlIExJTktfTUVUUklDIFRMViBpcyBhbHNvIGFkZGVkLg0KDQpXaHkgaXMgaXQgbm90IHBvc3Np YmxlIGZvciB0aGUgbGF0dGVyPyBJZiB0aGF0IGNvdWxkIGJlIGV4cGxhaW5lZC9oaW50ZWQgYXQg aW4gYSBoYWxmIHNlbnRlbmNlLCBJIHRoaW5rIGl04oCZZCBiZSBoZWxwZnVsIGluZm9ybWF0aW9u IHRvIGhhdmUgaW4gdGhlIGRyYWZ0Lg0KDQpUaGF0J3MgdmVyeSBoYXJkLCBhbmQgbm90IGp1c3Qg YmVjYXVzZSBpdCdzIGEgbmVnYXRpdmUuIEl0J3MgcmVhbGx5IGFuIG9ic2VydmF0aW9uIHRoYXQg bW90aXZhdGVzIHRoZSBkdXNjdXNzaW9uLiBBIGhhbGYgc2VudGVuY2Ugd291bGQgSSB0aGluayBj b25mdXNlIG1vcmUgdGhhbiBpdCBlbmxpZ2h0ZW5zIChpdCdzIGJlY2F1c2UgeW91IGhhdmUgdG9v IG1hbnkgY29uc3RyYWludHMgdG8gc2F0aXNmeSBhdCBvbmNlIC0gSSBkb3VidCB0aGF0IGhlbHBl ZCkuDQoNCg0KICAgICAgSW4gYSB0eXBpY2FsIGNhc2Ugd2hlcmUgYQ0KDQogICAgICBMSU5LX1NU QVRVUyBUTFYgdXNlcyBvbmx5IHRoZSBWYWx1ZXMgSEVBUkQgYW5kIFNZTU1FVFJJQywgd2l0aA0K DQogICAgICBlbm91Z2ggYWRkcmVzc2VzLCBzb3J0ZWQgYXBwcm9wcmlhdGVseSwgdHdvIHNpbmds ZSB2YWx1ZSBUTFZzIGNhbg0KDQogICAgICBiZSBtb3JlIGVmZmljaWVudCB0aGFuIG9uZSBtdWx0 aXZhbHVlIFRMVi4NCg0KU2FtZSB0aGluZzogd2h5Pw0KDQpIZXJlIEkgdGhpbmsgdGhpcyBzaG91 bGQgYmUgb2J2aW91cyB0byBhbnlvbmUgd2hvIGhhcyBsb29rZWQgYXQgNTQ0NC4NCg0KKiByZWdh cmRpbmcgdGhlIHNlY29uZCBwYXJhZ3JhcGggZnJvbSA2LjM8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTYuMz4uIFRM ViBWYWx1ZXMsIGkuZS4NCg0KDQoNCiAgIFRoaXMgYXBwcm9hY2ggd2FzIHNwZWNpZmllZCBpbiBb UkZDNzE4ODxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzE4OD5dLCBhbmQgcmVxdWly ZWQgZm9yIHByb3RvY29scw0KDQogICB0aGF0IGV4dGVuZCBbUkZDNjEzMDxodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNjEzMD5dIGFuZCBbUkZDNzE4MTxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNzE4MT5dLiAgSXQgaXMgaGVyZSBSRUNPTU1FTkRFRCB0aGF0DQoNCiAgIHRo aXMgYXBwcm9hY2ggaXMgZm9sbG93ZWQgd2hlbiBkZWZpbmluZyBhbnkgQWRkcmVzcyBCbG9jayBU TFYgdGhhdA0KDQogICBtYXkgYmUgdXNlZCBieSBhIHByb3RvY29sIHVzaW5nIFtSRkM1NDQ0PGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NDQ0Pl0uDQoNClRoZSB0ZXJtIOKAnnRoaXMg YXBwcm9hY2jigJwgY29uZnVzZWQgbWUsIHNpbmNlIEkgaW5pdGlhbGx5ICB0aG91Z2h0IGl0IG1l YW50IOKAnnRoZSBhcHByb2FjaCBpcyB0byB1c2UgVU5TUEVDSUZJRUQgaW4gYSB3YXkgdGhhdCBt YWtlcyBzZW5zZeKAnCByYXRoZXIgdGhhbiDigJ50aGUgYXBwcm9hY2ggaXMgdG8gdXNlIFVOU1BF Q0lGSUVE4oCcLiBNYXliZSB0aGF0IGNvdWxkIGJlIHJld29yZGVkIHRvIHNvbWV0aGluZyBhbG9u ZyB0aGUgbGluZXMgb2YNClRoZSBVTlNQRUNJRklFRCBUTFYgYW5kIGl0cyB1c2FnZSB3YXMgc3Bl Y2lmaWVkIGluIFtSRkM3MTg4XeKApg0KPw0KDQpOby4gVGhlcmUgaXMgbm8gVU5TUEVDSUZJRUQg VExWLiBUaGVyZSBpcyBhIHJlY29tbWVuZGF0aW9uIHRvIGluY2x1ZGUgYW4gVU5TUEVDSUZJRUQg dmFsdWUgaW4gYSBUTFYuIEJ1dCByZWFsbHksIHdlJ3ZlIGRlc2NyaWJlZCB0aGlzIG9uY2UgaW4g NzE4OCwgaXQncyB0aGVyZSB0byByZWFkLg0KDQoqIHJlZ2FyZGluZyA2LjM8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9u LTYuMz4uIFRMViBWYWx1ZXM6DQpUaGUgc2Vjb25kIHBhcmFncmFwaCBpcyBhIGJpdCBjb25mdXNp bmcgYW5kIHNlZW1zIHRvIGV4cGxhaW5nIHJvZ2hseSB0aGUgc2FtZSB0aGluZ3MgYXMgdGhlIGZv dXJ0aCBwYXJhZ3JhcGhzLiBJ4oCZZCBwcm9wb3NlIHRvIG1lcmdlIHRoZSBzZWNvbmQgaW50byB0 aGUgZm91cnRoLg0KDQpJJ20gbm90IHN1cmUgSSBleGFjdGx5IGFncmVlLCBidXQgdGhlIG9yZGVy aW5nIGluIHRoYXQgc2VjdGlvbiBjb3VsZCBiZSBpbXByb3ZlZC4NCg0KKiBmcm9tIDYuNDxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAz I3NlY3Rpb24tNi40Pi4gQXV0b21hdGlvbjoNCg0KDQogICBUaGUgcG9zc2libGUgZ2FpbiBkZXBl bmRzIG9uIHRoZSBlZmZpY2llbmN5DQoNCiAgIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlIGNyZWF0 aW9uLA0KDQp0aGUgdGVybSDigJ50aGUgb3JpZ2luYWwgbWVzc2FnZSBjcmVhdGlvbuKAnCBzZWVt cyBhIGJpdCBhbWJpZ3VvdXPigJMgZG9lcyB0aGlzIHJlZmVyIHRvIHRoZSBtZXNzYWdlIGFzIGNy ZWF0ZWQgYnkgYW4gUkZDNTQ0NCBtZXNzYWdlIGJ1aWxkZXIgaW1wbGVtZW50YXRpb24/DQoNClll cy4NCg0KQWRkaXRpb25hbGx5LCBJJ20gY29uY2VybmVkIGFib3V0IHR3byB0aGluZ3MgdGhhdCAq YXJlbuKAmXQqIGluIHRoZSBkcmFmdDoNCg0KKiAgU29tZSBvZiB0aGUgQU9EVnYyIGNvLWF1dGhv cnMgYW5kIG1lIGhhdmUgYXNrZWQgZm9yIGEgbGlzdCBvZiDigJ5hcyBhIHByb3RvY29sLCB5b3Ug Y2FuIHNldCBhbGwgb2YgdGhlc2UgZmllbGRzIG9mIGEgbWVzc2FnZSwgYnV0IHBsZWFzZSBsZWF2 ZSB0aGUgcmVzdCBhbG9uZeKAnCwgd2hpY2ggd291bGTigJl2ZSBzYXZlZCB1cyBtYW55IGhvdXJz IG9mIGRpc2N1c3Npb25zIChhbmQgSGVubmluZyBhIGxvdCBvZiB0aW1lIHNwZW50IGV4cGxhaW5p bmcgdGhlc2UgdGhpbmdz4oCmKS4gVGhlc2UgcmVxdWVzdHMgaGF2ZSBiZWVuIG1ldCB3aXRoIGEg cmVmdXNhbCB0byBzcGVjaWZ5IGEgY29uY3JldGUgQVBJLCBhcyBzdWNoIGFuIGVmZm9ydCBpcyBk ZXBlbmRlbnQgb24gb3V0c2lkZSBmYWN0b3JzIHN1Y2ggYXMgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2Ug b3Igc29mdHdhcmUgYXJjaGl0ZWN0dXJlLiBJIGFncmVlIHdpdGggdGhpcyBub3Rpb24sIGJ1dCBh IHByb2dyYW1taW5nLWxhbmd1YWdlIGRlcGVuZGVudCBBUEkgaXMgbm90IHdoYXQgd2XigJl2ZSBh c2tlZCBmb3IuIEnigJl2ZSB0cmllZCB0byBzdXBwbHkgYSBza2V0Y2ggb2Ygd2hhdCBJIGRpZCBh c2sgZm9yIGluIFsxXSwgYnV0IHVuZm9ydHVuYXRlbHkgSSBkaWRu4oCZdCBnZXQgYW4gYW5zd2Vy IChhbmQgYXMgZmFyIGFzIEkgY2FuIHNlZSBpdCwgdGhlIGRyYWZ0IHdhc27igJl0IGNoYW5nZWQg ZWl0aGVyKS4gSSBzdGlsbCB0aGluayB0aGF0IHN1Y2ggYSBsaXN0LCBpbiB3aGF0ZXZlciBmb3Jt LCB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwgZm9yIGZ1dHVyZSBJbnRlcm5ldC1EcmFmdCBhdXRob3Jz IGFuZCBJIGFsc28gdGhpbmsgdGhpcyByZXF1ZXN0IGlzIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUg aW50ZW50aW9ucyBzdGF0ZWQgaW4gMS4xIEhpc3RvcnkgYW5kIFB1cnBvc2UsIGFuZCBJIHRoaW5r IGl0IHNob3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgZG9jdW1lbnQuDQoNCk5vLiBUaGVyZSBhcmUg bWFueSByZWFzb25zIHdoeSB3ZSdyZSBqdXN0IG5vdCB0b3VjaGluZyB0aGlzIG9uZS4NCg0KT25l IGlzIHRoYXQgbGFuZ3VhZ2UgaW5kZXBlbmRlbmNlIGlzIGEgbWlyYWdlLiBIb3cgeW91IGdvIGFi b3V0IHRoaW5ncyBpcyBjb21wbGV0ZWx5IGRpZmZlcmVudCBpbiwgZm9yIGV4YW1wbGUgYW4gb2Jq ZWN0IG9yaWVudGVkIGxhbmd1YWdlIHRoYW4gb25lIHRoYXQgaXNuJ3QuIFNlY3Rpb24gNC41IHNo b3dzIHRoYXQgdGhlcmUgYXJlIHF1aXRlIGRpZmZlcmVudCB3YXlzIG9mIGRvaW5nIHRoaW5ncyBl dmVuIGdpdmVuIGEgZGVjaXNpb24gdG8gdXNlIGEgbWFwIGFwcHJvYWNoLCBhbmQgdGhlcmUgYXJl IG90aGVyIGFwcHJvYWNoZXMgdGhhbiB0aGF0LiBJdCB3b3VsZCBiZSB3cm9uZyBhbmQgYmV5b25k IG91ciBjb21wZXRlbmNlIHRvIHN1Z2dlc3Qgb25lIG9mIHRoZXNlIGFzICJiZXN0Ii4gVGhlcmUn cyByZWFzb25zIHRoZSBJRVRGIGRvZXNuJ3QgZG8gdGhpcywgYW5kIHRoYXQncyBvbmUuDQoNClBs dXMsIGZyYW5rbHksIHRoZSB3b3JrIGl0IHdvdWxkIHRha2UgaXMgYmV5b25kIHdoYXQgd2UgY2hv b3NlIHRvIHNwZW5kLg0KDQoNCjxTcGVha2luZyBhcyBhIFdHIFBhcnRpY2lwYW50Pg0KDQpJJ20g Y29uZnVzZWQgKHdoaWNoIGlzIGFuIGFsdG9nZXRoZXIgdG9vIGNvbW1vbiBvY2N1cnJlbmNlIHRo ZXNlIGRheXMpLiBJIGdldCB0aGF0IHdlIGRvbid0IHdhbnQgdG8gc3BlY2lmeSBhbiBBUEkuIEJ1 dCBJIHRoaW5rIHRoZSBkaXNjdXNzaW9uIGFib3V0IGZpZWxkcyBhIHByb3RvY29sIGNhbiBhbmQg Y2FuJ3QgdG91Y2ggaW4gYSBtZXNzYWdlcyBpcyBhIGdvb2QgdGhpbmcgLSBhbmQgaXQncyBvbmUg c3BvdCB3aGVyZSBJLCB0b28sIGZpbmQgdGhlIGRvY3VtZW50IHdhbnRpbmcuDQoNClRvIHBhcmFw aHJhc2Ugc29tZXRoaW5nIEkndmUgc2FpZCBiZWZvcmUsIEkgYmVsaWV2ZSB0aGF0IFJGQyA1NDQ0 IGNoYW5nZXMgdGhlIHJlbGF0aW9uc2hpcCB0aGF0IGEgcm91dGluZyBwcm90b2NvbCBoYXMgd2l0 aCBhbiAiaW50ZXJmYWNlIi4gSSdtIG5vdCBjb21tZW50aW5nIG9uIHdoZXRoZXIgb3Igbm90IHRo YXQncyBhIGdvb2QgdGhpbmcsIG9yIGEgYmFkIHRoaW5nIC0ganVzdCB0aGF0IGl0IGRvZXMgY2hh bmdlIHRoZSByZWxhdGlvbnNoaXAuIFRoaXMgY2hhbmdlIGhhcyBiZWVuIGF0IHRoZSByb290IG9m IHNvbWUgb2YgdGhlIGxvbmctcnVubmluZyBkaXNjdXNzaW9ucyBhcyB0byB3aGV0aGVyIHByb3Rv Y29scyB1bmRlciBkZXZlbG9wbWVudCB3ZXJlIFJGQyA1NDQ0IGNvbXBsaWFudCBvciBub3QuIFRo ZSBnb2FsIG9mIHRoaXMgZG9jdW1lbnQgYmVpbmcgdG8gZWxpbWluYXRlIChpdCdzIGEgZ29hbCwg cHJvYmFibHkgbm90IHJlYWNoYWJsZSkgdGhvc2UgZGlzY3Vzc2lvbnMsIEknZCBsaWtlIHRvIHNl ZSB0aGF0IGluZm9ybWF0aW9uIGluIHRoZSBkb2N1bWVudCBpbiBzb21lIGZvcm0uDQoNCkknbSBp bnRlcmVzdGVkIGluIHNlZWluZyB0aGlzIGRvY3VtZW50IHByb2dyZXNzLCBhbmQgZXZlbnR1YWxs eSBiZSBwdWJsaXNoZWQuIEkgdGhpbmsgaXQgd2lsbCBoZWxwIGZ1dHVyZSBwcm90b2NvbCBkZXNp Z25lcnMgdG8gYmV0dGVyIHVzZSBSRkMgNTQ0NC4gQnV0IEkgd291bGQgbGlrZSB0byBzZWUgKnNv bWV0aGluZyogYWxvbmcgdGhlIGxpbmVzIG9mIHdoYXQgTG90dGUgaXMgcmVxdWVzdGluZywgYXMg SSB0aGluayBpdCB3aWxsIGltcHJvdmUgdGhlIGRvYy4NCg0KUmVnYXJkcywNClN0YW4NCg0KDQoN CiogQXMgdGhlIGV4YWN0IHJ1bGVzIGZvciB1c2luZy9zZXR0aW5nIHRoZSBob3AgY291bnQgJiBo b3AtbGltaXQgZmllbGRzIGFyZSBjdXJyZW50bHkgYmVpbmcgZGlzY3Vzc2VkIHcvIHJlZ2FyZCB0 byBBT0RWdjIgaW4gYW5vdGhlciB0aHJlYWQgWzJd4oCTIHNob3VsZCBhIGRlZmluaXRpdmUgYW5z d2VyIHRvIHRoYXQgcXVlc3Rpb24gYmUgcGFydCBvZiA1NDQ0LXVzYWdlPw0KDQpZb3UgZG9uJ3Qg d2FudCB0aGF0LiBCZWNhdXNlIGlmIHdlIGRpZCBzcGVjaWZ5IHRoYXQgeW91J2QgZmluZCB5b3Vy c2VsZiBtb3JlIGNvbnN0cmFpbmVkIHRoYW4geW91IHdhbnQgdG8gYmUuIFRoZXJlIGlzIGEgZGVz aWduIGludGVudCBkZXNjcmliZWQgaW4gNTQ0NCwgYnV0IGl0IGFzc3VtZXMgaW1tdXRhYmxlIG1l c3NhZ2VzLiBXaGljaCB5b3UgZG9uJ3Qgd2FudC4gUmVhbGx5LCB3ZSdyZSBkb2luZyB5b3UgYSBm YXZvdXIgYnkgbm90IGltcG9zaW5nIG9uIHlvdS4NCg0KQmVzdCByZWdhcmRzLA0KTG90dGUNCg0K WzFdIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9t c2cxODA4Mi5odG1sDQpbMl0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9t YW5ldC9jdXJyZW50L21zZzE4Njc0Lmh0bWwNCg0KDQpBbSAwNi4wNC4yMDE2IHVtIDE5OjE0IHNj aHJpZWIgSnVzdGluIERlYW4gPGJlYmVtYXN0ZXJAZ21haWwuY29tPG1haWx0bzpiZWJlbWFzdGVy QGdtYWlsLmNvbT4+Og0KDQpUaGUgY2hhaXJzIGFncmVlIHRoYXQgYSAzIHdlZWsgV0dMQyBpcyBh cHByb3ByaWF0ZS4gIEV2ZXJ5b25lIHBsZWFzZSByZWFkIHRoZSBkcmFmdCBlYXJseSBhbmQgZ2V0 IGNvbW1lbnRzIGluIGVhcmx5IHNvIHRoYXQgdGhleSBjYW4gYmUgYWRkcmVzc2VkIHdpdGhpbiB0 aGUgbGFzdCBjYWxsIHBlcmlvZC4NCg0KSnVzdGluDQoNCk9uIFdlZCwgQXByIDYsIDIwMTYgYXQg Nzo0MCBBTSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgPGNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4+IHdyb3RlOg0K T2J2aW91c2x5ICsxIHRvIHRoZSByZXF1ZXN0IGZvciBXR0xDLg0KDQpXaXRoIHJlZ2FyZCB0byB3 aGF0J3MgY2hhbmdlZCwgdGVjaG5pY2FsbHkgdGhlIG9ubHkgc2lnbmlmaWNhbnQgdGhpbmcgaXMg dG8gbWFrZSBpdCBjbGVhciB0aGF0IGlmIGEgcHJvdG9jb2wgZGVsaXZlcnMgYSBtZXNzYWdlIHRv IHRoZSBtdWx0aXBsZXhlciwgdGhlIG11bHRpcGxleGVyIG11c3QgcGFzcyBpdCBvbiB1bmNoYW5n ZWQgdG8gdGhlIHByb3RvY29sIChhbm90aGVyIGluc3RhbmNlIG9mLCBhdCBhbm90aGVyIHJvdXRl cikgdW5jaGFuZ2VkLiBXaXRob3V0IHRoYXQgbm90aGluZyB0aGF0IHRoZSBwcm90b2NvbCBpdHNl bGYgY2hvb3NlcyB0byBkbyB3aXRoIHJlZ2FyZCB0byBzZWN1cml0eSBtYWtlcyBzZW5zZS4gVGhv dWdoIHRoZSBwcm90b2NvbCBjYW4gYWx0ZXJuYXRpdmVseSBsZXQgdGhlIG11bHRpcGxleGVyIGRv IHRoZSBzZWN1cml0eSwgNzE4MiBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gZWl0aGVyIHdheS4gVGhp cyBpc24ndCByZWFsbHkgbmV3LCBidXQgaXQgd2Fzbid0IGZvcm1hbGx5IHNwZWxsZWQgb3V0LiBJ dCdzIHByZXNlbnRlZCBhcyBwYXJ0IG9mIHNwZWxsaW5nIG91dCBtdWx0aXBsZXhlciBydWxlcyBt b3JlIGNhcmVmdWxseS4NCg0KQnV0IHdoYXQgYWJvdXQgbWVzc2FnZSBvcHRpbWlzYXRpb24/IFRo YXQncyBhIGZ1bmN0aW9uIG9mIGNvbnN0cnVjdGluZyBhIDU0NDQgbWVzc2FnZSwgbm90IHRoZSBt dWx0aXBsZXhlciwgYW5kIGlzIGRvd24gdG8gdGhhdCA1NDQ0IGluY2x1ZGVzIHR3byB0aGluZ3Mg LSBwYWNrZXQvbWVzc2FnZSBzdHJ1Y3R1cmUgKGFuZCBpbXBsaWNpdGx5LCBhbmQgaW4gcHJldHR5 IG11Y2ggYW55IGltcGxlbWVudGF0aW9uIEkgd291bGQgZXhwZWN0IHRvIHNlZSwgYSBwYXJzZXIg YW5kIGJ1aWxkZXIgZm9yIHRoYXQgc3RydWN0dXJlKSBhbmQgdGhlIG11bHRpcGxleGVyLiBTbyB3 ZSB0b29rIHRoZSBvcHBvcnR1bml0eSB0byBzZXBhcmF0ZSBvdXQgbW9yZSBjbGVhcmx5IGEgZGlz Y3Vzc2lvbiBvZiB0aGUgdHdvLCB3aGljaCB3ZSB0aGluayB3aWxsIGJlIGhlbHBmdWwuDQoNCi0t DQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQy MTk0PiAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j ZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwg RXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3Rl bXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVn aXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmlj ZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2Yg VWxyaWNoIEhlcmJlcmcNClNlbnQ6IDA1IEFwcmlsIDIwMTYgMjA6MDgNClRvOiBtYW5ldEBpZXRm Lm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbWFuZXRdIFdHTEMgcmVxdWVz dCBmb3IgZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBv cmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBl eHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5 IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1l bnRzIG9yIHJlcGx5Lg0KRm9sbG93IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5r IG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBl bWFpbCBtZXNzYWdlcy4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCioqKiBXQVJOSU5HICoqKg0KRVhURVJOQUwgRU1BSUwgLS0gVGhp cyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb24uDQoNCg0K SGksDQoNCkFzIHlvdSBoYXZlIHNlZW4sIHdlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHJldmlzaW9u IG9mIDU0NDQtdXNhZ2UuIFRoZSBhdXRob3JzIGZlZWwgY29tZm9ydGFibGUgdGhhdCB3ZSBoYXZl IGFkZHJlc3NlZCBhbGwgaXNzdWVzIGJ5IHRoaXMgdmVyc2lvbiwgYW5kIHdvdWxkIGxpa2UgdG8g YXNrIHRoZSBXRyBjaGFpcnMgdG8gaXNzdWUgYSBXR0xDIG9uIHRoaXMgZG9jdW1lbnQuIFdoaWxl IGl0IGlzIGEgZmFpcmx5IHNob3J0IGRvY3VtZW50LCBnaXZlbiB0aGF0IGl0IGlzIElFVEYgd2Vl ayBmb3Igc29tZSwgd2UnZCBzdWdnZXN0IHRoYXQgYSAzLTQgd2VlayBXR0xDIHdvdWxkIGJlIGFw cHJvcHJpYXRlLg0KDQpCZXN0IHJlZ2FyZHMNClVscmljaA0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBp ZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21hbmV0DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkDQpyZWNpcGllbnQgYW5kIG1h eSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KcmVjaXBp ZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5k ZXIuDQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9y IGRpc2Nsb3NlIG9yDQpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29u Lg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0 QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQg bWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1h bmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFp bHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tYW5ldA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD87DGLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1HQjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlVzZSBjYXNlcyBvZiByb3V0aW5nIHByb3RvY29scyBhcmVu 4oCZdCB0aGUgcG9pbnQsIHRoaXMgaXMgYWJvdXQgdGhlIGxheWVyIHRoZXkgdXNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VXNlIGNhc2VzIG9mIHRoYXQsIHdlIGhhdmUgc29tZSB2ZXJ5IGZ1bGx5IHdvcmtlZCBvdXQg ZXhhbXBsZXMgLSBSRkMgNjEzMCwgUkZDIDY2MjEsIFJGQyA3MTgxLCBhbmQsIGlmIHlvdSB3YW50 IGEgcmVhY3RpdmUgZXhhbXBsZSwgd2hhdOKAmXMgcXVvdGVkIGFzIFtHOTkwM10NCiBpbiB0aGUg ZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5CdXQgd2hhdOKAmXMgd2FudGVkIGhlcmUgaXMgb2YgY291cnNlIHRv IHVzZSB0aG9zZSB0byBtYWtlIHNwZWNpZmljIHBvaW50cy4gV2hpY2ggd2UgZG8gaW4gdmFyaW91 cyBwbGFjZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPG86 cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3 RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8 YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8 L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj N0Q3RDdEIj46ICZuYnNwOyYjNDM7NDQgKDApMTI0NSAyNDIxOTQgJm5ic3A7fCAmbmJzcDs8Yj5F Og0KPC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hy aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBD aGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3Nl eCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiPjxz cGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln ZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAw MTMzNzQ1MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz QThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3Jk LCBTdXJyZXksIEdVMiA3WVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWJkdXNzYWxhbSBCYXJ5dW4gW21haWx0bzph YmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxOCBBcHJpbCAy MDE2IDEwOjIxPGJyPg0KPGI+VG86PC9iPiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4N CjxiPkNjOjwvYj4gU3RhbiBSYXRsaWZmOyBDaHJpc3RvcGhlciBEZWFybG92ZTsgQ2hyaXN0b3Bo ZXIgRGVhcmxvdmU7IG1hbmV0QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFu ZXRdIFdHTEMgcmVxdWVzdCBmb3IgZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBw dCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dy b3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4q KiogV0FSTklORyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMg ZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBh cnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVs bHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNo bWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3Jt YXRpb24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ry b25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlv dSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVm PSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9z cG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwvYT4uPC9zcGFuPjwv ZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9s bG93DQo8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29y ay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lv dXMlMjBFbWFpbHMucGRmIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwv aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIENocmlzLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPklNTyB0aGUgdXNlIG9mIDU0NDQgaXMgZm9yIGltcGxlbWVudGF0aW9uIHB1cnBv c2Ugb3IgaW5mb3JtYXRpb24uIFNvLCBJIGFncmVlIHdpdGggU3RhbidzIGNvbW1lbnQsIHRoYXQg dGhpcyBkcmFmdCBpcyBpbXBvcnRhbnQgdG8gcHJvZ3Jlc3MsIGJ1dCB3b3VsZCBuaWNlIHRvIGFk ZCBpbiB0aGUgZHJhZnQgc29tZSBleGFtcGxlcyBvZiB1c2UgY2FzZXMgb2YgT0xTUnYyDQogYW5k IEFPRFZ2MiBib3RoIHJvdXRpbmctcHJvdG9jb2xzLCBvciBleGFtcGxlcyBvZiBpbXBsZW1lbnRh dGlvbi4gVGhpcyB3aWxsIGhlbHAgdGhlIHVzZSBvZiA1NDQ0IGJlY2F1c2UgSSB0aGluayB0aGVz ZSBwcm90b2NvbHMgdXNlIDU0NDQgZGlmZmVyZW50bHkgYmVjYXVzZSB0aGV5IGhhdmUgZGlmZmVy ZW50IHB1cnBvc2VzL2FkdmFudGFnZXMuIFRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QUI8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gTW9uLCBBcHIgMTgsIDIwMTYgYXQgMTA6NTIgQU0sIERlYXJsb3ZlLCBDaHJpc3Rv cGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQg YmVsaWV2ZSB3ZSBjYW4gb3Igc2hvdWxkIHN1Z2dlc3QgYW4gaW1wbGVtZW50YXRpb24uIFRoYXTi gJlzIG5vdCB3aGF0IHRoZSBJRVRGIGRvZXMsIGFuZCBpdA0KIHdvdWxkIGJlIGEgaGFyZCwgcHJv YmFibHkgaW1wb3NzaWJsZSwgc2VsbCwgdG8gdGhlIElFU0cuIFRoYXQgdGhlIG9idmlvdXMgaW1w bGVtZW50YXRpb24gZW1wbG95cyBhbiBpbmRlcGVuZGVudCBwYXJzZXIgaXMgYWxyZWFkeSBzYWlk IC0gaXQgbWF5IGJlIGFwcHJvcHJpYXRlIHRvIHN0cmVuZ3RoZW4gdGhlIHdvcmRzLCBidXQgdGhp cyBzZWNvbmQgSeKAmW0gbm90IHN1cmUgaWYgdGhhdOKAmXMgbmVlZGVkIChub3QgZ290IHRpbWUg dG8gY2hlY2sgY3VycmVudA0KIHdvcmRpbmcpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPC9zcGFuPjwvYj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lw YWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0 b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOzxhIGhyZWY9InRlbDolMkI0NCUyMCUyODAlMjkx MjQ1JTIwMjQyMTk0IiB0YXJnZXQ9Il9ibGFuayI+JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NDwvYT4N CiAmbmJzcDt8ICZuYnNwOzxiPkU6IDwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVA YmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z LmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAw N0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+ QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQ YXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJl Zj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl IExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3 NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNl YXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbWFu ZXQNCiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bWFuZXQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPlN0YW4gUmF0bGlmZjxicj4NCjxiPlNlbnQ6PC9iPiAxNiBBcHJpbCAyMDE2IDE5OjA5PGJy Pg0KPGI+VG86PC9iPiBDaHJpc3RvcGhlciBEZWFybG92ZTxicj4NCjxiPkNjOjwvYj4gPGEgaHJl Zj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8 L2E+OyBDaHJpc3RvcGhlciBEZWFybG92ZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0 XSBXR0xDIHJlcXVlc3QgZm9yIGRyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBw dCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5J TkcgKioqPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl Ij4NCjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNz YWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9t IGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljxicj4NCkNvbnNpZGVyIGNhcmVm dWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRh Y2htZW50cyBvciByZXBseS48YnI+DQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIDwvc3Bhbj48 L2k+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwv c3Bhbj48L2k+PC9iPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+ IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzDQogeW91IHJlY2VpdmUsIGNsaWNr IDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3Nl Y3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiIgdGFyZ2V0PSJfYmxh bmsiPg0KaGVyZTwvYT4uPGJyPg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMs IHBsZWFzZSBmb2xsb3cgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNv bS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGgl MjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0KdGhpcyBwcm9jZXNz PC9hPi48L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjEuMHB0IDQu MHB0IDEuMHB0IDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0 ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KjxiPioqIDwvYj48L3NwYW4+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+V0FSTklORw0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Kioq PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMg ZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBBcHIgMTUsIDIwMTYgYXQgMzoy NyBQTSwgQ2hyaXN0b3BoZXIgRGVhcmxvdmUgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc0BtbmVt b3N5bmUuZGVtb24uY28udWsiIHRhcmdldD0iX2JsYW5rIj5jaHJpc0BtbmVtb3N5bmUuZGVtb24u Y28udWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5JIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbiBieSB0aGUg Y29uY2VwdCBvZiAmcXVvdDtmaWVsZHMgdGhlIHByb3RvY29sIGNhbiBhbmQgY2FuJ3QgdG91Y2gm cXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkNBVkVBVDogSSBhbSBzcGVha2luZyBoZXJlIGFzIGEgV29ya2luZyBHcm91cCBw YXJ0aWNpcGFudC4gV2l0aCB0aGF0IHVuZGVyc3Rvb2Q6DQo8YnI+DQombmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlRUTCBpcyBhIGdyZWF0 IGV4YW1wbGUsIHNpbmNlIHRoYXQgZGlzY3Vzc2lvbiBibGV3IHRoZSBtYWlsaW5nIGxpc3QgdXAg YSBmZXcgbW9udGhzIGFnby4gSSdtICpub3QqIHNheWluZyBtYW5pcHVsYXRpbmcgVFRMIGlzIGEg Z29vZCB0aGluZyBmb3IgYSBwcm90b2NvbCB0byB0cnkgLSBpbiB0cnV0aCwgSSB0aGluayBpdCdz DQogcHJldHR5ICZxdW90O2hhY2t5JnF1b3Q7LiBCdXQgdGhlIG5vdGlvbiB3YXMgZmxvYXRlZCwg YW5kIGluIHRoZSBjb250ZXh0IG9mIHRoYXQgZGlzY3Vzc2lvbiwgaXQgbWF5IHdpbGwgaGF2ZSB3 b3JrZWQuIFRoZSBvcHBvc2l0aW9uIG9uLWxpc3Qgd2FzIGZhc3QsIGFuZCBwcmV0dHkgZm9yY2Vm dWwuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SSd2 ZSBzYWlkIGJlZm9yZSAtIDU0NDQsIGVzcGVjaWFsbHkgd2l0aCB0aGUgbXVsdGlwbGV4ZXIsIGNo YW5nZXMgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGEgcm91dGluZyBwcm90b2NvbCBhbmQgYW4g aW50ZXJmYWNlLiBJIHRoaW5rIHRoZSBkb2N1bWVudCBzaG91bGQgaGF2ZSBzb21lIHR5cGUgb2Yg JnF1b3Q7b3ZlcnZpZXcmcXVvdDsNCiBzZWN0aW9uIHdoaWNoIGRpc2N1c3NlcyB0aGVzZSBkaWZm ZXJlbmNlcywgaW4gb3JkZXIgdG8gZnJhbWUgdGhlIGlzc3VlIGZvciBzb21lb25lIGNvbWluZyBh bG9uZyB3aG8gaGFzbid0IGJlZW4gYSBwYXJ0IG9mIHRoZSA1NDQ0IG1haWwgZGlzY3Vzc2lvbi4N CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5JJ20gdGFs a2luZyBhYm91dCB0aGUgdHlwZSBvZiBvdmVydmlldyB0aGF0IGdvZXMgc29tZXRoaW5nIGxpa2Ug dGhpczoNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4m cXVvdDtVc2Ugb2YgUkZDIDU0NDQgd2l0aCB0aGUgbXVsdGlwbGV4ZXIgZmVhdHVyZSBpbXBvc2Vz IGRlc2lnbiByZXF1aXJlbWVudHMgb24gdGhlIHByb3RvY29sLiBUaGUgYWN0dWFsIHRyYW5zcG9y dCBtZWNoYW5pc20gaXMgYWJzdHJhY3RlZCBmcm9tIHRoZSBwcm90b2NvbC4gRm9yIGV4YW1wbGUs IHJvdXRpbmcgcHJvdG9jb2xzDQogYXJlIG5vdCBhd2FyZSBvZiBwcmVjaXNlbHkgd2hlbiBhIG1l c3NhZ2UgaXMgc2VudC4gQSBnb29kIGV4YW1wbGUgb2Ygb3BlcmF0aW9uIGluIHRoaXMgbW9kZWwg aXMgW0JHUF0sIHV0aWxpemluZyB0aGUgW1RDUF0gdHJhbnNwb3J0LiBUaGlzIGlzIG9wcG9zZWQg dG8gYSBwcm90b2NvbCBzdWNoIGFzIFtPU1BGXSwgd2hpY2ggaXMgY2FwYWJsZSBvZiBzZW5kaW5n IHRyYWZmaWMgd2l0aCBpdHMgb3duIElQIHR5cGUuIFNpbmNlIHRoZSB0cmFuc3BvcnQNCiBpcyBh YnN0cmFjdGVkLCBwcm90b2NvbHMgYXJlIG5vdCBwcmVzZW50ZWQgd2l0aCAmcXVvdDtwYWNrZXRz JnF1b3Q7LCBhbmQgYXJlIG5vdCBjYXBhYmxlIG9mIG1hbmlwdWxhdGluZyBkYXRhIGl0ZW1zIGlu IHBhY2tldCBoZWFkZXJzIChlLmcuIGRhdGEgaXRlbXMgYXQgdGhlIElQIGFuZC9vciBNQUMgbGF5 ZXJzKS4mcXVvdDs8YnI+DQo8YnI+DQpBcyBMb3UgQmVyZ2VyIHB1dCBpdCB0byBtZSBpbiB0aGUg Y29udGV4dCBvZiBETEVQIC0gJnF1b3Q7WW91IHdhbnQgYW4gZW5naW5lZXIgdG8gYmUgYWJsZSB0 byBwaWNrIHVwIHRoaXMgZG9jdW1lbnQsIHdpdGggbm8gcHJpb3IgZXhwb3N1cmUgdG8gdGhlIHRv cGljLCBhbmQgY29kZSBhbiBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9uLiZxdW90OyZuYnNw OyBJIHRoaW5rIHRoaXMgdHlwZSBvZiBhbiBvdmVydmlldywgc2V0dGluZyBiYXNpYyBncm91bmQg cnVsZXMsIHdvdWxkDQogaGVscC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+SSd2ZSBhbHNvIGNvbnRlbmRlZCBmb3IgYSB3aGlsZSBub3cgdGhhdCA1NDQ0 LCB3aXRoIHRoZSBtdXgsIGVmZmVjdGl2ZWx5IGZvcmNlcyBhbiBhcmNoaXRlY3R1cmUgb24gaW1w bGVtZW50ZXJzIC0gaW4gdGhlIExpbnV4IHdvcmxkLCB0aGF0IGFyY2hpdGVjdHVyZSBpcyBhIDU0 NDQgcGFyc2VyIGFzIGFuIGluZGVwZW5kZW50DQogcHJvY2Vzcywgd2l0aCBJUEMgbWVjaGFuaXNt cyB0byB0aGUgcm91dGluZyBwcm90b2NvbChzKSBpdCBpcyBzZXJ2aWNpbmcuIFRoZSA1NDQ0IHBh cnNlciBpdHNlbGYgJnF1b3Q7b3ducyZxdW90OyB0aGUgdHJhbnNwb3J0ICh0aGUgc29ja2V0KS4g VGhlIHVzYWdlIGRvY3VtZW50ICpzdHJvbmdseSBpbmZlcnMqIHRoYXQuIEkgYmVsaWV2ZSB3ZSBz aG91bGQgY29uY3JldGVseSBzdGF0ZSBpdCwgc28gd2UgZG9uJ3QgaGF2ZSB0byBhbnN3ZXIgdGhl IHF1ZXN0aW9uIG92ZXINCiBhbmQgb3ZlciBhZ2Fpbi4gPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlN0YW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGVuIGEgcHJv dG9jb2wgY3JlYXRlcyBhIG1lc3NhZ2UgZnJvbSBzY3JhdGNoIGl0J3Mgbm90IGNvbnN0cmFpbmVk IGluIGFueSB3YXkgSSdkIGRlc2NyaWJlIGluIHN1Y2ggdGVybXMuIFNvIEkgYXNzdW1lIHlvdSBt ZWFuIHdoZW4gaXQgcmVjZWl2ZXMgYSBtZXNzYWdlIGFuZCB0aGVuIHNlbmRzIGEgc2ltaWxhcg0K IG1lc3NhZ2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UaGVyZSBhcmUgdHdvIGNhc2VzIHRoZXJlLiBVbmNoYW5nZWQgKHdpdGggdGhl IHNwZWNpYWwgZXhjZXB0aW9ucyBmb3IgaG9wIGNvdW50IGFuZCBsaW1pdCkgYW5kIG5vdCB1bmNo YW5nZWQuIFRoZSBmb3JtZXIgaXMgYmV0dGVyLCBhbmQgdGhlcmUncyByZWFsbHkgbm90aGluZyBt b3JlIHRvIHNheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlNvIGxldCdzIGNvbnNpZGVyIHRoZSBsYXR0ZXIuIFJlYWxseSBpdCdzIG5v dCB0aGUgc2FtZSBtZXNzYWdlLCBpdCdzIGEgYnJhbmQgbmV3IG1lc3NhZ2UuIFRoYXQncyBhIHVz ZWZ1bCB3YXkgdG8gbG9vayBhdCBpdCBmcm9tIGEgc2VjdXJpdHkgcGVyc3BlY3RpdmUsIGJlY2F1 c2UgaXQgdGVsbHMgeW91IHRoYXQNCiBlbmQgdG8gZW5kIGF1dGhlbnRpY2F0aW9uIGlzbid0IGdv aW5nIHRvIHdvcmsuIEFuZCB3aGF0IGFyZSB0aGUgcmVzdHJpY3Rpb25zIG9uIGJyYW5kIG5ldyBt ZXNzYWdlcz8gVGhlIHNhbWUgYXMgb24gYW55IG5ldyBtZXNzYWdlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T0ssIHlvdSBtaWdodCBz YXksIHRydWUgYnV0IGRvZXMgdGhhdCBtZWFuIEkgY2FuIGFkZCB0aGlzLCByZW1vdmUgdGhhdCwg Y2hhbmdlIHRoZSBob3AgZGF0YT8gWWVzLiBCdXQgaXMgdGhhdCBhIGdvb2QgaWRlYT8gTm8uIEJ1 dCBtYXliZSB5b3UgYXJlIGZvcmNlZCBpbnRvIGl0LiBCdXQgdGhhdCBpdCdzIGluaGVyZW50bHkN CiBub3QgZ29vZCBzdWdnZXN0cyB0aGUgY29yb2xsYXJ5IHRoYXQgaWYgeW91IG11c3QsIGRvIHRo ZSBtaW5pbXVtIGFuZCBtYWtlIGl0IHRyYWNrYWJsZS4gQnV0IHRoYXQncyBub3QgYSA1NDQ0IHJl cXVpcmVtZW50LCBqdXN0IGdvb2QgcHJhY3RpY2UuIEl0IGRvZXMgYnJlYWsgNzE4MiBtZXNzYWdl IElDVnMsIHNvIGRvbid0IHVzZSB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2UgY291bGQsIGh5cG90aGV0aWNhbGx5LCBoYXZl IHNvbWVvbmUgY3JlYXRlIGFuIGV4dGVuc2lvbiBvciBhbHRlcm5hdGl2ZSB0byA3MTgyIHRoYXQg ZGVmaW5lZCBhZ2dyZWdhdGVkIHNpZ25hdHVyZXMuIFRoZW4gd2UnZCBoYXZlIHJ1bGVzIG9uIHdo YXQgeW91IGNvdWxkIGNoYW5nZS4gQnV0IHRoYXQgd291bGQNCiBiZWxvbmcgdGhlcmUuIElmIHlv dSB0aGluayB0aG9zZSB3b3VsZCBiZSBnb29kLCB0aGVuIGFnYWluIHlvdSB3b3VsZCB3YW50IG1h a2UgbWluaW1hbCBjaGFuZ2VzLCBhbmQgbWFpbmx5IG9ubHkgb2YgY2VydGFpbiB0eXBlcy4gV2hh dCB0eXBlcz8gVGhlcmUgSSBjYW4ndCBoZWxwIHlvdSBhcyBJIGRvbid0IGhhdmUgYSBjYW5kaWRh dGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaGUgc3VtbWFyeT8gRG9uJ3QgY2hhbmdlIGlmIHlvdSBkb24ndCBoYXZlIHRvLiBUaGF0 J3MgcmVjb21tZW5kZWQuIElmIHlvdSBtdXN0IGNoYW5nZSB5b3UncmUgb24geW91ciBvd24gKHdp dGggdGhlIHNhbWUgcmVzdHJpY3Rpb25zIGFzIG5ldyBtZXNzYWdlcykuIEFkdmljZSBsaWtlICZx dW90O2FzIGxpdHRsZSBhcw0KIHBvc3NpYmxlJnF1b3Q7IGlzIGdvb2QsIGJ1dCB0aGF0J3Mgbm90 IGFjdHVhbGx5IDU0NDQgYWR2aWNlLiBBbmQgZG9uJ3QgdXNlIDcxODIgbWVzc2FnZSBJQ1ZzLjxi cj4NCjxicj4NCi0tICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0ibWFpbHRvOmNocmlzdG9waGVyLmRl YXJsb3ZlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdG9waGVyLmRlYXJsb3ZlQGdt YWlsLmNvbTwvYT4gKGlQaG9uZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0ibWFpbHRvOmNocmlzQG1uZW1vc3luZS5kZW1vbi5j by51ayIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51azwvYT4gKGhv bWUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KT24gMTUgQXByIDIwMTYsIGF0IDE5OjM3LCBTdGFuIFJhdGxpZmYgJmx0OzxhIGhy ZWY9Im1haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5yYXRsaWZm c3RhbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TXkgbWFpbiBjb25jZXJuIGFkZHJl c3NlZCBpbmxpbmUuLi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBG cmksIEFwciAxNSwgMjAxNiBhdCAxOjQ5IFBNLCBDaHJpc3RvcGhlciBEZWFybG92ZSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkEgZmV3IGltbWVk aWF0ZSBjb21tZW50cyBpbmxpbmUgYmVsb3cuPGJyPg0KPGJyPg0KLS0gJm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaHJpc3RvcGhlciBEZWFybG92 ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 YSBocmVmPSJtYWlsdG86Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tPC9hPiAoaVBob25lKTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJt YWlsdG86Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXNA bW5lbW9zeW5lLmRlbW9uLmNvLnVrPC9hPiAoaG9tZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAxNSBBcHIgMjAxNiwgYXQg MTU6MTgsIExvdHRlIFN0ZWVuYnJpbmsgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3R0ZS5zdGVlbmJy aW5rQGZ1LWJlcmxpbi5kZSIgdGFyZ2V0PSJfYmxhbmsiPmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVy bGluLmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5zcGFya2VkIGJ5IHRoZSByZWNlbnRseSBzdGFydGVkIFdHTEMsIEnigJl2 ZSByZXZpZXdlZCB0aGUgY3VycmVudCByZXZpc2lvbiBvZiB0aGUgZHJhZnQuIEnigJlkIGxpa2Ug dG8gb2ZmZXIgdGhlIHdvcmtpbmcgZ3JvdXAgbXkgcGVyc3BlY3RpdmUgYXMgc29tZW9uZSB3aG8g ZG9lc27igJl0IGhhdmUgZGVjYWRlcyBvZg0KIHByb3RvY29sIGFuZC9vciBwYWNrZXQgZm9ybWF0 IGRlc2lnbiB1bmRlciB0aGVpciBiZWx0IChpLmUuIHNvbWUgdGhpbmdzIG1pZ2h0IG5vdCBiZSBv YnZpb3VzIHRvIG1lIHRoYXQgYXJlIG9idmlvdXMgdG8gb3RoZXJzKSwgYnV0IGFsc28gYXMgc29t ZW9uZSB3aG8gaGFzIHdvcmtlZCB3aXRoIFJGQyA1NDQ0IHdoZW4gaW1wbGVtZW50aW5nIGEgcm91 dGluZyBwcm90b2NvbCAoQU9EVnYyKSwgdXBkYXRpbmcgdGhlIHBhY2tldCBmb3JtYXQgb2YgYQ0K IHJvdXRpbmcgcHJvdG9jb2wgKEFPRFZ2MiBhZ2FpbikgYW5kIChwYXJ0aWFsbHkpIGltcGxlbWVu dGluZyBteSBvd24gUkZDNTQ0NCBidWlsZGVyL3BhcnNlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk92ZXJhbGwsIEkgdGhpbmsgdGhl IGRvY3VtZW50IGlzIGVhc3kgdG8gcmVhZCBhbmQgZm9sbG93LiBUbyBtZSwgaXQgY29udGFpbnMg dmFsdWFibGUgaW5mb3JtYXRpb24gYW5kIGd1aWRhbmNlIGFuZCBpbiBzb21lIGNhc2VzIHByZXZl bnRzIHBlb3BsZSBmcm9tIHNob290aW5nIHRoZW1zZWx2ZXMgaW4gdGhlDQogZm9vdC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SeKAmW0gcmVh bGx5IGhhcHB5IHRoaXMgZG9jdW1lbnQgZXhpc3RzIGFuZCBJ4oCZZCBsaWtlIGl0IHRvIG1vdmUg Zm9yd2FyZCBzb29uLCBidXQgSSBkbyBmZWVsIHRoYXQgaXQgaXMgc3RpbGwgbGFja2luZyBpbiBz b21lIGFyZWFzLCB3aGljaCBpcyB3aHkgSSB3YXMgYSBiaXQgc3VycHJpc2VkIHRvIHNlZSBpdCBn bw0KIHRvIExhc3QgQ2FsbCBhbGwgb2YgYSBzdWRkZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Tm90IHJlYWxseS4gVGhlIGF1dGhvcnMgaGFkIHNhaWQgd2hhdCB0aGV5IGludGVu ZGVkIHRvIHNheSwgbm8gb25lIHdhcyBjb21tZW50aW5nLCB0aW1lIGZvciBXR0xDLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkZpcnN0LCBzb21lIG5pdHBpY2tzIGFuZCBjb21tZW50czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiogZnJvbSZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNh Z2UtMDMjc2VjdGlvbi0xLjIuMSIgdGFyZ2V0PSJfYmxhbmsiPjxiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+MS4yLjE8L3NwYW4+PC9iPjwvYT48Yj4uDQog UGFja2V0L01lc3NhZ2UgRm9ybWF0PC9iPjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtb4oCmXSBhIHBhY2tldDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0cmFu c21pc3Npb24gZm9sbG93aW5nIGEgc3VjY2Vzc2Z1bCBwYWNrZXQgcmVjZXB0aW9uIGlzIGJ5IGRl c2lnbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBvZiBhIG5ldyBwYWNrZXQgdGhhdCBtYXkgaW5jbHVkZSBhbGwsIHNvbWUsIG9yIG5vbmUgb2Yg dGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHJlY2VpdmVkIG1lc3NhZ2VzIFsuLi5dPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J4oCZbSBub3QgYSBuYXRpdmUgc3Bl YWtlciwgYnV0IHRoYXQg4oCeb2bigJwgc2VlbXMgb3V0IG9mIHBsYWNlLi4uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkkgYW0gYSBuYXRpdmUgc3BlYWtlciwgYW5kIG5vLCBpdCdzIG5vdC4gU29tZSB3b3Vs ZCByZXBlYXQgaXQgYWZ0ZXIgZWFjaCBvZiBhbGwsIHNvbWUgYW5kIG5vbmUsIGFuZCBJIG1pZ2h0 IHNvbWV0aW1lcy4gQnV0IGl0IHJlYWxseSBkb2Vzbid0IG1hdHRlciB3aGljaCBvZiB0aGUgdHdv IHN0eWxlcyB3ZSBwaWNrLA0KIHRoZSBSRkMgRWRpdG9yIG1heSB3ZWxsIGNoYW5nZSB0byB0aGUg b3RoZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4qIFJlZ2FyZGluZyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi00LjIiIHRhcmdl dD0iX2JsYW5rIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPjQuMjwvc3Bhbj48L2I+PC9hPjxiPi4NCiBQYWNrZXRzIGFuZCBNZXNzYWdlczo8L2I+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoaXMg c2VjdGlvbiB0YWxrcyBhIGxvdCBhYm91dCBob3cgdGhlIG11bHRpcGxleGVyIG9wZXJhdGVzLCBz byBJIHRoaW5rIGl04oCZZCBiZSBoZWxwZnVsIGlmIGl0cyB0aXRsZSByZWZsZWN0ZWQgdGhhdC4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkknbSBvZiB0d28gb3BpbmlvbnMgb24gdGhhdC4gT24gdGhlIG9uZSBo YW5kIGl0IGlzLCBhcyBpdHMgdGl0bGUgc3VnZ2VzdHMsIGFib3V0IHRoZSBwYWNrZXQgYW5kIG1l c3NhZ2UgbGV2ZWwsIGFzIG9wcG9zZWQgdG8gbG93ZXIgbGV2ZWxzLCBhbmQgaXRzIHRpdGxlIGNv bnRyYXN0cyB3aXRoIHRoYXQgaWYgNC4zDQogZm9yIHRoYXQgcmVhc29uLiBPbiB0aGUgb3RoZXIg aGFuZCB5b3UgYXJlIHJpZ2h0LCBpdCBkb2VzIGhhdmUgbXVjaCBhYm91dCB0aGUgbXVsdGlwbGV4 ZXIuIEEgdGl0bGUgY292ZXJpbmcgYWxsIHRocmVlIHdvdWtkIHN0YXJ0IGdldHRpbmcgY3VtYmVy c29tZS4gV2lsbCB0YWtlIHRoaXMgb25lIGF3YXkgdG8gdGhpbmsgYWJvdXQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIGZyb20mbmJz cDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1y ZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNC40IiB0YXJnZXQ9Il9ibGFuayI+PGI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj40LjQ8L3NwYW4+PC9iPjwvYT48 Yj4uDQogQWRkcmVzc2VzIFJlcXVpcmUgQXR0cmlidXRlczo8L2I+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgQW4gdW5tb2RpZmllZCBleHRlbnNp b24gdG8gTkhEUCB3b3VsZCBpZ25vcmUgc3VjaCBhZGRyZXNzZXMsPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IGFzIHJlcXVpcmVkLCBhcyBpdCBkb2VzIG5vdCBzdXBwb3J0IHRo YXQgc3BlY2lhbGl6ZWQgcHVycG9zZS48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXQgZmlyc3QgZ2xhbmNlLCAodG8gbWUpIHRoaXMg cmVhZHMgYXMg4oCeQWxsIGFkZHJlc3NlcyB0aGF0IGFyZSBhc3NvY2lhdGVkIHdpdGggYW4gdW5r bm93biBUTFYgYXJlIGlnbm9yZWTigJwsIHdoaWNoIGlzIG9idmlvdXNseSBub25zZW5zZSAoYnV0 IHF1aXRlIHBhbmljLWluZHVjaW5nIDpEKS4gSeKAmWQgcHJvcG9zZQ0KIHRvIHJld29yZCBpdCB0 byBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cHJlPiZuYnNwOyZuYnNwOyBBbiB1bm1vZGlmaWVkIGV4dGVuc2lvbiB0byBO SERQIHdvdWxkIG5vdCBjb25zaWRlciB0aGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IGFkZHJlc3MgdG8gYmUgb2YgYSBuZWlnaGJvciwgYXMgaXQgaXMgbGFja2luZyBhIExJ TktfU1RBVFVTPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG9yIE9USEVSX05F SUdIQiBUTFYuPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGFrZSB5b3VyIHBvaW50LCBidXQgSSB0aGluayB0aGF0 IGlmIHRoZSBhZGRyZXNzIGVuZHMgdXAgd2l0aCBubyByZWxldmFudCBhc3NvY2lhdGVkIFRMVnMg dGhlbiBpdCBpcyBpZ25vcmVkIGlzIGFsc28gYSBwb2ludC4gSSBkYXJlIHNheSB3ZSBjYW4gd29y ZHNtaXRoIHNvbWV0aGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+QWxzbywgSSBkb27igJl0IHF1aXRlIGdldCB3aGVyZSB5b3XigJlyZSBnb2lu ZyB3aXRoIHRoZSBsYXN0IHBhcmFncmFwaCBvZiB0aGF0IHNlY3Rpb24gKOKAnDxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij5UaGVzZSByZXN0cmljdGlvbnMgZG8gbm90LCBob3dldmVyLCBt ZWFuIHRoYXQgYWRkZWQgaW5mb3JtYXRpb24NCiBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgY29tcGxldGVseSBpZ25vcmVkIGZvciBwdXJwb3NlcyBv ZiB0aGUgYmFzZSBwcm90b2NvbC7igJ0pLi4uPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVhZCBvbiwgdGhlIHJlc3Qgb2YgdGhlIHBhcmFncmFw aCBkZXNjcmliZXMgdGhlIGNhc2Ugd2hlcmUgbm90LiBCdXQgd2UgbWlnaHQgdGVsZWdyYXBoIHRo YXQgYmV0dGVyIGluIHRoZSBvcGVuaW5nIHNlbnRlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIHJlZ2FyZGluZyB0aGUgbWFwcyBpbiZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJm YzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi00LjUiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjQuNTwvc3Bhbj48L2I+PC9hPjxi Pi4NCiBJbmZvcm1hdGlvbiBSZXByZXNlbnRhdGlvbjo8L2I+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJltIGFmcmFpZCBJIGp1c3QgZG9u 4oCZdCByZWFsbHkgdW5kZXJzdGFuZCB0aGUgcHVycG9zZSBvZiB0aGlzIHNlY3Rpb24gYW5kIHRo ZSBtYXBwaW5nIG5vdGF0aW9uLiBJ4oCZbSBhc3N1bWluZyB0aGF0IHRoZSBtYXBzIGFyZSBzdXBw b3NlZCB0byBvZmZlciBhIHdheSBvZiBkZXNjcmliaW5nIGhvdyBhIFRMViByZWxhdGVzDQogdG8g YSBtZXNzYWdlIG9yIGFuIGFkZHJlc3M/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHNvLCB3aHkgZG9lcyBpdCBvbmx5IG1lbnRp b24gZXh0ZW5zaW9uIHR5cGVzLCBidXQgbm90IHRoZSBiYXNpcyB0eXBlcz88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBzYXlzIGV4 dGVuZGVkIHR5cGVzLCBtZWFuaW5nIHRoZSBjb21iaW5hdGlvbiBvZiB0aGUgdHdvLiBCdXQgZnVs bCB0eXBlIHdvdWxkIGJlIGJldHRlciwgYXMgYWxtb3N0IGRlZmluZWQgaW4gNTQ0NC4gSW4gZmFj dCBJIHRoaW5rIHdlIHNob3VsZCBhZGQgYSBjb21tZW50IHRvIHRoZSBub3RhdGlvbiBzZWN0aW9u Lg0KICg1NDQ0IHVzZXMgYSBzeW1ib2xpYyBuYW1lIHJhdGhlciB0aGFuIHRoZSBwaHJhc2UuKTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PciBpcyBp dCBzdXBwb3NlZCB0byBiZSB1c2VkIHNvbWV0aGluZyBsaWtlIHRoaXM6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q291cmllciI+QkFTRV9UTFY8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNvdXJpZXIiPk1lc3NhZ2U6Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q291cmllciI+KGJhc2VfdGx2X2V4dGVuc2lvbl90eXBlXzEpIC0mZ3Q7ICgyIG9j dGV0cywgJnF1b3Q7dmFsdWUgYSB3aGVuIGNvbmRpdGlvbiB4IGlzIG1ldCZxdW90Oyk8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4oYmFzZV90bHZfZXh0ZW5zaW9uX3R5cGVf MikgLSZndDsgKDIgb2N0ZXRzLCAmcXVvdDt2YWx1ZSBiIHdoZW4gY29uZGl0aW9uIHkgaXMgbWV0 JnF1b3Q7KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPj8gQWxzbywgSSBkb27igJl0IHF1aXRlIGdldCBob3cgdGhpcyB3b3Vs ZCBiZSB1c2VkIGluIGZ1dHVyZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucz8gT3IgYWlkIGluIGlt cGxlbWVudGluZyBSRkM1NDQ0IHBhcnNlcnM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuIGV4YW1wbGUgb3IgYSBjbGFyaWZpY2F0aW9uIHdv dWxkIGJlIHZlcnkgaGVscGZ1bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCdzIGEgd2F5IG9mIGxvb2tpbmcgYXQgdGhpbmdzLiBC dXQgbm90IHRoZSBvbmx5IG9uZSwgaXQgZ29lcyBvbiB0byBkaXNjdXNzIHZhcmlhbnRzLiBJIHRo aW5rIGl0IG1vc3RseSBjb21lcyB1bmRlciBoZWFkaW5nIG9mIGlmIHVzZWZ1bCB1c2UgaXQsIGlm IG5vdCBza2lwIGl0LiBXZSdsbCB0YWtlIGFub3RoZXINCiBsb29rLCBidXQgSSBkb24ndCB0aGlu ayB0aGlzIHdpbGwgZXZlciBiZSBlbGVtZW50YXJ5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIHJlZ2FyZGluZyZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMj c2VjdGlvbi00LjYiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjQuNjwvc3Bhbj48L2I+PC9hPjxiPi4NCiBUTFZzOjwvYj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4g Z2VuZXJhbCwgaXTigJlzIG5vdCBjbGVhciBldmVyeXdoZXJlIGluIHRoZSBzZWN0aW9uIHdoZXRo ZXIgeW914oCZcmUgdGFsa2luZyB0byBSRkM1NDQ0IHBhcnNlci9idWlsZGVyIGltcGxlbWVudG9y cyBvciBwcm90b2NvbCBkZXNpZ25lcnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgQSBwcm90b2NvbCBTSE9VTEQgdXNlIGFuIGVmZmlj aWVudDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyByZXByZXNlbnRhdGlvbiwg YnV0IHRoaXMgaXMgYSBxdWFsaXR5IG9mIGltcGxlbWVudGF0aW9uIGlzc3VlLjxvOnA+PC9vOnA+ PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SeKAmW0gbm90IHN1cmUg d2hlcmUgeW914oCZcmUgZ29pbmcgd2l0aCB0aGUgbGFzdCBwYXJ0IG9mIHRoYXQgc2VudGVuY2U/ IEnigJlkIHJld29yZCBpdCB0byBzb21ldGhpbmcgbGlrZSDigJ5BIHByb3RvY29sIFNIT1VMRCB1 c2UgYW4gZWZmaWNpZW50IHJlcHJlc2VudGF0aW9uLCBhdm9pZGluZyB1bm5lY2Vzc2FyaWx5IHZl cmJvc2UNCiB1c2Ugb2YgVExWcyBhbmQgZXh0ZW5zaW9uIHR5cGVzLiBIb3dldmVyLCB0aGUgZmlu YWwgYXJyYW5nZW1lbnQgaW4gYSBtZXNzYWdlLSBvciBhZGRyZXNzVExWIGJsb2NrIGlzICZuYnNw O2EgcXVhbGl0eSBvZiBpbXBsZW1lbnRhdGlvbiBpc3N1ZeKAnCAoaW4gY2FzZSB0aGF04oCZcyB3 aGF0IHlvdSBtZWFudCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ObywgeW91J3JlIGNvbnNpZGVyaW5nIHRoZSBwcm90 b2NvbCBkZXNpZ24uIFRoaXMgaXMgY29uc2lkZXJpbmcgdGhlIHByb3RvY29sIG9iamVjdCB0aGF0 IGltcGxlbWVudHMgdGhlIHByb3RvY29sLiBUaGVyZSBpc24ndCBhIG9uZSB0byBvbmUgbWFwcGlu ZyBmcm9tIGluZm9ybWF0aW9uIHRvIHJlcHJlc2VudGF0aW9uLA0KIGl0J3MgdXAgdG8gdGhlIGlt cGxlbWVudGF0aW9uIHRvIGRvIGl0IGVmZmljaWVudGx5LiBEaWZmZXJlbnQgaW1wbGVtZW50YXRp b25zIG9mIHRoZSBzYW1lIHByb3RvY29sIHNwZWNpZmljYXRpb24gbWF5IGRvIGJldHRlciBvciB3 b3JzZSBoZXJlLiAoVHJpdmlhbCBjYXNlLCBhbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBjaG9vc2Ug dG8gbmV2ZXIgY29tcHJlc3MgYWRkcmVzc2VzLiBCYWQgaWRlYSwgYnV0IGxlZ2FsLik8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5kIHRoZW46PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgQTxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBwcm90b2NvbCBNVVNUIHJlY29nbml6ZSBh bnkgcGVybWl0dGVkIHJlcHJlc2VudGF0aW9uIG9mIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBpbmZvcm1hdGlvbjsgZXZlbiBpZiBpdCBjaG9vc2VzIHRvIChmb3IgZXhh bXBsZSkgb25seSB1c2UgbXVsdGl2YWx1ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBUTFZzLCBpdCBNVVNUIHJlY29nbml6ZSBzaW5nbGUgdmFsdWUgVExWcyAoYW5kIHZpY2Ug dmVyc2EpLjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+4oCmIEkgdGhvdWdodCBwcm90b2NvbHMgd2VyZW7igJl0IHN1cHBvc2VkIHRvIHNwZWNpZnkg d2hldGhlciBhIFRMViBpcyBhcnJhbmdlZCAoZm9yIGV4YW1wbGUpIGFzIGEgbXVsdGl2YWx1ZSBU TFY/ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SW1wbGVtZW50YXRpb24gYWdhaW4sIG5vdCBkZXNpZ24uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmQgc28s IHNpbmNlIGEgcHJvdG9jb2wgc2hvdWxkbid0IGJlIGNvbmNlcm5lZCB3aXRoIG11bHRpdmFsdWUg VExWcyBhbmQgdGhlIGxpa2UsIHdvdWxkbuKAmXQgaXQgYmUgdGhlICpSRkM1NDQ0IGltcGxlbWVu dGF0aW9uKiB0aGF0IE1VU1QgcmVjb2duaXplIGFueSBwZXJtaXR0ZWQgcmVwcmVzZW50YXRpb24/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+WW91J3JlIGFzc3VtaW5nIHRoYXQgdGhlcmUgaXMgYW4gUkZDIDU0 NDQgaW1wbGVtZW50YXRpb24uIFRoYXQncyB0aGUgc2FtZSB3YXkgdG8gd29yayBpZiB5b3UgcGxh biB0byBpbXBsZW1lbnQgbW9yZSB0aGFuIG9uZSBwcm90b2NvbC4gQnV0IG5vdGhpbmcgc2F5cyB5 b3UgaGF2ZSB0byBkbyBpdCB0aGF0IHdheS4NCiBUaGUgYXJjaGl0ZWN0dXJlIGRlZmluZWQgYnkg NTQ5OCBhZG1pdHMgb2YgdGhlIG11bHRpcGxleGVyIGFuZCBwcm90b2NvbHMsIGFuZCB0aHVzIHRo ZXNlIGFyZSBydWxlcyBvbiB0aGUgcHJvdG9jb2wuIElmIHByb3RvY29scyBkZWxlZ2F0ZSBhbGwg dGhlaXIgY29tbW9uIHdvcmsgdG8gc29tZXRoaW5nIChwYXJzZXIvY3JlYXRvcikgdGhlbiBpdCBp bmhlcml0cyB0aG9zZSByZXN0cmljdGlvbnMsIGJ1dCB0aGF0J3Mgbm90IGRlZmluZWQsIGFuZCB3 ZQ0KIGNhbid0IGFzc3VtZSBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+T3IgaXMgdGhpcyBwYXJhZ3JhcGggcmVhbGx5IGp1c3QgYSBjb21wbGlj YXRlZCB3YXkgb2Ygc2F5aW5nIOKAnmFzIGEgcHJvdG9jb2wgZGVzaWduZXIsIG1ha2Ugc3VyZSB0 byBub3Qgc3BlY2lmeS9yZWx5IG9uIHRoaW5ncyBsaWtlIChmb3IgZXhhbXBsZSkgbXVsdGl2YWx1 ZSBUTFZzLCBzaW5jZSB5b3VyIG1lc3NhZ2VzDQogaGF2ZSB0byB3b3JrIHdpdGggKmFueSogcmVw cmVzZW50YXRpb27igJw/IElmIHNvLCBJIHRoaW5rIHRoYXQgc2hvdWxkIGJlIGRvbmUgaW4gYSBs ZXNzIGNvbXBsaWNhdGVkIGZhc2hpb24gKHNlZSBiZWxvdykuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiogcmVnYXJkaW5n Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFu ZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTUiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjU8L3NwYW4+PC9iPjwvYT48 Yj4uDQogU3RydWN0dXJlOjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+U2luY2UgdGhpcyBzZWN0aW9uIHRhbGtzIGEgbG90IGFib3V0IGZs YWdzLCBpdOKAmWQgYmUgbmljZSBpZiBpdHMgdGl0bGUgcmVwcmVzZW50ZWQgdGhhdC4gTWF5YmUg Y29uc2lkZXIgcmVuYW1pbmcgaXQgdG8mbmJzcDvigJ5TdHJ1Y3R1cmUgYW5kIEZsYWdz4oCcJm5i c3A7b3Igc28/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SSBtb3N0bHkgZG9uJ3QgYWdyZWUuIFN0cnVjdHVyZSBpcyB0aGUgc3ViamVj dCwgZmxhZ3MgYXJlIGEgZGV0YWlsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4qIGZyb20mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi4xIiB0 YXJnZXQ9Il9ibGFuayI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlv bjpub25lIj42LjE8L3NwYW4+PC9iPjwvYT48Yj4uDQogQWRkcmVzcyBCbG9jayBDb21wcmVzc2lv bjo8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJz cDsgQ29tcHJlc3Npb24gb2YgYWRkcmVzc2VzIGluIGFuIEFkZHJlc3MgQmxvY2sgY29uc2lkZXJz IGFkZHJlc3NlcyB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjb25zaXN0 IG9mIGEgSGVhZCwgYSBNaWQsIGFuZCBhIFRhaWwsIHdoZXJlIGFsbCBhZGRyZXNzZXMgaW4gYW48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgQWRkcmVzcyBCbG9jayBoYXZlIHRo ZSBzYW1lIEhlYWQgYW5kIFRhaWwsIGJ1dCBkaWZmZXJlbnQgTWlkcy48bzpwPjwvbzpwPjwvcHJl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJlkIGZp bmQgdGhpcyBzZW50ZW5jZSBlYXNpZXIgdG8gcmVhZCBpZiBpdCBzdGFydGVkIHdpdGgg4oCcQ29t cHJlc3Npb24gb2YgYWRkcmVzc2VzIGluIGFuIEFkZHJlc3MgQmxvY2sgaXMgcG9zc2libGUgd2hl biBhZGRyZXNzZXMgY29uc2lzdCBvZiBhIEhlYWQsIGEgTWlkIFvigKZd4oCdLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vLiBUaGF0 J3MgbWlzc2luZyB0aGUgcG9pbnQgYW5kIG1pc2xlYWRpbmcuIEFkZHJlc3NlcyBhcmUgYWx3YXlz IGNvbnNpZGVyZWQgdG8gaGF2ZSB0aGUgaGVhZC9taWQvdGFpbCBmb3JtYXQuIENvbXByZXNzaW9u IGlzIHBvc3NpYmxlIGlmIGVpdGhlciB0aGUgaGVhZCBvciB0YWlsIChvciBib3RoKSBpcyBub24t ZW1wdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiogZnJvbSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi02LjEiIHRhcmdldD0iX2JsYW5rIj48 Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjYuMTwvc3Bh bj48L2I+PC9hPjxiPi4NCiBBZGRyZXNzIEJsb2NrIENvbXByZXNzaW9uOjwvYj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IFB1dHRpbmcgYWRkcmVzc2VzIGludG8gYSBtZXNzYWdlIGVmZmljaWVudGx5 IGFsc28gaGFzIHRvIGluY2x1ZGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48 L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2h5IOKA nmhhcyB0b+KAnD8gSeKAmWQgdGhpbmsgdGhhdCB3b3VsZCBiZSBhIOKAnm1heeKAnC4gTXVsdGlw bGUgQWRyZXNzIEJsb2NrcyBhbmQvb3IgcmVvcmRlcmluZyBkb27igJl0IGluY3JlYXNlIGVmZmlj aWVuY3kgaW4gYWxsIHBvc3NpYmxlIGNhc2VzLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB0aGF0J3MgdGhlIHdyb25n IGNoYW5nZS4gUmF0aGVyICZxdW90O2luY2x1ZGUmcXVvdDsgc2hvdWxkIGJlICZxdW90O2NvbnNp ZGVyJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4qIGZyb20mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi4yIiB0YXJnZXQ9Il9ibGFu ayI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj42LjI8 L3NwYW4+PC9iPjwvYT48Yj4uDQogVExWczo8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbLi4uXSBUaGlzIGlzIGV2 ZW4gcG9zc2libGUgaWYgdGhlIE1QUiBUTFYgc3BlY2lmaWVkIGluPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9MU1J2MiBbPGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcxODEiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0i JnF1b3Q7VGhlIE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgUHJvdG9jb2wgdmVyc2lvbiAy JnF1b3Q7Ij5SRkM3MTgxPC9hPl0gaXMgYWRkZWQ7IGJ1dCBpdCBpcyBub3QgcG9zc2libGUsIGlu IGdlbmVyYWwsIGlmPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHRoZSBMSU5LX01FVFJJQyBUTFYgaXMgYWxzbyBhZGRlZC48bzpwPjwvbzpwPjwv cHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2h5IGlzIGl0 IG5vdCBwb3NzaWJsZSBmb3IgdGhlIGxhdHRlcj8gSWYgdGhhdCBjb3VsZCBiZSBleHBsYWluZWQv aGludGVkIGF0IGluIGEgaGFsZiBzZW50ZW5jZSwgSSB0aGluayBpdOKAmWQgYmUgaGVscGZ1bCBp bmZvcm1hdGlvbiB0byBoYXZlIGluIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGF0J3MgdmVyeSBoYXJkLCBhbmQg bm90IGp1c3QgYmVjYXVzZSBpdCdzIGEgbmVnYXRpdmUuIEl0J3MgcmVhbGx5IGFuIG9ic2VydmF0 aW9uIHRoYXQgbW90aXZhdGVzIHRoZSBkdXNjdXNzaW9uLiBBIGhhbGYgc2VudGVuY2Ugd291bGQg SSB0aGluayBjb25mdXNlIG1vcmUgdGhhbiBpdCBlbmxpZ2h0ZW5zIChpdCdzDQogYmVjYXVzZSB5 b3UgaGF2ZSB0b28gbWFueSBjb25zdHJhaW50cyB0byBzYXRpc2Z5IGF0IG9uY2UgLSBJIGRvdWJ0 IHRoYXQgaGVscGVkKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluIGEgdHlwaWNhbCBjYXNlIHdoZXJlIGE8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTElOS19TVEFUVVMg VExWIHVzZXMgb25seSB0aGUgVmFsdWVzIEhFQVJEIGFuZCBTWU1NRVRSSUMsIHdpdGg8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5vdWdoIGFk ZHJlc3Nlcywgc29ydGVkIGFwcHJvcHJpYXRlbHksIHR3byBzaW5nbGUgdmFsdWUgVExWcyBjYW48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmUg bW9yZSBlZmZpY2llbnQgdGhhbiBvbmUgbXVsdGl2YWx1ZSBUTFYuPG86cD48L286cD48L3ByZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNhbWUgdGhpbmc6IHdo eT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5IZXJlIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgb2J2aW91cyB0byBhbnlvbmUgd2hvIGhh cyBsb29rZWQgYXQgNTQ0NC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+KiByZWdhcmRpbmcgdGhlIHNlY29uZCBwYXJhZ3JhcGggZnJvbSZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0 NDQtdXNhZ2UtMDMjc2VjdGlvbi02LjMiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjYuMzwvc3Bhbj48L2I+PC9hPjxiPi4N CiBUTFYgVmFsdWVzPC9iPiwgaS5lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHBy ZT4mbmJzcDsgJm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoaXMg YXBwcm9hY2ggd2FzIHNwZWNpZmllZCBpbiBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzcxODgiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iQy4gYW5kIFQuIENsYXVzZW4i PlJGQzcxODg8L2E+XSwgYW5kIHJlcXVpcmVkIGZvciBwcm90b2NvbHM8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgdGhhdCBleHRlbmQgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM2MTMwIiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IiZxdW90O01vYmls ZSBBZCBIb2MgTmV0d29yayAoTUFORVQpIE5laWdoYm9yaG9vZCBEaXNjb3ZlcnkgUHJvdG9jb2wg KE5IRFApJnF1b3Q7Ij5SRkM2MTMwPC9hPl0gYW5kIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNzE4MSIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtUaGUgT3B0 aW1pemVkIExpbmsgU3RhdGUgUm91dGluZyBQcm90b2NvbCB2ZXJzaW9uIDImcXVvdDsiPlJGQzcx ODE8L2E+XS4mbmJzcDsgSXQgaXMgaGVyZSBSRUNPTU1FTkRFRCB0aGF0PG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRoaXMgYXBwcm9hY2ggaXMgZm9sbG93ZWQgd2hlbiBkZWZp bmluZyBhbnkgQWRkcmVzcyBCbG9jayBUTFYgdGhhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyBtYXkgYmUgdXNlZCBieSBhIHByb3RvY29sIHVzaW5nIFs8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTQ0NCIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSIm cXVvdDtHZW5lcmFsaXplZCBNQU5FVCBQYWNrZXQvTWVzc2FnZSBGb3JtYXQmcXVvdDsiPlJGQzU0 NDQ8L2E+XS48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VGhlIHRlcm0g4oCedGhpcyBhcHByb2FjaOKAnCBjb25mdXNlZCBtZSwgc2lu Y2UgSSBpbml0aWFsbHkgJm5ic3A7dGhvdWdodCBpdCBtZWFudCDigJ50aGUgYXBwcm9hY2ggaXMg dG8gdXNlIFVOU1BFQ0lGSUVEIGluIGEgd2F5IHRoYXQgbWFrZXMgc2Vuc2XigJwgcmF0aGVyIHRo YW4g4oCedGhlIGFwcHJvYWNoIGlzIHRvIHVzZSBVTlNQRUNJRklFROKAnC4NCiBNYXliZSB0aGF0 IGNvdWxkIGJlIHJld29yZGVkIHRvIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPlRoZSBVTlNQRUNJRklFRCBUTFYgYW5kIGl0 cyB1c2FnZSB3YXMgc3BlY2lmaWVkIGluIFtSRkM3MTg4XeKApjwvc3Bhbj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vLiBU aGVyZSBpcyBubyBVTlNQRUNJRklFRCBUTFYuIFRoZXJlIGlzIGEgcmVjb21tZW5kYXRpb24gdG8g aW5jbHVkZSBhbiBVTlNQRUNJRklFRCB2YWx1ZSBpbiBhIFRMVi4gQnV0IHJlYWxseSwgd2UndmUg ZGVzY3JpYmVkIHRoaXMgb25jZSBpbiA3MTg4LCBpdCdzIHRoZXJlIHRvIHJlYWQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiogcmVnYXJkaW5nJm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQt cmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTYuMyIgdGFyZ2V0PSJfYmxhbmsiPjxiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+Ni4zPC9zcGFuPjwvYj48L2E+ PGI+Lg0KIFRMViBWYWx1ZXM6PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UaGUgc2Vjb25kIHBhcmFncmFwaCBpcyBhIGJpdCBjb25mdXNp bmcgYW5kIHNlZW1zIHRvIGV4cGxhaW5nIHJvZ2hseSB0aGUgc2FtZSB0aGluZ3MgYXMgdGhlIGZv dXJ0aCBwYXJhZ3JhcGhzLiBJ4oCZZCBwcm9wb3NlIHRvIG1lcmdlIHRoZSBzZWNvbmQgaW50byB0 aGUgZm91cnRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkknbSBub3Qgc3VyZSBJIGV4YWN0bHkgYWdyZWUsIGJ1dCB0aGUgb3JkZXJp bmcgaW4gdGhhdCBzZWN0aW9uIGNvdWxkIGJlIGltcHJvdmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIGZyb20mbmJzcDs8YSBuYW1lPSJtXy05 MDgyOTIwMzg1ODg3NjkwODEzX21fNjU2NzU3MTYxNTEyMjc4Ij48L2E+PGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNz ZWN0aW9uLTYuNCIgdGFyZ2V0PSJfYmxhbmsiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazt0 ZXh0LWRlY29yYXRpb246bm9uZSI+Ni40PC9zcGFuPjwvYj48L2E+PGI+Lg0KIEF1dG9tYXRpb246 PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IFRoZSBwb3NzaWJsZSBnYWluIGRlcGVuZHMgb24gdGhlIGVmZmljaWVuY3k8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UgY3JlYXRpb24s PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPnRoZSB0ZXJtIOKAnnRoZSBvcmlnaW5hbCBtZXNzYWdlIGNyZWF0aW9u4oCcIHNlZW1zIGEg Yml0IGFtYmlndW91c+KAkyBkb2VzIHRoaXMgcmVmZXIgdG8gdGhlIG1lc3NhZ2UgYXMgY3JlYXRl ZCBieSBhbiBSRkM1NDQ0IG1lc3NhZ2UgYnVpbGRlciBpbXBsZW1lbnRhdGlvbj88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFkZGl0aW9u YWxseSwgSSdtIGNvbmNlcm5lZCBhYm91dCB0d28gdGhpbmdzIHRoYXQgKmFyZW7igJl0KiBpbiB0 aGUgZHJhZnQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4qICZuYnNwO1NvbWUgb2YgdGhlIEFPRFZ2MiBjby1hdXRob3JzIGFuZCBtZSBo YXZlIGFza2VkIGZvciBhIGxpc3Qgb2Yg4oCeYXMgYSBwcm90b2NvbCwgeW91IGNhbiBzZXQgYWxs IG9mIHRoZXNlIGZpZWxkcyBvZiBhIG1lc3NhZ2UsIGJ1dCBwbGVhc2UgbGVhdmUgdGhlIHJlc3Qg YWxvbmXigJwsIHdoaWNoIHdvdWxk4oCZdmUgc2F2ZWQNCiB1cyBtYW55IGhvdXJzIG9mIGRpc2N1 c3Npb25zIChhbmQgSGVubmluZyBhIGxvdCBvZiB0aW1lIHNwZW50IGV4cGxhaW5pbmcgdGhlc2Ug dGhpbmdz4oCmKS4gVGhlc2UgcmVxdWVzdHMgaGF2ZSBiZWVuIG1ldCB3aXRoIGEgcmVmdXNhbCB0 byBzcGVjaWZ5IGEgY29uY3JldGUgQVBJLCBhcyBzdWNoIGFuIGVmZm9ydCBpcyBkZXBlbmRlbnQg b24gb3V0c2lkZSBmYWN0b3JzIHN1Y2ggYXMgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2Ugb3Igc29mdHdh cmUgYXJjaGl0ZWN0dXJlLg0KIEkgYWdyZWUgd2l0aCB0aGlzIG5vdGlvbiwgYnV0IGEgcHJvZ3Jh bW1pbmctbGFuZ3VhZ2UgZGVwZW5kZW50IEFQSSBpcyBub3Qgd2hhdCB3ZeKAmXZlIGFza2VkIGZv ci4gSeKAmXZlIHRyaWVkIHRvIHN1cHBseSBhIHNrZXRjaCBvZiB3aGF0IEkgZGlkIGFzayBmb3Ig aW4gWzFdLCBidXQgdW5mb3J0dW5hdGVseSBJIGRpZG7igJl0IGdldCBhbiBhbnN3ZXIgKGFuZCBh cyBmYXIgYXMgSSBjYW4gc2VlIGl0LCB0aGUgZHJhZnQgd2FzbuKAmXQgY2hhbmdlZCBlaXRoZXIp Lg0KIEkgc3RpbGwgdGhpbmsgdGhhdCBzdWNoIGEgbGlzdCwgaW4gd2hhdGV2ZXIgZm9ybSwgd291 bGQgYmUgdmVyeSBoZWxwZnVsIGZvciBmdXR1cmUgSW50ZXJuZXQtRHJhZnQgYXV0aG9ycyBhbmQg SSBhbHNvIHRoaW5rIHRoaXMgcmVxdWVzdCBpcyBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIGludGVu dGlvbnMgc3RhdGVkIGluJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPjEu MSBIaXN0b3J5IGFuZCBQdXJwb3NlLCZuYnNwOzwvc3Bhbj5hbmQgSSB0aGluaw0KIGl0IHNob3Vs ZCBiZSBpbmNsdWRlZCBpbiB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm8uIFRoZXJlIGFyZSBtYW55IHJlYXNv bnMgd2h5IHdlJ3JlIGp1c3Qgbm90IHRvdWNoaW5nIHRoaXMgb25lLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T25lIGlzIHRoYXQgbGFu Z3VhZ2UgaW5kZXBlbmRlbmNlIGlzIGEgbWlyYWdlLiBIb3cgeW91IGdvIGFib3V0IHRoaW5ncyBp cyBjb21wbGV0ZWx5IGRpZmZlcmVudCBpbiwgZm9yIGV4YW1wbGUgYW4gb2JqZWN0IG9yaWVudGVk IGxhbmd1YWdlIHRoYW4gb25lIHRoYXQgaXNuJ3QuIFNlY3Rpb24gNC41IHNob3dzDQogdGhhdCB0 aGVyZSBhcmUgcXVpdGUgZGlmZmVyZW50IHdheXMgb2YgZG9pbmcgdGhpbmdzIGV2ZW4gZ2l2ZW4g YSBkZWNpc2lvbiB0byB1c2UgYSBtYXAgYXBwcm9hY2gsIGFuZCB0aGVyZSBhcmUgb3RoZXIgYXBw cm9hY2hlcyB0aGFuIHRoYXQuIEl0IHdvdWxkIGJlIHdyb25nIGFuZCBiZXlvbmQgb3VyIGNvbXBl dGVuY2UgdG8gc3VnZ2VzdCBvbmUgb2YgdGhlc2UgYXMgJnF1b3Q7YmVzdCZxdW90Oy4gVGhlcmUn cyByZWFzb25zIHRoZSBJRVRGIGRvZXNuJ3QgZG8gdGhpcywNCiBhbmQgdGhhdCdzIG9uZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBs dXMsIGZyYW5rbHksIHRoZSB3b3JrIGl0IHdvdWxkIHRha2UgaXMgYmV5b25kIHdoYXQgd2UgY2hv b3NlIHRvIHNwZW5kLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbHQ7U3BlYWtpbmcgYXMgYSBXRyBQ YXJ0aWNpcGFudCZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkknbSBjb25mdXNlZCAod2hpY2ggaXMgYW4gYWx0b2dldGhlciB0b28g Y29tbW9uIG9jY3VycmVuY2UgdGhlc2UgZGF5cykuIEkgZ2V0IHRoYXQgd2UgZG9uJ3Qgd2FudCB0 byBzcGVjaWZ5IGFuIEFQSS4gQnV0IEkgdGhpbmsgdGhlIGRpc2N1c3Npb24gYWJvdXQgZmllbGRz IGEgcHJvdG9jb2wgY2FuIGFuZCBjYW4ndA0KIHRvdWNoIGluIGEgbWVzc2FnZXMgaXMgYSBnb29k IHRoaW5nIC0gYW5kIGl0J3Mgb25lIHNwb3Qgd2hlcmUgSSwgdG9vLCBmaW5kIHRoZSBkb2N1bWVu dCB3YW50aW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VG8gcGFyYXBocmFzZSBzb21ldGhpbmcgSSd2ZSBzYWlkIGJlZm9y ZSwgSSBiZWxpZXZlIHRoYXQgUkZDIDU0NDQgY2hhbmdlcyB0aGUgcmVsYXRpb25zaGlwIHRoYXQg YSByb3V0aW5nIHByb3RvY29sIGhhcyB3aXRoIGFuICZxdW90O2ludGVyZmFjZSZxdW90Oy4gSSdt IG5vdCBjb21tZW50aW5nIG9uIHdoZXRoZXIgb3Igbm90DQogdGhhdCdzIGEgZ29vZCB0aGluZywg b3IgYSBiYWQgdGhpbmcgLSBqdXN0IHRoYXQgaXQgZG9lcyBjaGFuZ2UgdGhlIHJlbGF0aW9uc2hp cC4gVGhpcyBjaGFuZ2UgaGFzIGJlZW4gYXQgdGhlIHJvb3Qgb2Ygc29tZSBvZiB0aGUgbG9uZy1y dW5uaW5nIGRpc2N1c3Npb25zIGFzIHRvIHdoZXRoZXIgcHJvdG9jb2xzIHVuZGVyIGRldmVsb3Bt ZW50IHdlcmUgUkZDIDU0NDQgY29tcGxpYW50IG9yIG5vdC4gVGhlIGdvYWwgb2YgdGhpcyBkb2N1 bWVudCBiZWluZw0KIHRvIGVsaW1pbmF0ZSAoaXQncyBhIGdvYWwsIHByb2JhYmx5IG5vdCByZWFj aGFibGUpIHRob3NlIGRpc2N1c3Npb25zLCBJJ2QgbGlrZSB0byBzZWUgdGhhdCBpbmZvcm1hdGlv biBpbiB0aGUgZG9jdW1lbnQgaW4gc29tZSBmb3JtLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdtIGludGVyZXN0ZWQgaW4g c2VlaW5nIHRoaXMgZG9jdW1lbnQgcHJvZ3Jlc3MsIGFuZCBldmVudHVhbGx5IGJlIHB1Ymxpc2hl ZC4gSSB0aGluayBpdCB3aWxsIGhlbHAgZnV0dXJlIHByb3RvY29sIGRlc2lnbmVycyB0byBiZXR0 ZXIgdXNlIFJGQyA1NDQ0LiBCdXQgSSB3b3VsZCBsaWtlIHRvIHNlZSAqc29tZXRoaW5nKg0KIGFs b25nIHRoZSBsaW5lcyBvZiB3aGF0IExvdHRlIGlzIHJlcXVlc3RpbmcsIGFzIEkgdGhpbmsgaXQg d2lsbCBpbXByb3ZlIHRoZSBkb2MuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TdGFuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiogQXMgdGhl IGV4YWN0IHJ1bGVzIGZvciB1c2luZy9zZXR0aW5nIHRoZSBob3AgY291bnQgJmFtcDsgaG9wLWxp bWl0IGZpZWxkcyBhcmUgY3VycmVudGx5IGJlaW5nIGRpc2N1c3NlZCB3LyByZWdhcmQgdG8gQU9E VnYyIGluIGFub3RoZXIgdGhyZWFkIFsyXeKAkyBzaG91bGQgYSBkZWZpbml0aXZlIGFuc3dlciB0 byB0aGF0DQogcXVlc3Rpb24gYmUgcGFydCBvZiA1NDQ0LXVzYWdlPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPllvdSBkb24ndCB3YW50 IHRoYXQuIEJlY2F1c2UgaWYgd2UgZGlkIHNwZWNpZnkgdGhhdCB5b3UnZCBmaW5kIHlvdXJzZWxm IG1vcmUgY29uc3RyYWluZWQgdGhhbiB5b3Ugd2FudCB0byBiZS4gVGhlcmUgaXMgYSBkZXNpZ24g aW50ZW50IGRlc2NyaWJlZCBpbiA1NDQ0LCBidXQgaXQgYXNzdW1lcyBpbW11dGFibGUNCiBtZXNz YWdlcy4gV2hpY2ggeW91IGRvbid0IHdhbnQuIFJlYWxseSwgd2UncmUgZG9pbmcgeW91IGEgZmF2 b3VyIGJ5IG5vdCBpbXBvc2luZyBvbiB5b3UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TG90dGU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlsxXSZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cx ODA4Mi5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9tYW5ldC9jdXJyZW50L21zZzE4MDgyLmh0bWw8L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlsyXQ0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21zZzE4Njc0Lmh0 bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvbWFuZXQvY3VycmVudC9tc2cxODY3NC5odG1sPC9hPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+QW0gMDYuMDQuMjAxNiB1bSAxOToxNCBzY2hyaWViIEp1c3RpbiBEZWFuICZsdDs8YSBo cmVmPSJtYWlsdG86YmViZW1hc3RlckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5iZWJlbWFz dGVyQGdtYWlsLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlRoZSBjaGFpcnMgYWdyZWUgdGhhdCBhIDMgd2VlayBXR0xDIGlzIGFw cHJvcHJpYXRlLiZuYnNwOyBFdmVyeW9uZSBwbGVhc2UgcmVhZCB0aGUgZHJhZnQgZWFybHkgYW5k IGdldCBjb21tZW50cyBpbiBlYXJseSBzbyB0aGF0IHRoZXkgY2FuIGJlIGFkZHJlc3NlZCB3aXRo aW4gdGhlIGxhc3QgY2FsbCBwZXJpb2QuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIEFwciA2LCAyMDE2IGF0IDc6NDAgQU0s IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVh cmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PYnZpb3VzbHkgJiM0MzsxIHRvIHRoZSByZXF1ZXN0IGZvciBXR0xDLjxicj4NCjxi cj4NCldpdGggcmVnYXJkIHRvIHdoYXQncyBjaGFuZ2VkLCB0ZWNobmljYWxseSB0aGUgb25seSBz aWduaWZpY2FudCB0aGluZyBpcyB0byBtYWtlIGl0IGNsZWFyIHRoYXQgaWYgYSBwcm90b2NvbCBk ZWxpdmVycyBhIG1lc3NhZ2UgdG8gdGhlIG11bHRpcGxleGVyLCB0aGUgbXVsdGlwbGV4ZXIgbXVz dCBwYXNzIGl0IG9uIHVuY2hhbmdlZCB0byB0aGUgcHJvdG9jb2wgKGFub3RoZXIgaW5zdGFuY2Ug b2YsIGF0IGFub3RoZXIgcm91dGVyKSB1bmNoYW5nZWQuDQogV2l0aG91dCB0aGF0IG5vdGhpbmcg dGhhdCB0aGUgcHJvdG9jb2wgaXRzZWxmIGNob29zZXMgdG8gZG8gd2l0aCByZWdhcmQgdG8gc2Vj dXJpdHkgbWFrZXMgc2Vuc2UuIFRob3VnaCB0aGUgcHJvdG9jb2wgY2FuIGFsdGVybmF0aXZlbHkg bGV0IHRoZSBtdWx0aXBsZXhlciBkbyB0aGUgc2VjdXJpdHksIDcxODIgY2FuIGJlIGltcGxlbWVu dGVkIGluIGVpdGhlciB3YXkuIFRoaXMgaXNuJ3QgcmVhbGx5IG5ldywgYnV0IGl0IHdhc24ndCBm b3JtYWxseQ0KIHNwZWxsZWQgb3V0LiBJdCdzIHByZXNlbnRlZCBhcyBwYXJ0IG9mIHNwZWxsaW5n IG91dCBtdWx0aXBsZXhlciBydWxlcyBtb3JlIGNhcmVmdWxseS48YnI+DQo8YnI+DQpCdXQgd2hh dCBhYm91dCBtZXNzYWdlIG9wdGltaXNhdGlvbj8gVGhhdCdzIGEgZnVuY3Rpb24gb2YgY29uc3Ry dWN0aW5nIGEgNTQ0NCBtZXNzYWdlLCBub3QgdGhlIG11bHRpcGxleGVyLCBhbmQgaXMgZG93biB0 byB0aGF0IDU0NDQgaW5jbHVkZXMgdHdvIHRoaW5ncyAtIHBhY2tldC9tZXNzYWdlIHN0cnVjdHVy ZSAoYW5kIGltcGxpY2l0bHksIGFuZCBpbiBwcmV0dHkgbXVjaCBhbnkgaW1wbGVtZW50YXRpb24g SSB3b3VsZCBleHBlY3QgdG8gc2VlLA0KIGEgcGFyc2VyIGFuZCBidWlsZGVyIGZvciB0aGF0IHN0 cnVjdHVyZSkgYW5kIHRoZSBtdWx0aXBsZXhlci4gU28gd2UgdG9vayB0aGUgb3Bwb3J0dW5pdHkg dG8gc2VwYXJhdGUgb3V0IG1vcmUgY2xlYXJseSBhIGRpc2N1c3Npb24gb2YgdGhlIHR3bywgd2hp Y2ggd2UgdGhpbmsgd2lsbCBiZSBoZWxwZnVsLjxicj4NCjxicj4NCi0tPGJyPg0KQ2hyaXN0b3Bo ZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3Rl bXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQo8YnI+DQpUOiAmbmJzcDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUy MDI0MjE5NCIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8L2E+ICZuYnNw O3wgJm5ic3A7RToNCjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4N Cjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hu b2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4N CjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj53 d3cuYmFlc3lzdGVtcy5jb20vYWk8L2E+PGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxp Z2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzog MDEzMzc0NTE8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1 aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQpGcm9tOiBtYW5ldCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYW5ldC1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXQtYm91bmNlc0BpZXRmLm9yZzwvYT5d IE9uIEJlaGFsZiBPZiBVbHJpY2ggSGVyYmVyZzxicj4NClNlbnQ6IDA1IEFwcmlsIDIwMTYgMjA6 MDg8YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogW21hbmV0XSBXR0xDIHJlcXVlc3Qg Zm9yIGRyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMzxicj4NCjxicj4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVz c2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJv bSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVybmV0Ljxicj4NCkNvbnNpZGVy IGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFu eSBhdHRhY2htZW50cyBvciByZXBseS48YnI+DQpGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91 cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGlu ZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KKioqIFdBUk5JTkcg KioqPGJyPg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBv dXRzaWRlIG91ciBvcmdhbml6YXRpb24uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KSGksPGJyPg0KPGJyPg0KQXMgeW91IGhhdmUgc2Vl biwgd2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgcmV2aXNpb24gb2YgNTQ0NC11c2FnZS4gVGhlIGF1 dGhvcnMgZmVlbCBjb21mb3J0YWJsZSB0aGF0IHdlIGhhdmUgYWRkcmVzc2VkIGFsbCBpc3N1ZXMg YnkgdGhpcyB2ZXJzaW9uLCBhbmQgd291bGQgbGlrZSB0byBhc2sgdGhlIFdHIGNoYWlycyB0byBp c3N1ZSBhIFdHTEMgb24gdGhpcyBkb2N1bWVudC4gV2hpbGUgaXQgaXMgYSBmYWlybHkgc2hvcnQg ZG9jdW1lbnQsIGdpdmVuDQogdGhhdCBpdCBpcyBJRVRGIHdlZWsgZm9yIHNvbWUsIHdlJ2Qgc3Vn Z2VzdCB0aGF0IGEgMy00IHdlZWsgV0dMQyB3b3VsZCBiZSBhcHByb3ByaWF0ZS48YnI+DQo8YnI+ DQpCZXN0IHJlZ2FyZHM8YnI+DQpVbHJpY2g8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0QGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21hbmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNpcGllbnQg YW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxi cj4NCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlm eSB0aGUgc2VuZGVyLjxicj4NCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBh bnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+DQpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0 byBhbnkgb3RoZXIgcGVyc29uLjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5l dDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptYW5l dEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5l dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWFuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD87DGLKXM0002VGREEN_-- From nobody Mon Apr 18 03:09:53 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 10E1212D188 for ; Mon, 18 Apr 2016 03:09:52 -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 Db8P6UhIEBoF for ; Mon, 18 Apr 2016 03:09:50 -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 4260D12D14E for ; Mon, 18 Apr 2016 03:09:50 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id c126so210682086lfb.2 for ; Mon, 18 Apr 2016 03:09: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:from:date:message-id:subject:to :cc; bh=EzD03er/YOArExrPhhd2DZXlSr8fD1ZpOCogcQ88hnI=; b=uQwXCmEzacXCPPaaRAmXoZAE2U0Ba4LlmujjqjkyFet/7lVdhB+wc3HQ0QgTTWSKS1 Asxexyzchvi8grUPxP+t3uQESB2QfvZEMkCafL0pl84sQQYmiV+7UlulgC+hUpvYVsdi MRCpZRbenpXGUu8gK22ebWY+MX/E1k9X2M6dOuAutzyXyQV/67vipYbCLLfisZ7+FTnt 2AdxH9Tg0RNc/BoLFWRlVkMiwwUvkIUtT7BW5X1RtCa6M/R7xoRM/M1ckuwrkqwxZe6g Nv6BiYMaIo9s5JPzPRR8sOnVzUzmmDuF/zxHBVJPOPBRcVjpjBiRpZzkTweW9EqNsZd6 JRqA== 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=EzD03er/YOArExrPhhd2DZXlSr8fD1ZpOCogcQ88hnI=; b=j5ZW0HRpPU/Uhj/tTmUYU0PSUbHLh7Y21Gdi2nwfOtPRBSRc+D20orZE64SGhwbOpZ y23xDQWSeDv7AgmEpp+NI0I95zOIOAgFx0HX03qQOAK2lCpyXFM4KeciYgH2ZPL0g0mE aqBSuhZ0nUeN3v8G+gQgPkm2qf/IVuUcD0G5w5/XW0yVqpJbqNq+1nthWilIcZm4rqn1 QpG7KXWVtNFZXZB2qCkQnsp0XT70+HljzDnGTstESU5EYjziJ4izMa4zpnVvYFnajFeP eBPAMJe8YAKdc8Q+zAIRCdWLrZddarqS+atAcmVy4p0VPUfMPHTZUUEeLXt9bxavcuSV F72A== X-Gm-Message-State: AOPr4FX1mJ+stc5nOo3jwA8uxiet71WlAdKyr8fs5f61GyTJ/YATJGzsGweUbBOx+pbnLEsvizVQGSUNz3eHvg== X-Received: by 10.25.27.12 with SMTP id b12mr13710008lfb.92.1460974188477; Mon, 18 Apr 2016 03:09:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.30 with HTTP; Mon, 18 Apr 2016 03:09:18 -0700 (PDT) In-Reply-To: <57147860.5020805@earthlink.net> References: <570EDD6A.8070605@earthlink.net> <57147860.5020805@earthlink.net> From: Henning Rogge Date: Mon, 18 Apr 2016 12:09:18 +0200 Message-ID: To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , Mobile Ad Hoc Networks mailing list Subject: Re: [manet] draft-ietf-manet-rfc5444-usage-03 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, 18 Apr 2016 10:09:52 -0000 On Mon, Apr 18, 2016 at 8:02 AM, Charlie Perkins wrote: > The document requires the protocol to know about MTU but discussion on the > list inhibits the protocol from knowing about MTU. The only thing where the MTU should be relevant for ALL RFC5444 protocols is that you should not produce a RFC5444 Message that (including IP/UDP/RFC5444-Packet headers) does not fit into the MTU. Henning Rogge From nobody Mon Apr 18 03:13:59 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 A898712DA6F for ; Mon, 18 Apr 2016 03:13:57 -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 ZdPJmXLdGVt6 for ; Mon, 18 Apr 2016 03:13:56 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 92F4412D63F for ; Mon, 18 Apr 2016 03:13:55 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id c126so210794856lfb.2 for ; Mon, 18 Apr 2016 03:13:55 -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:content-transfer-encoding; bh=cUxin4TrGCAT7wTmfRbnjuCrIb/u/lYegoobubnbzTA=; b=vvGtS+XnnKsfL43+fRLw04fGrHyzXJv1Pi87mpYG8eO3l+xeIS1HsvS3EmeS+4UnPh j20a5vPaLVdm0kRnhYGkTtQNgz1a7tDONxQ/CAxvwqUIbuX4Rta5eTaC0uAu0VurajWs XjiD6sjWmHAzwrfJX5ofQmYmO7BkA21aZLvo/juxnJnsEOpnPt0tDh4B8TSqGjnaLnk+ jRTrjLkMOErKCqvFcq/+aUrjHHtBNohNYKEZJWsC8kQRNcqNgCHjoVl3ZCGrFqWoLK1V DNa91FrYkhe/dez4hq8/wbWu3FOYfCV4YUKVKGY062insFjF3yi2Bh/MSNF6NhOAr0TH 3AuQ== 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:content-transfer-encoding; bh=cUxin4TrGCAT7wTmfRbnjuCrIb/u/lYegoobubnbzTA=; b=A5Y2ofG4MVcC8jRNvhUmkTqL4haR2JzFsGsfsCA53j0G+dhN1D97zcyUzvrISolpo9 dOv6JZ4Tr3QUC/QZ6RX6a/lTYnGXxI1Eq1xzTismjrTQD5lly5HT1uUobXxB1EwD5xJu iTO/wWMBglzCGZwewz2vxE+p/VdXtfEeZ3xmsktvU76BfXBKpwd/iai1qB2QOkKo5lWD wf+OP07Sg5+Udja0zlGs4P16MEFBLZU1x8qq6HJzNLpIcUiYUlqf8s+8whPBepT4Ci6D /AcuO4vlGtsMc9N+0J5TDM+bfWGkLI6eEByHD9sdjHN60fGEkg8F6obJ2AE4uT9z1NuL +cWw== X-Gm-Message-State: AOPr4FUnZ4j0w42oFDd7RCYMOGFrgSKdNvDioaeTEUknE4b/H4ktht3AS8cawkAJaskq9qqbCmgxUAaT+wjXUw== X-Received: by 10.25.25.7 with SMTP id 7mr11310580lfz.166.1460974433850; Mon, 18 Apr 2016 03:13:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.30 with HTTP; Mon, 18 Apr 2016 03:13:24 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Mon, 18 Apr 2016 12:13:24 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] RFC 5444 usage - one specific point. 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, 18 Apr 2016 10:13:57 -0000 On Mon, Apr 18, 2016 at 11:07 AM, Dearlove, Christopher (UK) wrote: > So far I see one specific point for WG agreement - anything else is edito= rial. (Editorial matters, but it's not changing rules, so I'm trying here t= o address one specific rule issue.) Some comments have clearly overlooked t= his, but whether to telegraph it further (e.g. mention in non-normative int= roduction) is back to editorial. > > The draft currently says: > > o The multiplexer MAY delay messages briefly in order to assemble > more efficient packets. It SHOULD respect any constraints on such > delays requested by the protocol. > > Should we change that SHOULD to a MUST? Obviously IETF-style we don't run= votes as such, but what are people's opinions? Unless we specify what kind of "constraints" a protocol can specify, a MUST would be a bit strange. > As I see it: > > Argument for MUST: If the protocol has strong requirements the multiplexe= r needs to respect those. > > Argument for SHOULD: But the protocol might make an impossible demand, su= ch as zero delay when we all know nothing has zero delay. SHOULD isn't MAY,= it needs to do its best. > > Possible third course, something like (open to wordsmithing - I considere= d putting the caveat at the end, for example). > > o The multiplexer MAY delay messages briefly in order to assemble > more efficient packets. It MUST, as far as possible, respect any > constraints on such delays requested by the protocol. > > Argument against third course, we've seen before that anything that inclu= des wording like that is open to IESG not being happy. > > On balance, I think SHOULD is appropriate, assuming SHOULD is interpreted= as it should be - do this unless there really is a good reason not to. But= I could live with any of the three (if allowed). SHOULD would be okay... especially because (normally) multiplexer would restrict the amount of constraints of the protocol by its API anyways. Henning Rogge From nobody Mon Apr 18 03:37:54 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 EB78112DEAB for ; Mon, 18 Apr 2016 03:37:52 -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 II79BRGA45CW for ; Mon, 18 Apr 2016 03:37:51 -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 2EE2512DEA4 for ; Mon, 18 Apr 2016 03:37:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,502,1454976000"; d="scan'208";a="33735646" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 18 Apr 2016 11:37:49 +0100 X-IronPort-AV: E=Sophos;i="5.24,502,1454976000"; d="scan'208";a="114387236" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds016.greenlnk.net with ESMTP; 18 Apr 2016 11:37:49 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 11:37:50 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] RFC 5444 usage - one specific point. Thread-Index: AdGZUYEwrOFrZPQQR8i4HCwA3Y0EVAAAQ4MAAALYKuA= Date: Mon, 18 Apr 2016 10:37:48 +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: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] RFC 5444 usage - one specific point. 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, 18 Apr 2016 10:37:53 -0000 UGxheWluZyBkZXZpbCdzIGFkdm9jYXRlIChiZWNhdXNlIEkgcHJlZmVyIFNIT1VMRCkgaWYgd2Ug d2VudCBNVVNUIHRoZW4gd2Ugd291bGQsIGFzIHlvdSBzYXksIG5lZWQgdG8gc3RhdGUgc29tZXdo ZXJlIChwcm9iYWJseSBpbiB0aGlzIHBhcmFncmFwaCwgYnV0IEkgaGF2ZW7igJl0IGNoZWNrZWQg dGhlIGRyYWZ0KSB0aGF0IHRoZSBwcm90b2NvbCBNQVkgYWNjb21wYW55IGVhY2ggbWVzc2FnZSB3 aXRoIGEgbWF4aW11bSBkZWxheSBiZWZvcmUgc2VuZGluZywgd2hpY2ggdGhlIG11bHRpcGxleGVy IE1VU1QgZXRjLg0KDQotLSANCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFs IEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNClQ6IMKgKzQ0ICgwKTEyNDUgMjQyMTk0IMKgfCDCoEU6IGNo cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxs aWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNm b3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpDQpCQUUgU3lzdGVtcyBB cHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxl cyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywg R3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogSGVubmluZyBSb2dnZSBbbWFpbHRvOmhyb2dnZUBnbWFpbC5jb21dIA0KU2VudDog MTggQXByaWwgMjAxNiAxMToxMw0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpDYzog bWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFJGQyA1NDQ0IHVzYWdlIC0gb25l IHNwZWNpZmljIHBvaW50Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUg b3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9t IHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xp Y2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvbGxvdyB0 aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0 cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpPbiBN b24sIEFwciAxOCwgMjAxNiBhdCAxMTowNyBBTSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykg PGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPiB3cm90ZToNCj4gU28gZmFyIEkgc2VlIG9u ZSBzcGVjaWZpYyBwb2ludCBmb3IgV0cgYWdyZWVtZW50IC0gYW55dGhpbmcgZWxzZSBpcyBlZGl0 b3JpYWwuIChFZGl0b3JpYWwgbWF0dGVycywgYnV0IGl0J3Mgbm90IGNoYW5naW5nIHJ1bGVzLCBz byBJJ20gdHJ5aW5nIGhlcmUgdG8gYWRkcmVzcyBvbmUgc3BlY2lmaWMgcnVsZSBpc3N1ZS4pIFNv bWUgY29tbWVudHMgaGF2ZSBjbGVhcmx5IG92ZXJsb29rZWQgdGhpcywgYnV0IHdoZXRoZXIgdG8g dGVsZWdyYXBoIGl0IGZ1cnRoZXIgKGUuZy4gbWVudGlvbiBpbiBub24tbm9ybWF0aXZlIGludHJv ZHVjdGlvbikgaXMgYmFjayB0byBlZGl0b3JpYWwuDQo+DQo+IFRoZSBkcmFmdCBjdXJyZW50bHkg c2F5czoNCj4NCj4gICAgbyAgVGhlIG11bHRpcGxleGVyIE1BWSBkZWxheSBtZXNzYWdlcyBicmll Zmx5IGluIG9yZGVyIHRvIGFzc2VtYmxlDQo+ICAgICAgIG1vcmUgZWZmaWNpZW50IHBhY2tldHMu ICBJdCBTSE9VTEQgcmVzcGVjdCBhbnkgY29uc3RyYWludHMgb24gc3VjaA0KPiAgICAgICBkZWxh eXMgcmVxdWVzdGVkIGJ5IHRoZSBwcm90b2NvbC4NCj4NCj4gU2hvdWxkIHdlIGNoYW5nZSB0aGF0 IFNIT1VMRCB0byBhIE1VU1Q/IE9idmlvdXNseSBJRVRGLXN0eWxlIHdlIGRvbid0IHJ1biB2b3Rl cyBhcyBzdWNoLCBidXQgd2hhdCBhcmUgcGVvcGxlJ3Mgb3BpbmlvbnM/DQoNClVubGVzcyB3ZSBz cGVjaWZ5IHdoYXQga2luZCBvZiAiY29uc3RyYWludHMiIGEgcHJvdG9jb2wgY2FuIHNwZWNpZnks IGEgTVVTVCB3b3VsZCBiZSBhIGJpdCBzdHJhbmdlLg0KDQo+IEFzIEkgc2VlIGl0Og0KPg0KPiBB cmd1bWVudCBmb3IgTVVTVDogSWYgdGhlIHByb3RvY29sIGhhcyBzdHJvbmcgcmVxdWlyZW1lbnRz IHRoZSBtdWx0aXBsZXhlciBuZWVkcyB0byByZXNwZWN0IHRob3NlLg0KPg0KPiBBcmd1bWVudCBm b3IgU0hPVUxEOiBCdXQgdGhlIHByb3RvY29sIG1pZ2h0IG1ha2UgYW4gaW1wb3NzaWJsZSBkZW1h bmQsIHN1Y2ggYXMgemVybyBkZWxheSB3aGVuIHdlIGFsbCBrbm93IG5vdGhpbmcgaGFzIHplcm8g ZGVsYXkuIFNIT1VMRCBpc24ndCBNQVksIGl0IG5lZWRzIHRvIGRvIGl0cyBiZXN0Lg0KPg0KPiBQ b3NzaWJsZSB0aGlyZCBjb3Vyc2UsIHNvbWV0aGluZyBsaWtlIChvcGVuIHRvIHdvcmRzbWl0aGlu ZyAtIEkgY29uc2lkZXJlZCBwdXR0aW5nIHRoZSBjYXZlYXQgYXQgdGhlIGVuZCwgZm9yIGV4YW1w bGUpLg0KPg0KPiAgICBvICBUaGUgbXVsdGlwbGV4ZXIgTUFZIGRlbGF5IG1lc3NhZ2VzIGJyaWVm bHkgaW4gb3JkZXIgdG8gYXNzZW1ibGUNCj4gICAgICAgbW9yZSBlZmZpY2llbnQgcGFja2V0cy4g IEl0IE1VU1QsIGFzIGZhciBhcyBwb3NzaWJsZSwgcmVzcGVjdCBhbnkNCj4gICAgICAgY29uc3Ry YWludHMgb24gc3VjaCBkZWxheXMgcmVxdWVzdGVkIGJ5IHRoZSBwcm90b2NvbC4NCj4NCj4gQXJn dW1lbnQgYWdhaW5zdCB0aGlyZCBjb3Vyc2UsIHdlJ3ZlIHNlZW4gYmVmb3JlIHRoYXQgYW55dGhp bmcgdGhhdCBpbmNsdWRlcyB3b3JkaW5nIGxpa2UgdGhhdCBpcyBvcGVuIHRvIElFU0cgbm90IGJl aW5nIGhhcHB5Lg0KPg0KPiBPbiBiYWxhbmNlLCBJIHRoaW5rIFNIT1VMRCBpcyBhcHByb3ByaWF0 ZSwgYXNzdW1pbmcgU0hPVUxEIGlzIGludGVycHJldGVkIGFzIGl0IHNob3VsZCBiZSAtIGRvIHRo aXMgdW5sZXNzIHRoZXJlIHJlYWxseSBpcyBhIGdvb2QgcmVhc29uIG5vdCB0by4gQnV0IEkgY291 bGQgbGl2ZSB3aXRoIGFueSBvZiB0aGUgdGhyZWUgKGlmIGFsbG93ZWQpLg0KDQpTSE9VTEQgd291 bGQgYmUgb2theS4uLiBlc3BlY2lhbGx5IGJlY2F1c2UgKG5vcm1hbGx5KSBtdWx0aXBsZXhlciB3 b3VsZCByZXN0cmljdCB0aGUgYW1vdW50IG9mIGNvbnN0cmFpbnRzIG9mIHRoZSBwcm90b2NvbCBi eSBpdHMgQVBJIGFueXdheXMuDQoNCkhlbm5pbmcgUm9nZ2UNCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqClRoaXMgZW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZApy ZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBu b3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFu eSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKgo= From nobody Mon Apr 18 03:39: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 F168F12D1C8 for ; Mon, 18 Apr 2016 03:39:52 -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 EmeTb0TmOLVW for ; Mon, 18 Apr 2016 03:39:51 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 008F512D5E2 for ; Mon, 18 Apr 2016 03:39:50 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id j11so211237129lfb.1 for ; Mon, 18 Apr 2016 03:39: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:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7DZdeeW5iHxXcNnezY3N1Vgig/MBO3SnWpi3IGAM8oo=; b=fl/00ltI2tTmXj4KTneVEuEKvTDq22l73J3i58Hys71ZQBNORIoKM80SQeVwMC4De0 X24W3koxrior+1LIB8n0pNuDWhoJVm23LiNTwmK1alEns83upfJ2FEzSVIrnKp18vhVZ P5IVPCDYNu74kgySdq1NEyRZtPX/PJBDSXQ/K1pcBPiKvFuiCpvOGMKK/h+lZVy630P8 hAVYMYXW+YKidzCGt3uw9I5JZBofDHGf3rPEcF54rBP6hy/XAiq1XR6padVdCjk2Nt2p fB8yhtD/Rsdj+Mr0u7UqYoHs7WupIfj9q3gKOI/iKUAHcEKxBRdESkJ/E63Nt2W0EILM xlNA== 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:content-transfer-encoding; bh=7DZdeeW5iHxXcNnezY3N1Vgig/MBO3SnWpi3IGAM8oo=; b=Yc9Y+UIJWmXKX06LLHrO9ijKbjyCj+R9lMpN31AypKSVsd/H7xF27vIsUvI7DH9N/q 3MMygXS/sg8/6OR99z7DDnQDOE+maTEsvJmyHA61Gm5w7O/7s1xo8EYhRDPVzRgYOE9T h5n8MyIlsDrVSmjRk2JMx036MwTxyu8ao7P/+UfDJBwy3jcfyT/zn7sNEuCW5iGyLPSA 7EOuIlWqhVI6MXonXd1m9X6tFNjzcvIX1rhvNmXP9BtI0HpzAcRfsUFwM+5z0DMYcQNV 8WZkz9WZJDUDsWj7LXVLPpsO8CDky8UQSw6/C+JukG5h/Z7+FjyZZVEpgJombhqVh3F7 YRpw== X-Gm-Message-State: AOPr4FX2vpgT6DnFAaAqsO0Xj0YR1fewCBKRvnVnhmK3lItISwowJ2+BG4zs2lcvn2tZa9C2cxOgJwEeWlTLmA== X-Received: by 10.25.25.7 with SMTP id 7mr11343873lfz.166.1460975989101; Mon, 18 Apr 2016 03:39:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.30 with HTTP; Mon, 18 Apr 2016 03:39:19 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Mon, 18 Apr 2016 12:39:19 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] RFC 5444 usage - one specific point. 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, 18 Apr 2016 10:39:53 -0000 On Mon, Apr 18, 2016 at 12:37 PM, Dearlove, Christopher (UK) wrote: > Playing devil's advocate (because I prefer SHOULD) if we went MUST then w= e would, as you say, need to state somewhere (probably in this paragraph, b= ut I haven=E2=80=99t checked the draft) that the protocol MAY accompany eac= h message with a maximum delay before sending, which the multiplexer MUST e= tc. Which would be a little bit insane, on most operation systems there is NO WAY for userspace to be sure how long it will take for an IP packet to be transmitted. It might just sit in the outgoing transmission queue for a while... Henning Rogge From nobody Mon Apr 18 03:45: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 A8A0412DA56 for ; Mon, 18 Apr 2016 03:45:24 -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 JY-ywYqW7ss0 for ; Mon, 18 Apr 2016 03:45:23 -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 23EE812D8C8 for ; Mon, 18 Apr 2016 03:45:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,502,1454976000"; d="scan'208";a="61733739" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 18 Apr 2016 11:45:22 +0100 X-IronPort-AV: E=Sophos;i="5.24,502,1454976000"; d="scan'208";a="114388703" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 18 Apr 2016 11:45:21 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 11:45:21 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] RFC 5444 usage - one specific point. Thread-Index: AdGZUYEwrOFrZPQQR8i4HCwA3Y0EVAAAQ4MAAALYKuD///B8gP//7qNA Date: Mon, 18 Apr 2016 10:45:20 +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: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] RFC 5444 usage - one specific point. 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, 18 Apr 2016 10:45:24 -0000 SSB0aGluayBpdCdzIGEgcXVlc3Rpb24gb2YgdGltZXNjYWxlcy4gVGhvdWdoIHRoYXQgb3BlbnMg dXAgd2hvbGUgY2FucyBvZiB3b3Jtcy4gQnV0IHRoZSBzb3J0IG9mIHRpbWluZyB0aGF0IG1pZ2h0 IGJlIGltcG9zZWQgbWlnaHQgYmUgdGhhdCBOSERQIGFuZCBPTFNSdjIgbWlnaHQgYmUgT0sgd2l0 aCBhIGZldyB0ZW50aHMgb2Ygc2Vjb25kcyBleHRyYSBkZWxheS4gV2hpY2ggaXMgcHJvYmFibHkg bG9uZ2VyIHRoYW4gb3BlcmF0aW5nIHN5c3RlbSBkZWxheXMuDQoNCkJ1dCBJIHRoaW5rIHdlIGN1 cnJlbnRseSBoYXZlIHRoZSBiYWxhbmNlIGFib3V0IHJpZ2h0LiBBbmQgSSByZWFkIHlvdSBhcyBh Z3JlZWluZy4NCg0KLS0gDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBF bmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpUOiDCoCs0NCAoMCkxMjQ1IDI0MjE5NCDCoHwgwqBFOiBjaHJp cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbQ0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln ZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9y ZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haQ0KQkFFIFN5c3RlbXMgQXBw bGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMg Tm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1 aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEhlbm5pbmcgUm9nZ2UgW21haWx0bzpocm9nZ2VAZ21haWwuY29tXSANClNlbnQ6IDE4 IEFwcmlsIDIwMTYgMTE6MzkNClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IG1h bmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSBSRkMgNTQ0NCB1c2FnZSAtIG9uZSBz cGVjaWZpYyBwb2ludC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91 ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0 aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNr IG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb2xsb3cgdGhl ICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1 Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KT24gTW9u LCBBcHIgMTgsIDIwMTYgYXQgMTI6MzcgUE0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxj aHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4gd3JvdGU6DQo+IFBsYXlpbmcgZGV2aWwncyBh ZHZvY2F0ZSAoYmVjYXVzZSBJIHByZWZlciBTSE9VTEQpIGlmIHdlIHdlbnQgTVVTVCB0aGVuIHdl IHdvdWxkLCBhcyB5b3Ugc2F5LCBuZWVkIHRvIHN0YXRlIHNvbWV3aGVyZSAocHJvYmFibHkgaW4g dGhpcyBwYXJhZ3JhcGgsIGJ1dCBJIGhhdmVu4oCZdCBjaGVja2VkIHRoZSBkcmFmdCkgdGhhdCB0 aGUgcHJvdG9jb2wgTUFZIGFjY29tcGFueSBlYWNoIG1lc3NhZ2Ugd2l0aCBhIG1heGltdW0gZGVs YXkgYmVmb3JlIHNlbmRpbmcsIHdoaWNoIHRoZSBtdWx0aXBsZXhlciBNVVNUIGV0Yy4NCg0KV2hp Y2ggd291bGQgYmUgYSBsaXR0bGUgYml0IGluc2FuZSwgb24gbW9zdCBvcGVyYXRpb24gc3lzdGVt cyB0aGVyZSBpcyBOTyBXQVkgZm9yIHVzZXJzcGFjZSB0byBiZSBzdXJlIGhvdyBsb25nIGl0IHdp bGwgdGFrZSBmb3IgYW4gSVAgcGFja2V0IHRvIGJlIHRyYW5zbWl0dGVkLg0KDQpJdCBtaWdodCBq dXN0IHNpdCBpbiB0aGUgb3V0Z29pbmcgdHJhbnNtaXNzaW9uIHF1ZXVlIGZvciBhIHdoaWxlLi4u DQoNCkhlbm5pbmcgUm9nZ2UNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBh bHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQg cGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4K WW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNj bG9zZSBvcgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKgo= From nobody Mon Apr 18 03:48: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 E4E3112E09B for ; Mon, 18 Apr 2016 03:48: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, 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 9e-F8Dcl_82f for ; Mon, 18 Apr 2016 03:48:20 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 77E8F12E08A for ; Mon, 18 Apr 2016 03:48:20 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id c126so211693506lfb.2 for ; Mon, 18 Apr 2016 03:48:20 -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:content-transfer-encoding; bh=2CJlDerkzJusICEI95fStPX22LpK+0dUJyC8uUEcBJU=; b=0RkgfuIRw0eBYQojBduez2apTg61P2yE46xUPdPdkiGdUlRkJ6PMze5U/VI0vUazhw kKvTEAXT/WyU/EvNyxw2dhyysAg78pRoYcIWTQhAvt2ajN78RuKX/O37DrxlGhE+2jUI PKP1poUmkWkode78iobH41bd7886HdbGx+qO2cLfkSchnDLVGRKunP2Ar48YPEOro4Ik Hdj09wOGvgBfSljvsPfOQvKQCnSABbgDGeVv2Qyxe/whzbVPApmko7hTdM4Uu5gfQslc de+CTDnX+/YyCF7HpHz3RecmUAAXokjOyfhzmcLoeatSo0Ru6GI5f3vnIeH4oCczKqNr 5vvQ== 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:content-transfer-encoding; bh=2CJlDerkzJusICEI95fStPX22LpK+0dUJyC8uUEcBJU=; b=d1ZJz+M3bYy2tUoNvgTI8KzBOMKViTZumrv1ShH2NrNwmwDakoIuhBxY1euTB/BOSo nJkfq9IRqT5JATAg2/M8XW10or/KcBjCZAKOj7m2Jov4ct0y0v58tkfwn1iVSu6zWNY7 HofbIK9/OKTpxadG6fXR/hHNcXdqL61HOTDF9iCc4wlxj5JKfVy6WD2+44Spbz4RYwZP 7DDzZYDBz0dqaxNMIuE2zsWDdqNfB/CkkyyVhom1+bK9uu0tB1nCEXSuucII5CJGMcbx Wqx0nbqPZdu1aP0DXxycEyLrLHGWh6XKE9REsH6Km2WdaP9zGvqUHNa87+T7jkv2UWz5 7Sbw== X-Gm-Message-State: AOPr4FWUEdiZHjKduMnm4UStg8cAShqWo9ppIMECLlRvV6ffxLTnS/hd/P3o9vmEszUQ3xyMUOtn5ZXjQ97ZqQ== X-Received: by 10.25.131.147 with SMTP id f141mr14523510lfd.12.1460976498729; Mon, 18 Apr 2016 03:48:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.30 with HTTP; Mon, 18 Apr 2016 03:47:48 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Mon, 18 Apr 2016 12:47:48 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] RFC 5444 usage - one specific point. 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, 18 Apr 2016 10:48:22 -0000 On Mon, Apr 18, 2016 at 12:45 PM, Dearlove, Christopher (UK) wrote: > I think it's a question of timescales. Though that opens up whole cans of= worms. But the sort of timing that might be imposed might be that NHDP and= OLSRv2 might be OK with a few tenths of seconds extra delay. Which is prob= ably longer than operating system delays. > > But I think we currently have the balance about right. And I read you as = agreeing. I remember a Bufferbloat discussion where someone measured a delay of 30 seconds on LTE... just because there was a long, full and unmanaged queue in the way. Henning Rogge From nobody Mon Apr 18 05:03: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 8847012DE47 for ; Mon, 18 Apr 2016 05:03:15 -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 9JXOBRhjoKs4 for ; Mon, 18 Apr 2016 05:03:14 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 BCF1412DE3A for ; Mon, 18 Apr 2016 05:03:13 -0700 (PDT) Received: by mail-qg0-x235.google.com with SMTP id f52so114007582qga.3 for ; Mon, 18 Apr 2016 05:03: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=/TrP4Eitnd6KesR6PMSYBnrSpw7AUUXG55qlK6jNnJ4=; b=Wq5ck8B8AH7uFq4AvY+uh0eQC9T58izgWGOlXnhq28834VhNSTmPmrf1QCE/YAD9Y3 A86nhgY9eGK7uqPKB8+qzrPpoAs4adQ2SI6whLl3VRN7ujBz8ULSu0bEGyQnEifpv1nP IIxC01X9LjHFhNx785BqRYU/EmMES0ZHdKt5MWQaL61yUxyB800ceJRDa7DTLt2NkBlv DTl6262+z5/FY8A6N8tDnTmzJKQIpx1mW4mvH8sykQIgUQjXiIeF0ZGfNO6t8wSCArjJ oJUB16a3hfq6jm6DhmAW+MAvOBcOZWjCQHdUmZbDCHCXNuXbtA8WGLA+h3u7mYZhWB/q VT8Q== 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=/TrP4Eitnd6KesR6PMSYBnrSpw7AUUXG55qlK6jNnJ4=; b=WyuDZkpBDnySH0AQfQ7WYonF4nh44k19F9PZKcFh1UkbKdl+ZadvQYfmlr2wLIlacX M4TRoPM6xnPyI1gbdKx2TX8YLAUq/uFAkqpxmTMOFIHEEH2YRsYzRQHl4RklbrIynkPt T4WiUB/eMdEZLjlZcpU0ryzlHIHk44H2a6PPsmMXWG/bGKZj8VPuZ51gtx3e7WRAMH2f ZSKt9dC/+JRFJ56GB63dFyPJCcuKV5wnx5QqNL+4HNdrE6+1hONCRZK/NvUZRpQ9BIBF LyxRMBNDlT9iRQHO1q9LynH8Em8nSLL5Uo7y34zPPOnFvMl+R0IngsTMgyV/egqB8MO9 tvYw== X-Gm-Message-State: AOPr4FXYTe+FO9K9GTUY8eOXYODx8f6pAmRfuiXPqKakpQp18lYZ/RQkcmZ8dF0Yz1NcN3VDDdYh5xKk1hr2XQ== MIME-Version: 1.0 X-Received: by 10.140.35.115 with SMTP id m106mr41471931qgm.13.1460980992772; Mon, 18 Apr 2016 05:03:12 -0700 (PDT) Received: by 10.140.43.131 with HTTP; Mon, 18 Apr 2016 05:03:12 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Apr 2016 14:03:12 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11c038e0192ed80530c125c4 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] RFC 5444 usage - one specific point. 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, 18 Apr 2016 12:03:15 -0000 --001a11c038e0192ed80530c125c4 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 18, 2016 at 12:13 PM, Henning Rogge wrote: > On Mon, Apr 18, 2016 at 11:07 AM, Dearlove, Christopher (UK) > wrote: > > So far I see one specific point for WG agreement - anything else is > editorial. (Editorial matters, but it's not changing rules, so I'm trying > here to address one specific rule issue.) Some comments have clearly > overlooked this, but whether to telegraph it further (e.g. mention in > non-normative introduction) is back to editorial. > > > > The draft currently says: > > > > o The multiplexer MAY delay messages briefly in order to assemble > > more efficient packets. It SHOULD respect any constraints on such > > delays requested by the protocol. > > > > Should we change that SHOULD to a MUST? Obviously IETF-style we don't > run votes as such, but what are people's opinions? > > Unless we specify what kind of "constraints" a protocol can specify, a > MUST would be a bit strange. > IMO, I think it is not efficient to delay messages, I think it is strange to delay without saying how much that multiplexer is delaying to get to efficiency, so it seems that multiplexer efficiency is needed to be defined because it can be different than protocol efficiency. Therefore, I think we should change MAY to may and SHOULD to should, or if not changed we need to specify a maximum delay for the multiplexer, because leaving it without limit is not correct. > > > As I see it: > > > > Argument for MUST: If the protocol has strong requirements the > multiplexer needs to respect those. > > > > Argument for SHOULD: But the protocol might make an impossible demand, > such as zero delay when we all know nothing has zero delay. SHOULD isn't > MAY, it needs to do its best. > > > > Possible third course, something like (open to wordsmithing - I > considered putting the caveat at the end, for example). > > > > o The multiplexer MAY delay messages briefly in order to assemble > > more efficient packets. It MUST, as far as possible, respect any > > constraints on such delays requested by the protocol. > > > > Argument against third course, we've seen before that anything that > includes wording like that is open to IESG not being happy. > > > > On balance, I think SHOULD is appropriate, assuming SHOULD is > interpreted as it should be - do this unless there really is a good reason > not to. But I could live with any of the three (if allowed). > > SHOULD would be okay... especially because (normally) multiplexer > would restrict the amount of constraints of the protocol by its API > anyways. > IMO, It should say that the multiplexer MUST NOT delay messages if the protocol request constraints on delay. We don't want to change the multiplexer into having its own protocol without having a RFC for it. AB --001a11c038e0192ed80530c125c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 18, 2016 at 12:13 PM, Henning Rogge <<= a href=3D"mailto:hrogge@gmail.com" target=3D"_blank">hrogge@gmail.com&g= t; wrote:
On Mon,= Apr 18, 2016 at 11:07 AM, Dearlove, Christopher (UK)
<chris.dearlove@baesyst= ems.com> wrote:
> So far I see one specific point for WG agreement - anything else is ed= itorial. (Editorial matters, but it's not changing rules, so I'm tr= ying here to address one specific rule issue.) Some comments have clearly o= verlooked this, but whether to telegraph it further (e.g. mention in non-no= rmative introduction) is back to editorial.
>
> The draft currently says:
>
>=C2=A0 =C2=A0 o=C2=A0 The multiplexer MAY delay messages briefly in ord= er to assemble
>=C2=A0 =C2=A0 =C2=A0 =C2=A0more efficient packets.=C2=A0 It SHOULD resp= ect any constraints on such
>=C2=A0 =C2=A0 =C2=A0 =C2=A0delays requested by the protocol.
>
> Should we change that SHOULD to a MUST? Obviously IETF-style we don= 9;t run votes as such, but what are people's opinions?

Unless we specify what kind of "constraints" a protocol ca= n specify, a
MUST would be a bit strange.

IMO, I thi= nk it is not efficient to delay messages, I think it is strange to delay wi= thout saying how much that multiplexer is delaying to get to efficiency, so= it seems that multiplexer efficiency is needed to be defined because it ca= n be different than protocol efficiency.

Therefore, I th= ink we should change MAY to may and SHOULD to should, or if not changed we = need to specify a maximum delay for the multiplexer, because leaving it wit= hout limit is not correct.
=C2=A0

> As I see it:
>
> Argument for MUST: If the protocol has strong requirements the multipl= exer needs to respect those.
>
> Argument for SHOULD: But the protocol might make an impossible demand,= such as zero delay when we all know nothing has zero delay. SHOULD isn'= ;t MAY, it needs to do its best.
>
> Possible third course, something like (open to wordsmithing - I consid= ered putting the caveat at the end, for example).
>
>=C2=A0 =C2=A0 o=C2=A0 The multiplexer MAY delay messages briefly in ord= er to assemble
>=C2=A0 =C2=A0 =C2=A0 =C2=A0more efficient packets.=C2=A0 It MUST, as fa= r as possible, respect any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0constraints on such delays requested by the = protocol.
>
> Argument against third course, we've seen before that anything tha= t includes wording like that is open to IESG not being happy.
>
> On balance, I think SHOULD is appropriate, assuming SHOULD is interpre= ted as it should be - do this unless there really is a good reason not to. = But I could live with any of the three (if allowed).

SHOULD would be okay... especially because (normally) multiplexer would restrict the amount of constraints of the protocol by its API
anyways.

IMO, It should say that the mu= ltiplexer MUST NOT delay messages if the protocol request constraints on de= lay. We don't want to change the multiplexer into having its own protoc= ol without having a RFC for it.

AB
=
--001a11c038e0192ed80530c125c4-- From nobody Mon Apr 18 05:12: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 852AF12DAD7 for ; Mon, 18 Apr 2016 05:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.915 X-Spam-Level: X-Spam-Status: No, score=-7.915 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] 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 3Umg0opta7mb for ; Mon, 18 Apr 2016 05:12:39 -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 A78DD12DAD0 for ; Mon, 18 Apr 2016 05:12:38 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,502,1454976000"; d="scan'208,217"; a="61776251" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 18 Apr 2016 13:12:26 +0100 X-IronPort-AV: E=Sophos;i="5.24,502,1454976000"; d="scan'208,217";a="114408406" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 18 Apr 2016 13:12:25 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 13:12:25 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , Henning Rogge Thread-Topic: [manet] RFC 5444 usage - one specific point. Thread-Index: AdGZUYEwrOFrZPQQR8i4HCwA3Y0EVAAAQ4MAAAPVsAAAAkM7QA== Date: Mon, 18 Apr 2016 12:12:24 +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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD9A6GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] RFC 5444 usage - one specific point. 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, 18 Apr 2016 12:12:41 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD9A6GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 TXVsdGlwbGV4ZXIgZWZmaWNpZW5jeSBpcyBzdHJhaWdodGZvcndhcmQgLSBpZiB5b3UgcHV0IHR3 byBtZXNzYWdlcyBpbiBvbmUgcGFja2V0IHlvdSBzYXZlIGEgcGFja2V0IHRyYW5zbWlzc2lvbi4g T24gc29tZSBNQUNzIGFzIGxvbmcgYXMgcGFja2V0cyBhcmUgb2YgcmVhc29uYWJsZSBzaXplLCB0 aGUgcGFja2V0IHNpemUgaXMgcHJldHR5IGlycmVsZXZhbnQsIG9ubHkgdGhlIG51bWJlciBvZiBw YWNrZXRzIG1hdHRlcnMuDQoNClRoZXJl4oCZcyBhIGdvb2Qgc3luZXJneSBvZiB0aGlzIHdpdGgg UkZDIDUxNDggaWYgeW91IGFyZSB1c2luZyB0aGF0LCBidXQgdGhhdOKAmXMgbm90IHRoZSBzdWJq ZWN0IGhlcmUuDQoNCkFuZCBhcyBmb3IgY2hhbmdpbmcgdG8gbG93ZXIgY2FzZSwgZG9u4oCZdCBk byB0aGF0LiBJdCBpcyBvdmVyd2hlbG1pbmdseSBnb29kIHByYWN0aWNlIHRoYXQgaW4gbm9ybWF0 aXZlIHNlY3Rpb25zIG9mIGEgcmVwb3J0LCB1c2UgTUFZLCBTSE9VTEQsLiBNVVNUIGV0Yy4gYXMg MjExOSB0ZXJtcyBhbmQgYXZvaWQgYWxsIG90aGVyIHVzZSBvZiB0aG9zZSB3b3Jkcy4gQnV0IGhl cmUsIGFzIEkgaGF2ZSBzYWlkLCBJIHRoaW5rIFNIT1VMRCBpcyBhcHByb3ByaWF0ZS4NCg0KLS0N CkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lz dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl bXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3Rl bXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVh dCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20v YWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50 ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMz NzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQs IFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBBYmR1c3NhbGFtIEJhcnl1biBbbWFpbHRvOmFiZHVz c2FsYW1iYXJ5dW5AZ21haWwuY29tXQ0KU2VudDogMTggQXByaWwgMjAxNiAxMzowMw0KVG86IEhl bm5pbmcgUm9nZ2UNCkNjOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgbWFuZXRAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFJGQyA1NDQ0IHVzYWdlIC0gb25lIHNwZWNpZmljIHBv aW50Lg0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBv dXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIg b3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBj bGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGlu Zm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBp biBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVz eXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIw RmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2Ug Zm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hv d3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1 c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCg0KDQpPbiBNb24sIEFwciAxOCwgMjAxNiBhdCAxMjox MyBQTSwgSGVubmluZyBSb2dnZSA8aHJvZ2dlQGdtYWlsLmNvbTxtYWlsdG86aHJvZ2dlQGdtYWls LmNvbT4+IHdyb3RlOg0KT24gTW9uLCBBcHIgMTgsIDIwMTYgYXQgMTE6MDcgQU0sIERlYXJsb3Zl LCBDaHJpc3RvcGhlciAoVUspDQo8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRv OmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQo+IFNvIGZhciBJIHNlZSBv bmUgc3BlY2lmaWMgcG9pbnQgZm9yIFdHIGFncmVlbWVudCAtIGFueXRoaW5nIGVsc2UgaXMgZWRp dG9yaWFsLiAoRWRpdG9yaWFsIG1hdHRlcnMsIGJ1dCBpdCdzIG5vdCBjaGFuZ2luZyBydWxlcywg c28gSSdtIHRyeWluZyBoZXJlIHRvIGFkZHJlc3Mgb25lIHNwZWNpZmljIHJ1bGUgaXNzdWUuKSBT b21lIGNvbW1lbnRzIGhhdmUgY2xlYXJseSBvdmVybG9va2VkIHRoaXMsIGJ1dCB3aGV0aGVyIHRv IHRlbGVncmFwaCBpdCBmdXJ0aGVyIChlLmcuIG1lbnRpb24gaW4gbm9uLW5vcm1hdGl2ZSBpbnRy b2R1Y3Rpb24pIGlzIGJhY2sgdG8gZWRpdG9yaWFsLg0KPg0KPiBUaGUgZHJhZnQgY3VycmVudGx5 IHNheXM6DQo+DQo+ICAgIG8gIFRoZSBtdWx0aXBsZXhlciBNQVkgZGVsYXkgbWVzc2FnZXMgYnJp ZWZseSBpbiBvcmRlciB0byBhc3NlbWJsZQ0KPiAgICAgICBtb3JlIGVmZmljaWVudCBwYWNrZXRz LiAgSXQgU0hPVUxEIHJlc3BlY3QgYW55IGNvbnN0cmFpbnRzIG9uIHN1Y2gNCj4gICAgICAgZGVs YXlzIHJlcXVlc3RlZCBieSB0aGUgcHJvdG9jb2wuDQo+DQo+IFNob3VsZCB3ZSBjaGFuZ2UgdGhh dCBTSE9VTEQgdG8gYSBNVVNUPyBPYnZpb3VzbHkgSUVURi1zdHlsZSB3ZSBkb24ndCBydW4gdm90 ZXMgYXMgc3VjaCwgYnV0IHdoYXQgYXJlIHBlb3BsZSdzIG9waW5pb25zPw0KDQpVbmxlc3Mgd2Ug c3BlY2lmeSB3aGF0IGtpbmQgb2YgImNvbnN0cmFpbnRzIiBhIHByb3RvY29sIGNhbiBzcGVjaWZ5 LCBhDQpNVVNUIHdvdWxkIGJlIGEgYml0IHN0cmFuZ2UuDQoNCklNTywgSSB0aGluayBpdCBpcyBu b3QgZWZmaWNpZW50IHRvIGRlbGF5IG1lc3NhZ2VzLCBJIHRoaW5rIGl0IGlzIHN0cmFuZ2UgdG8g ZGVsYXkgd2l0aG91dCBzYXlpbmcgaG93IG11Y2ggdGhhdCBtdWx0aXBsZXhlciBpcyBkZWxheWlu ZyB0byBnZXQgdG8gZWZmaWNpZW5jeSwgc28gaXQgc2VlbXMgdGhhdCBtdWx0aXBsZXhlciBlZmZp Y2llbmN5IGlzIG5lZWRlZCB0byBiZSBkZWZpbmVkIGJlY2F1c2UgaXQgY2FuIGJlIGRpZmZlcmVu dCB0aGFuIHByb3RvY29sIGVmZmljaWVuY3kuDQpUaGVyZWZvcmUsIEkgdGhpbmsgd2Ugc2hvdWxk IGNoYW5nZSBNQVkgdG8gbWF5IGFuZCBTSE9VTEQgdG8gc2hvdWxkLCBvciBpZiBub3QgY2hhbmdl ZCB3ZSBuZWVkIHRvIHNwZWNpZnkgYSBtYXhpbXVtIGRlbGF5IGZvciB0aGUgbXVsdGlwbGV4ZXIs IGJlY2F1c2UgbGVhdmluZyBpdCB3aXRob3V0IGxpbWl0IGlzIG5vdCBjb3JyZWN0Lg0KDQoNCj4g QXMgSSBzZWUgaXQ6DQo+DQo+IEFyZ3VtZW50IGZvciBNVVNUOiBJZiB0aGUgcHJvdG9jb2wgaGFz IHN0cm9uZyByZXF1aXJlbWVudHMgdGhlIG11bHRpcGxleGVyIG5lZWRzIHRvIHJlc3BlY3QgdGhv c2UuDQo+DQo+IEFyZ3VtZW50IGZvciBTSE9VTEQ6IEJ1dCB0aGUgcHJvdG9jb2wgbWlnaHQgbWFr ZSBhbiBpbXBvc3NpYmxlIGRlbWFuZCwgc3VjaCBhcyB6ZXJvIGRlbGF5IHdoZW4gd2UgYWxsIGtu b3cgbm90aGluZyBoYXMgemVybyBkZWxheS4gU0hPVUxEIGlzbid0IE1BWSwgaXQgbmVlZHMgdG8g ZG8gaXRzIGJlc3QuDQo+DQo+IFBvc3NpYmxlIHRoaXJkIGNvdXJzZSwgc29tZXRoaW5nIGxpa2Ug KG9wZW4gdG8gd29yZHNtaXRoaW5nIC0gSSBjb25zaWRlcmVkIHB1dHRpbmcgdGhlIGNhdmVhdCBh dCB0aGUgZW5kLCBmb3IgZXhhbXBsZSkuDQo+DQo+ICAgIG8gIFRoZSBtdWx0aXBsZXhlciBNQVkg ZGVsYXkgbWVzc2FnZXMgYnJpZWZseSBpbiBvcmRlciB0byBhc3NlbWJsZQ0KPiAgICAgICBtb3Jl IGVmZmljaWVudCBwYWNrZXRzLiAgSXQgTVVTVCwgYXMgZmFyIGFzIHBvc3NpYmxlLCByZXNwZWN0 IGFueQ0KPiAgICAgICBjb25zdHJhaW50cyBvbiBzdWNoIGRlbGF5cyByZXF1ZXN0ZWQgYnkgdGhl IHByb3RvY29sLg0KPg0KPiBBcmd1bWVudCBhZ2FpbnN0IHRoaXJkIGNvdXJzZSwgd2UndmUgc2Vl biBiZWZvcmUgdGhhdCBhbnl0aGluZyB0aGF0IGluY2x1ZGVzIHdvcmRpbmcgbGlrZSB0aGF0IGlz IG9wZW4gdG8gSUVTRyBub3QgYmVpbmcgaGFwcHkuDQo+DQo+IE9uIGJhbGFuY2UsIEkgdGhpbmsg U0hPVUxEIGlzIGFwcHJvcHJpYXRlLCBhc3N1bWluZyBTSE9VTEQgaXMgaW50ZXJwcmV0ZWQgYXMg aXQgc2hvdWxkIGJlIC0gZG8gdGhpcyB1bmxlc3MgdGhlcmUgcmVhbGx5IGlzIGEgZ29vZCByZWFz b24gbm90IHRvLiBCdXQgSSBjb3VsZCBsaXZlIHdpdGggYW55IG9mIHRoZSB0aHJlZSAoaWYgYWxs b3dlZCkuDQoNClNIT1VMRCB3b3VsZCBiZSBva2F5Li4uIGVzcGVjaWFsbHkgYmVjYXVzZSAobm9y bWFsbHkpIG11bHRpcGxleGVyDQp3b3VsZCByZXN0cmljdCB0aGUgYW1vdW50IG9mIGNvbnN0cmFp bnRzIG9mIHRoZSBwcm90b2NvbCBieSBpdHMgQVBJDQphbnl3YXlzLg0KDQpJTU8sIEl0IHNob3Vs ZCBzYXkgdGhhdCB0aGUgbXVsdGlwbGV4ZXIgTVVTVCBOT1QgZGVsYXkgbWVzc2FnZXMgaWYgdGhl IHByb3RvY29sIHJlcXVlc3QgY29uc3RyYWludHMgb24gZGVsYXkuIFdlIGRvbid0IHdhbnQgdG8g Y2hhbmdlIHRoZSBtdWx0aXBsZXhlciBpbnRvIGhhdmluZyBpdHMgb3duIHByb3RvY29sIHdpdGhv dXQgaGF2aW5nIGEgUkZDIGZvciBpdC4NCkFCDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50 IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQK cmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRo ZSBzZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9z ZSBub3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbi4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioK --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD9A6GLKXM0002VGREEN_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk11bHRpcGxleGVyIGVmZmljaWVuY3kgaXMgc3RyYWlnaHRm b3J3YXJkIC0gaWYgeW91IHB1dCB0d28gbWVzc2FnZXMgaW4gb25lIHBhY2tldCB5b3Ugc2F2ZSBh IHBhY2tldCB0cmFuc21pc3Npb24uIE9uIHNvbWUgTUFDcyBhcyBsb25nIGFzIHBhY2tldHMgYXJl IG9mIHJlYXNvbmFibGUNCiBzaXplLCB0aGUgcGFja2V0IHNpemUgaXMgcHJldHR5IGlycmVsZXZh bnQsIG9ubHkgdGhlIG51bWJlciBvZiBwYWNrZXRzIG1hdHRlcnMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZeKA mXMgYSBnb29kIHN5bmVyZ3kgb2YgdGhpcyB3aXRoIFJGQyA1MTQ4IGlmIHlvdSBhcmUgdXNpbmcg dGhhdCwgYnV0IHRoYXTigJlzIG5vdCB0aGUgc3ViamVjdCBoZXJlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5kIGFz IGZvciBjaGFuZ2luZyB0byBsb3dlciBjYXNlLCBkb27igJl0IGRvIHRoYXQuIEl0IGlzIG92ZXJ3 aGVsbWluZ2x5IGdvb2QgcHJhY3RpY2UgdGhhdCBpbiBub3JtYXRpdmUgc2VjdGlvbnMgb2YgYSBy ZXBvcnQsIHVzZSBNQVksIFNIT1VMRCwuIE1VU1QgZXRjLiBhcw0KIDIxMTkgdGVybXMgYW5kIGF2 b2lkIGFsbCBvdGhlciB1c2Ugb2YgdGhvc2Ugd29yZHMuIEJ1dCBoZXJlLCBhcyBJIGhhdmUgc2Fp ZCwgSSB0aGluayBTSE9VTEQgaXMgYXBwcm9wcmlhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMDA3RTdFIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNl bmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln ZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOyYjNDM7NDQgKDApMTI0NSAy NDIxOTQgJm5ic3A7fCAmbmJzcDs8Yj5FOg0KPC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFy bG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+PGJy Pg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1z IEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQg QmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93 d3cuYmFlc3lzdGVtcy5jb20vYWkiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFl c3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUg U3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBF bmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkg UmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWJk dXNzYWxhbSBCYXJ5dW4gW21haWx0bzphYmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiAxOCBBcHJpbCAyMDE2IDEzOjAzPGJyPg0KPGI+VG86PC9iPiBIZW5uaW5n IFJvZ2dlPGJyPg0KPGI+Q2M6PC9iPiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgbWFuZXRA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gUkZDIDU0NDQgdXNhZ2Ug LSBvbmUgc3BlY2lmaWMgcG9pbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQg YmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48 L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91 bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+ VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVp dGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2Vt PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFu eSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0K PGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9z cGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5S ZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3Ug cmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMu Y29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5w ZGYiPg0KaGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBp cyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50 LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9E ZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIj4NCnRoaXMgcHJvY2Vzczwv YT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMzMzM5NzIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gTW9uLCBBcHIgMTgsIDIwMTYgYXQgMTI6MTMgUE0sIEhlbm5pbmcgUm9nZ2Ug Jmx0OzxhIGhyZWY9Im1haWx0bzpocm9nZ2VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHJv Z2dlQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gTW9uLCBBcHIgMTgsIDIwMTYgYXQgMTE6MDcgQU0sIERlYXJsb3ZlLCBDaHJp c3RvcGhlciAoVUspPGJyPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3cm90ZTo8 YnI+DQomZ3Q7IFNvIGZhciBJIHNlZSBvbmUgc3BlY2lmaWMgcG9pbnQgZm9yIFdHIGFncmVlbWVu dCAtIGFueXRoaW5nIGVsc2UgaXMgZWRpdG9yaWFsLiAoRWRpdG9yaWFsIG1hdHRlcnMsIGJ1dCBp dCdzIG5vdCBjaGFuZ2luZyBydWxlcywgc28gSSdtIHRyeWluZyBoZXJlIHRvIGFkZHJlc3Mgb25l IHNwZWNpZmljIHJ1bGUgaXNzdWUuKSBTb21lIGNvbW1lbnRzIGhhdmUgY2xlYXJseSBvdmVybG9v a2VkIHRoaXMsIGJ1dCB3aGV0aGVyIHRvIHRlbGVncmFwaCBpdA0KIGZ1cnRoZXIgKGUuZy4gbWVu dGlvbiBpbiBub24tbm9ybWF0aXZlIGludHJvZHVjdGlvbikgaXMgYmFjayB0byBlZGl0b3JpYWwu PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIGRyYWZ0IGN1cnJlbnRseSBzYXlzOjxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBvJm5ic3A7IFRoZSBtdWx0aXBsZXhlciBNQVkgZGVsYXkg bWVzc2FnZXMgYnJpZWZseSBpbiBvcmRlciB0byBhc3NlbWJsZTxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDttb3JlIGVmZmljaWVudCBwYWNrZXRzLiZuYnNwOyBJdCBTSE9VTEQg cmVzcGVjdCBhbnkgY29uc3RyYWludHMgb24gc3VjaDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtkZWxheXMgcmVxdWVzdGVkIGJ5IHRoZSBwcm90b2NvbC48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBTaG91bGQgd2UgY2hhbmdlIHRoYXQgU0hPVUxEIHRvIGEgTVVTVD8gT2J2aW91c2x5 IElFVEYtc3R5bGUgd2UgZG9uJ3QgcnVuIHZvdGVzIGFzIHN1Y2gsIGJ1dCB3aGF0IGFyZSBwZW9w bGUncyBvcGluaW9ucz88YnI+DQo8YnI+DQpVbmxlc3Mgd2Ugc3BlY2lmeSB3aGF0IGtpbmQgb2Yg JnF1b3Q7Y29uc3RyYWludHMmcXVvdDsgYSBwcm90b2NvbCBjYW4gc3BlY2lmeSwgYTxicj4NCk1V U1Qgd291bGQgYmUgYSBiaXQgc3RyYW5nZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SU1PLCBJIHRoaW5r IGl0IGlzIG5vdCBlZmZpY2llbnQgdG8gZGVsYXkgbWVzc2FnZXMsIEkgdGhpbmsgaXQgaXMgc3Ry YW5nZSB0byBkZWxheSB3aXRob3V0IHNheWluZyBob3cgbXVjaCB0aGF0IG11bHRpcGxleGVyIGlz IGRlbGF5aW5nIHRvIGdldCB0byBlZmZpY2llbmN5LCBzbyBpdCBzZWVtcyB0aGF0IG11bHRpcGxl eGVyIGVmZmljaWVuY3kgaXMgbmVlZGVkDQogdG8gYmUgZGVmaW5lZCBiZWNhdXNlIGl0IGNhbiBi ZSBkaWZmZXJlbnQgdGhhbiBwcm90b2NvbCBlZmZpY2llbmN5LiA8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlZm9yZSwgSSB0aGluayB3ZSBz aG91bGQgY2hhbmdlIE1BWSB0byBtYXkgYW5kIFNIT1VMRCB0byBzaG91bGQsIG9yIGlmIG5vdCBj aGFuZ2VkIHdlIG5lZWQgdG8gc3BlY2lmeSBhIG1heGltdW0gZGVsYXkgZm9yIHRoZSBtdWx0aXBs ZXhlciwgYmVjYXVzZSBsZWF2aW5nIGl0IHdpdGhvdXQgbGltaXQgaXMgbm90IGNvcnJlY3QuPGJy Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQomZ3Q7IEFzIEkgc2VlIGl0Ojxicj4NCiZndDs8YnI+DQomZ3Q7IEFy Z3VtZW50IGZvciBNVVNUOiBJZiB0aGUgcHJvdG9jb2wgaGFzIHN0cm9uZyByZXF1aXJlbWVudHMg dGhlIG11bHRpcGxleGVyIG5lZWRzIHRvIHJlc3BlY3QgdGhvc2UuPGJyPg0KJmd0Ozxicj4NCiZn dDsgQXJndW1lbnQgZm9yIFNIT1VMRDogQnV0IHRoZSBwcm90b2NvbCBtaWdodCBtYWtlIGFuIGlt cG9zc2libGUgZGVtYW5kLCBzdWNoIGFzIHplcm8gZGVsYXkgd2hlbiB3ZSBhbGwga25vdyBub3Ro aW5nIGhhcyB6ZXJvIGRlbGF5LiBTSE9VTEQgaXNuJ3QgTUFZLCBpdCBuZWVkcyB0byBkbyBpdHMg YmVzdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBQb3NzaWJsZSB0aGlyZCBjb3Vyc2UsIHNvbWV0aGlu ZyBsaWtlIChvcGVuIHRvIHdvcmRzbWl0aGluZyAtIEkgY29uc2lkZXJlZCBwdXR0aW5nIHRoZSBj YXZlYXQgYXQgdGhlIGVuZCwgZm9yIGV4YW1wbGUpLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyBvJm5ic3A7IFRoZSBtdWx0aXBsZXhlciBNQVkgZGVsYXkgbWVzc2FnZXMgYnJpZWZs eSBpbiBvcmRlciB0byBhc3NlbWJsZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDttb3JlIGVmZmljaWVudCBwYWNrZXRzLiZuYnNwOyBJdCBNVVNULCBhcyBmYXIgYXMgcG9zc2li bGUsIHJlc3BlY3QgYW55PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbnN0 cmFpbnRzIG9uIHN1Y2ggZGVsYXlzIHJlcXVlc3RlZCBieSB0aGUgcHJvdG9jb2wuPGJyPg0KJmd0 Ozxicj4NCiZndDsgQXJndW1lbnQgYWdhaW5zdCB0aGlyZCBjb3Vyc2UsIHdlJ3ZlIHNlZW4gYmVm b3JlIHRoYXQgYW55dGhpbmcgdGhhdCBpbmNsdWRlcyB3b3JkaW5nIGxpa2UgdGhhdCBpcyBvcGVu IHRvIElFU0cgbm90IGJlaW5nIGhhcHB5Ljxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIGJhbGFuY2Us IEkgdGhpbmsgU0hPVUxEIGlzIGFwcHJvcHJpYXRlLCBhc3N1bWluZyBTSE9VTEQgaXMgaW50ZXJw cmV0ZWQgYXMgaXQgc2hvdWxkIGJlIC0gZG8gdGhpcyB1bmxlc3MgdGhlcmUgcmVhbGx5IGlzIGEg Z29vZCByZWFzb24gbm90IHRvLiBCdXQgSSBjb3VsZCBsaXZlIHdpdGggYW55IG9mIHRoZSB0aHJl ZSAoaWYgYWxsb3dlZCkuPGJyPg0KPGJyPg0KU0hPVUxEIHdvdWxkIGJlIG9rYXkuLi4gZXNwZWNp YWxseSBiZWNhdXNlIChub3JtYWxseSkgbXVsdGlwbGV4ZXI8YnI+DQp3b3VsZCByZXN0cmljdCB0 aGUgYW1vdW50IG9mIGNvbnN0cmFpbnRzIG9mIHRoZSBwcm90b2NvbCBieSBpdHMgQVBJPGJyPg0K YW55d2F5cy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SU1PLCBJdCBzaG91bGQg c2F5IHRoYXQgdGhlIG11bHRpcGxleGVyIE1VU1QgTk9UIGRlbGF5IG1lc3NhZ2VzIGlmIHRoZSBw cm90b2NvbCByZXF1ZXN0IGNvbnN0cmFpbnRzIG9uIGRlbGF5LiBXZSBkb24ndCB3YW50IHRvIGNo YW5nZSB0aGUgbXVsdGlwbGV4ZXIgaW50byBoYXZpbmcgaXRzIG93biBwcm90b2NvbCB3aXRob3V0 IGhhdmluZyBhIFJGQyBmb3IgaXQuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFCPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+ClRoaXMgZW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZDxicj4KcmVjaXBp ZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQ8YnI+CnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5v dGlmeSB0aGUgc2VuZGVyLjxicj4KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9y IGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcjxicj4KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMg dG8gYW55IG90aGVyIHBlcnNvbi48YnI+CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPC9wPjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AD9A6GLKXM0002VGREEN_-- From nobody Mon Apr 18 06:08:59 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 2E4CD12D1BF for ; Mon, 18 Apr 2016 06:08: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 JD7Y2gMCQ03d for ; Mon, 18 Apr 2016 06:08:48 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001: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 08EB412D141 for ; Mon, 18 Apr 2016 06:08:48 -0700 (PDT) Received: by mail-ig0-x22b.google.com with SMTP id g8so79050640igr.0 for ; Mon, 18 Apr 2016 06:08: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=ULpLt8PkMkRUFXmtIEsNJ+dL4ZutSJpzFVs6OhC13Y0=; b=0OEw+IsTXFI2rDvPBspVGuNOhYupsO/t9U0T8zcdQr4KEDW79iGEaD271ID4tfF6JD yRstOAYzL5TVUMrpONDQNI/T/S5FnbYSgHttpxPl4fpEqlvqz7pB6bVrMAf3p2x25431 m6cjYo55Asut6plsd17T84uckx94lRyPdbPvDDPs8TNixAqp3bkIWEoSwnCEBcoc21ho WnRBRYcwd14fFWJnuU3vtgxj8DutsBIZFPxe5VOMiwvVVcUpYrDak4ov8sSAcc8DO3ME Y5n5YtL05t4JDF1uRcD935pGd5pVf77cn8+h7QdhP3wXFNMoHCSttmVYSCNXNXv1ttVE p1/g== 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=ULpLt8PkMkRUFXmtIEsNJ+dL4ZutSJpzFVs6OhC13Y0=; b=BYw8DLc7hmmFs3cZmPuocgM73iMWSwn0aUnoMybMyMox+NUO9ikBeH5Q3HrAo40mZw rIUjko8H+k0rQqmOnNq5xMmqF/+TeT7PZi58VdkvOh9kGf60MH5xEBjKiyR8h3jzkcSw TMaJRN8gXjj8B9DvU1hyl4QA6//15m3MWC6JNwVbHqvobRB/pgvi1KhUyGRLOSVM3t8U qmAsyheiktLVJPps8b8xrVbWnFXGc5NzmXCqaafTH4JRVk/RpOMvHihbY68ceiPiwXPY bKGjhnZPCQ4UXdGI4FsD5G3aPuD3bgn7YcJXQXgzdZc3Acu4RlSB3LQjoosDr80yZWzr zulg== X-Gm-Message-State: AOPr4FV979fGMCu6JvfhJonVdzFHyO/9G6ZU5pDshZU2ZXQlTxvOHCSciGw4nbFWWU0gJEYwDNVFwtESMqjH1w== MIME-Version: 1.0 X-Received: by 10.50.33.225 with SMTP id u1mr5014099igi.36.1460984926982; Mon, 18 Apr 2016 06:08:46 -0700 (PDT) Received: by 10.79.72.68 with HTTP; Mon, 18 Apr 2016 06:08:46 -0700 (PDT) In-Reply-To: References: <45DFA343-1FDD-4EB9-9291-AB3A830A3CD9@mnemosyne.demon.co.uk> Date: Mon, 18 Apr 2016 09:08:46 -0400 Message-ID: From: Stan Ratliff To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=f46d044469c9986b3a0530c20fa7 Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" , Christopher Dearlove Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 18 Apr 2016 13:08:58 -0000 --f46d044469c9986b3a0530c20fa7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 18, 2016 at 4:52 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > I don=E2=80=99t believe we can or should suggest an implementation. That= =E2=80=99s not > what the IETF does, and it would be a hard, probably impossible, sell, to > the IESG. That the obvious implementation employs an independent parser i= s > already said - it may be appropriate to strengthen the words, but this > second I=E2=80=99m not sure if that=E2=80=99s needed (not got time to che= ck current > wording). > (Again, with my Working Group Participant hat on) - I don't mean to suggest an implementation. At least to me, this is an architecture (that of an independent parser, with a reliable communications mechanism to said parser, that deals with logical messages instead of packets. Is sequencing guaranteed? I'm not sure, to be honest. But once the independent parser is assumed, engineers also MUST assume that the transport (and it's the transport for control plane traffic, but not for data plane traffic), is "owned" by the independent parser. Which leads me to the other point I'm trying to make (perhaps badly): Abstracting the transport away from the control plane *can* effect protocol design. I believe both of these points should be addressed in the usage document. Regards, Stan > > > *-- * > > > > > *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 *Stan Ratliff > *Sent:* 16 April 2016 19:09 > *To:* Christopher Dearlove > *Cc:* manet@ietf.org; Christopher Dearlove > *Subject:* Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > > > > > **** 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 Fri, Apr 15, 2016 at 3:27 PM, Christopher Dearlove < > chris@mnemosyne.demon.co.uk> wrote: > > I don't understand what you mean by the concept of "fields the protocol > can and can't touch". > > > > CAVEAT: I am speaking here as a Working Group participant. With that > understood: > > > > > TTL is a great example, since that discussion blew the mailing list up a > few months ago. I'm *not* saying manipulating TTL is a good thing for a > protocol to try - in truth, I think it's pretty "hacky". But the notion w= as > floated, and in the context of that discussion, it may will have worked. > The opposition on-list was fast, and pretty forceful. > > I've said before - 5444, especially with the multiplexer, changes the > relationship between a routing protocol and an interface. I think the > document should have some type of "overview" section which discusses thes= e > differences, in order to frame the issue for someone coming along who > hasn't been a part of the 5444 mail discussion. > > I'm talking about the type of overview that goes something like this: > > "Use of RFC 5444 with the multiplexer feature imposes design requirements > on the protocol. The actual transport mechanism is abstracted from the > protocol. For example, routing protocols are not aware of precisely when = a > message is sent. A good example of operation in this model is [BGP], > utilizing the [TCP] transport. This is opposed to a protocol such as > [OSPF], which is capable of sending traffic with its own IP type. Since t= he > transport is abstracted, protocols are not presented with "packets", and > are not capable of manipulating data items in packet headers (e.g. data > items at the IP and/or MAC layers)." > > As Lou Berger put it to me in the context of DLEP - "You want an engineer > to be able to pick up this document, with no prior exposure to the topic, > and code an interoperable implementation." I think this type of an > overview, setting basic ground rules, would help. > > I've also contended for a while now that 5444, with the mux, effectively > forces an architecture on implementers - in the Linux world, that > architecture is a 5444 parser as an independent process, with IPC > mechanisms to the routing protocol(s) it is servicing. The 5444 parser > itself "owns" the transport (the socket). The usage document *strongly > infers* that. I believe we should concretely state it, so we don't have t= o > answer the question over and over again. > > Regards, > > Stan > > > > > > > When a protocol creates a message from scratch it's not constrained in an= y > way I'd describe in such terms. So I assume you mean when it receives a > message and then sends a similar message. > > > > There are two cases there. Unchanged (with the special exceptions for hop > count and limit) and not unchanged. The former is better, and there's > really nothing more to say. > > > > So let's consider the latter. Really it's not the same message, it's a > brand new message. That's a useful way to look at it from a security > perspective, because it tells you that end to end authentication isn't > going to work. And what are the restrictions on brand new messages? The > same as on any new message. > > > > OK, you might say, true but does that mean I can add this, remove that, > change the hop data? Yes. But is that a good idea? No. But maybe you are > forced into it. But that it's inherently not good suggests the corollary > that if you must, do the minimum and make it trackable. But that's not a > 5444 requirement, just good practice. It does break 7182 message ICVs, so > don't use them. > > > > We could, hypothetically, have someone create an extension or alternative > to 7182 that defined aggregated signatures. Then we'd have rules on what > you could change. But that would belong there. If you think those would b= e > good, then again you would want make minimal changes, and mainly only of > certain types. What types? There I can't help you as I don't have a > candidate. > > > > The summary? Don't change if you don't have to. That's recommended. If yo= u > must change you're on your own (with the same restrictions as new > messages). Advice like "as little as possible" is good, but that's not > actually 5444 advice. And don't use 7182 message ICVs. > > -- > > Christopher Dearlove > > christopher.dearlove@gmail.com (iPhone) > > chris@mnemosyne.demon.co.uk (home) > > > On 15 Apr 2016, at 19:37, Stan Ratliff wrote: > > My main concern addressed inline... > > > > > > On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlove < > christopher.dearlove@gmail.com> wrote: > > A few immediate comments inline below. > > -- > > Christopher Dearlove > > christopher.dearlove@gmail.com (iPhone) > > chris@mnemosyne.demon.co.uk (home) > > > On 15 Apr 2016, at 15:18, Lotte Steenbrink > wrote: > > Hi all, > > > > sparked by the recently started WGLC, I=E2=80=99ve reviewed the current r= evision > of the draft. I=E2=80=99d like to offer the working group my perspective = as someone > who doesn=E2=80=99t have decades of protocol and/or packet format design = under > their belt (i.e. some things might not be obvious to me that are obvious = to > others), but also as someone who has worked with RFC 5444 when implementi= ng > a routing protocol (AODVv2), updating the packet format of a routing > protocol (AODVv2 again) and (partially) implementing my own RFC5444 > builder/parser. > > > > Overall, I think the document is easy to read and follow. To me, it > contains valuable information and guidance and in some cases prevents > people from shooting themselves in the foot. > > I=E2=80=99m really happy this document exists and I=E2=80=99d like it to = move forward > soon, but I do feel that it is still lacking in some areas, which is why = I > was a bit surprised to see it go to Last Call all of a sudden. > > > > Not really. The authors had said what they intended to say, no one was > commenting, time for WGLC. > > > > First, some nitpicks and comments: > > > > * from *1.2.1* > *. > Packet/Message Format*: > > > > [=E2=80=A6] a packet > > transmission following a successful packet reception is by design > > of a new packet that may include all, some, or none of the > > received messages [...] > > > > I=E2=80=99m not a native speaker, but that =E2=80=9Eof=E2=80=9C seems out= of place... > > > > I am a native speaker, and no, it's not. Some would repeat it after each > of all, some and none, and I might sometimes. But it really doesn't matte= r > which of the two styles we pick, the RFC Editor may well change to the > other. > > > > * Regarding *4.2* > *. > Packets and Messages:* > > this section talks a lot about how the multiplexer operates, so I think > it=E2=80=99d be helpful if its title reflected that. > > > > I'm of two opinions on that. On the one hand it is, as its title suggests= , > about the packet and message level, as opposed to lower levels, and its > title contrasts with that if 4.3 for that reason. On the other hand you a= re > right, it does have much about the multiplexer. A title covering all thre= e > woukd start getting cumbersome. Will take this one away to think about. > > > > * from *4.4* > *. > Addresses Require Attributes:* > > > > An unmodified extension to NHDP would ignore such addresses, > > as required, as it does not support that specialized purpose. > > > > At first glance, (to me) this reads as =E2=80=9EAll addresses that are as= sociated > with an unknown TLV are ignored=E2=80=9C, which is obviously nonsense (bu= t quite > panic-inducing :D). I=E2=80=99d propose to reword it to something along t= he lines > of > > An unmodified extension to NHDP would not consider this > > address to be of a neighbor, as it is lacking a LINK_STATUS > > or OTHER_NEIGHB TLV. > > > > I take your point, but I think that if the address ends up with no > relevant associated TLVs then it is ignored is also a point. I dare say w= e > can wordsmith something. > > > > Also, I don=E2=80=99t quite get where you=E2=80=99re going with the last = paragraph of that > section (=E2=80=9CThese restrictions do not, however, mean that added inf= ormation > is > > completely ignored for purposes of the base protocol.=E2=80=9D)... > > > > Read on, the rest of the paragraph describes the case where not. But we > might telegraph that better in the opening sentence. > > > > * regarding the maps in *4.5* > *. > Information Representation:* > > I=E2=80=99m afraid I just don=E2=80=99t really understand the purpose of = this section and > the mapping notation. I=E2=80=99m assuming that the maps are supposed to = offer a > way of describing how a TLV relates to a message or an address? > > If so, why does it only mention extension types, but not the basis types? > > > > It says extended types, meaning the combination of the two. But full type > would be better, as almost defined in 5444. In fact I think we should add= a > comment to the notation section. (5444 uses a symbolic name rather than t= he > phrase.) > > > > Or is it supposed to be used something like this: > > > > *BASE_TLV* > > > > Message: > > (base_tlv_extension_type_1) -> (2 octets, "value a when condition x is > met") > > (base_tlv_extension_type_2) -> (2 octets, "value b when condition y is > met") > > > > ? Also, I don=E2=80=99t quite get how this would be used in future protoc= ol > specifications? Or aid in implementing RFC5444 parsers? > > An example or a clarification would be very helpful. > > > > It's a way of looking at things. But not the only one, it goes on to > discuss variants. I think it mostly comes under heading of if useful use > it, if not skip it. We'll take another look, but I don't think this will > ever be elementary. > > > > * regarding *4.6* > *. > TLVs:* > > In general, it=E2=80=99s not clear everywhere in the section whether you= =E2=80=99re > talking to RFC5444 parser/builder implementors or protocol designers. > > > > A protocol SHOULD use an efficient > > representation, but this is a quality of implementation issue. > > > > I=E2=80=99m not sure where you=E2=80=99re going with the last part of tha= t sentence? I=E2=80=99d > reword it to something like =E2=80=9EA protocol SHOULD use an efficient > representation, avoiding unnecessarily verbose use of TLVs and extension > types. However, the final arrangement in a message- or addressTLV block i= s > a quality of implementation issue=E2=80=9C (in case that=E2=80=99s what = you meant). > > > > No, you're considering the protocol design. This is considering the > protocol object that implements the protocol. There isn't a one to one > mapping from information to representation, it's up to the implementation > to do it efficiently. Different implementations of the same protocol > specification may do better or worse here. (Trivial case, an implementati= on > could choose to never compress addresses. Bad idea, but legal.) > > > > And then: > > > > A > > protocol MUST recognize any permitted representation of the > > information; even if it chooses to (for example) only use multivalue > > TLVs, it MUST recognize single value TLVs (and vice versa). > > > > =E2=80=A6 I thought protocols weren=E2=80=99t supposed to specify whether= a TLV is > arranged (for example) as a multivalue TLV?! > > > > Implementation again, not design. > > > > And so, since a protocol shouldn't be concerned with multivalue TLVs and > the like, wouldn=E2=80=99t it be the *RFC5444 implementation* that MUST r= ecognize > any permitted representation? > > > > You're assuming that there is an RFC 5444 implementation. That's the same > way to work if you plan to implement more than one protocol. But nothing > says you have to do it that way. The architecture defined by 5498 admits = of > the multiplexer and protocols, and thus these are rules on the protocol. = If > protocols delegate all their common work to something (parser/creator) th= en > it inherits those restrictions, but that's not defined, and we can't assu= me > it. > > > > Or is this paragraph really just a complicated way of saying =E2=80=9Eas = a > protocol designer, make sure to not specify/rely on things like (for > example) multivalue TLVs, since your messages have to work with *any* > representation=E2=80=9C? If so, I think that should be done in a less com= plicated > fashion (see below). > > > > * regarding *5* > = *. > Structure:* > > Since this section talks a lot about flags, it=E2=80=99d be nice if its t= itle > represented that. Maybe consider renaming it to =E2=80=9EStructure and Fl= ags=E2=80=9C or so? > > > > I mostly don't agree. Structure is the subject, flags are a detail. > > > > * from *6.1* > *. > Address Block Compression:* > > > > Compression of addresses in an Address Block considers addresses to > > consist of a Head, a Mid, and a Tail, where all addresses in an > > Address Block have the same Head and Tail, but different Mids. > > > > > > I=E2=80=99d find this sentence easier to read if it started with =E2=80= =9CCompression of > addresses in an Address Block is possible when addresses consist of a Hea= d, > a Mid [=E2=80=A6]=E2=80=9D. > > > > No. That's missing the point and misleading. Addresses are always > considered to have the head/mid/tail format. Compression is possible if > either the head or tail (or both) is non-empty. > > > > * from *6.1* > *. > Address Block Compression:* > > > > Putting addresses into a message efficiently also has to include: > > > > Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that would be a =E2=80=9E= may=E2=80=9C. Multiple Adress Blocks > and/or reordering don=E2=80=99t increase efficiency in all possible cases= ... > > > > I think that's the wrong change. Rather "include" should be "consider". > > > > * from *6.2* > *. > TLVs:* > > [...] This is even possible if the MPR TLV specified in > > OLSRv2 [RFC7181 ] is added; bu= t it is not possible, in general, if > > the LINK_METRIC TLV is also added. > > > > Why is it not possible for the latter? If that could be explained/hinted > at in a half sentence, I think it=E2=80=99d be helpful information to hav= e in the > draft. > > > > That's very hard, and not just because it's a negative. It's really an > observation that motivates the duscussion. A half sentence would I think > confuse more than it enlightens (it's because you have too many constrain= ts > to satisfy at once - I doubt that helped). > > > > In a typical case where a > > LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with > > enough addresses, sorted appropriately, two single value TLVs can > > be more efficient than one multivalue TLV. > > > > Same thing: why? > > > > Here I think this should be obvious to anyone who has looked at 5444. > > > > * regarding the second paragraph from *6.3* > *. > TLV Values*, i.e. > > > > This approach was specified in [RFC7188 ], and required for protocols > > that extend [RFC6130 ] and [RFC71= 81 ]. It is here RECOMMENDED that > > this approach is followed when defining any Address Block TLV that > > may be used by a protocol using [RFC5444 ]. > > > > The term =E2=80=9Ethis approach=E2=80=9C confused me, since I initially = thought it meant > =E2=80=9Ethe approach is to use UNSPECIFIED in a way that makes sense=E2= =80=9C rather than > =E2=80=9Ethe approach is to use UNSPECIFIED=E2=80=9C. Maybe that could be= reworded to > something along the lines of > > The UNSPECIFIED TLV and its usage was specified in [RFC7188]=E2=80=A6 > > ? > > > > No. There is no UNSPECIFIED TLV. There is a recommendation to include an > UNSPECIFIED value in a TLV. But really, we've described this once in 7188= , > it's there to read. > > > > * regarding *6.3* > *. > TLV Values:* > > The second paragraph is a bit confusing and seems to explaing roghly the > same things as the fourth paragraphs. I=E2=80=99d propose to merge the se= cond into > the fourth. > > > > I'm not sure I exactly agree, but the ordering in that section could be > improved. > > > > * from *6.4* > *. > Automation:* > > > > The possible gain depends on the efficiency > > of the original message creation, > > > > the term =E2=80=9Ethe original message creation=E2=80=9C seems a bit ambi= guous=E2=80=93 does this > refer to the message as created by an RFC5444 message builder > implementation? > > > > Yes. > > > > Additionally, I'm concerned about two things that *aren=E2=80=99t* in the= draft: > > > > * Some of the AODVv2 co-authors and me have asked for a list of =E2=80= =9Eas a > protocol, you can set all of these fields of a message, but please leave > the rest alone=E2=80=9C, which would=E2=80=99ve saved us many hours of di= scussions (and > Henning a lot of time spent explaining these things=E2=80=A6). These requ= ests have > been met with a refusal to specify a concrete API, as such an effort is > dependent on outside factors such as programming language or software > architecture. I agree with this notion, but a programming-language > dependent API is not what we=E2=80=99ve asked for. I=E2=80=99ve tried to = supply a sketch of > what I did ask for in [1], but unfortunately I didn=E2=80=99t get an answ= er (and as > far as I can see it, the draft wasn=E2=80=99t changed either). I still th= ink that > such a list, in whatever form, would be very helpful for future > Internet-Draft authors and I also think this request is in accordance wit= h > the intentions stated in 1.1 History and Purpose, and I think it should > be included in the document. > > > > No. There are many reasons why we're just not touching this one. > > > > One is that language independence is a mirage. How you go about things is > completely different in, for example an object oriented language than one > that isn't. Section 4.5 shows that there are quite different ways of doin= g > things even given a decision to use a map approach, and there are other > approaches than that. It would be wrong and beyond our competence to > suggest one of these as "best". There's reasons the IETF doesn't do this, > and that's one. > > > > Plus, frankly, the work it would take is beyond what we choose to spend. > > > > > > > > > > I'm confused (which is an altogether too common occurrence these days). I > get that we don't want to specify an API. But I think the discussion abou= t > fields a protocol can and can't touch in a messages is a good thing - and > it's one spot where I, too, find the document wanting. > > > > To paraphrase something I've said before, I believe that RFC 5444 changes > the relationship that a routing protocol has with an "interface". I'm not > commenting on whether or not that's a good thing, or a bad thing - just > that it does change the relationship. This change has been at the root of > some of the long-running discussions as to whether protocols under > development were RFC 5444 compliant or not. The goal of this document bei= ng > to eliminate (it's a goal, probably not reachable) those discussions, I'd > like to see that information in the document in some form. > > > > I'm interested in seeing this document progress, and eventually be > published. I think it will help future protocol designers to better use R= FC > 5444. But I would like to see *something* along the lines of what Lotte i= s > requesting, as I think it will improve the doc. > > > > Regards, > > Stan > > > > > > > > * As the exact rules for using/setting the hop count & hop-limit fields > are currently being discussed w/ regard to AODVv2 in another thread [2]= =E2=80=93 > should a definitive answer to that question be part of 5444-usage? > > > > You don't want that. Because if we did specify that you'd find yourself > more constrained than you want to be. There is a design intent described = in > 5444, but it assumes immutable messages. Which you don't want. Really, > we're doing you a favour by not imposing on you. > > > > Best regards, > > Lotte > > > > [1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.html > > [2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.html > > > > > > Am 06.04.2016 um 19:14 schrieb Justin Dean : > > > > The chairs agree that a 3 week WGLC is appropriate. Everyone please read > the draft early and get comments in early so that they can be addressed > within the last call period. > > > > Justin > > > > On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > Obviously +1 to the request for WGLC. > > With regard to what's changed, technically the only significant thing is > to make it clear that if a protocol delivers a message to the multiplexer= , > the multiplexer must pass it on unchanged to the protocol (another instan= ce > of, at another router) unchanged. Without that nothing that the protocol > itself chooses to do with regard to security makes sense. Though the > protocol can alternatively let the multiplexer do the security, 7182 can = be > implemented in either way. This isn't really new, but it wasn't formally > spelled out. It's presented as part of spelling out multiplexer rules mor= e > carefully. > > But what about message optimisation? That's a function of constructing a > 5444 message, not the multiplexer, and is down to that 5444 includes two > things - packet/message structure (and implicitly, and in pretty much any > implementation I would expect to see, a parser and builder for that > structure) and the multiplexer. So we took the opportunity to separate ou= t > more clearly a discussion of the two, which we think will be helpful. > > -- > 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 > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg > Sent: 05 April 2016 20:08 > To: manet@ietf.org > Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > ----------------------! WARNING ! ---------------------- This message > originates from outside our organisation, either from an external partner > or from the internet. > Consider carefully whether you should click on any links, open any > attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions > on reporting suspicious email messages. > -------------------------------------------------------- > > *** WARNING *** > EXTERNAL EMAIL -- This message originates from outside our organization. > > > > Hi, > > As you have seen, we have submitted a new revision of 5444-usage. The > authors feel comfortable that we have addressed all issues by this versio= n, > and would like to ask the WG chairs to issue a WGLC on this document. Whi= le > it is a fairly short document, given that it is IETF week for some, we'd > suggest that a 3-4 week WGLC would be appropriate. > > Best regards > Ulrich > > _______________________________________________ > 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 > > > > _______________________________________________ > 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 > > > > > --f46d044469c9986b3a0530c20fa7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 18, 2016 at 4:52 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

I don=E2=80=99t believe w= e can or should suggest an implementation. That=E2=80=99s not what the IETF= does, and it would be a hard, probably impossible, sell, to the IESG. That the obvious implementation employs an independent parser is already said -= it may be appropriate to strengthen the words, but this second I=E2=80=99m= not sure if that=E2=80=99s needed (not got time to check current wording).=


(Again, with my Wor= king Group Participant hat on) -=C2=A0

I don't= mean to suggest an implementation. At least to me, this is an architecture= (that of an independent parser, with a reliable communications mechanism t= o said parser, that deals with logical messages instead of packets. Is sequ= encing guaranteed? I'm not sure, to be honest. But once the independent= parser is assumed, engineers also MUST assume that the transport (and it&#= 39;s the transport for control plane traffic, but not for data plane traffi= c), is "owned" by the independent parser.=C2=A0

Which leads me to the other point I'm trying to make (perhaps b= adly): =C2=A0Abstracting the transport away from the control plane *can* ef= fect protocol design.=C2=A0

I believe both of thes= e points should be addressed in the usage document.=C2=A0

Regards,
Stan

=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: manet [mailto:manet-bounces@ietf.org] On Behalf Of Stan Ratliff
Sent: 16 April 2016 19:09
To: Christopher Dearlove
Cc: manet@ietf.o= rg; Christopher Dearlove
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage= -03

=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.=

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

=C2=A0

=C2=A0

=C2=A0

On Fri, Apr 15, 2016 at 3:27 PM, Christopher Dearlov= e <chri= s@mnemosyne.demon.co.uk> wrote:

I don't understand what you mean by the concept = of "fields the protocol can and can't touch".

=C2=A0<= /p>

CAVEAT: I am speaking here as a Working Group partic= ipant. With that understood:
=C2=A0

=C2=A0

TTL is a great exampl= e, since that discussion blew the mailing list up a few months ago. I'm= *not* saying manipulating TTL is a good thing for a protocol to try - in t= ruth, I think it's pretty "hacky". But the notion was floated, and in the context of that discussion, it may will hav= e worked. The opposition on-list was fast, and pretty forceful.

I've said before = - 5444, especially with the multiplexer, changes the relationship between a= routing protocol and an interface. I think the document should have some t= ype of "overview" section which discusses these differences, in order to frame the issue for someone coming along wh= o hasn't been a part of the 5444 mail discussion.

I'm talking about= the type of overview that goes something like this:

"Use of RFC 5444= with the multiplexer feature imposes design requirements on the protocol. = The actual transport mechanism is abstracted from the protocol. For example= , routing protocols are not aware of precisely when a message is sent. A good example of operation in this model is [BGP]= , utilizing the [TCP] transport. This is opposed to a protocol such as [OSP= F], which is capable of sending traffic with its own IP type. Since the tra= nsport is abstracted, protocols are not presented with "packets", and are not capable of manipul= ating data items in packet headers (e.g. data items at the IP and/or MAC la= yers)."

As Lou Berger put it to me in the context of DLEP - "You want an engin= eer to be able to pick up this document, with no prior exposure to the topi= c, and code an interoperable implementation."=C2=A0 I think this type = of an overview, setting basic ground rules, would help.

I've also contend= ed for a while now that 5444, with the mux, effectively forces an architect= ure on implementers - in the Linux world, that architecture is a 5444 parse= r as an independent process, with IPC mechanisms to the routing protocol(s) it is servicing. The 5444 parser itself "o= wns" the transport (the socket). The usage document *strongly infers* = that. I believe we should concretely state it, so we don't have to answ= er the question over and over again.

Regards,

Stan


=C2=A0

=C2=A0

When a protocol creates a message from scratch it= 9;s not constrained in any way I'd describe in such terms. So I assume = you mean when it receives a message and then sends a similar message.

=C2=A0

There are two cases there. Unchanged (with the speci= al exceptions for hop count and limit) and not unchanged. The former is bet= ter, and there's really nothing more to say.

=C2=A0

So let's consider the latter. Really it's no= t the same message, it's a brand new message. That's a useful way t= o look at it from a security perspective, because it tells you that end to = end authentication isn't going to work. And what are the restrictions on brand new messages? The same as on any new message.=

=C2=A0

OK, you might say, true but does that mean I can add= this, remove that, change the hop data? Yes. But is that a good idea? No. = But maybe you are forced into it. But that it's inherently not good sug= gests the corollary that if you must, do the minimum and make it trackable. But that's not a 5444 requiremen= t, just good practice. It does break 7182 message ICVs, so don't use th= em.

=C2=A0

We could, hypothetically, have someone create an ext= ension or alternative to 7182 that defined aggregated signatures. Then we&#= 39;d have rules on what you could change. But that would belong there. If y= ou think those would be good, then again you would want make minimal changes, and mainly only of certain types. Wha= t types? There I can't help you as I don't have a candidate.=

=C2=A0

The summary? Don't change if you don't have = to. That's recommended. If you must change you're on your own (with= the same restrictions as new messages). Advice like "as little as pos= sible" is good, but that's not actually 5444 advice. And don't use 7182 message ICVs.

-- =C2=A0

Christopher Dearlove


On 15 Apr 2016, at 19:37, Stan Ratliff <ratliffstan@gmail.com> wrote:

My main concern addressed inline...

=C2=A0

=C2=A0

On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlov= e <c= hristopher.dearlove@gmail.com> wrote:

A few immediate comments inline below.

-- =C2=A0

Christopher Dearlove


On 15 Apr 2016, at 15:18, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de>= ; wrote:

Hi all,

=C2=A0

sparked by the recently started WGLC, I=E2=80=99ve r= eviewed the current revision of the draft. I=E2=80=99d like to offer the wo= rking group my perspective as someone who doesn=E2=80=99t have decades of p= rotocol and/or packet format design under their belt (i.e. some things might not be obvious to me that are obvious to others), but al= so as someone who has worked with RFC 5444 when implementing a routing prot= ocol (AODVv2), updating the packet format of a routing protocol (AODVv2 aga= in) and (partially) implementing my own RFC5444 builder/parser.

=C2=A0

Overall, I think the document is easy to read and fo= llow. To me, it contains valuable information and guidance and in some case= s prevents people from shooting themselves in the foot.

I=E2=80=99m really happy this document exists and I= =E2=80=99d like it to move forward soon, but I do feel that it is still lac= king in some areas, which is why I was a bit surprised to see it go to Last= Call all of a sudden.

=C2=A0

Not really. The authors had said what they intended = to say, no one was commenting, time for WGLC.



First, some nitpicks and comments:

=C2=A0

* from=C2=A01.2.1. Packet/= Message Format:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0[=E2=80=A6] a packet

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 transmission following a successful pac=
ket reception is by design


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of a new packet that may include all, s=
ome, or none of the


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 received messages [...]

=C2=A0

I=E2=80=99m not a native speaker, but that =E2=80=9E= of=E2=80=9C seems out of place...

=C2=A0

I am a native speaker, and no, it's not. Some wo= uld repeat it after each of all, some and none, and I might sometimes. But = it really doesn't matter which of the two styles we pick, the RFC Edito= r may well change to the other.



* Regarding=C2=A04.2. Packet= s and Messages:

this section talks a lot about how the multiplexer o= perates, so I think it=E2=80=99d be helpful if its title reflected that.=C2= =A0

=C2=A0

I'm of two opinions on that. On the one hand it = is, as its title suggests, about the packet and message level, as opposed t= o lower levels, and its title contrasts with that if 4.3 for that reason. O= n the other hand you are right, it does have much about the multiplexer. A title covering all three woukd start ge= tting cumbersome. Will take this one away to think about.



* from=C2=A04.4. Addresses R= equire Attributes:

=C2=A0

=C2=A0=C2=A0 An unmodified extension to NHDP would ignore such address=
es,
=C2=A0=C2=A0 as required, as it does not support that specialized purp=
ose.

=C2=A0

At first glance, (to me) this reads as =E2=80=9EAll = addresses that are associated with an unknown TLV are ignored=E2=80=9C, whi= ch is obviously nonsense (but quite panic-inducing :D). I=E2=80=99d propose= to reword it to something along the lines of=C2=A0

=C2=A0=C2=A0 An unmodified extension to NHDP would not consider this
=C2=A0=C2=A0 address to be of a neighbor, as it is lacking a LINK_STAT=
US
=C2=A0=C2=A0 or OTHER_NEIGHB TLV.

=C2=A0

I take your point, but I think that if the address e= nds up with no relevant associated TLVs then it is ignored is also a point.= I dare say we can wordsmith something.



Also, I don=E2=80=99t quite get where you=E2=80=99re= going with the last paragraph of that section (=E2=80=9CThese restrictions do not, however, mean that added informat= ion is

=C2=A0=C2=A0 completely ignored for purposes of the base protocol.=E2=
=80=9D)...

=C2=A0

Read on, the rest of the paragraph describes the cas= e where not. But we might telegraph that better in the opening sentence.=



Or is it supposed to be used something like this:=

=C2=A0

BASE_TLV

=C2=A0

Message:=C2=A0

(base_tlv_extens= ion_type_1) -> (2 octets, "value a when condition x is met")

(base_tlv_extens= ion_type_2) -> (2 octets, "value b when condition y is met")

=C2=A0

? Also, I don=E2=80=99t quite get how this would be = used in future protocol specifications? Or aid in implementing RFC5444 pars= ers?

An example or a clarification would be very helpful.=

=C2=A0

It's a way of looking at things. But not the onl= y one, it goes on to discuss variants. I think it mostly comes under headin= g of if useful use it, if not skip it. We'll take another look, but I d= on't think this will ever be elementary.



* regarding=C2=A04.6. TLVs:<= /b>

In general, it=E2=80=99s not clear everywhere in the= section whether you=E2=80=99re talking to RFC5444 parser/builder implement= ors or protocol designers.=C2=A0

=C2=A0

=C2=A0=C2=A0 A protocol SHOULD use an efficient
=C2=A0=C2=A0 representation, but this is a quality of implementation i=
ssue.

=C2=A0

I=E2=80=99m not sure where you=E2=80=99re going with= the last part of that sentence? I=E2=80=99d reword it to something like = =E2=80=9EA protocol SHOULD use an efficient representation, avoiding unnece= ssarily verbose use of TLVs and extension types. However, the final arrangement in a message- or addressTLV block is =C2=A0a quality of implem= entation issue=E2=80=9C (in case that=E2=80=99s what you meant).<= /u>

=C2=A0

No, you're considering the protocol design. This= is considering the protocol object that implements the protocol. There isn= 't a one to one mapping from information to representation, it's up= to the implementation to do it efficiently. Different implementations of the same protocol specification may do better or worse = here. (Trivial case, an implementation could choose to never compress addre= sses. Bad idea, but legal.)



And then:

=C2=A0

=C2=A0=C2=A0 A
=C2=A0=C2=A0 protocol MUST recognize any permitted representation of t=
he
=C2=A0=C2=A0 information; even if it chooses to (for example) only use=
 multivalue
=C2=A0=C2=A0 TLVs, it MUST recognize single value TLVs (and vice versa=
).

=C2=A0

=E2=80=A6 I thought protocols weren=E2=80=99t suppos= ed to specify whether a TLV is arranged (for example) as a multivalue TLV?!=

=C2=A0

Implementation again, not design.



And so, since a protocol shouldn't be concerned = with multivalue TLVs and the like, wouldn=E2=80=99t it be the *RFC5444 impl= ementation* that MUST recognize any permitted representation?=

=C2=A0

You're assuming that there is an RFC 5444 implem= entation. That's the same way to work if you plan to implement more tha= n one protocol. But nothing says you have to do it that way. The architectu= re defined by 5498 admits of the multiplexer and protocols, and thus these are rules on the protocol. If protocols dele= gate all their common work to something (parser/creator) then it inherits t= hose restrictions, but that's not defined, and we can't assume it.<= u>



Or is this paragraph really just a complicated way o= f saying =E2=80=9Eas a protocol designer, make sure to not specify/rely on = things like (for example) multivalue TLVs, since your messages have to work= with *any* representation=E2=80=9C? If so, I think that should be done in a less complicated fashion (see below).

=C2=A0

* regarding=C2=A05. Structure:=

Since this section talks a lot about flags, it=E2=80= =99d be nice if its title represented that. Maybe consider renaming it to= =C2=A0=E2=80=9EStructure and Flags=E2=80=9C=C2=A0or so?

=C2=A0

I mostly don't agree. Structure is the subject, = flags are a detail.



* from=C2=A06.1. Address Blo= ck Compression:

=C2=A0

=C2=A0=C2=A0 Compression of addresses in an Address Block considers ad=
dresses to
=C2=A0=C2=A0 consist of a Head, a Mid, and a Tail, where all addresses=
 in an
=C2=A0=C2=A0 Address Block have the same Head and Tail, but different =
Mids.

=C2=A0

=C2=A0

I=E2=80=99d find this sentence easier to read if it = started with =E2=80=9CCompression of addresses in an Address Block is possi= ble when addresses consist of a Head, a Mid [=E2=80=A6]=E2=80=9D.=

=C2=A0

No. That's missing the point and misleading. Add= resses are always considered to have the head/mid/tail format. Compression = is possible if either the head or tail (or both) is non-empty.



* from=C2=A06.1. Address Blo= ck Compression:

=C2=A0
=C2=A0=C2=A0 Putting addresses into a message efficiently also has to =
include:
=C2=A0

Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that= would be a =E2=80=9Emay=E2=80=9C. Multiple Adress Blocks and/or reordering= don=E2=80=99t increase efficiency in all possible cases...

=C2=A0

I think that's the wrong change. Rather "in= clude" should be "consider".



* from=C2=A06.2. TLVs:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [...] This is even possible if the MPR =
TLV specified in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OLSRv2 [RFC7181] is added; but it is not poss=
ible, in general, if
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the LINK_METRIC TLV is also added.

=C2=A0

Why is it not possible for the latter? If that could= be explained/hinted at in a half sentence, I think it=E2=80=99d be helpful= information to have in the draft.

=C2=A0

That's very hard, and not just because it's = a negative. It's really an observation that motivates the duscussion. A= half sentence would I think confuse more than it enlightens (it's beca= use you have too many constraints to satisfy at once - I doubt that helped).



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In a typical case where a=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LINK_STATUS TLV uses only the Values HE=
ARD and SYMMETRIC, with
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enough addresses, sorted appropriately,=
 two single value TLVs can
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 be more efficient than one multivalue T=
LV.

=C2=A0

Same thing: why?

=C2=A0

Here I think this should be obvious to anyone who ha= s looked at 5444.



* regarding the second paragraph from=C2=A06= .3. TLV Values, i.e.

=C2=A0 =C2=A0
=C2=A0=C2=A0 This approach was specified in [RFC718=
8], and required for protocols
=C2=A0=C2=A0 that extend [RFC6130] and [RFC7181].=C2=A0 It is her=
e RECOMMENDED that
=C2=A0=C2=A0 this approach is followed when defining any Address Block=
 TLV that
=C2=A0=C2=A0 may be used by a protocol using [RFC5444].

=C2=A0

The term =E2=80=9Ethis approach=E2=80=9C confused me= , since I initially =C2=A0thought it meant =E2=80=9Ethe approach is to use = UNSPECIFIED in a way that makes sense=E2=80=9C rather than =E2=80=9Ethe app= roach is to use UNSPECIFIED=E2=80=9C. Maybe that could be reworded to somet= hing along the lines of=C2=A0

The UNSPECIFIED = TLV and its usage was specified in [RFC7188]=E2=80=A6=C2=A0

?

=C2=A0

No. There is no UNSPECIFIED TLV. There is a recommen= dation to include an UNSPECIFIED value in a TLV. But really, we've desc= ribed this once in 7188, it's there to read.



* regarding=C2=A06.3. TLV Va= lues:

The second paragraph is a bit confusing and seems to= explaing roghly the same things as the fourth paragraphs. I=E2=80=99d prop= ose to merge the second into the fourth.

=C2=A0

I'm not sure I exactly agree, but the ordering i= n that section could be improved.



* from=C2=A06.4. Automa= tion:

=C2=A0

=C2=A0=C2=A0 The possible gain depends on the efficiency=

=C2=A0=C2=A0 of the original message creation,

=C2=A0

the term =E2=80=9Ethe original message creation=E2= =80=9C seems a bit ambiguous=E2=80=93 does this refer to the message as cre= ated by an RFC5444 message builder implementation?

=C2=A0

Yes.



Additionally, I'm concerned about two things tha= t *aren=E2=80=99t* in the draft:

=C2=A0

* =C2=A0Some of the AODVv2 co-authors and me have as= ked for a list of =E2=80=9Eas a protocol, you can set all of these fields o= f a message, but please leave the rest alone=E2=80=9C, which would=E2=80=99= ve saved us many hours of discussions (and Henning a lot of time spent explaining these things=E2=80=A6). These requests have been met with= a refusal to specify a concrete API, as such an effort is dependent on out= side factors such as programming language or software architecture. I agree= with this notion, but a programming-language dependent API is not what we=E2=80=99ve asked for. I=E2=80=99ve tried to s= upply a sketch of what I did ask for in [1], but unfortunately I didn=E2=80= =99t get an answer (and as far as I can see it, the draft wasn=E2=80=99t ch= anged either). I still think that such a list, in whatever form, would be very helpful for future Internet-Draft authors and I also think t= his request is in accordance with the intentions stated in=C2=A01.1 History and Purpose,=C2=A0and I think i= t should be included in the document.

=C2=A0

No. There are many reasons why we're just not to= uching this one.

=C2=A0

One is that language independence is a mirage. How y= ou go about things is completely different in, for example an object orient= ed language than one that isn't. Section 4.5 shows that there are quite= different ways of doing things even given a decision to use a map approach, and there are other approaches than that= . It would be wrong and beyond our competence to suggest one of these as &q= uot;best". There's reasons the IETF doesn't do this, and that&= #39;s one.

=C2=A0

Plus, frankly, the work it would take is beyond what= we choose to spend.

=C2=A0

=C2=A0

<Speaking as a WG Participant>

=C2=A0

I'm confused (which is an altogether too common = occurrence these days). I get that we don't want to specify an API. But= I think the discussion about fields a protocol can and can't touch in = a messages is a good thing - and it's one spot where I, too, find the document wanting.=C2=A0

=C2=A0

To paraphrase something I've said before, I beli= eve that RFC 5444 changes the relationship that a routing protocol has with= an "interface". I'm not commenting on whether or not that= 9;s a good thing, or a bad thing - just that it does change the relationship. This change has been at the root of some of the long-run= ning discussions as to whether protocols under development were RFC 5444 co= mpliant or not. The goal of this document being to eliminate (it's a go= al, probably not reachable) those discussions, I'd like to see that information in the document in some form.=C2=A0

=C2=A0

I'm interested in seeing this document progress,= and eventually be published. I think it will help future protocol designer= s to better use RFC 5444. But I would like to see *something* along the lin= es of what Lotte is requesting, as I think it will improve the doc.=C2=A0

=C2=A0

Regards,

Stan

=C2=A0

=C2=A0



* As the exact rules for using/setting the hop count= & hop-limit fields are currently being discussed w/ regard to AODVv2 i= n another thread [2]=E2=80=93 should a definitive answer to that question b= e part of 5444-usage?

=C2=A0

You don't want that. Because if we did specify t= hat you'd find yourself more constrained than you want to be. There is = a design intent described in 5444, but it assumes immutable messages. Which= you don't want. Really, we're doing you a favour by not imposing on you.



=C2=A0

=C2=A0

Am 06.04.2016 um 19:14 schrieb Justin Dean <bebemaster@gmail.com>:

=C2=A0

The chairs agree that a 3 week WGLC is appropriate.= =C2=A0 Everyone please read the draft early and get comments in early so th= at they can be addressed within the last call period.

=C2=A0

Justin

=C2=A0

On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christophe= r (UK) <chris.dearlove@baesystems.com> wrote:

Obviously +1 to the request for WGLC.

With regard to what's changed, technically the only significant thing i= s to make it clear that if a protocol delivers a message to the multiplexer= , the multiplexer must pass it on unchanged to the protocol (another instan= ce of, at another router) unchanged. Without that nothing that the protocol itself chooses to do with regard to= security makes sense. Though the protocol can alternatively let the multip= lexer do the security, 7182 can be implemented in either way. This isn'= t really new, but it wasn't formally spelled out. It's presented as part of spelling out multiplexer rules = more carefully.

But what about message optimisation? That's a function of constructing = a 5444 message, not the multiplexer, and is down to that 5444 includes two = things - packet/message structure (and implicitly, and in pretty much any i= mplementation I would expect to see, a parser and builder for that structure) and the multiplexer. So we took t= he opportunity to separate out more clearly a discussion of the two, which = we think will be helpful.

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

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN.
www.baesystems.c= om/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 Ulrich Herberg
Sent: 05 April 2016 20:08
To: manet@ietf.org<= br> Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

----------------------! 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 instru= ctions on reporting suspicious email messages.
--------------------------------------------------------

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



Hi,

As you have seen, we have submitted a new revision of 5444-usage. The autho= rs feel comfortable that we have addressed all issues by this version, and = would like to ask the WG chairs to issue a WGLC on this document. While it = is a fairly short document, given that it is IETF week for some, we'd suggest that a 3-4 week WGLC would= be appropriate.

Best regards
Ulrich

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://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
h= ttps://www.ietf.org/mailman/listinfo/manet

=C2=A0

_______________________________________________
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


--f46d044469c9986b3a0530c20fa7-- From nobody Mon Apr 18 06:14: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 8ABE212B04F for ; Mon, 18 Apr 2016 06:14: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 uDesUpimam8w for ; Mon, 18 Apr 2016 06:14:03 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [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 86D9512D623 for ; Mon, 18 Apr 2016 06:13:39 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,502,1454976000"; d="scan'208,217"; a="61805434" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 18 Apr 2016 14:13:34 +0100 X-IronPort-AV: E=Sophos;i="5.24,502,1454976000"; d="scan'208,217";a="114421415" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 18 Apr 2016 14:13:33 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 14:13:33 +0100 From: "Dearlove, Christopher (UK)" To: Stan Ratliff Thread-Topic: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 Thread-Index: AQHRj26efzFsMll+IU2A0f8aUpvZOp980SWwgABO2gCADfPgAIAAOu8AgAANM4CAAZs2zoACiJ1wgAA3bACAABD7IA== Date: Mon, 18 Apr 2016 13:13:33 +0000 Message-ID: References: <45DFA343-1FDD-4EB9-9291-AB3A830A3CD9@mnemosyne.demon.co.uk> 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ADA83GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" , Christopher Dearlove Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 18 Apr 2016 13:14:12 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ADA83GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgaGFzIGJlZW4gcG9pbnRlZCBvdXQgdG8gbWUsIHNvbWUgaW1wbGVtZW50YXRpb25zIGRvbuKA mXQgZG8gdGhpcy4gSWYgeW91IGFyZSBidWlsZGluZyBhbiBpbXBsZW1lbnRhdGlvbiBpbiBhIGNv bnN0cmFpbmVkIGVudmlyb25tZW50LCB5b3UgY2FuIGJ1aWxkIGEgY29uc3RyYWluZWQgaW1wbGVt ZW50YXRpb24uIEFuZCBzb21lIHBlb3BsZSBoYXZlLg0KDQpTbyBubywgaXTigJlzIG5vdCBhcHBy b3ByaWF0ZSB0byBzcGVjaWZ5IGFuIGluZGVwZW5kZW50IHBhcnNlciwgb3IgcmVxdWlyZSBvbmUu IFJhdGhlciB5b3UgbmVlZCB0byBkZXNpZ24gc28gdGhhdCB3aGVuIHBlb3BsZSBkbywgaXQgY2Fu IGJlIGVmZmljaWVudC4gV2hpY2ggaXMgd2hhdCB3ZSBoYXZlIGJlZW4gZG9pbmcuDQoNCk9yIGlu IG90aGVyIHdvcmRzLCBJIGRvbuKAmXQgdGhpbmsgdGhpcyBzb3J0IG9mIGNoYW5nZSBpcyBhcHBy b3ByaWF0ZS4gUXVpdGUgdGhlIGNvbnRyYXJ5Lg0KDQpUaGUga2V5IHBvaW50IGlzIHRoYXQgd2hh dOKAmXMgbWFuZGF0ZWQgaXMgYSBtdWx0aXBsZXhlciBhbmQgYSBmb3JtYXQuIEJ1dCBub3QgYW4g aW5kZXBlbmRlbnQgcGFyc2VyLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQ cmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9y YXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAg RTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1z Zm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00y IDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2Fp Pg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBp biBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5 IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IFN0YW4g UmF0bGlmZiBbbWFpbHRvOnJhdGxpZmZzdGFuQGdtYWlsLmNvbV0NClNlbnQ6IDE4IEFwcmlsIDIw MTYgMTQ6MDkNClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IENocmlzdG9waGVy IERlYXJsb3ZlOyBtYW5ldEBpZXRmLm9yZzsgQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClN1YmplY3Q6 IFJlOiBbbWFuZXRdIFdHTEMgcmVxdWVzdCBmb3IgZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVz YWdlLTAzDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9t IG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5l ciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxk IGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3Ig aW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9y IGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJh ZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQl MjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFz ZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20v aG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIw U3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KDQoNCk9uIE1vbiwgQXByIDE4LCAyMDE2IGF0IDQ6 NTIgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PiB3cm90ZToNCkkg ZG9u4oCZdCBiZWxpZXZlIHdlIGNhbiBvciBzaG91bGQgc3VnZ2VzdCBhbiBpbXBsZW1lbnRhdGlv bi4gVGhhdOKAmXMgbm90IHdoYXQgdGhlIElFVEYgZG9lcywgYW5kIGl0IHdvdWxkIGJlIGEgaGFy ZCwgcHJvYmFibHkgaW1wb3NzaWJsZSwgc2VsbCwgdG8gdGhlIElFU0cuIFRoYXQgdGhlIG9idmlv dXMgaW1wbGVtZW50YXRpb24gZW1wbG95cyBhbiBpbmRlcGVuZGVudCBwYXJzZXIgaXMgYWxyZWFk eSBzYWlkIC0gaXQgbWF5IGJlIGFwcHJvcHJpYXRlIHRvIHN0cmVuZ3RoZW4gdGhlIHdvcmRzLCBi dXQgdGhpcyBzZWNvbmQgSeKAmW0gbm90IHN1cmUgaWYgdGhhdOKAmXMgbmVlZGVkIChub3QgZ290 IHRpbWUgdG8gY2hlY2sgY3VycmVudCB3b3JkaW5nKS4NCg0KKEFnYWluLCB3aXRoIG15IFdvcmtp bmcgR3JvdXAgUGFydGljaXBhbnQgaGF0IG9uKSAtDQoNCkkgZG9uJ3QgbWVhbiB0byBzdWdnZXN0 IGFuIGltcGxlbWVudGF0aW9uLiBBdCBsZWFzdCB0byBtZSwgdGhpcyBpcyBhbiBhcmNoaXRlY3R1 cmUgKHRoYXQgb2YgYW4gaW5kZXBlbmRlbnQgcGFyc2VyLCB3aXRoIGEgcmVsaWFibGUgY29tbXVu aWNhdGlvbnMgbWVjaGFuaXNtIHRvIHNhaWQgcGFyc2VyLCB0aGF0IGRlYWxzIHdpdGggbG9naWNh bCBtZXNzYWdlcyBpbnN0ZWFkIG9mIHBhY2tldHMuIElzIHNlcXVlbmNpbmcgZ3VhcmFudGVlZD8g SSdtIG5vdCBzdXJlLCB0byBiZSBob25lc3QuIEJ1dCBvbmNlIHRoZSBpbmRlcGVuZGVudCBwYXJz ZXIgaXMgYXNzdW1lZCwgZW5naW5lZXJzIGFsc28gTVVTVCBhc3N1bWUgdGhhdCB0aGUgdHJhbnNw b3J0IChhbmQgaXQncyB0aGUgdHJhbnNwb3J0IGZvciBjb250cm9sIHBsYW5lIHRyYWZmaWMsIGJ1 dCBub3QgZm9yIGRhdGEgcGxhbmUgdHJhZmZpYyksIGlzICJvd25lZCIgYnkgdGhlIGluZGVwZW5k ZW50IHBhcnNlci4NCg0KV2hpY2ggbGVhZHMgbWUgdG8gdGhlIG90aGVyIHBvaW50IEknbSB0cnlp bmcgdG8gbWFrZSAocGVyaGFwcyBiYWRseSk6ICBBYnN0cmFjdGluZyB0aGUgdHJhbnNwb3J0IGF3 YXkgZnJvbSB0aGUgY29udHJvbCBwbGFuZSAqY2FuKiBlZmZlY3QgcHJvdG9jb2wgZGVzaWduLg0K DQpJIGJlbGlldmUgYm90aCBvZiB0aGVzZSBwb2ludHMgc2hvdWxkIGJlIGFkZHJlc3NlZCBpbiB0 aGUgdXNhZ2UgZG9jdW1lbnQuDQoNClJlZ2FyZHMsDQpTdGFuDQoNCg0KDQotLQ0KQ2hyaXN0b3Bo ZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxp ZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0 NCAoMCkxMjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4gIHwgIEU6 IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2Zv cmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4 SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4N CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4g RW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBS ZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBtYW5ldCBb bWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5v cmc+XSBPbiBCZWhhbGYgT2YgU3RhbiBSYXRsaWZmDQpTZW50OiAxNiBBcHJpbCAyMDE2IDE5OjA5 DQpUbzogQ2hyaXN0b3BoZXIgRGVhcmxvdmUNCkNjOiBtYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFu ZXRAaWV0Zi5vcmc+OyBDaHJpc3RvcGhlciBEZWFybG92ZQ0KU3ViamVjdDogUmU6IFttYW5ldF0g V0dMQyByZXF1ZXN0IGZvciBkcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMNCg0KDQoq KiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIg b3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRl cm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55 IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiBy ZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlv dSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20v aG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4u DQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlz IHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2Vj dXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIw RW1haWxzLnBkZj4uDQoqKiogV0FSTklORyAqKioNCkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVz c2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uLg0KDQoNCg0KT24g RnJpLCBBcHIgMTUsIDIwMTYgYXQgMzoyNyBQTSwgQ2hyaXN0b3BoZXIgRGVhcmxvdmUgPGNocmlz QG1uZW1vc3luZS5kZW1vbi5jby51azxtYWlsdG86Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVr Pj4gd3JvdGU6DQpJIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbiBieSB0aGUgY29uY2Vw dCBvZiAiZmllbGRzIHRoZSBwcm90b2NvbCBjYW4gYW5kIGNhbid0IHRvdWNoIi4NCg0KQ0FWRUFU OiBJIGFtIHNwZWFraW5nIGhlcmUgYXMgYSBXb3JraW5nIEdyb3VwIHBhcnRpY2lwYW50LiBXaXRo IHRoYXQgdW5kZXJzdG9vZDoNCg0KDQpUVEwgaXMgYSBncmVhdCBleGFtcGxlLCBzaW5jZSB0aGF0 IGRpc2N1c3Npb24gYmxldyB0aGUgbWFpbGluZyBsaXN0IHVwIGEgZmV3IG1vbnRocyBhZ28uIEkn bSAqbm90KiBzYXlpbmcgbWFuaXB1bGF0aW5nIFRUTCBpcyBhIGdvb2QgdGhpbmcgZm9yIGEgcHJv dG9jb2wgdG8gdHJ5IC0gaW4gdHJ1dGgsIEkgdGhpbmsgaXQncyBwcmV0dHkgImhhY2t5Ii4gQnV0 IHRoZSBub3Rpb24gd2FzIGZsb2F0ZWQsIGFuZCBpbiB0aGUgY29udGV4dCBvZiB0aGF0IGRpc2N1 c3Npb24sIGl0IG1heSB3aWxsIGhhdmUgd29ya2VkLiBUaGUgb3Bwb3NpdGlvbiBvbi1saXN0IHdh cyBmYXN0LCBhbmQgcHJldHR5IGZvcmNlZnVsLg0KSSd2ZSBzYWlkIGJlZm9yZSAtIDU0NDQsIGVz cGVjaWFsbHkgd2l0aCB0aGUgbXVsdGlwbGV4ZXIsIGNoYW5nZXMgdGhlIHJlbGF0aW9uc2hpcCBi ZXR3ZWVuIGEgcm91dGluZyBwcm90b2NvbCBhbmQgYW4gaW50ZXJmYWNlLiBJIHRoaW5rIHRoZSBk b2N1bWVudCBzaG91bGQgaGF2ZSBzb21lIHR5cGUgb2YgIm92ZXJ2aWV3IiBzZWN0aW9uIHdoaWNo IGRpc2N1c3NlcyB0aGVzZSBkaWZmZXJlbmNlcywgaW4gb3JkZXIgdG8gZnJhbWUgdGhlIGlzc3Vl IGZvciBzb21lb25lIGNvbWluZyBhbG9uZyB3aG8gaGFzbid0IGJlZW4gYSBwYXJ0IG9mIHRoZSA1 NDQ0IG1haWwgZGlzY3Vzc2lvbi4NCkknbSB0YWxraW5nIGFib3V0IHRoZSB0eXBlIG9mIG92ZXJ2 aWV3IHRoYXQgZ29lcyBzb21ldGhpbmcgbGlrZSB0aGlzOg0KIlVzZSBvZiBSRkMgNTQ0NCB3aXRo IHRoZSBtdWx0aXBsZXhlciBmZWF0dXJlIGltcG9zZXMgZGVzaWduIHJlcXVpcmVtZW50cyBvbiB0 aGUgcHJvdG9jb2wuIFRoZSBhY3R1YWwgdHJhbnNwb3J0IG1lY2hhbmlzbSBpcyBhYnN0cmFjdGVk IGZyb20gdGhlIHByb3RvY29sLiBGb3IgZXhhbXBsZSwgcm91dGluZyBwcm90b2NvbHMgYXJlIG5v dCBhd2FyZSBvZiBwcmVjaXNlbHkgd2hlbiBhIG1lc3NhZ2UgaXMgc2VudC4gQSBnb29kIGV4YW1w bGUgb2Ygb3BlcmF0aW9uIGluIHRoaXMgbW9kZWwgaXMgW0JHUF0sIHV0aWxpemluZyB0aGUgW1RD UF0gdHJhbnNwb3J0LiBUaGlzIGlzIG9wcG9zZWQgdG8gYSBwcm90b2NvbCBzdWNoIGFzIFtPU1BG XSwgd2hpY2ggaXMgY2FwYWJsZSBvZiBzZW5kaW5nIHRyYWZmaWMgd2l0aCBpdHMgb3duIElQIHR5 cGUuIFNpbmNlIHRoZSB0cmFuc3BvcnQgaXMgYWJzdHJhY3RlZCwgcHJvdG9jb2xzIGFyZSBub3Qg cHJlc2VudGVkIHdpdGggInBhY2tldHMiLCBhbmQgYXJlIG5vdCBjYXBhYmxlIG9mIG1hbmlwdWxh dGluZyBkYXRhIGl0ZW1zIGluIHBhY2tldCBoZWFkZXJzIChlLmcuIGRhdGEgaXRlbXMgYXQgdGhl IElQIGFuZC9vciBNQUMgbGF5ZXJzKS4iDQoNCkFzIExvdSBCZXJnZXIgcHV0IGl0IHRvIG1lIGlu IHRoZSBjb250ZXh0IG9mIERMRVAgLSAiWW91IHdhbnQgYW4gZW5naW5lZXIgdG8gYmUgYWJsZSB0 byBwaWNrIHVwIHRoaXMgZG9jdW1lbnQsIHdpdGggbm8gcHJpb3IgZXhwb3N1cmUgdG8gdGhlIHRv cGljLCBhbmQgY29kZSBhbiBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9uLiIgIEkgdGhpbmsg dGhpcyB0eXBlIG9mIGFuIG92ZXJ2aWV3LCBzZXR0aW5nIGJhc2ljIGdyb3VuZCBydWxlcywgd291 bGQgaGVscC4NCkkndmUgYWxzbyBjb250ZW5kZWQgZm9yIGEgd2hpbGUgbm93IHRoYXQgNTQ0NCwg d2l0aCB0aGUgbXV4LCBlZmZlY3RpdmVseSBmb3JjZXMgYW4gYXJjaGl0ZWN0dXJlIG9uIGltcGxl bWVudGVycyAtIGluIHRoZSBMaW51eCB3b3JsZCwgdGhhdCBhcmNoaXRlY3R1cmUgaXMgYSA1NDQ0 IHBhcnNlciBhcyBhbiBpbmRlcGVuZGVudCBwcm9jZXNzLCB3aXRoIElQQyBtZWNoYW5pc21zIHRv IHRoZSByb3V0aW5nIHByb3RvY29sKHMpIGl0IGlzIHNlcnZpY2luZy4gVGhlIDU0NDQgcGFyc2Vy IGl0c2VsZiAib3ducyIgdGhlIHRyYW5zcG9ydCAodGhlIHNvY2tldCkuIFRoZSB1c2FnZSBkb2N1 bWVudCAqc3Ryb25nbHkgaW5mZXJzKiB0aGF0LiBJIGJlbGlldmUgd2Ugc2hvdWxkIGNvbmNyZXRl bHkgc3RhdGUgaXQsIHNvIHdlIGRvbid0IGhhdmUgdG8gYW5zd2VyIHRoZSBxdWVzdGlvbiBvdmVy IGFuZCBvdmVyIGFnYWluLg0KUmVnYXJkcywNClN0YW4NCg0KDQoNCldoZW4gYSBwcm90b2NvbCBj cmVhdGVzIGEgbWVzc2FnZSBmcm9tIHNjcmF0Y2ggaXQncyBub3QgY29uc3RyYWluZWQgaW4gYW55 IHdheSBJJ2QgZGVzY3JpYmUgaW4gc3VjaCB0ZXJtcy4gU28gSSBhc3N1bWUgeW91IG1lYW4gd2hl biBpdCByZWNlaXZlcyBhIG1lc3NhZ2UgYW5kIHRoZW4gc2VuZHMgYSBzaW1pbGFyIG1lc3NhZ2Uu DQoNClRoZXJlIGFyZSB0d28gY2FzZXMgdGhlcmUuIFVuY2hhbmdlZCAod2l0aCB0aGUgc3BlY2lh bCBleGNlcHRpb25zIGZvciBob3AgY291bnQgYW5kIGxpbWl0KSBhbmQgbm90IHVuY2hhbmdlZC4g VGhlIGZvcm1lciBpcyBiZXR0ZXIsIGFuZCB0aGVyZSdzIHJlYWxseSBub3RoaW5nIG1vcmUgdG8g c2F5Lg0KDQpTbyBsZXQncyBjb25zaWRlciB0aGUgbGF0dGVyLiBSZWFsbHkgaXQncyBub3QgdGhl IHNhbWUgbWVzc2FnZSwgaXQncyBhIGJyYW5kIG5ldyBtZXNzYWdlLiBUaGF0J3MgYSB1c2VmdWwg d2F5IHRvIGxvb2sgYXQgaXQgZnJvbSBhIHNlY3VyaXR5IHBlcnNwZWN0aXZlLCBiZWNhdXNlIGl0 IHRlbGxzIHlvdSB0aGF0IGVuZCB0byBlbmQgYXV0aGVudGljYXRpb24gaXNuJ3QgZ29pbmcgdG8g d29yay4gQW5kIHdoYXQgYXJlIHRoZSByZXN0cmljdGlvbnMgb24gYnJhbmQgbmV3IG1lc3NhZ2Vz PyBUaGUgc2FtZSBhcyBvbiBhbnkgbmV3IG1lc3NhZ2UuDQoNCk9LLCB5b3UgbWlnaHQgc2F5LCB0 cnVlIGJ1dCBkb2VzIHRoYXQgbWVhbiBJIGNhbiBhZGQgdGhpcywgcmVtb3ZlIHRoYXQsIGNoYW5n ZSB0aGUgaG9wIGRhdGE/IFllcy4gQnV0IGlzIHRoYXQgYSBnb29kIGlkZWE/IE5vLiBCdXQgbWF5 YmUgeW91IGFyZSBmb3JjZWQgaW50byBpdC4gQnV0IHRoYXQgaXQncyBpbmhlcmVudGx5IG5vdCBn b29kIHN1Z2dlc3RzIHRoZSBjb3JvbGxhcnkgdGhhdCBpZiB5b3UgbXVzdCwgZG8gdGhlIG1pbmlt dW0gYW5kIG1ha2UgaXQgdHJhY2thYmxlLiBCdXQgdGhhdCdzIG5vdCBhIDU0NDQgcmVxdWlyZW1l bnQsIGp1c3QgZ29vZCBwcmFjdGljZS4gSXQgZG9lcyBicmVhayA3MTgyIG1lc3NhZ2UgSUNWcywg c28gZG9uJ3QgdXNlIHRoZW0uDQoNCldlIGNvdWxkLCBoeXBvdGhldGljYWxseSwgaGF2ZSBzb21l b25lIGNyZWF0ZSBhbiBleHRlbnNpb24gb3IgYWx0ZXJuYXRpdmUgdG8gNzE4MiB0aGF0IGRlZmlu ZWQgYWdncmVnYXRlZCBzaWduYXR1cmVzLiBUaGVuIHdlJ2QgaGF2ZSBydWxlcyBvbiB3aGF0IHlv dSBjb3VsZCBjaGFuZ2UuIEJ1dCB0aGF0IHdvdWxkIGJlbG9uZyB0aGVyZS4gSWYgeW91IHRoaW5r IHRob3NlIHdvdWxkIGJlIGdvb2QsIHRoZW4gYWdhaW4geW91IHdvdWxkIHdhbnQgbWFrZSBtaW5p bWFsIGNoYW5nZXMsIGFuZCBtYWlubHkgb25seSBvZiBjZXJ0YWluIHR5cGVzLiBXaGF0IHR5cGVz PyBUaGVyZSBJIGNhbid0IGhlbHAgeW91IGFzIEkgZG9uJ3QgaGF2ZSBhIGNhbmRpZGF0ZS4NCg0K VGhlIHN1bW1hcnk/IERvbid0IGNoYW5nZSBpZiB5b3UgZG9uJ3QgaGF2ZSB0by4gVGhhdCdzIHJl Y29tbWVuZGVkLiBJZiB5b3UgbXVzdCBjaGFuZ2UgeW91J3JlIG9uIHlvdXIgb3duICh3aXRoIHRo ZSBzYW1lIHJlc3RyaWN0aW9ucyBhcyBuZXcgbWVzc2FnZXMpLiBBZHZpY2UgbGlrZSAiYXMgbGl0 dGxlIGFzIHBvc3NpYmxlIiBpcyBnb29kLCBidXQgdGhhdCdzIG5vdCBhY3R1YWxseSA1NDQ0IGFk dmljZS4gQW5kIGRvbid0IHVzZSA3MTgyIG1lc3NhZ2UgSUNWcy4NCg0KLS0NCkNocmlzdG9waGVy IERlYXJsb3ZlDQpjaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb208bWFpbHRvOmNocmlzdG9w aGVyLmRlYXJsb3ZlQGdtYWlsLmNvbT4gKGlQaG9uZSkNCmNocmlzQG1uZW1vc3luZS5kZW1vbi5j by51azxtYWlsdG86Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrPiAoaG9tZSkNCg0KT24gMTUg QXByIDIwMTYsIGF0IDE5OjM3LCBTdGFuIFJhdGxpZmYgPHJhdGxpZmZzdGFuQGdtYWlsLmNvbTxt YWlsdG86cmF0bGlmZnN0YW5AZ21haWwuY29tPj4gd3JvdGU6DQpNeSBtYWluIGNvbmNlcm4gYWRk cmVzc2VkIGlubGluZS4uLg0KDQoNCk9uIEZyaSwgQXByIDE1LCAyMDE2IGF0IDE6NDkgUE0sIENo cmlzdG9waGVyIERlYXJsb3ZlIDxjaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb208bWFpbHRv OmNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNvbT4+IHdyb3RlOg0KQSBmZXcgaW1tZWRpYXRl IGNvbW1lbnRzIGlubGluZSBiZWxvdy4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpjaHJp c3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb208bWFpbHRvOmNocmlzdG9waGVyLmRlYXJsb3ZlQGdt YWlsLmNvbT4gKGlQaG9uZSkNCmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51azxtYWlsdG86Y2hy aXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrPiAoaG9tZSkNCg0KT24gMTUgQXByIDIwMTYsIGF0IDE1 OjE4LCBMb3R0ZSBTdGVlbmJyaW5rIDxsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZTxtYWls dG86bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4uZGU+PiB3cm90ZToNCkhpIGFsbCwNCg0Kc3Bh cmtlZCBieSB0aGUgcmVjZW50bHkgc3RhcnRlZCBXR0xDLCBJ4oCZdmUgcmV2aWV3ZWQgdGhlIGN1 cnJlbnQgcmV2aXNpb24gb2YgdGhlIGRyYWZ0LiBJ4oCZZCBsaWtlIHRvIG9mZmVyIHRoZSB3b3Jr aW5nIGdyb3VwIG15IHBlcnNwZWN0aXZlIGFzIHNvbWVvbmUgd2hvIGRvZXNu4oCZdCBoYXZlIGRl Y2FkZXMgb2YgcHJvdG9jb2wgYW5kL29yIHBhY2tldCBmb3JtYXQgZGVzaWduIHVuZGVyIHRoZWly IGJlbHQgKGkuZS4gc29tZSB0aGluZ3MgbWlnaHQgbm90IGJlIG9idmlvdXMgdG8gbWUgdGhhdCBh cmUgb2J2aW91cyB0byBvdGhlcnMpLCBidXQgYWxzbyBhcyBzb21lb25lIHdobyBoYXMgd29ya2Vk IHdpdGggUkZDIDU0NDQgd2hlbiBpbXBsZW1lbnRpbmcgYSByb3V0aW5nIHByb3RvY29sIChBT0RW djIpLCB1cGRhdGluZyB0aGUgcGFja2V0IGZvcm1hdCBvZiBhIHJvdXRpbmcgcHJvdG9jb2wgKEFP RFZ2MiBhZ2FpbikgYW5kIChwYXJ0aWFsbHkpIGltcGxlbWVudGluZyBteSBvd24gUkZDNTQ0NCBi dWlsZGVyL3BhcnNlci4NCg0KT3ZlcmFsbCwgSSB0aGluayB0aGUgZG9jdW1lbnQgaXMgZWFzeSB0 byByZWFkIGFuZCBmb2xsb3cuIFRvIG1lLCBpdCBjb250YWlucyB2YWx1YWJsZSBpbmZvcm1hdGlv biBhbmQgZ3VpZGFuY2UgYW5kIGluIHNvbWUgY2FzZXMgcHJldmVudHMgcGVvcGxlIGZyb20gc2hv b3RpbmcgdGhlbXNlbHZlcyBpbiB0aGUgZm9vdC4NCknigJltIHJlYWxseSBoYXBweSB0aGlzIGRv Y3VtZW50IGV4aXN0cyBhbmQgSeKAmWQgbGlrZSBpdCB0byBtb3ZlIGZvcndhcmQgc29vbiwgYnV0 IEkgZG8gZmVlbCB0aGF0IGl0IGlzIHN0aWxsIGxhY2tpbmcgaW4gc29tZSBhcmVhcywgd2hpY2gg aXMgd2h5IEkgd2FzIGEgYml0IHN1cnByaXNlZCB0byBzZWUgaXQgZ28gdG8gTGFzdCBDYWxsIGFs bCBvZiBhIHN1ZGRlbi4NCg0KTm90IHJlYWxseS4gVGhlIGF1dGhvcnMgaGFkIHNhaWQgd2hhdCB0 aGV5IGludGVuZGVkIHRvIHNheSwgbm8gb25lIHdhcyBjb21tZW50aW5nLCB0aW1lIGZvciBXR0xD Lg0KDQpGaXJzdCwgc29tZSBuaXRwaWNrcyBhbmQgY29tbWVudHM6DQoNCiogZnJvbSAxLjIuMTxo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdl LTAzI3NlY3Rpb24tMS4yLjE+LiBQYWNrZXQvTWVzc2FnZSBGb3JtYXQ6DQoNCg0KICAgICAgW+KA pl0gYSBwYWNrZXQNCg0KICAgICAgdHJhbnNtaXNzaW9uIGZvbGxvd2luZyBhIHN1Y2Nlc3NmdWwg cGFja2V0IHJlY2VwdGlvbiBpcyBieSBkZXNpZ24NCg0KICAgICAgb2YgYSBuZXcgcGFja2V0IHRo YXQgbWF5IGluY2x1ZGUgYWxsLCBzb21lLCBvciBub25lIG9mIHRoZQ0KDQogICAgICByZWNlaXZl ZCBtZXNzYWdlcyBbLi4uXQ0KDQpJ4oCZbSBub3QgYSBuYXRpdmUgc3BlYWtlciwgYnV0IHRoYXQg 4oCeb2bigJwgc2VlbXMgb3V0IG9mIHBsYWNlLi4uDQoNCkkgYW0gYSBuYXRpdmUgc3BlYWtlciwg YW5kIG5vLCBpdCdzIG5vdC4gU29tZSB3b3VsZCByZXBlYXQgaXQgYWZ0ZXIgZWFjaCBvZiBhbGws IHNvbWUgYW5kIG5vbmUsIGFuZCBJIG1pZ2h0IHNvbWV0aW1lcy4gQnV0IGl0IHJlYWxseSBkb2Vz bid0IG1hdHRlciB3aGljaCBvZiB0aGUgdHdvIHN0eWxlcyB3ZSBwaWNrLCB0aGUgUkZDIEVkaXRv ciBtYXkgd2VsbCBjaGFuZ2UgdG8gdGhlIG90aGVyLg0KDQoqIFJlZ2FyZGluZyA0LjI8aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNz ZWN0aW9uLTQuMj4uIFBhY2tldHMgYW5kIE1lc3NhZ2VzOg0KdGhpcyBzZWN0aW9uIHRhbGtzIGEg bG90IGFib3V0IGhvdyB0aGUgbXVsdGlwbGV4ZXIgb3BlcmF0ZXMsIHNvIEkgdGhpbmsgaXTigJlk IGJlIGhlbHBmdWwgaWYgaXRzIHRpdGxlIHJlZmxlY3RlZCB0aGF0Lg0KDQpJJ20gb2YgdHdvIG9w aW5pb25zIG9uIHRoYXQuIE9uIHRoZSBvbmUgaGFuZCBpdCBpcywgYXMgaXRzIHRpdGxlIHN1Z2dl c3RzLCBhYm91dCB0aGUgcGFja2V0IGFuZCBtZXNzYWdlIGxldmVsLCBhcyBvcHBvc2VkIHRvIGxv d2VyIGxldmVscywgYW5kIGl0cyB0aXRsZSBjb250cmFzdHMgd2l0aCB0aGF0IGlmIDQuMyBmb3Ig dGhhdCByZWFzb24uIE9uIHRoZSBvdGhlciBoYW5kIHlvdSBhcmUgcmlnaHQsIGl0IGRvZXMgaGF2 ZSBtdWNoIGFib3V0IHRoZSBtdWx0aXBsZXhlci4gQSB0aXRsZSBjb3ZlcmluZyBhbGwgdGhyZWUg d291a2Qgc3RhcnQgZ2V0dGluZyBjdW1iZXJzb21lLiBXaWxsIHRha2UgdGhpcyBvbmUgYXdheSB0 byB0aGluayBhYm91dC4NCg0KKiBmcm9tIDQuNDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNC40Pi4gQWRkcmVzc2Vz IFJlcXVpcmUgQXR0cmlidXRlczoNCg0KDQogICBBbiB1bm1vZGlmaWVkIGV4dGVuc2lvbiB0byBO SERQIHdvdWxkIGlnbm9yZSBzdWNoIGFkZHJlc3NlcywNCg0KICAgYXMgcmVxdWlyZWQsIGFzIGl0 IGRvZXMgbm90IHN1cHBvcnQgdGhhdCBzcGVjaWFsaXplZCBwdXJwb3NlLg0KDQpBdCBmaXJzdCBn bGFuY2UsICh0byBtZSkgdGhpcyByZWFkcyBhcyDigJ5BbGwgYWRkcmVzc2VzIHRoYXQgYXJlIGFz c29jaWF0ZWQgd2l0aCBhbiB1bmtub3duIFRMViBhcmUgaWdub3JlZOKAnCwgd2hpY2ggaXMgb2J2 aW91c2x5IG5vbnNlbnNlIChidXQgcXVpdGUgcGFuaWMtaW5kdWNpbmcgOkQpLiBJ4oCZZCBwcm9w b3NlIHRvIHJld29yZCBpdCB0byBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mDQoNCiAgIEFu IHVubW9kaWZpZWQgZXh0ZW5zaW9uIHRvIE5IRFAgd291bGQgbm90IGNvbnNpZGVyIHRoaXMNCg0K ICAgYWRkcmVzcyB0byBiZSBvZiBhIG5laWdoYm9yLCBhcyBpdCBpcyBsYWNraW5nIGEgTElOS19T VEFUVVMNCg0KICAgb3IgT1RIRVJfTkVJR0hCIFRMVi4NCg0KSSB0YWtlIHlvdXIgcG9pbnQsIGJ1 dCBJIHRoaW5rIHRoYXQgaWYgdGhlIGFkZHJlc3MgZW5kcyB1cCB3aXRoIG5vIHJlbGV2YW50IGFz c29jaWF0ZWQgVExWcyB0aGVuIGl0IGlzIGlnbm9yZWQgaXMgYWxzbyBhIHBvaW50LiBJIGRhcmUg c2F5IHdlIGNhbiB3b3Jkc21pdGggc29tZXRoaW5nLg0KDQpBbHNvLCBJIGRvbuKAmXQgcXVpdGUg Z2V0IHdoZXJlIHlvdeKAmXJlIGdvaW5nIHdpdGggdGhlIGxhc3QgcGFyYWdyYXBoIG9mIHRoYXQg c2VjdGlvbiAo4oCcVGhlc2UgcmVzdHJpY3Rpb25zIGRvIG5vdCwgaG93ZXZlciwgbWVhbiB0aGF0 IGFkZGVkIGluZm9ybWF0aW9uIGlzDQoNCiAgIGNvbXBsZXRlbHkgaWdub3JlZCBmb3IgcHVycG9z ZXMgb2YgdGhlIGJhc2UgcHJvdG9jb2wu4oCdKS4uLg0KDQpSZWFkIG9uLCB0aGUgcmVzdCBvZiB0 aGUgcGFyYWdyYXBoIGRlc2NyaWJlcyB0aGUgY2FzZSB3aGVyZSBub3QuIEJ1dCB3ZSBtaWdodCB0 ZWxlZ3JhcGggdGhhdCBiZXR0ZXIgaW4gdGhlIG9wZW5pbmcgc2VudGVuY2UuDQoNCiogcmVnYXJk aW5nIHRoZSBtYXBzIGluIDQuNTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNC41Pi4gSW5mb3JtYXRpb24gUmVwcmVz ZW50YXRpb246DQpJ4oCZbSBhZnJhaWQgSSBqdXN0IGRvbuKAmXQgcmVhbGx5IHVuZGVyc3RhbmQg dGhlIHB1cnBvc2Ugb2YgdGhpcyBzZWN0aW9uIGFuZCB0aGUgbWFwcGluZyBub3RhdGlvbi4gSeKA mW0gYXNzdW1pbmcgdGhhdCB0aGUgbWFwcyBhcmUgc3VwcG9zZWQgdG8gb2ZmZXIgYSB3YXkgb2Yg ZGVzY3JpYmluZyBob3cgYSBUTFYgcmVsYXRlcyB0byBhIG1lc3NhZ2Ugb3IgYW4gYWRkcmVzcz8N CklmIHNvLCB3aHkgZG9lcyBpdCBvbmx5IG1lbnRpb24gZXh0ZW5zaW9uIHR5cGVzLCBidXQgbm90 IHRoZSBiYXNpcyB0eXBlcz8NCg0KSXQgc2F5cyBleHRlbmRlZCB0eXBlcywgbWVhbmluZyB0aGUg Y29tYmluYXRpb24gb2YgdGhlIHR3by4gQnV0IGZ1bGwgdHlwZSB3b3VsZCBiZSBiZXR0ZXIsIGFz IGFsbW9zdCBkZWZpbmVkIGluIDU0NDQuIEluIGZhY3QgSSB0aGluayB3ZSBzaG91bGQgYWRkIGEg Y29tbWVudCB0byB0aGUgbm90YXRpb24gc2VjdGlvbi4gKDU0NDQgdXNlcyBhIHN5bWJvbGljIG5h bWUgcmF0aGVyIHRoYW4gdGhlIHBocmFzZS4pDQoNCk9yIGlzIGl0IHN1cHBvc2VkIHRvIGJlIHVz ZWQgc29tZXRoaW5nIGxpa2UgdGhpczoNCg0KQkFTRV9UTFYNCg0KTWVzc2FnZToNCihiYXNlX3Rs dl9leHRlbnNpb25fdHlwZV8xKSAtPiAoMiBvY3RldHMsICJ2YWx1ZSBhIHdoZW4gY29uZGl0aW9u IHggaXMgbWV0IikNCihiYXNlX3Rsdl9leHRlbnNpb25fdHlwZV8yKSAtPiAoMiBvY3RldHMsICJ2 YWx1ZSBiIHdoZW4gY29uZGl0aW9uIHkgaXMgbWV0IikNCg0KPyBBbHNvLCBJIGRvbuKAmXQgcXVp dGUgZ2V0IGhvdyB0aGlzIHdvdWxkIGJlIHVzZWQgaW4gZnV0dXJlIHByb3RvY29sIHNwZWNpZmlj YXRpb25zPyBPciBhaWQgaW4gaW1wbGVtZW50aW5nIFJGQzU0NDQgcGFyc2Vycz8NCkFuIGV4YW1w bGUgb3IgYSBjbGFyaWZpY2F0aW9uIHdvdWxkIGJlIHZlcnkgaGVscGZ1bC4NCg0KSXQncyBhIHdh eSBvZiBsb29raW5nIGF0IHRoaW5ncy4gQnV0IG5vdCB0aGUgb25seSBvbmUsIGl0IGdvZXMgb24g dG8gZGlzY3VzcyB2YXJpYW50cy4gSSB0aGluayBpdCBtb3N0bHkgY29tZXMgdW5kZXIgaGVhZGlu ZyBvZiBpZiB1c2VmdWwgdXNlIGl0LCBpZiBub3Qgc2tpcCBpdC4gV2UnbGwgdGFrZSBhbm90aGVy IGxvb2ssIGJ1dCBJIGRvbid0IHRoaW5rIHRoaXMgd2lsbCBldmVyIGJlIGVsZW1lbnRhcnkuDQoN CiogcmVnYXJkaW5nIDQuNjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1t YW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNC42Pi4gVExWczoNCkluIGdlbmVyYWwsIGl0 4oCZcyBub3QgY2xlYXIgZXZlcnl3aGVyZSBpbiB0aGUgc2VjdGlvbiB3aGV0aGVyIHlvdeKAmXJl IHRhbGtpbmcgdG8gUkZDNTQ0NCBwYXJzZXIvYnVpbGRlciBpbXBsZW1lbnRvcnMgb3IgcHJvdG9j b2wgZGVzaWduZXJzLg0KDQoNCiAgIEEgcHJvdG9jb2wgU0hPVUxEIHVzZSBhbiBlZmZpY2llbnQN Cg0KICAgcmVwcmVzZW50YXRpb24sIGJ1dCB0aGlzIGlzIGEgcXVhbGl0eSBvZiBpbXBsZW1lbnRh dGlvbiBpc3N1ZS4NCg0KSeKAmW0gbm90IHN1cmUgd2hlcmUgeW914oCZcmUgZ29pbmcgd2l0aCB0 aGUgbGFzdCBwYXJ0IG9mIHRoYXQgc2VudGVuY2U/IEnigJlkIHJld29yZCBpdCB0byBzb21ldGhp bmcgbGlrZSDigJ5BIHByb3RvY29sIFNIT1VMRCB1c2UgYW4gZWZmaWNpZW50IHJlcHJlc2VudGF0 aW9uLCBhdm9pZGluZyB1bm5lY2Vzc2FyaWx5IHZlcmJvc2UgdXNlIG9mIFRMVnMgYW5kIGV4dGVu c2lvbiB0eXBlcy4gSG93ZXZlciwgdGhlIGZpbmFsIGFycmFuZ2VtZW50IGluIGEgbWVzc2FnZS0g b3IgYWRkcmVzc1RMViBibG9jayBpcyAgYSBxdWFsaXR5IG9mIGltcGxlbWVudGF0aW9uIGlzc3Vl 4oCcIChpbiBjYXNlIHRoYXTigJlzIHdoYXQgeW91IG1lYW50KS4NCg0KTm8sIHlvdSdyZSBjb25z aWRlcmluZyB0aGUgcHJvdG9jb2wgZGVzaWduLiBUaGlzIGlzIGNvbnNpZGVyaW5nIHRoZSBwcm90 b2NvbCBvYmplY3QgdGhhdCBpbXBsZW1lbnRzIHRoZSBwcm90b2NvbC4gVGhlcmUgaXNuJ3QgYSBv bmUgdG8gb25lIG1hcHBpbmcgZnJvbSBpbmZvcm1hdGlvbiB0byByZXByZXNlbnRhdGlvbiwgaXQn cyB1cCB0byB0aGUgaW1wbGVtZW50YXRpb24gdG8gZG8gaXQgZWZmaWNpZW50bHkuIERpZmZlcmVu dCBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIHNhbWUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBtYXkg ZG8gYmV0dGVyIG9yIHdvcnNlIGhlcmUuIChUcml2aWFsIGNhc2UsIGFuIGltcGxlbWVudGF0aW9u IGNvdWxkIGNob29zZSB0byBuZXZlciBjb21wcmVzcyBhZGRyZXNzZXMuIEJhZCBpZGVhLCBidXQg bGVnYWwuKQ0KDQpBbmQgdGhlbjoNCg0KDQogICBBDQoNCiAgIHByb3RvY29sIE1VU1QgcmVjb2du aXplIGFueSBwZXJtaXR0ZWQgcmVwcmVzZW50YXRpb24gb2YgdGhlDQoNCiAgIGluZm9ybWF0aW9u OyBldmVuIGlmIGl0IGNob29zZXMgdG8gKGZvciBleGFtcGxlKSBvbmx5IHVzZSBtdWx0aXZhbHVl DQoNCiAgIFRMVnMsIGl0IE1VU1QgcmVjb2duaXplIHNpbmdsZSB2YWx1ZSBUTFZzIChhbmQgdmlj ZSB2ZXJzYSkuDQoNCuKApiBJIHRob3VnaHQgcHJvdG9jb2xzIHdlcmVu4oCZdCBzdXBwb3NlZCB0 byBzcGVjaWZ5IHdoZXRoZXIgYSBUTFYgaXMgYXJyYW5nZWQgKGZvciBleGFtcGxlKSBhcyBhIG11 bHRpdmFsdWUgVExWPyENCg0KSW1wbGVtZW50YXRpb24gYWdhaW4sIG5vdCBkZXNpZ24uDQoNCkFu ZCBzbywgc2luY2UgYSBwcm90b2NvbCBzaG91bGRuJ3QgYmUgY29uY2VybmVkIHdpdGggbXVsdGl2 YWx1ZSBUTFZzIGFuZCB0aGUgbGlrZSwgd291bGRu4oCZdCBpdCBiZSB0aGUgKlJGQzU0NDQgaW1w bGVtZW50YXRpb24qIHRoYXQgTVVTVCByZWNvZ25pemUgYW55IHBlcm1pdHRlZCByZXByZXNlbnRh dGlvbj8NCg0KWW91J3JlIGFzc3VtaW5nIHRoYXQgdGhlcmUgaXMgYW4gUkZDIDU0NDQgaW1wbGVt ZW50YXRpb24uIFRoYXQncyB0aGUgc2FtZSB3YXkgdG8gd29yayBpZiB5b3UgcGxhbiB0byBpbXBs ZW1lbnQgbW9yZSB0aGFuIG9uZSBwcm90b2NvbC4gQnV0IG5vdGhpbmcgc2F5cyB5b3UgaGF2ZSB0 byBkbyBpdCB0aGF0IHdheS4gVGhlIGFyY2hpdGVjdHVyZSBkZWZpbmVkIGJ5IDU0OTggYWRtaXRz IG9mIHRoZSBtdWx0aXBsZXhlciBhbmQgcHJvdG9jb2xzLCBhbmQgdGh1cyB0aGVzZSBhcmUgcnVs ZXMgb24gdGhlIHByb3RvY29sLiBJZiBwcm90b2NvbHMgZGVsZWdhdGUgYWxsIHRoZWlyIGNvbW1v biB3b3JrIHRvIHNvbWV0aGluZyAocGFyc2VyL2NyZWF0b3IpIHRoZW4gaXQgaW5oZXJpdHMgdGhv c2UgcmVzdHJpY3Rpb25zLCBidXQgdGhhdCdzIG5vdCBkZWZpbmVkLCBhbmQgd2UgY2FuJ3QgYXNz dW1lIGl0Lg0KDQpPciBpcyB0aGlzIHBhcmFncmFwaCByZWFsbHkganVzdCBhIGNvbXBsaWNhdGVk IHdheSBvZiBzYXlpbmcg4oCeYXMgYSBwcm90b2NvbCBkZXNpZ25lciwgbWFrZSBzdXJlIHRvIG5v dCBzcGVjaWZ5L3JlbHkgb24gdGhpbmdzIGxpa2UgKGZvciBleGFtcGxlKSBtdWx0aXZhbHVlIFRM VnMsIHNpbmNlIHlvdXIgbWVzc2FnZXMgaGF2ZSB0byB3b3JrIHdpdGggKmFueSogcmVwcmVzZW50 YXRpb27igJw/IElmIHNvLCBJIHRoaW5rIHRoYXQgc2hvdWxkIGJlIGRvbmUgaW4gYSBsZXNzIGNv bXBsaWNhdGVkIGZhc2hpb24gKHNlZSBiZWxvdykuDQoNCiogcmVnYXJkaW5nIDU8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0 aW9uLTU+LiBTdHJ1Y3R1cmU6DQpTaW5jZSB0aGlzIHNlY3Rpb24gdGFsa3MgYSBsb3QgYWJvdXQg ZmxhZ3MsIGl04oCZZCBiZSBuaWNlIGlmIGl0cyB0aXRsZSByZXByZXNlbnRlZCB0aGF0LiBNYXli ZSBjb25zaWRlciByZW5hbWluZyBpdCB0byDigJ5TdHJ1Y3R1cmUgYW5kIEZsYWdz4oCcIG9yIHNv Pw0KDQpJIG1vc3RseSBkb24ndCBhZ3JlZS4gU3RydWN0dXJlIGlzIHRoZSBzdWJqZWN0LCBmbGFn cyBhcmUgYSBkZXRhaWwuDQoNCiogZnJvbSA2LjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTYuMT4uIEFkZHJlc3Mg QmxvY2sgQ29tcHJlc3Npb246DQoNCg0KICAgQ29tcHJlc3Npb24gb2YgYWRkcmVzc2VzIGluIGFu IEFkZHJlc3MgQmxvY2sgY29uc2lkZXJzIGFkZHJlc3NlcyB0bw0KDQogICBjb25zaXN0IG9mIGEg SGVhZCwgYSBNaWQsIGFuZCBhIFRhaWwsIHdoZXJlIGFsbCBhZGRyZXNzZXMgaW4gYW4NCg0KICAg QWRkcmVzcyBCbG9jayBoYXZlIHRoZSBzYW1lIEhlYWQgYW5kIFRhaWwsIGJ1dCBkaWZmZXJlbnQg TWlkcy4NCg0KDQpJ4oCZZCBmaW5kIHRoaXMgc2VudGVuY2UgZWFzaWVyIHRvIHJlYWQgaWYgaXQg c3RhcnRlZCB3aXRoIOKAnENvbXByZXNzaW9uIG9mIGFkZHJlc3NlcyBpbiBhbiBBZGRyZXNzIEJs b2NrIGlzIHBvc3NpYmxlIHdoZW4gYWRkcmVzc2VzIGNvbnNpc3Qgb2YgYSBIZWFkLCBhIE1pZCBb 4oCmXeKAnS4NCg0KTm8uIFRoYXQncyBtaXNzaW5nIHRoZSBwb2ludCBhbmQgbWlzbGVhZGluZy4g QWRkcmVzc2VzIGFyZSBhbHdheXMgY29uc2lkZXJlZCB0byBoYXZlIHRoZSBoZWFkL21pZC90YWls IGZvcm1hdC4gQ29tcHJlc3Npb24gaXMgcG9zc2libGUgaWYgZWl0aGVyIHRoZSBoZWFkIG9yIHRh aWwgKG9yIGJvdGgpIGlzIG5vbi1lbXB0eS4NCg0KKiBmcm9tIDYuMTxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi4x Pi4gQWRkcmVzcyBCbG9jayBDb21wcmVzc2lvbjoNCg0KDQoNCiAgIFB1dHRpbmcgYWRkcmVzc2Vz IGludG8gYSBtZXNzYWdlIGVmZmljaWVudGx5IGFsc28gaGFzIHRvIGluY2x1ZGU6DQoNCg0KV2h5 IOKAnmhhcyB0b+KAnD8gSeKAmWQgdGhpbmsgdGhhdCB3b3VsZCBiZSBhIOKAnm1heeKAnC4gTXVs dGlwbGUgQWRyZXNzIEJsb2NrcyBhbmQvb3IgcmVvcmRlcmluZyBkb27igJl0IGluY3JlYXNlIGVm ZmljaWVuY3kgaW4gYWxsIHBvc3NpYmxlIGNhc2VzLi4uDQoNCkkgdGhpbmsgdGhhdCdzIHRoZSB3 cm9uZyBjaGFuZ2UuIFJhdGhlciAiaW5jbHVkZSIgc2hvdWxkIGJlICJjb25zaWRlciIuDQoNCiog ZnJvbSA2LjI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZj NTQ0NC11c2FnZS0wMyNzZWN0aW9uLTYuMj4uIFRMVnM6DQoNCiAgICAgIFsuLi5dIFRoaXMgaXMg ZXZlbiBwb3NzaWJsZSBpZiB0aGUgTVBSIFRMViBzcGVjaWZpZWQgaW4NCg0KICAgICAgT0xTUnYy IFtSRkM3MTgxPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTgxPl0gaXMgYWRkZWQ7 IGJ1dCBpdCBpcyBub3QgcG9zc2libGUsIGluIGdlbmVyYWwsIGlmDQoNCiAgICAgIHRoZSBMSU5L X01FVFJJQyBUTFYgaXMgYWxzbyBhZGRlZC4NCg0KV2h5IGlzIGl0IG5vdCBwb3NzaWJsZSBmb3Ig dGhlIGxhdHRlcj8gSWYgdGhhdCBjb3VsZCBiZSBleHBsYWluZWQvaGludGVkIGF0IGluIGEgaGFs ZiBzZW50ZW5jZSwgSSB0aGluayBpdOKAmWQgYmUgaGVscGZ1bCBpbmZvcm1hdGlvbiB0byBoYXZl IGluIHRoZSBkcmFmdC4NCg0KVGhhdCdzIHZlcnkgaGFyZCwgYW5kIG5vdCBqdXN0IGJlY2F1c2Ug aXQncyBhIG5lZ2F0aXZlLiBJdCdzIHJlYWxseSBhbiBvYnNlcnZhdGlvbiB0aGF0IG1vdGl2YXRl cyB0aGUgZHVzY3Vzc2lvbi4gQSBoYWxmIHNlbnRlbmNlIHdvdWxkIEkgdGhpbmsgY29uZnVzZSBt b3JlIHRoYW4gaXQgZW5saWdodGVucyAoaXQncyBiZWNhdXNlIHlvdSBoYXZlIHRvbyBtYW55IGNv bnN0cmFpbnRzIHRvIHNhdGlzZnkgYXQgb25jZSAtIEkgZG91YnQgdGhhdCBoZWxwZWQpLg0KDQoN CiAgICAgIEluIGEgdHlwaWNhbCBjYXNlIHdoZXJlIGENCg0KICAgICAgTElOS19TVEFUVVMgVExW IHVzZXMgb25seSB0aGUgVmFsdWVzIEhFQVJEIGFuZCBTWU1NRVRSSUMsIHdpdGgNCg0KICAgICAg ZW5vdWdoIGFkZHJlc3Nlcywgc29ydGVkIGFwcHJvcHJpYXRlbHksIHR3byBzaW5nbGUgdmFsdWUg VExWcyBjYW4NCg0KICAgICAgYmUgbW9yZSBlZmZpY2llbnQgdGhhbiBvbmUgbXVsdGl2YWx1ZSBU TFYuDQoNClNhbWUgdGhpbmc6IHdoeT8NCg0KSGVyZSBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIG9i dmlvdXMgdG8gYW55b25lIHdobyBoYXMgbG9va2VkIGF0IDU0NDQuDQoNCiogcmVnYXJkaW5nIHRo ZSBzZWNvbmQgcGFyYWdyYXBoIGZyb20gNi4zPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi02LjM+LiBUTFYgVmFsdWVz LCBpLmUuDQoNCg0KDQogICBUaGlzIGFwcHJvYWNoIHdhcyBzcGVjaWZpZWQgaW4gW1JGQzcxODg8 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcxODg+XSwgYW5kIHJlcXVpcmVkIGZvciBw cm90b2NvbHMNCg0KICAgdGhhdCBleHRlbmQgW1JGQzYxMzA8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzYxMzA+XSBhbmQgW1JGQzcxODE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzcxODE+XS4gIEl0IGlzIGhlcmUgUkVDT01NRU5ERUQgdGhhdA0KDQogICB0aGlzIGFwcHJv YWNoIGlzIGZvbGxvd2VkIHdoZW4gZGVmaW5pbmcgYW55IEFkZHJlc3MgQmxvY2sgVExWIHRoYXQN Cg0KICAgbWF5IGJlIHVzZWQgYnkgYSBwcm90b2NvbCB1c2luZyBbUkZDNTQ0NDxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNTQ0ND5dLg0KDQpUaGUgdGVybSDigJ50aGlzIGFwcHJvYWNo 4oCcIGNvbmZ1c2VkIG1lLCBzaW5jZSBJIGluaXRpYWxseSAgdGhvdWdodCBpdCBtZWFudCDigJ50 aGUgYXBwcm9hY2ggaXMgdG8gdXNlIFVOU1BFQ0lGSUVEIGluIGEgd2F5IHRoYXQgbWFrZXMgc2Vu c2XigJwgcmF0aGVyIHRoYW4g4oCedGhlIGFwcHJvYWNoIGlzIHRvIHVzZSBVTlNQRUNJRklFROKA nC4gTWF5YmUgdGhhdCBjb3VsZCBiZSByZXdvcmRlZCB0byBzb21ldGhpbmcgYWxvbmcgdGhlIGxp bmVzIG9mDQpUaGUgVU5TUEVDSUZJRUQgVExWIGFuZCBpdHMgdXNhZ2Ugd2FzIHNwZWNpZmllZCBp biBbUkZDNzE4OF3igKYNCj8NCg0KTm8uIFRoZXJlIGlzIG5vIFVOU1BFQ0lGSUVEIFRMVi4gVGhl cmUgaXMgYSByZWNvbW1lbmRhdGlvbiB0byBpbmNsdWRlIGFuIFVOU1BFQ0lGSUVEIHZhbHVlIGlu IGEgVExWLiBCdXQgcmVhbGx5LCB3ZSd2ZSBkZXNjcmliZWQgdGhpcyBvbmNlIGluIDcxODgsIGl0 J3MgdGhlcmUgdG8gcmVhZC4NCg0KKiByZWdhcmRpbmcgNi4zPGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi02LjM+LiBU TFYgVmFsdWVzOg0KVGhlIHNlY29uZCBwYXJhZ3JhcGggaXMgYSBiaXQgY29uZnVzaW5nIGFuZCBz ZWVtcyB0byBleHBsYWluZyByb2dobHkgdGhlIHNhbWUgdGhpbmdzIGFzIHRoZSBmb3VydGggcGFy YWdyYXBocy4gSeKAmWQgcHJvcG9zZSB0byBtZXJnZSB0aGUgc2Vjb25kIGludG8gdGhlIGZvdXJ0 aC4NCg0KSSdtIG5vdCBzdXJlIEkgZXhhY3RseSBhZ3JlZSwgYnV0IHRoZSBvcmRlcmluZyBpbiB0 aGF0IHNlY3Rpb24gY291bGQgYmUgaW1wcm92ZWQuDQoNCiogZnJvbSA2LjQ8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9u LTYuND4uIEF1dG9tYXRpb246DQoNCg0KICAgVGhlIHBvc3NpYmxlIGdhaW4gZGVwZW5kcyBvbiB0 aGUgZWZmaWNpZW5jeQ0KDQogICBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZSBjcmVhdGlvbiwNCg0K dGhlIHRlcm0g4oCedGhlIG9yaWdpbmFsIG1lc3NhZ2UgY3JlYXRpb27igJwgc2VlbXMgYSBiaXQg YW1iaWd1b3Vz4oCTIGRvZXMgdGhpcyByZWZlciB0byB0aGUgbWVzc2FnZSBhcyBjcmVhdGVkIGJ5 IGFuIFJGQzU0NDQgbWVzc2FnZSBidWlsZGVyIGltcGxlbWVudGF0aW9uPw0KDQpZZXMuDQoNCkFk ZGl0aW9uYWxseSwgSSdtIGNvbmNlcm5lZCBhYm91dCB0d28gdGhpbmdzIHRoYXQgKmFyZW7igJl0 KiBpbiB0aGUgZHJhZnQ6DQoNCiogIFNvbWUgb2YgdGhlIEFPRFZ2MiBjby1hdXRob3JzIGFuZCBt ZSBoYXZlIGFza2VkIGZvciBhIGxpc3Qgb2Yg4oCeYXMgYSBwcm90b2NvbCwgeW91IGNhbiBzZXQg YWxsIG9mIHRoZXNlIGZpZWxkcyBvZiBhIG1lc3NhZ2UsIGJ1dCBwbGVhc2UgbGVhdmUgdGhlIHJl c3QgYWxvbmXigJwsIHdoaWNoIHdvdWxk4oCZdmUgc2F2ZWQgdXMgbWFueSBob3VycyBvZiBkaXNj dXNzaW9ucyAoYW5kIEhlbm5pbmcgYSBsb3Qgb2YgdGltZSBzcGVudCBleHBsYWluaW5nIHRoZXNl IHRoaW5nc+KApikuIFRoZXNlIHJlcXVlc3RzIGhhdmUgYmVlbiBtZXQgd2l0aCBhIHJlZnVzYWwg dG8gc3BlY2lmeSBhIGNvbmNyZXRlIEFQSSwgYXMgc3VjaCBhbiBlZmZvcnQgaXMgZGVwZW5kZW50 IG9uIG91dHNpZGUgZmFjdG9ycyBzdWNoIGFzIHByb2dyYW1taW5nIGxhbmd1YWdlIG9yIHNvZnR3 YXJlIGFyY2hpdGVjdHVyZS4gSSBhZ3JlZSB3aXRoIHRoaXMgbm90aW9uLCBidXQgYSBwcm9ncmFt bWluZy1sYW5ndWFnZSBkZXBlbmRlbnQgQVBJIGlzIG5vdCB3aGF0IHdl4oCZdmUgYXNrZWQgZm9y LiBJ4oCZdmUgdHJpZWQgdG8gc3VwcGx5IGEgc2tldGNoIG9mIHdoYXQgSSBkaWQgYXNrIGZvciBp biBbMV0sIGJ1dCB1bmZvcnR1bmF0ZWx5IEkgZGlkbuKAmXQgZ2V0IGFuIGFuc3dlciAoYW5kIGFz IGZhciBhcyBJIGNhbiBzZWUgaXQsIHRoZSBkcmFmdCB3YXNu4oCZdCBjaGFuZ2VkIGVpdGhlciku IEkgc3RpbGwgdGhpbmsgdGhhdCBzdWNoIGEgbGlzdCwgaW4gd2hhdGV2ZXIgZm9ybSwgd291bGQg YmUgdmVyeSBoZWxwZnVsIGZvciBmdXR1cmUgSW50ZXJuZXQtRHJhZnQgYXV0aG9ycyBhbmQgSSBh bHNvIHRoaW5rIHRoaXMgcmVxdWVzdCBpcyBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIGludGVudGlv bnMgc3RhdGVkIGluIDEuMSBIaXN0b3J5IGFuZCBQdXJwb3NlLCBhbmQgSSB0aGluayBpdCBzaG91 bGQgYmUgaW5jbHVkZWQgaW4gdGhlIGRvY3VtZW50Lg0KDQpOby4gVGhlcmUgYXJlIG1hbnkgcmVh c29ucyB3aHkgd2UncmUganVzdCBub3QgdG91Y2hpbmcgdGhpcyBvbmUuDQoNCk9uZSBpcyB0aGF0 IGxhbmd1YWdlIGluZGVwZW5kZW5jZSBpcyBhIG1pcmFnZS4gSG93IHlvdSBnbyBhYm91dCB0aGlu Z3MgaXMgY29tcGxldGVseSBkaWZmZXJlbnQgaW4sIGZvciBleGFtcGxlIGFuIG9iamVjdCBvcmll bnRlZCBsYW5ndWFnZSB0aGFuIG9uZSB0aGF0IGlzbid0LiBTZWN0aW9uIDQuNSBzaG93cyB0aGF0 IHRoZXJlIGFyZSBxdWl0ZSBkaWZmZXJlbnQgd2F5cyBvZiBkb2luZyB0aGluZ3MgZXZlbiBnaXZl biBhIGRlY2lzaW9uIHRvIHVzZSBhIG1hcCBhcHByb2FjaCwgYW5kIHRoZXJlIGFyZSBvdGhlciBh cHByb2FjaGVzIHRoYW4gdGhhdC4gSXQgd291bGQgYmUgd3JvbmcgYW5kIGJleW9uZCBvdXIgY29t cGV0ZW5jZSB0byBzdWdnZXN0IG9uZSBvZiB0aGVzZSBhcyAiYmVzdCIuIFRoZXJlJ3MgcmVhc29u cyB0aGUgSUVURiBkb2Vzbid0IGRvIHRoaXMsIGFuZCB0aGF0J3Mgb25lLg0KDQpQbHVzLCBmcmFu a2x5LCB0aGUgd29yayBpdCB3b3VsZCB0YWtlIGlzIGJleW9uZCB3aGF0IHdlIGNob29zZSB0byBz cGVuZC4NCg0KDQo8U3BlYWtpbmcgYXMgYSBXRyBQYXJ0aWNpcGFudD4NCg0KSSdtIGNvbmZ1c2Vk ICh3aGljaCBpcyBhbiBhbHRvZ2V0aGVyIHRvbyBjb21tb24gb2NjdXJyZW5jZSB0aGVzZSBkYXlz KS4gSSBnZXQgdGhhdCB3ZSBkb24ndCB3YW50IHRvIHNwZWNpZnkgYW4gQVBJLiBCdXQgSSB0aGlu ayB0aGUgZGlzY3Vzc2lvbiBhYm91dCBmaWVsZHMgYSBwcm90b2NvbCBjYW4gYW5kIGNhbid0IHRv dWNoIGluIGEgbWVzc2FnZXMgaXMgYSBnb29kIHRoaW5nIC0gYW5kIGl0J3Mgb25lIHNwb3Qgd2hl cmUgSSwgdG9vLCBmaW5kIHRoZSBkb2N1bWVudCB3YW50aW5nLg0KDQpUbyBwYXJhcGhyYXNlIHNv bWV0aGluZyBJJ3ZlIHNhaWQgYmVmb3JlLCBJIGJlbGlldmUgdGhhdCBSRkMgNTQ0NCBjaGFuZ2Vz IHRoZSByZWxhdGlvbnNoaXAgdGhhdCBhIHJvdXRpbmcgcHJvdG9jb2wgaGFzIHdpdGggYW4gImlu dGVyZmFjZSIuIEknbSBub3QgY29tbWVudGluZyBvbiB3aGV0aGVyIG9yIG5vdCB0aGF0J3MgYSBn b29kIHRoaW5nLCBvciBhIGJhZCB0aGluZyAtIGp1c3QgdGhhdCBpdCBkb2VzIGNoYW5nZSB0aGUg cmVsYXRpb25zaGlwLiBUaGlzIGNoYW5nZSBoYXMgYmVlbiBhdCB0aGUgcm9vdCBvZiBzb21lIG9m IHRoZSBsb25nLXJ1bm5pbmcgZGlzY3Vzc2lvbnMgYXMgdG8gd2hldGhlciBwcm90b2NvbHMgdW5k ZXIgZGV2ZWxvcG1lbnQgd2VyZSBSRkMgNTQ0NCBjb21wbGlhbnQgb3Igbm90LiBUaGUgZ29hbCBv ZiB0aGlzIGRvY3VtZW50IGJlaW5nIHRvIGVsaW1pbmF0ZSAoaXQncyBhIGdvYWwsIHByb2JhYmx5 IG5vdCByZWFjaGFibGUpIHRob3NlIGRpc2N1c3Npb25zLCBJJ2QgbGlrZSB0byBzZWUgdGhhdCBp bmZvcm1hdGlvbiBpbiB0aGUgZG9jdW1lbnQgaW4gc29tZSBmb3JtLg0KDQpJJ20gaW50ZXJlc3Rl ZCBpbiBzZWVpbmcgdGhpcyBkb2N1bWVudCBwcm9ncmVzcywgYW5kIGV2ZW50dWFsbHkgYmUgcHVi bGlzaGVkLiBJIHRoaW5rIGl0IHdpbGwgaGVscCBmdXR1cmUgcHJvdG9jb2wgZGVzaWduZXJzIHRv IGJldHRlciB1c2UgUkZDIDU0NDQuIEJ1dCBJIHdvdWxkIGxpa2UgdG8gc2VlICpzb21ldGhpbmcq IGFsb25nIHRoZSBsaW5lcyBvZiB3aGF0IExvdHRlIGlzIHJlcXVlc3RpbmcsIGFzIEkgdGhpbmsg aXQgd2lsbCBpbXByb3ZlIHRoZSBkb2MuDQoNClJlZ2FyZHMsDQpTdGFuDQoNCg0KDQoqIEFzIHRo ZSBleGFjdCBydWxlcyBmb3IgdXNpbmcvc2V0dGluZyB0aGUgaG9wIGNvdW50ICYgaG9wLWxpbWl0 IGZpZWxkcyBhcmUgY3VycmVudGx5IGJlaW5nIGRpc2N1c3NlZCB3LyByZWdhcmQgdG8gQU9EVnYy IGluIGFub3RoZXIgdGhyZWFkIFsyXeKAkyBzaG91bGQgYSBkZWZpbml0aXZlIGFuc3dlciB0byB0 aGF0IHF1ZXN0aW9uIGJlIHBhcnQgb2YgNTQ0NC11c2FnZT8NCg0KWW91IGRvbid0IHdhbnQgdGhh dC4gQmVjYXVzZSBpZiB3ZSBkaWQgc3BlY2lmeSB0aGF0IHlvdSdkIGZpbmQgeW91cnNlbGYgbW9y ZSBjb25zdHJhaW5lZCB0aGFuIHlvdSB3YW50IHRvIGJlLiBUaGVyZSBpcyBhIGRlc2lnbiBpbnRl bnQgZGVzY3JpYmVkIGluIDU0NDQsIGJ1dCBpdCBhc3N1bWVzIGltbXV0YWJsZSBtZXNzYWdlcy4g V2hpY2ggeW91IGRvbid0IHdhbnQuIFJlYWxseSwgd2UncmUgZG9pbmcgeW91IGEgZmF2b3VyIGJ5 IG5vdCBpbXBvc2luZyBvbiB5b3UuDQoNCkJlc3QgcmVnYXJkcywNCkxvdHRlDQoNClsxXSBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTgwODIu aHRtbA0KWzJdIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3Vy cmVudC9tc2cxODY3NC5odG1sDQoNCg0KQW0gMDYuMDQuMjAxNiB1bSAxOToxNCBzY2hyaWViIEp1 c3RpbiBEZWFuIDxiZWJlbWFzdGVyQGdtYWlsLmNvbTxtYWlsdG86YmViZW1hc3RlckBnbWFpbC5j b20+PjoNCg0KVGhlIGNoYWlycyBhZ3JlZSB0aGF0IGEgMyB3ZWVrIFdHTEMgaXMgYXBwcm9wcmlh dGUuICBFdmVyeW9uZSBwbGVhc2UgcmVhZCB0aGUgZHJhZnQgZWFybHkgYW5kIGdldCBjb21tZW50 cyBpbiBlYXJseSBzbyB0aGF0IHRoZXkgY2FuIGJlIGFkZHJlc3NlZCB3aXRoaW4gdGhlIGxhc3Qg Y2FsbCBwZXJpb2QuDQoNCkp1c3Rpbg0KDQpPbiBXZWQsIEFwciA2LCAyMDE2IGF0IDc6NDAgQU0s IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNv bTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PiB3cm90ZToNCk9idmlvdXNs eSArMSB0byB0aGUgcmVxdWVzdCBmb3IgV0dMQy4NCg0KV2l0aCByZWdhcmQgdG8gd2hhdCdzIGNo YW5nZWQsIHRlY2huaWNhbGx5IHRoZSBvbmx5IHNpZ25pZmljYW50IHRoaW5nIGlzIHRvIG1ha2Ug aXQgY2xlYXIgdGhhdCBpZiBhIHByb3RvY29sIGRlbGl2ZXJzIGEgbWVzc2FnZSB0byB0aGUgbXVs dGlwbGV4ZXIsIHRoZSBtdWx0aXBsZXhlciBtdXN0IHBhc3MgaXQgb24gdW5jaGFuZ2VkIHRvIHRo ZSBwcm90b2NvbCAoYW5vdGhlciBpbnN0YW5jZSBvZiwgYXQgYW5vdGhlciByb3V0ZXIpIHVuY2hh bmdlZC4gV2l0aG91dCB0aGF0IG5vdGhpbmcgdGhhdCB0aGUgcHJvdG9jb2wgaXRzZWxmIGNob29z ZXMgdG8gZG8gd2l0aCByZWdhcmQgdG8gc2VjdXJpdHkgbWFrZXMgc2Vuc2UuIFRob3VnaCB0aGUg cHJvdG9jb2wgY2FuIGFsdGVybmF0aXZlbHkgbGV0IHRoZSBtdWx0aXBsZXhlciBkbyB0aGUgc2Vj dXJpdHksIDcxODIgY2FuIGJlIGltcGxlbWVudGVkIGluIGVpdGhlciB3YXkuIFRoaXMgaXNuJ3Qg cmVhbGx5IG5ldywgYnV0IGl0IHdhc24ndCBmb3JtYWxseSBzcGVsbGVkIG91dC4gSXQncyBwcmVz ZW50ZWQgYXMgcGFydCBvZiBzcGVsbGluZyBvdXQgbXVsdGlwbGV4ZXIgcnVsZXMgbW9yZSBjYXJl ZnVsbHkuDQoNCkJ1dCB3aGF0IGFib3V0IG1lc3NhZ2Ugb3B0aW1pc2F0aW9uPyBUaGF0J3MgYSBm dW5jdGlvbiBvZiBjb25zdHJ1Y3RpbmcgYSA1NDQ0IG1lc3NhZ2UsIG5vdCB0aGUgbXVsdGlwbGV4 ZXIsIGFuZCBpcyBkb3duIHRvIHRoYXQgNTQ0NCBpbmNsdWRlcyB0d28gdGhpbmdzIC0gcGFja2V0 L21lc3NhZ2Ugc3RydWN0dXJlIChhbmQgaW1wbGljaXRseSwgYW5kIGluIHByZXR0eSBtdWNoIGFu eSBpbXBsZW1lbnRhdGlvbiBJIHdvdWxkIGV4cGVjdCB0byBzZWUsIGEgcGFyc2VyIGFuZCBidWls ZGVyIGZvciB0aGF0IHN0cnVjdHVyZSkgYW5kIHRoZSBtdWx0aXBsZXhlci4gU28gd2UgdG9vayB0 aGUgb3Bwb3J0dW5pdHkgdG8gc2VwYXJhdGUgb3V0IG1vcmUgY2xlYXJseSBhIGRpc2N1c3Npb24g b2YgdGhlIHR3bywgd2hpY2ggd2UgdGhpbmsgd2lsbCBiZSBoZWxwZnVsLg0KDQotLQ0KQ2hyaXN0 b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFw cGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDog ICs0NCAoMCkxMjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4gIHwg IEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBi YWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxt c2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENN MiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9h aT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQg aW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJl eSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFVscmljaCBI ZXJiZXJnDQpTZW50OiAwNSBBcHJpbCAyMDE2IDIwOjA4DQpUbzogbWFuZXRAaWV0Zi5vcmc8bWFp bHRvOm1hbmV0QGlldGYub3JnPg0KU3ViamVjdDogW21hbmV0XSBXR0xDIHJlcXVlc3QgZm9yIGRy YWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t ISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRl cyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwg cGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVy IHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciBy ZXBseS4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBt YXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVz c2FnZXMuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQoqKiogV0FSTklORyAqKioNCkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2Fn ZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uLg0KDQoNCkhpLA0KDQpB cyB5b3UgaGF2ZSBzZWVuLCB3ZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyByZXZpc2lvbiBvZiA1NDQ0 LXVzYWdlLiBUaGUgYXV0aG9ycyBmZWVsIGNvbWZvcnRhYmxlIHRoYXQgd2UgaGF2ZSBhZGRyZXNz ZWQgYWxsIGlzc3VlcyBieSB0aGlzIHZlcnNpb24sIGFuZCB3b3VsZCBsaWtlIHRvIGFzayB0aGUg V0cgY2hhaXJzIHRvIGlzc3VlIGEgV0dMQyBvbiB0aGlzIGRvY3VtZW50LiBXaGlsZSBpdCBpcyBh IGZhaXJseSBzaG9ydCBkb2N1bWVudCwgZ2l2ZW4gdGhhdCBpdCBpcyBJRVRGIHdlZWsgZm9yIHNv bWUsIHdlJ2Qgc3VnZ2VzdCB0aGF0IGEgMy00IHdlZWsgV0dMQyB3b3VsZCBiZSBhcHByb3ByaWF0 ZS4NCg0KQmVzdCByZWdhcmRzDQpVbHJpY2gNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8 bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tYW5ldA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh cmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBi ZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCBwbGVh c2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLg0KWW91 IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9z ZSBvcg0KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4NCioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcg bGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRm Lm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21hbmV0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5l dEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQN Cg0KDQoNCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ADA83GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30N CnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1HQjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+QXMgaGFzIGJlZW4gcG9pbnRlZCBvdXQgdG8gbWUsIHNvbWUgaW1wbGVtZW50YXRpb25z IGRvbuKAmXQgZG8gdGhpcy4gSWYgeW91IGFyZSBidWlsZGluZyBhbiBpbXBsZW1lbnRhdGlvbiBp biBhIGNvbnN0cmFpbmVkIGVudmlyb25tZW50LCB5b3UgY2FuIGJ1aWxkIGEgY29uc3RyYWluZWQN CiBpbXBsZW1lbnRhdGlvbi4gQW5kIHNvbWUgcGVvcGxlIGhhdmUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBubywg aXTigJlzIG5vdCBhcHByb3ByaWF0ZSB0byBzcGVjaWZ5IGFuIGluZGVwZW5kZW50IHBhcnNlciwg b3IgcmVxdWlyZSBvbmUuIFJhdGhlciB5b3UgbmVlZCB0byBkZXNpZ24gc28gdGhhdCB3aGVuIHBl b3BsZSBkbywgaXQgY2FuIGJlIGVmZmljaWVudC4gV2hpY2ggaXMNCiB3aGF0IHdlIGhhdmUgYmVl biBkb2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPk9yIGluIG90aGVyIHdvcmRzLCBJIGRvbuKAmXQgdGhpbmsgdGhp cyBzb3J0IG9mIGNoYW5nZSBpcyBhcHByb3ByaWF0ZS4gUXVpdGUgdGhlIGNvbnRyYXJ5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhlIGtleSBwb2ludCBpcyB0aGF0IHdoYXTigJlzIG1hbmRhdGVkIGlzIGEgbXVsdGlw bGV4ZXIgYW5kIGEgZm9ybWF0LiBCdXQgbm90IGFuIGluZGVwZW5kZW50IHBhcnNlci48bzpwPjwv 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 c2VyaWYmcXVvdDsiPiBTdGFuIFJhdGxpZmYgW21haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTggQXByaWwgMjAxNiAxNDowOTxicj4NCjxiPlRvOjwvYj4g RGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk8YnI+DQo8Yj5DYzo8L2I+IENocmlzdG9waGVyIERl YXJsb3ZlOyBtYW5ldEBpZXRmLm9yZzsgQ2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFttYW5ldF0gV0dMQyByZXF1ZXN0IGZvciBkcmFmdC1pZXRmLW1hbmV0LXJm YzU0NDQtdXNhZ2UtMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAx LjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFs aWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0 ZSI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1l c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZy b20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtz LCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48L3NwYW4+PC9p PjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFn czwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzMzMzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZl LA0KIGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93 d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiI+DQpo ZXJlPC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz MzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3Bp Y2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lz dGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmcl MjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3Nw YW4+PC9lbT48L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3 MiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBNb24sIEFwciAxOCwgMjAxNiBhdCA0OjUyIEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIg KFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0 YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IGJlbGll dmUgd2UgY2FuIG9yIHNob3VsZCBzdWdnZXN0IGFuIGltcGxlbWVudGF0aW9uLiBUaGF04oCZcyBu b3Qgd2hhdCB0aGUgSUVURiBkb2VzLCBhbmQgaXQNCiB3b3VsZCBiZSBhIGhhcmQsIHByb2JhYmx5 IGltcG9zc2libGUsIHNlbGwsIHRvIHRoZSBJRVNHLiBUaGF0IHRoZSBvYnZpb3VzIGltcGxlbWVu dGF0aW9uIGVtcGxveXMgYW4gaW5kZXBlbmRlbnQgcGFyc2VyIGlzIGFscmVhZHkgc2FpZCAtIGl0 IG1heSBiZSBhcHByb3ByaWF0ZSB0byBzdHJlbmd0aGVuIHRoZSB3b3JkcywgYnV0IHRoaXMgc2Vj b25kIEnigJltIG5vdCBzdXJlIGlmIHRoYXTigJlzIG5lZWRlZCAobm90IGdvdCB0aW1lIHRvIGNo ZWNrIGN1cnJlbnQNCiB3b3JkaW5nKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KEFnYWluLCB3aXRoIG15IFdvcmtp bmcgR3JvdXAgUGFydGljaXBhbnQgaGF0IG9uKSAtJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgbWVhbiB0byBzdWdnZXN0 IGFuIGltcGxlbWVudGF0aW9uLiBBdCBsZWFzdCB0byBtZSwgdGhpcyBpcyBhbiBhcmNoaXRlY3R1 cmUgKHRoYXQgb2YgYW4gaW5kZXBlbmRlbnQgcGFyc2VyLCB3aXRoIGEgcmVsaWFibGUgY29tbXVu aWNhdGlvbnMgbWVjaGFuaXNtIHRvIHNhaWQgcGFyc2VyLCB0aGF0IGRlYWxzIHdpdGggbG9naWNh bCBtZXNzYWdlcyBpbnN0ZWFkIG9mIHBhY2tldHMuIElzIHNlcXVlbmNpbmcNCiBndWFyYW50ZWVk PyBJJ20gbm90IHN1cmUsIHRvIGJlIGhvbmVzdC4gQnV0IG9uY2UgdGhlIGluZGVwZW5kZW50IHBh cnNlciBpcyBhc3N1bWVkLCBlbmdpbmVlcnMgYWxzbyBNVVNUIGFzc3VtZSB0aGF0IHRoZSB0cmFu c3BvcnQgKGFuZCBpdCdzIHRoZSB0cmFuc3BvcnQgZm9yIGNvbnRyb2wgcGxhbmUgdHJhZmZpYywg YnV0IG5vdCBmb3IgZGF0YSBwbGFuZSB0cmFmZmljKSwgaXMgJnF1b3Q7b3duZWQmcXVvdDsgYnkg dGhlIGluZGVwZW5kZW50IHBhcnNlci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpY2ggbGVhZHMgbWUgdG8gdGhlIG90aGVyIHBv aW50IEknbSB0cnlpbmcgdG8gbWFrZSAocGVyaGFwcyBiYWRseSk6ICZuYnNwO0Fic3RyYWN0aW5n IHRoZSB0cmFuc3BvcnQgYXdheSBmcm9tIHRoZSBjb250cm9sIHBsYW5lICpjYW4qIGVmZmVjdCBw cm90b2NvbCBkZXNpZ24uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgYmVsaWV2ZSBib3RoIG9mIHRoZXNlIHBvaW50cyBzaG91bGQg YmUgYWRkcmVzc2VkIGluIHRoZSB1c2FnZSBkb2N1bWVudC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0YW48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPC9zcGFuPjwvYj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5n aW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8 YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVC RSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojN0Q3RDdEIj46ICZuYnNwOzxhIGhyZWY9InRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIw MjQyMTk0IiB0YXJnZXQ9Il9ibGFuayI+JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NDwvYT4NCiAmbmJz cDt8ICZuYnNwOzxiPkU6IDwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwv YT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxi cj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBH cmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0 cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0 ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQ YXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbWFuZXQNCiBb bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bWFuZXQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlN0 YW4gUmF0bGlmZjxicj4NCjxiPlNlbnQ6PC9iPiAxNiBBcHJpbCAyMDE2IDE5OjA5PGJyPg0KPGI+ VG86PC9iPiBDaHJpc3RvcGhlciBEZWFybG92ZTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFp bHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+OyBD aHJpc3RvcGhlciBEZWFybG92ZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBXR0xD IHJlcXVlc3QgZm9yIGRyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBw dCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4 dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioq PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxl bT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBv cmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBl eHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lk ZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4g YW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9u Zz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFu PjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcy Ij4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xp Y2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsv c2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIiB0YXJnZXQ9Il9i bGFuayI+DQpoZXJlPC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWls IGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5l bnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRz L0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiIHRhcmdldD0iX2JsYW5r Ij4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdpbmRv d3RleHQgMS4wcHQ7cGFkZGluZzoxLjBwdCA0LjBwdCAxLjBwdCA0LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50ZXIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pio8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4qKg0KPC9zcGFuPjwvc3Ryb25nPjwvc3Bhbj48c3Ryb25nPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldBUk5JTkcNCjwvc3Bhbj48L3N0cm9uZz48c3Ryb25n PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4qKio8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RVhURVJOQUwgRU1BSUwgLS0g VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb248L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBBcHIgMTUsIDIwMTYgYXQgMzoyNyBQTSwg Q2hyaXN0b3BoZXIgRGVhcmxvdmUgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc0BtbmVtb3N5bmUu ZGVtb24uY28udWsiIHRhcmdldD0iX2JsYW5rIj5jaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWs8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5JIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbiBieSB0aGUgY29uY2Vw dCBvZiAmcXVvdDtmaWVsZHMgdGhlIHByb3RvY29sIGNhbiBhbmQgY2FuJ3QgdG91Y2gmcXVvdDsu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkNBVkVBVDogSSBhbSBzcGVha2luZyBoZXJlIGFzIGEgV29ya2luZyBHcm91cCBwYXJ0aWNp cGFudC4gV2l0aCB0aGF0IHVuZGVyc3Rvb2Q6DQo8YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlRUTCBpcyBhIGdyZWF0IGV4YW1w bGUsIHNpbmNlIHRoYXQgZGlzY3Vzc2lvbiBibGV3IHRoZSBtYWlsaW5nIGxpc3QgdXAgYSBmZXcg bW9udGhzIGFnby4gSSdtICpub3QqIHNheWluZyBtYW5pcHVsYXRpbmcgVFRMIGlzIGEgZ29vZCB0 aGluZyBmb3IgYSBwcm90b2NvbCB0byB0cnkgLSBpbiB0cnV0aCwgSSB0aGluayBpdCdzDQogcHJl dHR5ICZxdW90O2hhY2t5JnF1b3Q7LiBCdXQgdGhlIG5vdGlvbiB3YXMgZmxvYXRlZCwgYW5kIGlu IHRoZSBjb250ZXh0IG9mIHRoYXQgZGlzY3Vzc2lvbiwgaXQgbWF5IHdpbGwgaGF2ZSB3b3JrZWQu IFRoZSBvcHBvc2l0aW9uIG9uLWxpc3Qgd2FzIGZhc3QsIGFuZCBwcmV0dHkgZm9yY2VmdWwuDQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SSd2ZSBzYWlk IGJlZm9yZSAtIDU0NDQsIGVzcGVjaWFsbHkgd2l0aCB0aGUgbXVsdGlwbGV4ZXIsIGNoYW5nZXMg dGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGEgcm91dGluZyBwcm90b2NvbCBhbmQgYW4gaW50ZXJm YWNlLiBJIHRoaW5rIHRoZSBkb2N1bWVudCBzaG91bGQgaGF2ZSBzb21lIHR5cGUgb2YgJnF1b3Q7 b3ZlcnZpZXcmcXVvdDsNCiBzZWN0aW9uIHdoaWNoIGRpc2N1c3NlcyB0aGVzZSBkaWZmZXJlbmNl cywgaW4gb3JkZXIgdG8gZnJhbWUgdGhlIGlzc3VlIGZvciBzb21lb25lIGNvbWluZyBhbG9uZyB3 aG8gaGFzbid0IGJlZW4gYSBwYXJ0IG9mIHRoZSA1NDQ0IG1haWwgZGlzY3Vzc2lvbi4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5JJ20gdGFsa2luZyBh Ym91dCB0aGUgdHlwZSBvZiBvdmVydmlldyB0aGF0IGdvZXMgc29tZXRoaW5nIGxpa2UgdGhpczoN CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mcXVvdDtV c2Ugb2YgUkZDIDU0NDQgd2l0aCB0aGUgbXVsdGlwbGV4ZXIgZmVhdHVyZSBpbXBvc2VzIGRlc2ln biByZXF1aXJlbWVudHMgb24gdGhlIHByb3RvY29sLiBUaGUgYWN0dWFsIHRyYW5zcG9ydCBtZWNo YW5pc20gaXMgYWJzdHJhY3RlZCBmcm9tIHRoZSBwcm90b2NvbC4gRm9yIGV4YW1wbGUsIHJvdXRp bmcgcHJvdG9jb2xzDQogYXJlIG5vdCBhd2FyZSBvZiBwcmVjaXNlbHkgd2hlbiBhIG1lc3NhZ2Ug aXMgc2VudC4gQSBnb29kIGV4YW1wbGUgb2Ygb3BlcmF0aW9uIGluIHRoaXMgbW9kZWwgaXMgW0JH UF0sIHV0aWxpemluZyB0aGUgW1RDUF0gdHJhbnNwb3J0LiBUaGlzIGlzIG9wcG9zZWQgdG8gYSBw cm90b2NvbCBzdWNoIGFzIFtPU1BGXSwgd2hpY2ggaXMgY2FwYWJsZSBvZiBzZW5kaW5nIHRyYWZm aWMgd2l0aCBpdHMgb3duIElQIHR5cGUuIFNpbmNlIHRoZSB0cmFuc3BvcnQNCiBpcyBhYnN0cmFj dGVkLCBwcm90b2NvbHMgYXJlIG5vdCBwcmVzZW50ZWQgd2l0aCAmcXVvdDtwYWNrZXRzJnF1b3Q7 LCBhbmQgYXJlIG5vdCBjYXBhYmxlIG9mIG1hbmlwdWxhdGluZyBkYXRhIGl0ZW1zIGluIHBhY2tl dCBoZWFkZXJzIChlLmcuIGRhdGEgaXRlbXMgYXQgdGhlIElQIGFuZC9vciBNQUMgbGF5ZXJzKS4m cXVvdDs8YnI+DQo8YnI+DQpBcyBMb3UgQmVyZ2VyIHB1dCBpdCB0byBtZSBpbiB0aGUgY29udGV4 dCBvZiBETEVQIC0gJnF1b3Q7WW91IHdhbnQgYW4gZW5naW5lZXIgdG8gYmUgYWJsZSB0byBwaWNr IHVwIHRoaXMgZG9jdW1lbnQsIHdpdGggbm8gcHJpb3IgZXhwb3N1cmUgdG8gdGhlIHRvcGljLCBh bmQgY29kZSBhbiBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9uLiZxdW90OyZuYnNwOyBJIHRo aW5rIHRoaXMgdHlwZSBvZiBhbiBvdmVydmlldywgc2V0dGluZyBiYXNpYyBncm91bmQgcnVsZXMs IHdvdWxkDQogaGVscC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+SSd2ZSBhbHNvIGNvbnRlbmRlZCBmb3IgYSB3aGlsZSBub3cgdGhhdCA1NDQ0LCB3aXRo IHRoZSBtdXgsIGVmZmVjdGl2ZWx5IGZvcmNlcyBhbiBhcmNoaXRlY3R1cmUgb24gaW1wbGVtZW50 ZXJzIC0gaW4gdGhlIExpbnV4IHdvcmxkLCB0aGF0IGFyY2hpdGVjdHVyZSBpcyBhIDU0NDQgcGFy c2VyIGFzIGFuIGluZGVwZW5kZW50DQogcHJvY2Vzcywgd2l0aCBJUEMgbWVjaGFuaXNtcyB0byB0 aGUgcm91dGluZyBwcm90b2NvbChzKSBpdCBpcyBzZXJ2aWNpbmcuIFRoZSA1NDQ0IHBhcnNlciBp dHNlbGYgJnF1b3Q7b3ducyZxdW90OyB0aGUgdHJhbnNwb3J0ICh0aGUgc29ja2V0KS4gVGhlIHVz YWdlIGRvY3VtZW50ICpzdHJvbmdseSBpbmZlcnMqIHRoYXQuIEkgYmVsaWV2ZSB3ZSBzaG91bGQg Y29uY3JldGVseSBzdGF0ZSBpdCwgc28gd2UgZG9uJ3QgaGF2ZSB0byBhbnN3ZXIgdGhlIHF1ZXN0 aW9uIG92ZXINCiBhbmQgb3ZlciBhZ2Fpbi4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlN0YW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGVuIGEgcHJvdG9jb2wg Y3JlYXRlcyBhIG1lc3NhZ2UgZnJvbSBzY3JhdGNoIGl0J3Mgbm90IGNvbnN0cmFpbmVkIGluIGFu eSB3YXkgSSdkIGRlc2NyaWJlIGluIHN1Y2ggdGVybXMuIFNvIEkgYXNzdW1lIHlvdSBtZWFuIHdo ZW4gaXQgcmVjZWl2ZXMgYSBtZXNzYWdlIGFuZCB0aGVuIHNlbmRzIGEgc2ltaWxhcg0KIG1lc3Nh Z2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaGVyZSBhcmUgdHdvIGNhc2VzIHRoZXJlLiBVbmNoYW5nZWQgKHdpdGggdGhlIHNwZWNp YWwgZXhjZXB0aW9ucyBmb3IgaG9wIGNvdW50IGFuZCBsaW1pdCkgYW5kIG5vdCB1bmNoYW5nZWQu IFRoZSBmb3JtZXIgaXMgYmV0dGVyLCBhbmQgdGhlcmUncyByZWFsbHkgbm90aGluZyBtb3JlIHRv IHNheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlNvIGxldCdzIGNvbnNpZGVyIHRoZSBsYXR0ZXIuIFJlYWxseSBpdCdzIG5vdCB0aGUg c2FtZSBtZXNzYWdlLCBpdCdzIGEgYnJhbmQgbmV3IG1lc3NhZ2UuIFRoYXQncyBhIHVzZWZ1bCB3 YXkgdG8gbG9vayBhdCBpdCBmcm9tIGEgc2VjdXJpdHkgcGVyc3BlY3RpdmUsIGJlY2F1c2UgaXQg dGVsbHMgeW91IHRoYXQNCiBlbmQgdG8gZW5kIGF1dGhlbnRpY2F0aW9uIGlzbid0IGdvaW5nIHRv IHdvcmsuIEFuZCB3aGF0IGFyZSB0aGUgcmVzdHJpY3Rpb25zIG9uIGJyYW5kIG5ldyBtZXNzYWdl cz8gVGhlIHNhbWUgYXMgb24gYW55IG5ldyBtZXNzYWdlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T0ssIHlvdSBtaWdodCBzYXksIHRy dWUgYnV0IGRvZXMgdGhhdCBtZWFuIEkgY2FuIGFkZCB0aGlzLCByZW1vdmUgdGhhdCwgY2hhbmdl IHRoZSBob3AgZGF0YT8gWWVzLiBCdXQgaXMgdGhhdCBhIGdvb2QgaWRlYT8gTm8uIEJ1dCBtYXli ZSB5b3UgYXJlIGZvcmNlZCBpbnRvIGl0LiBCdXQgdGhhdCBpdCdzIGluaGVyZW50bHkNCiBub3Qg Z29vZCBzdWdnZXN0cyB0aGUgY29yb2xsYXJ5IHRoYXQgaWYgeW91IG11c3QsIGRvIHRoZSBtaW5p bXVtIGFuZCBtYWtlIGl0IHRyYWNrYWJsZS4gQnV0IHRoYXQncyBub3QgYSA1NDQ0IHJlcXVpcmVt ZW50LCBqdXN0IGdvb2QgcHJhY3RpY2UuIEl0IGRvZXMgYnJlYWsgNzE4MiBtZXNzYWdlIElDVnMs IHNvIGRvbid0IHVzZSB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+V2UgY291bGQsIGh5cG90aGV0aWNhbGx5LCBoYXZlIHNvbWVv bmUgY3JlYXRlIGFuIGV4dGVuc2lvbiBvciBhbHRlcm5hdGl2ZSB0byA3MTgyIHRoYXQgZGVmaW5l ZCBhZ2dyZWdhdGVkIHNpZ25hdHVyZXMuIFRoZW4gd2UnZCBoYXZlIHJ1bGVzIG9uIHdoYXQgeW91 IGNvdWxkIGNoYW5nZS4gQnV0IHRoYXQgd291bGQNCiBiZWxvbmcgdGhlcmUuIElmIHlvdSB0aGlu ayB0aG9zZSB3b3VsZCBiZSBnb29kLCB0aGVuIGFnYWluIHlvdSB3b3VsZCB3YW50IG1ha2UgbWlu aW1hbCBjaGFuZ2VzLCBhbmQgbWFpbmx5IG9ubHkgb2YgY2VydGFpbiB0eXBlcy4gV2hhdCB0eXBl cz8gVGhlcmUgSSBjYW4ndCBoZWxwIHlvdSBhcyBJIGRvbid0IGhhdmUgYSBjYW5kaWRhdGUuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGUgc3VtbWFyeT8gRG9uJ3QgY2hhbmdlIGlmIHlvdSBkb24ndCBoYXZlIHRvLiBUaGF0J3MgcmVj b21tZW5kZWQuIElmIHlvdSBtdXN0IGNoYW5nZSB5b3UncmUgb24geW91ciBvd24gKHdpdGggdGhl IHNhbWUgcmVzdHJpY3Rpb25zIGFzIG5ldyBtZXNzYWdlcykuIEFkdmljZSBsaWtlICZxdW90O2Fz IGxpdHRsZSBhcw0KIHBvc3NpYmxlJnF1b3Q7IGlzIGdvb2QsIGJ1dCB0aGF0J3Mgbm90IGFjdHVh bGx5IDU0NDQgYWR2aWNlLiBBbmQgZG9uJ3QgdXNlIDcxODIgbWVzc2FnZSBJQ1ZzLjxicj4NCjxi cj4NCi0tICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0ibWFpbHRvOmNocmlzdG9waGVyLmRlYXJsb3Zl QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNv bTwvYT4gKGlQaG9uZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGEgaHJlZj0ibWFpbHRvOmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51ayIg dGFyZ2V0PSJfYmxhbmsiPmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51azwvYT4gKGhvbWUpPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KT24gMTUgQXByIDIwMTYsIGF0IDE5OjM3LCBTdGFuIFJhdGxpZmYgJmx0OzxhIGhyZWY9Im1h aWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5yYXRsaWZmc3RhbkBn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TXkgbWFpbiBjb25jZXJuIGFkZHJlc3NlZCBp bmxpbmUuLi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmksIEFw ciAxNSwgMjAxNiBhdCAxOjQ5IFBNLCBDaHJpc3RvcGhlciBEZWFybG92ZSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNo cmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkEgZmV3IGltbWVkaWF0ZSBj b21tZW50cyBpbmxpbmUgYmVsb3cuPGJyPg0KPGJyPg0KLS0gJm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaHJpc3RvcGhlciBEZWFybG92ZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVm PSJtYWlsdG86Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tPC9hPiAoaVBob25lKTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJtYWlsdG86 Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXNAbW5lbW9z eW5lLmRlbW9uLmNvLnVrPC9hPiAoaG9tZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAxNSBBcHIgMjAxNiwgYXQgMTU6MTgs IExvdHRlIFN0ZWVuYnJpbmsgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3R0ZS5zdGVlbmJyaW5rQGZ1 LWJlcmxpbi5kZSIgdGFyZ2V0PSJfYmxhbmsiPmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRl PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5zcGFya2VkIGJ5IHRoZSByZWNlbnRseSBzdGFydGVkIFdHTEMsIEnigJl2ZSByZXZp ZXdlZCB0aGUgY3VycmVudCByZXZpc2lvbiBvZiB0aGUgZHJhZnQuIEnigJlkIGxpa2UgdG8gb2Zm ZXIgdGhlIHdvcmtpbmcgZ3JvdXAgbXkgcGVyc3BlY3RpdmUgYXMgc29tZW9uZSB3aG8gZG9lc27i gJl0IGhhdmUgZGVjYWRlcyBvZg0KIHByb3RvY29sIGFuZC9vciBwYWNrZXQgZm9ybWF0IGRlc2ln biB1bmRlciB0aGVpciBiZWx0IChpLmUuIHNvbWUgdGhpbmdzIG1pZ2h0IG5vdCBiZSBvYnZpb3Vz IHRvIG1lIHRoYXQgYXJlIG9idmlvdXMgdG8gb3RoZXJzKSwgYnV0IGFsc28gYXMgc29tZW9uZSB3 aG8gaGFzIHdvcmtlZCB3aXRoIFJGQyA1NDQ0IHdoZW4gaW1wbGVtZW50aW5nIGEgcm91dGluZyBw cm90b2NvbCAoQU9EVnYyKSwgdXBkYXRpbmcgdGhlIHBhY2tldCBmb3JtYXQgb2YgYQ0KIHJvdXRp bmcgcHJvdG9jb2wgKEFPRFZ2MiBhZ2FpbikgYW5kIChwYXJ0aWFsbHkpIGltcGxlbWVudGluZyBt eSBvd24gUkZDNTQ0NCBidWlsZGVyL3BhcnNlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk92ZXJhbGwsIEkgdGhpbmsgdGhlIGRvY3Vt ZW50IGlzIGVhc3kgdG8gcmVhZCBhbmQgZm9sbG93LiBUbyBtZSwgaXQgY29udGFpbnMgdmFsdWFi bGUgaW5mb3JtYXRpb24gYW5kIGd1aWRhbmNlIGFuZCBpbiBzb21lIGNhc2VzIHByZXZlbnRzIHBl b3BsZSBmcm9tIHNob290aW5nIHRoZW1zZWx2ZXMgaW4gdGhlDQogZm9vdC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SeKAmW0gcmVhbGx5IGhh cHB5IHRoaXMgZG9jdW1lbnQgZXhpc3RzIGFuZCBJ4oCZZCBsaWtlIGl0IHRvIG1vdmUgZm9yd2Fy ZCBzb29uLCBidXQgSSBkbyBmZWVsIHRoYXQgaXQgaXMgc3RpbGwgbGFja2luZyBpbiBzb21lIGFy ZWFzLCB3aGljaCBpcyB3aHkgSSB3YXMgYSBiaXQgc3VycHJpc2VkIHRvIHNlZSBpdCBnbw0KIHRv IExhc3QgQ2FsbCBhbGwgb2YgYSBzdWRkZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Tm90IHJlYWxseS4gVGhlIGF1dGhvcnMgaGFkIHNhaWQgd2hhdCB0aGV5IGludGVuZGVkIHRv IHNheSwgbm8gb25lIHdhcyBjb21tZW50aW5nLCB0aW1lIGZvciBXR0xDLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZpcnN0 LCBzb21lIG5pdHBpY2tzIGFuZCBjb21tZW50czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiogZnJvbSZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMj c2VjdGlvbi0xLjIuMSIgdGFyZ2V0PSJfYmxhbmsiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj azt0ZXh0LWRlY29yYXRpb246bm9uZSI+MS4yLjE8L3NwYW4+PC9iPjwvYT48Yj4uDQogUGFja2V0 L01lc3NhZ2UgRm9ybWF0PC9iPjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtb4oCmXSBhIHBhY2tldDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0cmFuc21pc3Np b24gZm9sbG93aW5nIGEgc3VjY2Vzc2Z1bCBwYWNrZXQgcmVjZXB0aW9uIGlzIGJ5IGRlc2lnbjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvZiBh IG5ldyBwYWNrZXQgdGhhdCBtYXkgaW5jbHVkZSBhbGwsIHNvbWUsIG9yIG5vbmUgb2YgdGhlPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlY2Vp dmVkIG1lc3NhZ2VzIFsuLi5dPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J4oCZbSBub3QgYSBuYXRpdmUgc3BlYWtlciwg YnV0IHRoYXQg4oCeb2bigJwgc2VlbXMgb3V0IG9mIHBsYWNlLi4uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkkgYW0gYSBuYXRpdmUgc3BlYWtlciwgYW5kIG5vLCBpdCdzIG5vdC4gU29tZSB3b3VsZCByZXBl YXQgaXQgYWZ0ZXIgZWFjaCBvZiBhbGwsIHNvbWUgYW5kIG5vbmUsIGFuZCBJIG1pZ2h0IHNvbWV0 aW1lcy4gQnV0IGl0IHJlYWxseSBkb2Vzbid0IG1hdHRlciB3aGljaCBvZiB0aGUgdHdvIHN0eWxl cyB3ZSBwaWNrLA0KIHRoZSBSRkMgRWRpdG9yIG1heSB3ZWxsIGNoYW5nZSB0byB0aGUgb3RoZXIu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4qIFJlZ2FyZGluZyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi00LjIiIHRhcmdldD0iX2Js YW5rIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjQu Mjwvc3Bhbj48L2I+PC9hPjxiPi4NCiBQYWNrZXRzIGFuZCBNZXNzYWdlczo8L2I+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoaXMgc2VjdGlv biB0YWxrcyBhIGxvdCBhYm91dCBob3cgdGhlIG11bHRpcGxleGVyIG9wZXJhdGVzLCBzbyBJIHRo aW5rIGl04oCZZCBiZSBoZWxwZnVsIGlmIGl0cyB0aXRsZSByZWZsZWN0ZWQgdGhhdC4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkknbSBvZiB0d28gb3BpbmlvbnMgb24gdGhhdC4gT24gdGhlIG9uZSBoYW5kIGl0 IGlzLCBhcyBpdHMgdGl0bGUgc3VnZ2VzdHMsIGFib3V0IHRoZSBwYWNrZXQgYW5kIG1lc3NhZ2Ug bGV2ZWwsIGFzIG9wcG9zZWQgdG8gbG93ZXIgbGV2ZWxzLCBhbmQgaXRzIHRpdGxlIGNvbnRyYXN0 cyB3aXRoIHRoYXQgaWYgNC4zDQogZm9yIHRoYXQgcmVhc29uLiBPbiB0aGUgb3RoZXIgaGFuZCB5 b3UgYXJlIHJpZ2h0LCBpdCBkb2VzIGhhdmUgbXVjaCBhYm91dCB0aGUgbXVsdGlwbGV4ZXIuIEEg dGl0bGUgY292ZXJpbmcgYWxsIHRocmVlIHdvdWtkIHN0YXJ0IGdldHRpbmcgY3VtYmVyc29tZS4g V2lsbCB0YWtlIHRoaXMgb25lIGF3YXkgdG8gdGhpbmsgYWJvdXQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIGZyb20mbmJzcDs8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0 LXVzYWdlLTAzI3NlY3Rpb24tNC40IiB0YXJnZXQ9Il9ibGFuayI+PGI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj40LjQ8L3NwYW4+PC9iPjwvYT48Yj4uDQog QWRkcmVzc2VzIFJlcXVpcmUgQXR0cmlidXRlczo8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgQW4gdW5tb2RpZmllZCBleHRlbnNpb24gdG8g TkhEUCB3b3VsZCBpZ25vcmUgc3VjaCBhZGRyZXNzZXMsPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IGFzIHJlcXVpcmVkLCBhcyBpdCBkb2VzIG5vdCBzdXBwb3J0IHRoYXQgc3Bl Y2lhbGl6ZWQgcHVycG9zZS48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+QXQgZmlyc3QgZ2xhbmNlLCAodG8gbWUpIHRoaXMgcmVhZHMg YXMg4oCeQWxsIGFkZHJlc3NlcyB0aGF0IGFyZSBhc3NvY2lhdGVkIHdpdGggYW4gdW5rbm93biBU TFYgYXJlIGlnbm9yZWTigJwsIHdoaWNoIGlzIG9idmlvdXNseSBub25zZW5zZSAoYnV0IHF1aXRl IHBhbmljLWluZHVjaW5nIDpEKS4gSeKAmWQgcHJvcG9zZQ0KIHRvIHJld29yZCBpdCB0byBzb21l dGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cHJlPiZuYnNwOyZuYnNwOyBBbiB1bm1vZGlmaWVkIGV4dGVuc2lvbiB0byBOSERQIHdv dWxkIG5vdCBjb25zaWRlciB0aGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IGFkZHJlc3MgdG8gYmUgb2YgYSBuZWlnaGJvciwgYXMgaXQgaXMgbGFja2luZyBhIExJTktfU1RB VFVTPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG9yIE9USEVSX05FSUdIQiBU TFYuPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkkgdGFrZSB5b3VyIHBvaW50LCBidXQgSSB0aGluayB0aGF0IGlmIHRo ZSBhZGRyZXNzIGVuZHMgdXAgd2l0aCBubyByZWxldmFudCBhc3NvY2lhdGVkIFRMVnMgdGhlbiBp dCBpcyBpZ25vcmVkIGlzIGFsc28gYSBwb2ludC4gSSBkYXJlIHNheSB3ZSBjYW4gd29yZHNtaXRo IHNvbWV0aGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+QWxzbywgSSBkb27igJl0IHF1aXRlIGdldCB3aGVyZSB5b3XigJlyZSBnb2luZyB3aXRo IHRoZSBsYXN0IHBhcmFncmFwaCBvZiB0aGF0IHNlY3Rpb24gKOKAnDxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij5UaGVzZSByZXN0cmljdGlvbnMgZG8gbm90LCBob3dldmVyLCBtZWFuIHRo YXQgYWRkZWQgaW5mb3JtYXRpb24NCiBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHByZT4mbmJzcDsmbmJzcDsgY29tcGxldGVseSBpZ25vcmVkIGZvciBwdXJwb3NlcyBvZiB0aGUg YmFzZSBwcm90b2NvbC7igJ0pLi4uPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+UmVhZCBvbiwgdGhlIHJlc3Qgb2YgdGhlIHBhcmFncmFwaCBkZXNj cmliZXMgdGhlIGNhc2Ugd2hlcmUgbm90LiBCdXQgd2UgbWlnaHQgdGVsZWdyYXBoIHRoYXQgYmV0 dGVyIGluIHRoZSBvcGVuaW5nIHNlbnRlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIHJlZ2FyZGluZyB0aGUgbWFwcyBpbiZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQt dXNhZ2UtMDMjc2VjdGlvbi00LjUiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjQuNTwvc3Bhbj48L2I+PC9hPjxiPi4NCiBJ bmZvcm1hdGlvbiBSZXByZXNlbnRhdGlvbjo8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJltIGFmcmFpZCBJIGp1c3QgZG9u4oCZdCBy ZWFsbHkgdW5kZXJzdGFuZCB0aGUgcHVycG9zZSBvZiB0aGlzIHNlY3Rpb24gYW5kIHRoZSBtYXBw aW5nIG5vdGF0aW9uLiBJ4oCZbSBhc3N1bWluZyB0aGF0IHRoZSBtYXBzIGFyZSBzdXBwb3NlZCB0 byBvZmZlciBhIHdheSBvZiBkZXNjcmliaW5nIGhvdyBhIFRMViByZWxhdGVzDQogdG8gYSBtZXNz YWdlIG9yIGFuIGFkZHJlc3M/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHNvLCB3aHkgZG9lcyBpdCBvbmx5IG1lbnRpb24gZXh0 ZW5zaW9uIHR5cGVzLCBidXQgbm90IHRoZSBiYXNpcyB0eXBlcz88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBzYXlzIGV4dGVuZGVk IHR5cGVzLCBtZWFuaW5nIHRoZSBjb21iaW5hdGlvbiBvZiB0aGUgdHdvLiBCdXQgZnVsbCB0eXBl IHdvdWxkIGJlIGJldHRlciwgYXMgYWxtb3N0IGRlZmluZWQgaW4gNTQ0NC4gSW4gZmFjdCBJIHRo aW5rIHdlIHNob3VsZCBhZGQgYSBjb21tZW50IHRvIHRoZSBub3RhdGlvbiBzZWN0aW9uLg0KICg1 NDQ0IHVzZXMgYSBzeW1ib2xpYyBuYW1lIHJhdGhlciB0aGFuIHRoZSBwaHJhc2UuKTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PciBpcyBpdCBzdXBw b3NlZCB0byBiZSB1c2VkIHNvbWV0aGluZyBsaWtlIHRoaXM6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q291cmllciI+QkFTRV9UTFY8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNvdXJpZXIiPk1lc3NhZ2U6Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q291cmllciI+KGJhc2VfdGx2X2V4dGVuc2lvbl90eXBlXzEpIC0mZ3Q7ICgyIG9jdGV0cywg JnF1b3Q7dmFsdWUgYSB3aGVuIGNvbmRpdGlvbiB4IGlzIG1ldCZxdW90Oyk8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4oYmFzZV90bHZfZXh0ZW5zaW9uX3R5cGVfMikgLSZn dDsgKDIgb2N0ZXRzLCAmcXVvdDt2YWx1ZSBiIHdoZW4gY29uZGl0aW9uIHkgaXMgbWV0JnF1b3Q7 KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPj8gQWxzbywgSSBkb27igJl0IHF1aXRlIGdldCBob3cgdGhpcyB3b3VsZCBiZSB1 c2VkIGluIGZ1dHVyZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucz8gT3IgYWlkIGluIGltcGxlbWVu dGluZyBSRkM1NDQ0IHBhcnNlcnM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkFuIGV4YW1wbGUgb3IgYSBjbGFyaWZpY2F0aW9uIHdvdWxkIGJl IHZlcnkgaGVscGZ1bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5JdCdzIGEgd2F5IG9mIGxvb2tpbmcgYXQgdGhpbmdzLiBCdXQgbm90 IHRoZSBvbmx5IG9uZSwgaXQgZ29lcyBvbiB0byBkaXNjdXNzIHZhcmlhbnRzLiBJIHRoaW5rIGl0 IG1vc3RseSBjb21lcyB1bmRlciBoZWFkaW5nIG9mIGlmIHVzZWZ1bCB1c2UgaXQsIGlmIG5vdCBz a2lwIGl0LiBXZSdsbCB0YWtlIGFub3RoZXINCiBsb29rLCBidXQgSSBkb24ndCB0aGluayB0aGlz IHdpbGwgZXZlciBiZSBlbGVtZW50YXJ5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4qIHJlZ2FyZGluZyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlv bi00LjYiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPjQuNjwvc3Bhbj48L2I+PC9hPjxiPi4NCiBUTFZzOjwvYj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gZ2VuZXJh bCwgaXTigJlzIG5vdCBjbGVhciBldmVyeXdoZXJlIGluIHRoZSBzZWN0aW9uIHdoZXRoZXIgeW91 4oCZcmUgdGFsa2luZyB0byBSRkM1NDQ0IHBhcnNlci9idWlsZGVyIGltcGxlbWVudG9ycyBvciBw cm90b2NvbCBkZXNpZ25lcnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHByZT4mbmJzcDsmbmJzcDsgQSBwcm90b2NvbCBTSE9VTEQgdXNlIGFuIGVmZmljaWVudDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyByZXByZXNlbnRhdGlvbiwgYnV0IHRo aXMgaXMgYSBxdWFsaXR5IG9mIGltcGxlbWVudGF0aW9uIGlzc3VlLjxvOnA+PC9vOnA+PC9wcmU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SeKAmW0gbm90IHN1cmUgd2hlcmUg eW914oCZcmUgZ29pbmcgd2l0aCB0aGUgbGFzdCBwYXJ0IG9mIHRoYXQgc2VudGVuY2U/IEnigJlk IHJld29yZCBpdCB0byBzb21ldGhpbmcgbGlrZSDigJ5BIHByb3RvY29sIFNIT1VMRCB1c2UgYW4g ZWZmaWNpZW50IHJlcHJlc2VudGF0aW9uLCBhdm9pZGluZyB1bm5lY2Vzc2FyaWx5IHZlcmJvc2UN CiB1c2Ugb2YgVExWcyBhbmQgZXh0ZW5zaW9uIHR5cGVzLiBIb3dldmVyLCB0aGUgZmluYWwgYXJy YW5nZW1lbnQgaW4gYSBtZXNzYWdlLSBvciBhZGRyZXNzVExWIGJsb2NrIGlzICZuYnNwO2EgcXVh bGl0eSBvZiBpbXBsZW1lbnRhdGlvbiBpc3N1ZeKAnCAoaW4gY2FzZSB0aGF04oCZcyB3aGF0IHlv dSBtZWFudCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5ObywgeW91J3JlIGNvbnNpZGVyaW5nIHRoZSBwcm90b2NvbCBk ZXNpZ24uIFRoaXMgaXMgY29uc2lkZXJpbmcgdGhlIHByb3RvY29sIG9iamVjdCB0aGF0IGltcGxl bWVudHMgdGhlIHByb3RvY29sLiBUaGVyZSBpc24ndCBhIG9uZSB0byBvbmUgbWFwcGluZyBmcm9t IGluZm9ybWF0aW9uIHRvIHJlcHJlc2VudGF0aW9uLA0KIGl0J3MgdXAgdG8gdGhlIGltcGxlbWVu dGF0aW9uIHRvIGRvIGl0IGVmZmljaWVudGx5LiBEaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zIG9m IHRoZSBzYW1lIHByb3RvY29sIHNwZWNpZmljYXRpb24gbWF5IGRvIGJldHRlciBvciB3b3JzZSBo ZXJlLiAoVHJpdmlhbCBjYXNlLCBhbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBjaG9vc2UgdG8gbmV2 ZXIgY29tcHJlc3MgYWRkcmVzc2VzLiBCYWQgaWRlYSwgYnV0IGxlZ2FsLik8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5kIHRoZW46PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgQTxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBwcm90b2NvbCBNVVNUIHJlY29nbml6ZSBhbnkgcGVy bWl0dGVkIHJlcHJlc2VudGF0aW9uIG9mIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyBpbmZvcm1hdGlvbjsgZXZlbiBpZiBpdCBjaG9vc2VzIHRvIChmb3IgZXhhbXBsZSkg b25seSB1c2UgbXVsdGl2YWx1ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBU TFZzLCBpdCBNVVNUIHJlY29nbml6ZSBzaW5nbGUgdmFsdWUgVExWcyAoYW5kIHZpY2UgdmVyc2Ep LjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+4oCm IEkgdGhvdWdodCBwcm90b2NvbHMgd2VyZW7igJl0IHN1cHBvc2VkIHRvIHNwZWNpZnkgd2hldGhl ciBhIFRMViBpcyBhcnJhbmdlZCAoZm9yIGV4YW1wbGUpIGFzIGEgbXVsdGl2YWx1ZSBUTFY/ITxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SW1wbGVtZW50YXRpb24gYWdhaW4sIG5vdCBkZXNpZ24uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmQgc28sIHNpbmNl IGEgcHJvdG9jb2wgc2hvdWxkbid0IGJlIGNvbmNlcm5lZCB3aXRoIG11bHRpdmFsdWUgVExWcyBh bmQgdGhlIGxpa2UsIHdvdWxkbuKAmXQgaXQgYmUgdGhlICpSRkM1NDQ0IGltcGxlbWVudGF0aW9u KiB0aGF0IE1VU1QgcmVjb2duaXplIGFueSBwZXJtaXR0ZWQgcmVwcmVzZW50YXRpb24/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+WW91J3JlIGFzc3VtaW5nIHRoYXQgdGhlcmUgaXMgYW4gUkZDIDU0NDQgaW1w bGVtZW50YXRpb24uIFRoYXQncyB0aGUgc2FtZSB3YXkgdG8gd29yayBpZiB5b3UgcGxhbiB0byBp bXBsZW1lbnQgbW9yZSB0aGFuIG9uZSBwcm90b2NvbC4gQnV0IG5vdGhpbmcgc2F5cyB5b3UgaGF2 ZSB0byBkbyBpdCB0aGF0IHdheS4NCiBUaGUgYXJjaGl0ZWN0dXJlIGRlZmluZWQgYnkgNTQ5OCBh ZG1pdHMgb2YgdGhlIG11bHRpcGxleGVyIGFuZCBwcm90b2NvbHMsIGFuZCB0aHVzIHRoZXNlIGFy ZSBydWxlcyBvbiB0aGUgcHJvdG9jb2wuIElmIHByb3RvY29scyBkZWxlZ2F0ZSBhbGwgdGhlaXIg Y29tbW9uIHdvcmsgdG8gc29tZXRoaW5nIChwYXJzZXIvY3JlYXRvcikgdGhlbiBpdCBpbmhlcml0 cyB0aG9zZSByZXN0cmljdGlvbnMsIGJ1dCB0aGF0J3Mgbm90IGRlZmluZWQsIGFuZCB3ZQ0KIGNh bid0IGFzc3VtZSBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T3IgaXMgdGhpcyBwYXJhZ3JhcGggcmVhbGx5IGp1c3QgYSBjb21wbGljYXRlZCB3 YXkgb2Ygc2F5aW5nIOKAnmFzIGEgcHJvdG9jb2wgZGVzaWduZXIsIG1ha2Ugc3VyZSB0byBub3Qg c3BlY2lmeS9yZWx5IG9uIHRoaW5ncyBsaWtlIChmb3IgZXhhbXBsZSkgbXVsdGl2YWx1ZSBUTFZz LCBzaW5jZSB5b3VyIG1lc3NhZ2VzDQogaGF2ZSB0byB3b3JrIHdpdGggKmFueSogcmVwcmVzZW50 YXRpb27igJw/IElmIHNvLCBJIHRoaW5rIHRoYXQgc2hvdWxkIGJlIGRvbmUgaW4gYSBsZXNzIGNv bXBsaWNhdGVkIGZhc2hpb24gKHNlZSBiZWxvdykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiogcmVnYXJkaW5nJm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZj NTQ0NC11c2FnZS0wMyNzZWN0aW9uLTUiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjU8L3NwYW4+PC9iPjwvYT48Yj4uDQog U3RydWN0dXJlOjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+U2luY2UgdGhpcyBzZWN0aW9uIHRhbGtzIGEgbG90IGFib3V0IGZsYWdzLCBp dOKAmWQgYmUgbmljZSBpZiBpdHMgdGl0bGUgcmVwcmVzZW50ZWQgdGhhdC4gTWF5YmUgY29uc2lk ZXIgcmVuYW1pbmcgaXQgdG8mbmJzcDvigJ5TdHJ1Y3R1cmUgYW5kIEZsYWdz4oCcJm5ic3A7b3Ig c28/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SSBtb3N0bHkgZG9uJ3QgYWdyZWUuIFN0cnVjdHVyZSBpcyB0aGUgc3ViamVjdCwgZmxh Z3MgYXJlIGEgZGV0YWlsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4qIGZyb20mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi4xIiB0YXJnZXQ9 Il9ibGFuayI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25l Ij42LjE8L3NwYW4+PC9iPjwvYT48Yj4uDQogQWRkcmVzcyBCbG9jayBDb21wcmVzc2lvbjo8L2I+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgQ29t cHJlc3Npb24gb2YgYWRkcmVzc2VzIGluIGFuIEFkZHJlc3MgQmxvY2sgY29uc2lkZXJzIGFkZHJl c3NlcyB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjb25zaXN0IG9mIGEg SGVhZCwgYSBNaWQsIGFuZCBhIFRhaWwsIHdoZXJlIGFsbCBhZGRyZXNzZXMgaW4gYW48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgQWRkcmVzcyBCbG9jayBoYXZlIHRoZSBzYW1l IEhlYWQgYW5kIFRhaWwsIGJ1dCBkaWZmZXJlbnQgTWlkcy48bzpwPjwvbzpwPjwvcHJlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJlkIGZpbmQgdGhp cyBzZW50ZW5jZSBlYXNpZXIgdG8gcmVhZCBpZiBpdCBzdGFydGVkIHdpdGgg4oCcQ29tcHJlc3Np b24gb2YgYWRkcmVzc2VzIGluIGFuIEFkZHJlc3MgQmxvY2sgaXMgcG9zc2libGUgd2hlbiBhZGRy ZXNzZXMgY29uc2lzdCBvZiBhIEhlYWQsIGEgTWlkIFvigKZd4oCdLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vLiBUaGF0J3MgbWlz c2luZyB0aGUgcG9pbnQgYW5kIG1pc2xlYWRpbmcuIEFkZHJlc3NlcyBhcmUgYWx3YXlzIGNvbnNp ZGVyZWQgdG8gaGF2ZSB0aGUgaGVhZC9taWQvdGFpbCBmb3JtYXQuIENvbXByZXNzaW9uIGlzIHBv c3NpYmxlIGlmIGVpdGhlciB0aGUgaGVhZCBvciB0YWlsIChvciBib3RoKSBpcyBub24tZW1wdHku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiogZnJv bSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1h bmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi02LjEiIHRhcmdldD0iX2JsYW5rIj48Yj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjYuMTwvc3Bhbj48L2I+ PC9hPjxiPi4NCiBBZGRyZXNzIEJsb2NrIENvbXByZXNzaW9uOjwvYj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IFB1dHRpbmcgYWRkcmVzc2VzIGludG8gYSBtZXNzYWdlIGVmZmljaWVudGx5IGFsc28g aGFzIHRvIGluY2x1ZGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2h5IOKAnmhhcyB0 b+KAnD8gSeKAmWQgdGhpbmsgdGhhdCB3b3VsZCBiZSBhIOKAnm1heeKAnC4gTXVsdGlwbGUgQWRy ZXNzIEJsb2NrcyBhbmQvb3IgcmVvcmRlcmluZyBkb27igJl0IGluY3JlYXNlIGVmZmljaWVuY3kg aW4gYWxsIHBvc3NpYmxlIGNhc2VzLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB0aGF0J3MgdGhlIHdyb25nIGNoYW5n ZS4gUmF0aGVyICZxdW90O2luY2x1ZGUmcXVvdDsgc2hvdWxkIGJlICZxdW90O2NvbnNpZGVyJnF1 b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4q IGZyb20mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi4yIiB0YXJnZXQ9Il9ibGFuayI+PGI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj42LjI8L3NwYW4+ PC9iPjwvYT48Yj4uDQogVExWczo8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbLi4uXSBUaGlzIGlzIGV2ZW4gcG9z c2libGUgaWYgdGhlIE1QUiBUTFYgc3BlY2lmaWVkIGluPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9MU1J2MiBbPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzcxODEiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iJnF1b3Q7 VGhlIE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgUHJvdG9jb2wgdmVyc2lvbiAyJnF1b3Q7 Ij5SRkM3MTgxPC9hPl0gaXMgYWRkZWQ7IGJ1dCBpdCBpcyBub3QgcG9zc2libGUsIGluIGdlbmVy YWwsIGlmPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRoZSBMSU5LX01FVFJJQyBUTFYgaXMgYWxzbyBhZGRlZC48bzpwPjwvbzpwPjwvcHJlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2h5IGlzIGl0IG5vdCBw b3NzaWJsZSBmb3IgdGhlIGxhdHRlcj8gSWYgdGhhdCBjb3VsZCBiZSBleHBsYWluZWQvaGludGVk IGF0IGluIGEgaGFsZiBzZW50ZW5jZSwgSSB0aGluayBpdOKAmWQgYmUgaGVscGZ1bCBpbmZvcm1h dGlvbiB0byBoYXZlIGluIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGF0J3MgdmVyeSBoYXJkLCBhbmQgbm90IGp1 c3QgYmVjYXVzZSBpdCdzIGEgbmVnYXRpdmUuIEl0J3MgcmVhbGx5IGFuIG9ic2VydmF0aW9uIHRo YXQgbW90aXZhdGVzIHRoZSBkdXNjdXNzaW9uLiBBIGhhbGYgc2VudGVuY2Ugd291bGQgSSB0aGlu ayBjb25mdXNlIG1vcmUgdGhhbiBpdCBlbmxpZ2h0ZW5zIChpdCdzDQogYmVjYXVzZSB5b3UgaGF2 ZSB0b28gbWFueSBjb25zdHJhaW50cyB0byBzYXRpc2Z5IGF0IG9uY2UgLSBJIGRvdWJ0IHRoYXQg aGVscGVkKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEluIGEgdHlwaWNhbCBjYXNlIHdoZXJlIGE8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTElOS19TVEFUVVMgVExWIHVz ZXMgb25seSB0aGUgVmFsdWVzIEhFQVJEIGFuZCBTWU1NRVRSSUMsIHdpdGg8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5vdWdoIGFkZHJlc3Nl cywgc29ydGVkIGFwcHJvcHJpYXRlbHksIHR3byBzaW5nbGUgdmFsdWUgVExWcyBjYW48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmUgbW9yZSBl ZmZpY2llbnQgdGhhbiBvbmUgbXVsdGl2YWx1ZSBUTFYuPG86cD48L286cD48L3ByZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNhbWUgdGhpbmc6IHdoeT88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5I ZXJlIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgb2J2aW91cyB0byBhbnlvbmUgd2hvIGhhcyBsb29r ZWQgYXQgNTQ0NC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+KiByZWdhcmRpbmcgdGhlIHNlY29uZCBwYXJhZ3JhcGggZnJvbSZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNh Z2UtMDMjc2VjdGlvbi02LjMiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjYuMzwvc3Bhbj48L2I+PC9hPjxiPi4NCiBUTFYg VmFsdWVzPC9iPiwgaS5lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJz cDsgJm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoaXMgYXBwcm9h Y2ggd2FzIHNwZWNpZmllZCBpbiBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzcxODgiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iQy4gYW5kIFQuIENsYXVzZW4iPlJGQzcx ODg8L2E+XSwgYW5kIHJlcXVpcmVkIGZvciBwcm90b2NvbHM8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgdGhhdCBleHRlbmQgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2MTMwIiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IiZxdW90O01vYmlsZSBBZCBI b2MgTmV0d29yayAoTUFORVQpIE5laWdoYm9yaG9vZCBEaXNjb3ZlcnkgUHJvdG9jb2wgKE5IRFAp JnF1b3Q7Ij5SRkM2MTMwPC9hPl0gYW5kIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNzE4MSIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtUaGUgT3B0aW1pemVk IExpbmsgU3RhdGUgUm91dGluZyBQcm90b2NvbCB2ZXJzaW9uIDImcXVvdDsiPlJGQzcxODE8L2E+ XS4mbmJzcDsgSXQgaXMgaGVyZSBSRUNPTU1FTkRFRCB0aGF0PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IHRoaXMgYXBwcm9hY2ggaXMgZm9sbG93ZWQgd2hlbiBkZWZpbmluZyBh bnkgQWRkcmVzcyBCbG9jayBUTFYgdGhhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBtYXkgYmUgdXNlZCBieSBhIHByb3RvY29sIHVzaW5nIFs8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNTQ0NCIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtH ZW5lcmFsaXplZCBNQU5FVCBQYWNrZXQvTWVzc2FnZSBGb3JtYXQmcXVvdDsiPlJGQzU0NDQ8L2E+ XS48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhlIHRlcm0g4oCedGhpcyBhcHByb2FjaOKAnCBjb25mdXNlZCBtZSwgc2luY2UgSSBp bml0aWFsbHkgJm5ic3A7dGhvdWdodCBpdCBtZWFudCDigJ50aGUgYXBwcm9hY2ggaXMgdG8gdXNl IFVOU1BFQ0lGSUVEIGluIGEgd2F5IHRoYXQgbWFrZXMgc2Vuc2XigJwgcmF0aGVyIHRoYW4g4oCe dGhlIGFwcHJvYWNoIGlzIHRvIHVzZSBVTlNQRUNJRklFROKAnC4NCiBNYXliZSB0aGF0IGNvdWxk IGJlIHJld29yZGVkIHRvIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPlRoZSBVTlNQRUNJRklFRCBUTFYgYW5kIGl0cyB1c2Fn ZSB3YXMgc3BlY2lmaWVkIGluIFtSRkM3MTg4XeKApjwvc3Bhbj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vLiBUaGVyZSBp cyBubyBVTlNQRUNJRklFRCBUTFYuIFRoZXJlIGlzIGEgcmVjb21tZW5kYXRpb24gdG8gaW5jbHVk ZSBhbiBVTlNQRUNJRklFRCB2YWx1ZSBpbiBhIFRMVi4gQnV0IHJlYWxseSwgd2UndmUgZGVzY3Jp YmVkIHRoaXMgb25jZSBpbiA3MTg4LCBpdCdzIHRoZXJlIHRvIHJlYWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiogcmVnYXJkaW5nJm5ic3A7PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0 NC11c2FnZS0wMyNzZWN0aW9uLTYuMyIgdGFyZ2V0PSJfYmxhbmsiPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+Ni4zPC9zcGFuPjwvYj48L2E+PGI+Lg0K IFRMViBWYWx1ZXM6PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5UaGUgc2Vjb25kIHBhcmFncmFwaCBpcyBhIGJpdCBjb25mdXNpbmcgYW5k IHNlZW1zIHRvIGV4cGxhaW5nIHJvZ2hseSB0aGUgc2FtZSB0aGluZ3MgYXMgdGhlIGZvdXJ0aCBw YXJhZ3JhcGhzLiBJ4oCZZCBwcm9wb3NlIHRvIG1lcmdlIHRoZSBzZWNvbmQgaW50byB0aGUgZm91 cnRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkknbSBub3Qgc3VyZSBJIGV4YWN0bHkgYWdyZWUsIGJ1dCB0aGUgb3JkZXJpbmcgaW4g dGhhdCBzZWN0aW9uIGNvdWxkIGJlIGltcHJvdmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIGZyb20mbmJzcDs8YSBuYW1lPSJtXy00NTI5NjM3 OTk3MTQ3NTg1NTAyX21fNjU2NzU3MTYxNTEyMjc4Ij48L2E+PGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9u LTYuNCIgdGFyZ2V0PSJfYmxhbmsiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRl Y29yYXRpb246bm9uZSI+Ni40PC9zcGFuPjwvYj48L2E+PGI+Lg0KIEF1dG9tYXRpb246PC9iPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBw b3NzaWJsZSBnYWluIGRlcGVuZHMgb24gdGhlIGVmZmljaWVuY3k8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UgY3JlYXRpb24sPG86cD48 L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRo ZSB0ZXJtIOKAnnRoZSBvcmlnaW5hbCBtZXNzYWdlIGNyZWF0aW9u4oCcIHNlZW1zIGEgYml0IGFt YmlndW91c+KAkyBkb2VzIHRoaXMgcmVmZXIgdG8gdGhlIG1lc3NhZ2UgYXMgY3JlYXRlZCBieSBh biBSRkM1NDQ0IG1lc3NhZ2UgYnVpbGRlciBpbXBsZW1lbnRhdGlvbj88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFkZGl0aW9uYWxseSwg SSdtIGNvbmNlcm5lZCBhYm91dCB0d28gdGhpbmdzIHRoYXQgKmFyZW7igJl0KiBpbiB0aGUgZHJh ZnQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4qICZuYnNwO1NvbWUgb2YgdGhlIEFPRFZ2MiBjby1hdXRob3JzIGFuZCBtZSBoYXZlIGFz a2VkIGZvciBhIGxpc3Qgb2Yg4oCeYXMgYSBwcm90b2NvbCwgeW91IGNhbiBzZXQgYWxsIG9mIHRo ZXNlIGZpZWxkcyBvZiBhIG1lc3NhZ2UsIGJ1dCBwbGVhc2UgbGVhdmUgdGhlIHJlc3QgYWxvbmXi gJwsIHdoaWNoIHdvdWxk4oCZdmUgc2F2ZWQNCiB1cyBtYW55IGhvdXJzIG9mIGRpc2N1c3Npb25z IChhbmQgSGVubmluZyBhIGxvdCBvZiB0aW1lIHNwZW50IGV4cGxhaW5pbmcgdGhlc2UgdGhpbmdz 4oCmKS4gVGhlc2UgcmVxdWVzdHMgaGF2ZSBiZWVuIG1ldCB3aXRoIGEgcmVmdXNhbCB0byBzcGVj aWZ5IGEgY29uY3JldGUgQVBJLCBhcyBzdWNoIGFuIGVmZm9ydCBpcyBkZXBlbmRlbnQgb24gb3V0 c2lkZSBmYWN0b3JzIHN1Y2ggYXMgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2Ugb3Igc29mdHdhcmUgYXJj aGl0ZWN0dXJlLg0KIEkgYWdyZWUgd2l0aCB0aGlzIG5vdGlvbiwgYnV0IGEgcHJvZ3JhbW1pbmct bGFuZ3VhZ2UgZGVwZW5kZW50IEFQSSBpcyBub3Qgd2hhdCB3ZeKAmXZlIGFza2VkIGZvci4gSeKA mXZlIHRyaWVkIHRvIHN1cHBseSBhIHNrZXRjaCBvZiB3aGF0IEkgZGlkIGFzayBmb3IgaW4gWzFd LCBidXQgdW5mb3J0dW5hdGVseSBJIGRpZG7igJl0IGdldCBhbiBhbnN3ZXIgKGFuZCBhcyBmYXIg YXMgSSBjYW4gc2VlIGl0LCB0aGUgZHJhZnQgd2FzbuKAmXQgY2hhbmdlZCBlaXRoZXIpLg0KIEkg c3RpbGwgdGhpbmsgdGhhdCBzdWNoIGEgbGlzdCwgaW4gd2hhdGV2ZXIgZm9ybSwgd291bGQgYmUg dmVyeSBoZWxwZnVsIGZvciBmdXR1cmUgSW50ZXJuZXQtRHJhZnQgYXV0aG9ycyBhbmQgSSBhbHNv IHRoaW5rIHRoaXMgcmVxdWVzdCBpcyBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIGludGVudGlvbnMg c3RhdGVkIGluJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPjEuMSBIaXN0 b3J5IGFuZCBQdXJwb3NlLCZuYnNwOzwvc3Bhbj5hbmQgSSB0aGluaw0KIGl0IHNob3VsZCBiZSBp bmNsdWRlZCBpbiB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm8uIFRoZXJlIGFyZSBtYW55IHJlYXNvbnMgd2h5 IHdlJ3JlIGp1c3Qgbm90IHRvdWNoaW5nIHRoaXMgb25lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T25lIGlzIHRoYXQgbGFuZ3VhZ2Ug aW5kZXBlbmRlbmNlIGlzIGEgbWlyYWdlLiBIb3cgeW91IGdvIGFib3V0IHRoaW5ncyBpcyBjb21w bGV0ZWx5IGRpZmZlcmVudCBpbiwgZm9yIGV4YW1wbGUgYW4gb2JqZWN0IG9yaWVudGVkIGxhbmd1 YWdlIHRoYW4gb25lIHRoYXQgaXNuJ3QuIFNlY3Rpb24gNC41IHNob3dzDQogdGhhdCB0aGVyZSBh cmUgcXVpdGUgZGlmZmVyZW50IHdheXMgb2YgZG9pbmcgdGhpbmdzIGV2ZW4gZ2l2ZW4gYSBkZWNp c2lvbiB0byB1c2UgYSBtYXAgYXBwcm9hY2gsIGFuZCB0aGVyZSBhcmUgb3RoZXIgYXBwcm9hY2hl cyB0aGFuIHRoYXQuIEl0IHdvdWxkIGJlIHdyb25nIGFuZCBiZXlvbmQgb3VyIGNvbXBldGVuY2Ug dG8gc3VnZ2VzdCBvbmUgb2YgdGhlc2UgYXMgJnF1b3Q7YmVzdCZxdW90Oy4gVGhlcmUncyByZWFz b25zIHRoZSBJRVRGIGRvZXNuJ3QgZG8gdGhpcywNCiBhbmQgdGhhdCdzIG9uZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBsdXMsIGZy YW5rbHksIHRoZSB3b3JrIGl0IHdvdWxkIHRha2UgaXMgYmV5b25kIHdoYXQgd2UgY2hvb3NlIHRv IHNwZW5kLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbHQ7U3BlYWtpbmcgYXMgYSBXRyBQYXJ0aWNp cGFudCZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkknbSBjb25mdXNlZCAod2hpY2ggaXMgYW4gYWx0b2dldGhlciB0b28gY29tbW9u IG9jY3VycmVuY2UgdGhlc2UgZGF5cykuIEkgZ2V0IHRoYXQgd2UgZG9uJ3Qgd2FudCB0byBzcGVj aWZ5IGFuIEFQSS4gQnV0IEkgdGhpbmsgdGhlIGRpc2N1c3Npb24gYWJvdXQgZmllbGRzIGEgcHJv dG9jb2wgY2FuIGFuZCBjYW4ndA0KIHRvdWNoIGluIGEgbWVzc2FnZXMgaXMgYSBnb29kIHRoaW5n IC0gYW5kIGl0J3Mgb25lIHNwb3Qgd2hlcmUgSSwgdG9vLCBmaW5kIHRoZSBkb2N1bWVudCB3YW50 aW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VG8gcGFyYXBocmFzZSBzb21ldGhpbmcgSSd2ZSBzYWlkIGJlZm9yZSwgSSBi ZWxpZXZlIHRoYXQgUkZDIDU0NDQgY2hhbmdlcyB0aGUgcmVsYXRpb25zaGlwIHRoYXQgYSByb3V0 aW5nIHByb3RvY29sIGhhcyB3aXRoIGFuICZxdW90O2ludGVyZmFjZSZxdW90Oy4gSSdtIG5vdCBj b21tZW50aW5nIG9uIHdoZXRoZXIgb3Igbm90DQogdGhhdCdzIGEgZ29vZCB0aGluZywgb3IgYSBi YWQgdGhpbmcgLSBqdXN0IHRoYXQgaXQgZG9lcyBjaGFuZ2UgdGhlIHJlbGF0aW9uc2hpcC4gVGhp cyBjaGFuZ2UgaGFzIGJlZW4gYXQgdGhlIHJvb3Qgb2Ygc29tZSBvZiB0aGUgbG9uZy1ydW5uaW5n IGRpc2N1c3Npb25zIGFzIHRvIHdoZXRoZXIgcHJvdG9jb2xzIHVuZGVyIGRldmVsb3BtZW50IHdl cmUgUkZDIDU0NDQgY29tcGxpYW50IG9yIG5vdC4gVGhlIGdvYWwgb2YgdGhpcyBkb2N1bWVudCBi ZWluZw0KIHRvIGVsaW1pbmF0ZSAoaXQncyBhIGdvYWwsIHByb2JhYmx5IG5vdCByZWFjaGFibGUp IHRob3NlIGRpc2N1c3Npb25zLCBJJ2QgbGlrZSB0byBzZWUgdGhhdCBpbmZvcm1hdGlvbiBpbiB0 aGUgZG9jdW1lbnQgaW4gc29tZSBmb3JtLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdtIGludGVyZXN0ZWQgaW4gc2VlaW5n IHRoaXMgZG9jdW1lbnQgcHJvZ3Jlc3MsIGFuZCBldmVudHVhbGx5IGJlIHB1Ymxpc2hlZC4gSSB0 aGluayBpdCB3aWxsIGhlbHAgZnV0dXJlIHByb3RvY29sIGRlc2lnbmVycyB0byBiZXR0ZXIgdXNl IFJGQyA1NDQ0LiBCdXQgSSB3b3VsZCBsaWtlIHRvIHNlZSAqc29tZXRoaW5nKg0KIGFsb25nIHRo ZSBsaW5lcyBvZiB3aGF0IExvdHRlIGlzIHJlcXVlc3RpbmcsIGFzIEkgdGhpbmsgaXQgd2lsbCBp bXByb3ZlIHRoZSBkb2MuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TdGFuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiogQXMgdGhlIGV4YWN0 IHJ1bGVzIGZvciB1c2luZy9zZXR0aW5nIHRoZSBob3AgY291bnQgJmFtcDsgaG9wLWxpbWl0IGZp ZWxkcyBhcmUgY3VycmVudGx5IGJlaW5nIGRpc2N1c3NlZCB3LyByZWdhcmQgdG8gQU9EVnYyIGlu IGFub3RoZXIgdGhyZWFkIFsyXeKAkyBzaG91bGQgYSBkZWZpbml0aXZlIGFuc3dlciB0byB0aGF0 DQogcXVlc3Rpb24gYmUgcGFydCBvZiA1NDQ0LXVzYWdlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPllvdSBkb24ndCB3YW50IHRoYXQu IEJlY2F1c2UgaWYgd2UgZGlkIHNwZWNpZnkgdGhhdCB5b3UnZCBmaW5kIHlvdXJzZWxmIG1vcmUg Y29uc3RyYWluZWQgdGhhbiB5b3Ugd2FudCB0byBiZS4gVGhlcmUgaXMgYSBkZXNpZ24gaW50ZW50 IGRlc2NyaWJlZCBpbiA1NDQ0LCBidXQgaXQgYXNzdW1lcyBpbW11dGFibGUNCiBtZXNzYWdlcy4g V2hpY2ggeW91IGRvbid0IHdhbnQuIFJlYWxseSwgd2UncmUgZG9pbmcgeW91IGEgZmF2b3VyIGJ5 IG5vdCBpbXBvc2luZyBvbiB5b3UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TG90dGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlsxXSZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cxODA4Mi5o dG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9tYW5ldC9jdXJyZW50L21zZzE4MDgyLmh0bWw8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlsyXQ0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21zZzE4Njc0Lmh0bWwiIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFu ZXQvY3VycmVudC9tc2cxODY3NC5odG1sPC9hPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ QW0gMDYuMDQuMjAxNiB1bSAxOToxNCBzY2hyaWViIEp1c3RpbiBEZWFuICZsdDs8YSBocmVmPSJt YWlsdG86YmViZW1hc3RlckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5iZWJlbWFzdGVyQGdt YWlsLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoZSBjaGFpcnMgYWdyZWUgdGhhdCBhIDMgd2VlayBXR0xDIGlzIGFwcHJvcHJp YXRlLiZuYnNwOyBFdmVyeW9uZSBwbGVhc2UgcmVhZCB0aGUgZHJhZnQgZWFybHkgYW5kIGdldCBj b21tZW50cyBpbiBlYXJseSBzbyB0aGF0IHRoZXkgY2FuIGJlIGFkZHJlc3NlZCB3aXRoaW4gdGhl IGxhc3QgY2FsbCBwZXJpb2QuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIEFwciA2LCAyMDE2IGF0IDc6NDAgQU0sIERlYXJs b3ZlLCBDaHJpc3RvcGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVA YmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5PYnZpb3VzbHkgJiM0MzsxIHRvIHRoZSByZXF1ZXN0IGZvciBXR0xDLjxicj4NCjxicj4NCldp dGggcmVnYXJkIHRvIHdoYXQncyBjaGFuZ2VkLCB0ZWNobmljYWxseSB0aGUgb25seSBzaWduaWZp Y2FudCB0aGluZyBpcyB0byBtYWtlIGl0IGNsZWFyIHRoYXQgaWYgYSBwcm90b2NvbCBkZWxpdmVy cyBhIG1lc3NhZ2UgdG8gdGhlIG11bHRpcGxleGVyLCB0aGUgbXVsdGlwbGV4ZXIgbXVzdCBwYXNz IGl0IG9uIHVuY2hhbmdlZCB0byB0aGUgcHJvdG9jb2wgKGFub3RoZXIgaW5zdGFuY2Ugb2YsIGF0 IGFub3RoZXIgcm91dGVyKSB1bmNoYW5nZWQuDQogV2l0aG91dCB0aGF0IG5vdGhpbmcgdGhhdCB0 aGUgcHJvdG9jb2wgaXRzZWxmIGNob29zZXMgdG8gZG8gd2l0aCByZWdhcmQgdG8gc2VjdXJpdHkg bWFrZXMgc2Vuc2UuIFRob3VnaCB0aGUgcHJvdG9jb2wgY2FuIGFsdGVybmF0aXZlbHkgbGV0IHRo ZSBtdWx0aXBsZXhlciBkbyB0aGUgc2VjdXJpdHksIDcxODIgY2FuIGJlIGltcGxlbWVudGVkIGlu IGVpdGhlciB3YXkuIFRoaXMgaXNuJ3QgcmVhbGx5IG5ldywgYnV0IGl0IHdhc24ndCBmb3JtYWxs eQ0KIHNwZWxsZWQgb3V0LiBJdCdzIHByZXNlbnRlZCBhcyBwYXJ0IG9mIHNwZWxsaW5nIG91dCBt dWx0aXBsZXhlciBydWxlcyBtb3JlIGNhcmVmdWxseS48YnI+DQo8YnI+DQpCdXQgd2hhdCBhYm91 dCBtZXNzYWdlIG9wdGltaXNhdGlvbj8gVGhhdCdzIGEgZnVuY3Rpb24gb2YgY29uc3RydWN0aW5n IGEgNTQ0NCBtZXNzYWdlLCBub3QgdGhlIG11bHRpcGxleGVyLCBhbmQgaXMgZG93biB0byB0aGF0 IDU0NDQgaW5jbHVkZXMgdHdvIHRoaW5ncyAtIHBhY2tldC9tZXNzYWdlIHN0cnVjdHVyZSAoYW5k IGltcGxpY2l0bHksIGFuZCBpbiBwcmV0dHkgbXVjaCBhbnkgaW1wbGVtZW50YXRpb24gSSB3b3Vs ZCBleHBlY3QgdG8gc2VlLA0KIGEgcGFyc2VyIGFuZCBidWlsZGVyIGZvciB0aGF0IHN0cnVjdHVy ZSkgYW5kIHRoZSBtdWx0aXBsZXhlci4gU28gd2UgdG9vayB0aGUgb3Bwb3J0dW5pdHkgdG8gc2Vw YXJhdGUgb3V0IG1vcmUgY2xlYXJseSBhIGRpc2N1c3Npb24gb2YgdGhlIHR3bywgd2hpY2ggd2Ug dGhpbmsgd2lsbCBiZSBoZWxwZnVsLjxicj4NCjxicj4NCi0tPGJyPg0KQ2hyaXN0b3BoZXIgRGVh cmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBw bGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQo8YnI+DQpUOiAmbmJzcDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5 NCIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8L2E+ICZuYnNwO3wgJm5i c3A7RToNCjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjxicj4N CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kg UGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhy ZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj53d3cuYmFl c3lzdGVtcy5jb20vYWk8L2E+PGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2Ug TGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0 NTE8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9y ZCwgU3VycmV5LCBHVTIgN1lQPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQpGcm9tOiBtYW5ldCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYW5ldC1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXQtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJl aGFsZiBPZiBVbHJpY2ggSGVyYmVyZzxicj4NClNlbnQ6IDA1IEFwcmlsIDIwMTYgMjA6MDg8YnI+ DQpUbzogPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFu ZXRAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogW21hbmV0XSBXR0xDIHJlcXVlc3QgZm9yIGRy YWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMzxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBv cmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBl eHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVybmV0Ljxicj4NCkNvbnNpZGVyIGNhcmVm dWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRh Y2htZW50cyBvciByZXBseS48YnI+DQpGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFp bHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNw aWNpb3VzIGVtYWlsIG1lc3NhZ2VzLjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KKioqIFdBUk5JTkcgKioqPGJy Pg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRl IG91ciBvcmdhbml6YXRpb24uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KPGJyPg0KSGksPGJyPg0KPGJyPg0KQXMgeW91IGhhdmUgc2Vlbiwgd2Ug aGF2ZSBzdWJtaXR0ZWQgYSBuZXcgcmV2aXNpb24gb2YgNTQ0NC11c2FnZS4gVGhlIGF1dGhvcnMg ZmVlbCBjb21mb3J0YWJsZSB0aGF0IHdlIGhhdmUgYWRkcmVzc2VkIGFsbCBpc3N1ZXMgYnkgdGhp cyB2ZXJzaW9uLCBhbmQgd291bGQgbGlrZSB0byBhc2sgdGhlIFdHIGNoYWlycyB0byBpc3N1ZSBh IFdHTEMgb24gdGhpcyBkb2N1bWVudC4gV2hpbGUgaXQgaXMgYSBmYWlybHkgc2hvcnQgZG9jdW1l bnQsIGdpdmVuDQogdGhhdCBpdCBpcyBJRVRGIHdlZWsgZm9yIHNvbWUsIHdlJ2Qgc3VnZ2VzdCB0 aGF0IGEgMy00IHdlZWsgV0dMQyB3b3VsZCBiZSBhcHByb3ByaWF0ZS48YnI+DQo8YnI+DQpCZXN0 IHJlZ2FyZHM8YnI+DQpVbHJpY2g8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0QGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21hbmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKio8YnI+DQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNpcGllbnQgYW5kIG1h eSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4NCnJl Y2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUg c2VuZGVyLjxicj4NCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVy cG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+DQpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFu ZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Om1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ADA83GLKXM0002VGREEN_-- From nobody Mon Apr 18 06:17: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 8F27312D8F8 for ; Mon, 18 Apr 2016 06:17:47 -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 HhJUT8KwCUdd for ; Mon, 18 Apr 2016 06:17:42 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 C80FA12B04F for ; Mon, 18 Apr 2016 06:17:41 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id 2so194219129ioy.1 for ; Mon, 18 Apr 2016 06:17:41 -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=+OSs0ZzaTfJm3j4hzm2kYbfOSzKmP3jWCRIfCgsk+w0=; b=quIyrmO8eBvydlNw2fx5acd6lrYILcC61ce3/6Yc55uD4m7CNDJ9Ksx44u9PZQPiJ9 AUaC7z2+/uQdk5nrdxJX1M+3LNUMS6OlcTuS+vhNHTYitgqRJXOHjsKZ6Ic83nyTIKI1 cwvQ7252wAIE4iKUcA8uHW0/dNhytUTUPCzvmgZqUxUzMjI7cG7AH4AmPtNRtVF0Qb9P 2weZOpzMDf/oFKSq1Iu2cX2aGGFxRSWK8fO6s7bgCtcuZvhHJM57GgGXz42XlKOHsvTn TkqwDTjhNALxwSPziFoQGrTEGzlLNRGnMh5OefMma+oyxbo0if/AnvHrFJPwqnDQxP6t kSTQ== 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=+OSs0ZzaTfJm3j4hzm2kYbfOSzKmP3jWCRIfCgsk+w0=; b=IDtfSanR/TVW18exJmkBkaWXRgJ1M/xdOq4gDlMXfWm1E+CuKYKOFUnhVZwsl8ThY/ PitqR6InJDdyvfHvimulOI9f7GlQot/r43UGlozH5HLo/UROidaZGD/PVOzq1x44ASrM e8M5WlV6JqIB00a+FFaBlcHfPgKVRp7UmwYqagNy7RLMqTtQk/jcVo5hMOlbHD85CXnp hk1jb6Pu4KxuumYBV/B5HCfEbcvbaDygI+/JXlJT6Swkuj8aR9/voDBT0D9/LkAnnr6J U0xEjllAoYQxflg8jvFC3VOfyz5qC1Xzs/LQ47ePl5ZCVM3MEqkrSoROK7dwDh7GcoR4 fGFw== X-Gm-Message-State: AOPr4FW9EaN/Rie8i2ignuyj9kOwFy8g7pRemGpD5MZGzuJ/xZcpHiUD8cFLzwrM0zTwLYMy5Lp/JMyB7FAsUg== MIME-Version: 1.0 X-Received: by 10.107.129.32 with SMTP id c32mr37882184iod.102.1460985460965; Mon, 18 Apr 2016 06:17:40 -0700 (PDT) Received: by 10.79.72.68 with HTTP; Mon, 18 Apr 2016 06:17:40 -0700 (PDT) In-Reply-To: References: <45DFA343-1FDD-4EB9-9291-AB3A830A3CD9@mnemosyne.demon.co.uk> Date: Mon, 18 Apr 2016 09:17:40 -0400 Message-ID: From: Stan Ratliff To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a113ec9286c4b450530c22f33 Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" , Christopher Dearlove Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 18 Apr 2016 13:17:47 -0000 --001a113ec9286c4b450530c22f33 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 18, 2016 at 9:13 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > As has been pointed out to me, some implementations don=E2=80=99t do this= . If you > are building an implementation in a constrained environment, you can buil= d > a constrained implementation. And some people have. > > > > So no, it=E2=80=99s not appropriate to specify an independent parser, or = require > one. Rather you need to design so that when people do, it can be efficien= t. > Which is what we have been doing. > > > > Or in other words, I don=E2=80=99t think this sort of change is appropria= te. Quite > the contrary. > Well, we disagree. This has been a fundamental point of contention for some of the follow-on protocols attempting to use 5444. and IMO, this has to be addressed. > > > The key point is that what=E2=80=99s mandated is a multiplexer and a form= at. But > not an independent parser. > How can you mandate a multiplexer, but not an independent parser? This makes no sense. Stan > > > *-- * > > > > > *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:* Stan Ratliff [mailto:ratliffstan@gmail.com] > *Sent:* 18 April 2016 14:09 > *To:* Dearlove, Christopher (UK) > *Cc:* Christopher Dearlove; manet@ietf.org; Christopher Dearlove > *Subject:* Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > > > > > **** 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 Mon, Apr 18, 2016 at 4:52 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > I don=E2=80=99t believe we can or should suggest an implementation. That= =E2=80=99s not > what the IETF does, and it would be a hard, probably impossible, sell, to > the IESG. That the obvious implementation employs an independent parser i= s > already said - it may be appropriate to strengthen the words, but this > second I=E2=80=99m not sure if that=E2=80=99s needed (not got time to che= ck current > wording). > > > > (Again, with my Working Group Participant hat on) - > > > > I don't mean to suggest an implementation. At least to me, this is an > architecture (that of an independent parser, with a reliable communicatio= ns > mechanism to said parser, that deals with logical messages instead of > packets. Is sequencing guaranteed? I'm not sure, to be honest. But once t= he > independent parser is assumed, engineers also MUST assume that the > transport (and it's the transport for control plane traffic, but not for > data plane traffic), is "owned" by the independent parser. > > > > Which leads me to the other point I'm trying to make (perhaps badly): > Abstracting the transport away from the control plane *can* effect > protocol design. > > > > I believe both of these points should be addressed in the usage document. > > > > Regards, > > Stan > > > > > > > > *-- * > > > > > *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 *Stan Ratliff > *Sent:* 16 April 2016 19:09 > *To:* Christopher Dearlove > *Cc:* manet@ietf.org; Christopher Dearlove > *Subject:* Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > > > > > **** 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 Fri, Apr 15, 2016 at 3:27 PM, Christopher Dearlove < > chris@mnemosyne.demon.co.uk> wrote: > > I don't understand what you mean by the concept of "fields the protocol > can and can't touch". > > > > CAVEAT: I am speaking here as a Working Group participant. With that > understood: > > > > > TTL is a great example, since that discussion blew the mailing list up a > few months ago. I'm *not* saying manipulating TTL is a good thing for a > protocol to try - in truth, I think it's pretty "hacky". But the notion w= as > floated, and in the context of that discussion, it may will have worked. > The opposition on-list was fast, and pretty forceful. > > I've said before - 5444, especially with the multiplexer, changes the > relationship between a routing protocol and an interface. I think the > document should have some type of "overview" section which discusses thes= e > differences, in order to frame the issue for someone coming along who > hasn't been a part of the 5444 mail discussion. > > I'm talking about the type of overview that goes something like this: > > "Use of RFC 5444 with the multiplexer feature imposes design requirements > on the protocol. The actual transport mechanism is abstracted from the > protocol. For example, routing protocols are not aware of precisely when = a > message is sent. A good example of operation in this model is [BGP], > utilizing the [TCP] transport. This is opposed to a protocol such as > [OSPF], which is capable of sending traffic with its own IP type. Since t= he > transport is abstracted, protocols are not presented with "packets", and > are not capable of manipulating data items in packet headers (e.g. data > items at the IP and/or MAC layers)." > > As Lou Berger put it to me in the context of DLEP - "You want an engineer > to be able to pick up this document, with no prior exposure to the topic, > and code an interoperable implementation." I think this type of an > overview, setting basic ground rules, would help. > > I've also contended for a while now that 5444, with the mux, effectively > forces an architecture on implementers - in the Linux world, that > architecture is a 5444 parser as an independent process, with IPC > mechanisms to the routing protocol(s) it is servicing. The 5444 parser > itself "owns" the transport (the socket). The usage document *strongly > infers* that. I believe we should concretely state it, so we don't have t= o > answer the question over and over again. > > Regards, > > Stan > > > > > > > When a protocol creates a message from scratch it's not constrained in an= y > way I'd describe in such terms. So I assume you mean when it receives a > message and then sends a similar message. > > > > There are two cases there. Unchanged (with the special exceptions for hop > count and limit) and not unchanged. The former is better, and there's > really nothing more to say. > > > > So let's consider the latter. Really it's not the same message, it's a > brand new message. That's a useful way to look at it from a security > perspective, because it tells you that end to end authentication isn't > going to work. And what are the restrictions on brand new messages? The > same as on any new message. > > > > OK, you might say, true but does that mean I can add this, remove that, > change the hop data? Yes. But is that a good idea? No. But maybe you are > forced into it. But that it's inherently not good suggests the corollary > that if you must, do the minimum and make it trackable. But that's not a > 5444 requirement, just good practice. It does break 7182 message ICVs, so > don't use them. > > > > We could, hypothetically, have someone create an extension or alternative > to 7182 that defined aggregated signatures. Then we'd have rules on what > you could change. But that would belong there. If you think those would b= e > good, then again you would want make minimal changes, and mainly only of > certain types. What types? There I can't help you as I don't have a > candidate. > > > > The summary? Don't change if you don't have to. That's recommended. If yo= u > must change you're on your own (with the same restrictions as new > messages). Advice like "as little as possible" is good, but that's not > actually 5444 advice. And don't use 7182 message ICVs. > > -- > > Christopher Dearlove > > christopher.dearlove@gmail.com (iPhone) > > chris@mnemosyne.demon.co.uk (home) > > > On 15 Apr 2016, at 19:37, Stan Ratliff wrote: > > My main concern addressed inline... > > > > > > On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlove < > christopher.dearlove@gmail.com> wrote: > > A few immediate comments inline below. > > -- > > Christopher Dearlove > > christopher.dearlove@gmail.com (iPhone) > > chris@mnemosyne.demon.co.uk (home) > > > On 15 Apr 2016, at 15:18, Lotte Steenbrink > wrote: > > Hi all, > > > > sparked by the recently started WGLC, I=E2=80=99ve reviewed the current r= evision > of the draft. I=E2=80=99d like to offer the working group my perspective = as someone > who doesn=E2=80=99t have decades of protocol and/or packet format design = under > their belt (i.e. some things might not be obvious to me that are obvious = to > others), but also as someone who has worked with RFC 5444 when implementi= ng > a routing protocol (AODVv2), updating the packet format of a routing > protocol (AODVv2 again) and (partially) implementing my own RFC5444 > builder/parser. > > > > Overall, I think the document is easy to read and follow. To me, it > contains valuable information and guidance and in some cases prevents > people from shooting themselves in the foot. > > I=E2=80=99m really happy this document exists and I=E2=80=99d like it to = move forward > soon, but I do feel that it is still lacking in some areas, which is why = I > was a bit surprised to see it go to Last Call all of a sudden. > > > > Not really. The authors had said what they intended to say, no one was > commenting, time for WGLC. > > > > First, some nitpicks and comments: > > > > * from *1.2.1* > *. > Packet/Message Format*: > > > > [=E2=80=A6] a packet > > transmission following a successful packet reception is by design > > of a new packet that may include all, some, or none of the > > received messages [...] > > > > I=E2=80=99m not a native speaker, but that =E2=80=9Eof=E2=80=9C seems out= of place... > > > > I am a native speaker, and no, it's not. Some would repeat it after each > of all, some and none, and I might sometimes. But it really doesn't matte= r > which of the two styles we pick, the RFC Editor may well change to the > other. > > > > * Regarding *4.2* > *. > Packets and Messages:* > > this section talks a lot about how the multiplexer operates, so I think > it=E2=80=99d be helpful if its title reflected that. > > > > I'm of two opinions on that. On the one hand it is, as its title suggests= , > about the packet and message level, as opposed to lower levels, and its > title contrasts with that if 4.3 for that reason. On the other hand you a= re > right, it does have much about the multiplexer. A title covering all thre= e > woukd start getting cumbersome. Will take this one away to think about. > > > > * from *4.4* > *. > Addresses Require Attributes:* > > > > An unmodified extension to NHDP would ignore such addresses, > > as required, as it does not support that specialized purpose. > > > > At first glance, (to me) this reads as =E2=80=9EAll addresses that are as= sociated > with an unknown TLV are ignored=E2=80=9C, which is obviously nonsense (bu= t quite > panic-inducing :D). I=E2=80=99d propose to reword it to something along t= he lines > of > > An unmodified extension to NHDP would not consider this > > address to be of a neighbor, as it is lacking a LINK_STATUS > > or OTHER_NEIGHB TLV. > > > > I take your point, but I think that if the address ends up with no > relevant associated TLVs then it is ignored is also a point. I dare say w= e > can wordsmith something. > > > > Also, I don=E2=80=99t quite get where you=E2=80=99re going with the last = paragraph of that > section (=E2=80=9CThese restrictions do not, however, mean that added inf= ormation > is > > completely ignored for purposes of the base protocol.=E2=80=9D)... > > > > Read on, the rest of the paragraph describes the case where not. But we > might telegraph that better in the opening sentence. > > > > * regarding the maps in *4.5* > *. > Information Representation:* > > I=E2=80=99m afraid I just don=E2=80=99t really understand the purpose of = this section and > the mapping notation. I=E2=80=99m assuming that the maps are supposed to = offer a > way of describing how a TLV relates to a message or an address? > > If so, why does it only mention extension types, but not the basis types? > > > > It says extended types, meaning the combination of the two. But full type > would be better, as almost defined in 5444. In fact I think we should add= a > comment to the notation section. (5444 uses a symbolic name rather than t= he > phrase.) > > > > Or is it supposed to be used something like this: > > > > *BASE_TLV* > > > > Message: > > (base_tlv_extension_type_1) -> (2 octets, "value a when condition x is > met") > > (base_tlv_extension_type_2) -> (2 octets, "value b when condition y is > met") > > > > ? Also, I don=E2=80=99t quite get how this would be used in future protoc= ol > specifications? Or aid in implementing RFC5444 parsers? > > An example or a clarification would be very helpful. > > > > It's a way of looking at things. But not the only one, it goes on to > discuss variants. I think it mostly comes under heading of if useful use > it, if not skip it. We'll take another look, but I don't think this will > ever be elementary. > > > > * regarding *4.6* > *. > TLVs:* > > In general, it=E2=80=99s not clear everywhere in the section whether you= =E2=80=99re > talking to RFC5444 parser/builder implementors or protocol designers. > > > > A protocol SHOULD use an efficient > > representation, but this is a quality of implementation issue. > > > > I=E2=80=99m not sure where you=E2=80=99re going with the last part of tha= t sentence? I=E2=80=99d > reword it to something like =E2=80=9EA protocol SHOULD use an efficient > representation, avoiding unnecessarily verbose use of TLVs and extension > types. However, the final arrangement in a message- or addressTLV block i= s > a quality of implementation issue=E2=80=9C (in case that=E2=80=99s what = you meant). > > > > No, you're considering the protocol design. This is considering the > protocol object that implements the protocol. There isn't a one to one > mapping from information to representation, it's up to the implementation > to do it efficiently. Different implementations of the same protocol > specification may do better or worse here. (Trivial case, an implementati= on > could choose to never compress addresses. Bad idea, but legal.) > > > > And then: > > > > A > > protocol MUST recognize any permitted representation of the > > information; even if it chooses to (for example) only use multivalue > > TLVs, it MUST recognize single value TLVs (and vice versa). > > > > =E2=80=A6 I thought protocols weren=E2=80=99t supposed to specify whether= a TLV is > arranged (for example) as a multivalue TLV?! > > > > Implementation again, not design. > > > > And so, since a protocol shouldn't be concerned with multivalue TLVs and > the like, wouldn=E2=80=99t it be the *RFC5444 implementation* that MUST r= ecognize > any permitted representation? > > > > You're assuming that there is an RFC 5444 implementation. That's the same > way to work if you plan to implement more than one protocol. But nothing > says you have to do it that way. The architecture defined by 5498 admits = of > the multiplexer and protocols, and thus these are rules on the protocol. = If > protocols delegate all their common work to something (parser/creator) th= en > it inherits those restrictions, but that's not defined, and we can't assu= me > it. > > > > Or is this paragraph really just a complicated way of saying =E2=80=9Eas = a > protocol designer, make sure to not specify/rely on things like (for > example) multivalue TLVs, since your messages have to work with *any* > representation=E2=80=9C? If so, I think that should be done in a less com= plicated > fashion (see below). > > > > * regarding *5* > = *. > Structure:* > > Since this section talks a lot about flags, it=E2=80=99d be nice if its t= itle > represented that. Maybe consider renaming it to =E2=80=9EStructure and Fl= ags=E2=80=9C or so? > > > > I mostly don't agree. Structure is the subject, flags are a detail. > > > > * from *6.1* > *. > Address Block Compression:* > > > > Compression of addresses in an Address Block considers addresses to > > consist of a Head, a Mid, and a Tail, where all addresses in an > > Address Block have the same Head and Tail, but different Mids. > > > > > > I=E2=80=99d find this sentence easier to read if it started with =E2=80= =9CCompression of > addresses in an Address Block is possible when addresses consist of a Hea= d, > a Mid [=E2=80=A6]=E2=80=9D. > > > > No. That's missing the point and misleading. Addresses are always > considered to have the head/mid/tail format. Compression is possible if > either the head or tail (or both) is non-empty. > > > > * from *6.1* > *. > Address Block Compression:* > > > > Putting addresses into a message efficiently also has to include: > > > > Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that would be a =E2=80=9E= may=E2=80=9C. Multiple Adress Blocks > and/or reordering don=E2=80=99t increase efficiency in all possible cases= ... > > > > I think that's the wrong change. Rather "include" should be "consider". > > > > * from *6.2* > *. > TLVs:* > > [...] This is even possible if the MPR TLV specified in > > OLSRv2 [RFC7181 ] is added; bu= t it is not possible, in general, if > > the LINK_METRIC TLV is also added. > > > > Why is it not possible for the latter? If that could be explained/hinted > at in a half sentence, I think it=E2=80=99d be helpful information to hav= e in the > draft. > > > > That's very hard, and not just because it's a negative. It's really an > observation that motivates the duscussion. A half sentence would I think > confuse more than it enlightens (it's because you have too many constrain= ts > to satisfy at once - I doubt that helped). > > > > In a typical case where a > > LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with > > enough addresses, sorted appropriately, two single value TLVs can > > be more efficient than one multivalue TLV. > > > > Same thing: why? > > > > Here I think this should be obvious to anyone who has looked at 5444. > > > > * regarding the second paragraph from *6.3* > *. > TLV Values*, i.e. > > > > This approach was specified in [RFC7188 ], and required for protocols > > that extend [RFC6130 ] and [RFC71= 81 ]. It is here RECOMMENDED that > > this approach is followed when defining any Address Block TLV that > > may be used by a protocol using [RFC5444 ]. > > > > The term =E2=80=9Ethis approach=E2=80=9C confused me, since I initially = thought it meant > =E2=80=9Ethe approach is to use UNSPECIFIED in a way that makes sense=E2= =80=9C rather than > =E2=80=9Ethe approach is to use UNSPECIFIED=E2=80=9C. Maybe that could be= reworded to > something along the lines of > > The UNSPECIFIED TLV and its usage was specified in [RFC7188]=E2=80=A6 > > ? > > > > No. There is no UNSPECIFIED TLV. There is a recommendation to include an > UNSPECIFIED value in a TLV. But really, we've described this once in 7188= , > it's there to read. > > > > * regarding *6.3* > *. > TLV Values:* > > The second paragraph is a bit confusing and seems to explaing roghly the > same things as the fourth paragraphs. I=E2=80=99d propose to merge the se= cond into > the fourth. > > > > I'm not sure I exactly agree, but the ordering in that section could be > improved. > > > > * from *6.4* > *. > Automation:* > > > > The possible gain depends on the efficiency > > of the original message creation, > > > > the term =E2=80=9Ethe original message creation=E2=80=9C seems a bit ambi= guous=E2=80=93 does this > refer to the message as created by an RFC5444 message builder > implementation? > > > > Yes. > > > > Additionally, I'm concerned about two things that *aren=E2=80=99t* in the= draft: > > > > * Some of the AODVv2 co-authors and me have asked for a list of =E2=80= =9Eas a > protocol, you can set all of these fields of a message, but please leave > the rest alone=E2=80=9C, which would=E2=80=99ve saved us many hours of di= scussions (and > Henning a lot of time spent explaining these things=E2=80=A6). These requ= ests have > been met with a refusal to specify a concrete API, as such an effort is > dependent on outside factors such as programming language or software > architecture. I agree with this notion, but a programming-language > dependent API is not what we=E2=80=99ve asked for. I=E2=80=99ve tried to = supply a sketch of > what I did ask for in [1], but unfortunately I didn=E2=80=99t get an answ= er (and as > far as I can see it, the draft wasn=E2=80=99t changed either). I still th= ink that > such a list, in whatever form, would be very helpful for future > Internet-Draft authors and I also think this request is in accordance wit= h > the intentions stated in 1.1 History and Purpose, and I think it should > be included in the document. > > > > No. There are many reasons why we're just not touching this one. > > > > One is that language independence is a mirage. How you go about things is > completely different in, for example an object oriented language than one > that isn't. Section 4.5 shows that there are quite different ways of doin= g > things even given a decision to use a map approach, and there are other > approaches than that. It would be wrong and beyond our competence to > suggest one of these as "best". There's reasons the IETF doesn't do this, > and that's one. > > > > Plus, frankly, the work it would take is beyond what we choose to spend. > > > > > > > > > > I'm confused (which is an altogether too common occurrence these days). I > get that we don't want to specify an API. But I think the discussion abou= t > fields a protocol can and can't touch in a messages is a good thing - and > it's one spot where I, too, find the document wanting. > > > > To paraphrase something I've said before, I believe that RFC 5444 changes > the relationship that a routing protocol has with an "interface". I'm not > commenting on whether or not that's a good thing, or a bad thing - just > that it does change the relationship. This change has been at the root of > some of the long-running discussions as to whether protocols under > development were RFC 5444 compliant or not. The goal of this document bei= ng > to eliminate (it's a goal, probably not reachable) those discussions, I'd > like to see that information in the document in some form. > > > > I'm interested in seeing this document progress, and eventually be > published. I think it will help future protocol designers to better use R= FC > 5444. But I would like to see *something* along the lines of what Lotte i= s > requesting, as I think it will improve the doc. > > > > Regards, > > Stan > > > > > > > > * As the exact rules for using/setting the hop count & hop-limit fields > are currently being discussed w/ regard to AODVv2 in another thread [2]= =E2=80=93 > should a definitive answer to that question be part of 5444-usage? > > > > You don't want that. Because if we did specify that you'd find yourself > more constrained than you want to be. There is a design intent described = in > 5444, but it assumes immutable messages. Which you don't want. Really, > we're doing you a favour by not imposing on you. > > > > Best regards, > > Lotte > > > > [1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.html > > [2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.html > > > > > > Am 06.04.2016 um 19:14 schrieb Justin Dean : > > > > The chairs agree that a 3 week WGLC is appropriate. Everyone please read > the draft early and get comments in early so that they can be addressed > within the last call period. > > > > Justin > > > > On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > Obviously +1 to the request for WGLC. > > With regard to what's changed, technically the only significant thing is > to make it clear that if a protocol delivers a message to the multiplexer= , > the multiplexer must pass it on unchanged to the protocol (another instan= ce > of, at another router) unchanged. Without that nothing that the protocol > itself chooses to do with regard to security makes sense. Though the > protocol can alternatively let the multiplexer do the security, 7182 can = be > implemented in either way. This isn't really new, but it wasn't formally > spelled out. It's presented as part of spelling out multiplexer rules mor= e > carefully. > > But what about message optimisation? That's a function of constructing a > 5444 message, not the multiplexer, and is down to that 5444 includes two > things - packet/message structure (and implicitly, and in pretty much any > implementation I would expect to see, a parser and builder for that > structure) and the multiplexer. So we took the opportunity to separate ou= t > more clearly a discussion of the two, which we think will be helpful. > > -- > 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 > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg > Sent: 05 April 2016 20:08 > To: manet@ietf.org > Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > ----------------------! WARNING ! ---------------------- This message > originates from outside our organisation, either from an external partner > or from the internet. > Consider carefully whether you should click on any links, open any > attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions > on reporting suspicious email messages. > -------------------------------------------------------- > > *** WARNING *** > EXTERNAL EMAIL -- This message originates from outside our organization. > > > > Hi, > > As you have seen, we have submitted a new revision of 5444-usage. The > authors feel comfortable that we have addressed all issues by this versio= n, > and would like to ask the WG chairs to issue a WGLC on this document. Whi= le > it is a fairly short document, given that it is IETF week for some, we'd > suggest that a 3-4 week WGLC would be appropriate. > > Best regards > Ulrich > > _______________________________________________ > 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 > > > > _______________________________________________ > 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 > > > > > > > --001a113ec9286c4b450530c22f33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 18, 2016 at 9:13 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

As has been pointed out t= o me, some implementations don=E2=80=99t do this. If you are building an im= plementation in a constrained environment, you can build a constrained implementation. And some people have.

=C2=A0

So no, it=E2=80=99s not a= ppropriate to specify an independent parser, or require one. Rather you nee= d to design so that when people do, it can be efficient. Which is what we have been doing.

=C2=A0

Or in other words, I don= =E2=80=99t think this sort of change is appropriate. Quite the contrary.


Well, we disagree. Thi= s has been a fundamental point of contention for some of the follow-on prot= ocols attempting to use 5444. and IMO, this has to be addressed.=C2=A0
=C2=A0

=C2=A0

The key point is that wha= t=E2=80=99s mandated is a multiplexer and a format. But not an independent = parser.


How can you = mandate a multiplexer, but not an independent parser? This makes no sense.= =C2=A0

Stan=C2=A0

=C2=A0<= /div>

<= u>

=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: Stan Ratliff [mailto:ratliffstan@gmail.com]
Sent: 18 April 2016 14:09
To: Dearlove, Christopher (UK)
Cc: Christopher Dearlove; manet@ietf.org; Christopher Dearlove
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage= -03

=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 Mon, Apr 18, 2016 at 4:52 AM, Dearlove, Christoph= er (UK) <chris.dearlove@baesystems.com> wrote:

I don=E2=80=99t believe w= e can or should suggest an implementation. That=E2=80=99s not what the IETF= does, and it would be a hard, probably impossible, sell, to the IESG. That the obvious = implementation employs an independent parser is already said - it may be ap= propriate to strengthen the words, but this second I=E2=80=99m not sure if = that=E2=80=99s needed (not got time to check current wording).

=C2=A0

(Again, with my Working Group Participant hat on) -= =C2=A0

=C2=A0

I don't mean to suggest an implementation. At le= ast to me, this is an architecture (that of an independent parser, with a r= eliable communications mechanism to said parser, that deals with logical me= ssages instead of packets. Is sequencing guaranteed? I'm not sure, to be honest. But once the independent parse= r is assumed, engineers also MUST assume that the transport (and it's t= he transport for control plane traffic, but not for data plane traffic), is= "owned" by the independent parser.=C2=A0

=C2=A0

Which leads me to the other point I'm trying to = make (perhaps badly): =C2=A0Abstracting the transport away from the control= plane *can* effect protocol design.=C2=A0

=C2=A0

I believe both of these points should be addressed i= n the usage document.=C2=A0

=C2=A0

Regards,

Stan

=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 Stan Ratliff
Sent: 16 April 2016 19:09
To: Christopher Dearlove
Cc: manet@ietf.o= rg; Christopher Dearlove
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage= -03

=C2=A0

=C2=A0

*** WARNING ***

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.

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

=C2=A0

=C2=A0

=C2=A0

On Fri, Apr 15, 2016 at 3:27 PM, Christopher Dearlov= e <chri= s@mnemosyne.demon.co.uk> wrote:

I don't understand what you mean by the concept = of "fields the protocol can and can't touch".

=C2=A0<= /p>

CAVEAT: I am speaking here as a Working Group partic= ipant. With that understood:
=C2=A0

=C2=A0

TTL is a great exampl= e, since that discussion blew the mailing list up a few months ago. I'm= *not* saying manipulating TTL is a good thing for a protocol to try - in t= ruth, I think it's pretty "hacky". But the notion was floated, and in the context o= f that discussion, it may will have worked. The opposition on-list was fast= , and pretty forceful.

I've said before = - 5444, especially with the multiplexer, changes the relationship between a= routing protocol and an interface. I think the document should have some t= ype of "overview" section which discusses these differences, in order to frame the issue for= someone coming along who hasn't been a part of the 5444 mail discussio= n.

I'm talking about= the type of overview that goes something like this:

"Use of RFC 5444= with the multiplexer feature imposes design requirements on the protocol. = The actual transport mechanism is abstracted from the protocol. For example= , routing protocols are not aware of precisely when a message is sent. A good example of opera= tion in this model is [BGP], utilizing the [TCP] transport. This is opposed= to a protocol such as [OSPF], which is capable of sending traffic with its= own IP type. Since the transport is abstracted, protocols are not presented with "packets", and a= re not capable of manipulating data items in packet headers (e.g. data item= s at the IP and/or MAC layers)."

As Lou Berger put it to me in the context of DLEP - "You want an engin= eer to be able to pick up this document, with no prior exposure to the topi= c, and code an interoperable implementation."=C2=A0 I think this type = of an overview, setting basic ground rules, would help.

I've also contend= ed for a while now that 5444, with the mux, effectively forces an architect= ure on implementers - in the Linux world, that architecture is a 5444 parse= r as an independent process, with IPC mechanisms to the routing protocol(s) it is servicing. T= he 5444 parser itself "owns" the transport (the socket). The usag= e document *strongly infers* that. I believe we should concretely state it,= so we don't have to answer the question over and over again.

Regards,

Stan


=C2=A0

=C2=A0

When a protocol creates a message from scratch it= 9;s not constrained in any way I'd describe in such terms. So I assume = you mean when it receives a message and then sends a similar message.

=C2=A0

There are two cases there. Unchanged (with the speci= al exceptions for hop count and limit) and not unchanged. The former is bet= ter, and there's really nothing more to say.

=C2=A0

So let's consider the latter. Really it's no= t the same message, it's a brand new message. That's a useful way t= o look at it from a security perspective, because it tells you that end to end authentication isn't going to work. And what are the restri= ctions on brand new messages? The same as on any new message.=

=C2=A0

OK, you might say, true but does that mean I can add= this, remove that, change the hop data? Yes. But is that a good idea? No. = But maybe you are forced into it. But that it's inherently not good suggests the corollary that if you must, do the minimum and make = it trackable. But that's not a 5444 requirement, just good practice. It= does break 7182 message ICVs, so don't use them.

=C2=A0

We could, hypothetically, have someone create an ext= ension or alternative to 7182 that defined aggregated signatures. Then we&#= 39;d have rules on what you could change. But that would belong there. If you think those would be good, then again you would want = make minimal changes, and mainly only of certain types. What types? There I= can't help you as I don't have a candidate.

=C2=A0

The summary? Don't change if you don't have = to. That's recommended. If you must change you're on your own (with= the same restrictions as new messages). Advice like "as little as possible" is good, but that's not actually 5444 advice. And don&#= 39;t use 7182 message ICVs.

-- =C2=A0

Christopher Dearlove


On 15 Apr 2016, at 19:37, Stan Ratliff <ratliffstan@gmail.com> wrote:

My main concern addressed inline...

=C2=A0

=C2=A0

On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlov= e <c= hristopher.dearlove@gmail.com> wrote:

A few immediate comments inline below.

-- =C2=A0

Christopher Dearlove


On 15 Apr 2016, at 15:18, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de>= ; wrote:

Hi all,

=C2=A0

sparked by the recently started WGLC, I=E2=80=99ve r= eviewed the current revision of the draft. I=E2=80=99d like to offer the wo= rking group my perspective as someone who doesn=E2=80=99t have decades of protocol and/or packet format design under their belt (i.e. some things mi= ght not be obvious to me that are obvious to others), but also as someone w= ho has worked with RFC 5444 when implementing a routing protocol (AODVv2), = updating the packet format of a routing protocol (AODVv2 again) and (partially) implementing my own RFC544= 4 builder/parser.

=C2=A0

Overall, I think the document is easy to read and fo= llow. To me, it contains valuable information and guidance and in some case= s prevents people from shooting themselves in the foot.

I=E2=80=99m really happy this document exists and I= =E2=80=99d like it to move forward soon, but I do feel that it is still lac= king in some areas, which is why I was a bit surprised to see it go to Last Call all of a sudden.

=C2=A0

Not really. The authors had said what they intended = to say, no one was commenting, time for WGLC.

=C2=A0<= /p>

First, some nitpicks and comments:

=C2=A0

* from=C2=A01.2.1. Packet/Message Format:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0[=E2=80=A6] a packet

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 transmission following a successful pac=
ket reception is by design


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of a new packet that may include all, s=
ome, or none of the


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 received messages [...]

=C2=A0

I=E2=80=99m not a native speaker, but that =E2=80=9E= of=E2=80=9C seems out of place...

=C2=A0

I am a native speaker, and no, it's not. Some wo= uld repeat it after each of all, some and none, and I might sometimes. But = it really doesn't matter which of the two styles we pick, the RFC Editor may well change to the other.

=C2=A0<= /p>

* Regarding=C2=A04.2. Packets and Messages:

this section talks a lot about how the multiplexer o= perates, so I think it=E2=80=99d be helpful if its title reflected that.=C2= =A0

=C2=A0

I'm of two opinions on that. On the one hand it = is, as its title suggests, about the packet and message level, as opposed t= o lower levels, and its title contrasts with that if 4.3 for that reason. On the other hand you are right, it does have much about = the multiplexer. A title covering all three woukd start getting cumbersome.= Will take this one away to think about.

=C2=A0<= /p>

* from=C2=A04.4. Addresses Require Attributes:

=C2=A0

=C2=A0=C2=A0 An unmodified extension to NHDP would ignore such address=
es,
=C2=A0=C2=A0 as required, as it does not support that specialized purp=
ose.

=C2=A0

At first glance, (to me) this reads as =E2=80=9EAll = addresses that are associated with an unknown TLV are ignored=E2=80=9C, whi= ch is obviously nonsense (but quite panic-inducing :D). I=E2=80=99d propose to reword it to something along the lines of=C2=A0

=C2=A0=C2=A0 An unmodified extension to NHDP would not consider this
=C2=A0=C2=A0 address to be of a neighbor, as it is lacking a LINK_STAT=
US
=C2=A0=C2=A0 or OTHER_NEIGHB TLV.

=C2=A0

I take your point, but I think that if the address e= nds up with no relevant associated TLVs then it is ignored is also a point.= I dare say we can wordsmith something.

=C2=A0<= /p>

Also, I don=E2=80=99t quite get where you=E2=80=99re= going with the last paragraph of that section (=E2=80=9CThese restrictions do not, however, mean that added informat= ion is

=C2=A0=C2=A0 completely ignored for purposes of the base protocol.=E2=
=80=9D)...

=C2=A0

Read on, the rest of the paragraph describes the cas= e where not. But we might telegraph that better in the opening sentence.=

=C2=A0<= /p>

Or is it supposed to be used something like this:=

=C2=A0

BASE_TLV

=C2=A0

Message:=C2=A0

(base_tlv_extens= ion_type_1) -> (2 octets, "value a when condition x is met")

(base_tlv_extens= ion_type_2) -> (2 octets, "value b when condition y is met")

=C2=A0

? Also, I don=E2=80=99t quite get how this would be = used in future protocol specifications? Or aid in implementing RFC5444 pars= ers?

An example or a clarification would be very helpful.=

=C2=A0

It's a way of looking at things. But not the onl= y one, it goes on to discuss variants. I think it mostly comes under headin= g of if useful use it, if not skip it. We'll take another look, but I don't think this will ever be elementary.

=C2=A0<= /p>

In general, it=E2=80=99s not clear everywhere in the= section whether you=E2=80=99re talking to RFC5444 parser/builder implement= ors or protocol designers.=C2=A0

=C2=A0

=C2=A0=C2=A0 A protocol SHOULD use an efficient
=C2=A0=C2=A0 representation, but this is a quality of implementation i=
ssue.

=C2=A0

I=E2=80=99m not sure where you=E2=80=99re going with= the last part of that sentence? I=E2=80=99d reword it to something like = =E2=80=9EA protocol SHOULD use an efficient representation, avoiding unnece= ssarily verbose use of TLVs and extension types. However, the final arrangement in a messa= ge- or addressTLV block is =C2=A0a quality of implementation issue=E2=80=9C= (in case that=E2=80=99s what you meant).

=C2=A0

No, you're considering the protocol design. This= is considering the protocol object that implements the protocol. There isn= 't a one to one mapping from information to representation, it's up to the implementation to do it efficiently. Different implemen= tations of the same protocol specification may do better or worse here. (Tr= ivial case, an implementation could choose to never compress addresses. Bad= idea, but legal.)

=C2=A0<= /p>

And then:

=C2=A0

=C2=A0=C2=A0 A
=C2=A0=C2=A0 protocol MUST recognize any permitted representation of t=
he
=C2=A0=C2=A0 information; even if it chooses to (for example) only use=
 multivalue
=C2=A0=C2=A0 TLVs, it MUST recognize single value TLVs (and vice versa=
).

=C2=A0

=E2=80=A6 I thought protocols weren=E2=80=99t suppos= ed to specify whether a TLV is arranged (for example) as a multivalue TLV?!=

=C2=A0

Implementation again, not design.

=C2=A0<= /p>

And so, since a protocol shouldn't be concerned = with multivalue TLVs and the like, wouldn=E2=80=99t it be the *RFC5444 impl= ementation* that MUST recognize any permitted representation?=

=C2=A0

You're assuming that there is an RFC 5444 implem= entation. That's the same way to work if you plan to implement more tha= n one protocol. But nothing says you have to do it that way. The architecture defined by 5498 admits of the multiplexer and protocols, = and thus these are rules on the protocol. If protocols delegate all their c= ommon work to something (parser/creator) then it inherits those restriction= s, but that's not defined, and we can't assume it.

=C2=A0<= /p>

Or is this paragraph really just a complicated way o= f saying =E2=80=9Eas a protocol designer, make sure to not specify/rely on = things like (for example) multivalue TLVs, since your messages have to work with *any* representation=E2=80=9C? If so, I think that shoul= d be done in a less complicated fashion (see below).

=C2=A0

* regarding=C2=A05. Structure:

Since this section talks a lot about flags, it=E2=80= =99d be nice if its title represented that. Maybe consider renaming it to= =C2=A0=E2=80=9EStructure and Flags=E2=80=9C=C2=A0or so?

=C2=A0

I mostly don't agree. Structure is the subject, = flags are a detail.

=C2=A0<= /p>

* from=C2=A06.1. Address Block Compression:

=C2=A0

=C2=A0=C2=A0 Compression of addresses in an Address Block considers ad=
dresses to
=C2=A0=C2=A0 consist of a Head, a Mid, and a Tail, where all addresses=
 in an
=C2=A0=C2=A0 Address Block have the same Head and Tail, but different =
Mids.

=C2=A0

=C2=A0

I=E2=80=99d find this sentence easier to read if it = started with =E2=80=9CCompression of addresses in an Address Block is possi= ble when addresses consist of a Head, a Mid [=E2=80=A6]=E2=80=9D.=

=C2=A0

No. That's missing the point and misleading. Add= resses are always considered to have the head/mid/tail format. Compression = is possible if either the head or tail (or both) is non-empty.

=C2=A0<= /p>

* from=C2=A06.1. Address Block Compression:

=C2=A0
=C2=A0=C2=A0 Putting addresses into a message efficiently also has to =
include:
=C2=A0

Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that= would be a =E2=80=9Emay=E2=80=9C. Multiple Adress Blocks and/or reordering= don=E2=80=99t increase efficiency in all possible cases...

=C2=A0

I think that's the wrong change. Rather "in= clude" should be "consider".

=C2=A0<= /p>

* from=C2=A06.2. TLVs:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [...] This is even possible if the MPR =
TLV specified in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OLSRv2 [RFC7181] is added; but it is not poss=
ible, in general, if
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the LINK_METRIC TLV is also added.

=C2=A0

Why is it not possible for the latter? If that could= be explained/hinted at in a half sentence, I think it=E2=80=99d be helpful= information to have in the draft.

=C2=A0

That's very hard, and not just because it's = a negative. It's really an observation that motivates the duscussion. A= half sentence would I think confuse more than it enlightens (it's because you have too many constraints to satisfy at once - I doubt that he= lped).

=C2=A0<= /p> 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In a typical case where a=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LINK_STATUS TLV uses only the Values HE=
ARD and SYMMETRIC, with
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enough addresses, sorted appropriately,=
 two single value TLVs can
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 be more efficient than one multivalue T=
LV.

=C2=A0

Same thing: why?

=C2=A0

Here I think this should be obvious to anyone who ha= s looked at 5444.

=C2=A0<= /p>

* regarding the second paragraph from=C2=A06= .3. TLV Values, i.e.

=C2=A0 =C2=A0
=C2=A0=C2=A0 This approach was specified in [RFC718=
8], and required for protocols
=C2=A0=C2=A0 that extend [RFC6130] and [RFC7181].=C2=A0 It is her=
e RECOMMENDED that
=C2=A0=C2=A0 this approach is followed when defining any Address Block=
 TLV that
=C2=A0=C2=A0 may be used by a protocol using [RFC5444].

=C2=A0

The term =E2=80=9Ethis approach=E2=80=9C confused me= , since I initially =C2=A0thought it meant =E2=80=9Ethe approach is to use = UNSPECIFIED in a way that makes sense=E2=80=9C rather than =E2=80=9Ethe app= roach is to use UNSPECIFIED=E2=80=9C. Maybe that could be reworded to something along the lines of=C2=A0<= u>

The UNSPECIFIED = TLV and its usage was specified in [RFC7188]=E2=80=A6=C2=A0

?

=C2=A0

No. There is no UNSPECIFIED TLV. There is a recommen= dation to include an UNSPECIFIED value in a TLV. But really, we've desc= ribed this once in 7188, it's there to read.

=C2=A0<= /p>

* regarding=C2=A06.3. TLV Values:

The second paragraph is a bit confusing and seems to= explaing roghly the same things as the fourth paragraphs. I=E2=80=99d prop= ose to merge the second into the fourth.

=C2=A0

I'm not sure I exactly agree, but the ordering i= n that section could be improved.

=C2=A0<= /p>

* from=C2=A06.4. Automation:

=C2=A0

=C2=A0=C2=A0 The possible gain depends on the efficiency=

=C2=A0=C2=A0 of the original message creation,

=C2=A0

the term =E2=80=9Ethe original message creation=E2= =80=9C seems a bit ambiguous=E2=80=93 does this refer to the message as cre= ated by an RFC5444 message builder implementation?

=C2=A0

Yes.

=C2=A0<= /p>

Additionally, I'm concerned about two things tha= t *aren=E2=80=99t* in the draft:

=C2=A0

* =C2=A0Some of the AODVv2 co-authors and me have as= ked for a list of =E2=80=9Eas a protocol, you can set all of these fields o= f a message, but please leave the rest alone=E2=80=9C, which would=E2=80=99= ve saved us many hours of discussions (and Henning a lot of time spent explaining t= hese things=E2=80=A6). These requests have been met with a refusal to speci= fy a concrete API, as such an effort is dependent on outside factors such a= s programming language or software architecture. I agree with this notion, but a programming-language dependent API is not = what we=E2=80=99ve asked for. I=E2=80=99ve tried to supply a sketch of what= I did ask for in [1], but unfortunately I didn=E2=80=99t get an answer (an= d as far as I can see it, the draft wasn=E2=80=99t changed either). I still think that such a list, in whatever form, would be very helpful fo= r future Internet-Draft authors and I also think this request is in accorda= nce with the intentions stated in=C2=A0= 1.1 History and Purpose,=C2=A0and I think it should be included in the document.

=C2=A0

No. There are many reasons why we're just not to= uching this one.

=C2=A0

One is that language independence is a mirage. How y= ou go about things is completely different in, for example an object orient= ed language than one that isn't. Section 4.5 shows that there are quite different ways of doing things even given a decision = to use a map approach, and there are other approaches than that. It would b= e wrong and beyond our competence to suggest one of these as "best&quo= t;. There's reasons the IETF doesn't do this, and that's one.

=C2=A0

Plus, frankly, the work it would take is beyond what= we choose to spend.

=C2=A0

=C2=A0

<Speaking as a WG Participant>

=C2=A0

I'm confused (which is an altogether too common = occurrence these days). I get that we don't want to specify an API. But= I think the discussion about fields a protocol can and can't touch in a messages is a good thing - and it's one spot where I, too, = find the document wanting.=C2=A0

=C2=A0

To paraphrase something I've said before, I beli= eve that RFC 5444 changes the relationship that a routing protocol has with= an "interface". I'm not commenting on whether or not that's a good thing, or a bad thing - just that it does change the rel= ationship. This change has been at the root of some of the long-running dis= cussions as to whether protocols under development were RFC 5444 compliant = or not. The goal of this document being to eliminate (it's a goal, probably not reachable) those discussions, = I'd like to see that information in the document in some form.=C2=A0=

=C2=A0

I'm interested in seeing this document progress,= and eventually be published. I think it will help future protocol designer= s to better use RFC 5444. But I would like to see *something* along the lines of what Lotte is requesting, as I think it will improve th= e doc.=C2=A0

=C2=A0

Regards,

Stan

=C2=A0

=C2=A0

=C2=A0<= /p>

* As the exact rules for using/setting the hop count= & hop-limit fields are currently being discussed w/ regard to AODVv2 i= n another thread [2]=E2=80=93 should a definitive answer to that question be part of 5444-usage?

=C2=A0

You don't want that. Because if we did specify t= hat you'd find yourself more constrained than you want to be. There is = a design intent described in 5444, but it assumes immutable messages. Which you don't want. Really, we're doing you a favour b= y not imposing on you.

=C2=A0<= /p>

=C2=A0

=C2=A0

Am 06.04.2016 um 19:14 schrieb Justin Dean <bebemaster@gmail.com>:

=C2=A0

The chairs agree that a 3 week WGLC is appropriate.= =C2=A0 Everyone please read the draft early and get comments in early so th= at they can be addressed within the last call period.

=C2=A0

Justin

=C2=A0

On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christophe= r (UK) <chris.dearlove@baesystems.com> wrote:

Obviously +1 to the request for WGLC.

With regard to what's changed, technically the only significant thing i= s to make it clear that if a protocol delivers a message to the multiplexer= , the multiplexer must pass it on unchanged to the protocol (another instan= ce of, at another router) unchanged. Without that nothing that the protocol itself chooses to do with regard to= security makes sense. Though the protocol can alternatively let the multip= lexer do the security, 7182 can be implemented in either way. This isn'= t really new, but it wasn't formally spelled out. It's presented as part of spelling out multiplexer rules = more carefully.

But what about message optimisation? That's a function of constructing = a 5444 message, not the multiplexer, and is down to that 5444 includes two = things - packet/message structure (and implicitly, and in pretty much any i= mplementation I would expect to see, a parser and builder for that structure) and the multiplexer. So we took t= he opportunity to separate out more clearly a discussion of the two, which = we think will be helpful.

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

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN.
www.baesystems.c= om/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 Ulrich Herberg
Sent: 05 April 2016 20:08
To: manet@ietf.org<= br> Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

----------------------! 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 instru= ctions on reporting suspicious email messages.
--------------------------------------------------------

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



Hi,

As you have seen, we have submitted a new revision of 5444-usage. The autho= rs feel comfortable that we have addressed all issues by this version, and = would like to ask the WG chairs to issue a WGLC on this document. While it = is a fairly short document, given that it is IETF week for some, we'd suggest that a 3-4 week WGLC would= be appropriate.

Best regards
Ulrich

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://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
h= ttps://www.ietf.org/mailman/listinfo/manet

=C2=A0

_______________________________________________
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

=C2=A0


--001a113ec9286c4b450530c22f33-- From nobody Mon Apr 18 08: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 3D6B312D978 for ; Mon, 18 Apr 2016 08:05:54 -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 Fbcv-PWHkN6j for ; Mon, 18 Apr 2016 08:05:53 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 9FEFD12D6CE for ; Mon, 18 Apr 2016 08:05:52 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id v188so123969446wme.1 for ; Mon, 18 Apr 2016 08:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=4fS0qW+Bxl96metr6yk8gSuh/XM9s31UKckfIPgrkNE=; b=i+jK+T50tx7k5TX56LskwIJUo5MOdhQRtv6fv8C1llDSgH1lWBC7Bk3ZjopTeWBrk/ 8ojCybcovz+wdg7RQgL0PnSV+0lONALdF/1WalQkOz2f5tubBtrRwnkH74qHRrO4UOPk Q0MpjjAXfPXvm7Hne5y9LQTsNooQ7xjwcf3/h+Tg/XI6YayK8vK9gjre3++SSEga6aJW SDbCaB8XwfOPQw5q5aRr0I/yEe52arnBM9hqpcxYX+gfDoDOckgBz0SKe8Vrcan/ouOk 5Rd5MkVSi2Tjxrx1fSnauubFMzaJNzT1kv03NAEL0eLYm7P+hmZP7h/U/1JPLpoq7DAT baDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=4fS0qW+Bxl96metr6yk8gSuh/XM9s31UKckfIPgrkNE=; b=KgpMTlZZdP8oLekpzLh+7ZwRMeNRg/jWQRdo0oMyMDEWE8ERWVfsUXDilDbAYQBeTx xMEaR/qeaCq3lkEqtuPKqvx+//yMHRu176ab9Jyj9DyzsIzKGDMLEHiKKfz79OiPlLUV SSL4MdIawf9Iseut5VmEda6HrMWd4ScYpzZRxtYdBCXzSUHUg+ZCeQ07quvUr3WuelC0 Mv8zsm5znTWlivehnS9cWRQeVCCH2saufNNEOUq0QB9ZPD7Yb6N++s7lFqP94KNWMMvW ApYCVEGsuMFFF3XtFtKG5P6Fk6+Ii6QO316RTj4dK8Ndj30+AXU14MCkpsVn0J9GLIfh SoLw== X-Gm-Message-State: AOPr4FV14Q0c0xcGvJzp1QHS/kZRrzm68xTfzletQqDlpEKayvvF1DQS3bZnumMGeRrBXQ== X-Received: by 10.28.100.132 with SMTP id y126mr19683665wmb.91.1460991951089; Mon, 18 Apr 2016 08:05:51 -0700 (PDT) Received: from johns-mbp-4.home (host86-157-43-97.range86-157.btcentralplus.com. [86.157.43.97]) by smtp.gmail.com with ESMTPSA id c125sm54104251wme.6.2016.04.18.08.05.49 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Apr 2016 08:05:49 -0700 (PDT) From: John Dowdell Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <4D088849-F444-4FA3-B0AE-0FD2078A76F5@gmail.com> Date: Mon, 18 Apr 2016 16:05:47 +0100 To: manet@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [manet] Review of draft-ietf-manet-rfc5444-usage-03 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, 18 Apr 2016 15:05:54 -0000 First let me say that I wholeheartedly welcome this document. I asked = for it when I was unable to map AODVv2 messages on to the 5444 format to = the satisfaction of the 5444 author team. Some of the other AODVv2 = co-authors have had similar issues, so it=E2=80=99s good that we have = this draft that will hopefully put us and anyone coming after us on the = right track. I=E2=80=99m also sold on the idea of a multiplexer to = increase the efficiency of over the air transmission. Some comments: 4.2, transmission, first bullet: " Outgoing messages are created by = their owning protocol, and MAY be modified by any extending protocols if = the owning protocol permits this.=E2=80=9D Fair enough, so messages from = the hosted protocol can be modified by an extension to that protocol = before getting to the 5444 parser. =E2=80=9C Messages MAY also be forwarded by their owning protocol.=E2=80=9D. Also = ok, there are no extension protocols. "It is strongly RECOMMENDED that messages are not modified in the latter = case.=E2=80=9D I=E2=80=99m not following this. Why is it ok to modify = messages that have been impacted by an extension to the hosted protocol, = but it=E2=80=99s not ok to modify messages that have not been subject to = extension processing? What does =E2=80=98modify=E2=80=99 mean in this = context anyway? 4.2, transmission, second bullet: =E2=80=9C=E2=80=A6 The owning = protocol MUST indicate which interface(s) the messages are to be sent on = =E2=80=A6=E2=80=9D. I have struggled with this for a long time. The = hosted protocol is isolated from the interface by at least the 5444 = multiplexer, and therefore has no idea which interfaces are being used = for transmission or reception. Is there an implicit requirement that the = demultiplexer must indicate the interface that a message came in on = (and, if different, the associated outgoing interface), so that outgoing = messages can be directed accordingly? 4.2, transmission, third bullet: " The multiplexer SHOULD combine = messages =E2=80=A6 provided that in so doing the multiplexer does not = cause an IP packet to exceed the current MTU .. (Note that the = multiplexer cannot fragment messages; creating suitable sized messages = is the responsibility of the protocol generating the message.)=E2=80=9D First problem; how does the hosted protocol know the MTU if it is = isolated from the interface? Second problem; I completely disagree that the hosted protocol, which = has no knowledge of interface or MTU, and may not be the only hosted = protocol, should be in charge of making short enough messages that fit = the MTU size. Since the multiplexer is potentially conducting all kinds = of compression, the hosted protocol is required to carefully craft a = message that fits what it believes is the MTU, if it has been told, only = for the multiplexer to optimise and shave off some bytes (and maybe many = bytes), potentially combine it with messages from some other hosted = protocol and send it out the interface. The hosted protocol could have = used those bytes to send more information, and less overhead would have = been generated. If the 5444 mux/demux is in charge of making whole = messages magically reappear in one piece at the receiving end, it = doesn=E2=80=99t matter to me how many fragments the message was spread = across in transit. 4.2, transmission, fifth bullet: =E2=80=9C =E2=80=A6 the multiplexer = SHOULD =E2=80=A6 include a Packet Sequence Number in the packet=E2=80=9D. = I=E2=80=99m not sure this is necessary. The hosted protocol is most = likely using its own sequence numbers in its own messages, and = understands that messages can arrive out of sequence. Additionally, = packets are only sent hop by hop (section 1.2.1 bullet 3) and never = forwarded. I can see that having a packet sequence number could be = useful for system-level debugging, but otherwise I can=E2=80=99t see the = need. 4.2, reception, "Each message MUST be sent to its owning protocol.=E2=80=9D= Can you clarify that if an extension protocol is being used, that such = a protocol might want or need to process the message first? Bullet 4 = discusses the extension protocol too. 6.4 " Such a protocol-independent optimizer MAY be used by the router = generating a message, but MUST NOT be used on a message that is = forwarded unchanged by a router.=E2=80=9D I understood that 5444 = operates one hop at a time and the messages are presented back to the = host protocol for action. If the host protocol chooses to forward the = message unchanged, I understand that it would be more efficient to wave = the message through at the 5444 level, but surely that is not allowed? A suggestion: Given that AODVv2 is the first =E2=80=9Ccustomer=E2=80=9D = for 5444 outside of the team that also wrote the OLSRv2 series RFCs, can = someone from that team please review the relevant sections in the AODVv2 = draft and assess how well that draft matches up to this draft? Thus = someone coming after us can be directed to AODVv2 as the first = =E2=80=9Ccorrect" independent usage in the manet working group of = RFC5444, and could meet a potential AD-level question of =E2=80=98did we = eat our own dog food?=E2=80=99. I use =E2=80=9Ccorrect=E2=80=9D here not = to say that all potential use cases are covered, but at least AODVv2 = correctly follows the model that the authors of 5444 intended. And finally =E2=80=A6 I=E2=80=99d still like to see even a minimal API = specification, it would have saved me days if not weeks of wasted effort = going in the wrong direction. Also, I=E2=80=99d still like to see a = statement of components that are reserved entirely for use by the 5444 = process, and what can be usefully used by the hosted protocol. Regards John From nobody Mon Apr 18 08:23: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 09F2812DA3D for ; Mon, 18 Apr 2016 08:23: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 0js34Lee_F5l for ; Mon, 18 Apr 2016 08:23:36 -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 B457612D96E for ; Mon, 18 Apr 2016 08:23:35 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,503,1454976000"; d="scan'208,217"; a="33771662" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 18 Apr 2016 16:23:33 +0100 X-IronPort-AV: E=Sophos;i="5.24,503,1454976000"; d="scan'208,217";a="114451646" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 18 Apr 2016 16:23:33 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 16:23:33 +0100 From: "Dearlove, Christopher (UK)" To: Stan Ratliff Thread-Topic: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 Thread-Index: AQHRj26efzFsMll+IU2A0f8aUpvZOp980SWwgABO2gCADfPgAIAAOu8AgAANM4CAAZs2zoACiJ1wgAA3bACAABD7IP//8YIAgAAxN1A= Date: Mon, 18 Apr 2016 15:23:33 +0000 Message-ID: References: <45DFA343-1FDD-4EB9-9291-AB3A830A3CD9@mnemosyne.demon.co.uk> 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ADAB6GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" , Christopher Dearlove Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 18 Apr 2016 15:23:42 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ADAB6GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2YgY291cnNlIGl0IG1ha2VzIHNlbnNlIC0gYmVjYXVzZSBpdOKAmXMgYmVlbiBkb25lIGFzIEkg bm90ZWQuDQoNClRoZSBtdWx0aXBsZXhlciBkb2VzbuKAmXQgYWN0dWFsbHkgaGF2ZSB0byBwYXJz ZSBtZXNzYWdlcywgaXQgbmVlZHMgdG8gZ3JvdXAgdGhlbSBpbnRvIHBhY2tldHMuIEl0IG5lZWRz IHRvIGJlIGFibGUgdG8gcGFyc2UgYSBwYWNrZXQgZG93biB0byDigJxoZXJlIGFyZSB0aGUgbWVz c2FnZXPigJ0gYW5kIGRlbGl2ZXIgdGhlbS4gVGhlIG1lc3NhZ2VzIGNhbiBiZSBzaW1wbGUgYmxv YnMuIEZvciB0aGF0IGl0IG5lZWRzIHRoZSBtZXNzYWdlIHR5cGUgLSBjb252ZW5pZW50bHkgcGxh Y2VkIHVwIGZyb250IGluIHRoZSBtZXNzYWdlIGhlYWRlciB0byBiZSByZWFkIC0gYW5kIHRoZSBt ZXNzYWdlIGxlbmd0aCAtIGRpdHRvLiBUaGUgcGFyc2luZyBvZiB0aGUgbWVzc2FnZXMgaXMgYSBw cm90b2NvbCBwcm9ibGVtLiBJZiBqdXN0IGltcGxlbWVudGluZyBvbmUgcHJvdG9jb2wgaXQgY291 bGQgaW5jb3Jwb3JhdGUgdGhlIHBhcnNlci4gSWYgaW1wbGVtZW50aW5nIG11bHRpcGxlIHByb3Rv Y29scyB5b3UgY2FuIGNyZWF0ZSBhbiBpbmRlcGVuZGVudCBwYXJzZXIuIE9yIHlvdSBtYXkgZG8g dGhlIGxhdHRlciBldmVuIGluIHRoZSBmb3JtZXIgY2FzZS4NCg0KQW5kIGV2ZW4gaWYgd2UgYWxs IGltcGxlbWVudGVkIGluZGVwZW5kZW50IHBhcnNlcnMgdGhleSBjYW4gYmUgcXVpdGUgZGlmZmVy ZW50LiBBcyBpbmRlZWQgdGhlIG9uZXMgdGhhdCBleGlzdCBhcmUuIE5vdCBqdXN0IG1lcmVseSBp biBBUEkuIEZvciBleGFtcGxlIEkgY291bGQgdHVybiBhIG1lc3NhZ2UgaW50byBhIHNldCBvZiBv YmplY3RzLiBPciBJIGNvdWxkIHByb3ZpZGUgcG9pbnRlcnMgaW50byB0aGUgZGF0YSBibG9jayB0 aGF0IHJlcHJlc2VudHMgdGhlIG1lc3NhZ2UuICBBbmQgb3RoZXIgYXBwcm9hY2hlcy4NCg0KLS0N CkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lz dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl bXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3Rl bXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVh dCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20v YWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50 ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMz NzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQs IFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBTdGFuIFJhdGxpZmYgW21haWx0bzpyYXRsaWZmc3Rh bkBnbWFpbC5jb21dDQpTZW50OiAxOCBBcHJpbCAyMDE2IDE0OjE4DQpUbzogRGVhcmxvdmUsIENo cmlzdG9waGVyIChVSykNCkNjOiBDaHJpc3RvcGhlciBEZWFybG92ZTsgbWFuZXRAaWV0Zi5vcmc7 IENocmlzdG9waGVyIERlYXJsb3ZlDQpTdWJqZWN0OiBSZTogW21hbmV0XSBXR0xDIHJlcXVlc3Qg Zm9yIGRyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMw0KDQoNCioqKiBXQVJOSU5HICoq Kg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24s IGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lk ZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4g YW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQg RmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNs aWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2Vj dXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVs IHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRw Oi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGln aHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4N Cg0KDQpPbiBNb24sIEFwciAxOCwgMjAxNiBhdCA5OjEzIEFNLCBEZWFybG92ZSwgQ2hyaXN0b3Bo ZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJs b3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQpBcyBoYXMgYmVlbiBwb2ludGVkIG91dCB0byBt ZSwgc29tZSBpbXBsZW1lbnRhdGlvbnMgZG9u4oCZdCBkbyB0aGlzLiBJZiB5b3UgYXJlIGJ1aWxk aW5nIGFuIGltcGxlbWVudGF0aW9uIGluIGEgY29uc3RyYWluZWQgZW52aXJvbm1lbnQsIHlvdSBj YW4gYnVpbGQgYSBjb25zdHJhaW5lZCBpbXBsZW1lbnRhdGlvbi4gQW5kIHNvbWUgcGVvcGxlIGhh dmUuDQoNClNvIG5vLCBpdOKAmXMgbm90IGFwcHJvcHJpYXRlIHRvIHNwZWNpZnkgYW4gaW5kZXBl bmRlbnQgcGFyc2VyLCBvciByZXF1aXJlIG9uZS4gUmF0aGVyIHlvdSBuZWVkIHRvIGRlc2lnbiBz byB0aGF0IHdoZW4gcGVvcGxlIGRvLCBpdCBjYW4gYmUgZWZmaWNpZW50LiBXaGljaCBpcyB3aGF0 IHdlIGhhdmUgYmVlbiBkb2luZy4NCg0KT3IgaW4gb3RoZXIgd29yZHMsIEkgZG9u4oCZdCB0aGlu ayB0aGlzIHNvcnQgb2YgY2hhbmdlIGlzIGFwcHJvcHJpYXRlLiBRdWl0ZSB0aGUgY29udHJhcnku DQoNCldlbGwsIHdlIGRpc2FncmVlLiBUaGlzIGhhcyBiZWVuIGEgZnVuZGFtZW50YWwgcG9pbnQg b2YgY29udGVudGlvbiBmb3Igc29tZSBvZiB0aGUgZm9sbG93LW9uIHByb3RvY29scyBhdHRlbXB0 aW5nIHRvIHVzZSA1NDQ0LiBhbmQgSU1PLCB0aGlzIGhhcyB0byBiZSBhZGRyZXNzZWQuDQoNCg0K VGhlIGtleSBwb2ludCBpcyB0aGF0IHdoYXTigJlzIG1hbmRhdGVkIGlzIGEgbXVsdGlwbGV4ZXIg YW5kIGEgZm9ybWF0LiBCdXQgbm90IGFuIGluZGVwZW5kZW50IHBhcnNlci4NCg0KSG93IGNhbiB5 b3UgbWFuZGF0ZSBhIG11bHRpcGxleGVyLCBidXQgbm90IGFuIGluZGVwZW5kZW50IHBhcnNlcj8g VGhpcyBtYWtlcyBubyBzZW5zZS4NCg0KU3Rhbg0KDQoNCg0KLS0NCkNocmlzdG9waGVyIERlYXJs b3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs bGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0 NSAyNDIxOTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5k ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hu b2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3 LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lz dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQg JiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2gg UGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTogU3RhbiBSYXRsaWZmIFtt YWlsdG86cmF0bGlmZnN0YW5AZ21haWwuY29tPG1haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb20+ XQ0KU2VudDogMTggQXByaWwgMjAxNiAxNDowOQ0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAo VUspDQpDYzogQ2hyaXN0b3BoZXIgRGVhcmxvdmU7IG1hbmV0QGlldGYub3JnPG1haWx0bzptYW5l dEBpZXRmLm9yZz47IENocmlzdG9waGVyIERlYXJsb3ZlDQpTdWJqZWN0OiBSZTogW21hbmV0XSBX R0xDIHJlcXVlc3QgZm9yIGRyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMw0KDQoNCioq KiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBv cmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVy bmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkg bGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJl Z2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91 IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9o b3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4N CklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMg cHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1 cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBF bWFpbHMucGRmPi4NCg0KDQpPbiBNb24sIEFwciAxOCwgMjAxNiBhdCA0OjUyIEFNLCBEZWFybG92 ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRv OmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQpJIGRvbuKAmXQgYmVsaWV2 ZSB3ZSBjYW4gb3Igc2hvdWxkIHN1Z2dlc3QgYW4gaW1wbGVtZW50YXRpb24uIFRoYXTigJlzIG5v dCB3aGF0IHRoZSBJRVRGIGRvZXMsIGFuZCBpdCB3b3VsZCBiZSBhIGhhcmQsIHByb2JhYmx5IGlt cG9zc2libGUsIHNlbGwsIHRvIHRoZSBJRVNHLiBUaGF0IHRoZSBvYnZpb3VzIGltcGxlbWVudGF0 aW9uIGVtcGxveXMgYW4gaW5kZXBlbmRlbnQgcGFyc2VyIGlzIGFscmVhZHkgc2FpZCAtIGl0IG1h eSBiZSBhcHByb3ByaWF0ZSB0byBzdHJlbmd0aGVuIHRoZSB3b3JkcywgYnV0IHRoaXMgc2Vjb25k IEnigJltIG5vdCBzdXJlIGlmIHRoYXTigJlzIG5lZWRlZCAobm90IGdvdCB0aW1lIHRvIGNoZWNr IGN1cnJlbnQgd29yZGluZykuDQoNCihBZ2Fpbiwgd2l0aCBteSBXb3JraW5nIEdyb3VwIFBhcnRp Y2lwYW50IGhhdCBvbikgLQ0KDQpJIGRvbid0IG1lYW4gdG8gc3VnZ2VzdCBhbiBpbXBsZW1lbnRh dGlvbi4gQXQgbGVhc3QgdG8gbWUsIHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJlICh0aGF0IG9mIGFu IGluZGVwZW5kZW50IHBhcnNlciwgd2l0aCBhIHJlbGlhYmxlIGNvbW11bmljYXRpb25zIG1lY2hh bmlzbSB0byBzYWlkIHBhcnNlciwgdGhhdCBkZWFscyB3aXRoIGxvZ2ljYWwgbWVzc2FnZXMgaW5z dGVhZCBvZiBwYWNrZXRzLiBJcyBzZXF1ZW5jaW5nIGd1YXJhbnRlZWQ/IEknbSBub3Qgc3VyZSwg dG8gYmUgaG9uZXN0LiBCdXQgb25jZSB0aGUgaW5kZXBlbmRlbnQgcGFyc2VyIGlzIGFzc3VtZWQs IGVuZ2luZWVycyBhbHNvIE1VU1QgYXNzdW1lIHRoYXQgdGhlIHRyYW5zcG9ydCAoYW5kIGl0J3Mg dGhlIHRyYW5zcG9ydCBmb3IgY29udHJvbCBwbGFuZSB0cmFmZmljLCBidXQgbm90IGZvciBkYXRh IHBsYW5lIHRyYWZmaWMpLCBpcyAib3duZWQiIGJ5IHRoZSBpbmRlcGVuZGVudCBwYXJzZXIuDQoN CldoaWNoIGxlYWRzIG1lIHRvIHRoZSBvdGhlciBwb2ludCBJJ20gdHJ5aW5nIHRvIG1ha2UgKHBl cmhhcHMgYmFkbHkpOiAgQWJzdHJhY3RpbmcgdGhlIHRyYW5zcG9ydCBhd2F5IGZyb20gdGhlIGNv bnRyb2wgcGxhbmUgKmNhbiogZWZmZWN0IHByb3RvY29sIGRlc2lnbi4NCg0KSSBiZWxpZXZlIGJv dGggb2YgdGhlc2UgcG9pbnRzIHNob3VsZCBiZSBhZGRyZXNzZWQgaW4gdGhlIHVzYWdlIGRvY3Vt ZW50Lg0KDQpSZWdhcmRzLA0KU3Rhbg0KDQoNCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpT ZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j ZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIx OTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoN CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kg UGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5 c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBB cHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxl cyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywg R3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1i b3VuY2VzQGlldGYub3JnPG1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxm IE9mIFN0YW4gUmF0bGlmZg0KU2VudDogMTYgQXByaWwgMjAxNiAxOTowOQ0KVG86IENocmlzdG9w aGVyIERlYXJsb3ZlDQpDYzogbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPjsg Q2hyaXN0b3BoZXIgRGVhcmxvdmUNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFdHTEMgcmVxdWVzdCBm b3IgZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzDQoNCg0KKioqIFdBUk5JTkcgKioq DQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwg ZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRl ciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBh bnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBG bGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xp Y2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1 cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwg dGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6 Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdo dHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0K KioqIFdBUk5JTkcgKioqDQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRl cyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbi4NCg0KDQoNCk9uIEZyaSwgQXByIDE1LCAy MDE2IGF0IDM6MjcgUE0sIENocmlzdG9waGVyIERlYXJsb3ZlIDxjaHJpc0BtbmVtb3N5bmUuZGVt b24uY28udWs8bWFpbHRvOmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51az4+IHdyb3RlOg0KSSBk b24ndCB1bmRlcnN0YW5kIHdoYXQgeW91IG1lYW4gYnkgdGhlIGNvbmNlcHQgb2YgImZpZWxkcyB0 aGUgcHJvdG9jb2wgY2FuIGFuZCBjYW4ndCB0b3VjaCIuDQoNCkNBVkVBVDogSSBhbSBzcGVha2lu ZyBoZXJlIGFzIGEgV29ya2luZyBHcm91cCBwYXJ0aWNpcGFudC4gV2l0aCB0aGF0IHVuZGVyc3Rv b2Q6DQoNCg0KVFRMIGlzIGEgZ3JlYXQgZXhhbXBsZSwgc2luY2UgdGhhdCBkaXNjdXNzaW9uIGJs ZXcgdGhlIG1haWxpbmcgbGlzdCB1cCBhIGZldyBtb250aHMgYWdvLiBJJ20gKm5vdCogc2F5aW5n IG1hbmlwdWxhdGluZyBUVEwgaXMgYSBnb29kIHRoaW5nIGZvciBhIHByb3RvY29sIHRvIHRyeSAt IGluIHRydXRoLCBJIHRoaW5rIGl0J3MgcHJldHR5ICJoYWNreSIuIEJ1dCB0aGUgbm90aW9uIHdh cyBmbG9hdGVkLCBhbmQgaW4gdGhlIGNvbnRleHQgb2YgdGhhdCBkaXNjdXNzaW9uLCBpdCBtYXkg d2lsbCBoYXZlIHdvcmtlZC4gVGhlIG9wcG9zaXRpb24gb24tbGlzdCB3YXMgZmFzdCwgYW5kIHBy ZXR0eSBmb3JjZWZ1bC4NCkkndmUgc2FpZCBiZWZvcmUgLSA1NDQ0LCBlc3BlY2lhbGx5IHdpdGgg dGhlIG11bHRpcGxleGVyLCBjaGFuZ2VzIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBhIHJvdXRp bmcgcHJvdG9jb2wgYW5kIGFuIGludGVyZmFjZS4gSSB0aGluayB0aGUgZG9jdW1lbnQgc2hvdWxk IGhhdmUgc29tZSB0eXBlIG9mICJvdmVydmlldyIgc2VjdGlvbiB3aGljaCBkaXNjdXNzZXMgdGhl c2UgZGlmZmVyZW5jZXMsIGluIG9yZGVyIHRvIGZyYW1lIHRoZSBpc3N1ZSBmb3Igc29tZW9uZSBj b21pbmcgYWxvbmcgd2hvIGhhc24ndCBiZWVuIGEgcGFydCBvZiB0aGUgNTQ0NCBtYWlsIGRpc2N1 c3Npb24uDQpJJ20gdGFsa2luZyBhYm91dCB0aGUgdHlwZSBvZiBvdmVydmlldyB0aGF0IGdvZXMg c29tZXRoaW5nIGxpa2UgdGhpczoNCiJVc2Ugb2YgUkZDIDU0NDQgd2l0aCB0aGUgbXVsdGlwbGV4 ZXIgZmVhdHVyZSBpbXBvc2VzIGRlc2lnbiByZXF1aXJlbWVudHMgb24gdGhlIHByb3RvY29sLiBU aGUgYWN0dWFsIHRyYW5zcG9ydCBtZWNoYW5pc20gaXMgYWJzdHJhY3RlZCBmcm9tIHRoZSBwcm90 b2NvbC4gRm9yIGV4YW1wbGUsIHJvdXRpbmcgcHJvdG9jb2xzIGFyZSBub3QgYXdhcmUgb2YgcHJl Y2lzZWx5IHdoZW4gYSBtZXNzYWdlIGlzIHNlbnQuIEEgZ29vZCBleGFtcGxlIG9mIG9wZXJhdGlv biBpbiB0aGlzIG1vZGVsIGlzIFtCR1BdLCB1dGlsaXppbmcgdGhlIFtUQ1BdIHRyYW5zcG9ydC4g VGhpcyBpcyBvcHBvc2VkIHRvIGEgcHJvdG9jb2wgc3VjaCBhcyBbT1NQRl0sIHdoaWNoIGlzIGNh cGFibGUgb2Ygc2VuZGluZyB0cmFmZmljIHdpdGggaXRzIG93biBJUCB0eXBlLiBTaW5jZSB0aGUg dHJhbnNwb3J0IGlzIGFic3RyYWN0ZWQsIHByb3RvY29scyBhcmUgbm90IHByZXNlbnRlZCB3aXRo ICJwYWNrZXRzIiwgYW5kIGFyZSBub3QgY2FwYWJsZSBvZiBtYW5pcHVsYXRpbmcgZGF0YSBpdGVt cyBpbiBwYWNrZXQgaGVhZGVycyAoZS5nLiBkYXRhIGl0ZW1zIGF0IHRoZSBJUCBhbmQvb3IgTUFD IGxheWVycykuIg0KDQpBcyBMb3UgQmVyZ2VyIHB1dCBpdCB0byBtZSBpbiB0aGUgY29udGV4dCBv ZiBETEVQIC0gIllvdSB3YW50IGFuIGVuZ2luZWVyIHRvIGJlIGFibGUgdG8gcGljayB1cCB0aGlz IGRvY3VtZW50LCB3aXRoIG5vIHByaW9yIGV4cG9zdXJlIHRvIHRoZSB0b3BpYywgYW5kIGNvZGUg YW4gaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbi4iICBJIHRoaW5rIHRoaXMgdHlwZSBvZiBh biBvdmVydmlldywgc2V0dGluZyBiYXNpYyBncm91bmQgcnVsZXMsIHdvdWxkIGhlbHAuDQpJJ3Zl IGFsc28gY29udGVuZGVkIGZvciBhIHdoaWxlIG5vdyB0aGF0IDU0NDQsIHdpdGggdGhlIG11eCwg ZWZmZWN0aXZlbHkgZm9yY2VzIGFuIGFyY2hpdGVjdHVyZSBvbiBpbXBsZW1lbnRlcnMgLSBpbiB0 aGUgTGludXggd29ybGQsIHRoYXQgYXJjaGl0ZWN0dXJlIGlzIGEgNTQ0NCBwYXJzZXIgYXMgYW4g aW5kZXBlbmRlbnQgcHJvY2Vzcywgd2l0aCBJUEMgbWVjaGFuaXNtcyB0byB0aGUgcm91dGluZyBw cm90b2NvbChzKSBpdCBpcyBzZXJ2aWNpbmcuIFRoZSA1NDQ0IHBhcnNlciBpdHNlbGYgIm93bnMi IHRoZSB0cmFuc3BvcnQgKHRoZSBzb2NrZXQpLiBUaGUgdXNhZ2UgZG9jdW1lbnQgKnN0cm9uZ2x5 IGluZmVycyogdGhhdC4gSSBiZWxpZXZlIHdlIHNob3VsZCBjb25jcmV0ZWx5IHN0YXRlIGl0LCBz byB3ZSBkb24ndCBoYXZlIHRvIGFuc3dlciB0aGUgcXVlc3Rpb24gb3ZlciBhbmQgb3ZlciBhZ2Fp bi4NClJlZ2FyZHMsDQpTdGFuDQoNCg0KDQpXaGVuIGEgcHJvdG9jb2wgY3JlYXRlcyBhIG1lc3Nh Z2UgZnJvbSBzY3JhdGNoIGl0J3Mgbm90IGNvbnN0cmFpbmVkIGluIGFueSB3YXkgSSdkIGRlc2Ny aWJlIGluIHN1Y2ggdGVybXMuIFNvIEkgYXNzdW1lIHlvdSBtZWFuIHdoZW4gaXQgcmVjZWl2ZXMg YSBtZXNzYWdlIGFuZCB0aGVuIHNlbmRzIGEgc2ltaWxhciBtZXNzYWdlLg0KDQpUaGVyZSBhcmUg dHdvIGNhc2VzIHRoZXJlLiBVbmNoYW5nZWQgKHdpdGggdGhlIHNwZWNpYWwgZXhjZXB0aW9ucyBm b3IgaG9wIGNvdW50IGFuZCBsaW1pdCkgYW5kIG5vdCB1bmNoYW5nZWQuIFRoZSBmb3JtZXIgaXMg YmV0dGVyLCBhbmQgdGhlcmUncyByZWFsbHkgbm90aGluZyBtb3JlIHRvIHNheS4NCg0KU28gbGV0 J3MgY29uc2lkZXIgdGhlIGxhdHRlci4gUmVhbGx5IGl0J3Mgbm90IHRoZSBzYW1lIG1lc3NhZ2Us IGl0J3MgYSBicmFuZCBuZXcgbWVzc2FnZS4gVGhhdCdzIGEgdXNlZnVsIHdheSB0byBsb29rIGF0 IGl0IGZyb20gYSBzZWN1cml0eSBwZXJzcGVjdGl2ZSwgYmVjYXVzZSBpdCB0ZWxscyB5b3UgdGhh dCBlbmQgdG8gZW5kIGF1dGhlbnRpY2F0aW9uIGlzbid0IGdvaW5nIHRvIHdvcmsuIEFuZCB3aGF0 IGFyZSB0aGUgcmVzdHJpY3Rpb25zIG9uIGJyYW5kIG5ldyBtZXNzYWdlcz8gVGhlIHNhbWUgYXMg b24gYW55IG5ldyBtZXNzYWdlLg0KDQpPSywgeW91IG1pZ2h0IHNheSwgdHJ1ZSBidXQgZG9lcyB0 aGF0IG1lYW4gSSBjYW4gYWRkIHRoaXMsIHJlbW92ZSB0aGF0LCBjaGFuZ2UgdGhlIGhvcCBkYXRh PyBZZXMuIEJ1dCBpcyB0aGF0IGEgZ29vZCBpZGVhPyBOby4gQnV0IG1heWJlIHlvdSBhcmUgZm9y Y2VkIGludG8gaXQuIEJ1dCB0aGF0IGl0J3MgaW5oZXJlbnRseSBub3QgZ29vZCBzdWdnZXN0cyB0 aGUgY29yb2xsYXJ5IHRoYXQgaWYgeW91IG11c3QsIGRvIHRoZSBtaW5pbXVtIGFuZCBtYWtlIGl0 IHRyYWNrYWJsZS4gQnV0IHRoYXQncyBub3QgYSA1NDQ0IHJlcXVpcmVtZW50LCBqdXN0IGdvb2Qg cHJhY3RpY2UuIEl0IGRvZXMgYnJlYWsgNzE4MiBtZXNzYWdlIElDVnMsIHNvIGRvbid0IHVzZSB0 aGVtLg0KDQpXZSBjb3VsZCwgaHlwb3RoZXRpY2FsbHksIGhhdmUgc29tZW9uZSBjcmVhdGUgYW4g ZXh0ZW5zaW9uIG9yIGFsdGVybmF0aXZlIHRvIDcxODIgdGhhdCBkZWZpbmVkIGFnZ3JlZ2F0ZWQg c2lnbmF0dXJlcy4gVGhlbiB3ZSdkIGhhdmUgcnVsZXMgb24gd2hhdCB5b3UgY291bGQgY2hhbmdl LiBCdXQgdGhhdCB3b3VsZCBiZWxvbmcgdGhlcmUuIElmIHlvdSB0aGluayB0aG9zZSB3b3VsZCBi ZSBnb29kLCB0aGVuIGFnYWluIHlvdSB3b3VsZCB3YW50IG1ha2UgbWluaW1hbCBjaGFuZ2VzLCBh bmQgbWFpbmx5IG9ubHkgb2YgY2VydGFpbiB0eXBlcy4gV2hhdCB0eXBlcz8gVGhlcmUgSSBjYW4n dCBoZWxwIHlvdSBhcyBJIGRvbid0IGhhdmUgYSBjYW5kaWRhdGUuDQoNClRoZSBzdW1tYXJ5PyBE b24ndCBjaGFuZ2UgaWYgeW91IGRvbid0IGhhdmUgdG8uIFRoYXQncyByZWNvbW1lbmRlZC4gSWYg eW91IG11c3QgY2hhbmdlIHlvdSdyZSBvbiB5b3VyIG93biAod2l0aCB0aGUgc2FtZSByZXN0cmlj dGlvbnMgYXMgbmV3IG1lc3NhZ2VzKS4gQWR2aWNlIGxpa2UgImFzIGxpdHRsZSBhcyBwb3NzaWJs ZSIgaXMgZ29vZCwgYnV0IHRoYXQncyBub3QgYWN0dWFsbHkgNTQ0NCBhZHZpY2UuIEFuZCBkb24n dCB1c2UgNzE4MiBtZXNzYWdlIElDVnMuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KY2hy aXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tPG1haWx0bzpjaHJpc3RvcGhlci5kZWFybG92ZUBn bWFpbC5jb20+IChpUGhvbmUpDQpjaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWs8bWFpbHRvOmNo cmlzQG1uZW1vc3luZS5kZW1vbi5jby51az4gKGhvbWUpDQoNCk9uIDE1IEFwciAyMDE2LCBhdCAx OTozNywgU3RhbiBSYXRsaWZmIDxyYXRsaWZmc3RhbkBnbWFpbC5jb208bWFpbHRvOnJhdGxpZmZz dGFuQGdtYWlsLmNvbT4+IHdyb3RlOg0KTXkgbWFpbiBjb25jZXJuIGFkZHJlc3NlZCBpbmxpbmUu Li4NCg0KDQpPbiBGcmksIEFwciAxNSwgMjAxNiBhdCAxOjQ5IFBNLCBDaHJpc3RvcGhlciBEZWFy bG92ZSA8Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tPG1haWx0bzpjaHJpc3RvcGhlci5k ZWFybG92ZUBnbWFpbC5jb20+PiB3cm90ZToNCkEgZmV3IGltbWVkaWF0ZSBjb21tZW50cyBpbmxp bmUgYmVsb3cuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KY2hyaXN0b3BoZXIuZGVhcmxv dmVAZ21haWwuY29tPG1haWx0bzpjaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb20+IChpUGhv bmUpDQpjaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWs8bWFpbHRvOmNocmlzQG1uZW1vc3luZS5k ZW1vbi5jby51az4gKGhvbWUpDQoNCk9uIDE1IEFwciAyMDE2LCBhdCAxNToxOCwgTG90dGUgU3Rl ZW5icmluayA8bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4uZGU8bWFpbHRvOmxvdHRlLnN0ZWVu YnJpbmtAZnUtYmVybGluLmRlPj4gd3JvdGU6DQpIaSBhbGwsDQoNCnNwYXJrZWQgYnkgdGhlIHJl Y2VudGx5IHN0YXJ0ZWQgV0dMQywgSeKAmXZlIHJldmlld2VkIHRoZSBjdXJyZW50IHJldmlzaW9u IG9mIHRoZSBkcmFmdC4gSeKAmWQgbGlrZSB0byBvZmZlciB0aGUgd29ya2luZyBncm91cCBteSBw ZXJzcGVjdGl2ZSBhcyBzb21lb25lIHdobyBkb2VzbuKAmXQgaGF2ZSBkZWNhZGVzIG9mIHByb3Rv Y29sIGFuZC9vciBwYWNrZXQgZm9ybWF0IGRlc2lnbiB1bmRlciB0aGVpciBiZWx0IChpLmUuIHNv bWUgdGhpbmdzIG1pZ2h0IG5vdCBiZSBvYnZpb3VzIHRvIG1lIHRoYXQgYXJlIG9idmlvdXMgdG8g b3RoZXJzKSwgYnV0IGFsc28gYXMgc29tZW9uZSB3aG8gaGFzIHdvcmtlZCB3aXRoIFJGQyA1NDQ0 IHdoZW4gaW1wbGVtZW50aW5nIGEgcm91dGluZyBwcm90b2NvbCAoQU9EVnYyKSwgdXBkYXRpbmcg dGhlIHBhY2tldCBmb3JtYXQgb2YgYSByb3V0aW5nIHByb3RvY29sIChBT0RWdjIgYWdhaW4pIGFu ZCAocGFydGlhbGx5KSBpbXBsZW1lbnRpbmcgbXkgb3duIFJGQzU0NDQgYnVpbGRlci9wYXJzZXIu DQoNCk92ZXJhbGwsIEkgdGhpbmsgdGhlIGRvY3VtZW50IGlzIGVhc3kgdG8gcmVhZCBhbmQgZm9s bG93LiBUbyBtZSwgaXQgY29udGFpbnMgdmFsdWFibGUgaW5mb3JtYXRpb24gYW5kIGd1aWRhbmNl IGFuZCBpbiBzb21lIGNhc2VzIHByZXZlbnRzIHBlb3BsZSBmcm9tIHNob290aW5nIHRoZW1zZWx2 ZXMgaW4gdGhlIGZvb3QuDQpJ4oCZbSByZWFsbHkgaGFwcHkgdGhpcyBkb2N1bWVudCBleGlzdHMg YW5kIEnigJlkIGxpa2UgaXQgdG8gbW92ZSBmb3J3YXJkIHNvb24sIGJ1dCBJIGRvIGZlZWwgdGhh dCBpdCBpcyBzdGlsbCBsYWNraW5nIGluIHNvbWUgYXJlYXMsIHdoaWNoIGlzIHdoeSBJIHdhcyBh IGJpdCBzdXJwcmlzZWQgdG8gc2VlIGl0IGdvIHRvIExhc3QgQ2FsbCBhbGwgb2YgYSBzdWRkZW4u DQoNCk5vdCByZWFsbHkuIFRoZSBhdXRob3JzIGhhZCBzYWlkIHdoYXQgdGhleSBpbnRlbmRlZCB0 byBzYXksIG5vIG9uZSB3YXMgY29tbWVudGluZywgdGltZSBmb3IgV0dMQy4NCg0KRmlyc3QsIHNv bWUgbml0cGlja3MgYW5kIGNvbW1lbnRzOg0KDQoqIGZyb20gMS4yLjE8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTEu Mi4xPi4gUGFja2V0L01lc3NhZ2UgRm9ybWF0Og0KDQoNCiAgICAgIFvigKZdIGEgcGFja2V0DQoN CiAgICAgIHRyYW5zbWlzc2lvbiBmb2xsb3dpbmcgYSBzdWNjZXNzZnVsIHBhY2tldCByZWNlcHRp b24gaXMgYnkgZGVzaWduDQoNCiAgICAgIG9mIGEgbmV3IHBhY2tldCB0aGF0IG1heSBpbmNsdWRl IGFsbCwgc29tZSwgb3Igbm9uZSBvZiB0aGUNCg0KICAgICAgcmVjZWl2ZWQgbWVzc2FnZXMgWy4u Ll0NCg0KSeKAmW0gbm90IGEgbmF0aXZlIHNwZWFrZXIsIGJ1dCB0aGF0IOKAnm9m4oCcIHNlZW1z IG91dCBvZiBwbGFjZS4uLg0KDQpJIGFtIGEgbmF0aXZlIHNwZWFrZXIsIGFuZCBubywgaXQncyBu b3QuIFNvbWUgd291bGQgcmVwZWF0IGl0IGFmdGVyIGVhY2ggb2YgYWxsLCBzb21lIGFuZCBub25l LCBhbmQgSSBtaWdodCBzb21ldGltZXMuIEJ1dCBpdCByZWFsbHkgZG9lc24ndCBtYXR0ZXIgd2hp Y2ggb2YgdGhlIHR3byBzdHlsZXMgd2UgcGljaywgdGhlIFJGQyBFZGl0b3IgbWF5IHdlbGwgY2hh bmdlIHRvIHRoZSBvdGhlci4NCg0KKiBSZWdhcmRpbmcgNC4yPGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi00LjI+LiBQ YWNrZXRzIGFuZCBNZXNzYWdlczoNCnRoaXMgc2VjdGlvbiB0YWxrcyBhIGxvdCBhYm91dCBob3cg dGhlIG11bHRpcGxleGVyIG9wZXJhdGVzLCBzbyBJIHRoaW5rIGl04oCZZCBiZSBoZWxwZnVsIGlm IGl0cyB0aXRsZSByZWZsZWN0ZWQgdGhhdC4NCg0KSSdtIG9mIHR3byBvcGluaW9ucyBvbiB0aGF0 LiBPbiB0aGUgb25lIGhhbmQgaXQgaXMsIGFzIGl0cyB0aXRsZSBzdWdnZXN0cywgYWJvdXQgdGhl IHBhY2tldCBhbmQgbWVzc2FnZSBsZXZlbCwgYXMgb3Bwb3NlZCB0byBsb3dlciBsZXZlbHMsIGFu ZCBpdHMgdGl0bGUgY29udHJhc3RzIHdpdGggdGhhdCBpZiA0LjMgZm9yIHRoYXQgcmVhc29uLiBP biB0aGUgb3RoZXIgaGFuZCB5b3UgYXJlIHJpZ2h0LCBpdCBkb2VzIGhhdmUgbXVjaCBhYm91dCB0 aGUgbXVsdGlwbGV4ZXIuIEEgdGl0bGUgY292ZXJpbmcgYWxsIHRocmVlIHdvdWtkIHN0YXJ0IGdl dHRpbmcgY3VtYmVyc29tZS4gV2lsbCB0YWtlIHRoaXMgb25lIGF3YXkgdG8gdGhpbmsgYWJvdXQu DQoNCiogZnJvbSA0LjQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFu ZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTQuND4uIEFkZHJlc3NlcyBSZXF1aXJlIEF0dHJp YnV0ZXM6DQoNCg0KICAgQW4gdW5tb2RpZmllZCBleHRlbnNpb24gdG8gTkhEUCB3b3VsZCBpZ25v cmUgc3VjaCBhZGRyZXNzZXMsDQoNCiAgIGFzIHJlcXVpcmVkLCBhcyBpdCBkb2VzIG5vdCBzdXBw b3J0IHRoYXQgc3BlY2lhbGl6ZWQgcHVycG9zZS4NCg0KQXQgZmlyc3QgZ2xhbmNlLCAodG8gbWUp IHRoaXMgcmVhZHMgYXMg4oCeQWxsIGFkZHJlc3NlcyB0aGF0IGFyZSBhc3NvY2lhdGVkIHdpdGgg YW4gdW5rbm93biBUTFYgYXJlIGlnbm9yZWTigJwsIHdoaWNoIGlzIG9idmlvdXNseSBub25zZW5z ZSAoYnV0IHF1aXRlIHBhbmljLWluZHVjaW5nIDpEKS4gSeKAmWQgcHJvcG9zZSB0byByZXdvcmQg aXQgdG8gc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZg0KDQogICBBbiB1bm1vZGlmaWVkIGV4 dGVuc2lvbiB0byBOSERQIHdvdWxkIG5vdCBjb25zaWRlciB0aGlzDQoNCiAgIGFkZHJlc3MgdG8g YmUgb2YgYSBuZWlnaGJvciwgYXMgaXQgaXMgbGFja2luZyBhIExJTktfU1RBVFVTDQoNCiAgIG9y IE9USEVSX05FSUdIQiBUTFYuDQoNCkkgdGFrZSB5b3VyIHBvaW50LCBidXQgSSB0aGluayB0aGF0 IGlmIHRoZSBhZGRyZXNzIGVuZHMgdXAgd2l0aCBubyByZWxldmFudCBhc3NvY2lhdGVkIFRMVnMg dGhlbiBpdCBpcyBpZ25vcmVkIGlzIGFsc28gYSBwb2ludC4gSSBkYXJlIHNheSB3ZSBjYW4gd29y ZHNtaXRoIHNvbWV0aGluZy4NCg0KQWxzbywgSSBkb27igJl0IHF1aXRlIGdldCB3aGVyZSB5b3Xi gJlyZSBnb2luZyB3aXRoIHRoZSBsYXN0IHBhcmFncmFwaCBvZiB0aGF0IHNlY3Rpb24gKOKAnFRo ZXNlIHJlc3RyaWN0aW9ucyBkbyBub3QsIGhvd2V2ZXIsIG1lYW4gdGhhdCBhZGRlZCBpbmZvcm1h dGlvbiBpcw0KDQogICBjb21wbGV0ZWx5IGlnbm9yZWQgZm9yIHB1cnBvc2VzIG9mIHRoZSBiYXNl IHByb3RvY29sLuKAnSkuLi4NCg0KUmVhZCBvbiwgdGhlIHJlc3Qgb2YgdGhlIHBhcmFncmFwaCBk ZXNjcmliZXMgdGhlIGNhc2Ugd2hlcmUgbm90LiBCdXQgd2UgbWlnaHQgdGVsZWdyYXBoIHRoYXQg YmV0dGVyIGluIHRoZSBvcGVuaW5nIHNlbnRlbmNlLg0KDQoqIHJlZ2FyZGluZyB0aGUgbWFwcyBp biA0LjU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0 NC11c2FnZS0wMyNzZWN0aW9uLTQuNT4uIEluZm9ybWF0aW9uIFJlcHJlc2VudGF0aW9uOg0KSeKA mW0gYWZyYWlkIEkganVzdCBkb27igJl0IHJlYWxseSB1bmRlcnN0YW5kIHRoZSBwdXJwb3NlIG9m IHRoaXMgc2VjdGlvbiBhbmQgdGhlIG1hcHBpbmcgbm90YXRpb24uIEnigJltIGFzc3VtaW5nIHRo YXQgdGhlIG1hcHMgYXJlIHN1cHBvc2VkIHRvIG9mZmVyIGEgd2F5IG9mIGRlc2NyaWJpbmcgaG93 IGEgVExWIHJlbGF0ZXMgdG8gYSBtZXNzYWdlIG9yIGFuIGFkZHJlc3M/DQpJZiBzbywgd2h5IGRv ZXMgaXQgb25seSBtZW50aW9uIGV4dGVuc2lvbiB0eXBlcywgYnV0IG5vdCB0aGUgYmFzaXMgdHlw ZXM/DQoNCkl0IHNheXMgZXh0ZW5kZWQgdHlwZXMsIG1lYW5pbmcgdGhlIGNvbWJpbmF0aW9uIG9m IHRoZSB0d28uIEJ1dCBmdWxsIHR5cGUgd291bGQgYmUgYmV0dGVyLCBhcyBhbG1vc3QgZGVmaW5l ZCBpbiA1NDQ0LiBJbiBmYWN0IEkgdGhpbmsgd2Ugc2hvdWxkIGFkZCBhIGNvbW1lbnQgdG8gdGhl IG5vdGF0aW9uIHNlY3Rpb24uICg1NDQ0IHVzZXMgYSBzeW1ib2xpYyBuYW1lIHJhdGhlciB0aGFu IHRoZSBwaHJhc2UuKQ0KDQpPciBpcyBpdCBzdXBwb3NlZCB0byBiZSB1c2VkIHNvbWV0aGluZyBs aWtlIHRoaXM6DQoNCkJBU0VfVExWDQoNCk1lc3NhZ2U6DQooYmFzZV90bHZfZXh0ZW5zaW9uX3R5 cGVfMSkgLT4gKDIgb2N0ZXRzLCAidmFsdWUgYSB3aGVuIGNvbmRpdGlvbiB4IGlzIG1ldCIpDQoo YmFzZV90bHZfZXh0ZW5zaW9uX3R5cGVfMikgLT4gKDIgb2N0ZXRzLCAidmFsdWUgYiB3aGVuIGNv bmRpdGlvbiB5IGlzIG1ldCIpDQoNCj8gQWxzbywgSSBkb27igJl0IHF1aXRlIGdldCBob3cgdGhp cyB3b3VsZCBiZSB1c2VkIGluIGZ1dHVyZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucz8gT3IgYWlk IGluIGltcGxlbWVudGluZyBSRkM1NDQ0IHBhcnNlcnM/DQpBbiBleGFtcGxlIG9yIGEgY2xhcmlm aWNhdGlvbiB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwuDQoNCkl0J3MgYSB3YXkgb2YgbG9va2luZyBh dCB0aGluZ3MuIEJ1dCBub3QgdGhlIG9ubHkgb25lLCBpdCBnb2VzIG9uIHRvIGRpc2N1c3MgdmFy aWFudHMuIEkgdGhpbmsgaXQgbW9zdGx5IGNvbWVzIHVuZGVyIGhlYWRpbmcgb2YgaWYgdXNlZnVs IHVzZSBpdCwgaWYgbm90IHNraXAgaXQuIFdlJ2xsIHRha2UgYW5vdGhlciBsb29rLCBidXQgSSBk b24ndCB0aGluayB0aGlzIHdpbGwgZXZlciBiZSBlbGVtZW50YXJ5Lg0KDQoqIHJlZ2FyZGluZyA0 LjY8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11 c2FnZS0wMyNzZWN0aW9uLTQuNj4uIFRMVnM6DQpJbiBnZW5lcmFsLCBpdOKAmXMgbm90IGNsZWFy IGV2ZXJ5d2hlcmUgaW4gdGhlIHNlY3Rpb24gd2hldGhlciB5b3XigJlyZSB0YWxraW5nIHRvIFJG QzU0NDQgcGFyc2VyL2J1aWxkZXIgaW1wbGVtZW50b3JzIG9yIHByb3RvY29sIGRlc2lnbmVycy4N Cg0KDQogICBBIHByb3RvY29sIFNIT1VMRCB1c2UgYW4gZWZmaWNpZW50DQoNCiAgIHJlcHJlc2Vu dGF0aW9uLCBidXQgdGhpcyBpcyBhIHF1YWxpdHkgb2YgaW1wbGVtZW50YXRpb24gaXNzdWUuDQoN CknigJltIG5vdCBzdXJlIHdoZXJlIHlvdeKAmXJlIGdvaW5nIHdpdGggdGhlIGxhc3QgcGFydCBv ZiB0aGF0IHNlbnRlbmNlPyBJ4oCZZCByZXdvcmQgaXQgdG8gc29tZXRoaW5nIGxpa2Ug4oCeQSBw cm90b2NvbCBTSE9VTEQgdXNlIGFuIGVmZmljaWVudCByZXByZXNlbnRhdGlvbiwgYXZvaWRpbmcg dW5uZWNlc3NhcmlseSB2ZXJib3NlIHVzZSBvZiBUTFZzIGFuZCBleHRlbnNpb24gdHlwZXMuIEhv d2V2ZXIsIHRoZSBmaW5hbCBhcnJhbmdlbWVudCBpbiBhIG1lc3NhZ2UtIG9yIGFkZHJlc3NUTFYg YmxvY2sgaXMgIGEgcXVhbGl0eSBvZiBpbXBsZW1lbnRhdGlvbiBpc3N1ZeKAnCAoaW4gY2FzZSB0 aGF04oCZcyB3aGF0IHlvdSBtZWFudCkuDQoNCk5vLCB5b3UncmUgY29uc2lkZXJpbmcgdGhlIHBy b3RvY29sIGRlc2lnbi4gVGhpcyBpcyBjb25zaWRlcmluZyB0aGUgcHJvdG9jb2wgb2JqZWN0IHRo YXQgaW1wbGVtZW50cyB0aGUgcHJvdG9jb2wuIFRoZXJlIGlzbid0IGEgb25lIHRvIG9uZSBtYXBw aW5nIGZyb20gaW5mb3JtYXRpb24gdG8gcmVwcmVzZW50YXRpb24sIGl0J3MgdXAgdG8gdGhlIGlt cGxlbWVudGF0aW9uIHRvIGRvIGl0IGVmZmljaWVudGx5LiBEaWZmZXJlbnQgaW1wbGVtZW50YXRp b25zIG9mIHRoZSBzYW1lIHByb3RvY29sIHNwZWNpZmljYXRpb24gbWF5IGRvIGJldHRlciBvciB3 b3JzZSBoZXJlLiAoVHJpdmlhbCBjYXNlLCBhbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBjaG9vc2Ug dG8gbmV2ZXIgY29tcHJlc3MgYWRkcmVzc2VzLiBCYWQgaWRlYSwgYnV0IGxlZ2FsLikNCg0KQW5k IHRoZW46DQoNCg0KICAgQQ0KDQogICBwcm90b2NvbCBNVVNUIHJlY29nbml6ZSBhbnkgcGVybWl0 dGVkIHJlcHJlc2VudGF0aW9uIG9mIHRoZQ0KDQogICBpbmZvcm1hdGlvbjsgZXZlbiBpZiBpdCBj aG9vc2VzIHRvIChmb3IgZXhhbXBsZSkgb25seSB1c2UgbXVsdGl2YWx1ZQ0KDQogICBUTFZzLCBp dCBNVVNUIHJlY29nbml6ZSBzaW5nbGUgdmFsdWUgVExWcyAoYW5kIHZpY2UgdmVyc2EpLg0KDQri gKYgSSB0aG91Z2h0IHByb3RvY29scyB3ZXJlbuKAmXQgc3VwcG9zZWQgdG8gc3BlY2lmeSB3aGV0 aGVyIGEgVExWIGlzIGFycmFuZ2VkIChmb3IgZXhhbXBsZSkgYXMgYSBtdWx0aXZhbHVlIFRMVj8h DQoNCkltcGxlbWVudGF0aW9uIGFnYWluLCBub3QgZGVzaWduLg0KDQpBbmQgc28sIHNpbmNlIGEg cHJvdG9jb2wgc2hvdWxkbid0IGJlIGNvbmNlcm5lZCB3aXRoIG11bHRpdmFsdWUgVExWcyBhbmQg dGhlIGxpa2UsIHdvdWxkbuKAmXQgaXQgYmUgdGhlICpSRkM1NDQ0IGltcGxlbWVudGF0aW9uKiB0 aGF0IE1VU1QgcmVjb2duaXplIGFueSBwZXJtaXR0ZWQgcmVwcmVzZW50YXRpb24/DQoNCllvdSdy ZSBhc3N1bWluZyB0aGF0IHRoZXJlIGlzIGFuIFJGQyA1NDQ0IGltcGxlbWVudGF0aW9uLiBUaGF0 J3MgdGhlIHNhbWUgd2F5IHRvIHdvcmsgaWYgeW91IHBsYW4gdG8gaW1wbGVtZW50IG1vcmUgdGhh biBvbmUgcHJvdG9jb2wuIEJ1dCBub3RoaW5nIHNheXMgeW91IGhhdmUgdG8gZG8gaXQgdGhhdCB3 YXkuIFRoZSBhcmNoaXRlY3R1cmUgZGVmaW5lZCBieSA1NDk4IGFkbWl0cyBvZiB0aGUgbXVsdGlw bGV4ZXIgYW5kIHByb3RvY29scywgYW5kIHRodXMgdGhlc2UgYXJlIHJ1bGVzIG9uIHRoZSBwcm90 b2NvbC4gSWYgcHJvdG9jb2xzIGRlbGVnYXRlIGFsbCB0aGVpciBjb21tb24gd29yayB0byBzb21l dGhpbmcgKHBhcnNlci9jcmVhdG9yKSB0aGVuIGl0IGluaGVyaXRzIHRob3NlIHJlc3RyaWN0aW9u cywgYnV0IHRoYXQncyBub3QgZGVmaW5lZCwgYW5kIHdlIGNhbid0IGFzc3VtZSBpdC4NCg0KT3Ig aXMgdGhpcyBwYXJhZ3JhcGggcmVhbGx5IGp1c3QgYSBjb21wbGljYXRlZCB3YXkgb2Ygc2F5aW5n IOKAnmFzIGEgcHJvdG9jb2wgZGVzaWduZXIsIG1ha2Ugc3VyZSB0byBub3Qgc3BlY2lmeS9yZWx5 IG9uIHRoaW5ncyBsaWtlIChmb3IgZXhhbXBsZSkgbXVsdGl2YWx1ZSBUTFZzLCBzaW5jZSB5b3Vy IG1lc3NhZ2VzIGhhdmUgdG8gd29yayB3aXRoICphbnkqIHJlcHJlc2VudGF0aW9u4oCcPyBJZiBz bywgSSB0aGluayB0aGF0IHNob3VsZCBiZSBkb25lIGluIGEgbGVzcyBjb21wbGljYXRlZCBmYXNo aW9uIChzZWUgYmVsb3cpLg0KDQoqIHJlZ2FyZGluZyA1PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi01Pi4gU3RydWN0 dXJlOg0KU2luY2UgdGhpcyBzZWN0aW9uIHRhbGtzIGEgbG90IGFib3V0IGZsYWdzLCBpdOKAmWQg YmUgbmljZSBpZiBpdHMgdGl0bGUgcmVwcmVzZW50ZWQgdGhhdC4gTWF5YmUgY29uc2lkZXIgcmVu YW1pbmcgaXQgdG8g4oCeU3RydWN0dXJlIGFuZCBGbGFnc+KAnCBvciBzbz8NCg0KSSBtb3N0bHkg ZG9uJ3QgYWdyZWUuIFN0cnVjdHVyZSBpcyB0aGUgc3ViamVjdCwgZmxhZ3MgYXJlIGEgZGV0YWls Lg0KDQoqIGZyb20gNi4xPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1h bmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi02LjE+LiBBZGRyZXNzIEJsb2NrIENvbXByZXNz aW9uOg0KDQoNCiAgIENvbXByZXNzaW9uIG9mIGFkZHJlc3NlcyBpbiBhbiBBZGRyZXNzIEJsb2Nr IGNvbnNpZGVycyBhZGRyZXNzZXMgdG8NCg0KICAgY29uc2lzdCBvZiBhIEhlYWQsIGEgTWlkLCBh bmQgYSBUYWlsLCB3aGVyZSBhbGwgYWRkcmVzc2VzIGluIGFuDQoNCiAgIEFkZHJlc3MgQmxvY2sg aGF2ZSB0aGUgc2FtZSBIZWFkIGFuZCBUYWlsLCBidXQgZGlmZmVyZW50IE1pZHMuDQoNCg0KSeKA mWQgZmluZCB0aGlzIHNlbnRlbmNlIGVhc2llciB0byByZWFkIGlmIGl0IHN0YXJ0ZWQgd2l0aCDi gJxDb21wcmVzc2lvbiBvZiBhZGRyZXNzZXMgaW4gYW4gQWRkcmVzcyBCbG9jayBpcyBwb3NzaWJs ZSB3aGVuIGFkZHJlc3NlcyBjb25zaXN0IG9mIGEgSGVhZCwgYSBNaWQgW+KApl3igJ0uDQoNCk5v LiBUaGF0J3MgbWlzc2luZyB0aGUgcG9pbnQgYW5kIG1pc2xlYWRpbmcuIEFkZHJlc3NlcyBhcmUg YWx3YXlzIGNvbnNpZGVyZWQgdG8gaGF2ZSB0aGUgaGVhZC9taWQvdGFpbCBmb3JtYXQuIENvbXBy ZXNzaW9uIGlzIHBvc3NpYmxlIGlmIGVpdGhlciB0aGUgaGVhZCBvciB0YWlsIChvciBib3RoKSBp cyBub24tZW1wdHkuDQoNCiogZnJvbSA2LjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTYuMT4uIEFkZHJlc3MgQmxv Y2sgQ29tcHJlc3Npb246DQoNCg0KDQogICBQdXR0aW5nIGFkZHJlc3NlcyBpbnRvIGEgbWVzc2Fn ZSBlZmZpY2llbnRseSBhbHNvIGhhcyB0byBpbmNsdWRlOg0KDQoNCldoeSDigJ5oYXMgdG/igJw/ IEnigJlkIHRoaW5rIHRoYXQgd291bGQgYmUgYSDigJ5tYXnigJwuIE11bHRpcGxlIEFkcmVzcyBC bG9ja3MgYW5kL29yIHJlb3JkZXJpbmcgZG9u4oCZdCBpbmNyZWFzZSBlZmZpY2llbmN5IGluIGFs bCBwb3NzaWJsZSBjYXNlcy4uLg0KDQpJIHRoaW5rIHRoYXQncyB0aGUgd3JvbmcgY2hhbmdlLiBS YXRoZXIgImluY2x1ZGUiIHNob3VsZCBiZSAiY29uc2lkZXIiLg0KDQoqIGZyb20gNi4yPGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMj c2VjdGlvbi02LjI+LiBUTFZzOg0KDQogICAgICBbLi4uXSBUaGlzIGlzIGV2ZW4gcG9zc2libGUg aWYgdGhlIE1QUiBUTFYgc3BlY2lmaWVkIGluDQoNCiAgICAgIE9MU1J2MiBbUkZDNzE4MTxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzE4MT5dIGlzIGFkZGVkOyBidXQgaXQgaXMgbm90 IHBvc3NpYmxlLCBpbiBnZW5lcmFsLCBpZg0KDQogICAgICB0aGUgTElOS19NRVRSSUMgVExWIGlz IGFsc28gYWRkZWQuDQoNCldoeSBpcyBpdCBub3QgcG9zc2libGUgZm9yIHRoZSBsYXR0ZXI/IElm IHRoYXQgY291bGQgYmUgZXhwbGFpbmVkL2hpbnRlZCBhdCBpbiBhIGhhbGYgc2VudGVuY2UsIEkg dGhpbmsgaXTigJlkIGJlIGhlbHBmdWwgaW5mb3JtYXRpb24gdG8gaGF2ZSBpbiB0aGUgZHJhZnQu DQoNClRoYXQncyB2ZXJ5IGhhcmQsIGFuZCBub3QganVzdCBiZWNhdXNlIGl0J3MgYSBuZWdhdGl2 ZS4gSXQncyByZWFsbHkgYW4gb2JzZXJ2YXRpb24gdGhhdCBtb3RpdmF0ZXMgdGhlIGR1c2N1c3Np b24uIEEgaGFsZiBzZW50ZW5jZSB3b3VsZCBJIHRoaW5rIGNvbmZ1c2UgbW9yZSB0aGFuIGl0IGVu bGlnaHRlbnMgKGl0J3MgYmVjYXVzZSB5b3UgaGF2ZSB0b28gbWFueSBjb25zdHJhaW50cyB0byBz YXRpc2Z5IGF0IG9uY2UgLSBJIGRvdWJ0IHRoYXQgaGVscGVkKS4NCg0KDQogICAgICBJbiBhIHR5 cGljYWwgY2FzZSB3aGVyZSBhDQoNCiAgICAgIExJTktfU1RBVFVTIFRMViB1c2VzIG9ubHkgdGhl IFZhbHVlcyBIRUFSRCBhbmQgU1lNTUVUUklDLCB3aXRoDQoNCiAgICAgIGVub3VnaCBhZGRyZXNz ZXMsIHNvcnRlZCBhcHByb3ByaWF0ZWx5LCB0d28gc2luZ2xlIHZhbHVlIFRMVnMgY2FuDQoNCiAg ICAgIGJlIG1vcmUgZWZmaWNpZW50IHRoYW4gb25lIG11bHRpdmFsdWUgVExWLg0KDQpTYW1lIHRo aW5nOiB3aHk/DQoNCkhlcmUgSSB0aGluayB0aGlzIHNob3VsZCBiZSBvYnZpb3VzIHRvIGFueW9u ZSB3aG8gaGFzIGxvb2tlZCBhdCA1NDQ0Lg0KDQoqIHJlZ2FyZGluZyB0aGUgc2Vjb25kIHBhcmFn cmFwaCBmcm9tIDYuMzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5l dC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi4zPi4gVExWIFZhbHVlcywgaS5lLg0KDQoNCg0K ICAgVGhpcyBhcHByb2FjaCB3YXMgc3BlY2lmaWVkIGluIFtSRkM3MTg4PGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3MTg4Pl0sIGFuZCByZXF1aXJlZCBmb3IgcHJvdG9jb2xzDQoNCiAg IHRoYXQgZXh0ZW5kIFtSRkM2MTMwPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MTMw Pl0gYW5kIFtSRkM3MTgxPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTgxPl0uICBJ dCBpcyBoZXJlIFJFQ09NTUVOREVEIHRoYXQNCg0KICAgdGhpcyBhcHByb2FjaCBpcyBmb2xsb3dl ZCB3aGVuIGRlZmluaW5nIGFueSBBZGRyZXNzIEJsb2NrIFRMViB0aGF0DQoNCiAgIG1heSBiZSB1 c2VkIGJ5IGEgcHJvdG9jb2wgdXNpbmcgW1JGQzU0NDQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzU0NDQ+XS4NCg0KVGhlIHRlcm0g4oCedGhpcyBhcHByb2FjaOKAnCBjb25mdXNlZCBt ZSwgc2luY2UgSSBpbml0aWFsbHkgIHRob3VnaHQgaXQgbWVhbnQg4oCedGhlIGFwcHJvYWNoIGlz IHRvIHVzZSBVTlNQRUNJRklFRCBpbiBhIHdheSB0aGF0IG1ha2VzIHNlbnNl4oCcIHJhdGhlciB0 aGFuIOKAnnRoZSBhcHByb2FjaCBpcyB0byB1c2UgVU5TUEVDSUZJRUTigJwuIE1heWJlIHRoYXQg Y291bGQgYmUgcmV3b3JkZWQgdG8gc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZg0KVGhlIFVO U1BFQ0lGSUVEIFRMViBhbmQgaXRzIHVzYWdlIHdhcyBzcGVjaWZpZWQgaW4gW1JGQzcxODhd4oCm DQo/DQoNCk5vLiBUaGVyZSBpcyBubyBVTlNQRUNJRklFRCBUTFYuIFRoZXJlIGlzIGEgcmVjb21t ZW5kYXRpb24gdG8gaW5jbHVkZSBhbiBVTlNQRUNJRklFRCB2YWx1ZSBpbiBhIFRMVi4gQnV0IHJl YWxseSwgd2UndmUgZGVzY3JpYmVkIHRoaXMgb25jZSBpbiA3MTg4LCBpdCdzIHRoZXJlIHRvIHJl YWQuDQoNCiogcmVnYXJkaW5nIDYuMzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi4zPi4gVExWIFZhbHVlczoNClRo ZSBzZWNvbmQgcGFyYWdyYXBoIGlzIGEgYml0IGNvbmZ1c2luZyBhbmQgc2VlbXMgdG8gZXhwbGFp bmcgcm9naGx5IHRoZSBzYW1lIHRoaW5ncyBhcyB0aGUgZm91cnRoIHBhcmFncmFwaHMuIEnigJlk IHByb3Bvc2UgdG8gbWVyZ2UgdGhlIHNlY29uZCBpbnRvIHRoZSBmb3VydGguDQoNCkknbSBub3Qg c3VyZSBJIGV4YWN0bHkgYWdyZWUsIGJ1dCB0aGUgb3JkZXJpbmcgaW4gdGhhdCBzZWN0aW9uIGNv dWxkIGJlIGltcHJvdmVkLg0KDQoqIGZyb20gNi40PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi02LjQ+LiBBdXRvbWF0 aW9uOg0KDQoNCiAgIFRoZSBwb3NzaWJsZSBnYWluIGRlcGVuZHMgb24gdGhlIGVmZmljaWVuY3kN Cg0KICAgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UgY3JlYXRpb24sDQoNCnRoZSB0ZXJtIOKAnnRo ZSBvcmlnaW5hbCBtZXNzYWdlIGNyZWF0aW9u4oCcIHNlZW1zIGEgYml0IGFtYmlndW91c+KAkyBk b2VzIHRoaXMgcmVmZXIgdG8gdGhlIG1lc3NhZ2UgYXMgY3JlYXRlZCBieSBhbiBSRkM1NDQ0IG1l c3NhZ2UgYnVpbGRlciBpbXBsZW1lbnRhdGlvbj8NCg0KWWVzLg0KDQpBZGRpdGlvbmFsbHksIEkn bSBjb25jZXJuZWQgYWJvdXQgdHdvIHRoaW5ncyB0aGF0ICphcmVu4oCZdCogaW4gdGhlIGRyYWZ0 Og0KDQoqICBTb21lIG9mIHRoZSBBT0RWdjIgY28tYXV0aG9ycyBhbmQgbWUgaGF2ZSBhc2tlZCBm b3IgYSBsaXN0IG9mIOKAnmFzIGEgcHJvdG9jb2wsIHlvdSBjYW4gc2V0IGFsbCBvZiB0aGVzZSBm aWVsZHMgb2YgYSBtZXNzYWdlLCBidXQgcGxlYXNlIGxlYXZlIHRoZSByZXN0IGFsb25l4oCcLCB3 aGljaCB3b3VsZOKAmXZlIHNhdmVkIHVzIG1hbnkgaG91cnMgb2YgZGlzY3Vzc2lvbnMgKGFuZCBI ZW5uaW5nIGEgbG90IG9mIHRpbWUgc3BlbnQgZXhwbGFpbmluZyB0aGVzZSB0aGluZ3PigKYpLiBU aGVzZSByZXF1ZXN0cyBoYXZlIGJlZW4gbWV0IHdpdGggYSByZWZ1c2FsIHRvIHNwZWNpZnkgYSBj b25jcmV0ZSBBUEksIGFzIHN1Y2ggYW4gZWZmb3J0IGlzIGRlcGVuZGVudCBvbiBvdXRzaWRlIGZh Y3RvcnMgc3VjaCBhcyBwcm9ncmFtbWluZyBsYW5ndWFnZSBvciBzb2Z0d2FyZSBhcmNoaXRlY3R1 cmUuIEkgYWdyZWUgd2l0aCB0aGlzIG5vdGlvbiwgYnV0IGEgcHJvZ3JhbW1pbmctbGFuZ3VhZ2Ug ZGVwZW5kZW50IEFQSSBpcyBub3Qgd2hhdCB3ZeKAmXZlIGFza2VkIGZvci4gSeKAmXZlIHRyaWVk IHRvIHN1cHBseSBhIHNrZXRjaCBvZiB3aGF0IEkgZGlkIGFzayBmb3IgaW4gWzFdLCBidXQgdW5m b3J0dW5hdGVseSBJIGRpZG7igJl0IGdldCBhbiBhbnN3ZXIgKGFuZCBhcyBmYXIgYXMgSSBjYW4g c2VlIGl0LCB0aGUgZHJhZnQgd2FzbuKAmXQgY2hhbmdlZCBlaXRoZXIpLiBJIHN0aWxsIHRoaW5r IHRoYXQgc3VjaCBhIGxpc3QsIGluIHdoYXRldmVyIGZvcm0sIHdvdWxkIGJlIHZlcnkgaGVscGZ1 bCBmb3IgZnV0dXJlIEludGVybmV0LURyYWZ0IGF1dGhvcnMgYW5kIEkgYWxzbyB0aGluayB0aGlz IHJlcXVlc3QgaXMgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBpbnRlbnRpb25zIHN0YXRlZCBpbiAx LjEgSGlzdG9yeSBhbmQgUHVycG9zZSwgYW5kIEkgdGhpbmsgaXQgc2hvdWxkIGJlIGluY2x1ZGVk IGluIHRoZSBkb2N1bWVudC4NCg0KTm8uIFRoZXJlIGFyZSBtYW55IHJlYXNvbnMgd2h5IHdlJ3Jl IGp1c3Qgbm90IHRvdWNoaW5nIHRoaXMgb25lLg0KDQpPbmUgaXMgdGhhdCBsYW5ndWFnZSBpbmRl cGVuZGVuY2UgaXMgYSBtaXJhZ2UuIEhvdyB5b3UgZ28gYWJvdXQgdGhpbmdzIGlzIGNvbXBsZXRl bHkgZGlmZmVyZW50IGluLCBmb3IgZXhhbXBsZSBhbiBvYmplY3Qgb3JpZW50ZWQgbGFuZ3VhZ2Ug dGhhbiBvbmUgdGhhdCBpc24ndC4gU2VjdGlvbiA0LjUgc2hvd3MgdGhhdCB0aGVyZSBhcmUgcXVp dGUgZGlmZmVyZW50IHdheXMgb2YgZG9pbmcgdGhpbmdzIGV2ZW4gZ2l2ZW4gYSBkZWNpc2lvbiB0 byB1c2UgYSBtYXAgYXBwcm9hY2gsIGFuZCB0aGVyZSBhcmUgb3RoZXIgYXBwcm9hY2hlcyB0aGFu IHRoYXQuIEl0IHdvdWxkIGJlIHdyb25nIGFuZCBiZXlvbmQgb3VyIGNvbXBldGVuY2UgdG8gc3Vn Z2VzdCBvbmUgb2YgdGhlc2UgYXMgImJlc3QiLiBUaGVyZSdzIHJlYXNvbnMgdGhlIElFVEYgZG9l c24ndCBkbyB0aGlzLCBhbmQgdGhhdCdzIG9uZS4NCg0KUGx1cywgZnJhbmtseSwgdGhlIHdvcmsg aXQgd291bGQgdGFrZSBpcyBiZXlvbmQgd2hhdCB3ZSBjaG9vc2UgdG8gc3BlbmQuDQoNCg0KPFNw ZWFraW5nIGFzIGEgV0cgUGFydGljaXBhbnQ+DQoNCkknbSBjb25mdXNlZCAod2hpY2ggaXMgYW4g YWx0b2dldGhlciB0b28gY29tbW9uIG9jY3VycmVuY2UgdGhlc2UgZGF5cykuIEkgZ2V0IHRoYXQg d2UgZG9uJ3Qgd2FudCB0byBzcGVjaWZ5IGFuIEFQSS4gQnV0IEkgdGhpbmsgdGhlIGRpc2N1c3Np b24gYWJvdXQgZmllbGRzIGEgcHJvdG9jb2wgY2FuIGFuZCBjYW4ndCB0b3VjaCBpbiBhIG1lc3Nh Z2VzIGlzIGEgZ29vZCB0aGluZyAtIGFuZCBpdCdzIG9uZSBzcG90IHdoZXJlIEksIHRvbywgZmlu ZCB0aGUgZG9jdW1lbnQgd2FudGluZy4NCg0KVG8gcGFyYXBocmFzZSBzb21ldGhpbmcgSSd2ZSBz YWlkIGJlZm9yZSwgSSBiZWxpZXZlIHRoYXQgUkZDIDU0NDQgY2hhbmdlcyB0aGUgcmVsYXRpb25z aGlwIHRoYXQgYSByb3V0aW5nIHByb3RvY29sIGhhcyB3aXRoIGFuICJpbnRlcmZhY2UiLiBJJ20g bm90IGNvbW1lbnRpbmcgb24gd2hldGhlciBvciBub3QgdGhhdCdzIGEgZ29vZCB0aGluZywgb3Ig YSBiYWQgdGhpbmcgLSBqdXN0IHRoYXQgaXQgZG9lcyBjaGFuZ2UgdGhlIHJlbGF0aW9uc2hpcC4g VGhpcyBjaGFuZ2UgaGFzIGJlZW4gYXQgdGhlIHJvb3Qgb2Ygc29tZSBvZiB0aGUgbG9uZy1ydW5u aW5nIGRpc2N1c3Npb25zIGFzIHRvIHdoZXRoZXIgcHJvdG9jb2xzIHVuZGVyIGRldmVsb3BtZW50 IHdlcmUgUkZDIDU0NDQgY29tcGxpYW50IG9yIG5vdC4gVGhlIGdvYWwgb2YgdGhpcyBkb2N1bWVu dCBiZWluZyB0byBlbGltaW5hdGUgKGl0J3MgYSBnb2FsLCBwcm9iYWJseSBub3QgcmVhY2hhYmxl KSB0aG9zZSBkaXNjdXNzaW9ucywgSSdkIGxpa2UgdG8gc2VlIHRoYXQgaW5mb3JtYXRpb24gaW4g dGhlIGRvY3VtZW50IGluIHNvbWUgZm9ybS4NCg0KSSdtIGludGVyZXN0ZWQgaW4gc2VlaW5nIHRo aXMgZG9jdW1lbnQgcHJvZ3Jlc3MsIGFuZCBldmVudHVhbGx5IGJlIHB1Ymxpc2hlZC4gSSB0aGlu ayBpdCB3aWxsIGhlbHAgZnV0dXJlIHByb3RvY29sIGRlc2lnbmVycyB0byBiZXR0ZXIgdXNlIFJG QyA1NDQ0LiBCdXQgSSB3b3VsZCBsaWtlIHRvIHNlZSAqc29tZXRoaW5nKiBhbG9uZyB0aGUgbGlu ZXMgb2Ygd2hhdCBMb3R0ZSBpcyByZXF1ZXN0aW5nLCBhcyBJIHRoaW5rIGl0IHdpbGwgaW1wcm92 ZSB0aGUgZG9jLg0KDQpSZWdhcmRzLA0KU3Rhbg0KDQoNCg0KKiBBcyB0aGUgZXhhY3QgcnVsZXMg Zm9yIHVzaW5nL3NldHRpbmcgdGhlIGhvcCBjb3VudCAmIGhvcC1saW1pdCBmaWVsZHMgYXJlIGN1 cnJlbnRseSBiZWluZyBkaXNjdXNzZWQgdy8gcmVnYXJkIHRvIEFPRFZ2MiBpbiBhbm90aGVyIHRo cmVhZCBbMl3igJMgc2hvdWxkIGEgZGVmaW5pdGl2ZSBhbnN3ZXIgdG8gdGhhdCBxdWVzdGlvbiBi ZSBwYXJ0IG9mIDU0NDQtdXNhZ2U/DQoNCllvdSBkb24ndCB3YW50IHRoYXQuIEJlY2F1c2UgaWYg d2UgZGlkIHNwZWNpZnkgdGhhdCB5b3UnZCBmaW5kIHlvdXJzZWxmIG1vcmUgY29uc3RyYWluZWQg dGhhbiB5b3Ugd2FudCB0byBiZS4gVGhlcmUgaXMgYSBkZXNpZ24gaW50ZW50IGRlc2NyaWJlZCBp biA1NDQ0LCBidXQgaXQgYXNzdW1lcyBpbW11dGFibGUgbWVzc2FnZXMuIFdoaWNoIHlvdSBkb24n dCB3YW50LiBSZWFsbHksIHdlJ3JlIGRvaW5nIHlvdSBhIGZhdm91ciBieSBub3QgaW1wb3Npbmcg b24geW91Lg0KDQpCZXN0IHJlZ2FyZHMsDQpMb3R0ZQ0KDQpbMV0gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21zZzE4MDgyLmh0bWwNClsyXSBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTg2NzQu aHRtbA0KDQoNCkFtIDA2LjA0LjIwMTYgdW0gMTk6MTQgc2NocmllYiBKdXN0aW4gRGVhbiA8YmVi ZW1hc3RlckBnbWFpbC5jb208bWFpbHRvOmJlYmVtYXN0ZXJAZ21haWwuY29tPj46DQoNClRoZSBj aGFpcnMgYWdyZWUgdGhhdCBhIDMgd2VlayBXR0xDIGlzIGFwcHJvcHJpYXRlLiAgRXZlcnlvbmUg cGxlYXNlIHJlYWQgdGhlIGRyYWZ0IGVhcmx5IGFuZCBnZXQgY29tbWVudHMgaW4gZWFybHkgc28g dGhhdCB0aGV5IGNhbiBiZSBhZGRyZXNzZWQgd2l0aGluIHRoZSBsYXN0IGNhbGwgcGVyaW9kLg0K DQpKdXN0aW4NCg0KT24gV2VkLCBBcHIgNiwgMjAxNiBhdCA3OjQwIEFNLCBEZWFybG92ZSwgQ2hy aXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlz LmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQpPYnZpb3VzbHkgKzEgdG8gdGhlIHJl cXVlc3QgZm9yIFdHTEMuDQoNCldpdGggcmVnYXJkIHRvIHdoYXQncyBjaGFuZ2VkLCB0ZWNobmlj YWxseSB0aGUgb25seSBzaWduaWZpY2FudCB0aGluZyBpcyB0byBtYWtlIGl0IGNsZWFyIHRoYXQg aWYgYSBwcm90b2NvbCBkZWxpdmVycyBhIG1lc3NhZ2UgdG8gdGhlIG11bHRpcGxleGVyLCB0aGUg bXVsdGlwbGV4ZXIgbXVzdCBwYXNzIGl0IG9uIHVuY2hhbmdlZCB0byB0aGUgcHJvdG9jb2wgKGFu b3RoZXIgaW5zdGFuY2Ugb2YsIGF0IGFub3RoZXIgcm91dGVyKSB1bmNoYW5nZWQuIFdpdGhvdXQg dGhhdCBub3RoaW5nIHRoYXQgdGhlIHByb3RvY29sIGl0c2VsZiBjaG9vc2VzIHRvIGRvIHdpdGgg cmVnYXJkIHRvIHNlY3VyaXR5IG1ha2VzIHNlbnNlLiBUaG91Z2ggdGhlIHByb3RvY29sIGNhbiBh bHRlcm5hdGl2ZWx5IGxldCB0aGUgbXVsdGlwbGV4ZXIgZG8gdGhlIHNlY3VyaXR5LCA3MTgyIGNh biBiZSBpbXBsZW1lbnRlZCBpbiBlaXRoZXIgd2F5LiBUaGlzIGlzbid0IHJlYWxseSBuZXcsIGJ1 dCBpdCB3YXNuJ3QgZm9ybWFsbHkgc3BlbGxlZCBvdXQuIEl0J3MgcHJlc2VudGVkIGFzIHBhcnQg b2Ygc3BlbGxpbmcgb3V0IG11bHRpcGxleGVyIHJ1bGVzIG1vcmUgY2FyZWZ1bGx5Lg0KDQpCdXQg d2hhdCBhYm91dCBtZXNzYWdlIG9wdGltaXNhdGlvbj8gVGhhdCdzIGEgZnVuY3Rpb24gb2YgY29u c3RydWN0aW5nIGEgNTQ0NCBtZXNzYWdlLCBub3QgdGhlIG11bHRpcGxleGVyLCBhbmQgaXMgZG93 biB0byB0aGF0IDU0NDQgaW5jbHVkZXMgdHdvIHRoaW5ncyAtIHBhY2tldC9tZXNzYWdlIHN0cnVj dHVyZSAoYW5kIGltcGxpY2l0bHksIGFuZCBpbiBwcmV0dHkgbXVjaCBhbnkgaW1wbGVtZW50YXRp b24gSSB3b3VsZCBleHBlY3QgdG8gc2VlLCBhIHBhcnNlciBhbmQgYnVpbGRlciBmb3IgdGhhdCBz dHJ1Y3R1cmUpIGFuZCB0aGUgbXVsdGlwbGV4ZXIuIFNvIHdlIHRvb2sgdGhlIG9wcG9ydHVuaXR5 IHRvIHNlcGFyYXRlIG91dCBtb3JlIGNsZWFybHkgYSBkaXNjdXNzaW9uIG9mIHRoZSB0d28sIHdo aWNoIHdlIHRoaW5rIHdpbGwgYmUgaGVscGZ1bC4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3Zl DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln ZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAy NDIxOTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFy bG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+ DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xv Z3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJh ZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVt cyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBX YWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFy aywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bWFu ZXQtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBVbHJpY2ggSGVyYmVyZw0KU2VudDog MDUgQXByaWwgMjAxNiAyMDowOA0KVG86IG1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRm Lm9yZz4NClN1YmplY3Q6IFttYW5ldF0gV0dMQyByZXF1ZXN0IGZvciBkcmFmdC1pZXRmLW1hbmV0 LXJmYzU0NDQtdXNhZ2UtMDMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRl IG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJv bSB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNs aWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb2xsb3cg dGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5z dHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KKioq IFdBUk5JTkcgKioqDQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBm cm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbi4NCg0KDQpIaSwNCg0KQXMgeW91IGhhdmUgc2Vl biwgd2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgcmV2aXNpb24gb2YgNTQ0NC11c2FnZS4gVGhlIGF1 dGhvcnMgZmVlbCBjb21mb3J0YWJsZSB0aGF0IHdlIGhhdmUgYWRkcmVzc2VkIGFsbCBpc3N1ZXMg YnkgdGhpcyB2ZXJzaW9uLCBhbmQgd291bGQgbGlrZSB0byBhc2sgdGhlIFdHIGNoYWlycyB0byBp c3N1ZSBhIFdHTEMgb24gdGhpcyBkb2N1bWVudC4gV2hpbGUgaXQgaXMgYSBmYWlybHkgc2hvcnQg ZG9jdW1lbnQsIGdpdmVuIHRoYXQgaXQgaXMgSUVURiB3ZWVrIGZvciBzb21lLCB3ZSdkIHN1Z2dl c3QgdGhhdCBhIDMtNCB3ZWVrIFdHTEMgd291bGQgYmUgYXBwcm9wcmlhdGUuDQoNCkJlc3QgcmVn YXJkcw0KVWxyaWNoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqDQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlh bCB0byB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBm cm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4NCllvdSBzaG91bGQgbm90IGNv cHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3INCmRpc3RyaWJ1 dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uDQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGlu ZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGll dGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWFuZXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1h bmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5l dA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFu ZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCg0KDQoNCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ADAB6GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30N CnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1HQjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+T2YgY291cnNlIGl0IG1ha2VzIHNlbnNlIC0gYmVjYXVzZSBpdOKAmXMgYmVlbiBkb25l IGFzIEkgbm90ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgbXVsdGlwbGV4ZXIgZG9lc27igJl0IGFjdHVhbGx5 IGhhdmUgdG8gcGFyc2UgbWVzc2FnZXMsIGl0IG5lZWRzIHRvIGdyb3VwIHRoZW0gaW50byBwYWNr ZXRzLiBJdCBuZWVkcyB0byBiZSBhYmxlIHRvIHBhcnNlIGEgcGFja2V0IGRvd24gdG8g4oCcaGVy ZSBhcmUgdGhlIG1lc3NhZ2Vz4oCdDQogYW5kIGRlbGl2ZXIgdGhlbS4gVGhlIG1lc3NhZ2VzIGNh biBiZSBzaW1wbGUgYmxvYnMuIEZvciB0aGF0IGl0IG5lZWRzIHRoZSBtZXNzYWdlIHR5cGUgLSBj b252ZW5pZW50bHkgcGxhY2VkIHVwIGZyb250IGluIHRoZSBtZXNzYWdlIGhlYWRlciB0byBiZSBy ZWFkIC0gYW5kIHRoZSBtZXNzYWdlIGxlbmd0aCAtIGRpdHRvLiBUaGUgcGFyc2luZyBvZiB0aGUg bWVzc2FnZXMgaXMgYSBwcm90b2NvbCBwcm9ibGVtLiBJZiBqdXN0IGltcGxlbWVudGluZw0KIG9u ZSBwcm90b2NvbCBpdCBjb3VsZCBpbmNvcnBvcmF0ZSB0aGUgcGFyc2VyLiBJZiBpbXBsZW1lbnRp bmcgbXVsdGlwbGUgcHJvdG9jb2xzIHlvdSBjYW4gY3JlYXRlIGFuIGluZGVwZW5kZW50IHBhcnNl ci4gT3IgeW91IG1heSBkbyB0aGUgbGF0dGVyIGV2ZW4gaW4gdGhlIGZvcm1lciBjYXNlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+QW5kIGV2ZW4gaWYgd2UgYWxsIGltcGxlbWVudGVkIGluZGVwZW5kZW50IHBhcnNlcnMg dGhleSBjYW4gYmUgcXVpdGUgZGlmZmVyZW50LiBBcyBpbmRlZWQgdGhlIG9uZXMgdGhhdCBleGlz dCBhcmUuIE5vdCBqdXN0IG1lcmVseSBpbiBBUEkuIEZvciBleGFtcGxlIEkgY291bGQNCiB0dXJu IGEgbWVzc2FnZSBpbnRvIGEgc2V0IG9mIG9iamVjdHMuIE9yIEkgY291bGQgcHJvdmlkZSBwb2lu dGVycyBpbnRvIHRoZSBkYXRhIGJsb2NrIHRoYXQgcmVwcmVzZW50cyB0aGUgbWVzc2FnZS4gJm5i c3A7QW5kIG90aGVyIGFwcHJvYWNoZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MDA3RTdFIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmlu Y2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJv cmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOyYjNDM7NDQgKDApMTI0NSAyNDIxOTQgJm5i c3A7fCAmbmJzcDs8Yj5FOg0KPC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+PGJyPg0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQg SW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBD aGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lz dGVtcy5jb20vYWkiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5j b20vYWk8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBB cHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZh bXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2gg UGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU3RhbiBSYXRsaWZm IFttYWlsdG86cmF0bGlmZnN0YW5AZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE4IEFw cmlsIDIwMTYgMTQ6MTg8YnI+DQo8Yj5Ubzo8L2I+IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp PGJyPg0KPGI+Q2M6PC9iPiBDaHJpc3RvcGhlciBEZWFybG92ZTsgbWFuZXRAaWV0Zi5vcmc7IENo cmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFuZXRdIFdHTEMg cmVxdWVzdCBmb3IgZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAy LjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0 ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklO RyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3Rl eHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRz aWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3Ig dGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhl ciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3Ig cmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVn YXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9v ayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8v aW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRz L0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBo cmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0 eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFp bHMucGRmIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBcHIgMTgsIDIwMTYgYXQg OToxMyBBTSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpj aHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzLmRlYXJs b3ZlQGJhZXN5c3RlbXMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkFzIGhhcyBiZWVuIHBvaW50ZWQgb3V0IHRvIG1lLCBzb21lIGltcGxl bWVudGF0aW9ucyBkb27igJl0IGRvIHRoaXMuIElmIHlvdSBhcmUgYnVpbGRpbmcgYW4gaW1wbGVt ZW50YXRpb24NCiBpbiBhIGNvbnN0cmFpbmVkIGVudmlyb25tZW50LCB5b3UgY2FuIGJ1aWxkIGEg Y29uc3RyYWluZWQgaW1wbGVtZW50YXRpb24uIEFuZCBzb21lIHBlb3BsZSBoYXZlLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlNvIG5vLCBpdOKAmXMgbm90IGFwcHJvcHJpYXRlIHRvIHNwZWNpZnkgYW4gaW5kZXBl bmRlbnQgcGFyc2VyLCBvciByZXF1aXJlIG9uZS4gUmF0aGVyIHlvdSBuZWVkIHRvDQogZGVzaWdu IHNvIHRoYXQgd2hlbiBwZW9wbGUgZG8sIGl0IGNhbiBiZSBlZmZpY2llbnQuIFdoaWNoIGlzIHdo YXQgd2UgaGF2ZSBiZWVuIGRvaW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9yIGluIG90aGVyIHdvcmRzLCBJ IGRvbuKAmXQgdGhpbmsgdGhpcyBzb3J0IG9mIGNoYW5nZSBpcyBhcHByb3ByaWF0ZS4gUXVpdGUg dGhlIGNvbnRyYXJ5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZWxsLCB3ZSBkaXNhZ3JlZS4gVGhpcyBoYXMgYmVl biBhIGZ1bmRhbWVudGFsIHBvaW50IG9mIGNvbnRlbnRpb24gZm9yIHNvbWUgb2YgdGhlIGZvbGxv dy1vbiBwcm90b2NvbHMgYXR0ZW1wdGluZyB0byB1c2UgNTQ0NC4gYW5kIElNTywgdGhpcyBoYXMg dG8gYmUgYWRkcmVzc2VkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoZSBrZXkgcG9pbnQgaXMgdGhhdCB3aGF04oCZcyBtYW5kYXRlZCBpcyBhIG11 bHRpcGxleGVyIGFuZCBhIGZvcm1hdC4gQnV0IG5vdCBhbiBpbmRlcGVuZGVudCBwYXJzZXIuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBjYW4geW91IG1hbmRhdGUgYSBtdWx0aXBsZXhl ciwgYnV0IG5vdCBhbiBpbmRlcGVuZGVudCBwYXJzZXI/IFRoaXMgbWFrZXMgbm8gc2Vuc2UuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlN0YW4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0K PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4N ClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs bGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOzxhIGhyZWY9InRlbDol MkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0IiB0YXJnZXQ9Il9ibGFuayI+JiM0Mzs0NCAoMCkx MjQ1IDI0MjE5NDwvYT4NCiAmbmJzcDt8ICZuYnNwOzxiPkU6IDwvYj48YSBocmVmPSJtYWlsdG86 Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFy bG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2Zv cmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4 SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8 L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxp ZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsg V2FsZXMgTm86IDAxMzM3NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZp Y2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gU3Rhbg0KIFJhdGxpZmYgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cmF0bGlm ZnN0YW5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmF0bGlmZnN0YW5AZ21haWwuY29tPC9h Pl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxOCBBcHJpbCAyMDE2IDE0OjA5PGJyPg0KPGI+VG86PC9i PiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4NCjxiPkNjOjwvYj4gQ2hyaXN0b3BoZXIg RGVhcmxvdmU7IDxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pg0KbWFuZXRAaWV0Zi5vcmc8L2E+OyBDaHJpc3RvcGhlciBEZWFybG92ZTxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW21hbmV0XSBXR0xDIHJlcXVlc3QgZm9yIGRyYWZ0LWlldGYtbWFuZXQtcmZj NTQ0NC11c2FnZS0wMzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sg MS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRl cjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRl cjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5p c2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48 L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxi cj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBj bGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48 L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+ DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBl bWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5i YWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVk JTIwRmxhZ3MucGRmIiB0YXJnZXQ9Il9ibGFuayI+DQpoZXJlPC9hPi48L3NwYW4+PC9lbT48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxh IGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3Vy aXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVt YWlscy5wZGYiIHRhcmdldD0iX2JsYW5rIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+ PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gTW9uLCBBcHIgMTgsIDIwMTYgYXQgNDo1MiBBTSwgRGVhcmxvdmUsIENocmlz dG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZ dCBiZWxpZXZlIHdlIGNhbiBvciBzaG91bGQgc3VnZ2VzdCBhbiBpbXBsZW1lbnRhdGlvbi4gVGhh dOKAmXMgbm90IHdoYXQgdGhlIElFVEYgZG9lcywgYW5kIGl0DQogd291bGQgYmUgYSBoYXJkLCBw cm9iYWJseSBpbXBvc3NpYmxlLCBzZWxsLCB0byB0aGUgSUVTRy4gVGhhdCB0aGUgb2J2aW91cyBp bXBsZW1lbnRhdGlvbiBlbXBsb3lzIGFuIGluZGVwZW5kZW50IHBhcnNlciBpcyBhbHJlYWR5IHNh aWQgLSBpdCBtYXkgYmUgYXBwcm9wcmlhdGUgdG8gc3RyZW5ndGhlbiB0aGUgd29yZHMsIGJ1dCB0 aGlzIHNlY29uZCBJ4oCZbSBub3Qgc3VyZSBpZiB0aGF04oCZcyBuZWVkZWQgKG5vdCBnb3QgdGlt ZSB0byBjaGVjayBjdXJyZW50DQogd29yZGluZykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4oQWdhaW4sIHdp dGggbXkgV29ya2luZyBHcm91cCBQYXJ0aWNpcGFudCBoYXQgb24pIC0mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZG9uJ3Qg bWVhbiB0byBzdWdnZXN0IGFuIGltcGxlbWVudGF0aW9uLiBBdCBsZWFzdCB0byBtZSwgdGhpcyBp cyBhbiBhcmNoaXRlY3R1cmUgKHRoYXQgb2YgYW4gaW5kZXBlbmRlbnQgcGFyc2VyLCB3aXRoIGEg cmVsaWFibGUgY29tbXVuaWNhdGlvbnMgbWVjaGFuaXNtIHRvIHNhaWQgcGFyc2VyLCB0aGF0DQog ZGVhbHMgd2l0aCBsb2dpY2FsIG1lc3NhZ2VzIGluc3RlYWQgb2YgcGFja2V0cy4gSXMgc2VxdWVu Y2luZyBndWFyYW50ZWVkPyBJJ20gbm90IHN1cmUsIHRvIGJlIGhvbmVzdC4gQnV0IG9uY2UgdGhl IGluZGVwZW5kZW50IHBhcnNlciBpcyBhc3N1bWVkLCBlbmdpbmVlcnMgYWxzbyBNVVNUIGFzc3Vt ZSB0aGF0IHRoZSB0cmFuc3BvcnQgKGFuZCBpdCdzIHRoZSB0cmFuc3BvcnQgZm9yIGNvbnRyb2wg cGxhbmUgdHJhZmZpYywgYnV0IG5vdCBmb3IgZGF0YQ0KIHBsYW5lIHRyYWZmaWMpLCBpcyAmcXVv dDtvd25lZCZxdW90OyBieSB0aGUgaW5kZXBlbmRlbnQgcGFyc2VyLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hpY2ggbGVh ZHMgbWUgdG8gdGhlIG90aGVyIHBvaW50IEknbSB0cnlpbmcgdG8gbWFrZSAocGVyaGFwcyBiYWRs eSk6ICZuYnNwO0Fic3RyYWN0aW5nIHRoZSB0cmFuc3BvcnQgYXdheSBmcm9tIHRoZSBjb250cm9s IHBsYW5lICpjYW4qIGVmZmVjdCBwcm90b2NvbCBkZXNpZ24uJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGJlbGlldmUgYm90 aCBvZiB0aGVzZSBwb2ludHMgc2hvdWxkIGJlIGFkZHJlc3NlZCBpbiB0aGUgdXNhZ2UgZG9jdW1l bnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5TdGFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPC9zcGFu PjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlv ciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j ZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv 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+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gbWFuZXQNCiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPlN0YW4gUmF0bGlmZjxicj4NCjxiPlNlbnQ6PC9iPiAxNiBBcHJpbCAyMDE2 IDE5OjA5PGJyPg0KPGI+VG86PC9iPiBDaHJpc3RvcGhlciBEZWFybG92ZTxicj4NCjxiPkNjOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRA aWV0Zi5vcmc8L2E+OyBDaHJpc3RvcGhlciBEZWFybG92ZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW21hbmV0XSBXR0xDIHJlcXVlc3QgZm9yIGRyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2Fn ZS0wMzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFk ZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3Jv dW5kOndoaXRlIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+ KioqIFdBUk5JTkcgKioqPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3Jv dW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIi PlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBl aXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9l bT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBh bnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4N CjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwv c3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+ UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91 IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1z LmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3Mu cGRmIiB0YXJnZXQ9Il9ibGFuayI+DQpoZXJlPC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91 IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0 dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3Rs aWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYi IHRhcmdldD0iX2JsYW5rIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwv aT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzoxLjBwdCA0LjBwdCAxLjBwdCA0LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50 ZXIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPio8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qKg0KPC9zcGFuPjwvc3Ryb25nPjwv c3Bhbj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldBUk5JTkcNCjwvc3Bhbj48 L3N0cm9uZz48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qKio8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RVhU RVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBv cmdhbml6YXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBBcHIgMTUsIDIw MTYgYXQgMzoyNyBQTSwgQ2hyaXN0b3BoZXIgRGVhcmxvdmUgJmx0OzxhIGhyZWY9Im1haWx0bzpj aHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWsiIHRhcmdldD0iX2JsYW5rIj5jaHJpc0BtbmVtb3N5 bmUuZGVtb24uY28udWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVh biBieSB0aGUgY29uY2VwdCBvZiAmcXVvdDtmaWVsZHMgdGhlIHByb3RvY29sIGNhbiBhbmQgY2Fu J3QgdG91Y2gmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkNBVkVBVDogSSBhbSBzcGVha2luZyBoZXJlIGFzIGEgV29ya2lu ZyBHcm91cCBwYXJ0aWNpcGFudC4gV2l0aCB0aGF0IHVuZGVyc3Rvb2Q6DQo8YnI+DQombmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlRUTCBp cyBhIGdyZWF0IGV4YW1wbGUsIHNpbmNlIHRoYXQgZGlzY3Vzc2lvbiBibGV3IHRoZSBtYWlsaW5n IGxpc3QgdXAgYSBmZXcgbW9udGhzIGFnby4gSSdtICpub3QqIHNheWluZyBtYW5pcHVsYXRpbmcg VFRMIGlzIGEgZ29vZCB0aGluZyBmb3IgYSBwcm90b2NvbCB0byB0cnkgLSBpbiB0cnV0aCwgSSB0 aGluayBpdCdzDQogcHJldHR5ICZxdW90O2hhY2t5JnF1b3Q7LiBCdXQgdGhlIG5vdGlvbiB3YXMg ZmxvYXRlZCwgYW5kIGluIHRoZSBjb250ZXh0IG9mIHRoYXQgZGlzY3Vzc2lvbiwgaXQgbWF5IHdp bGwgaGF2ZSB3b3JrZWQuIFRoZSBvcHBvc2l0aW9uIG9uLWxpc3Qgd2FzIGZhc3QsIGFuZCBwcmV0 dHkgZm9yY2VmdWwuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+SSd2ZSBzYWlkIGJlZm9yZSAtIDU0NDQsIGVzcGVjaWFsbHkgd2l0aCB0aGUgbXVsdGlw bGV4ZXIsIGNoYW5nZXMgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGEgcm91dGluZyBwcm90b2Nv bCBhbmQgYW4gaW50ZXJmYWNlLiBJIHRoaW5rIHRoZSBkb2N1bWVudCBzaG91bGQgaGF2ZSBzb21l IHR5cGUgb2YgJnF1b3Q7b3ZlcnZpZXcmcXVvdDsNCiBzZWN0aW9uIHdoaWNoIGRpc2N1c3NlcyB0 aGVzZSBkaWZmZXJlbmNlcywgaW4gb3JkZXIgdG8gZnJhbWUgdGhlIGlzc3VlIGZvciBzb21lb25l IGNvbWluZyBhbG9uZyB3aG8gaGFzbid0IGJlZW4gYSBwYXJ0IG9mIHRoZSA1NDQ0IG1haWwgZGlz Y3Vzc2lvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij5JJ20gdGFsa2luZyBhYm91dCB0aGUgdHlwZSBvZiBvdmVydmlldyB0aGF0IGdvZXMgc29tZXRo aW5nIGxpa2UgdGhpczoNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0Ij4mcXVvdDtVc2Ugb2YgUkZDIDU0NDQgd2l0aCB0aGUgbXVsdGlwbGV4ZXIgZmVhdHVy ZSBpbXBvc2VzIGRlc2lnbiByZXF1aXJlbWVudHMgb24gdGhlIHByb3RvY29sLiBUaGUgYWN0dWFs IHRyYW5zcG9ydCBtZWNoYW5pc20gaXMgYWJzdHJhY3RlZCBmcm9tIHRoZSBwcm90b2NvbC4gRm9y IGV4YW1wbGUsIHJvdXRpbmcgcHJvdG9jb2xzDQogYXJlIG5vdCBhd2FyZSBvZiBwcmVjaXNlbHkg d2hlbiBhIG1lc3NhZ2UgaXMgc2VudC4gQSBnb29kIGV4YW1wbGUgb2Ygb3BlcmF0aW9uIGluIHRo aXMgbW9kZWwgaXMgW0JHUF0sIHV0aWxpemluZyB0aGUgW1RDUF0gdHJhbnNwb3J0LiBUaGlzIGlz IG9wcG9zZWQgdG8gYSBwcm90b2NvbCBzdWNoIGFzIFtPU1BGXSwgd2hpY2ggaXMgY2FwYWJsZSBv ZiBzZW5kaW5nIHRyYWZmaWMgd2l0aCBpdHMgb3duIElQIHR5cGUuIFNpbmNlIHRoZSB0cmFuc3Bv cnQNCiBpcyBhYnN0cmFjdGVkLCBwcm90b2NvbHMgYXJlIG5vdCBwcmVzZW50ZWQgd2l0aCAmcXVv dDtwYWNrZXRzJnF1b3Q7LCBhbmQgYXJlIG5vdCBjYXBhYmxlIG9mIG1hbmlwdWxhdGluZyBkYXRh IGl0ZW1zIGluIHBhY2tldCBoZWFkZXJzIChlLmcuIGRhdGEgaXRlbXMgYXQgdGhlIElQIGFuZC9v ciBNQUMgbGF5ZXJzKS4mcXVvdDs8YnI+DQo8YnI+DQpBcyBMb3UgQmVyZ2VyIHB1dCBpdCB0byBt ZSBpbiB0aGUgY29udGV4dCBvZiBETEVQIC0gJnF1b3Q7WW91IHdhbnQgYW4gZW5naW5lZXIgdG8g YmUgYWJsZSB0byBwaWNrIHVwIHRoaXMgZG9jdW1lbnQsIHdpdGggbm8gcHJpb3IgZXhwb3N1cmUg dG8gdGhlIHRvcGljLCBhbmQgY29kZSBhbiBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9uLiZx dW90OyZuYnNwOyBJIHRoaW5rIHRoaXMgdHlwZSBvZiBhbiBvdmVydmlldywgc2V0dGluZyBiYXNp YyBncm91bmQgcnVsZXMsIHdvdWxkDQogaGVscC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+SSd2ZSBhbHNvIGNvbnRlbmRlZCBmb3IgYSB3aGlsZSBub3cg dGhhdCA1NDQ0LCB3aXRoIHRoZSBtdXgsIGVmZmVjdGl2ZWx5IGZvcmNlcyBhbiBhcmNoaXRlY3R1 cmUgb24gaW1wbGVtZW50ZXJzIC0gaW4gdGhlIExpbnV4IHdvcmxkLCB0aGF0IGFyY2hpdGVjdHVy ZSBpcyBhIDU0NDQgcGFyc2VyIGFzIGFuIGluZGVwZW5kZW50DQogcHJvY2Vzcywgd2l0aCBJUEMg bWVjaGFuaXNtcyB0byB0aGUgcm91dGluZyBwcm90b2NvbChzKSBpdCBpcyBzZXJ2aWNpbmcuIFRo ZSA1NDQ0IHBhcnNlciBpdHNlbGYgJnF1b3Q7b3ducyZxdW90OyB0aGUgdHJhbnNwb3J0ICh0aGUg c29ja2V0KS4gVGhlIHVzYWdlIGRvY3VtZW50ICpzdHJvbmdseSBpbmZlcnMqIHRoYXQuIEkgYmVs aWV2ZSB3ZSBzaG91bGQgY29uY3JldGVseSBzdGF0ZSBpdCwgc28gd2UgZG9uJ3QgaGF2ZSB0byBh bnN3ZXIgdGhlIHF1ZXN0aW9uIG92ZXINCiBhbmQgb3ZlciBhZ2Fpbi4gPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlN0YW48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5X aGVuIGEgcHJvdG9jb2wgY3JlYXRlcyBhIG1lc3NhZ2UgZnJvbSBzY3JhdGNoIGl0J3Mgbm90IGNv bnN0cmFpbmVkIGluIGFueSB3YXkgSSdkIGRlc2NyaWJlIGluIHN1Y2ggdGVybXMuIFNvIEkgYXNz dW1lIHlvdSBtZWFuIHdoZW4gaXQgcmVjZWl2ZXMgYSBtZXNzYWdlIGFuZCB0aGVuIHNlbmRzIGEg c2ltaWxhcg0KIG1lc3NhZ2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UaGVyZSBhcmUgdHdvIGNhc2VzIHRoZXJlLiBVbmNoYW5nZWQg KHdpdGggdGhlIHNwZWNpYWwgZXhjZXB0aW9ucyBmb3IgaG9wIGNvdW50IGFuZCBsaW1pdCkgYW5k IG5vdCB1bmNoYW5nZWQuIFRoZSBmb3JtZXIgaXMgYmV0dGVyLCBhbmQgdGhlcmUncyByZWFsbHkg bm90aGluZyBtb3JlIHRvIHNheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvIGxldCdzIGNvbnNpZGVyIHRoZSBsYXR0ZXIuIFJlYWxs eSBpdCdzIG5vdCB0aGUgc2FtZSBtZXNzYWdlLCBpdCdzIGEgYnJhbmQgbmV3IG1lc3NhZ2UuIFRo YXQncyBhIHVzZWZ1bCB3YXkgdG8gbG9vayBhdCBpdCBmcm9tIGEgc2VjdXJpdHkgcGVyc3BlY3Rp dmUsIGJlY2F1c2UgaXQgdGVsbHMgeW91IHRoYXQNCiBlbmQgdG8gZW5kIGF1dGhlbnRpY2F0aW9u IGlzbid0IGdvaW5nIHRvIHdvcmsuIEFuZCB3aGF0IGFyZSB0aGUgcmVzdHJpY3Rpb25zIG9uIGJy YW5kIG5ldyBtZXNzYWdlcz8gVGhlIHNhbWUgYXMgb24gYW55IG5ldyBtZXNzYWdlLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T0ssIHlv dSBtaWdodCBzYXksIHRydWUgYnV0IGRvZXMgdGhhdCBtZWFuIEkgY2FuIGFkZCB0aGlzLCByZW1v dmUgdGhhdCwgY2hhbmdlIHRoZSBob3AgZGF0YT8gWWVzLiBCdXQgaXMgdGhhdCBhIGdvb2QgaWRl YT8gTm8uIEJ1dCBtYXliZSB5b3UgYXJlIGZvcmNlZCBpbnRvIGl0LiBCdXQgdGhhdCBpdCdzIGlu aGVyZW50bHkNCiBub3QgZ29vZCBzdWdnZXN0cyB0aGUgY29yb2xsYXJ5IHRoYXQgaWYgeW91IG11 c3QsIGRvIHRoZSBtaW5pbXVtIGFuZCBtYWtlIGl0IHRyYWNrYWJsZS4gQnV0IHRoYXQncyBub3Qg YSA1NDQ0IHJlcXVpcmVtZW50LCBqdXN0IGdvb2QgcHJhY3RpY2UuIEl0IGRvZXMgYnJlYWsgNzE4 MiBtZXNzYWdlIElDVnMsIHNvIGRvbid0IHVzZSB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2UgY291bGQsIGh5cG90aGV0aWNh bGx5LCBoYXZlIHNvbWVvbmUgY3JlYXRlIGFuIGV4dGVuc2lvbiBvciBhbHRlcm5hdGl2ZSB0byA3 MTgyIHRoYXQgZGVmaW5lZCBhZ2dyZWdhdGVkIHNpZ25hdHVyZXMuIFRoZW4gd2UnZCBoYXZlIHJ1 bGVzIG9uIHdoYXQgeW91IGNvdWxkIGNoYW5nZS4gQnV0IHRoYXQgd291bGQNCiBiZWxvbmcgdGhl cmUuIElmIHlvdSB0aGluayB0aG9zZSB3b3VsZCBiZSBnb29kLCB0aGVuIGFnYWluIHlvdSB3b3Vs ZCB3YW50IG1ha2UgbWluaW1hbCBjaGFuZ2VzLCBhbmQgbWFpbmx5IG9ubHkgb2YgY2VydGFpbiB0 eXBlcy4gV2hhdCB0eXBlcz8gVGhlcmUgSSBjYW4ndCBoZWxwIHlvdSBhcyBJIGRvbid0IGhhdmUg YSBjYW5kaWRhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5UaGUgc3VtbWFyeT8gRG9uJ3QgY2hhbmdlIGlmIHlvdSBkb24ndCBoYXZl IHRvLiBUaGF0J3MgcmVjb21tZW5kZWQuIElmIHlvdSBtdXN0IGNoYW5nZSB5b3UncmUgb24geW91 ciBvd24gKHdpdGggdGhlIHNhbWUgcmVzdHJpY3Rpb25zIGFzIG5ldyBtZXNzYWdlcykuIEFkdmlj ZSBsaWtlICZxdW90O2FzIGxpdHRsZSBhcw0KIHBvc3NpYmxlJnF1b3Q7IGlzIGdvb2QsIGJ1dCB0 aGF0J3Mgbm90IGFjdHVhbGx5IDU0NDQgYWR2aWNlLiBBbmQgZG9uJ3QgdXNlIDcxODIgbWVzc2Fn ZSBJQ1ZzLjxicj4NCjxicj4NCi0tICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0ibWFpbHRvOmNocmlz dG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdG9waGVyLmRl YXJsb3ZlQGdtYWlsLmNvbTwvYT4gKGlQaG9uZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0ibWFpbHRvOmNocmlzQG1uZW1vc3lu ZS5kZW1vbi5jby51ayIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51 azwvYT4gKGhvbWUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KT24gMTUgQXByIDIwMTYsIGF0IDE5OjM3LCBTdGFuIFJhdGxpZmYg Jmx0OzxhIGhyZWY9Im1haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5yYXRsaWZmc3RhbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TXkgbWFpbiBjb25j ZXJuIGFkZHJlc3NlZCBpbmxpbmUuLi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5PbiBGcmksIEFwciAxNSwgMjAxNiBhdCAxOjQ5IFBNLCBDaHJpc3RvcGhlciBEZWFybG92 ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkEg ZmV3IGltbWVkaWF0ZSBjb21tZW50cyBpbmxpbmUgYmVsb3cuPGJyPg0KPGJyPg0KLS0gJm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaHJpc3RvcGhl ciBEZWFybG92ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48YSBocmVmPSJtYWlsdG86Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tPC9hPiAoaVBob25l KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 YSBocmVmPSJtYWlsdG86Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrIiB0YXJnZXQ9Il9ibGFu ayI+Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrPC9hPiAoaG9tZSk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAxNSBBcHIg MjAxNiwgYXQgMTU6MTgsIExvdHRlIFN0ZWVuYnJpbmsgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3R0 ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZSIgdGFyZ2V0PSJfYmxhbmsiPmxvdHRlLnN0ZWVuYnJp bmtAZnUtYmVybGluLmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5zcGFya2VkIGJ5IHRoZSByZWNlbnRseSBzdGFydGVkIFdH TEMsIEnigJl2ZSByZXZpZXdlZCB0aGUgY3VycmVudCByZXZpc2lvbiBvZiB0aGUgZHJhZnQuIEni gJlkIGxpa2UgdG8gb2ZmZXIgdGhlIHdvcmtpbmcgZ3JvdXAgbXkgcGVyc3BlY3RpdmUgYXMgc29t ZW9uZSB3aG8gZG9lc27igJl0IGhhdmUgZGVjYWRlcyBvZg0KIHByb3RvY29sIGFuZC9vciBwYWNr ZXQgZm9ybWF0IGRlc2lnbiB1bmRlciB0aGVpciBiZWx0IChpLmUuIHNvbWUgdGhpbmdzIG1pZ2h0 IG5vdCBiZSBvYnZpb3VzIHRvIG1lIHRoYXQgYXJlIG9idmlvdXMgdG8gb3RoZXJzKSwgYnV0IGFs c28gYXMgc29tZW9uZSB3aG8gaGFzIHdvcmtlZCB3aXRoIFJGQyA1NDQ0IHdoZW4gaW1wbGVtZW50 aW5nIGEgcm91dGluZyBwcm90b2NvbCAoQU9EVnYyKSwgdXBkYXRpbmcgdGhlIHBhY2tldCBmb3Jt YXQgb2YgYQ0KIHJvdXRpbmcgcHJvdG9jb2wgKEFPRFZ2MiBhZ2FpbikgYW5kIChwYXJ0aWFsbHkp IGltcGxlbWVudGluZyBteSBvd24gUkZDNTQ0NCBidWlsZGVyL3BhcnNlci48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk92ZXJhbGwsIEkg dGhpbmsgdGhlIGRvY3VtZW50IGlzIGVhc3kgdG8gcmVhZCBhbmQgZm9sbG93LiBUbyBtZSwgaXQg Y29udGFpbnMgdmFsdWFibGUgaW5mb3JtYXRpb24gYW5kIGd1aWRhbmNlIGFuZCBpbiBzb21lIGNh c2VzIHByZXZlbnRzIHBlb3BsZSBmcm9tIHNob290aW5nIHRoZW1zZWx2ZXMgaW4gdGhlDQogZm9v dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SeKAmW0gcmVhbGx5IGhhcHB5IHRoaXMgZG9jdW1lbnQgZXhpc3RzIGFuZCBJ4oCZZCBsaWtlIGl0 IHRvIG1vdmUgZm9yd2FyZCBzb29uLCBidXQgSSBkbyBmZWVsIHRoYXQgaXQgaXMgc3RpbGwgbGFj a2luZyBpbiBzb21lIGFyZWFzLCB3aGljaCBpcyB3aHkgSSB3YXMgYSBiaXQgc3VycHJpc2VkIHRv IHNlZSBpdCBnbw0KIHRvIExhc3QgQ2FsbCBhbGwgb2YgYSBzdWRkZW4uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Tm90IHJlYWxseS4gVGhlIGF1dGhvcnMgaGFkIHNhaWQgd2hhdCB0 aGV5IGludGVuZGVkIHRvIHNheSwgbm8gb25lIHdhcyBjb21tZW50aW5nLCB0aW1lIGZvciBXR0xD LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkZpcnN0LCBzb21lIG5pdHBpY2tzIGFuZCBjb21tZW50czo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiogZnJvbSZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJm YzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi0xLjIuMSIgdGFyZ2V0PSJfYmxhbmsiPjxiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+MS4yLjE8L3NwYW4+PC9iPjwv YT48Yj4uDQogUGFja2V0L01lc3NhZ2UgRm9ybWF0PC9iPjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtb4oCmXSBh IHBhY2tldDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB0cmFuc21pc3Npb24gZm9sbG93aW5nIGEgc3VjY2Vzc2Z1bCBwYWNrZXQgcmVjZXB0aW9u IGlzIGJ5IGRlc2lnbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBvZiBhIG5ldyBwYWNrZXQgdGhhdCBtYXkgaW5jbHVkZSBhbGwsIHNvbWUsIG9y IG5vbmUgb2YgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHJlY2VpdmVkIG1lc3NhZ2VzIFsuLi5dPG86cD48L286cD48L3ByZT4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J4oCZbSBub3QgYSBu YXRpdmUgc3BlYWtlciwgYnV0IHRoYXQg4oCeb2bigJwgc2VlbXMgb3V0IG9mIHBsYWNlLi4uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkkgYW0gYSBuYXRpdmUgc3BlYWtlciwgYW5kIG5vLCBpdCdzIG5vdC4g U29tZSB3b3VsZCByZXBlYXQgaXQgYWZ0ZXIgZWFjaCBvZiBhbGwsIHNvbWUgYW5kIG5vbmUsIGFu ZCBJIG1pZ2h0IHNvbWV0aW1lcy4gQnV0IGl0IHJlYWxseSBkb2Vzbid0IG1hdHRlciB3aGljaCBv ZiB0aGUgdHdvIHN0eWxlcyB3ZSBwaWNrLA0KIHRoZSBSRkMgRWRpdG9yIG1heSB3ZWxsIGNoYW5n ZSB0byB0aGUgb3RoZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4qIFJlZ2FyZGluZyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi00 LjIiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPjQuMjwvc3Bhbj48L2I+PC9hPjxiPi4NCiBQYWNrZXRzIGFuZCBNZXNzYWdl czo8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPnRoaXMgc2VjdGlvbiB0YWxrcyBhIGxvdCBhYm91dCBob3cgdGhlIG11bHRpcGxleGVyIG9w ZXJhdGVzLCBzbyBJIHRoaW5rIGl04oCZZCBiZSBoZWxwZnVsIGlmIGl0cyB0aXRsZSByZWZsZWN0 ZWQgdGhhdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkknbSBvZiB0d28gb3BpbmlvbnMgb24gdGhhdC4gT24g dGhlIG9uZSBoYW5kIGl0IGlzLCBhcyBpdHMgdGl0bGUgc3VnZ2VzdHMsIGFib3V0IHRoZSBwYWNr ZXQgYW5kIG1lc3NhZ2UgbGV2ZWwsIGFzIG9wcG9zZWQgdG8gbG93ZXIgbGV2ZWxzLCBhbmQgaXRz IHRpdGxlIGNvbnRyYXN0cyB3aXRoIHRoYXQgaWYgNC4zDQogZm9yIHRoYXQgcmVhc29uLiBPbiB0 aGUgb3RoZXIgaGFuZCB5b3UgYXJlIHJpZ2h0LCBpdCBkb2VzIGhhdmUgbXVjaCBhYm91dCB0aGUg bXVsdGlwbGV4ZXIuIEEgdGl0bGUgY292ZXJpbmcgYWxsIHRocmVlIHdvdWtkIHN0YXJ0IGdldHRp bmcgY3VtYmVyc29tZS4gV2lsbCB0YWtlIHRoaXMgb25lIGF3YXkgdG8gdGhpbmsgYWJvdXQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4q IGZyb20mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNC40IiB0YXJnZXQ9Il9ibGFuayI+PGI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj40LjQ8L3NwYW4+ PC9iPjwvYT48Yj4uDQogQWRkcmVzc2VzIFJlcXVpcmUgQXR0cmlidXRlczo8L2I+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgQW4gdW5tb2RpZmll ZCBleHRlbnNpb24gdG8gTkhEUCB3b3VsZCBpZ25vcmUgc3VjaCBhZGRyZXNzZXMsPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGFzIHJlcXVpcmVkLCBhcyBpdCBkb2VzIG5vdCBz dXBwb3J0IHRoYXQgc3BlY2lhbGl6ZWQgcHVycG9zZS48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXQgZmlyc3QgZ2xhbmNlLCAodG8g bWUpIHRoaXMgcmVhZHMgYXMg4oCeQWxsIGFkZHJlc3NlcyB0aGF0IGFyZSBhc3NvY2lhdGVkIHdp dGggYW4gdW5rbm93biBUTFYgYXJlIGlnbm9yZWTigJwsIHdoaWNoIGlzIG9idmlvdXNseSBub25z ZW5zZSAoYnV0IHF1aXRlIHBhbmljLWluZHVjaW5nIDpEKS4gSeKAmWQgcHJvcG9zZQ0KIHRvIHJl d29yZCBpdCB0byBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPiZuYnNwOyZuYnNwOyBBbiB1bm1vZGlmaWVkIGV4dGVu c2lvbiB0byBOSERQIHdvdWxkIG5vdCBjb25zaWRlciB0aGlzPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IGFkZHJlc3MgdG8gYmUgb2YgYSBuZWlnaGJvciwgYXMgaXQgaXMgbGFj a2luZyBhIExJTktfU1RBVFVTPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG9y IE9USEVSX05FSUdIQiBUTFYuPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGFrZSB5b3VyIHBvaW50LCBidXQgSSB0 aGluayB0aGF0IGlmIHRoZSBhZGRyZXNzIGVuZHMgdXAgd2l0aCBubyByZWxldmFudCBhc3NvY2lh dGVkIFRMVnMgdGhlbiBpdCBpcyBpZ25vcmVkIGlzIGFsc28gYSBwb2ludC4gSSBkYXJlIHNheSB3 ZSBjYW4gd29yZHNtaXRoIHNvbWV0aGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+QWxzbywgSSBkb27igJl0IHF1aXRlIGdldCB3aGVyZSB5b3Xi gJlyZSBnb2luZyB3aXRoIHRoZSBsYXN0IHBhcmFncmFwaCBvZiB0aGF0IHNlY3Rpb24gKOKAnDxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGVzZSByZXN0cmljdGlvbnMgZG8gbm90LCBo b3dldmVyLCBtZWFuIHRoYXQgYWRkZWQgaW5mb3JtYXRpb24NCiBpczwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgY29tcGxldGVseSBpZ25vcmVkIGZvciBw dXJwb3NlcyBvZiB0aGUgYmFzZSBwcm90b2NvbC7igJ0pLi4uPG86cD48L286cD48L3ByZT4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVhZCBvbiwgdGhlIHJlc3Qgb2YgdGhl IHBhcmFncmFwaCBkZXNjcmliZXMgdGhlIGNhc2Ugd2hlcmUgbm90LiBCdXQgd2UgbWlnaHQgdGVs ZWdyYXBoIHRoYXQgYmV0dGVyIGluIHRoZSBvcGVuaW5nIHNlbnRlbmNlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIHJlZ2FyZGluZyB0aGUgbWFw cyBpbiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi00LjUiIHRhcmdldD0iX2JsYW5rIj48Yj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjQuNTwvc3Bhbj48 L2I+PC9hPjxiPi4NCiBJbmZvcm1hdGlvbiBSZXByZXNlbnRhdGlvbjo8L2I+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJltIGFmcmFpZCBJ IGp1c3QgZG9u4oCZdCByZWFsbHkgdW5kZXJzdGFuZCB0aGUgcHVycG9zZSBvZiB0aGlzIHNlY3Rp b24gYW5kIHRoZSBtYXBwaW5nIG5vdGF0aW9uLiBJ4oCZbSBhc3N1bWluZyB0aGF0IHRoZSBtYXBz IGFyZSBzdXBwb3NlZCB0byBvZmZlciBhIHdheSBvZiBkZXNjcmliaW5nIGhvdyBhIFRMViByZWxh dGVzDQogdG8gYSBtZXNzYWdlIG9yIGFuIGFkZHJlc3M/Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHNvLCB3aHkgZG9lcyBpdCBv bmx5IG1lbnRpb24gZXh0ZW5zaW9uIHR5cGVzLCBidXQgbm90IHRoZSBiYXNpcyB0eXBlcz88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J dCBzYXlzIGV4dGVuZGVkIHR5cGVzLCBtZWFuaW5nIHRoZSBjb21iaW5hdGlvbiBvZiB0aGUgdHdv LiBCdXQgZnVsbCB0eXBlIHdvdWxkIGJlIGJldHRlciwgYXMgYWxtb3N0IGRlZmluZWQgaW4gNTQ0 NC4gSW4gZmFjdCBJIHRoaW5rIHdlIHNob3VsZCBhZGQgYSBjb21tZW50IHRvIHRoZSBub3RhdGlv biBzZWN0aW9uLg0KICg1NDQ0IHVzZXMgYSBzeW1ib2xpYyBuYW1lIHJhdGhlciB0aGFuIHRoZSBw aHJhc2UuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5PciBpcyBpdCBzdXBwb3NlZCB0byBiZSB1c2VkIHNvbWV0aGluZyBsaWtlIHRoaXM6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+QkFTRV9UTFY8L3NwYW4+PC9iPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPk1lc3NhZ2U6Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+KGJhc2VfdGx2X2V4dGVuc2lvbl90eXBlXzEpIC0m Z3Q7ICgyIG9jdGV0cywgJnF1b3Q7dmFsdWUgYSB3aGVuIGNvbmRpdGlvbiB4IGlzIG1ldCZxdW90 Oyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj4oYmFzZV90bHZfZXh0ZW5z aW9uX3R5cGVfMikgLSZndDsgKDIgb2N0ZXRzLCAmcXVvdDt2YWx1ZSBiIHdoZW4gY29uZGl0aW9u IHkgaXMgbWV0JnF1b3Q7KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPj8gQWxzbywgSSBkb27igJl0IHF1aXRlIGdldCBob3cg dGhpcyB3b3VsZCBiZSB1c2VkIGluIGZ1dHVyZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucz8gT3Ig YWlkIGluIGltcGxlbWVudGluZyBSRkM1NDQ0IHBhcnNlcnM/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuIGV4YW1wbGUgb3IgYSBjbGFyaWZp Y2F0aW9uIHdvdWxkIGJlIHZlcnkgaGVscGZ1bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCdzIGEgd2F5IG9mIGxvb2tpbmcgYXQg dGhpbmdzLiBCdXQgbm90IHRoZSBvbmx5IG9uZSwgaXQgZ29lcyBvbiB0byBkaXNjdXNzIHZhcmlh bnRzLiBJIHRoaW5rIGl0IG1vc3RseSBjb21lcyB1bmRlciBoZWFkaW5nIG9mIGlmIHVzZWZ1bCB1 c2UgaXQsIGlmIG5vdCBza2lwIGl0LiBXZSdsbCB0YWtlIGFub3RoZXINCiBsb29rLCBidXQgSSBk b24ndCB0aGluayB0aGlzIHdpbGwgZXZlciBiZSBlbGVtZW50YXJ5LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIHJlZ2FyZGluZyZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQt dXNhZ2UtMDMjc2VjdGlvbi00LjYiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjQuNjwvc3Bhbj48L2I+PC9hPjxiPi4NCiBU TFZzOjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SW4gZ2VuZXJhbCwgaXTigJlzIG5vdCBjbGVhciBldmVyeXdoZXJlIGluIHRoZSBzZWN0 aW9uIHdoZXRoZXIgeW914oCZcmUgdGFsa2luZyB0byBSRkM1NDQ0IHBhcnNlci9idWlsZGVyIGlt cGxlbWVudG9ycyBvciBwcm90b2NvbCBkZXNpZ25lcnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgQSBwcm90b2NvbCBTSE9VTEQgdXNl IGFuIGVmZmljaWVudDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyByZXByZXNl bnRhdGlvbiwgYnV0IHRoaXMgaXMgYSBxdWFsaXR5IG9mIGltcGxlbWVudGF0aW9uIGlzc3VlLjxv OnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SeKAmW0g bm90IHN1cmUgd2hlcmUgeW914oCZcmUgZ29pbmcgd2l0aCB0aGUgbGFzdCBwYXJ0IG9mIHRoYXQg c2VudGVuY2U/IEnigJlkIHJld29yZCBpdCB0byBzb21ldGhpbmcgbGlrZSDigJ5BIHByb3RvY29s IFNIT1VMRCB1c2UgYW4gZWZmaWNpZW50IHJlcHJlc2VudGF0aW9uLCBhdm9pZGluZyB1bm5lY2Vz c2FyaWx5IHZlcmJvc2UNCiB1c2Ugb2YgVExWcyBhbmQgZXh0ZW5zaW9uIHR5cGVzLiBIb3dldmVy LCB0aGUgZmluYWwgYXJyYW5nZW1lbnQgaW4gYSBtZXNzYWdlLSBvciBhZGRyZXNzVExWIGJsb2Nr IGlzICZuYnNwO2EgcXVhbGl0eSBvZiBpbXBsZW1lbnRhdGlvbiBpc3N1ZeKAnCAoaW4gY2FzZSB0 aGF04oCZcyB3aGF0IHlvdSBtZWFudCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ObywgeW91J3JlIGNvbnNpZGVyaW5n IHRoZSBwcm90b2NvbCBkZXNpZ24uIFRoaXMgaXMgY29uc2lkZXJpbmcgdGhlIHByb3RvY29sIG9i amVjdCB0aGF0IGltcGxlbWVudHMgdGhlIHByb3RvY29sLiBUaGVyZSBpc24ndCBhIG9uZSB0byBv bmUgbWFwcGluZyBmcm9tIGluZm9ybWF0aW9uIHRvIHJlcHJlc2VudGF0aW9uLA0KIGl0J3MgdXAg dG8gdGhlIGltcGxlbWVudGF0aW9uIHRvIGRvIGl0IGVmZmljaWVudGx5LiBEaWZmZXJlbnQgaW1w bGVtZW50YXRpb25zIG9mIHRoZSBzYW1lIHByb3RvY29sIHNwZWNpZmljYXRpb24gbWF5IGRvIGJl dHRlciBvciB3b3JzZSBoZXJlLiAoVHJpdmlhbCBjYXNlLCBhbiBpbXBsZW1lbnRhdGlvbiBjb3Vs ZCBjaG9vc2UgdG8gbmV2ZXIgY29tcHJlc3MgYWRkcmVzc2VzLiBCYWQgaWRlYSwgYnV0IGxlZ2Fs Lik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5k IHRoZW46PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJz cDsgQTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBwcm90b2NvbCBNVVNUIHJl Y29nbml6ZSBhbnkgcGVybWl0dGVkIHJlcHJlc2VudGF0aW9uIG9mIHRoZTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBpbmZvcm1hdGlvbjsgZXZlbiBpZiBpdCBjaG9vc2VzIHRv IChmb3IgZXhhbXBsZSkgb25seSB1c2UgbXVsdGl2YWx1ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBUTFZzLCBpdCBNVVNUIHJlY29nbml6ZSBzaW5nbGUgdmFsdWUgVExWcyAo YW5kIHZpY2UgdmVyc2EpLjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+4oCmIEkgdGhvdWdodCBwcm90b2NvbHMgd2VyZW7igJl0IHN1cHBvc2VkIHRv IHNwZWNpZnkgd2hldGhlciBhIFRMViBpcyBhcnJhbmdlZCAoZm9yIGV4YW1wbGUpIGFzIGEgbXVs dGl2YWx1ZSBUTFY/ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW1wbGVtZW50YXRpb24gYWdhaW4sIG5vdCBkZXNpZ24u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5BbmQgc28sIHNpbmNlIGEgcHJvdG9jb2wgc2hvdWxkbid0IGJlIGNvbmNlcm5lZCB3aXRoIG11 bHRpdmFsdWUgVExWcyBhbmQgdGhlIGxpa2UsIHdvdWxkbuKAmXQgaXQgYmUgdGhlICpSRkM1NDQ0 IGltcGxlbWVudGF0aW9uKiB0aGF0IE1VU1QgcmVjb2duaXplIGFueSBwZXJtaXR0ZWQgcmVwcmVz ZW50YXRpb24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WW91J3JlIGFzc3VtaW5nIHRoYXQgdGhlcmUgaXMg YW4gUkZDIDU0NDQgaW1wbGVtZW50YXRpb24uIFRoYXQncyB0aGUgc2FtZSB3YXkgdG8gd29yayBp ZiB5b3UgcGxhbiB0byBpbXBsZW1lbnQgbW9yZSB0aGFuIG9uZSBwcm90b2NvbC4gQnV0IG5vdGhp bmcgc2F5cyB5b3UgaGF2ZSB0byBkbyBpdCB0aGF0IHdheS4NCiBUaGUgYXJjaGl0ZWN0dXJlIGRl ZmluZWQgYnkgNTQ5OCBhZG1pdHMgb2YgdGhlIG11bHRpcGxleGVyIGFuZCBwcm90b2NvbHMsIGFu ZCB0aHVzIHRoZXNlIGFyZSBydWxlcyBvbiB0aGUgcHJvdG9jb2wuIElmIHByb3RvY29scyBkZWxl Z2F0ZSBhbGwgdGhlaXIgY29tbW9uIHdvcmsgdG8gc29tZXRoaW5nIChwYXJzZXIvY3JlYXRvcikg dGhlbiBpdCBpbmhlcml0cyB0aG9zZSByZXN0cmljdGlvbnMsIGJ1dCB0aGF0J3Mgbm90IGRlZmlu ZWQsIGFuZCB3ZQ0KIGNhbid0IGFzc3VtZSBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T3IgaXMgdGhpcyBwYXJhZ3JhcGggcmVhbGx5IGp1c3Qg YSBjb21wbGljYXRlZCB3YXkgb2Ygc2F5aW5nIOKAnmFzIGEgcHJvdG9jb2wgZGVzaWduZXIsIG1h a2Ugc3VyZSB0byBub3Qgc3BlY2lmeS9yZWx5IG9uIHRoaW5ncyBsaWtlIChmb3IgZXhhbXBsZSkg bXVsdGl2YWx1ZSBUTFZzLCBzaW5jZSB5b3VyIG1lc3NhZ2VzDQogaGF2ZSB0byB3b3JrIHdpdGgg KmFueSogcmVwcmVzZW50YXRpb27igJw/IElmIHNvLCBJIHRoaW5rIHRoYXQgc2hvdWxkIGJlIGRv bmUgaW4gYSBsZXNzIGNvbXBsaWNhdGVkIGZhc2hpb24gKHNlZSBiZWxvdykuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiog cmVnYXJkaW5nJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTUiIHRhcmdldD0iX2JsYW5rIj48 Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjU8L3NwYW4+ PC9iPjwvYT48Yj4uDQogU3RydWN0dXJlOjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2luY2UgdGhpcyBzZWN0aW9uIHRhbGtzIGEgbG90 IGFib3V0IGZsYWdzLCBpdOKAmWQgYmUgbmljZSBpZiBpdHMgdGl0bGUgcmVwcmVzZW50ZWQgdGhh dC4gTWF5YmUgY29uc2lkZXIgcmVuYW1pbmcgaXQgdG8mbmJzcDvigJ5TdHJ1Y3R1cmUgYW5kIEZs YWdz4oCcJm5ic3A7b3Igc28/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SSBtb3N0bHkgZG9uJ3QgYWdyZWUuIFN0cnVjdHVyZSBpcyB0 aGUgc3ViamVjdCwgZmxhZ3MgYXJlIGEgZGV0YWlsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIGZyb20mbmJzcDs8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rp b24tNi4xIiB0YXJnZXQ9Il9ibGFuayI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQt ZGVjb3JhdGlvbjpub25lIj42LjE8L3NwYW4+PC9iPjwvYT48Yj4uDQogQWRkcmVzcyBCbG9jayBD b21wcmVzc2lvbjo8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4m bmJzcDsmbmJzcDsgQ29tcHJlc3Npb24gb2YgYWRkcmVzc2VzIGluIGFuIEFkZHJlc3MgQmxvY2sg Y29uc2lkZXJzIGFkZHJlc3NlcyB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBjb25zaXN0IG9mIGEgSGVhZCwgYSBNaWQsIGFuZCBhIFRhaWwsIHdoZXJlIGFsbCBhZGRyZXNz ZXMgaW4gYW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgQWRkcmVzcyBCbG9j ayBoYXZlIHRoZSBzYW1lIEhlYWQgYW5kIFRhaWwsIGJ1dCBkaWZmZXJlbnQgTWlkcy48bzpwPjwv bzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PknigJlkIGZpbmQgdGhpcyBzZW50ZW5jZSBlYXNpZXIgdG8gcmVhZCBpZiBpdCBzdGFydGVkIHdp dGgg4oCcQ29tcHJlc3Npb24gb2YgYWRkcmVzc2VzIGluIGFuIEFkZHJlc3MgQmxvY2sgaXMgcG9z c2libGUgd2hlbiBhZGRyZXNzZXMgY29uc2lzdCBvZiBhIEhlYWQsIGEgTWlkIFvigKZd4oCdLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk5vLiBUaGF0J3MgbWlzc2luZyB0aGUgcG9pbnQgYW5kIG1pc2xlYWRpbmcuIEFkZHJlc3NlcyBh cmUgYWx3YXlzIGNvbnNpZGVyZWQgdG8gaGF2ZSB0aGUgaGVhZC9taWQvdGFpbCBmb3JtYXQuIENv bXByZXNzaW9uIGlzIHBvc3NpYmxlIGlmIGVpdGhlciB0aGUgaGVhZCBvciB0YWlsIChvciBib3Ro KSBpcyBub24tZW1wdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiogZnJvbSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi02LjEiIHRhcmdldD0i X2JsYW5rIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUi PjYuMTwvc3Bhbj48L2I+PC9hPjxiPi4NCiBBZGRyZXNzIEJsb2NrIENvbXByZXNzaW9uOjwvYj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFB1dHRpbmcgYWRkcmVzc2VzIGludG8gYSBtZXNzYWdlIGVm ZmljaWVudGx5IGFsc28gaGFzIHRvIGluY2x1ZGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+V2h5IOKAnmhhcyB0b+KAnD8gSeKAmWQgdGhpbmsgdGhhdCB3b3VsZCBiZSBhIOKAnm1heeKA nC4gTXVsdGlwbGUgQWRyZXNzIEJsb2NrcyBhbmQvb3IgcmVvcmRlcmluZyBkb27igJl0IGluY3Jl YXNlIGVmZmljaWVuY3kgaW4gYWxsIHBvc3NpYmxlIGNhc2VzLi4uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB0aGF0J3Mg dGhlIHdyb25nIGNoYW5nZS4gUmF0aGVyICZxdW90O2luY2x1ZGUmcXVvdDsgc2hvdWxkIGJlICZx dW90O2NvbnNpZGVyJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4qIGZyb20mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi4yIiB0YXJn ZXQ9Il9ibGFuayI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpu b25lIj42LjI8L3NwYW4+PC9iPjwvYT48Yj4uDQogVExWczo8L2I+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbLi4uXSBU aGlzIGlzIGV2ZW4gcG9zc2libGUgaWYgdGhlIE1QUiBUTFYgc3BlY2lmaWVkIGluPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9MU1J2MiBbPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcxODEiIHRhcmdldD0iX2JsYW5r IiB0aXRsZT0iJnF1b3Q7VGhlIE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgUHJvdG9jb2wg dmVyc2lvbiAyJnF1b3Q7Ij5SRkM3MTgxPC9hPl0gaXMgYWRkZWQ7IGJ1dCBpdCBpcyBub3QgcG9z c2libGUsIGluIGdlbmVyYWwsIGlmPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBMSU5LX01FVFJJQyBUTFYgaXMgYWxzbyBhZGRlZC48bzpw PjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ V2h5IGlzIGl0IG5vdCBwb3NzaWJsZSBmb3IgdGhlIGxhdHRlcj8gSWYgdGhhdCBjb3VsZCBiZSBl eHBsYWluZWQvaGludGVkIGF0IGluIGEgaGFsZiBzZW50ZW5jZSwgSSB0aGluayBpdOKAmWQgYmUg aGVscGZ1bCBpbmZvcm1hdGlvbiB0byBoYXZlIGluIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGF0J3MgdmVyeSBo YXJkLCBhbmQgbm90IGp1c3QgYmVjYXVzZSBpdCdzIGEgbmVnYXRpdmUuIEl0J3MgcmVhbGx5IGFu IG9ic2VydmF0aW9uIHRoYXQgbW90aXZhdGVzIHRoZSBkdXNjdXNzaW9uLiBBIGhhbGYgc2VudGVu Y2Ugd291bGQgSSB0aGluayBjb25mdXNlIG1vcmUgdGhhbiBpdCBlbmxpZ2h0ZW5zIChpdCdzDQog YmVjYXVzZSB5b3UgaGF2ZSB0b28gbWFueSBjb25zdHJhaW50cyB0byBzYXRpc2Z5IGF0IG9uY2Ug LSBJIGRvdWJ0IHRoYXQgaGVscGVkKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluIGEgdHlwaWNhbCBjYXNlIHdoZXJlIGE8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTElO S19TVEFUVVMgVExWIHVzZXMgb25seSB0aGUgVmFsdWVzIEhFQVJEIGFuZCBTWU1NRVRSSUMsIHdp dGg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg ZW5vdWdoIGFkZHJlc3Nlcywgc29ydGVkIGFwcHJvcHJpYXRlbHksIHR3byBzaW5nbGUgdmFsdWUg VExWcyBjYW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgYmUgbW9yZSBlZmZpY2llbnQgdGhhbiBvbmUgbXVsdGl2YWx1ZSBUTFYuPG86cD48L286 cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNhbWUg dGhpbmc6IHdoeT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5IZXJlIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgb2J2aW91cyB0byBhbnlv bmUgd2hvIGhhcyBsb29rZWQgYXQgNTQ0NC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+KiByZWdhcmRpbmcgdGhlIHNlY29uZCBwYXJhZ3JhcGggZnJv bSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1h bmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi02LjMiIHRhcmdldD0iX2JsYW5rIj48Yj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjYuMzwvc3Bhbj48L2I+ PC9hPjxiPi4NCiBUTFYgVmFsdWVzPC9iPiwgaS5lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHByZT4mbmJzcDsgJm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IFRoaXMgYXBwcm9hY2ggd2FzIHNwZWNpZmllZCBpbiBbPGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzcxODgiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iQy4gYW5kIFQu IENsYXVzZW4iPlJGQzcxODg8L2E+XSwgYW5kIHJlcXVpcmVkIGZvciBwcm90b2NvbHM8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdGhhdCBleHRlbmQgWzxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MTMwIiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IiZx dW90O01vYmlsZSBBZCBIb2MgTmV0d29yayAoTUFORVQpIE5laWdoYm9yaG9vZCBEaXNjb3Zlcnkg UHJvdG9jb2wgKE5IRFApJnF1b3Q7Ij5SRkM2MTMwPC9hPl0gYW5kIFs8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzE4MSIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVv dDtUaGUgT3B0aW1pemVkIExpbmsgU3RhdGUgUm91dGluZyBQcm90b2NvbCB2ZXJzaW9uIDImcXVv dDsiPlJGQzcxODE8L2E+XS4mbmJzcDsgSXQgaXMgaGVyZSBSRUNPTU1FTkRFRCB0aGF0PG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRoaXMgYXBwcm9hY2ggaXMgZm9sbG93ZWQg d2hlbiBkZWZpbmluZyBhbnkgQWRkcmVzcyBCbG9jayBUTFYgdGhhdDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyBtYXkgYmUgdXNlZCBieSBhIHByb3RvY29sIHVzaW5nIFs8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTQ0NCIgdGFyZ2V0PSJfYmxhbmsi IHRpdGxlPSImcXVvdDtHZW5lcmFsaXplZCBNQU5FVCBQYWNrZXQvTWVzc2FnZSBGb3JtYXQmcXVv dDsiPlJGQzU0NDQ8L2E+XS48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHRlcm0g4oCedGhpcyBhcHByb2FjaOKAnCBjb25mdXNl ZCBtZSwgc2luY2UgSSBpbml0aWFsbHkgJm5ic3A7dGhvdWdodCBpdCBtZWFudCDigJ50aGUgYXBw cm9hY2ggaXMgdG8gdXNlIFVOU1BFQ0lGSUVEIGluIGEgd2F5IHRoYXQgbWFrZXMgc2Vuc2XigJwg cmF0aGVyIHRoYW4g4oCedGhlIGFwcHJvYWNoIGlzIHRvIHVzZSBVTlNQRUNJRklFROKAnC4NCiBN YXliZSB0aGF0IGNvdWxkIGJlIHJld29yZGVkIHRvIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMg b2YmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPlRoZSBVTlNQRUNJRklFRCBU TFYgYW5kIGl0cyB1c2FnZSB3YXMgc3BlY2lmaWVkIGluIFtSRkM3MTg4XeKApjwvc3Bhbj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk5vLiBUaGVyZSBpcyBubyBVTlNQRUNJRklFRCBUTFYuIFRoZXJlIGlzIGEgcmVjb21tZW5k YXRpb24gdG8gaW5jbHVkZSBhbiBVTlNQRUNJRklFRCB2YWx1ZSBpbiBhIFRMVi4gQnV0IHJlYWxs eSwgd2UndmUgZGVzY3JpYmVkIHRoaXMgb25jZSBpbiA3MTg4LCBpdCdzIHRoZXJlIHRvIHJlYWQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiogcmVn YXJkaW5nJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTYuMyIgdGFyZ2V0PSJfYmxhbmsiPjxi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+Ni4zPC9zcGFu PjwvYj48L2E+PGI+Lg0KIFRMViBWYWx1ZXM6PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgc2Vjb25kIHBhcmFncmFwaCBpcyBhIGJp dCBjb25mdXNpbmcgYW5kIHNlZW1zIHRvIGV4cGxhaW5nIHJvZ2hseSB0aGUgc2FtZSB0aGluZ3Mg YXMgdGhlIGZvdXJ0aCBwYXJhZ3JhcGhzLiBJ4oCZZCBwcm9wb3NlIHRvIG1lcmdlIHRoZSBzZWNv bmQgaW50byB0aGUgZm91cnRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkknbSBub3Qgc3VyZSBJIGV4YWN0bHkgYWdyZWUsIGJ1dCB0 aGUgb3JkZXJpbmcgaW4gdGhhdCBzZWN0aW9uIGNvdWxkIGJlIGltcHJvdmVkLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIGZyb20mbmJzcDs8YSBu YW1lPSJtXzM5NzU0MzA0NzM0NjAzMzI2NDJfbV8tNDUyOTYzNzk5NzE0NzU4Ij48L2E+PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11 c2FnZS0wMyNzZWN0aW9uLTYuNCIgdGFyZ2V0PSJfYmxhbmsiPjxiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+Ni40PC9zcGFuPjwvYj48L2E+PGI+Lg0KIEF1 dG9tYXRpb246PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5i c3A7Jm5ic3A7IFRoZSBwb3NzaWJsZSBnYWluIGRlcGVuZHMgb24gdGhlIGVmZmljaWVuY3k8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ug Y3JlYXRpb24sPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPnRoZSB0ZXJtIOKAnnRoZSBvcmlnaW5hbCBtZXNzYWdlIGNyZWF0aW9u4oCc IHNlZW1zIGEgYml0IGFtYmlndW91c+KAkyBkb2VzIHRoaXMgcmVmZXIgdG8gdGhlIG1lc3NhZ2Ug YXMgY3JlYXRlZCBieSBhbiBSRkM1NDQ0IG1lc3NhZ2UgYnVpbGRlciBpbXBsZW1lbnRhdGlvbj88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5ZZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkFkZGl0aW9uYWxseSwgSSdtIGNvbmNlcm5lZCBhYm91dCB0d28gdGhpbmdzIHRoYXQgKmFyZW7i gJl0KiBpbiB0aGUgZHJhZnQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4qICZuYnNwO1NvbWUgb2YgdGhlIEFPRFZ2MiBjby1hdXRob3Jz IGFuZCBtZSBoYXZlIGFza2VkIGZvciBhIGxpc3Qgb2Yg4oCeYXMgYSBwcm90b2NvbCwgeW91IGNh biBzZXQgYWxsIG9mIHRoZXNlIGZpZWxkcyBvZiBhIG1lc3NhZ2UsIGJ1dCBwbGVhc2UgbGVhdmUg dGhlIHJlc3QgYWxvbmXigJwsIHdoaWNoIHdvdWxk4oCZdmUgc2F2ZWQNCiB1cyBtYW55IGhvdXJz IG9mIGRpc2N1c3Npb25zIChhbmQgSGVubmluZyBhIGxvdCBvZiB0aW1lIHNwZW50IGV4cGxhaW5p bmcgdGhlc2UgdGhpbmdz4oCmKS4gVGhlc2UgcmVxdWVzdHMgaGF2ZSBiZWVuIG1ldCB3aXRoIGEg cmVmdXNhbCB0byBzcGVjaWZ5IGEgY29uY3JldGUgQVBJLCBhcyBzdWNoIGFuIGVmZm9ydCBpcyBk ZXBlbmRlbnQgb24gb3V0c2lkZSBmYWN0b3JzIHN1Y2ggYXMgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2Ug b3Igc29mdHdhcmUgYXJjaGl0ZWN0dXJlLg0KIEkgYWdyZWUgd2l0aCB0aGlzIG5vdGlvbiwgYnV0 IGEgcHJvZ3JhbW1pbmctbGFuZ3VhZ2UgZGVwZW5kZW50IEFQSSBpcyBub3Qgd2hhdCB3ZeKAmXZl IGFza2VkIGZvci4gSeKAmXZlIHRyaWVkIHRvIHN1cHBseSBhIHNrZXRjaCBvZiB3aGF0IEkgZGlk IGFzayBmb3IgaW4gWzFdLCBidXQgdW5mb3J0dW5hdGVseSBJIGRpZG7igJl0IGdldCBhbiBhbnN3 ZXIgKGFuZCBhcyBmYXIgYXMgSSBjYW4gc2VlIGl0LCB0aGUgZHJhZnQgd2FzbuKAmXQgY2hhbmdl ZCBlaXRoZXIpLg0KIEkgc3RpbGwgdGhpbmsgdGhhdCBzdWNoIGEgbGlzdCwgaW4gd2hhdGV2ZXIg Zm9ybSwgd291bGQgYmUgdmVyeSBoZWxwZnVsIGZvciBmdXR1cmUgSW50ZXJuZXQtRHJhZnQgYXV0 aG9ycyBhbmQgSSBhbHNvIHRoaW5rIHRoaXMgcmVxdWVzdCBpcyBpbiBhY2NvcmRhbmNlIHdpdGgg dGhlIGludGVudGlvbnMgc3RhdGVkIGluJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNv dXJpZXIiPjEuMSBIaXN0b3J5IGFuZCBQdXJwb3NlLCZuYnNwOzwvc3Bhbj5hbmQgSSB0aGluaw0K IGl0IHNob3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm8uIFRoZXJlIGFyZSBt YW55IHJlYXNvbnMgd2h5IHdlJ3JlIGp1c3Qgbm90IHRvdWNoaW5nIHRoaXMgb25lLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T25lIGlz IHRoYXQgbGFuZ3VhZ2UgaW5kZXBlbmRlbmNlIGlzIGEgbWlyYWdlLiBIb3cgeW91IGdvIGFib3V0 IHRoaW5ncyBpcyBjb21wbGV0ZWx5IGRpZmZlcmVudCBpbiwgZm9yIGV4YW1wbGUgYW4gb2JqZWN0 IG9yaWVudGVkIGxhbmd1YWdlIHRoYW4gb25lIHRoYXQgaXNuJ3QuIFNlY3Rpb24gNC41IHNob3dz DQogdGhhdCB0aGVyZSBhcmUgcXVpdGUgZGlmZmVyZW50IHdheXMgb2YgZG9pbmcgdGhpbmdzIGV2 ZW4gZ2l2ZW4gYSBkZWNpc2lvbiB0byB1c2UgYSBtYXAgYXBwcm9hY2gsIGFuZCB0aGVyZSBhcmUg b3RoZXIgYXBwcm9hY2hlcyB0aGFuIHRoYXQuIEl0IHdvdWxkIGJlIHdyb25nIGFuZCBiZXlvbmQg b3VyIGNvbXBldGVuY2UgdG8gc3VnZ2VzdCBvbmUgb2YgdGhlc2UgYXMgJnF1b3Q7YmVzdCZxdW90 Oy4gVGhlcmUncyByZWFzb25zIHRoZSBJRVRGIGRvZXNuJ3QgZG8gdGhpcywNCiBhbmQgdGhhdCdz IG9uZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlBsdXMsIGZyYW5rbHksIHRoZSB3b3JrIGl0IHdvdWxkIHRha2UgaXMgYmV5b25kIHdo YXQgd2UgY2hvb3NlIHRvIHNwZW5kLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbHQ7U3BlYWtpbmcg YXMgYSBXRyBQYXJ0aWNpcGFudCZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkknbSBjb25mdXNlZCAod2hpY2ggaXMgYW4gYWx0b2dl dGhlciB0b28gY29tbW9uIG9jY3VycmVuY2UgdGhlc2UgZGF5cykuIEkgZ2V0IHRoYXQgd2UgZG9u J3Qgd2FudCB0byBzcGVjaWZ5IGFuIEFQSS4gQnV0IEkgdGhpbmsgdGhlIGRpc2N1c3Npb24gYWJv dXQgZmllbGRzIGEgcHJvdG9jb2wgY2FuIGFuZCBjYW4ndA0KIHRvdWNoIGluIGEgbWVzc2FnZXMg aXMgYSBnb29kIHRoaW5nIC0gYW5kIGl0J3Mgb25lIHNwb3Qgd2hlcmUgSSwgdG9vLCBmaW5kIHRo ZSBkb2N1bWVudCB3YW50aW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VG8gcGFyYXBocmFzZSBzb21ldGhpbmcgSSd2ZSBz YWlkIGJlZm9yZSwgSSBiZWxpZXZlIHRoYXQgUkZDIDU0NDQgY2hhbmdlcyB0aGUgcmVsYXRpb25z aGlwIHRoYXQgYSByb3V0aW5nIHByb3RvY29sIGhhcyB3aXRoIGFuICZxdW90O2ludGVyZmFjZSZx dW90Oy4gSSdtIG5vdCBjb21tZW50aW5nIG9uIHdoZXRoZXIgb3Igbm90DQogdGhhdCdzIGEgZ29v ZCB0aGluZywgb3IgYSBiYWQgdGhpbmcgLSBqdXN0IHRoYXQgaXQgZG9lcyBjaGFuZ2UgdGhlIHJl bGF0aW9uc2hpcC4gVGhpcyBjaGFuZ2UgaGFzIGJlZW4gYXQgdGhlIHJvb3Qgb2Ygc29tZSBvZiB0 aGUgbG9uZy1ydW5uaW5nIGRpc2N1c3Npb25zIGFzIHRvIHdoZXRoZXIgcHJvdG9jb2xzIHVuZGVy IGRldmVsb3BtZW50IHdlcmUgUkZDIDU0NDQgY29tcGxpYW50IG9yIG5vdC4gVGhlIGdvYWwgb2Yg dGhpcyBkb2N1bWVudCBiZWluZw0KIHRvIGVsaW1pbmF0ZSAoaXQncyBhIGdvYWwsIHByb2JhYmx5 IG5vdCByZWFjaGFibGUpIHRob3NlIGRpc2N1c3Npb25zLCBJJ2QgbGlrZSB0byBzZWUgdGhhdCBp bmZvcm1hdGlvbiBpbiB0aGUgZG9jdW1lbnQgaW4gc29tZSBmb3JtLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdtIGludGVy ZXN0ZWQgaW4gc2VlaW5nIHRoaXMgZG9jdW1lbnQgcHJvZ3Jlc3MsIGFuZCBldmVudHVhbGx5IGJl IHB1Ymxpc2hlZC4gSSB0aGluayBpdCB3aWxsIGhlbHAgZnV0dXJlIHByb3RvY29sIGRlc2lnbmVy cyB0byBiZXR0ZXIgdXNlIFJGQyA1NDQ0LiBCdXQgSSB3b3VsZCBsaWtlIHRvIHNlZSAqc29tZXRo aW5nKg0KIGFsb25nIHRoZSBsaW5lcyBvZiB3aGF0IExvdHRlIGlzIHJlcXVlc3RpbmcsIGFzIEkg dGhpbmsgaXQgd2lsbCBpbXByb3ZlIHRoZSBkb2MuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TdGFuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiogQXMgdGhlIGV4YWN0IHJ1bGVzIGZvciB1c2luZy9zZXR0aW5nIHRoZSBob3AgY291bnQgJmFt cDsgaG9wLWxpbWl0IGZpZWxkcyBhcmUgY3VycmVudGx5IGJlaW5nIGRpc2N1c3NlZCB3LyByZWdh cmQgdG8gQU9EVnYyIGluIGFub3RoZXIgdGhyZWFkIFsyXeKAkyBzaG91bGQgYSBkZWZpbml0aXZl IGFuc3dlciB0byB0aGF0DQogcXVlc3Rpb24gYmUgcGFydCBvZiA1NDQ0LXVzYWdlPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPllvdSBk b24ndCB3YW50IHRoYXQuIEJlY2F1c2UgaWYgd2UgZGlkIHNwZWNpZnkgdGhhdCB5b3UnZCBmaW5k IHlvdXJzZWxmIG1vcmUgY29uc3RyYWluZWQgdGhhbiB5b3Ugd2FudCB0byBiZS4gVGhlcmUgaXMg YSBkZXNpZ24gaW50ZW50IGRlc2NyaWJlZCBpbiA1NDQ0LCBidXQgaXQgYXNzdW1lcyBpbW11dGFi bGUNCiBtZXNzYWdlcy4gV2hpY2ggeW91IGRvbid0IHdhbnQuIFJlYWxseSwgd2UncmUgZG9pbmcg eW91IGEgZmF2b3VyIGJ5IG5vdCBpbXBvc2luZyBvbiB5b3UuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TG90dGU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlsxXSZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3Vy cmVudC9tc2cxODA4Mi5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21zZzE4MDgyLmh0bWw8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlsyXQ0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21z ZzE4Njc0Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cxODY3NC5odG1sPC9hPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+QW0gMDYuMDQuMjAxNiB1bSAxOToxNCBzY2hyaWViIEp1c3RpbiBEZWFu ICZsdDs8YSBocmVmPSJtYWlsdG86YmViZW1hc3RlckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5iZWJlbWFzdGVyQGdtYWlsLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBjaGFpcnMgYWdyZWUgdGhhdCBhIDMgd2VlayBX R0xDIGlzIGFwcHJvcHJpYXRlLiZuYnNwOyBFdmVyeW9uZSBwbGVhc2UgcmVhZCB0aGUgZHJhZnQg ZWFybHkgYW5kIGdldCBjb21tZW50cyBpbiBlYXJseSBzbyB0aGF0IHRoZXkgY2FuIGJlIGFkZHJl c3NlZCB3aXRoaW4gdGhlIGxhc3QgY2FsbCBwZXJpb2QuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SnVzdGluPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIEFwciA2LCAyMDE2IGF0 IDc6NDAgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86 Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFy bG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PYnZpb3VzbHkgJiM0MzsxIHRvIHRoZSByZXF1ZXN0IGZvciBXR0xD Ljxicj4NCjxicj4NCldpdGggcmVnYXJkIHRvIHdoYXQncyBjaGFuZ2VkLCB0ZWNobmljYWxseSB0 aGUgb25seSBzaWduaWZpY2FudCB0aGluZyBpcyB0byBtYWtlIGl0IGNsZWFyIHRoYXQgaWYgYSBw cm90b2NvbCBkZWxpdmVycyBhIG1lc3NhZ2UgdG8gdGhlIG11bHRpcGxleGVyLCB0aGUgbXVsdGlw bGV4ZXIgbXVzdCBwYXNzIGl0IG9uIHVuY2hhbmdlZCB0byB0aGUgcHJvdG9jb2wgKGFub3RoZXIg aW5zdGFuY2Ugb2YsIGF0IGFub3RoZXIgcm91dGVyKSB1bmNoYW5nZWQuDQogV2l0aG91dCB0aGF0 IG5vdGhpbmcgdGhhdCB0aGUgcHJvdG9jb2wgaXRzZWxmIGNob29zZXMgdG8gZG8gd2l0aCByZWdh cmQgdG8gc2VjdXJpdHkgbWFrZXMgc2Vuc2UuIFRob3VnaCB0aGUgcHJvdG9jb2wgY2FuIGFsdGVy bmF0aXZlbHkgbGV0IHRoZSBtdWx0aXBsZXhlciBkbyB0aGUgc2VjdXJpdHksIDcxODIgY2FuIGJl IGltcGxlbWVudGVkIGluIGVpdGhlciB3YXkuIFRoaXMgaXNuJ3QgcmVhbGx5IG5ldywgYnV0IGl0 IHdhc24ndCBmb3JtYWxseQ0KIHNwZWxsZWQgb3V0LiBJdCdzIHByZXNlbnRlZCBhcyBwYXJ0IG9m IHNwZWxsaW5nIG91dCBtdWx0aXBsZXhlciBydWxlcyBtb3JlIGNhcmVmdWxseS48YnI+DQo8YnI+ DQpCdXQgd2hhdCBhYm91dCBtZXNzYWdlIG9wdGltaXNhdGlvbj8gVGhhdCdzIGEgZnVuY3Rpb24g b2YgY29uc3RydWN0aW5nIGEgNTQ0NCBtZXNzYWdlLCBub3QgdGhlIG11bHRpcGxleGVyLCBhbmQg aXMgZG93biB0byB0aGF0IDU0NDQgaW5jbHVkZXMgdHdvIHRoaW5ncyAtIHBhY2tldC9tZXNzYWdl IHN0cnVjdHVyZSAoYW5kIGltcGxpY2l0bHksIGFuZCBpbiBwcmV0dHkgbXVjaCBhbnkgaW1wbGVt ZW50YXRpb24gSSB3b3VsZCBleHBlY3QgdG8gc2VlLA0KIGEgcGFyc2VyIGFuZCBidWlsZGVyIGZv ciB0aGF0IHN0cnVjdHVyZSkgYW5kIHRoZSBtdWx0aXBsZXhlci4gU28gd2UgdG9vayB0aGUgb3Bw b3J0dW5pdHkgdG8gc2VwYXJhdGUgb3V0IG1vcmUgY2xlYXJseSBhIGRpc2N1c3Npb24gb2YgdGhl IHR3bywgd2hpY2ggd2UgdGhpbmsgd2lsbCBiZSBoZWxwZnVsLjxicj4NCjxicj4NCi0tPGJyPg0K Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0K QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQo8YnI+DQpUOiAmbmJzcDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgw JTI5MTI0NSUyMDI0MjE5NCIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8 L2E+ICZuYnNwO3wgJm5ic3A7RToNCjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t PC9hPjxicj4NCjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNm b3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIg OEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0i X2JsYW5rIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L2E+PGJyPg0KQkFFIFN5c3RlbXMgQXBwbGll ZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBX YWxlcyBObzogMDEzMzc0NTE8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNo IFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBtYW5ldCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpt YW5ldC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXQtYm91bmNlc0BpZXRm Lm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBVbHJpY2ggSGVyYmVyZzxicj4NClNlbnQ6IDA1IEFwcmls IDIwMTYgMjA6MDg8YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogW21hbmV0XSBXR0xD IHJlcXVlc3QgZm9yIGRyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMzxicj4NCjxicj4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t IFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBl aXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVybmV0Ljxicj4N CkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtz LCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48YnI+DQpGb2xsb3cgdGhlICdSZXBvcnQg U3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9u IHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLjxicj4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KKioq IFdBUk5JTkcgKioqPGJyPg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0 ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb24uPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KSGksPGJyPg0KPGJyPg0KQXMgeW91 IGhhdmUgc2Vlbiwgd2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgcmV2aXNpb24gb2YgNTQ0NC11c2Fn ZS4gVGhlIGF1dGhvcnMgZmVlbCBjb21mb3J0YWJsZSB0aGF0IHdlIGhhdmUgYWRkcmVzc2VkIGFs bCBpc3N1ZXMgYnkgdGhpcyB2ZXJzaW9uLCBhbmQgd291bGQgbGlrZSB0byBhc2sgdGhlIFdHIGNo YWlycyB0byBpc3N1ZSBhIFdHTEMgb24gdGhpcyBkb2N1bWVudC4gV2hpbGUgaXQgaXMgYSBmYWly bHkgc2hvcnQgZG9jdW1lbnQsIGdpdmVuDQogdGhhdCBpdCBpcyBJRVRGIHdlZWsgZm9yIHNvbWUs IHdlJ2Qgc3VnZ2VzdCB0aGF0IGEgMy00IHdlZWsgV0dMQyB3b3VsZCBiZSBhcHByb3ByaWF0ZS48 YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHM8YnI+DQpVbHJpY2g8YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQpUaGlzIGVtYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQ8YnI+DQpy ZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZDxicj4NCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0g YW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj4NCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNl IGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+DQpkaXN0cmlidXRlIGl0cyBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4NCioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0QGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21h bmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWFuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ADAB6GLKXM0002VGREEN_-- From nobody Mon Apr 18 08:50: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 D17AD12E178 for ; Mon, 18 Apr 2016 08:50:50 -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 qBQxbwGOMIeE for ; Mon, 18 Apr 2016 08:50:48 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [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 087F112E175 for ; Mon, 18 Apr 2016 08:50:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,503,1454976000"; d="scan'208";a="61879593" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 18 Apr 2016 16:50:47 +0100 X-IronPort-AV: E=Sophos;i="5.24,503,1454976000"; d="scan'208";a="114456157" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 18 Apr 2016 16:50:46 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 16:50:46 +0100 From: "Dearlove, Christopher (UK)" To: John Dowdell , "manet@ietf.org" Thread-Topic: [manet] Review of draft-ietf-manet-rfc5444-usage-03 Thread-Index: AQHRmYPi83qX1zKGTE6pZZRlAgZtP5+P2bGg Date: Mon, 18 Apr 2016 15:50:45 +0000 Message-ID: References: <4D088849-F444-4FA3-B0AE-0FD2078A76F5@gmail.com> In-Reply-To: <4D088849-F444-4FA3-B0AE-0FD2078A76F5@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: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [manet] Review of draft-ietf-manet-rfc5444-usage-03 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, 18 Apr 2016 15:50:51 -0000 Sm9obg0KPiA0LjIsIHRyYW5zbWlzc2lvbiwgZmlyc3QgYnVsbGV0OiAiIE91dGdvaW5nIG1lc3Nh Z2VzIGFyZSBjcmVhdGVkIGJ5IHRoZWlyIG93bmluZyBwcm90b2NvbCwgYW5kIE1BWSBiZSBtb2Rp ZmllZCBieSBhbnkgZXh0ZW5kaW5nIHByb3RvY29scyBpZiB0aGUgb3duaW5nIHByb3RvY29sIHBl cm1pdHMgdGhpcy7igJ0gRmFpciBlbm91Z2gsIHNvIG1lc3NhZ2VzIGZyb20gdGhlIGhvc3RlZCBw cm90b2NvbCBjYW4gYmUgbW9kaWZpZWQgYnkgYW4gZXh0ZW5zaW9uIHRvIHRoYXQgcHJvdG9jb2wg YmVmb3JlIGdldHRpbmcgdG8gdGhlIDU0NDQgcGFyc2VyLiDigJwNCg0KVGhlIGZpbmFsIGRlbGl2 ZXJ5IHRvIHRoZSBtdWx0aXBsZXhlciBpcyAoY29uY2VwdHVhbGx5LCBvZiBjb3Vyc2UgaW1wbGVt ZW50YXRpb25zIGNhbiBvcHRpbWlzZSAtIGFsd2F5cyB0cnVlIGlmIHRoZSByZXN1bHQgaXMgdW5k ZXRlY3RhYmxlKSBpcyBmcm9tIHRoZSBvd25pbmcgcHJvdG9jb2wuDQoNCj4gTWVzc2FnZXMgTUFZ IGFsc28gYmUgZm9yd2FyZGVkIGJ5IHRoZWlyIG93bmluZyBwcm90b2NvbC7igJ0uIEFsc28gb2ss IHRoZXJlIGFyZSBubyBleHRlbnNpb24gcHJvdG9jb2xzLg0KDQpUbyB3aGF0Pw0KDQo+ICJJdCBp cyBzdHJvbmdseSBSRUNPTU1FTkRFRCB0aGF0IG1lc3NhZ2VzIGFyZSBub3QgbW9kaWZpZWQgaW4g dGhlIGxhdHRlciBjYXNlLuKAnSBJ4oCZbSBub3QgZm9sbG93aW5nIHRoaXMuIFdoeSBpcyBpdCBv ayB0byBtb2RpZnkgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gaW1wYWN0ZWQgYnkgYW4gZXh0ZW5z aW9uIHRvIHRoZSBob3N0ZWQgcHJvdG9jb2wsIGJ1dCBpdOKAmXMgbm90IG9rIHRvIG1vZGlmeSBt ZXNzYWdlcyB0aGF0IGhhdmUgbm90IGJlZW4gc3ViamVjdCB0byBleHRlbnNpb24gcHJvY2Vzc2lu Zz8gV2hhdCBkb2VzIOKAmG1vZGlmeeKAmSBtZWFuIGluIHRoaXMgY29udGV4dCBhbnl3YXk/DQoN CkJlY2F1c2Ugb25lIGlzIGluIHRoZSBlbmRwb2ludCwgb25lIGlzIG5vdC4gSWYgeW91IG1vZGlm eSBtZXNzYWdlcyBhdCB0aGUgZW5kcG9pbnQgKGUuZy4gT0xTUnYyIGFkZGluZyBNUFJzIHRvIE5I RFAncyBIRUxMTyBtZXNzYWdlcykgeW91IGNhbiBhZGQgYW4gSUNWIGFmdGVyd2FyZHMgYW5kIHN0 aWxsIGdldCBlbmQgdG8gZW5kIHNlY3VyaXR5LiBJZiB5b3UgbW9kaWZ5IGluIGJldHdlZW4gdGhl IHR3byB0aGVuIHlvdSBjYW4ndC4NCg0KPiA0LjIsIHRyYW5zbWlzc2lvbiwgc2Vjb25kIGJ1bGxl dDog4oCc4oCmICBUaGUgb3duaW5nIHByb3RvY29sIE1VU1QgaW5kaWNhdGUgd2hpY2ggaW50ZXJm YWNlKHMpIHRoZSBtZXNzYWdlcyBhcmUgdG8gYmUgc2VudCBvbiDigKbigJ0uIEkgaGF2ZSBzdHJ1 Z2dsZWQgd2l0aCB0aGlzIGZvciBhIGxvbmcgdGltZS4gVGhlIGhvc3RlZCBwcm90b2NvbCBpcyBp c29sYXRlZCBmcm9tIHRoZSBpbnRlcmZhY2UgYnkgYXQgbGVhc3QgdGhlIDU0NDQgbXVsdGlwbGV4 ZXIsIGFuZCB0aGVyZWZvcmUgaGFzIG5vIGlkZWEgd2hpY2ggaW50ZXJmYWNlcyBhcmUgYmVpbmcg dXNlZCBmb3IgdHJhbnNtaXNzaW9uIG9yIHJlY2VwdGlvbi4gSXMgdGhlcmUgYW4gaW1wbGljaXQg cmVxdWlyZW1lbnQgdGhhdCB0aGUgZGVtdWx0aXBsZXhlciBtdXN0IGluZGljYXRlIHRoZSBpbnRl cmZhY2UgdGhhdCBhIG1lc3NhZ2UgY2FtZSBpbiBvbiAoYW5kLCBpZiBkaWZmZXJlbnQsIHRoZSBh c3NvY2lhdGVkIG91dGdvaW5nIGludGVyZmFjZSksIHNvIHRoYXQgb3V0Z29pbmcgbWVzc2FnZXMg Y2FuIGJlIGRpcmVjdGVkIGFjY29yZGluZ2x5Pw0KDQpJIG5lZWQgdG8gd29yayBvdXQgaG93IGlt cGxpY2l0IHRoYXQgaXMsIHdoYXQncyBiZWVuIHNhaWQuIEJ1dCB5ZXMsIHRoZSBwcm90b2NvbCBt YXkgbmVlZCB0byBrbm93IHdoaWNoIGludGVyZmFjZSBhIG1lc3NhZ2UgY2FtZSBpbiBvbi4gTkhE UCBkb2VzLiBJIHRob3VnaHQgd2UnZCBhZGRlZCBhbiBpbmRpY2F0aW9uIG9mIHdoYXQgdGhlIChk ZSltdWx0aXBsZXhlciBuZWVkcyB0byBkZWxpdmVyIC0gYWRkcmVzc2VzLCBwYWNrZXQgaGVhZGVy LCBpbnRlcmZhY2UuDQoNCj4gNC4yLCB0cmFuc21pc3Npb24sIHRoaXJkIGJ1bGxldDogIiBUaGUg bXVsdGlwbGV4ZXIgU0hPVUxEIGNvbWJpbmUgbWVzc2FnZXMg4oCmIHByb3ZpZGVkIHRoYXQgaW4g c28gZG9pbmcgdGhlIG11bHRpcGxleGVyIGRvZXMgbm90IGNhdXNlIGFuIElQIHBhY2tldCB0byBl eGNlZWQgdGhlIGN1cnJlbnQgTVRVIC4uIChOb3RlIHRoYXQgdGhlIG11bHRpcGxleGVyIGNhbm5v dCBmcmFnbWVudCBtZXNzYWdlczsgY3JlYXRpbmcgc3VpdGFibGUgc2l6ZWQgbWVzc2FnZXMgaXMg dGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBwcm90b2NvbCBnZW5lcmF0aW5nIHRoZSBtZXNzYWdl LinigJ0NCg0KPiBGaXJzdCBwcm9ibGVtOyBob3cgZG9lcyB0aGUgaG9zdGVkIHByb3RvY29sIGtu b3cgdGhlIE1UVSBpZiBpdCBpcyBpc29sYXRlZCBmcm9tIHRoZSBpbnRlcmZhY2U/DQoNCkp1c3Qg YmVlbiBoYXZpbmcgdGhhdCBjb252ZXJzYXRpb24uIEFwYXJ0IGZyb20gbm90IHByb2R1Y2luZyBz aW5nbGUgbWVzc2FnZXMgdGhhdCBhcmUgdG9vIGxhcmdlIC0gd2hpY2ggaXMgYSBwcm9ibGVtIG1h bnkgdGhpbmdzIG5vdCBkaXJlY3RseSBzaXR0aW5nIG9uIElQIGhhdmUgLSB0aGF0IHBhcmFncmFw aCBpcyBhYm91dCB0aGUgbXVsdGlwbGV4ZXIsIGl0J3Mgbm90IHRoZSBwcm90b2NvbCdzIHByb2Js ZW0uDQoNCj4gU2Vjb25kIHByb2JsZW07IEkgY29tcGxldGVseSBkaXNhZ3JlZSB0aGF0IHRoZSBo b3N0ZWQgcHJvdG9jb2wsIHdoaWNoIGhhcyBubyBrbm93bGVkZ2Ugb2YgaW50ZXJmYWNlIG9yIE1U VSwgYW5kIG1heSBub3QgYmUgdGhlIG9ubHkgaG9zdGVkIHByb3RvY29sLCBzaG91bGQgYmUgaW4g Y2hhcmdlIG9mIG1ha2luZyBzaG9ydCBlbm91Z2ggbWVzc2FnZXMgdGhhdCBmaXQgdGhlIE1UVSBz aXplLiBTaW5jZSB0aGUgbXVsdGlwbGV4ZXIgaXMgcG90ZW50aWFsbHkgY29uZHVjdGluZyBhbGwg a2luZHMgb2YgY29tcHJlc3Npb24sIA0KDQpObywgaXQncyBub3QuIEl0J3MgcHJvaGliaXRlZCBm cm9tIGRvaW5nIHNvLiBJdCBzYXlzIHNvIGluIHRoaXMgZHJhZnQuIA0KDQo+IHRoZSBob3N0ZWQg cHJvdG9jb2wgaXMgcmVxdWlyZWQgdG8gY2FyZWZ1bGx5IGNyYWZ0IGEgbWVzc2FnZSB0aGF0IGZp dHMgd2hhdCBpdCBiZWxpZXZlcyBpcyB0aGUgTVRVLCBpZiBpdCBoYXMgYmVlbiB0b2xkLCBvbmx5 IGZvciB0aGUgbXVsdGlwbGV4ZXIgdG8gb3B0aW1pc2UgYW5kIHNoYXZlIG9mZiBzb21lIGJ5dGVz IChhbmQgbWF5YmUgbWFueSBieXRlcyksDQoNCllvdSBhcmUgY29uZnVzaW5nIHRoZSBvcHRpb25h bCBjb25jZXB0IG9mIGhhdmluZyBhIHBhcnNlciB3aXRoIGEgbXVsdGlwbGV4ZXIuIFRoZXJlIGlz IG5vIHN1Y2ggZnVuY3Rpb24gZ3VhcmFudGVlZCB0byBleGlzdC4NCg0KQ29uc2lkZXIgNTQ0NCBh cyBjb25zaXN0aW5nIG9mIHdobyB0aGluZ3MgdGhhdCBvdWdodCB0byBiZSBpbiB0d28gZGlmZmVy ZW50IFJGQ3MuIE9uZSBpcyB0aGUgbXVsdGlwbGV4ZXIuIE9uZSBpcyBhIHNwZWNpZmljYXRpb24g b2YgcGFja2V0IGFuZCBtZXNzYWdlIGZvcm1hdC4gTm90ZSwgbm8gc3VjaCB0aGluZyBhcyBhIHBh cnNlci4gQSBwYXJzZXIgaXMgYW4gaW1wbGVtZW50YXRpb24gY2hvaWNlIHRoYXQgYXJpc2VzIGZy b20gIllvdSBrbm93LCBPTFNSdjIgYW5kIFNNRiBhcmUgdXNpbmcgdGhlIHNhbWUgZm9ybWF0LiBX aHkgZG9uJ3QgSSBqdXN0IHdyaXRlIHRoYXQgY29kZSBvbmNlPyIuIElmIHlvdSB3YW50IHRvIG9w dGltaXNlciBob3cgdG8gZG8gdGhhdCwgdGhhdCdzIHVwIHRvIHlvdS4gQnV0IGluIHRlcm5zIG9m IHRoZSA1NDQ0IG1vZGVsLCB0aGF0J3MgYWxsIHByb3RvY29sLg0KDQo+IHBvdGVudGlhbGx5IGNv bWJpbmUgaXQgd2l0aCBtZXNzYWdlcyBmcm9tIHNvbWUgb3RoZXIgaG9zdGVkIHByb3RvY29sIGFu ZCBzZW5kIGl0IG91dCB0aGUgaW50ZXJmYWNlLiBUaGUgaG9zdGVkIHByb3RvY29sIGNvdWxkIGhh dmUgdXNlZCB0aG9zZSBieXRlcyB0byBzZW5kIG1vcmUgaW5mb3JtYXRpb24sIGFuZCBsZXNzIG92 ZXJoZWFkIHdvdWxkIGhhdmUgYmVlbiBnZW5lcmF0ZWQuIElmIHRoZSA1NDQ0IG11eC9kZW11eCBp cyBpbiBjaGFyZ2Ugb2YgbWFraW5nIHdob2xlIG1lc3NhZ2VzIG1hZ2ljYWxseSByZWFwcGVhciBp biBvbmUgcGllY2UgYXQgdGhlIHJlY2VpdmluZyBlbmQsIGl0IGRvZXNu4oCZdCBtYXR0ZXIgdG8g bWUgaG93IG1hbnkgZnJhZ21lbnRzIHRoZSBtZXNzYWdlIHdhcyBzcHJlYWQgYWNyb3NzIGluIHRy YW5zaXQuDQoNCklmIGl0J3MgZnJhZ21lbnRlZCwgaXQncyBmcmFnbWVudGVkIGJ5IElQLCBiZWNh dXNlIHRoZSBtdWx0aXBsZXhlciBkb2Vzbid0IGZyYWdtZW50LiBBcyB0aGF0IHRleHQgc2F5cy4g SSBwcmVmZXIgdGhpbmdzIG5vdCB0byBiZSBmcmFnbWVudGVkIGJ5IElQLCBlc3BlY2lhbGx5IG9u IHVucmVsaWFibGUgcmFkaW8gbGlua3MuDQoNCj4gNC4yLCB0cmFuc21pc3Npb24sIGZpZnRoIGJ1 bGxldDog4oCcIOKApiB0aGUgbXVsdGlwbGV4ZXIgU0hPVUxEIOKApiBpbmNsdWRlIGEgUGFja2V0 IFNlcXVlbmNlIE51bWJlciBpbiB0aGUgcGFja2V04oCdLiBJ4oCZbSBub3Qgc3VyZSB0aGlzIGlz IG5lY2Vzc2FyeS4gVGhlIGhvc3RlZCBwcm90b2NvbCBpcyBtb3N0IGxpa2VseSB1c2luZyBpdHMg b3duIHNlcXVlbmNlIG51bWJlcnMgaW4gaXRzIG93biBtZXNzYWdlcywgYW5kIHVuZGVyc3RhbmRz IHRoYXQgbWVzc2FnZXMgY2FuIGFycml2ZSBvdXQgb2Ygc2VxdWVuY2UuIEFkZGl0aW9uYWxseSwg cGFja2V0cyBhcmUgb25seSBzZW50IGhvcCBieSBob3AgKHNlY3Rpb24gMS4yLjEgYnVsbGV0IDMp IGFuZCBuZXZlciBmb3J3YXJkZWQuIEkgY2FuIHNlZSB0aGF0IGhhdmluZyBhIHBhY2tldCBzZXF1 ZW5jZSBudW1iZXIgY291bGQgYmUgdXNlZnVsIGZvciBzeXN0ZW0tbGV2ZWwgZGVidWdnaW5nLCBi dXQgb3RoZXJ3aXNlIEkgY2Fu4oCZdCBzZWUgdGhlIG5lZWQuDQoNCkJ1dCBJIGNhbi4gSXQncyB1 c2VmdWwgaW4gc29tZSBOSERQL09MU1J2MiBjb21iaW5hdGlvbnMgdG8gdHJhY2sgdGhlIGxpbmsg cmVsaWFiaWxpdHkuIEJ1dCBpZiB5b3Uga25vdyB5b3UgZG9uJ3QgY2FyZSwgdGhlIHRoYXQncyBh IFNIT1VMRCAtIGkuZS4geW91IG1hZGUgYW4gaW5mb3JtZWQgZGVjaXNpb24gbm90IHRvLCBzbyB5 b3UgY2FuIG5vdCBkby4NCg0KPiA0LjIsIHJlY2VwdGlvbiwgIkVhY2ggbWVzc2FnZSBNVVNUIGJl IHNlbnQgdG8gaXRzIG93bmluZyBwcm90b2NvbC7igJ0gQ2FuIHlvdSBjbGFyaWZ5IHRoYXQgaWYg YW4gZXh0ZW5zaW9uIHByb3RvY29sIGlzIGJlaW5nIHVzZWQsIHRoYXQgc3VjaCBhIHByb3RvY29s IG1pZ2h0IHdhbnQgb3IgbmVlZCB0byBwcm9jZXNzIHRoZSBtZXNzYWdlIGZpcnN0PyBCdWxsZXQg NCBkaXNjdXNzZXMgdGhlIGV4dGVuc2lvbiBwcm90b2NvbCB0b28uDQoNCk5vLiBJdCBnb2VzIHRv IHRoZSBiYXNlIHByb3RvY29sLiBJZiB5b3UgdGhpbmsgdGhlIGV4dGVuc2lvbiBwcm90b2NvbCBu ZWVkcyB0byBzZWUgaXQgZWFybHkgaW4gdGhlIHByb2Nlc3NpbmcsIHRoYXQncyB1cCB0byB5b3Ug dG8gc3BlY2lmeSBpbiB0aGUgYmFzZSBwcm90b2NvbCAob3IgaW4gYW4gZXh0ZW5zaW9uIGRyYWZ0 IHRoYXQgbW9kaWZpZXMgdGhlIGJhc2UgcHJvdG9jb2wpIGhvdyB0aGF0J3MgZG9uZS4NCg0KPiA2 LjQgIiBTdWNoIGEgcHJvdG9jb2wtaW5kZXBlbmRlbnQgb3B0aW1pemVyIE1BWSBiZSB1c2VkIGJ5 IHRoZSByb3V0ZXIgZ2VuZXJhdGluZyBhIG1lc3NhZ2UsIGJ1dCBNVVNUIE5PVCBiZSB1c2VkIG9u IGEgbWVzc2FnZSB0aGF0IGlzIGZvcndhcmRlZCB1bmNoYW5nZWQgYnkgYSByb3V0ZXIu4oCdIEkg dW5kZXJzdG9vZCB0aGF0IDU0NDQgb3BlcmF0ZXMgb25lIGhvcCBhdCBhIHRpbWUgYW5kIHRoZSBt ZXNzYWdlcyBhcmUgcHJlc2VudGVkIGJhY2sgdG8gdGhlIGhvc3QgcHJvdG9jb2wgZm9yIGFjdGlv bi4gSWYgdGhlIGhvc3QgcHJvdG9jb2wgY2hvb3NlcyB0byBmb3J3YXJkIHRoZSBtZXNzYWdlIHVu Y2hhbmdlZCwgSSB1bmRlcnN0YW5kIHRoYXQgaXQgd291bGQgYmUgbW9yZSBlZmZpY2llbnQgdG8g d2F2ZSB0aGUgbWVzc2FnZSB0aHJvdWdoIGF0IHRoZSA1NDQ0IGxldmVsLCBidXQgc3VyZWx5IHRo YXQgaXMgbm90IGFsbG93ZWQ/DQoNCkkgdGhpbmsgdGhpcyB3YXMgaW50ZW5kZWQgdG8gY2xhcmlm eSwgYnV0IG1heSBub3QgaGF2ZSBkb25lIHNvLiBBcyBub3RlZCwgcGFyc2luZyBpcyB1cCB0byB5 b3UuIEhvd2V2ZXIgd2hlbiB5b3UgYXJlIGNyZWF0aW5nIGEgbWVzc2FnZSBpbiB0aGUgcHJvdG9j b2wsIGFzIGEgbWF0dGVyIG9mIHByYWN0aWNhbCBpbXBsZW1lbnRhdGlvbiB5b3UgbWlnaHQgY2hv b3NlIHRvIG9wdGltaXNlIHRoZSBtZXNzYWdlLiBZb3UgbWlnaHQgYWxzbyBkZWNpZGUgdG8gd3Jp dGUgYW4gaW5kZXBlbmRlbnQgcGFyc2VyLiBZb3UgbWlnaHQgY2hvb3NlIHRvIGNvbWJpbmUgdGhl IHR3by4gQWxsIGdvb2QuIFlvdSBtaWdodCB0aGVuIGJlIHRlbXB0ZWQgdG8gdXNlIHRoZSBvcHRp bWlzaW5nIHBhcnNlciBpbiB0aGUgNTQ0NCBtdWx0aXBsZXhlciBpbiBhbiBpbnRlcm1lZGlhdGUg cm91dGVyLiBOb3QgZ29vZC4gVGhpcyBpcyBpbnRlbmRlZCB0byBzYXkgdGhhdCAtIGRvbid0IGRv IHRoaXMuIE9mIGNvdXJzZSBpZiB5b3Ugd2VyZSBuZXZlciB0ZW1wdGVkLCBub3QgYSBwcm9ibGVt Lg0KDQo+IEEgc3VnZ2VzdGlvbjogR2l2ZW4gdGhhdCBBT0RWdjIgaXMgdGhlIGZpcnN0IOKAnGN1 c3RvbWVy4oCdIGZvciA1NDQ0IG91dHNpZGUgb2YgdGhlIHRlYW0gdGhhdCBhbHNvIHdyb3RlIHRo ZSBPTFNSdjIgc2VyaWVzIFJGQ3MsDQoNCk5vdCBzby4gUkZDIDY2MjEuDQoNCj4gY2FuIHNvbWVv bmUgZnJvbSB0aGF0IHRlYW0gcGxlYXNlIHJldmlldyB0aGUgcmVsZXZhbnQgc2VjdGlvbnMgaW4g dGhlIEFPRFZ2MiBkcmFmdCBhbmQgYXNzZXNzIGhvdyB3ZWxsIHRoYXQgZHJhZnQgbWF0Y2hlcyB1 cCB0byB0aGlzIGRyYWZ0PyANCg0KSWYgc29tZW9uZSB3b3VsZCBmdW5kIG1lIHRvIGRvIHNvLCBJ J2QgYmUgZGVsaWdodGVkLiBJbiB0aGUgbWVhbndoaWxlIHRoYXQgd2lsbCBnZXQgZG9uZSBpZiBJ IGV2ZXIgZ2V0IHRoZSB0aW1lLiBBbmQgdGhlIHdob2xlIGFwcHJvYWNoIG9mIHRoZSBBT0RWdjIg YXV0aG9ycyBvZiBwcml2YXRlIGRpc2N1c3Npb25zIHRoYXQgYXJlbid0IGhlbGQgaGVyZSwgd2hl cmUgdGhleSBzaG91bGQgYmUsIGFuZCBmYWlsdXJlIHRvIGFzayBiYXNpYyBxdWVzdGlvbnMgeWVh cnMgYWdvIGluc3RlYWQgb2YgdGFsa2luZyBwcml2YXRlbHkgYW5kIHRoZW4gd2hlbiBjb21tZW50 cyBhcmUgcmVjZWl2ZWQgb2Z0ZW4gaWdub3JpbmcgdGhlbSAodGhlcmUgYXJlIGNvbW1lbnRzIEkg aGF2ZSBtYWRlIHNldmVyYWwgdGltZXMgb24gc2V2ZXJhbCBkcmFmdHMgYmVmb3JlIHRoZXkgZXZl bnR1YWxseSBoYXBwZW5lZCkgaXNuJ3QgYWN0dWFsbHkgaGVscGluZyB0aGF0IGhhcHBlbi4NCg0K PiBUaHVzIHNvbWVvbmUgY29taW5nIGFmdGVyIHVzIGNhbiBiZSBkaXJlY3RlZCB0byBBT0RWdjIg YXMgdGhlIGZpcnN0IOKAnGNvcnJlY3QiIGluZGVwZW5kZW50IHVzYWdlIGluIHRoZSBtYW5ldCB3 b3JraW5nIGdyb3VwICBvZiBSRkM1NDQ0LCBhbmQgY291bGQgbWVldCBhIHBvdGVudGlhbCBBRC1s ZXZlbCBxdWVzdGlvbiBvZiDigJhkaWQgd2UgZWF0IG91ciBvd24gZG9nIGZvb2Q/4oCZLiBJIHVz ZSDigJxjb3JyZWN04oCdIGhlcmUgbm90IHRvIHNheSB0aGF0IGFsbCBwb3RlbnRpYWwgdXNlIGNh c2VzIGFyZSBjb3ZlcmVkLCBidXQgYXQgbGVhc3QgQU9EVnYyIGNvcnJlY3RseSBmb2xsb3dzIHRo ZSBtb2RlbCB0aGF0IHRoZSBhdXRob3JzIG9mIDU0NDQgaW50ZW5kZWQuDQoNCkkgdGhpbmsgdGhp cyBmYWlscyB0byB0YWtlIG9uIGJvYXJkIHRoYXQgdGhlIGF1dGhvcnMgb2YgNTQ0NCBkaWRuJ3Qg c2V0IG91dCB0byBjcmVhdGUgc29tZXRoaW5nIGFuZCBmb2lzdCBpdCBvbiB5b3UsIHdoaWNoIGlz IGEgbWVzc2FnZSBJIGdldCB0b28gb2Z0ZW4gZnJvbSB0aGUgQU9EVnYyIGF1dGhvciB0ZWFtLiBX ZSBjcmVhdGVkIDU0NDQgZm9yIG91ciBwcm90b2NvbHMsIHRoZW4gd2VyZSBoYWxmIHBlcnN1YWRl ZCwgaGFsZiBib3VuY2VkLCBpbnRvIGdlbmVyYWxpc2luZyBpdCBieSBhIERZTU8gYXV0aG9yLiBT byB0aGUgaW50ZW50IHdhcyB0aGUgV0cgYXMgYSB3aG9sZSwgbm90IHNpbXBseSB0aGUgNTQ0NCBh dXRob3JzLg0KDQo+IEFuZCBmaW5hbGx5IOKApiBJ4oCZZCBzdGlsbCBsaWtlIHRvIHNlZSBldmVu IGEgbWluaW1hbCBBUEkgc3BlY2lmaWNhdGlvbiwgaXQgd291bGQgaGF2ZSBzYXZlZCBtZSBkYXlz IGlmIG5vdCB3ZWVrcyBvZiB3YXN0ZWQgZWZmb3J0IGdvaW5nIGluIHRoZSB3cm9uZyBkaXJlY3Rp b24uIA0KDQpBbmQgYWdhaW4uIE5vLiBOb3QgYXBwcm9wcmlhdGUuIEFuZCBJIHRoaW5rIGJhc2Vk IG9uIHRoZSBtaXNjb25jZXB0aW9uIEkgbm90ZSBhYm92ZSBhbmQgYmVsb3cuDQoNCj4gQWxzbywg SeKAmWQgc3RpbGwgbGlrZSB0byBzZWUgYSBzdGF0ZW1lbnQgb2YgY29tcG9uZW50cyB0aGF0IGFy ZSByZXNlcnZlZCBlbnRpcmVseSBmb3IgdXNlIGJ5IHRoZSA1NDQ0IHByb2Nlc3MsIGFuZCB3aGF0 IGNhbiBiZSB1c2VmdWxseSB1c2VkIGJ5IHRoZSBob3N0ZWQgcHJvdG9jb2wuDQoNCkRvbid0IHVu ZGVyc3RhbmQgdGhpcy4gSSB0aGluayBpdCdzIGJhc2VkIG9uIHRoZSBtaXNjb25jZXB0aW9uIHRo YXQgdGhlcmUncyBhIHBhcnNlciBvYmplY3QgaW4gdGhlIG11bHRpcGxleGVyLg0KDQpSZWdhcmRz DQpKb2huDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFu ZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVj aXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBz ZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBu b3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv bi4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioK From nobody Mon Apr 18 09:04:46 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 F227512DD1E for ; Mon, 18 Apr 2016 09:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.929 X-Spam-Level: **** X-Spam-Status: No, score=4.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FROM_MISSP_FREEMAIL=2.754, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, TO_NO_BRKTS_FROM_MSSP=2.499, T_FROM_MISSP_DKIM=0.01] 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 SYD7sDPBBFVx for ; Mon, 18 Apr 2016 09:04:43 -0700 (PDT) Received: from smtpsalv.upv.es (smtpsalv.cc.upv.es [158.42.249.11]) (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 0D8BE12DB72 for ; Mon, 18 Apr 2016 09:04:42 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by smtpsalv.upv.es (8.14.4/8.14.4) with ESMTP id u3IFtIK0003992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Apr 2016 17:55:18 +0200 Received: from smtp.upv.es (smtpv.cc.upv.es [158.42.249.16]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id u3IFtHDE021109 for ; Mon, 18 Apr 2016 17:55:18 +0200 Received: from JLLORET (pptp243-28.vpns.upv.es [158.42.243.28]) by smtp.upv.es (8.14.4/8.14.4) with SMTP id u3IFtGQr007843 for ; Mon, 18 Apr 2016 17:55:17 +0200 Date: Mon, 18 Apr 2016 17:55:17 +0200 Message-Id: <201604181555.u3IFtGQr007843@smtp.upv.es> From: Sandra Sendra To: manet@ietf.org CC: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Subject: [manet] Deadline April 24: GreeNets 2016, June 27-28, 2016 - Valencia, Spain 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, 18 Apr 2016 16:04:45 -0000 ==================================================================================== 3rd EAI International Conference on Green Communications and Networking - GreeNets 2016 June 27-28, 2016 Valencia, Spain http://greenets.org/2016/show/home Submission Deadline: April 24, 2016 ==================================================================================== CALL FOR PAPERS [Scope] Global warming and climate change have been a growing worldwide concern. Six sources, i.e., transportation, power, buildings, industry, agriculture and forestry, and land use, have been identified as major contributors to the rise of global carbon dioxide (CO2). The mobile industry is seen as a potential enabler to reduce greenhouse gases contributed by these six sources provided that appropriate measures are implemented. On the other hand, the mobile industry itself will also contribute to CO2 emission through network operations, mobile equipments, etc. To meet the requirement of low-carbon economy development, it is necessary to reduce the operation expenditure or energy consumption of mobile networks, while maintaining acceptable quality of service. This conference will explore and explain the scope and challenges of designing, building, and deploying GreeNets. In this regard, the conference aims to establish a forum to bring together research professionals from diverse f! ields including green mobile networ ks, system architectures, networking & communication protocols, applications, test-bed and prototype, traffic balance and energy-efficient cooperation transmission, system and application issues related to GreeNets. [Topics] The conference invites original technical papers that were not previously published and are not currently under review for publication elsewhere. Topics include, but are not limited to: - Communications and Networking: Communication techniques and protocols for GreeNets Energy-efficient transmission technologies based on the cooperation communication Scalable and flexible energy efficiency mobile network architectures, deployments, and applications - Energy-efficient network architecture & protocols: Scalability and mobility issues in energy efficiency cross-layer design MAC Protocols and QoS Designing for mobile networks - Systems and Technology: Transactions and workflows in green mobile networks Adaptability and stability of green mobile networks Mobile and multimedia supported green mobile networks Experimental and test bed studies for energy efficiency mobile networks, simulation tools - Energy-efficient management: Energy-efficient traffic balance, cooperation and management Distributed energy efficiency resource management techniques Protocols for cooperative management and control [Highlights] - Selected papers will be invited to a Special Issue on Green Communications and Networking 2016 in: International Journal ACM/Springer Mobile Networks & Applications (MONET): http://www.springer.com/engineering/signals/journal/11036 - Selected papers will be invited to publish in the EAI Endorsed Transactions on Energy Web and in the special issue of EAI Transactions on Intelligent Communication Protocols and Algorithms (http://eai.eu/transaction/intelligent-communication-protocols-and-algorithms). - Proceedings are submitted for inclusion to the leading indexing services: DBLP, Google Scholar, Thomson Scientific ISI Proceedings, EI Elsevier Engineering Index, CrossRef, Scopus, as well as ICST's own EU Digital Library (EUDL). - All accepted papers will be submitted for publication in Springer and made available through SpringerLink Digital Library, one of the world's largest scientific libraries. - All participants are invited to enjoy walking tour "Emblematic Valencia" which is organized on 27th June. The tour starts at 5pm! [Paper submission] - Papers should be in English. - Regular papers should be up to 8 pages in length. - Previously published work may not be submitted, nor may the work be concurrently submitted to any other conference or journal. Such papers will be rejected without review. - The paper submissions must follow the SPRINGER formatting guidelines: http://greenets.org/2016/show/authors-kit - All the papers formatted according with the instructions have to be submitted through the conference online system at: http://greenets.org/2016/show/initial-submission ==================================================================================== GreeNets 2016 also seeks proposals for posters and live demonstrations describing novel work on green mobile networks, system architectures, networking and communication protocols, applications, test-bed and prototype, traffic balance and energy-efficient cooperation transmission, system and application issues related to GreeNets. Posters and demonstrations will be presented during a reception at the conference. The poster/demo session is meant to introduce new and ongoing work and provide opportunities for authors to interact directly with conference attendees. Posters sessions provide a forum for researchers to present their work in progress that can generate discussion or promising new ideas from experts. On the other hand, live demos session will offer a unique opportunity to showcase real prototypes, tools, and systems to the conference attendees. The areas of interest for both poster and demo abstracts are the same as for full research papers. [Demo/Poster submission] - Demo and poster abstracts must not exceed 3 pages. Titles should start with "Poster: ..." or "Demo: ..." depending on the case. The page limits include figures, tables, and references. Submissions may not be anonymous. - Please use the main GreeNets conference paper style (http://greenets.org/2016/show/authors-kit) and submission guidelines. - Poster and demo abstracts will be reviewed by at least three members of the poster/demo committee to ensure quality and matching to the goals of the poster/demo session as well as to the conference?s topics. Accepted poster and demo abstracts will be included in the conference proceedings. Demo and poster proposals should include the following: - The purpose and goals of the work. - Any background and motivation needed to understand the work. - Any critical hypotheses and assumptions that underlie the work. - A clear summary of the contribution and/or results, in sufficient detail for a (re)viewer to understand the work and its relevance. If the work is at an initial stage, it is especially important to state clearly the anticipated contributions and any early results towards them. - The relationship to other related efforts, where appropriate. Authors of accepted posters may be asked to point out relationships to work represented by other accepted posters. - Where to find additional information (a web site where viewers can go to find additional information about the work how to contact the authors, including email addresses citations for any papers, books, or other materials that provide additional information) If selected, authors shall prepare a final, camera ready version of the extended abstract, taking into account all feedback from reviewers, and formatted according to the GreeNets conference. [Presentation at the conference] In addition to space given to every accepted abstract during the poster/demo session, one author of the abstract will be given a slot in a further "10-minute madness" session within the main program. In this session, authors will have the opportunity to describe their work to the entire conference audience with a single slide and a 10-minute speech. ==================================================================================== [Important dates] Full Paper Deadline: April 24, 2016 Notification of Acceptance: May 10 2016 Camera-ready Deadline: May 29, 2016 Conference dates: 27th - 28th June 2016 [Conference organising committees] General Chair: Jaime Lloret, Universidad Politecnica de Valencia, Spain TPC Chair: Elsa Macias-López, Las Palmas de Gran Canaria University, Spain Publicity and Social Media Chair / Co-Chairs: Kayhan Zrar Ghafoor, Koya University, Iraq Workshops Chair: Sabu M. Thampi, Indian Institute of Information Technology and Management- Kerala (IIITM-K), India Sponsorship & Exhibits Chair: Raquel Lacuesta, University of Zaragoza Publications Chair: Jose Miguel Jimenez, Integrated Management Coastal Research Institute, Universidad Politecnica de Valencia,Spain Lorena Parra, Integrated Management Coastal Research Institute, Universidad Politecnica de Valencia,Spain Panels Chair: Milos Stojmenovic, Singidunum University,Belgrade, Serbia Tutorials Chair: Jose Maria Alcaraz, University of the West of Scotland, Scotland,UK Demos, Posters and PhD Track Chair: Gregorio Martinez, University of Murcia, Spain Local Chair: Sandra Sendra, Integrated Management Coastal Research Institute, Universidad Politécnica de Valencia, Spain Web Chair: Alejandro Canovas, Integrated Management Coastal Research Institute, Universidad Politécnica de Valencia,Spain ==================================================================================== ABOUT EAI The European Alliance for Innovation is a dynamic eco-system for fostering ICT enabled innovation to improve European competitiveness and to benefit society. EAI uses open e-platforms to inspire grassroots collaboration among all relevant actors, from organizations to individuals, to stimulate community driven innovation to its institutional and individual members worldwide. Through EAI, organizations find ideas and talent, and individual innovators find organizations for their ingenuity and craft. Join the innovation community at www.eai.eu From nobody Mon Apr 18 09:14:51 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 DDDA312DFB1 for ; Mon, 18 Apr 2016 09:14:49 -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 T1y5VI5DknOx for ; Mon, 18 Apr 2016 09:14:48 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 2398212DA60 for ; Mon, 18 Apr 2016 09:14:47 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id f105so118933360qge.2 for ; Mon, 18 Apr 2016 09:14: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=NV/7AqgtYkpkXS4+rIqVzX+njz1nzuU4LUeZJA9CY18=; b=q0+aOvQPui/FioLBXjlygrOPRlFfEdgTC5ySa6iJNx+x4lMTQGjltiIvckNasXYfoP mQ5FagBXHPO/O7A0styz+cHbJqxWbPHMkg1qJA/aIhBpB1FQ09F/FMZEk/ueO9Mj/+RW PGA8CvLB2XTYn7YUVQqG76bPxWzvVJjO4NOS111zv7vgdP64CnbHQZ5gC0MONUbI0axG 5HVVesQkr5IPS9Y+AjE1XN1hLTab+kklQ9zJ612jZCC5R4KDvj09+r7oOxcFU055Em/A 5IKpMliNy2PJAWBy7Uiu8wnZmrR2ZKhDIyO947g41PyO19+DsZ6QpeQM+0+IT+xSLedT fTTw== 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=NV/7AqgtYkpkXS4+rIqVzX+njz1nzuU4LUeZJA9CY18=; b=FBmm09rGNn+/y7VG3EAM2ZMAAYXsRpjvSxAPrWMyo9kEfvzR885MiQq0/dICU2Oprw KleNKCp8vTZ49mbTW05AIH+Jj99YdS2WQoirUf7qSC5XMZ8XGZtGVYM+pG/d7YAic5zZ L0ThHBhMheqg/VdSz1wYPaQChQX/fhppkE+YoqSrdzQpNYVrQ5Db3f2/Yjl4dL4KrJGJ Rj8ViQbc4DD9JoCm7X9j4C4aj0/kDgu5oFsdp4ZUVLSTHymHKkLGG625HmJjcwMTJQz8 EF20GGqFB2ynI7j/ucb1vcxLYdAUrjNAd60qlUVUxF1kukxihvxfnGpFqLqycHC6+RGV 8c2w== X-Gm-Message-State: AOPr4FXepJOMXgJxTLVhk4ukArLVzkzrZBls7iWDEmlrVVsndyMmZ+w3LPl70rIFZN7SLoHxglTykJ21SUrZYw== MIME-Version: 1.0 X-Received: by 10.140.28.36 with SMTP id 33mr21183073qgy.47.1460996086194; Mon, 18 Apr 2016 09:14:46 -0700 (PDT) Received: by 10.140.43.131 with HTTP; Mon, 18 Apr 2016 09:14:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Apr 2016 18:14:46 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a113a9a64bc74200530c4a881 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] RFC 5444 usage - one specific point. 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, 18 Apr 2016 16:14:50 -0000 --001a113a9a64bc74200530c4a881 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable IMO. The number of packets is not the only thing that multiplexer should look into but the time is important as well. The draft may need to show efficiency not only looking at number of packets sent but also number of messages in a packet. The draft must mention the delay of multiplexing if it is stating efficiency, however, it is delaying packets not messages. Therefore, the texts mentioned in your message needs to say that multiplexer may delay packets. However, there is a need to determine this in the draft. AB On Mon, Apr 18, 2016 at 2:12 PM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > Multiplexer efficiency is straightforward - if you put two messages in on= e > packet you save a packet transmission. On some MACs as long as packets ar= e > of reasonable size, the packet size is pretty irrelevant, only the number > of packets matters. > > > > There=E2=80=99s a good synergy of this with RFC 5148 if you are using tha= t, but > that=E2=80=99s not the subject here. > > > > And as for changing to lower case, don=E2=80=99t do that. It is overwhelm= ingly > good practice that in normative sections of a report, use MAY, SHOULD,. > MUST etc. as 2119 terms and avoid all other use of those words. But here, > as I have said, I think SHOULD is appropriate. > > > > *-- * > > > > > *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:* Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > *Sent:* 18 April 2016 13:03 > *To:* Henning Rogge > *Cc:* Dearlove, Christopher (UK); manet@ietf.org > *Subject:* Re: [manet] RFC 5444 usage - one specific point. > > > > > > **** 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 Mon, Apr 18, 2016 at 12:13 PM, Henning Rogge wrote: > > On Mon, Apr 18, 2016 at 11:07 AM, Dearlove, Christopher (UK) > wrote: > > So far I see one specific point for WG agreement - anything else is > editorial. (Editorial matters, but it's not changing rules, so I'm trying > here to address one specific rule issue.) Some comments have clearly > overlooked this, but whether to telegraph it further (e.g. mention in > non-normative introduction) is back to editorial. > > > > The draft currently says: > > > > o The multiplexer MAY delay messages briefly in order to assemble > > more efficient packets. It SHOULD respect any constraints on suc= h > > delays requested by the protocol. > > > > Should we change that SHOULD to a MUST? Obviously IETF-style we don't > run votes as such, but what are people's opinions? > > Unless we specify what kind of "constraints" a protocol can specify, a > MUST would be a bit strange. > > > > IMO, I think it is not efficient to delay messages, I think it is strange > to delay without saying how much that multiplexer is delaying to get to > efficiency, so it seems that multiplexer efficiency is needed to be defin= ed > because it can be different than protocol efficiency. > > Therefore, I think we should change MAY to may and SHOULD to should, or i= f > not changed we need to specify a maximum delay for the multiplexer, becau= se > leaving it without limit is not correct. > > > > > As I see it: > > > > Argument for MUST: If the protocol has strong requirements the > multiplexer needs to respect those. > > > > Argument for SHOULD: But the protocol might make an impossible demand, > such as zero delay when we all know nothing has zero delay. SHOULD isn't > MAY, it needs to do its best. > > > > Possible third course, something like (open to wordsmithing - I > considered putting the caveat at the end, for example). > > > > o The multiplexer MAY delay messages briefly in order to assemble > > more efficient packets. It MUST, as far as possible, respect any > > constraints on such delays requested by the protocol. > > > > Argument against third course, we've seen before that anything that > includes wording like that is open to IESG not being happy. > > > > On balance, I think SHOULD is appropriate, assuming SHOULD is > interpreted as it should be - do this unless there really is a good reaso= n > not to. But I could live with any of the three (if allowed). > > SHOULD would be okay... especially because (normally) multiplexer > would restrict the amount of constraints of the protocol by its API > anyways. > > > > IMO, It should say that the multiplexer MUST NOT delay messages if the > protocol request constraints on delay. We don't want to change the > multiplexer into having its own protocol without having a RFC for it. > > AB > > ******************************************************************** > 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. > ******************************************************************** > --001a113a9a64bc74200530c4a881 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IMO. The number of packets is not the only thing that= multiplexer should look into but the time is important as well. The draft = may need to show efficiency not only looking at number of packets sent but = also number of messages in a packet. The draft must mention the delay of mu= ltiplexing if it is stating efficiency, however, it is delaying packets not= messages. Therefore, the texts mentioned in your message needs to say that= multiplexer may delay packets. However, there is a need to determine this = in the draft.

AB

On Mon, Apr 18, 2016 at 2:12 PM, Dearlove, Christophe= r (UK) <chris.dearlove@baesystems.com> wrote:

Multiplexer efficiency is= straightforward - if you put two messages in one packet you save a packet = transmission. On some MACs as long as packets are of reasonable size, the packet size is pretty irrelevant, only the number of packets mat= ters.

=C2=A0

There=E2=80=99s a good sy= nergy of this with RFC 5148 if you are using that, but that=E2=80=99s not t= he subject here.

=C2=A0

And as for changing to lo= wer case, don=E2=80=99t do that. It is overwhelmingly good practice that in= normative sections of a report, use MAY, SHOULD,. MUST etc. as 2119 terms and avoid all other use of those words. But here, as I have sai= d, I think SHOULD is appropriate.

=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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 18 April 2016 13:03
To: Henning Rogge
Cc: Dearlove, Christopher (UK); manet@ietf.org
Subject: Re: [manet] RFC 5444 usage - one specific point.<= /u>

=C2=A0

=C2=A0

*** WARNING ***

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.
For 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 Mon, Apr 18, 2016 at 12:13 PM, Henning Rogge <= hrogge@gmail.com&= gt; wrote:

On Mon, Apr 18, 2016 at 11:07 AM, Dearlove, Christop= her (UK)
<chri= s.dearlove@baesystems.com> wrote:
> So far I see one specific point for WG agreement - anything else is ed= itorial. (Editorial matters, but it's not changing rules, so I'm tr= ying here to address one specific rule issue.) Some comments have clearly o= verlooked this, but whether to telegraph it further (e.g. mention in non-normative introduction) is back to editorial.=
>
> The draft currently says:
>
>=C2=A0 =C2=A0 o=C2=A0 The multiplexer MAY delay messages briefly in ord= er to assemble
>=C2=A0 =C2=A0 =C2=A0 =C2=A0more efficient packets.=C2=A0 It SHOULD resp= ect any constraints on such
>=C2=A0 =C2=A0 =C2=A0 =C2=A0delays requested by the protocol.
>
> Should we change that SHOULD to a MUST? Obviously IETF-style we don= 9;t run votes as such, but what are people's opinions?

Unless we specify what kind of "constraints" a protocol can speci= fy, a
MUST would be a bit strange.

=C2=A0

IMO, I think it is no= t efficient to delay messages, I think it is strange to delay without sayin= g how much that multiplexer is delaying to get to efficiency, so it seems t= hat multiplexer efficiency is needed to be defined because it can be different than protocol efficiency.

Therefore, I think we should change MAY to may and S= HOULD to should, or if not changed we need to specify a maximum delay for t= he multiplexer, because leaving it without limit is not correct.
=C2=A0


> As I see it:
>
> Argument for MUST: If the protocol has strong requirements the multipl= exer needs to respect those.
>
> Argument for SHOULD: But the protocol might make an impossible demand,= such as zero delay when we all know nothing has zero delay. SHOULD isn'= ;t MAY, it needs to do its best.
>
> Possible third course, something like (open to wordsmithing - I consid= ered putting the caveat at the end, for example).
>
>=C2=A0 =C2=A0 o=C2=A0 The multiplexer MAY delay messages briefly in ord= er to assemble
>=C2=A0 =C2=A0 =C2=A0 =C2=A0more efficient packets.=C2=A0 It MUST, as fa= r as possible, respect any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0constraints on such delays requested by the = protocol.
>
> Argument against third course, we've seen before that anything tha= t includes wording like that is open to IESG not being happy.
>
> On balance, I think SHOULD is appropriate, assuming SHOULD is interpre= ted as it should be - do this unless there really is a good reason not to. = But I could live with any of the three (if allowed).

SHOULD would be okay... especially because (normally) multiplexer
would restrict the amount of constraints of the protocol by its API
anyways.

=C2=A0

IMO, It should say th= at the multiplexer MUST NOT delay messages if the protocol request constrai= nts on delay. We don't want to change the multiplexer into having its o= wn protocol without having a RFC for it.

AB

********************************************************************
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.
********************************************************************=


--001a113a9a64bc74200530c4a881-- From nobody Mon Apr 18 09:18: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 B9BA812E1FE for ; Mon, 18 Apr 2016 09:18:36 -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 u6HU_zXh-aFk for ; Mon, 18 Apr 2016 09:18:33 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [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 8E52212E1F7 for ; Mon, 18 Apr 2016 09:17:28 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,503,1454976000"; d="scan'208,217"; a="61887815" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 18 Apr 2016 17:17:27 +0100 X-IronPort-AV: E=Sophos;i="5.24,503,1454976000"; d="scan'208,217";a="114460453" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 18 Apr 2016 17:17:26 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 17:17:26 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] RFC 5444 usage - one specific point. Thread-Index: AdGZUYEwrOFrZPQQR8i4HCwA3Y0EVAAAQ4MAAAPVsAAAAkM7QAAGhfQAAAIeMoA= Date: Mon, 18 Apr 2016 16:17:26 +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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ADB11GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] RFC 5444 usage - one specific point. 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, 18 Apr 2016 16:18:37 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ADB11GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGRyYWZ0IGFscmVhZHkgc2F5cyB0aGF0IGEgbXVsdGlwbGV4ZXIgbWF5IGRlbGF5IHBhY2tl dHMuIEhlbmNlIGJ5IG9idmlvdXMgaW1wbGljYXRpb24gaXQgbWF5IGNob29zZSBub3QgdG8uIEl0 IHNheXMgaXQgbWlnaHQgZGVsYXkgZm9yIGVmZmljaWVuY3kuIE9idmlvdXNseSBpdCB3b3VsZCBu b3QgZGVsYXkgaWYgdGhlIHRyYWRlb2ZmIHdlcmUgZGVlbWVkIHVuc2F0aXNmYWN0b3J5LiBQYXJ0 IG9mIHRoZSBsYXR0ZXIgaXMgdGhhdCB0aGUgcHJvdG9jb2wgbWlnaHQgY2hvb3NlIHRvIG1ha2Ug YSBzdWdnZXN0aW9uIGFzIHRvIHdoYXQgbWF0dGVycyB0byBpdC4NCg0KLS0NCkNocmlzdG9waGVy IERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVk IEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQg KDApMTI0NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0 bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJ bnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENo ZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3 dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExp bWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0 ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1Uy IDdZUA0KDQpGcm9tOiBBYmR1c3NhbGFtIEJhcnl1biBbbWFpbHRvOmFiZHVzc2FsYW1iYXJ5dW5A Z21haWwuY29tXQ0KU2VudDogMTggQXByaWwgMjAxNiAxNzoxNQ0KVG86IERlYXJsb3ZlLCBDaHJp c3RvcGhlciAoVUspDQpDYzogSGVubmluZyBSb2dnZTsgbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbbWFuZXRdIFJGQyA1NDQ0IHVzYWdlIC0gb25lIHNwZWNpZmljIHBvaW50Lg0KDQoNCioq KiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBv cmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVy bmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkg bGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJl Z2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91 IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9o b3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4N CklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMg cHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1 cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBF bWFpbHMucGRmPi4NCklNTy4gVGhlIG51bWJlciBvZiBwYWNrZXRzIGlzIG5vdCB0aGUgb25seSB0 aGluZyB0aGF0IG11bHRpcGxleGVyIHNob3VsZCBsb29rIGludG8gYnV0IHRoZSB0aW1lIGlzIGlt cG9ydGFudCBhcyB3ZWxsLiBUaGUgZHJhZnQgbWF5IG5lZWQgdG8gc2hvdyBlZmZpY2llbmN5IG5v dCBvbmx5IGxvb2tpbmcgYXQgbnVtYmVyIG9mIHBhY2tldHMgc2VudCBidXQgYWxzbyBudW1iZXIg b2YgbWVzc2FnZXMgaW4gYSBwYWNrZXQuIFRoZSBkcmFmdCBtdXN0IG1lbnRpb24gdGhlIGRlbGF5 IG9mIG11bHRpcGxleGluZyBpZiBpdCBpcyBzdGF0aW5nIGVmZmljaWVuY3ksIGhvd2V2ZXIsIGl0 IGlzIGRlbGF5aW5nIHBhY2tldHMgbm90IG1lc3NhZ2VzLiBUaGVyZWZvcmUsIHRoZSB0ZXh0cyBt ZW50aW9uZWQgaW4geW91ciBtZXNzYWdlIG5lZWRzIHRvIHNheSB0aGF0IG11bHRpcGxleGVyIG1h eSBkZWxheSBwYWNrZXRzLiBIb3dldmVyLCB0aGVyZSBpcyBhIG5lZWQgdG8gZGV0ZXJtaW5lIHRo aXMgaW4gdGhlIGRyYWZ0Lg0KQUINCg0KT24gTW9uLCBBcHIgMTgsIDIwMTYgYXQgMjoxMiBQTSwg RGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgPGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t PG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4+IHdyb3RlOg0KTXVsdGlwbGV4 ZXIgZWZmaWNpZW5jeSBpcyBzdHJhaWdodGZvcndhcmQgLSBpZiB5b3UgcHV0IHR3byBtZXNzYWdl cyBpbiBvbmUgcGFja2V0IHlvdSBzYXZlIGEgcGFja2V0IHRyYW5zbWlzc2lvbi4gT24gc29tZSBN QUNzIGFzIGxvbmcgYXMgcGFja2V0cyBhcmUgb2YgcmVhc29uYWJsZSBzaXplLCB0aGUgcGFja2V0 IHNpemUgaXMgcHJldHR5IGlycmVsZXZhbnQsIG9ubHkgdGhlIG51bWJlciBvZiBwYWNrZXRzIG1h dHRlcnMuDQoNClRoZXJl4oCZcyBhIGdvb2Qgc3luZXJneSBvZiB0aGlzIHdpdGggUkZDIDUxNDgg aWYgeW91IGFyZSB1c2luZyB0aGF0LCBidXQgdGhhdOKAmXMgbm90IHRoZSBzdWJqZWN0IGhlcmUu DQoNCkFuZCBhcyBmb3IgY2hhbmdpbmcgdG8gbG93ZXIgY2FzZSwgZG9u4oCZdCBkbyB0aGF0LiBJ dCBpcyBvdmVyd2hlbG1pbmdseSBnb29kIHByYWN0aWNlIHRoYXQgaW4gbm9ybWF0aXZlIHNlY3Rp b25zIG9mIGEgcmVwb3J0LCB1c2UgTUFZLCBTSE9VTEQsLiBNVVNUIGV0Yy4gYXMgMjExOSB0ZXJt cyBhbmQgYXZvaWQgYWxsIG90aGVyIHVzZSBvZiB0aG9zZSB3b3Jkcy4gQnV0IGhlcmUsIGFzIEkg aGF2ZSBzYWlkLCBJIHRoaW5rIFNIT1VMRCBpcyBhcHByb3ByaWF0ZS4NCg0KLS0NCkNocmlzdG9w aGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBs aWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICAr NDQgKDApMTI0NSAyNDIxOTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBF OiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFl c3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNm b3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIg OEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+ DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGlu IEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkg UmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTogQWJkdXNz YWxhbSBCYXJ5dW4gW21haWx0bzphYmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbTxtYWlsdG86YWJk dXNzYWxhbWJhcnl1bkBnbWFpbC5jb20+XQ0KU2VudDogMTggQXByaWwgMjAxNiAxMzowMw0KVG86 IEhlbm5pbmcgUm9nZ2UNCkNjOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgbWFuZXRAaWV0 Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFttYW5ldF0gUkZDIDU0 NDQgdXNhZ2UgLSBvbmUgc3BlY2lmaWMgcG9pbnQuDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlz IG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVy IGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJl ZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0 YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0 aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVy ZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9z cG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVt YWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRy YW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9j dW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KDQoNCk9u IE1vbiwgQXByIDE4LCAyMDE2IGF0IDEyOjEzIFBNLCBIZW5uaW5nIFJvZ2dlIDxocm9nZ2VAZ21h aWwuY29tPG1haWx0bzpocm9nZ2VAZ21haWwuY29tPj4gd3JvdGU6DQpPbiBNb24sIEFwciAxOCwg MjAxNiBhdCAxMTowNyBBTSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNCjxjaHJpcy5kZWFy bG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+ PiB3cm90ZToNCj4gU28gZmFyIEkgc2VlIG9uZSBzcGVjaWZpYyBwb2ludCBmb3IgV0cgYWdyZWVt ZW50IC0gYW55dGhpbmcgZWxzZSBpcyBlZGl0b3JpYWwuIChFZGl0b3JpYWwgbWF0dGVycywgYnV0 IGl0J3Mgbm90IGNoYW5naW5nIHJ1bGVzLCBzbyBJJ20gdHJ5aW5nIGhlcmUgdG8gYWRkcmVzcyBv bmUgc3BlY2lmaWMgcnVsZSBpc3N1ZS4pIFNvbWUgY29tbWVudHMgaGF2ZSBjbGVhcmx5IG92ZXJs b29rZWQgdGhpcywgYnV0IHdoZXRoZXIgdG8gdGVsZWdyYXBoIGl0IGZ1cnRoZXIgKGUuZy4gbWVu dGlvbiBpbiBub24tbm9ybWF0aXZlIGludHJvZHVjdGlvbikgaXMgYmFjayB0byBlZGl0b3JpYWwu DQo+DQo+IFRoZSBkcmFmdCBjdXJyZW50bHkgc2F5czoNCj4NCj4gICAgbyAgVGhlIG11bHRpcGxl eGVyIE1BWSBkZWxheSBtZXNzYWdlcyBicmllZmx5IGluIG9yZGVyIHRvIGFzc2VtYmxlDQo+ICAg ICAgIG1vcmUgZWZmaWNpZW50IHBhY2tldHMuICBJdCBTSE9VTEQgcmVzcGVjdCBhbnkgY29uc3Ry YWludHMgb24gc3VjaA0KPiAgICAgICBkZWxheXMgcmVxdWVzdGVkIGJ5IHRoZSBwcm90b2NvbC4N Cj4NCj4gU2hvdWxkIHdlIGNoYW5nZSB0aGF0IFNIT1VMRCB0byBhIE1VU1Q/IE9idmlvdXNseSBJ RVRGLXN0eWxlIHdlIGRvbid0IHJ1biB2b3RlcyBhcyBzdWNoLCBidXQgd2hhdCBhcmUgcGVvcGxl J3Mgb3BpbmlvbnM/DQoNClVubGVzcyB3ZSBzcGVjaWZ5IHdoYXQga2luZCBvZiAiY29uc3RyYWlu dHMiIGEgcHJvdG9jb2wgY2FuIHNwZWNpZnksIGENCk1VU1Qgd291bGQgYmUgYSBiaXQgc3RyYW5n ZS4NCg0KSU1PLCBJIHRoaW5rIGl0IGlzIG5vdCBlZmZpY2llbnQgdG8gZGVsYXkgbWVzc2FnZXMs IEkgdGhpbmsgaXQgaXMgc3RyYW5nZSB0byBkZWxheSB3aXRob3V0IHNheWluZyBob3cgbXVjaCB0 aGF0IG11bHRpcGxleGVyIGlzIGRlbGF5aW5nIHRvIGdldCB0byBlZmZpY2llbmN5LCBzbyBpdCBz ZWVtcyB0aGF0IG11bHRpcGxleGVyIGVmZmljaWVuY3kgaXMgbmVlZGVkIHRvIGJlIGRlZmluZWQg YmVjYXVzZSBpdCBjYW4gYmUgZGlmZmVyZW50IHRoYW4gcHJvdG9jb2wgZWZmaWNpZW5jeS4NClRo ZXJlZm9yZSwgSSB0aGluayB3ZSBzaG91bGQgY2hhbmdlIE1BWSB0byBtYXkgYW5kIFNIT1VMRCB0 byBzaG91bGQsIG9yIGlmIG5vdCBjaGFuZ2VkIHdlIG5lZWQgdG8gc3BlY2lmeSBhIG1heGltdW0g ZGVsYXkgZm9yIHRoZSBtdWx0aXBsZXhlciwgYmVjYXVzZSBsZWF2aW5nIGl0IHdpdGhvdXQgbGlt aXQgaXMgbm90IGNvcnJlY3QuDQoNCg0KPiBBcyBJIHNlZSBpdDoNCj4NCj4gQXJndW1lbnQgZm9y IE1VU1Q6IElmIHRoZSBwcm90b2NvbCBoYXMgc3Ryb25nIHJlcXVpcmVtZW50cyB0aGUgbXVsdGlw bGV4ZXIgbmVlZHMgdG8gcmVzcGVjdCB0aG9zZS4NCj4NCj4gQXJndW1lbnQgZm9yIFNIT1VMRDog QnV0IHRoZSBwcm90b2NvbCBtaWdodCBtYWtlIGFuIGltcG9zc2libGUgZGVtYW5kLCBzdWNoIGFz IHplcm8gZGVsYXkgd2hlbiB3ZSBhbGwga25vdyBub3RoaW5nIGhhcyB6ZXJvIGRlbGF5LiBTSE9V TEQgaXNuJ3QgTUFZLCBpdCBuZWVkcyB0byBkbyBpdHMgYmVzdC4NCj4NCj4gUG9zc2libGUgdGhp cmQgY291cnNlLCBzb21ldGhpbmcgbGlrZSAob3BlbiB0byB3b3Jkc21pdGhpbmcgLSBJIGNvbnNp ZGVyZWQgcHV0dGluZyB0aGUgY2F2ZWF0IGF0IHRoZSBlbmQsIGZvciBleGFtcGxlKS4NCj4NCj4g ICAgbyAgVGhlIG11bHRpcGxleGVyIE1BWSBkZWxheSBtZXNzYWdlcyBicmllZmx5IGluIG9yZGVy IHRvIGFzc2VtYmxlDQo+ICAgICAgIG1vcmUgZWZmaWNpZW50IHBhY2tldHMuICBJdCBNVVNULCBh cyBmYXIgYXMgcG9zc2libGUsIHJlc3BlY3QgYW55DQo+ICAgICAgIGNvbnN0cmFpbnRzIG9uIHN1 Y2ggZGVsYXlzIHJlcXVlc3RlZCBieSB0aGUgcHJvdG9jb2wuDQo+DQo+IEFyZ3VtZW50IGFnYWlu c3QgdGhpcmQgY291cnNlLCB3ZSd2ZSBzZWVuIGJlZm9yZSB0aGF0IGFueXRoaW5nIHRoYXQgaW5j bHVkZXMgd29yZGluZyBsaWtlIHRoYXQgaXMgb3BlbiB0byBJRVNHIG5vdCBiZWluZyBoYXBweS4N Cj4NCj4gT24gYmFsYW5jZSwgSSB0aGluayBTSE9VTEQgaXMgYXBwcm9wcmlhdGUsIGFzc3VtaW5n IFNIT1VMRCBpcyBpbnRlcnByZXRlZCBhcyBpdCBzaG91bGQgYmUgLSBkbyB0aGlzIHVubGVzcyB0 aGVyZSByZWFsbHkgaXMgYSBnb29kIHJlYXNvbiBub3QgdG8uIEJ1dCBJIGNvdWxkIGxpdmUgd2l0 aCBhbnkgb2YgdGhlIHRocmVlIChpZiBhbGxvd2VkKS4NCg0KU0hPVUxEIHdvdWxkIGJlIG9rYXku Li4gZXNwZWNpYWxseSBiZWNhdXNlIChub3JtYWxseSkgbXVsdGlwbGV4ZXINCndvdWxkIHJlc3Ry aWN0IHRoZSBhbW91bnQgb2YgY29uc3RyYWludHMgb2YgdGhlIHByb3RvY29sIGJ5IGl0cyBBUEkN CmFueXdheXMuDQoNCklNTywgSXQgc2hvdWxkIHNheSB0aGF0IHRoZSBtdWx0aXBsZXhlciBNVVNU IE5PVCBkZWxheSBtZXNzYWdlcyBpZiB0aGUgcHJvdG9jb2wgcmVxdWVzdCBjb25zdHJhaW50cyBv biBkZWxheS4gV2UgZG9uJ3Qgd2FudCB0byBjaGFuZ2UgdGhlIG11bHRpcGxleGVyIGludG8gaGF2 aW5nIGl0cyBvd24gcHJvdG9jb2wgd2l0aG91dCBoYXZpbmcgYSBSRkMgZm9yIGl0Lg0KQUINCg0K KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioNClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50 aWFsIHRvIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2Vk LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0 IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLg0KWW91IHNob3VsZCBub3Qg Y29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcg0KZGlzdHJp YnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4NCioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ADB11GLKXM0002VGREEN_ 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 LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBkcmFmdCBhbHJlYWR5IHNheXMgdGhh dCBhIG11bHRpcGxleGVyIG1heSBkZWxheSBwYWNrZXRzLiBIZW5jZSBieSBvYnZpb3VzIGltcGxp Y2F0aW9uIGl0IG1heSBjaG9vc2Ugbm90IHRvLiBJdCBzYXlzIGl0IG1pZ2h0IGRlbGF5IGZvciBl ZmZpY2llbmN5LiBPYnZpb3VzbHkNCiBpdCB3b3VsZCBub3QgZGVsYXkgaWYgdGhlIHRyYWRlb2Zm IHdlcmUgZGVlbWVkIHVuc2F0aXNmYWN0b3J5LiBQYXJ0IG9mIHRoZSBsYXR0ZXIgaXMgdGhhdCB0 aGUgcHJvdG9jb2wgbWlnaHQgY2hvb3NlIHRvIG1ha2UgYSBzdWdnZXN0aW9uIGFzIHRvIHdoYXQg bWF0dGVycyB0byBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0t DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMDdFN0UiPkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdp bmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxi cj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJF Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiM3RDdEN0QiPjogJm5ic3A7JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8ICZuYnNw OzxiPkU6DQo8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t Ij5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu Y2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQs IEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9h aSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bh bj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50 ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMg Tm86IDAxMzM3NDUxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWls ZGZvcmQsIFN1cnJleSwgR1UyIDdZUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBYmR1c3NhbGFtIEJhcnl1biBbbWFp bHRvOmFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE4IEFw cmlsIDIwMTYgMTc6MTU8YnI+DQo8Yj5Ubzo8L2I+IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp PGJyPg0KPGI+Q2M6PC9iPiBIZW5uaW5nIFJvZ2dlOyBtYW5ldEBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW21hbmV0XSBSRkMgNTQ0NCB1c2FnZSAtIG9uZSBzcGVjaWZpYyBwb2lu dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5n OjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj ZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjti YWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5 NzIiPioqKiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8ZW0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2lu YXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJu YWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNh cmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBh dHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBp bmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48L3NwYW4+PC9pPjxzdHJvbmc+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+ PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+IHRo YXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLA0KIGNsaWNrIDxh IGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3Vy aXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiI+DQpoZXJlPC9hPi48L3Nw YW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4N CjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFz ZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93 d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3Vz cGljaW91cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3NwYW4+PC9lbT48L3Nw YW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JTU8uIFRoZSBudW1iZXIgb2Yg cGFja2V0cyBpcyBub3QgdGhlIG9ubHkgdGhpbmcgdGhhdCBtdWx0aXBsZXhlciBzaG91bGQgbG9v ayBpbnRvIGJ1dCB0aGUgdGltZSBpcyBpbXBvcnRhbnQgYXMgd2VsbC4gVGhlIGRyYWZ0IG1heSBu ZWVkIHRvIHNob3cgZWZmaWNpZW5jeSBub3Qgb25seSBsb29raW5nIGF0IG51bWJlciBvZiBwYWNr ZXRzIHNlbnQgYnV0IGFsc28NCiBudW1iZXIgb2YgbWVzc2FnZXMgaW4gYSBwYWNrZXQuIFRoZSBk cmFmdCBtdXN0IG1lbnRpb24gdGhlIGRlbGF5IG9mIG11bHRpcGxleGluZyBpZiBpdCBpcyBzdGF0 aW5nIGVmZmljaWVuY3ksIGhvd2V2ZXIsIGl0IGlzIGRlbGF5aW5nIHBhY2tldHMgbm90IG1lc3Nh Z2VzLiBUaGVyZWZvcmUsIHRoZSB0ZXh0cyBtZW50aW9uZWQgaW4geW91ciBtZXNzYWdlIG5lZWRz IHRvIHNheSB0aGF0IG11bHRpcGxleGVyIG1heSBkZWxheSBwYWNrZXRzLiBIb3dldmVyLA0KIHRo ZXJlIGlzIGEgbmVlZCB0byBkZXRlcm1pbmUgdGhpcyBpbiB0aGUgZHJhZnQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFCPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEFwciAxOCwgMjAxNiBhdCAyOjEyIFBN LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFl c3lzdGVtcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+TXVsdGlwbGV4ZXIgZWZmaWNpZW5jeSBpcyBzdHJhaWdodGZvcndhcmQgLSBpZiB5 b3UgcHV0IHR3byBtZXNzYWdlcyBpbiBvbmUgcGFja2V0IHlvdSBzYXZlIGEgcGFja2V0DQogdHJh bnNtaXNzaW9uLiBPbiBzb21lIE1BQ3MgYXMgbG9uZyBhcyBwYWNrZXRzIGFyZSBvZiByZWFzb25h YmxlIHNpemUsIHRoZSBwYWNrZXQgc2l6ZSBpcyBwcmV0dHkgaXJyZWxldmFudCwgb25seSB0aGUg bnVtYmVyIG9mIHBhY2tldHMgbWF0dGVycy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZeKAmXMgYSBnb29k IHN5bmVyZ3kgb2YgdGhpcyB3aXRoIFJGQyA1MTQ4IGlmIHlvdSBhcmUgdXNpbmcgdGhhdCwgYnV0 IHRoYXTigJlzIG5vdCB0aGUgc3ViamVjdCBoZXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZCBhcyBmb3Ig Y2hhbmdpbmcgdG8gbG93ZXIgY2FzZSwgZG9u4oCZdCBkbyB0aGF0LiBJdCBpcyBvdmVyd2hlbG1p bmdseSBnb29kIHByYWN0aWNlIHRoYXQgaW4gbm9ybWF0aXZlDQogc2VjdGlvbnMgb2YgYSByZXBv cnQsIHVzZSBNQVksIFNIT1VMRCwuIE1VU1QgZXRjLiBhcyAyMTE5IHRlcm1zIGFuZCBhdm9pZCBh bGwgb3RoZXIgdXNlIG9mIHRob3NlIHdvcmRzLiBCdXQgaGVyZSwgYXMgSSBoYXZlIHNhaWQsIEkg dGhpbmsgU0hPVUxEIGlzIGFwcHJvcHJpYXRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPC9zcGFuPjwvYj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lw YWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0 b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOzxhIGhyZWY9InRlbDolMkI0NCUyMCUyODAlMjkx MjQ1JTIwMjQyMTk0IiB0YXJnZXQ9Il9ibGFuayI+JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NDwvYT4N CiAmbmJzcDt8ICZuYnNwOzxiPkU6IDwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVA YmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z LmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAw N0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+ QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQ YXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJl Zj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl IExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3 NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNl YXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWJk dXNzYWxhbQ0KIEJhcnl1biBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzphYmR1c3NhbGFtYmFyeXVu QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tPC9h Pl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxOCBBcHJpbCAyMDE2IDEzOjAzPGJyPg0KPGI+VG86PC9i PiBIZW5uaW5nIFJvZ2dlPGJyPg0KPGI+Q2M6PC9iPiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVL KTsgPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQptYW5l dEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gUkZDIDU0NDQg dXNhZ2UgLSBvbmUgc3BlY2lmaWMgcG9pbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNr Z3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3Rl eHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8L3NwYW4+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O3Rl eHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRz aWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3Ig dGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhl ciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3Ig cmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVn YXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9v ayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8v aW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRz L0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiIHRhcmdldD0iX2JsYW5rIj4NCmhlcmU8L2E+Ljwv c3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJy Pg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxl YXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9o b3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBT dXNwaWNpb3VzJTIwRW1haWxzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0KdGhpcyBwcm9jZXNzPC9h Pi48L3NwYW4+PC9lbT48L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgQXByIDE4LCAyMDE2 IGF0IDEyOjEzIFBNLCBIZW5uaW5nIFJvZ2dlICZsdDs8YSBocmVmPSJtYWlsdG86aHJvZ2dlQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmhyb2dnZUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTW9uLCBBcHIgMTgsIDIw MTYgYXQgMTE6MDcgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspPGJyPg0KJmx0OzxhIGhy ZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBT byBmYXIgSSBzZWUgb25lIHNwZWNpZmljIHBvaW50IGZvciBXRyBhZ3JlZW1lbnQgLSBhbnl0aGlu ZyBlbHNlIGlzIGVkaXRvcmlhbC4gKEVkaXRvcmlhbCBtYXR0ZXJzLCBidXQgaXQncyBub3QgY2hh bmdpbmcgcnVsZXMsIHNvIEknbSB0cnlpbmcgaGVyZSB0byBhZGRyZXNzIG9uZSBzcGVjaWZpYyBy dWxlIGlzc3VlLikgU29tZSBjb21tZW50cyBoYXZlIGNsZWFybHkgb3Zlcmxvb2tlZCB0aGlzLCBi dXQgd2hldGhlciB0byB0ZWxlZ3JhcGggaXQNCiBmdXJ0aGVyIChlLmcuIG1lbnRpb24gaW4gbm9u LW5vcm1hdGl2ZSBpbnRyb2R1Y3Rpb24pIGlzIGJhY2sgdG8gZWRpdG9yaWFsLjxicj4NCiZndDs8 YnI+DQomZ3Q7IFRoZSBkcmFmdCBjdXJyZW50bHkgc2F5czo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgbyZuYnNwOyBUaGUgbXVsdGlwbGV4ZXIgTUFZIGRlbGF5IG1lc3NhZ2VzIGJy aWVmbHkgaW4gb3JkZXIgdG8gYXNzZW1ibGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7bW9yZSBlZmZpY2llbnQgcGFja2V0cy4mbmJzcDsgSXQgU0hPVUxEIHJlc3BlY3QgYW55 IGNvbnN0cmFpbnRzIG9uIHN1Y2g8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ZGVsYXlzIHJlcXVlc3RlZCBieSB0aGUgcHJvdG9jb2wuPGJyPg0KJmd0Ozxicj4NCiZndDsgU2hv dWxkIHdlIGNoYW5nZSB0aGF0IFNIT1VMRCB0byBhIE1VU1Q/IE9idmlvdXNseSBJRVRGLXN0eWxl IHdlIGRvbid0IHJ1biB2b3RlcyBhcyBzdWNoLCBidXQgd2hhdCBhcmUgcGVvcGxlJ3Mgb3Bpbmlv bnM/PGJyPg0KPGJyPg0KVW5sZXNzIHdlIHNwZWNpZnkgd2hhdCBraW5kIG9mICZxdW90O2NvbnN0 cmFpbnRzJnF1b3Q7IGEgcHJvdG9jb2wgY2FuIHNwZWNpZnksIGE8YnI+DQpNVVNUIHdvdWxkIGJl IGEgYml0IHN0cmFuZ2UuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+SU1PLCBJIHRoaW5rIGl0IGlzIG5vdCBlZmZpY2llbnQgdG8gZGVsYXkgbWVzc2FnZXMsIEkg dGhpbmsgaXQgaXMgc3RyYW5nZSB0byBkZWxheSB3aXRob3V0IHNheWluZyBob3cgbXVjaCB0aGF0 IG11bHRpcGxleGVyIGlzIGRlbGF5aW5nIHRvIGdldCB0byBlZmZpY2llbmN5LCBzbyBpdCBzZWVt cyB0aGF0IG11bHRpcGxleGVyDQogZWZmaWNpZW5jeSBpcyBuZWVkZWQgdG8gYmUgZGVmaW5lZCBi ZWNhdXNlIGl0IGNhbiBiZSBkaWZmZXJlbnQgdGhhbiBwcm90b2NvbCBlZmZpY2llbmN5Lg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZXJl Zm9yZSwgSSB0aGluayB3ZSBzaG91bGQgY2hhbmdlIE1BWSB0byBtYXkgYW5kIFNIT1VMRCB0byBz aG91bGQsIG9yIGlmIG5vdCBjaGFuZ2VkIHdlIG5lZWQgdG8gc3BlY2lmeSBhIG1heGltdW0gZGVs YXkgZm9yIHRoZSBtdWx0aXBsZXhlciwgYmVjYXVzZSBsZWF2aW5nIGl0IHdpdGhvdXQgbGltaXQg aXMNCiBub3QgY29ycmVjdC48YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxicj4NCiZndDsgQXMgSSBzZWUgaXQ6PGJyPg0KJmd0Ozxicj4NCiZndDsg QXJndW1lbnQgZm9yIE1VU1Q6IElmIHRoZSBwcm90b2NvbCBoYXMgc3Ryb25nIHJlcXVpcmVtZW50 cyB0aGUgbXVsdGlwbGV4ZXIgbmVlZHMgdG8gcmVzcGVjdCB0aG9zZS48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBBcmd1bWVudCBmb3IgU0hPVUxEOiBCdXQgdGhlIHByb3RvY29sIG1pZ2h0IG1ha2UgYW4g aW1wb3NzaWJsZSBkZW1hbmQsIHN1Y2ggYXMgemVybyBkZWxheSB3aGVuIHdlIGFsbCBrbm93IG5v dGhpbmcgaGFzIHplcm8gZGVsYXkuIFNIT1VMRCBpc24ndCBNQVksIGl0IG5lZWRzIHRvIGRvIGl0 cyBiZXN0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFBvc3NpYmxlIHRoaXJkIGNvdXJzZSwgc29tZXRo aW5nIGxpa2UgKG9wZW4gdG8gd29yZHNtaXRoaW5nIC0gSSBjb25zaWRlcmVkIHB1dHRpbmcgdGhl IGNhdmVhdCBhdCB0aGUgZW5kLCBmb3IgZXhhbXBsZSkuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJz cDsgJm5ic3A7IG8mbmJzcDsgVGhlIG11bHRpcGxleGVyIE1BWSBkZWxheSBtZXNzYWdlcyBicmll Zmx5IGluIG9yZGVyIHRvIGFzc2VtYmxlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO21vcmUgZWZmaWNpZW50IHBhY2tldHMuJm5ic3A7IEl0IE1VU1QsIGFzIGZhciBhcyBwb3Nz aWJsZSwgcmVzcGVjdCBhbnk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29u c3RyYWludHMgb24gc3VjaCBkZWxheXMgcmVxdWVzdGVkIGJ5IHRoZSBwcm90b2NvbC48YnI+DQom Z3Q7PGJyPg0KJmd0OyBBcmd1bWVudCBhZ2FpbnN0IHRoaXJkIGNvdXJzZSwgd2UndmUgc2VlbiBi ZWZvcmUgdGhhdCBhbnl0aGluZyB0aGF0IGluY2x1ZGVzIHdvcmRpbmcgbGlrZSB0aGF0IGlzIG9w ZW4gdG8gSUVTRyBub3QgYmVpbmcgaGFwcHkuPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gYmFsYW5j ZSwgSSB0aGluayBTSE9VTEQgaXMgYXBwcm9wcmlhdGUsIGFzc3VtaW5nIFNIT1VMRCBpcyBpbnRl cnByZXRlZCBhcyBpdCBzaG91bGQgYmUgLSBkbyB0aGlzIHVubGVzcyB0aGVyZSByZWFsbHkgaXMg YSBnb29kIHJlYXNvbiBub3QgdG8uIEJ1dCBJIGNvdWxkIGxpdmUgd2l0aCBhbnkgb2YgdGhlIHRo cmVlIChpZiBhbGxvd2VkKS48YnI+DQo8YnI+DQpTSE9VTEQgd291bGQgYmUgb2theS4uLiBlc3Bl Y2lhbGx5IGJlY2F1c2UgKG5vcm1hbGx5KSBtdWx0aXBsZXhlcjxicj4NCndvdWxkIHJlc3RyaWN0 IHRoZSBhbW91bnQgb2YgY29uc3RyYWludHMgb2YgdGhlIHByb3RvY29sIGJ5IGl0cyBBUEk8YnI+ DQphbnl3YXlzLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPklNTywgSXQgc2hvdWxkIHNheSB0aGF0IHRoZSBtdWx0aXBsZXhlciBNVVNU IE5PVCBkZWxheSBtZXNzYWdlcyBpZiB0aGUgcHJvdG9jb2wgcmVxdWVzdCBjb25zdHJhaW50cyBv biBkZWxheS4gV2UgZG9uJ3Qgd2FudCB0byBjaGFuZ2UgdGhlIG11bHRpcGxleGVyIGludG8gaGF2 aW5nIGl0cyBvd24gcHJvdG9jb2wgd2l0aG91dA0KIGhhdmluZyBhIFJGQyBmb3IgaXQuIDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BQjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cD4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZDxicj4NCnJlY2lwaWVudCBhbmQg bWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPg0K cmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRo ZSBzZW5kZXIuPGJyPg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBw dXJwb3NlIG5vciBkaXNjbG9zZSBvcjxicj4NCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFu eSBvdGhlciBwZXJzb24uPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923ADB11GLKXM0002VGREEN_-- From nobody Mon Apr 18 09:21: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 E165D12E249 for ; Mon, 18 Apr 2016 09:21:32 -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 EdmEh9JgpUXR for ; Mon, 18 Apr 2016 09:21:31 -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 08BA512E26F for ; Mon, 18 Apr 2016 09:18:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=mVC00ofFgOji7/7n51eGrjK1ATnUuJJJfd59GJNeLpD8t5hPv3boiUmc7N4Bf+2D; h=Received:From:Subject:To:Message-ID:Date:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [107.1.141.74] (helo=[192.168.255.195]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1asBsP-0004T8-DH for manet@ietf.org; Mon, 18 Apr 2016 12:18:17 -0400 From: Charlie Perkins To: Mobile Ad Hoc Networks mailing list Message-ID: <571508C8.3030003@earthlink.net> Date: Mon, 18 Apr 2016 09:18:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7c0db9b3f75ff34758e4b1ba9268ca99d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: Subject: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 18 Apr 2016 16:21:33 -0000 Hello folks, After extensive discussion with various people, I think there does not exist today a suitable IETF registry for protocol-independent link metrics. My earlier support for using the RFC 6551 registry was not appropriate because the formats for the metrics defined in that document are not protocol-independent. In the case of AODVv2, the cure is simple. RFC 6551 was only cited in section 11.6. That section can be easily modified to lose the citation. The result is: 11.6. MetricType Allocation The metric types used by AODVv2 are identified according to a new table to be created and maintained by IANA. All implementations MUST use these values. +---------------------+----------+--------------------+ | Name of MetricType | Type | Metric Value Size | +---------------------+----------+--------------------+ | Unassigned | 0 | Undefined | | Hop Count | 1 | 1 octet | | Unallocated | 2 - 254 | TBD | | Reserved | 255 | Undefined | +---------------------+----------+--------------------+ Table 7: AODVv2 Metric Types This will also require some new text in IANA Considerations. I have specifications for other other link metric types that are also useful for wireless links and routing. I will post them later today, but the discussion about the exact format of those metric values should not stand in the way of AODVv2. Comments please? Regards, Charlie P. From nobody Mon Apr 18 09:27:54 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 A18D812E216 for ; Mon, 18 Apr 2016 09:27:52 -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 UKgyHekALojh for ; Mon, 18 Apr 2016 09:27:51 -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 39E8012E20F for ; Mon, 18 Apr 2016 09:27:51 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id g184so223264408lfb.3 for ; Mon, 18 Apr 2016 09:27: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:from:date:message-id:subject:to :cc; bh=p2AS8tmFG0AZWSOdyFWPdKNePo7TyC2Q9Y4rZoX1M+o=; b=r8o+sYjSY1FiyOx1U3TR6GC116WdU141+OUnOP7vNyARj+sgp+stagoyf9D2BGlErM /gpx2w0yzmKyphk63Y8cfZusKHkMWPWUrk2zlPBkNhftooNHUMgsZ4ENM+UXAf0aaR/W d2B2on+cESxu/6X9SI3HDdcA/h479iOiX/ND78WaHm8DPKLL4SnKVMdDEOLWOzOAKcJ0 l0+avNZDA6x/jmGxPXk2dt8RrGp/wKYfIDhsr+iUnssCu4ubokoknX50Wi5JvtlDfX5h VnFRb9eYjp7Hdk6tzTxpVIv+yIdIdwDWi+cKlDLYU0SCN6TToF/yrRP4Q161ju+otHr3 jDJw== 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=p2AS8tmFG0AZWSOdyFWPdKNePo7TyC2Q9Y4rZoX1M+o=; b=OHocFgcfoeRctTmYgIua4xziOEEy5QvMw+hhbD2rKhNj9gieNCou4PYlO9IlfeY5sh 0mMvm6eQJ0FpJVcG1WN2czPBblIMAXlrPW5U30AV6fXsf4r34YM3I2hlJS6Ocj+W/M1i Pz7DK1e13BXjK7AIElXCY2FULIvYjJwL4/ZUunSfJdlb4MiQzZBePsSZPK6644IxxVQa vZfSiwHyu9eejghxjq7kIX0vbAxCBntH1LMSSg400B/68jfpz2bMBpzd3KL666pzbP8O RgcHMMBjM28Nk/dex8fdcBu+SvfgeAZ6lnp+iy+m7p9ffD71tsqHjOa/nUPKAiDOx2BT h7qQ== X-Gm-Message-State: AOPr4FXL7o8zlGDuLeKXoYdOlp4/z4UzdfCQsHz1pIc9z96F91+M5PATHs5OSs2bWr56zVdHhOCHNdZrF/Vqzg== X-Received: by 10.25.131.147 with SMTP id f141mr15155233lfd.12.1460996869409; Mon, 18 Apr 2016 09:27:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.30 with HTTP; Mon, 18 Apr 2016 09:27:19 -0700 (PDT) In-Reply-To: <571508C8.3030003@earthlink.net> References: <571508C8.3030003@earthlink.net> From: Henning Rogge Date: Mon, 18 Apr 2016 18:27:19 +0200 Message-ID: To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 18 Apr 2016 16:27:52 -0000 On Mon, Apr 18, 2016 at 6:18 PM, Charlie Perkins wrote: > I have specifications for other other link metric types that are also useful > for wireless links and routing. I will post them later today, but the > discussion about the exact format of those metric values should not stand in > the way of AODVv2. > > Comments please? I think it would be good to have at least one "32 bit unsigned integer" metric value... because you could use the DAT metric and then just plug it into you path cost calculation if you want. every OLSRv2 link metric can be expressed with 24 bits, so 32 bits give you a maximum path length of 255, which is the maximum for an IP packet anyways. Henning Rogge From nobody Mon Apr 18 09:33:46 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 34D4712E1F0 for ; Mon, 18 Apr 2016 09:33:45 -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 MosVOnnIuWyl for ; Mon, 18 Apr 2016 09:33:43 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [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 CF2EC12DFB4 for ; Mon, 18 Apr 2016 09:33:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,503,1454976000"; d="scan'208";a="61892492" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 18 Apr 2016 17:33:41 +0100 X-IronPort-AV: E=Sophos;i="5.24,503,1454976000"; d="scan'208";a="114462426" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 18 Apr 2016 17:33:41 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 17:33:41 +0100 From: "Dearlove, Christopher (UK)" To: Charlie Perkins , "Mobile Ad Hoc Networks mailing list" Thread-Topic: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics Thread-Index: AQHRmY5icHfeUArH5kuyP0m9D3y0IJ+P67lA Date: Mon, 18 Apr 2016 16:33:40 +0000 Message-ID: References: <571508C8.3030003@earthlink.net> In-Reply-To: <571508C8.3030003@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="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 18 Apr 2016 16:33:45 -0000 That's discussing metric types and bits. I have two observations. First, that needs to know where it's going to be used. TLV type extensions = of a TLV type? Second, having a metric size that is variable with type is painful in terms= of parsing. If someone adds a new type you need to change code, or at leas= t change a lookup table associated with your code. We made the opposite cho= ice in OLSRv2 - of course we had the advantage of only needing link metrics= on the wire. Lots of protocols have made a similar choice that makes type = knowledge necessary in a parser that can become outdated. (And several of t= hose designers have been cursed for it.) As ever in such cases, need to be = clear about tradeoffs and then decide. -- = 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 Charlie Perkins Sent: 18 April 2016 17:18 To: Mobile Ad Hoc Networks mailing list Subject: [manet] Resolution for whether or not to use the RFC 6551 registry= for link metrics ----------------------! 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. Hello folks, After extensive discussion with various people, I think there does not exis= t today a suitable IETF registry for protocol-independent link metrics. My= earlier support for using the RFC 6551 registry was not appropriate becaus= e the formats for the metrics defined in that document are not protocol-ind= ependent. In the case of AODVv2, the cure is simple. RFC 6551 was only cited in secti= on 11.6. That section can be easily modified to lose the citation. = The result is: 11.6. MetricType Allocation The metric types used by AODVv2 are identified according to a new table to be created and maintained by IANA. All implementations MUST use these values. +---------------------+----------+--------------------+ | Name of MetricType | Type | Metric Value Size | +---------------------+----------+--------------------+ | Unassigned | 0 | Undefined | | Hop Count | 1 | 1 octet | | Unallocated | 2 - 254 | TBD | | Reserved | 255 | Undefined | +---------------------+----------+--------------------+ Table 7: AODVv2 Metric Types This will also require some new text in IANA Considerations. I have specifications for other other link metric types that are also = useful for wireless links and routing. I will post them later today, = but the discussion about the exact format of those metric values should = not stand in the way of AODVv2. Comments please? Regards, Charlie P. _______________________________________________ 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 Mon Apr 18 09:36:32 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 2196012E27B for ; Mon, 18 Apr 2016 09:36:31 -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 4h4wzkVHEoUn for ; Mon, 18 Apr 2016 09:36:29 -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 CC3B912E27A for ; Mon, 18 Apr 2016 09:36:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,503,1454976000"; d="scan'208";a="33777246" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 18 Apr 2016 17:36:27 +0100 X-IronPort-AV: E=Sophos;i="5.24,503,1454976000"; d="scan'208";a="114462718" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 18 Apr 2016 17:36:27 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 17:36:27 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , Charlie Perkins Thread-Topic: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics Thread-Index: AQHRmY5icHfeUArH5kuyP0m9D3y0IJ+P2nqAgAASnNA= Date: Mon, 18 Apr 2016 16:36:26 +0000 Message-ID: References: <571508C8.3030003@earthlink.net> 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: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 18 Apr 2016 16:36:31 -0000 I was about to say correction, then realised I was the one that needed corr= ecting. In an earlier post I said 28 bits, where Henning has here correctly= said 24 bits. Doubly embarrassing as I designed that representation (modif= ied from previous, modified from RFC 5497 for times, modified from OLSRv1). -- = 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 Henning Rogge Sent: 18 April 2016 17:27 To: Charlie Perkins Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 regi= stry for link metrics ----------------------! 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. On Mon, Apr 18, 2016 at 6:18 PM, Charlie Perkins wrote: > I have specifications for other other link metric types that are also = > useful for wireless links and routing. I will post them later today, = > but the discussion about the exact format of those metric values = > should not stand in the way of AODVv2. > > Comments please? I think it would be good to have at least one "32 bit unsigned integer" met= ric value... because you could use the DAT metric and then just plug it int= o you path cost calculation if you want. every OLSRv2 link metric can be expressed with 24 bits, so 32 bits give you= a maximum path length of 255, which is the maximum for an IP packet anyway= s. Henning Rogge _______________________________________________ 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 Mon Apr 18 12:11: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 1E9B812E5EF for ; Mon, 18 Apr 2016 12:11:27 -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 Gnil1XlP6vD9 for ; Mon, 18 Apr 2016 12:11:25 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id AC59112E5EA for ; Mon, 18 Apr 2016 12:11:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ne8svKeFiMcMQa8+y55StyNXaRNd3dBTNJoeidwAOgMLWAWzYN9QrORCImEdUT64; 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 [107.1.141.74] (helo=[192.168.255.195]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1asEZn-0004wJ-7J; Mon, 18 Apr 2016 15:11:15 -0400 To: Henning Rogge References: <571508C8.3030003@earthlink.net> From: Charlie Perkins Message-ID: <57153151.6090706@earthlink.net> Date: Mon, 18 Apr 2016 12:11:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7eea5def5f2b187ac1fc4b31955483359350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 18 Apr 2016 19:11:28 -0000 Hello Henning, I think that's a good idea, but I'm not sure what metric specification to cite for that. Do you have a suggestion? Should I just cite RFC 7185? Regards, Charlie P. On 4/18/2016 9:27 AM, Henning Rogge wrote: > On Mon, Apr 18, 2016 at 6:18 PM, Charlie Perkins > wrote: >> I have specifications for other other link metric types that are also useful >> for wireless links and routing. I will post them later today, but the >> discussion about the exact format of those metric values should not stand in >> the way of AODVv2. >> >> Comments please? > I think it would be good to have at least one "32 bit unsigned > integer" metric value... because you could use the DAT metric and then > just plug it into you path cost calculation if you want. > > every OLSRv2 link metric can be expressed with 24 bits, so 32 bits > give you a maximum path length of 255, which is the maximum for an IP > packet anyways. > > Henning Rogge > From nobody Mon Apr 18 12:13: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 61C6012B019 for ; Mon, 18 Apr 2016 12:13:03 -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 7pheuG4-FRv3 for ; Mon, 18 Apr 2016 12:13:02 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 1DFA612E5A6 for ; Mon, 18 Apr 2016 12:13:02 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id f52so123601517qga.3 for ; Mon, 18 Apr 2016 12:13:02 -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=GGckoTS9BXYLY6dsaNudhKgFKpOD+I6SvD6t8AJEPDE=; b=QhQnDGZK2Dqy1h4g2qiPIbRyndKhVdNegjX9vaWbudlIrSYD+OvkWYRRaB66LJoSEv RtKOtpBrJlMxpFldOoqCiwEuK4kd9ccoghGYOC4GgR1oAvowtvH+buKx0b+5V7/PZobo Ify52Cgp/n2V2Sf/+p5UOEwiaBtg/3ddpmuUI4UmTEHulzKYgwHkohn3A+NdqjGFx01P aXPEZ+EiYgisCmICub6R5qIwJANSE4KkPfNq2cqFDHafSDwHCrf7ROIlxqdtkA13rSve mSFuNvrUR+Cfe097NIOKeU7TOHMh9BPNqIfP/IDuEtaz852+aKX8IAPFI3KlcJB+JQFs c2Rw== 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=GGckoTS9BXYLY6dsaNudhKgFKpOD+I6SvD6t8AJEPDE=; b=b/8EI4TdTaLjd0lZfiW1+rvjV/bIFdTQ9j7oa88yL4pY9FdGbfagIIBPe8Yo3OSg6V p/Rm6qdoAOLBonEESOSqT161g+ocy6RJCmv6EKAjIPuZPZelf4UJtTI5bkzEtmJpW9W7 wFN95e8ZZHJgm5ogdYYprZDiAaLPqmWOCZqfX3y4mX/JZZERZJPJ2heT2hVACGI6AXgQ 3BZ7CL1dsOMF12qioVtmh+sbNgZIqY0A227FxETfk8+YB/qzs0jeurtEYcz3IDLw1YZo 87a/z37bS7RQyxtsJaeotNRodu6xsHFGY1u1F8SLffzDqId/7iaMt3KrPKjHoOlKEgiz seNA== X-Gm-Message-State: AOPr4FXWd5hyaenL5zbjR/wjDKXryhyF09pEXdy8X4sUxscRCQu0hqoHNRNew230vSesJuKC7g6m6aNwZQ743w== MIME-Version: 1.0 X-Received: by 10.140.35.115 with SMTP id m106mr44270485qgm.13.1461006781305; Mon, 18 Apr 2016 12:13:01 -0700 (PDT) Received: by 10.140.43.131 with HTTP; Mon, 18 Apr 2016 12:13:01 -0700 (PDT) In-Reply-To: <571508C8.3030003@earthlink.net> References: <571508C8.3030003@earthlink.net> Date: Mon, 18 Apr 2016 21:13:01 +0200 Message-ID: From: Abdussalam Baryun To: Charlie Perkins Content-Type: multipart/alternative; boundary=001a11c038e036daac0530c72698 Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 18 Apr 2016 19:13:03 -0000 --001a11c038e036daac0530c72698 Content-Type: text/plain; charset=UTF-8 Hi Charlie, I think nothing should be in the way of AODVv2 we want the best reactive protocol for IETF , we done the proactive so now doing reactive. Therefore, yes we need new metric format for AODVv2. AB --001a11c038e036daac0530c72698 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Charlie,

I think nothing sh= ould be in the way of AODVv2 we want the best reactive protocol for IETF
, we done the proactive so now doing reactive. Therefore, yes we nee= d new metric format for AODVv2.

AB
--001a11c038e036daac0530c72698-- From nobody Mon Apr 18 12:13: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 B6DB612E5D5 for ; Mon, 18 Apr 2016 12:13:33 -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 t0-VOADz2LNC for ; Mon, 18 Apr 2016 12:13:32 -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 D1E3712E5D0 for ; Mon, 18 Apr 2016 12:13:31 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id j11so228416965lfb.1 for ; Mon, 18 Apr 2016 12:13:31 -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=r3LhdI1Gqi99FZd5Qq7C97qXhUKJFWKBDMEAt35EIiQ=; b=zfouciq6PfBSUsP1RMNHgMzQ++JzAYKpg8jJZgYHwOjpgvEEjaRw3enrC/svYfKwYL G39PrSxn6zb/NMKUPzP7/zfv0OiymB9LIJBA2CQnauCxbA5K7nhxw3BAox0VxXEr2ecM ttW2fYkpLJ/LH9fVhbq6yxGhdrDq0Gi6nEUJ9NcYFyMiGt23L9ZwosHR5Vef54m2JTY0 RDm+uJp+/zlnv/F/JuUPHAvpNJvcSKc+UkzJf1pnwFiIN/7qmEkZHDC7to/Ex4Bf09k9 07xnw9+566j4YISpN0XCkjMUr4mZIlBnLQdGzNv72rN+0+eQ8Uo6X1JqOTCEaRee2C5o 5xkA== 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=r3LhdI1Gqi99FZd5Qq7C97qXhUKJFWKBDMEAt35EIiQ=; b=le/f4kAW9Vfi1lOl0e+fK7JJpU0VuWmru2hN0l5Kni8FPuWaPT+22Nx6vaUVF85TRW L93LAutbbBV6lceLCO90UQR3XM3KTPPsbNQrKwVdZtK0BZV0CPJdh5RdpirKfvl9J1c5 2RPGydHWKJ8GWUhYwc624sYQa/W632Ty03FHiVTatYcPGxu5evINYHcRDCp9eywRRNy5 XUqD/AQ52Z8ttDsPvQiHl4msi7uqgFqTlvHziZG0Fdv7BV1AfjqAhzf52wUtUvuVX5jQ uybPxRCuIS9RLBCcyv8MQOUgNa+QFHAUGtViDKO+lgSBvI3Rk14YIBsmWM45wogv2v9L gEQQ== X-Gm-Message-State: AOPr4FVXI4sov1cxLj64WAgSwntJw/khpttRS6pMpi41f1+9wus8CgpX0n8WkDlgmHwlOJfWfePpqTYpWZz4Sg== X-Received: by 10.112.12.98 with SMTP id x2mr14871372lbb.76.1461006810047; Mon, 18 Apr 2016 12:13:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.30 with HTTP; Mon, 18 Apr 2016 12:13:00 -0700 (PDT) In-Reply-To: <57153151.6090706@earthlink.net> References: <571508C8.3030003@earthlink.net> <57153151.6090706@earthlink.net> From: Henning Rogge Date: Mon, 18 Apr 2016 21:13:00 +0200 Message-ID: To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 18 Apr 2016 19:13:34 -0000 On Mon, Apr 18, 2016 at 9:11 PM, Charlie Perkins wrote: > Hello Henning, > > I think that's a good idea, but I'm not sure what metric specification to > cite for that. Do you have a suggestion? Should I just cite RFC 7185? Yes, I would refer to the OLSRv2 design document and mention that a 32 bit path metric TLV makes AODV2 be able to use any kind of OLSRv2 link metric. Henning Rogge From nobody Mon Apr 18 12: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 D074C12E667 for ; Mon, 18 Apr 2016 12:35:32 -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 B_-9AO3zl4cN for ; Mon, 18 Apr 2016 12:35:31 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8E11012E666 for ; Mon, 18 Apr 2016 12:35:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=LhOYwF//8n0zU5el0t1kUWqGdEsYsMl+2FEIRJf8QpWVt6Cy+NMw3Mf9diZKnExn; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [107.1.141.74] (helo=[192.168.255.195]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1asExC-0000AR-8o; Mon, 18 Apr 2016 15:35:26 -0400 To: Abdussalam Baryun References: <571508C8.3030003@earthlink.net> From: Charlie Perkins Message-ID: <571536FC.5050407@earthlink.net> Date: Mon, 18 Apr 2016 12:35:24 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090606040707010606050705" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7d20730532ff37a47f1aff40588e6e033350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 18 Apr 2016 19:35:33 -0000 This is a multi-part message in MIME format. --------------090606040707010606050705 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello Abdussalam, Thanks for your support! I think that the link metric type table specified in the AODVv2 document should remain protocol-independent as much as possible. I also support the OLSRv2 strategy of using additive cost metrics insofar as is possible. Regards, Charlie P. On 4/18/2016 12:13 PM, Abdussalam Baryun wrote: > Hi Charlie, > > I think nothing should be in the way of AODVv2 we want the best > reactive protocol for IETF > , we done the proactive so now doing reactive. Therefore, yes we need > new metric format for AODVv2. > > AB --------------090606040707010606050705 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello Abdussalam,

Thanks for your support!

I think that the link metric type table specified in the AODVv2 document should remain protocol-independent as much as possible.  I also support the OLSRv2 strategy of using additive cost metrics insofar as is possible.

Regards,
Charlie P.


On 4/18/2016 12:13 PM, Abdussalam Baryun wrote:
Hi Charlie,

I think nothing should be in the way of AODVv2 we want the best reactive protocol for IETF
, we done the proactive so now doing reactive. Therefore, yes we need new metric format for AODVv2.

AB

--------------090606040707010606050705-- From nobody Mon Apr 18 12:54:24 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 AA61112DEB7 for ; Mon, 18 Apr 2016 12:54:22 -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 QGssNZ3bCdip for ; Mon, 18 Apr 2016 12:54:21 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 CE6E912D992 for ; Mon, 18 Apr 2016 12:54:20 -0700 (PDT) Received: by mail-qg0-x22a.google.com with SMTP id c6so124875048qga.1 for ; Mon, 18 Apr 2016 12:54:20 -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=pUVOYjRgxCviSEBsJjvImtgXa33IcAwwD9bEO8NNfoU=; b=zh/vKSh+dska+T3dInnX29finaQ4AuuBaw5vSiztDXI5LpS4jhj0EgVCYgG59HTOz1 ybiJ1zIFvz3EylB+Sj/2aGanTBKRZ/lcu5xtkSbf9yuATtPJtkllssDHc5PMLS7wRlR9 mdVL/3ylR+FCQR3u2l4Uc6GTMT0OWbpEe3M7KSk3y28x4Q5d9Jbohx/R/unWaUYM2pUK RjNus+tDxa9NQGeBU8xUGTraKPuHKoEmEuiEBct4dnAqa+dlOqAPaQfoQpLdzOPnlFIb dvEZdxH4KmTLV1otxi2jqf7ukwC0GRsOAqucUmCOif8YApuvTd2jPfdxoO9OGWJk/tiT k+oQ== 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=pUVOYjRgxCviSEBsJjvImtgXa33IcAwwD9bEO8NNfoU=; b=Iz1aPEI490oU7DQMootVNEQcWyCg8flOGo3jowmL1R4omGRlHBcSywktddRSgZ5JgO osjeWJ+1VhHYsTteHeWGozXecBH9yKHxwcwl1pHhIu0QhFdf/UABd6mlCmL8mQOQQ8lW fMY0LZ/dxwhfHx3A2tB3E9m/COjWTmyct3J5izFvJDE5BZnX2BpVyB2WzYHEtl9xaH2k 7v8wL9d8f6B2DAE9MLX9C7NLcBp+kv9pwu4UoHnyTPXz580FimFBg/YzNxlUO3GWiC6C 2rpU02cPoG+lHhg4DdSXHMyQSEa8ATi6+J/RoiqMa8grymAt39YIJ/NKF0NPA8fF8LY+ 2fyg== X-Gm-Message-State: AOPr4FUjvbnKuoBJcucFhxcZZfSGBnmKm8aMuFAuhbIXQ2u7kk8RA/G/zkjyNenoBV6MdMkmfaI7+wyVR7i8TQ== MIME-Version: 1.0 X-Received: by 10.140.241.139 with SMTP id m133mr24331011qhc.64.1461009259944; Mon, 18 Apr 2016 12:54:19 -0700 (PDT) Received: by 10.140.43.131 with HTTP; Mon, 18 Apr 2016 12:54:19 -0700 (PDT) In-Reply-To: <571536FC.5050407@earthlink.net> References: <571508C8.3030003@earthlink.net> <571536FC.5050407@earthlink.net> Date: Mon, 18 Apr 2016 21:54:19 +0200 Message-ID: From: Abdussalam Baryun To: Charlie Perkins Content-Type: multipart/alternative; boundary=001a113a469cf3e44f0530c7b9ae Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 18 Apr 2016 19:54:22 -0000 --001a113a469cf3e44f0530c7b9ae Content-Type: text/plain; charset=UTF-8 IMO, yes we agreed to use the same formats as general (I only agree if not affecting performance of protocol), because the WG was looking into the hybrid networking opportunity, but I don't care about hybrid protocol performance now, but I look into the one protocol performance first which is the AODVv2, as I done when reviewed the OLSRv2. Therefore the strategy better to be first for AODVv2 best efficiency, then with the AODVv2 hybrid networking. I don't much care about multiplexing efficiency while having bad protocol efficiency, so we need to focus on the best ways for the protocol not the best ways for mixing it with others. However, that is my opinion a WG participant, but liked to discuss as seen a request. AB On Mon, Apr 18, 2016 at 9:35 PM, Charlie Perkins < charles.perkins@earthlink.net> wrote: > Hello Abdussalam, > > Thanks for your support! > > I think that the link metric type table specified in the AODVv2 document > should remain protocol-independent as much as possible. I also support the > OLSRv2 strategy of using additive cost metrics insofar as is possible. > > Regards, > Charlie P. > > > > On 4/18/2016 12:13 PM, Abdussalam Baryun wrote: > > Hi Charlie, > > I think nothing should be in the way of AODVv2 we want the best reactive > protocol for IETF > , we done the proactive so now doing reactive. Therefore, yes we need new > metric format for AODVv2. > > AB > > > --001a113a469cf3e44f0530c7b9ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IMO, yes we agreed to use the same formats as general= (I only agree if not affecting performance of protocol), because the WG wa= s looking into the hybrid networking opportunity, but I don't care abou= t hybrid protocol performance now, but I look into the one protocol perform= ance first which is the AODVv2, as I done when reviewed the OLSRv2. Therefo= re the strategy better to be first for AODVv2 best efficiency,=C2=A0 then w= ith the AODVv2 hybrid networking. I don't much care about multiplexing = efficiency while having bad protocol efficiency, so we need to focus on the= best ways for the protocol not the best ways for mixing it with others. Ho= wever, that is my opinion a WG participant, but liked to discuss as seen a = request.

AB

On Mon, Apr 18, 2016 at 9:35 PM, Charlie Perkins <charles.perkins@earthlink.net> wrote:
=20 =20 =20
Hello Abdussalam,

Thanks for your support!

I think that the link metric type table specified in the AODVv2 document should remain protocol-independent as much as possible.=C2=A0 = I also support the OLSRv2 strategy of using additive cost metrics insofar as is possible.

Regards,
Charlie P.



On 4/18/2016 12:13 PM, Abdussalam Baryun wrote:
=20
Hi Charlie,

I think nothing should be in the way of AODVv2 we want the best reactive protocol for IETF
, we done the proactive so now doing reactive. Therefore, yes we need new metric format for AODVv2.

AB


--001a113a469cf3e44f0530c7b9ae-- From nobody Mon Apr 18 15:49:39 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 E752912D6B4 for ; Mon, 18 Apr 2016 15:49:36 -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 2u8WBT6TxqBX for ; Mon, 18 Apr 2016 15:49:35 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 7CB9212D1AA for ; Mon, 18 Apr 2016 15:49:35 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id u206so2200708wme.1 for ; Mon, 18 Apr 2016 15:49:35 -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=EUQaNI2fYExf5X9yvD9reNKOIMa3meIxkED4AIapKFw=; b=NVWpYLmhigX22nySxQqCPob7ccVddvJxo+wJ4TGli3veFf8XrXq+uazZRtnI0QDz2r PMk8hji1+FSguMNWVbadHheBLpyRnOyhBdVr6F0vK1r7lUZEIZ9qXoKFTpUHXT/6BWvb /hZU2e9YcWK3N4wcmkwbWw8ENeRVIIVpchWaQI0WrG/lBSGhivVy778thry7M0Re4JMa OCs+DOR0SocXuaqKF8LbzjIdhK9VAXzTo3tjL2RYmPCCsdmtj4EyEimKWVeu2Rvr7DEL V+MvvVGQdDkZB20D4R+Lvb5nixBuVFBCyucLxfenErwZMM4f8zs8JyHfyg4W9OHS7/c0 U5aQ== 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=EUQaNI2fYExf5X9yvD9reNKOIMa3meIxkED4AIapKFw=; b=KNvfQ+VwGHvWrdpJxKWpHEegHOxx4oDcKcLf4xz9L7Tqjk7oOx5aS5Apmdaf3bT7xj wMOlSAv1q+r1fjy630mgHRL1wJ9d/Ukd/4dW+7unnz1vWqI72dksleCK8IOxYoUR1fxz 3aqw/jLfYVXb3ce2tq7RoDUis2OTQrpiE76qgVQl8MpoWljdwkMXqSzKdB8Q1zi9ftaA FHzAMRNqgTziPsRp0LIhP+r6C2f/4KhEpaQGK0yZyJfmHCKQKhphnFRUq5srYyn7f0Xq Y4FH/ftzT/P7RQsi9kgzlF6oGzB6adVqGYqpCOA+iI571yJ4h0NRKEK4+bQOUkpSvFTx HIyA== X-Gm-Message-State: AOPr4FWEp2atYZJxxhkDJP88Iw+4JgKSTNfbk9iJNj9ih7RoHZfmoZ55V1RDqHQzzsykLCsAEylWlV+IP19WUw== MIME-Version: 1.0 X-Received: by 10.28.54.208 with SMTP id y77mr19907247wmh.17.1461019774074; Mon, 18 Apr 2016 15:49:34 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.153.166 with HTTP; Mon, 18 Apr 2016 15:49:34 -0700 (PDT) In-Reply-To: References: <4D088849-F444-4FA3-B0AE-0FD2078A76F5@gmail.com> Date: Tue, 19 Apr 2016 00:49:34 +0200 X-Google-Sender-Auth: rXrURrmCYYqEfYU_JaXhTJpfaxI Message-ID: From: Jiazi YI To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a11435430a4c9c10530ca2cd8 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Review of draft-ietf-manet-rfc5444-usage-03 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, 18 Apr 2016 22:49:37 -0000 --001a11435430a4c9c10530ca2cd8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > > > > "It is strongly RECOMMENDED that messages are not modified in the latte= r > case.=E2=80=9D I=E2=80=99m not following this. Why is it ok to modify mes= sages that have > been impacted by an extension to the hosted protocol, but it=E2=80=99s no= t ok to > modify messages that have not been subject to extension processing? What > does =E2=80=98modify=E2=80=99 mean in this context anyway? > > Because one is in the endpoint, one is not. If you modify messages at the > endpoint (e.g. OLSRv2 adding MPRs to NHDP's HELLO messages) you can add a= n > ICV afterwards and still get end to end security. If you modify in betwee= n > the two then you can't. > I can understand for the purpose of integrity checking, we couldn't modify when the messages are being forwarded. But RFC5444 is designed for reactive protocol also, which (in most cases), by nature, will modify the message in intermediate routers. It sounds a bit strange for me if such operation is not recommended by RFC5444. Jiazi --001a11435430a4c9c10530ca2cd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


> "It is strongly RECOMMENDED that messages are not modified in the= latter case.=E2=80=9D I=E2=80=99m not following this. Why is it ok to modi= fy messages that have been impacted by an extension to the hosted protocol,= but it=E2=80=99s not ok to modify messages that have not been subject to e= xtension processing? What does =E2=80=98modify=E2=80=99 mean in this contex= t anyway?

Because one is in the endpoint, one is not. If you modify messages a= t the endpoint (e.g. OLSRv2 adding MPRs to NHDP's HELLO messages) you c= an add an ICV afterwards and still get end to end security. If you modify i= n between the two then you can't.

I= can understand for the purpose of integrity checking, we couldn't modi= fy when the messages are being forwarded.=C2=A0
But RFC5444 is de= signed for reactive protocol also, which (in most cases), by nature, will m= odify the message in intermediate routers. It sounds a bit strange for me i= f such operation is not recommended by RFC5444.=C2=A0

<= div>Jiazi
--001a11435430a4c9c10530ca2cd8-- From nobody Mon Apr 18 16:06: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 2149012E905 for ; Mon, 18 Apr 2016 16:06: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 Af1Qaix-OHMt for ; Mon, 18 Apr 2016 16:06:06 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 EF94C12E904 for ; Mon, 18 Apr 2016 16:06:05 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id u185so1983721iod.3 for ; Mon, 18 Apr 2016 16:06:05 -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=MzgABPpXpPSxAf9rgN4aEql1ALmRs75bcIVELmm6SGs=; b=NQ4qDDWFyEcZ+0c+fZFK/l/3NWF+Yqx9PjlQUjDz4XDu/DMIYH7U8Jk9tgA81TNeCq vIH1Qa6Ug4hPXxzhn9/DdNTufQ0jwxm/GPjtDU0/GR2FHB3Oedx/+k9od3oE9WJzegHV zuHzTMQ2vJTtmfpFjebfCnEU+9V65y4khqjrDZlX5/3K5a6OFg5ccfhLLgce8QchrK0b bHIfwsHfiJUSXfi5iGEI23ddBem9QKu4/xV/BQF4J+Bcq9Irv7FaqEcO/K4zRX2wH2lJ b2RTnQbZBZFhrPF0T0IVwSAZD0vSVoKEhLphCJcyr4RfoV1Kk/hJW7j4oSzKA5cnNsuj QfLQ== 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=MzgABPpXpPSxAf9rgN4aEql1ALmRs75bcIVELmm6SGs=; b=Us/IyATkNBfia5cAnhRDIlcBJT6eAGmXPUv2aVJdsZUlB/YCB7MLb7DxzNZnQ4yYSJ JMVJBuInLdS8KMv55as0VXpVy3UhtyoguatemfemQr8xGU1cXQna/q04yarEZ1xebiuq z2R6zhcGEpVAQ+eKwtQgpI3Fdd8KyJLwD/98jYpstcVAelKagLXiQr9jb8YRW2/QrdLC 2iQ8PZleo9lQVMp3qhDwVRuZ2z9hZCyAYZ3bMqwl55rs4jgUSS+KLbKP3b67XlKVJYbV c7niVVYtJdL5KrXPLJGF3iWZ4FI6KI7BRRVHEpWOhhrE4/0PpLPwNoobWACUgWDa5w4X bVrw== X-Gm-Message-State: AOPr4FUWNcwJZCPlibQAF7tkjSRxotkHbIpGLqQ+NHRbTHLHJbBanWPy/RYB4JUzMuCqj9P1Gv8X6FAbxnOcWg== MIME-Version: 1.0 X-Received: by 10.107.129.32 with SMTP id c32mr367837iod.102.1461020764994; Mon, 18 Apr 2016 16:06:04 -0700 (PDT) Received: by 10.79.72.68 with HTTP; Mon, 18 Apr 2016 16:06:04 -0700 (PDT) In-Reply-To: References: <45DFA343-1FDD-4EB9-9291-AB3A830A3CD9@mnemosyne.demon.co.uk> Date: Mon, 18 Apr 2016 19:06:04 -0400 Message-ID: From: Stan Ratliff To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a113ec928b51ab00530ca676f Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" , Christopher Dearlove Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 18 Apr 2016 23:06:10 -0000 --001a113ec928b51ab00530ca676f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 18, 2016 at 11:23 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > Of course it makes sense - because it=E2=80=99s been done as I noted. > (*Still* speaking as a WG participant): OK, I get that. It's only minimally interesting (IMO), but I get it. > > > The multiplexer doesn=E2=80=99t actually have to parse messages, it needs= to group > them into packets. It needs to be able to parse a packet down to =E2=80= =9Chere are > the messages=E2=80=9D and deliver them. The messages can be simple blobs.= For that > it needs the message type - conveniently placed up front in the message > header to be read - and the message length - ditto. The parsing of the > messages is a protocol problem. If just implementing one protocol it coul= d > incorporate the parser. If implementing multiple protocols you can create > an independent parser. Or you may do the latter even in the former case. > > > > And even if we all implemented independent parsers they can be quite > different. As indeed the ones that exist are. Not just merely in API. For > example I could turn a message into a set of objects. Or I could provide > pointers into the data block that represents the message. And other > approaches. > And I think we've drifted from my initial ask - that the usage document better describe the usage of 5444. There's been a lot coming out of the various threads on this topic - how 5444 changes the relationship between protocol and interface, whether a parser is implemented or not, etc. The whole discussion (all of these different threads put together) *begs* for some additional clarity in the document. I've been (politely) turned away thus far, but speaking as a WG participant, but - again I stress that this is interesting, important information, and needs to be addressed in this document. Regards, Stan > > > *-- * > > > > > *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:* Stan Ratliff [mailto:ratliffstan@gmail.com] > *Sent:* 18 April 2016 14:18 > *To:* Dearlove, Christopher (UK) > *Cc:* Christopher Dearlove; manet@ietf.org; Christopher Dearlove > *Subject:* Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > > > > > **** 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 Mon, Apr 18, 2016 at 9:13 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > As has been pointed out to me, some implementations don=E2=80=99t do this= . If you > are building an implementation in a constrained environment, you can buil= d > a constrained implementation. And some people have. > > > > So no, it=E2=80=99s not appropriate to specify an independent parser, or = require > one. Rather you need to design so that when people do, it can be efficien= t. > Which is what we have been doing. > > > > Or in other words, I don=E2=80=99t think this sort of change is appropria= te. Quite > the contrary. > > > > Well, we disagree. This has been a fundamental point of contention for > some of the follow-on protocols attempting to use 5444. and IMO, this has > to be addressed. > > > > > > The key point is that what=E2=80=99s mandated is a multiplexer and a form= at. But > not an independent parser. > > > > How can you mandate a multiplexer, but not an independent parser? This > makes no sense. > > > > Stan > > > > > > > > *-- * > > > > > *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:* Stan Ratliff [mailto:ratliffstan@gmail.com] > *Sent:* 18 April 2016 14:09 > *To:* Dearlove, Christopher (UK) > *Cc:* Christopher Dearlove; manet@ietf.org; Christopher Dearlove > *Subject:* Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > > > > > **** 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 Mon, Apr 18, 2016 at 4:52 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > I don=E2=80=99t believe we can or should suggest an implementation. That= =E2=80=99s not > what the IETF does, and it would be a hard, probably impossible, sell, to > the IESG. That the obvious implementation employs an independent parser i= s > already said - it may be appropriate to strengthen the words, but this > second I=E2=80=99m not sure if that=E2=80=99s needed (not got time to che= ck current > wording). > > > > (Again, with my Working Group Participant hat on) - > > > > I don't mean to suggest an implementation. At least to me, this is an > architecture (that of an independent parser, with a reliable communicatio= ns > mechanism to said parser, that deals with logical messages instead of > packets. Is sequencing guaranteed? I'm not sure, to be honest. But once t= he > independent parser is assumed, engineers also MUST assume that the > transport (and it's the transport for control plane traffic, but not for > data plane traffic), is "owned" by the independent parser. > > > > Which leads me to the other point I'm trying to make (perhaps badly): > Abstracting the transport away from the control plane *can* effect > protocol design. > > > > I believe both of these points should be addressed in the usage document. > > > > Regards, > > Stan > > > > > > > > *-- * > > > > > *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 *Stan Ratliff > *Sent:* 16 April 2016 19:09 > *To:* Christopher Dearlove > *Cc:* manet@ietf.org; Christopher Dearlove > *Subject:* Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > > > > > **** 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 Fri, Apr 15, 2016 at 3:27 PM, Christopher Dearlove < > chris@mnemosyne.demon.co.uk> wrote: > > I don't understand what you mean by the concept of "fields the protocol > can and can't touch". > > > > CAVEAT: I am speaking here as a Working Group participant. With that > understood: > > > > > TTL is a great example, since that discussion blew the mailing list up a > few months ago. I'm *not* saying manipulating TTL is a good thing for a > protocol to try - in truth, I think it's pretty "hacky". But the notion w= as > floated, and in the context of that discussion, it may will have worked. > The opposition on-list was fast, and pretty forceful. > > I've said before - 5444, especially with the multiplexer, changes the > relationship between a routing protocol and an interface. I think the > document should have some type of "overview" section which discusses thes= e > differences, in order to frame the issue for someone coming along who > hasn't been a part of the 5444 mail discussion. > > I'm talking about the type of overview that goes something like this: > > "Use of RFC 5444 with the multiplexer feature imposes design requirements > on the protocol. The actual transport mechanism is abstracted from the > protocol. For example, routing protocols are not aware of precisely when = a > message is sent. A good example of operation in this model is [BGP], > utilizing the [TCP] transport. This is opposed to a protocol such as > [OSPF], which is capable of sending traffic with its own IP type. Since t= he > transport is abstracted, protocols are not presented with "packets", and > are not capable of manipulating data items in packet headers (e.g. data > items at the IP and/or MAC layers)." > > As Lou Berger put it to me in the context of DLEP - "You want an engineer > to be able to pick up this document, with no prior exposure to the topic, > and code an interoperable implementation." I think this type of an > overview, setting basic ground rules, would help. > > I've also contended for a while now that 5444, with the mux, effectively > forces an architecture on implementers - in the Linux world, that > architecture is a 5444 parser as an independent process, with IPC > mechanisms to the routing protocol(s) it is servicing. The 5444 parser > itself "owns" the transport (the socket). The usage document *strongly > infers* that. I believe we should concretely state it, so we don't have t= o > answer the question over and over again. > > Regards, > > Stan > > > > > > > When a protocol creates a message from scratch it's not constrained in an= y > way I'd describe in such terms. So I assume you mean when it receives a > message and then sends a similar message. > > > > There are two cases there. Unchanged (with the special exceptions for hop > count and limit) and not unchanged. The former is better, and there's > really nothing more to say. > > > > So let's consider the latter. Really it's not the same message, it's a > brand new message. That's a useful way to look at it from a security > perspective, because it tells you that end to end authentication isn't > going to work. And what are the restrictions on brand new messages? The > same as on any new message. > > > > OK, you might say, true but does that mean I can add this, remove that, > change the hop data? Yes. But is that a good idea? No. But maybe you are > forced into it. But that it's inherently not good suggests the corollary > that if you must, do the minimum and make it trackable. But that's not a > 5444 requirement, just good practice. It does break 7182 message ICVs, so > don't use them. > > > > We could, hypothetically, have someone create an extension or alternative > to 7182 that defined aggregated signatures. Then we'd have rules on what > you could change. But that would belong there. If you think those would b= e > good, then again you would want make minimal changes, and mainly only of > certain types. What types? There I can't help you as I don't have a > candidate. > > > > The summary? Don't change if you don't have to. That's recommended. If yo= u > must change you're on your own (with the same restrictions as new > messages). Advice like "as little as possible" is good, but that's not > actually 5444 advice. And don't use 7182 message ICVs. > > -- > > Christopher Dearlove > > christopher.dearlove@gmail.com (iPhone) > > chris@mnemosyne.demon.co.uk (home) > > > On 15 Apr 2016, at 19:37, Stan Ratliff wrote: > > My main concern addressed inline... > > > > > > On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlove < > christopher.dearlove@gmail.com> wrote: > > A few immediate comments inline below. > > -- > > Christopher Dearlove > > christopher.dearlove@gmail.com (iPhone) > > chris@mnemosyne.demon.co.uk (home) > > > On 15 Apr 2016, at 15:18, Lotte Steenbrink > wrote: > > Hi all, > > > > sparked by the recently started WGLC, I=E2=80=99ve reviewed the current r= evision > of the draft. I=E2=80=99d like to offer the working group my perspective = as someone > who doesn=E2=80=99t have decades of protocol and/or packet format design = under > their belt (i.e. some things might not be obvious to me that are obvious = to > others), but also as someone who has worked with RFC 5444 when implementi= ng > a routing protocol (AODVv2), updating the packet format of a routing > protocol (AODVv2 again) and (partially) implementing my own RFC5444 > builder/parser. > > > > Overall, I think the document is easy to read and follow. To me, it > contains valuable information and guidance and in some cases prevents > people from shooting themselves in the foot. > > I=E2=80=99m really happy this document exists and I=E2=80=99d like it to = move forward > soon, but I do feel that it is still lacking in some areas, which is why = I > was a bit surprised to see it go to Last Call all of a sudden. > > > > Not really. The authors had said what they intended to say, no one was > commenting, time for WGLC. > > > > First, some nitpicks and comments: > > > > * from *1.2.1* > *. > Packet/Message Format*: > > > > [=E2=80=A6] a packet > > transmission following a successful packet reception is by design > > of a new packet that may include all, some, or none of the > > received messages [...] > > > > I=E2=80=99m not a native speaker, but that =E2=80=9Eof=E2=80=9C seems out= of place... > > > > I am a native speaker, and no, it's not. Some would repeat it after each > of all, some and none, and I might sometimes. But it really doesn't matte= r > which of the two styles we pick, the RFC Editor may well change to the > other. > > > > * Regarding *4.2* > *. > Packets and Messages:* > > this section talks a lot about how the multiplexer operates, so I think > it=E2=80=99d be helpful if its title reflected that. > > > > I'm of two opinions on that. On the one hand it is, as its title suggests= , > about the packet and message level, as opposed to lower levels, and its > title contrasts with that if 4.3 for that reason. On the other hand you a= re > right, it does have much about the multiplexer. A title covering all thre= e > woukd start getting cumbersome. Will take this one away to think about. > > > > * from *4.4* > *. > Addresses Require Attributes:* > > > > An unmodified extension to NHDP would ignore such addresses, > > as required, as it does not support that specialized purpose. > > > > At first glance, (to me) this reads as =E2=80=9EAll addresses that are as= sociated > with an unknown TLV are ignored=E2=80=9C, which is obviously nonsense (bu= t quite > panic-inducing :D). I=E2=80=99d propose to reword it to something along t= he lines > of > > An unmodified extension to NHDP would not consider this > > address to be of a neighbor, as it is lacking a LINK_STATUS > > or OTHER_NEIGHB TLV. > > > > I take your point, but I think that if the address ends up with no > relevant associated TLVs then it is ignored is also a point. I dare say w= e > can wordsmith something. > > > > Also, I don=E2=80=99t quite get where you=E2=80=99re going with the last = paragraph of that > section (=E2=80=9CThese restrictions do not, however, mean that added inf= ormation > is > > completely ignored for purposes of the base protocol.=E2=80=9D)... > > > > Read on, the rest of the paragraph describes the case where not. But we > might telegraph that better in the opening sentence. > > > > * regarding the maps in *4.5* > *. > Information Representation:* > > I=E2=80=99m afraid I just don=E2=80=99t really understand the purpose of = this section and > the mapping notation. I=E2=80=99m assuming that the maps are supposed to = offer a > way of describing how a TLV relates to a message or an address? > > If so, why does it only mention extension types, but not the basis types? > > > > It says extended types, meaning the combination of the two. But full type > would be better, as almost defined in 5444. In fact I think we should add= a > comment to the notation section. (5444 uses a symbolic name rather than t= he > phrase.) > > > > Or is it supposed to be used something like this: > > > > *BASE_TLV* > > > > Message: > > (base_tlv_extension_type_1) -> (2 octets, "value a when condition x is > met") > > (base_tlv_extension_type_2) -> (2 octets, "value b when condition y is > met") > > > > ? Also, I don=E2=80=99t quite get how this would be used in future protoc= ol > specifications? Or aid in implementing RFC5444 parsers? > > An example or a clarification would be very helpful. > > > > It's a way of looking at things. But not the only one, it goes on to > discuss variants. I think it mostly comes under heading of if useful use > it, if not skip it. We'll take another look, but I don't think this will > ever be elementary. > > > > * regarding *4.6* > *. > TLVs:* > > In general, it=E2=80=99s not clear everywhere in the section whether you= =E2=80=99re > talking to RFC5444 parser/builder implementors or protocol designers. > > > > A protocol SHOULD use an efficient > > representation, but this is a quality of implementation issue. > > > > I=E2=80=99m not sure where you=E2=80=99re going with the last part of tha= t sentence? I=E2=80=99d > reword it to something like =E2=80=9EA protocol SHOULD use an efficient > representation, avoiding unnecessarily verbose use of TLVs and extension > types. However, the final arrangement in a message- or addressTLV block i= s > a quality of implementation issue=E2=80=9C (in case that=E2=80=99s what = you meant). > > > > No, you're considering the protocol design. This is considering the > protocol object that implements the protocol. There isn't a one to one > mapping from information to representation, it's up to the implementation > to do it efficiently. Different implementations of the same protocol > specification may do better or worse here. (Trivial case, an implementati= on > could choose to never compress addresses. Bad idea, but legal.) > > > > And then: > > > > A > > protocol MUST recognize any permitted representation of the > > information; even if it chooses to (for example) only use multivalue > > TLVs, it MUST recognize single value TLVs (and vice versa). > > > > =E2=80=A6 I thought protocols weren=E2=80=99t supposed to specify whether= a TLV is > arranged (for example) as a multivalue TLV?! > > > > Implementation again, not design. > > > > And so, since a protocol shouldn't be concerned with multivalue TLVs and > the like, wouldn=E2=80=99t it be the *RFC5444 implementation* that MUST r= ecognize > any permitted representation? > > > > You're assuming that there is an RFC 5444 implementation. That's the same > way to work if you plan to implement more than one protocol. But nothing > says you have to do it that way. The architecture defined by 5498 admits = of > the multiplexer and protocols, and thus these are rules on the protocol. = If > protocols delegate all their common work to something (parser/creator) th= en > it inherits those restrictions, but that's not defined, and we can't assu= me > it. > > > > Or is this paragraph really just a complicated way of saying =E2=80=9Eas = a > protocol designer, make sure to not specify/rely on things like (for > example) multivalue TLVs, since your messages have to work with *any* > representation=E2=80=9C? If so, I think that should be done in a less com= plicated > fashion (see below). > > > > * regarding *5* > = *. > Structure:* > > Since this section talks a lot about flags, it=E2=80=99d be nice if its t= itle > represented that. Maybe consider renaming it to =E2=80=9EStructure and Fl= ags=E2=80=9C or so? > > > > I mostly don't agree. Structure is the subject, flags are a detail. > > > > * from *6.1* > *. > Address Block Compression:* > > > > Compression of addresses in an Address Block considers addresses to > > consist of a Head, a Mid, and a Tail, where all addresses in an > > Address Block have the same Head and Tail, but different Mids. > > > > > > I=E2=80=99d find this sentence easier to read if it started with =E2=80= =9CCompression of > addresses in an Address Block is possible when addresses consist of a Hea= d, > a Mid [=E2=80=A6]=E2=80=9D. > > > > No. That's missing the point and misleading. Addresses are always > considered to have the head/mid/tail format. Compression is possible if > either the head or tail (or both) is non-empty. > > > > * from *6.1* > *. > Address Block Compression:* > > > > Putting addresses into a message efficiently also has to include: > > > > Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that would be a =E2=80=9E= may=E2=80=9C. Multiple Adress Blocks > and/or reordering don=E2=80=99t increase efficiency in all possible cases= ... > > > > I think that's the wrong change. Rather "include" should be "consider". > > > > * from *6.2* > *. > TLVs:* > > [...] This is even possible if the MPR TLV specified in > > OLSRv2 [RFC7181 ] is added; bu= t it is not possible, in general, if > > the LINK_METRIC TLV is also added. > > > > Why is it not possible for the latter? If that could be explained/hinted > at in a half sentence, I think it=E2=80=99d be helpful information to hav= e in the > draft. > > > > That's very hard, and not just because it's a negative. It's really an > observation that motivates the duscussion. A half sentence would I think > confuse more than it enlightens (it's because you have too many constrain= ts > to satisfy at once - I doubt that helped). > > > > In a typical case where a > > LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with > > enough addresses, sorted appropriately, two single value TLVs can > > be more efficient than one multivalue TLV. > > > > Same thing: why? > > > > Here I think this should be obvious to anyone who has looked at 5444. > > > > * regarding the second paragraph from *6.3* > *. > TLV Values*, i.e. > > > > This approach was specified in [RFC7188 ], and required for protocols > > that extend [RFC6130 ] and [RFC71= 81 ]. It is here RECOMMENDED that > > this approach is followed when defining any Address Block TLV that > > may be used by a protocol using [RFC5444 ]. > > > > The term =E2=80=9Ethis approach=E2=80=9C confused me, since I initially = thought it meant > =E2=80=9Ethe approach is to use UNSPECIFIED in a way that makes sense=E2= =80=9C rather than > =E2=80=9Ethe approach is to use UNSPECIFIED=E2=80=9C. Maybe that could be= reworded to > something along the lines of > > The UNSPECIFIED TLV and its usage was specified in [RFC7188]=E2=80=A6 > > ? > > > > No. There is no UNSPECIFIED TLV. There is a recommendation to include an > UNSPECIFIED value in a TLV. But really, we've described this once in 7188= , > it's there to read. > > > > * regarding *6.3* > *. > TLV Values:* > > The second paragraph is a bit confusing and seems to explaing roghly the > same things as the fourth paragraphs. I=E2=80=99d propose to merge the se= cond into > the fourth. > > > > I'm not sure I exactly agree, but the ordering in that section could be > improved. > > > > * from *6.4* > *. > Automation:* > > > > The possible gain depends on the efficiency > > of the original message creation, > > > > the term =E2=80=9Ethe original message creation=E2=80=9C seems a bit ambi= guous=E2=80=93 does this > refer to the message as created by an RFC5444 message builder > implementation? > > > > Yes. > > > > Additionally, I'm concerned about two things that *aren=E2=80=99t* in the= draft: > > > > * Some of the AODVv2 co-authors and me have asked for a list of =E2=80= =9Eas a > protocol, you can set all of these fields of a message, but please leave > the rest alone=E2=80=9C, which would=E2=80=99ve saved us many hours of di= scussions (and > Henning a lot of time spent explaining these things=E2=80=A6). These requ= ests have > been met with a refusal to specify a concrete API, as such an effort is > dependent on outside factors such as programming language or software > architecture. I agree with this notion, but a programming-language > dependent API is not what we=E2=80=99ve asked for. I=E2=80=99ve tried to = supply a sketch of > what I did ask for in [1], but unfortunately I didn=E2=80=99t get an answ= er (and as > far as I can see it, the draft wasn=E2=80=99t changed either). I still th= ink that > such a list, in whatever form, would be very helpful for future > Internet-Draft authors and I also think this request is in accordance wit= h > the intentions stated in 1.1 History and Purpose, and I think it should > be included in the document. > > > > No. There are many reasons why we're just not touching this one. > > > > One is that language independence is a mirage. How you go about things is > completely different in, for example an object oriented language than one > that isn't. Section 4.5 shows that there are quite different ways of doin= g > things even given a decision to use a map approach, and there are other > approaches than that. It would be wrong and beyond our competence to > suggest one of these as "best". There's reasons the IETF doesn't do this, > and that's one. > > > > Plus, frankly, the work it would take is beyond what we choose to spend. > > > > > > > > > > I'm confused (which is an altogether too common occurrence these days). I > get that we don't want to specify an API. But I think the discussion abou= t > fields a protocol can and can't touch in a messages is a good thing - and > it's one spot where I, too, find the document wanting. > > > > To paraphrase something I've said before, I believe that RFC 5444 changes > the relationship that a routing protocol has with an "interface". I'm not > commenting on whether or not that's a good thing, or a bad thing - just > that it does change the relationship. This change has been at the root of > some of the long-running discussions as to whether protocols under > development were RFC 5444 compliant or not. The goal of this document bei= ng > to eliminate (it's a goal, probably not reachable) those discussions, I'd > like to see that information in the document in some form. > > > > I'm interested in seeing this document progress, and eventually be > published. I think it will help future protocol designers to better use R= FC > 5444. But I would like to see *something* along the lines of what Lotte i= s > requesting, as I think it will improve the doc. > > > > Regards, > > Stan > > > > > > > > * As the exact rules for using/setting the hop count & hop-limit fields > are currently being discussed w/ regard to AODVv2 in another thread [2]= =E2=80=93 > should a definitive answer to that question be part of 5444-usage? > > > > You don't want that. Because if we did specify that you'd find yourself > more constrained than you want to be. There is a design intent described = in > 5444, but it assumes immutable messages. Which you don't want. Really, > we're doing you a favour by not imposing on you. > > > > Best regards, > > Lotte > > > > [1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.html > > [2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.html > > > > > > Am 06.04.2016 um 19:14 schrieb Justin Dean : > > > > The chairs agree that a 3 week WGLC is appropriate. Everyone please read > the draft early and get comments in early so that they can be addressed > within the last call period. > > > > Justin > > > > On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > Obviously +1 to the request for WGLC. > > With regard to what's changed, technically the only significant thing is > to make it clear that if a protocol delivers a message to the multiplexer= , > the multiplexer must pass it on unchanged to the protocol (another instan= ce > of, at another router) unchanged. Without that nothing that the protocol > itself chooses to do with regard to security makes sense. Though the > protocol can alternatively let the multiplexer do the security, 7182 can = be > implemented in either way. This isn't really new, but it wasn't formally > spelled out. It's presented as part of spelling out multiplexer rules mor= e > carefully. > > But what about message optimisation? That's a function of constructing a > 5444 message, not the multiplexer, and is down to that 5444 includes two > things - packet/message structure (and implicitly, and in pretty much any > implementation I would expect to see, a parser and builder for that > structure) and the multiplexer. So we took the opportunity to separate ou= t > more clearly a discussion of the two, which we think will be helpful. > > -- > 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 > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg > Sent: 05 April 2016 20:08 > To: manet@ietf.org > Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 > > ----------------------! WARNING ! ---------------------- This message > originates from outside our organisation, either from an external partner > or from the internet. > Consider carefully whether you should click on any links, open any > attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions > on reporting suspicious email messages. > -------------------------------------------------------- > > *** WARNING *** > EXTERNAL EMAIL -- This message originates from outside our organization. > > > > Hi, > > As you have seen, we have submitted a new revision of 5444-usage. The > authors feel comfortable that we have addressed all issues by this versio= n, > and would like to ask the WG chairs to issue a WGLC on this document. Whi= le > it is a fairly short document, given that it is IETF week for some, we'd > suggest that a 3-4 week WGLC would be appropriate. > > Best regards > Ulrich > > _______________________________________________ > 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 > > > > _______________________________________________ > 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 > > > > > > > > > --001a113ec928b51ab00530ca676f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 18, 2016 at 11:23 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

Of course it makes sense = - because it=E2=80=99s been done as I noted.


(*Still* speaking as a WG participant):

OK, I get that. It's only minimally interesting (IMO), but I ge= t it.
=C2=A0

=C2=A0

The multiplexer doesn=E2= =80=99t actually have to parse messages, it needs to group them into packet= s. It needs to be able to parse a packet down to =E2=80=9Chere are the mess= ages=E2=80=9D and deliver them. The messages can be simple blobs. For that it needs the = message type - conveniently placed up front in the message header to be rea= d - and the message length - ditto. The parsing of the messages is a protoc= ol problem. If just implementing one protocol it could incorporate the parser. If implementing multiple pro= tocols you can create an independent parser. Or you may do the latter even = in the former case.

=C2=A0

And even if we all implem= ented independent parsers they can be quite different. As indeed the ones t= hat exist are. Not just merely in API. For example I could turn a message into a set of objects. Or I could provide pointers into the= data block that represents the message.=C2=A0 And other approaches.=



And I think we've = drifted from my initial ask - that the usage document better describe the u= sage of 5444. There's been a lot coming out of the various threads on t= his topic - how 5444 changes the relationship between protocol and interfac= e, whether a parser is implemented or not, etc. The whole discussion (all o= f these different threads put together) *begs* for some additional clarity = in the document. I've been (politely) turned away thus far, but speakin= g as a WG participant, but - again I stress that this is interesting, impor= tant information, and needs to be addressed in this document.

Regards,
Stan

=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: Stan Ratliff [mailto:ratliffstan@gmail.com]
Sent: 18 April 2016 14:18
To: Dearlove, Christopher (UK)
Cc: Christopher Dearlove; manet@ietf.org; Christopher Dearlove
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage= -03

=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 Mon, Apr 18, 2016 at 9:13 AM, Dearlove, Christoph= er (UK) <chris.dearlove@baesystems.com> wrote:

As has been pointed out t= o me, some implementations don=E2=80=99t do this. If you are building an im= plementation in a constrained environment, you can build a constrained implementation. = And some people have.

=C2=A0

So no, it=E2=80=99s not a= ppropriate to specify an independent parser, or require one. Rather you nee= d to design so that when people do, it can be efficient. Which is what we have = been doing.

=C2=A0

Or in other words, I don= =E2=80=99t think this sort of change is appropriate. Quite the contrary.

=C2=A0

Well, we disagree. This has been a fundamental point= of contention for some of the follow-on protocols attempting to use 5444. = and IMO, this has to be addressed.=C2=A0

=C2=A0

=C2=A0

The key point is that wha= t=E2=80=99s mandated is a multiplexer and a format. But not an independent = parser.

=C2=A0

How can you mandate a multiplexer, but not an indepe= ndent parser? This makes no sense.=C2=A0

=C2=A0

Stan=C2=A0

=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: Stan Ratliff [mailto:ratliffstan@gmail.com]
Sent: 18 April 2016 14:09
To: Dearlove, Christopher (UK)
Cc: Christopher Dearlove; manet@ietf.org; Christopher Dearlove
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage= -03

=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.

=C2=A0

=C2=A0

On Mon, Apr 18, 2016 at 4:52 AM, Dearlove, Christoph= er (UK) <chris.dearlove@baesystems.com> wrote:

I don=E2=80=99t believe w= e can or should suggest an implementation. That=E2=80=99s not what the IETF= does, and it would be a hard, probably impossible, sell, to the IESG. That the obvious = implementation employs an independent parser is already said - it may be ap= propriate to strengthen the words, but this second I=E2=80=99m not sure if = that=E2=80=99s needed (not got time to check current wording).

=C2=A0

(Again, with my Working Group Participant hat on) -= =C2=A0

=C2=A0

I don't mean to suggest an implementation. At le= ast to me, this is an architecture (that of an independent parser, with a r= eliable communications mechanism to said parser, that deals with logical messages instead of packets. Is sequencing guaranteed? = I'm not sure, to be honest. But once the independent parser is assumed,= engineers also MUST assume that the transport (and it's the transport = for control plane traffic, but not for data plane traffic), is "owned" by the independent parser.=C2=A0

=C2=A0

Which leads me to the other point I'm trying to = make (perhaps badly): =C2=A0Abstracting the transport away from the control= plane *can* effect protocol design.=C2=A0

=C2=A0

I believe both of these points should be addressed i= n the usage document.=C2=A0

=C2=A0

Regards,

Stan

=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 Stan Ratliff
Sent: 16 April 2016 19:09
To: Christopher Dearlove
Cc: manet@ietf.o= rg; Christopher Dearlove
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage= -03

=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

=C2=A0

On Fri, Apr 15, 2016 at 3:27 PM, Christopher Dearlov= e <chri= s@mnemosyne.demon.co.uk> wrote:

I don't understand what you mean by the concept = of "fields the protocol can and can't touch".

=C2=A0<= /p>

CAVEAT: I am speaking here as a Working Group partic= ipant. With that understood:
=C2=A0

=C2=A0

TTL is a great exampl= e, since that discussion blew the mailing list up a few months ago. I'm= *not* saying manipulating TTL is a good thing for a protocol to try - in t= ruth, I think it's pretty "hacky". But the notion was floated, and in the context o= f that discussion, it may will have worked. The opposition on-list was fast= , and pretty forceful.

I've said before = - 5444, especially with the multiplexer, changes the relationship between a= routing protocol and an interface. I think the document should have some t= ype of "overview" section which discusses these differences, in order to frame the issue for= someone coming along who hasn't been a part of the 5444 mail discussio= n.

I'm talking about= the type of overview that goes something like this:

"Use of RFC 5444= with the multiplexer feature imposes design requirements on the protocol. = The actual transport mechanism is abstracted from the protocol. For example= , routing protocols are not aware of precisely when a message is sent. A good example of opera= tion in this model is [BGP], utilizing the [TCP] transport. This is opposed= to a protocol such as [OSPF], which is capable of sending traffic with its= own IP type. Since the transport is abstracted, protocols are not presented with "packets", and a= re not capable of manipulating data items in packet headers (e.g. data item= s at the IP and/or MAC layers)."

As Lou Berger put it to me in the context of DLEP - "You want an engin= eer to be able to pick up this document, with no prior exposure to the topi= c, and code an interoperable implementation."=C2=A0 I think this type = of an overview, setting basic ground rules, would help.

I've also contend= ed for a while now that 5444, with the mux, effectively forces an architect= ure on implementers - in the Linux world, that architecture is a 5444 parse= r as an independent process, with IPC mechanisms to the routing protocol(s) it is servicing. T= he 5444 parser itself "owns" the transport (the socket). The usag= e document *strongly infers* that. I believe we should concretely state it,= so we don't have to answer the question over and over again.

Regards,

Stan


=C2=A0

=C2=A0

When a protocol creates a message from scratch it= 9;s not constrained in any way I'd describe in such terms. So I assume = you mean when it receives a message and then sends a similar message.

=C2=A0

There are two cases there. Unchanged (with the speci= al exceptions for hop count and limit) and not unchanged. The former is bet= ter, and there's really nothing more to say.

=C2=A0

So let's consider the latter. Really it's no= t the same message, it's a brand new message. That's a useful way t= o look at it from a security perspective, because it tells you that end to end authentication isn't going to work. And what are the restri= ctions on brand new messages? The same as on any new message.=

=C2=A0

OK, you might say, true but does that mean I can add= this, remove that, change the hop data? Yes. But is that a good idea? No. = But maybe you are forced into it. But that it's inherently not good suggests the corollary that if you must, do the minimum and make = it trackable. But that's not a 5444 requirement, just good practice. It= does break 7182 message ICVs, so don't use them.

=C2=A0

We could, hypothetically, have someone create an ext= ension or alternative to 7182 that defined aggregated signatures. Then we&#= 39;d have rules on what you could change. But that would belong there. If you think those would be good, then again you would want = make minimal changes, and mainly only of certain types. What types? There I= can't help you as I don't have a candidate.

=C2=A0

The summary? Don't change if you don't have = to. That's recommended. If you must change you're on your own (with= the same restrictions as new messages). Advice like "as little as possible" is good, but that's not actually 5444 advice. And don&#= 39;t use 7182 message ICVs.

-- =C2=A0

Christopher Dearlove


On 15 Apr 2016, at 19:37, Stan Ratliff <ratliffstan@gmail.com> wrote:

My main concern addressed inline...

=C2=A0

=C2=A0

On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlov= e <c= hristopher.dearlove@gmail.com> wrote:

A few immediate comments inline below.

-- =C2=A0

Christopher Dearlove


On 15 Apr 2016, at 15:18, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de>= ; wrote:

Hi all,

=C2=A0

sparked by the recently started WGLC, I=E2=80=99ve r= eviewed the current revision of the draft. I=E2=80=99d like to offer the wo= rking group my perspective as someone who doesn=E2=80=99t have decades of protocol and/or packet format design under their belt (i.e. some things mi= ght not be obvious to me that are obvious to others), but also as someone w= ho has worked with RFC 5444 when implementing a routing protocol (AODVv2), = updating the packet format of a routing protocol (AODVv2 again) and (partially) implementing my own RFC544= 4 builder/parser.

=C2=A0

Overall, I think the document is easy to read and fo= llow. To me, it contains valuable information and guidance and in some case= s prevents people from shooting themselves in the foot.

I=E2=80=99m really happy this document exists and I= =E2=80=99d like it to move forward soon, but I do feel that it is still lac= king in some areas, which is why I was a bit surprised to see it go to Last Call all of a sudden.

=C2=A0

Not really. The authors had said what they intended = to say, no one was commenting, time for WGLC.

=C2=A0<= /p>

First, some nitpicks and comments:

=C2=A0

* from=C2=A01.2.1. Packet/Message Format:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0[=E2=80=A6] a packet

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 transmission following a successful pac=
ket reception is by design


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of a new packet that may include all, s=
ome, or none of the


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 received messages [...]

=C2=A0

I=E2=80=99m not a native speaker, but that =E2=80=9E= of=E2=80=9C seems out of place...

=C2=A0

I am a native speaker, and no, it's not. Some wo= uld repeat it after each of all, some and none, and I might sometimes. But = it really doesn't matter which of the two styles we pick, the RFC Editor may well change to the other.

=C2=A0<= /p>

* Regarding=C2=A04.2. Packets and Messages:

this section talks a lot about how the multiplexer o= perates, so I think it=E2=80=99d be helpful if its title reflected that.=C2= =A0

=C2=A0

I'm of two opinions on that. On the one hand it = is, as its title suggests, about the packet and message level, as opposed t= o lower levels, and its title contrasts with that if 4.3 for that reason. On the other hand you are right, it does have much about = the multiplexer. A title covering all three woukd start getting cumbersome.= Will take this one away to think about.

=C2=A0<= /p>

* from=C2=A04.4. Addresses Require Attributes:

=C2=A0

=C2=A0=C2=A0 An unmodified extension to NHDP would ignore such address=
es,
=C2=A0=C2=A0 as required, as it does not support that specialized purp=
ose.

=C2=A0

At first glance, (to me) this reads as =E2=80=9EAll = addresses that are associated with an unknown TLV are ignored=E2=80=9C, whi= ch is obviously nonsense (but quite panic-inducing :D). I=E2=80=99d propose to reword it to something along the lines of=C2=A0

=C2=A0=C2=A0 An unmodified extension to NHDP would not consider this
=C2=A0=C2=A0 address to be of a neighbor, as it is lacking a LINK_STAT=
US
=C2=A0=C2=A0 or OTHER_NEIGHB TLV.

=C2=A0

I take your point, but I think that if the address e= nds up with no relevant associated TLVs then it is ignored is also a point.= I dare say we can wordsmith something.

=C2=A0<= /p>

Also, I don=E2=80=99t quite get where you=E2=80=99re= going with the last paragraph of that section (=E2=80=9CThese restrictions do not, however, mean that added informat= ion is

=C2=A0=C2=A0 completely ignored for purposes of the base protocol.=E2=
=80=9D)...

=C2=A0

Read on, the rest of the paragraph describes the cas= e where not. But we might telegraph that better in the opening sentence.=

=C2=A0<= /p>

Or is it supposed to be used something like this:=

=C2=A0

BASE_TLV

=C2=A0

Message:=C2=A0

(base_tlv_extens= ion_type_1) -> (2 octets, "value a when condition x is met")

(base_tlv_extens= ion_type_2) -> (2 octets, "value b when condition y is met")

=C2=A0

? Also, I don=E2=80=99t quite get how this would be = used in future protocol specifications? Or aid in implementing RFC5444 pars= ers?

An example or a clarification would be very helpful.=

=C2=A0

It's a way of looking at things. But not the onl= y one, it goes on to discuss variants. I think it mostly comes under headin= g of if useful use it, if not skip it. We'll take another look, but I don't think this will ever be elementary.

=C2=A0<= /p>

In general, it=E2=80=99s not clear everywhere in the= section whether you=E2=80=99re talking to RFC5444 parser/builder implement= ors or protocol designers.=C2=A0

=C2=A0

=C2=A0=C2=A0 A protocol SHOULD use an efficient
=C2=A0=C2=A0 representation, but this is a quality of implementation i=
ssue.

=C2=A0

I=E2=80=99m not sure where you=E2=80=99re going with= the last part of that sentence? I=E2=80=99d reword it to something like = =E2=80=9EA protocol SHOULD use an efficient representation, avoiding unnece= ssarily verbose use of TLVs and extension types. However, the final arrangement in a messa= ge- or addressTLV block is =C2=A0a quality of implementation issue=E2=80=9C= (in case that=E2=80=99s what you meant).

=C2=A0

No, you're considering the protocol design. This= is considering the protocol object that implements the protocol. There isn= 't a one to one mapping from information to representation, it's up to the implementation to do it efficiently. Different implemen= tations of the same protocol specification may do better or worse here. (Tr= ivial case, an implementation could choose to never compress addresses. Bad= idea, but legal.)

=C2=A0<= /p>

And then:

=C2=A0

=C2=A0=C2=A0 A
=C2=A0=C2=A0 protocol MUST recognize any permitted representation of t=
he
=C2=A0=C2=A0 information; even if it chooses to (for example) only use=
 multivalue
=C2=A0=C2=A0 TLVs, it MUST recognize single value TLVs (and vice versa=
).

=C2=A0

=E2=80=A6 I thought protocols weren=E2=80=99t suppos= ed to specify whether a TLV is arranged (for example) as a multivalue TLV?!=

=C2=A0

Implementation again, not design.

=C2=A0<= /p>

And so, since a protocol shouldn't be concerned = with multivalue TLVs and the like, wouldn=E2=80=99t it be the *RFC5444 impl= ementation* that MUST recognize any permitted representation?=

=C2=A0

You're assuming that there is an RFC 5444 implem= entation. That's the same way to work if you plan to implement more tha= n one protocol. But nothing says you have to do it that way. The architecture defined by 5498 admits of the multiplexer and protocols, = and thus these are rules on the protocol. If protocols delegate all their c= ommon work to something (parser/creator) then it inherits those restriction= s, but that's not defined, and we can't assume it.

=C2=A0<= /p>

Or is this paragraph really just a complicated way o= f saying =E2=80=9Eas a protocol designer, make sure to not specify/rely on = things like (for example) multivalue TLVs, since your messages have to work with *any* representation=E2=80=9C? If so, I think that shoul= d be done in a less complicated fashion (see below).

=C2=A0

* regarding=C2=A05. Structure:

Since this section talks a lot about flags, it=E2=80= =99d be nice if its title represented that. Maybe consider renaming it to= =C2=A0=E2=80=9EStructure and Flags=E2=80=9C=C2=A0or so?

=C2=A0

I mostly don't agree. Structure is the subject, = flags are a detail.

=C2=A0<= /p>

* from=C2=A06.1. Address Block Compression:

=C2=A0

=C2=A0=C2=A0 Compression of addresses in an Address Block considers ad=
dresses to
=C2=A0=C2=A0 consist of a Head, a Mid, and a Tail, where all addresses=
 in an
=C2=A0=C2=A0 Address Block have the same Head and Tail, but different =
Mids.

=C2=A0

=C2=A0

I=E2=80=99d find this sentence easier to read if it = started with =E2=80=9CCompression of addresses in an Address Block is possi= ble when addresses consist of a Head, a Mid [=E2=80=A6]=E2=80=9D.=

=C2=A0

No. That's missing the point and misleading. Add= resses are always considered to have the head/mid/tail format. Compression = is possible if either the head or tail (or both) is non-empty.

=C2=A0<= /p>

* from=C2=A06.1. Address Block Compression:

=C2=A0
=C2=A0=C2=A0 Putting addresses into a message efficiently also has to =
include:
=C2=A0

Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that= would be a =E2=80=9Emay=E2=80=9C. Multiple Adress Blocks and/or reordering= don=E2=80=99t increase efficiency in all possible cases...

=C2=A0

I think that's the wrong change. Rather "in= clude" should be "consider".

=C2=A0<= /p>

* from=C2=A06.2. TLVs:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [...] This is even possible if the MPR =
TLV specified in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OLSRv2 [RFC7181] is added; but it is not poss=
ible, in general, if
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the LINK_METRIC TLV is also added.

=C2=A0

Why is it not possible for the latter? If that could= be explained/hinted at in a half sentence, I think it=E2=80=99d be helpful= information to have in the draft.

=C2=A0

That's very hard, and not just because it's = a negative. It's really an observation that motivates the duscussion. A= half sentence would I think confuse more than it enlightens (it's because you have too many constraints to satisfy at once - I doubt that he= lped).

=C2=A0<= /p> 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In a typical case where a=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LINK_STATUS TLV uses only the Values HE=
ARD and SYMMETRIC, with
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enough addresses, sorted appropriately,=
 two single value TLVs can
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 be more efficient than one multivalue T=
LV.

=C2=A0

Same thing: why?

=C2=A0

Here I think this should be obvious to anyone who ha= s looked at 5444.

=C2=A0<= /p>

* regarding the second paragraph from=C2=A06= .3. TLV Values, i.e.

=C2=A0 =C2=A0
=C2=A0=C2=A0 This approach was specified in [RFC718=
8], and required for protocols
=C2=A0=C2=A0 that extend [RFC6130] and [RFC7181].=C2=A0 It is her=
e RECOMMENDED that
=C2=A0=C2=A0 this approach is followed when defining any Address Block=
 TLV that
=C2=A0=C2=A0 may be used by a protocol using [RFC5444].

=C2=A0

The term =E2=80=9Ethis approach=E2=80=9C confused me= , since I initially =C2=A0thought it meant =E2=80=9Ethe approach is to use = UNSPECIFIED in a way that makes sense=E2=80=9C rather than =E2=80=9Ethe app= roach is to use UNSPECIFIED=E2=80=9C. Maybe that could be reworded to something along the lines of=C2=A0<= u>

The UNSPECIFIED = TLV and its usage was specified in [RFC7188]=E2=80=A6=C2=A0

?

=C2=A0

No. There is no UNSPECIFIED TLV. There is a recommen= dation to include an UNSPECIFIED value in a TLV. But really, we've desc= ribed this once in 7188, it's there to read.

=C2=A0<= /p>

* regarding=C2=A06.3. TLV Values:

The second paragraph is a bit confusing and seems to= explaing roghly the same things as the fourth paragraphs. I=E2=80=99d prop= ose to merge the second into the fourth.

=C2=A0

I'm not sure I exactly agree, but the ordering i= n that section could be improved.

=C2=A0<= /p>

* from=C2=A06.4. Automation:

=C2=A0

=C2=A0=C2=A0 The possible gain depends on the efficiency=

=C2=A0=C2=A0 of the original message creation,

=C2=A0

the term =E2=80=9Ethe original message creation=E2= =80=9C seems a bit ambiguous=E2=80=93 does this refer to the message as cre= ated by an RFC5444 message builder implementation?

=C2=A0

Yes.

=C2=A0<= /p>

Additionally, I'm concerned about two things tha= t *aren=E2=80=99t* in the draft:

=C2=A0

* =C2=A0Some of the AODVv2 co-authors and me have as= ked for a list of =E2=80=9Eas a protocol, you can set all of these fields o= f a message, but please leave the rest alone=E2=80=9C, which would=E2=80=99= ve saved us many hours of discussions (and Henning a lot of time spent explaining t= hese things=E2=80=A6). These requests have been met with a refusal to speci= fy a concrete API, as such an effort is dependent on outside factors such a= s programming language or software architecture. I agree with this notion, but a programming-language dependent API is not = what we=E2=80=99ve asked for. I=E2=80=99ve tried to supply a sketch of what= I did ask for in [1], but unfortunately I didn=E2=80=99t get an answer (an= d as far as I can see it, the draft wasn=E2=80=99t changed either). I still think that such a list, in whatever form, would be very helpful fo= r future Internet-Draft authors and I also think this request is in accorda= nce with the intentions stated in=C2=A0= 1.1 History and Purpose,=C2=A0and I think it should be included in the document.

=C2=A0

No. There are many reasons why we're just not to= uching this one.

=C2=A0

One is that language independence is a mirage. How y= ou go about things is completely different in, for example an object orient= ed language than one that isn't. Section 4.5 shows that there are quite different ways of doing things even given a decision = to use a map approach, and there are other approaches than that. It would b= e wrong and beyond our competence to suggest one of these as "best&quo= t;. There's reasons the IETF doesn't do this, and that's one.

=C2=A0

Plus, frankly, the work it would take is beyond what= we choose to spend.

=C2=A0

=C2=A0

<Speaking as a WG Participant>

=C2=A0

I'm confused (which is an altogether too common = occurrence these days). I get that we don't want to specify an API. But= I think the discussion about fields a protocol can and can't touch in a messages is a good thing - and it's one spot where I, too, = find the document wanting.=C2=A0

=C2=A0

To paraphrase something I've said before, I beli= eve that RFC 5444 changes the relationship that a routing protocol has with= an "interface". I'm not commenting on whether or not that's a good thing, or a bad thing - just that it does change the rel= ationship. This change has been at the root of some of the long-running dis= cussions as to whether protocols under development were RFC 5444 compliant = or not. The goal of this document being to eliminate (it's a goal, probably not reachable) those discussions, = I'd like to see that information in the document in some form.=C2=A0=

=C2=A0

I'm interested in seeing this document progress,= and eventually be published. I think it will help future protocol designer= s to better use RFC 5444. But I would like to see *something* along the lines of what Lotte is requesting, as I think it will improve th= e doc.=C2=A0

=C2=A0

Regards,

Stan

=C2=A0

=C2=A0

=C2=A0<= /p>

* As the exact rules for using/setting the hop count= & hop-limit fields are currently being discussed w/ regard to AODVv2 i= n another thread [2]=E2=80=93 should a definitive answer to that question be part of 5444-usage?

=C2=A0

You don't want that. Because if we did specify t= hat you'd find yourself more constrained than you want to be. There is = a design intent described in 5444, but it assumes immutable messages. Which you don't want. Really, we're doing you a favour b= y not imposing on you.

=C2=A0<= /p>

=C2=A0

=C2=A0

Am 06.04.2016 um 19:14 schrieb Justin Dean <bebemaster@gmail.com>:

=C2=A0

The chairs agree that a 3 week WGLC is appropriate.= =C2=A0 Everyone please read the draft early and get comments in early so th= at they can be addressed within the last call period.

=C2=A0

Justin

=C2=A0

On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christophe= r (UK) <chris.dearlove@baesystems.com> wrote:

Obviously +1 to the request for WGLC.

With regard to what's changed, technically the only significant thing i= s to make it clear that if a protocol delivers a message to the multiplexer= , the multiplexer must pass it on unchanged to the protocol (another instan= ce of, at another router) unchanged. Without that nothing that the protocol itself chooses to do with regard to= security makes sense. Though the protocol can alternatively let the multip= lexer do the security, 7182 can be implemented in either way. This isn'= t really new, but it wasn't formally spelled out. It's presented as part of spelling out multiplexer rules = more carefully.

But what about message optimisation? That's a function of constructing = a 5444 message, not the multiplexer, and is down to that 5444 includes two = things - packet/message structure (and implicitly, and in pretty much any i= mplementation I would expect to see, a parser and builder for that structure) and the multiplexer. So we took t= he opportunity to separate out more clearly a discussion of the two, which = we think will be helpful.

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

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN.
www.baesystems.c= om/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 Ulrich Herberg
Sent: 05 April 2016 20:08
To: manet@ietf.org<= br> Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

----------------------! 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 instru= ctions on reporting suspicious email messages.
--------------------------------------------------------

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



Hi,

As you have seen, we have submitted a new revision of 5444-usage. The autho= rs feel comfortable that we have addressed all issues by this version, and = would like to ask the WG chairs to issue a WGLC on this document. While it = is a fairly short document, given that it is IETF week for some, we'd suggest that a 3-4 week WGLC would= be appropriate.

Best regards
Ulrich

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://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
h= ttps://www.ietf.org/mailman/listinfo/manet

=C2=A0

_______________________________________________
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

=C2=A0

=C2=A0


--001a113ec928b51ab00530ca676f-- From nobody Tue Apr 19 02:02: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 DEC4A12DBEB for ; Tue, 19 Apr 2016 02:02:43 -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 veMOllK3aDB8 for ; Tue, 19 Apr 2016 02:02:38 -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 38DA012D85C for ; Tue, 19 Apr 2016 02:02:37 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,506,1454976000"; d="scan'208,217"; a="33804318" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 19 Apr 2016 10:02:35 +0100 X-IronPort-AV: E=Sophos;i="5.24,506,1454976000"; d="scan'208,217";a="114544003" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 19 Apr 2016 10:02:35 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0248.002; Tue, 19 Apr 2016 10:02:33 +0100 From: "Dearlove, Christopher (UK)" To: Stan Ratliff Thread-Topic: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 Thread-Index: AQHRj26efzFsMll+IU2A0f8aUpvZOp980SWwgABO2gCADfPgAIAAOu8AgAANM4CAAZs2zoACiJ1wgAA3bACAABD7IP//8YIAgAAxN1CAAHMuAIAAtoYA Date: Tue, 19 Apr 2016 09:02:32 +0000 Message-ID: References: <45DFA343-1FDD-4EB9-9291-AB3A830A3CD9@mnemosyne.demon.co.uk> 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AEC54GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" , Christopher Dearlove Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03 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, 19 Apr 2016 09:02:44 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AEC54GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gYWZyYWlkIEnigJltIG5vdCBnZXR0aW5nIHRoZSBhc2sgaGVyZS4NCg0KV2UgaGF2ZSBh IHdob2xlIHNlY3Rpb24gMSBvbiBkZXNjcmliaW5nIHRoZSB1c2FnZSBvZiA1NDQ0LiAgSW4gc29t ZSBkZXRhaWwuDQoNCldoYXQsIHNwZWNpZmljYWxseSwgaXMgbWlzc2luZyAtIGp1c3Qg4oCcZXhw bGFpbiBiZXR0ZXLigJ0gaXMgbm90IGhlbHBmdWwuDQoNCihJ4oCZdmUgc3BlbnQgbXVjaCBvZiBt eSB0aW1lIGV4cGxhaW5pbmcgdGhhdCB0aGVyZSBpcyBubyBtYW5kYXRlZCBwYXJzZXIuIEEgZmV3 IHdvcmRzIG9uIHRoYXQgYXJlIHNvbWV0aGluZyB0aGF0IHdlIGNhbiBhZGQuKQ0KDQotLQ0KQ2hy aXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1z IEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K VDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBB cHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJh ZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxo dHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxp Z2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUx DQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3Vy cmV5LCBHVTIgN1lQDQoNCkZyb206IFN0YW4gUmF0bGlmZiBbbWFpbHRvOnJhdGxpZmZzdGFuQGdt YWlsLmNvbV0NClNlbnQ6IDE5IEFwcmlsIDIwMTYgMDA6MDYNClRvOiBEZWFybG92ZSwgQ2hyaXN0 b3BoZXIgKFVLKQ0KQ2M6IENocmlzdG9waGVyIERlYXJsb3ZlOyBtYW5ldEBpZXRmLm9yZzsgQ2hy aXN0b3BoZXIgRGVhcmxvdmUNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFdHTEMgcmVxdWVzdCBmb3Ig ZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzDQoNCg0KKioqIFdBUk5JTkcgKioqDQpU aGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0 aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBj YXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkg YXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFn cyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sg aGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0 eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhl IGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9p bnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMv RG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KDQoN Ck9uIE1vbiwgQXByIDE4LCAyMDE2IGF0IDExOjIzIEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIg KFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3Zl QGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQpPZiBjb3Vyc2UgaXQgbWFrZXMgc2Vuc2UgLSBiZWNh dXNlIGl04oCZcyBiZWVuIGRvbmUgYXMgSSBub3RlZC4NCg0KKCpTdGlsbCogc3BlYWtpbmcgYXMg YSBXRyBwYXJ0aWNpcGFudCk6DQpPSywgSSBnZXQgdGhhdC4gSXQncyBvbmx5IG1pbmltYWxseSBp bnRlcmVzdGluZyAoSU1PKSwgYnV0IEkgZ2V0IGl0Lg0KDQoNClRoZSBtdWx0aXBsZXhlciBkb2Vz buKAmXQgYWN0dWFsbHkgaGF2ZSB0byBwYXJzZSBtZXNzYWdlcywgaXQgbmVlZHMgdG8gZ3JvdXAg dGhlbSBpbnRvIHBhY2tldHMuIEl0IG5lZWRzIHRvIGJlIGFibGUgdG8gcGFyc2UgYSBwYWNrZXQg ZG93biB0byDigJxoZXJlIGFyZSB0aGUgbWVzc2FnZXPigJ0gYW5kIGRlbGl2ZXIgdGhlbS4gVGhl IG1lc3NhZ2VzIGNhbiBiZSBzaW1wbGUgYmxvYnMuIEZvciB0aGF0IGl0IG5lZWRzIHRoZSBtZXNz YWdlIHR5cGUgLSBjb252ZW5pZW50bHkgcGxhY2VkIHVwIGZyb250IGluIHRoZSBtZXNzYWdlIGhl YWRlciB0byBiZSByZWFkIC0gYW5kIHRoZSBtZXNzYWdlIGxlbmd0aCAtIGRpdHRvLiBUaGUgcGFy c2luZyBvZiB0aGUgbWVzc2FnZXMgaXMgYSBwcm90b2NvbCBwcm9ibGVtLiBJZiBqdXN0IGltcGxl bWVudGluZyBvbmUgcHJvdG9jb2wgaXQgY291bGQgaW5jb3Jwb3JhdGUgdGhlIHBhcnNlci4gSWYg aW1wbGVtZW50aW5nIG11bHRpcGxlIHByb3RvY29scyB5b3UgY2FuIGNyZWF0ZSBhbiBpbmRlcGVu ZGVudCBwYXJzZXIuIE9yIHlvdSBtYXkgZG8gdGhlIGxhdHRlciBldmVuIGluIHRoZSBmb3JtZXIg Y2FzZS4NCg0KQW5kIGV2ZW4gaWYgd2UgYWxsIGltcGxlbWVudGVkIGluZGVwZW5kZW50IHBhcnNl cnMgdGhleSBjYW4gYmUgcXVpdGUgZGlmZmVyZW50LiBBcyBpbmRlZWQgdGhlIG9uZXMgdGhhdCBl eGlzdCBhcmUuIE5vdCBqdXN0IG1lcmVseSBpbiBBUEkuIEZvciBleGFtcGxlIEkgY291bGQgdHVy biBhIG1lc3NhZ2UgaW50byBhIHNldCBvZiBvYmplY3RzLiBPciBJIGNvdWxkIHByb3ZpZGUgcG9p bnRlcnMgaW50byB0aGUgZGF0YSBibG9jayB0aGF0IHJlcHJlc2VudHMgdGhlIG1lc3NhZ2UuICBB bmQgb3RoZXIgYXBwcm9hY2hlcy4NCg0KQW5kIEkgdGhpbmsgd2UndmUgZHJpZnRlZCBmcm9tIG15 IGluaXRpYWwgYXNrIC0gdGhhdCB0aGUgdXNhZ2UgZG9jdW1lbnQgYmV0dGVyIGRlc2NyaWJlIHRo ZSB1c2FnZSBvZiA1NDQ0LiBUaGVyZSdzIGJlZW4gYSBsb3QgY29taW5nIG91dCBvZiB0aGUgdmFy aW91cyB0aHJlYWRzIG9uIHRoaXMgdG9waWMgLSBob3cgNTQ0NCBjaGFuZ2VzIHRoZSByZWxhdGlv bnNoaXAgYmV0d2VlbiBwcm90b2NvbCBhbmQgaW50ZXJmYWNlLCB3aGV0aGVyIGEgcGFyc2VyIGlz IGltcGxlbWVudGVkIG9yIG5vdCwgZXRjLiBUaGUgd2hvbGUgZGlzY3Vzc2lvbiAoYWxsIG9mIHRo ZXNlIGRpZmZlcmVudCB0aHJlYWRzIHB1dCB0b2dldGhlcikgKmJlZ3MqIGZvciBzb21lIGFkZGl0 aW9uYWwgY2xhcml0eSBpbiB0aGUgZG9jdW1lbnQuIEkndmUgYmVlbiAocG9saXRlbHkpIHR1cm5l ZCBhd2F5IHRodXMgZmFyLCBidXQgc3BlYWtpbmcgYXMgYSBXRyBwYXJ0aWNpcGFudCwgYnV0IC0g YWdhaW4gSSBzdHJlc3MgdGhhdCB0aGlzIGlzIGludGVyZXN0aW5nLCBpbXBvcnRhbnQgaW5mb3Jt YXRpb24sIGFuZCBuZWVkcyB0byBiZSBhZGRyZXNzZWQgaW4gdGhpcyBkb2N1bWVudC4NClJlZ2Fy ZHMsDQpTdGFuDQoNCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFs IEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVsOiUyQjQ0JTIw JTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNv bTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFw cGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFk ZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0 dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln ZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTEN ClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJy ZXksIEdVMiA3WVANCg0KRnJvbTogU3RhbiBSYXRsaWZmIFttYWlsdG86cmF0bGlmZnN0YW5AZ21h aWwuY29tPG1haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb20+XQ0KU2VudDogMTggQXByaWwgMjAx NiAxNDoxOA0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpDYzogQ2hyaXN0b3BoZXIg RGVhcmxvdmU7IG1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz47IENocmlzdG9w aGVyIERlYXJsb3ZlDQpTdWJqZWN0OiBSZTogW21hbmV0XSBXR0xDIHJlcXVlc3QgZm9yIGRyYWZ0 LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMw0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBt ZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBm cm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1 bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFj aG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhh dCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8 aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3Bv dGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFp bCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFu ZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3Vt ZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCg0KDQpPbiBN b24sIEFwciAxOCwgMjAxNiBhdCA5OjEzIEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8 Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tPj4gd3JvdGU6DQpBcyBoYXMgYmVlbiBwb2ludGVkIG91dCB0byBtZSwgc29tZSBp bXBsZW1lbnRhdGlvbnMgZG9u4oCZdCBkbyB0aGlzLiBJZiB5b3UgYXJlIGJ1aWxkaW5nIGFuIGlt cGxlbWVudGF0aW9uIGluIGEgY29uc3RyYWluZWQgZW52aXJvbm1lbnQsIHlvdSBjYW4gYnVpbGQg YSBjb25zdHJhaW5lZCBpbXBsZW1lbnRhdGlvbi4gQW5kIHNvbWUgcGVvcGxlIGhhdmUuDQoNClNv IG5vLCBpdOKAmXMgbm90IGFwcHJvcHJpYXRlIHRvIHNwZWNpZnkgYW4gaW5kZXBlbmRlbnQgcGFy c2VyLCBvciByZXF1aXJlIG9uZS4gUmF0aGVyIHlvdSBuZWVkIHRvIGRlc2lnbiBzbyB0aGF0IHdo ZW4gcGVvcGxlIGRvLCBpdCBjYW4gYmUgZWZmaWNpZW50LiBXaGljaCBpcyB3aGF0IHdlIGhhdmUg YmVlbiBkb2luZy4NCg0KT3IgaW4gb3RoZXIgd29yZHMsIEkgZG9u4oCZdCB0aGluayB0aGlzIHNv cnQgb2YgY2hhbmdlIGlzIGFwcHJvcHJpYXRlLiBRdWl0ZSB0aGUgY29udHJhcnkuDQoNCldlbGws IHdlIGRpc2FncmVlLiBUaGlzIGhhcyBiZWVuIGEgZnVuZGFtZW50YWwgcG9pbnQgb2YgY29udGVu dGlvbiBmb3Igc29tZSBvZiB0aGUgZm9sbG93LW9uIHByb3RvY29scyBhdHRlbXB0aW5nIHRvIHVz ZSA1NDQ0LiBhbmQgSU1PLCB0aGlzIGhhcyB0byBiZSBhZGRyZXNzZWQuDQoNCg0KVGhlIGtleSBw b2ludCBpcyB0aGF0IHdoYXTigJlzIG1hbmRhdGVkIGlzIGEgbXVsdGlwbGV4ZXIgYW5kIGEgZm9y bWF0LiBCdXQgbm90IGFuIGluZGVwZW5kZW50IHBhcnNlci4NCg0KSG93IGNhbiB5b3UgbWFuZGF0 ZSBhIG11bHRpcGxleGVyLCBidXQgbm90IGFuIGluZGVwZW5kZW50IHBhcnNlcj8gVGhpcyBtYWtl cyBubyBzZW5zZS4NCg0KU3Rhbg0KDQoNCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5p b3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBM YWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8 dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBi YWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJB RSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFy aywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3Rl bXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBs aWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBO bzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3Vp bGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTogU3RhbiBSYXRsaWZmIFttYWlsdG86cmF0 bGlmZnN0YW5AZ21haWwuY29tPG1haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb20+XQ0KU2VudDog MTggQXByaWwgMjAxNiAxNDowOQ0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpDYzog Q2hyaXN0b3BoZXIgRGVhcmxvdmU7IG1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9y Zz47IENocmlzdG9waGVyIERlYXJsb3ZlDQpTdWJqZWN0OiBSZTogW21hbmV0XSBXR0xDIHJlcXVl c3QgZm9yIGRyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMw0KDQoNCioqKiBXQVJOSU5H ICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRp b24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29u c2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9w ZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBS ZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUs IGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsv c2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBm ZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2Vzczxo dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90 bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRm Pi4NCg0KDQpPbiBNb24sIEFwciAxOCwgMjAxNiBhdCA0OjUyIEFNLCBEZWFybG92ZSwgQ2hyaXN0 b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQpJIGRvbuKAmXQgYmVsaWV2ZSB3ZSBjYW4g b3Igc2hvdWxkIHN1Z2dlc3QgYW4gaW1wbGVtZW50YXRpb24uIFRoYXTigJlzIG5vdCB3aGF0IHRo ZSBJRVRGIGRvZXMsIGFuZCBpdCB3b3VsZCBiZSBhIGhhcmQsIHByb2JhYmx5IGltcG9zc2libGUs IHNlbGwsIHRvIHRoZSBJRVNHLiBUaGF0IHRoZSBvYnZpb3VzIGltcGxlbWVudGF0aW9uIGVtcGxv eXMgYW4gaW5kZXBlbmRlbnQgcGFyc2VyIGlzIGFscmVhZHkgc2FpZCAtIGl0IG1heSBiZSBhcHBy b3ByaWF0ZSB0byBzdHJlbmd0aGVuIHRoZSB3b3JkcywgYnV0IHRoaXMgc2Vjb25kIEnigJltIG5v dCBzdXJlIGlmIHRoYXTigJlzIG5lZWRlZCAobm90IGdvdCB0aW1lIHRvIGNoZWNrIGN1cnJlbnQg d29yZGluZykuDQoNCihBZ2Fpbiwgd2l0aCBteSBXb3JraW5nIEdyb3VwIFBhcnRpY2lwYW50IGhh dCBvbikgLQ0KDQpJIGRvbid0IG1lYW4gdG8gc3VnZ2VzdCBhbiBpbXBsZW1lbnRhdGlvbi4gQXQg bGVhc3QgdG8gbWUsIHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJlICh0aGF0IG9mIGFuIGluZGVwZW5k ZW50IHBhcnNlciwgd2l0aCBhIHJlbGlhYmxlIGNvbW11bmljYXRpb25zIG1lY2hhbmlzbSB0byBz YWlkIHBhcnNlciwgdGhhdCBkZWFscyB3aXRoIGxvZ2ljYWwgbWVzc2FnZXMgaW5zdGVhZCBvZiBw YWNrZXRzLiBJcyBzZXF1ZW5jaW5nIGd1YXJhbnRlZWQ/IEknbSBub3Qgc3VyZSwgdG8gYmUgaG9u ZXN0LiBCdXQgb25jZSB0aGUgaW5kZXBlbmRlbnQgcGFyc2VyIGlzIGFzc3VtZWQsIGVuZ2luZWVy cyBhbHNvIE1VU1QgYXNzdW1lIHRoYXQgdGhlIHRyYW5zcG9ydCAoYW5kIGl0J3MgdGhlIHRyYW5z cG9ydCBmb3IgY29udHJvbCBwbGFuZSB0cmFmZmljLCBidXQgbm90IGZvciBkYXRhIHBsYW5lIHRy YWZmaWMpLCBpcyAib3duZWQiIGJ5IHRoZSBpbmRlcGVuZGVudCBwYXJzZXIuDQoNCldoaWNoIGxl YWRzIG1lIHRvIHRoZSBvdGhlciBwb2ludCBJJ20gdHJ5aW5nIHRvIG1ha2UgKHBlcmhhcHMgYmFk bHkpOiAgQWJzdHJhY3RpbmcgdGhlIHRyYW5zcG9ydCBhd2F5IGZyb20gdGhlIGNvbnRyb2wgcGxh bmUgKmNhbiogZWZmZWN0IHByb3RvY29sIGRlc2lnbi4NCg0KSSBiZWxpZXZlIGJvdGggb2YgdGhl c2UgcG9pbnRzIHNob3VsZCBiZSBhZGRyZXNzZWQgaW4gdGhlIHVzYWdlIGRvY3VtZW50Lg0KDQpS ZWdhcmRzLA0KU3Rhbg0KDQoNCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJp bmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0 b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVsOiUy QjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0 ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3Jl YXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29t L2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIElu dGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEz Mzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3Jk LCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGll dGYub3JnPG1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFN0YW4g UmF0bGlmZg0KU2VudDogMTYgQXByaWwgMjAxNiAxOTowOQ0KVG86IENocmlzdG9waGVyIERlYXJs b3ZlDQpDYzogbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPjsgQ2hyaXN0b3Bo ZXIgRGVhcmxvdmUNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFdHTEMgcmVxdWVzdCBmb3IgZHJhZnQt aWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1l c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZy b20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVs bHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNo bWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0 IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxo dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90 bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWls IGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5l dC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1l bnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KKioqIFdBUk5J TkcgKioqDQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91 dHNpZGUgb3VyIG9yZ2FuaXphdGlvbi4NCg0KDQoNCk9uIEZyaSwgQXByIDE1LCAyMDE2IGF0IDM6 MjcgUE0sIENocmlzdG9waGVyIERlYXJsb3ZlIDxjaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWs8 bWFpbHRvOmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51az4+IHdyb3RlOg0KSSBkb24ndCB1bmRl cnN0YW5kIHdoYXQgeW91IG1lYW4gYnkgdGhlIGNvbmNlcHQgb2YgImZpZWxkcyB0aGUgcHJvdG9j b2wgY2FuIGFuZCBjYW4ndCB0b3VjaCIuDQoNCkNBVkVBVDogSSBhbSBzcGVha2luZyBoZXJlIGFz IGEgV29ya2luZyBHcm91cCBwYXJ0aWNpcGFudC4gV2l0aCB0aGF0IHVuZGVyc3Rvb2Q6DQoNCg0K VFRMIGlzIGEgZ3JlYXQgZXhhbXBsZSwgc2luY2UgdGhhdCBkaXNjdXNzaW9uIGJsZXcgdGhlIG1h aWxpbmcgbGlzdCB1cCBhIGZldyBtb250aHMgYWdvLiBJJ20gKm5vdCogc2F5aW5nIG1hbmlwdWxh dGluZyBUVEwgaXMgYSBnb29kIHRoaW5nIGZvciBhIHByb3RvY29sIHRvIHRyeSAtIGluIHRydXRo LCBJIHRoaW5rIGl0J3MgcHJldHR5ICJoYWNreSIuIEJ1dCB0aGUgbm90aW9uIHdhcyBmbG9hdGVk LCBhbmQgaW4gdGhlIGNvbnRleHQgb2YgdGhhdCBkaXNjdXNzaW9uLCBpdCBtYXkgd2lsbCBoYXZl IHdvcmtlZC4gVGhlIG9wcG9zaXRpb24gb24tbGlzdCB3YXMgZmFzdCwgYW5kIHByZXR0eSBmb3Jj ZWZ1bC4NCkkndmUgc2FpZCBiZWZvcmUgLSA1NDQ0LCBlc3BlY2lhbGx5IHdpdGggdGhlIG11bHRp cGxleGVyLCBjaGFuZ2VzIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBhIHJvdXRpbmcgcHJvdG9j b2wgYW5kIGFuIGludGVyZmFjZS4gSSB0aGluayB0aGUgZG9jdW1lbnQgc2hvdWxkIGhhdmUgc29t ZSB0eXBlIG9mICJvdmVydmlldyIgc2VjdGlvbiB3aGljaCBkaXNjdXNzZXMgdGhlc2UgZGlmZmVy ZW5jZXMsIGluIG9yZGVyIHRvIGZyYW1lIHRoZSBpc3N1ZSBmb3Igc29tZW9uZSBjb21pbmcgYWxv bmcgd2hvIGhhc24ndCBiZWVuIGEgcGFydCBvZiB0aGUgNTQ0NCBtYWlsIGRpc2N1c3Npb24uDQpJ J20gdGFsa2luZyBhYm91dCB0aGUgdHlwZSBvZiBvdmVydmlldyB0aGF0IGdvZXMgc29tZXRoaW5n IGxpa2UgdGhpczoNCiJVc2Ugb2YgUkZDIDU0NDQgd2l0aCB0aGUgbXVsdGlwbGV4ZXIgZmVhdHVy ZSBpbXBvc2VzIGRlc2lnbiByZXF1aXJlbWVudHMgb24gdGhlIHByb3RvY29sLiBUaGUgYWN0dWFs IHRyYW5zcG9ydCBtZWNoYW5pc20gaXMgYWJzdHJhY3RlZCBmcm9tIHRoZSBwcm90b2NvbC4gRm9y IGV4YW1wbGUsIHJvdXRpbmcgcHJvdG9jb2xzIGFyZSBub3QgYXdhcmUgb2YgcHJlY2lzZWx5IHdo ZW4gYSBtZXNzYWdlIGlzIHNlbnQuIEEgZ29vZCBleGFtcGxlIG9mIG9wZXJhdGlvbiBpbiB0aGlz IG1vZGVsIGlzIFtCR1BdLCB1dGlsaXppbmcgdGhlIFtUQ1BdIHRyYW5zcG9ydC4gVGhpcyBpcyBv cHBvc2VkIHRvIGEgcHJvdG9jb2wgc3VjaCBhcyBbT1NQRl0sIHdoaWNoIGlzIGNhcGFibGUgb2Yg c2VuZGluZyB0cmFmZmljIHdpdGggaXRzIG93biBJUCB0eXBlLiBTaW5jZSB0aGUgdHJhbnNwb3J0 IGlzIGFic3RyYWN0ZWQsIHByb3RvY29scyBhcmUgbm90IHByZXNlbnRlZCB3aXRoICJwYWNrZXRz IiwgYW5kIGFyZSBub3QgY2FwYWJsZSBvZiBtYW5pcHVsYXRpbmcgZGF0YSBpdGVtcyBpbiBwYWNr ZXQgaGVhZGVycyAoZS5nLiBkYXRhIGl0ZW1zIGF0IHRoZSBJUCBhbmQvb3IgTUFDIGxheWVycyku Ig0KDQpBcyBMb3UgQmVyZ2VyIHB1dCBpdCB0byBtZSBpbiB0aGUgY29udGV4dCBvZiBETEVQIC0g IllvdSB3YW50IGFuIGVuZ2luZWVyIHRvIGJlIGFibGUgdG8gcGljayB1cCB0aGlzIGRvY3VtZW50 LCB3aXRoIG5vIHByaW9yIGV4cG9zdXJlIHRvIHRoZSB0b3BpYywgYW5kIGNvZGUgYW4gaW50ZXJv cGVyYWJsZSBpbXBsZW1lbnRhdGlvbi4iICBJIHRoaW5rIHRoaXMgdHlwZSBvZiBhbiBvdmVydmll dywgc2V0dGluZyBiYXNpYyBncm91bmQgcnVsZXMsIHdvdWxkIGhlbHAuDQpJJ3ZlIGFsc28gY29u dGVuZGVkIGZvciBhIHdoaWxlIG5vdyB0aGF0IDU0NDQsIHdpdGggdGhlIG11eCwgZWZmZWN0aXZl bHkgZm9yY2VzIGFuIGFyY2hpdGVjdHVyZSBvbiBpbXBsZW1lbnRlcnMgLSBpbiB0aGUgTGludXgg d29ybGQsIHRoYXQgYXJjaGl0ZWN0dXJlIGlzIGEgNTQ0NCBwYXJzZXIgYXMgYW4gaW5kZXBlbmRl bnQgcHJvY2Vzcywgd2l0aCBJUEMgbWVjaGFuaXNtcyB0byB0aGUgcm91dGluZyBwcm90b2NvbChz KSBpdCBpcyBzZXJ2aWNpbmcuIFRoZSA1NDQ0IHBhcnNlciBpdHNlbGYgIm93bnMiIHRoZSB0cmFu c3BvcnQgKHRoZSBzb2NrZXQpLiBUaGUgdXNhZ2UgZG9jdW1lbnQgKnN0cm9uZ2x5IGluZmVycyog dGhhdC4gSSBiZWxpZXZlIHdlIHNob3VsZCBjb25jcmV0ZWx5IHN0YXRlIGl0LCBzbyB3ZSBkb24n dCBoYXZlIHRvIGFuc3dlciB0aGUgcXVlc3Rpb24gb3ZlciBhbmQgb3ZlciBhZ2Fpbi4NClJlZ2Fy ZHMsDQpTdGFuDQoNCg0KDQpXaGVuIGEgcHJvdG9jb2wgY3JlYXRlcyBhIG1lc3NhZ2UgZnJvbSBz Y3JhdGNoIGl0J3Mgbm90IGNvbnN0cmFpbmVkIGluIGFueSB3YXkgSSdkIGRlc2NyaWJlIGluIHN1 Y2ggdGVybXMuIFNvIEkgYXNzdW1lIHlvdSBtZWFuIHdoZW4gaXQgcmVjZWl2ZXMgYSBtZXNzYWdl IGFuZCB0aGVuIHNlbmRzIGEgc2ltaWxhciBtZXNzYWdlLg0KDQpUaGVyZSBhcmUgdHdvIGNhc2Vz IHRoZXJlLiBVbmNoYW5nZWQgKHdpdGggdGhlIHNwZWNpYWwgZXhjZXB0aW9ucyBmb3IgaG9wIGNv dW50IGFuZCBsaW1pdCkgYW5kIG5vdCB1bmNoYW5nZWQuIFRoZSBmb3JtZXIgaXMgYmV0dGVyLCBh bmQgdGhlcmUncyByZWFsbHkgbm90aGluZyBtb3JlIHRvIHNheS4NCg0KU28gbGV0J3MgY29uc2lk ZXIgdGhlIGxhdHRlci4gUmVhbGx5IGl0J3Mgbm90IHRoZSBzYW1lIG1lc3NhZ2UsIGl0J3MgYSBi cmFuZCBuZXcgbWVzc2FnZS4gVGhhdCdzIGEgdXNlZnVsIHdheSB0byBsb29rIGF0IGl0IGZyb20g YSBzZWN1cml0eSBwZXJzcGVjdGl2ZSwgYmVjYXVzZSBpdCB0ZWxscyB5b3UgdGhhdCBlbmQgdG8g ZW5kIGF1dGhlbnRpY2F0aW9uIGlzbid0IGdvaW5nIHRvIHdvcmsuIEFuZCB3aGF0IGFyZSB0aGUg cmVzdHJpY3Rpb25zIG9uIGJyYW5kIG5ldyBtZXNzYWdlcz8gVGhlIHNhbWUgYXMgb24gYW55IG5l dyBtZXNzYWdlLg0KDQpPSywgeW91IG1pZ2h0IHNheSwgdHJ1ZSBidXQgZG9lcyB0aGF0IG1lYW4g SSBjYW4gYWRkIHRoaXMsIHJlbW92ZSB0aGF0LCBjaGFuZ2UgdGhlIGhvcCBkYXRhPyBZZXMuIEJ1 dCBpcyB0aGF0IGEgZ29vZCBpZGVhPyBOby4gQnV0IG1heWJlIHlvdSBhcmUgZm9yY2VkIGludG8g aXQuIEJ1dCB0aGF0IGl0J3MgaW5oZXJlbnRseSBub3QgZ29vZCBzdWdnZXN0cyB0aGUgY29yb2xs YXJ5IHRoYXQgaWYgeW91IG11c3QsIGRvIHRoZSBtaW5pbXVtIGFuZCBtYWtlIGl0IHRyYWNrYWJs ZS4gQnV0IHRoYXQncyBub3QgYSA1NDQ0IHJlcXVpcmVtZW50LCBqdXN0IGdvb2QgcHJhY3RpY2Uu IEl0IGRvZXMgYnJlYWsgNzE4MiBtZXNzYWdlIElDVnMsIHNvIGRvbid0IHVzZSB0aGVtLg0KDQpX ZSBjb3VsZCwgaHlwb3RoZXRpY2FsbHksIGhhdmUgc29tZW9uZSBjcmVhdGUgYW4gZXh0ZW5zaW9u IG9yIGFsdGVybmF0aXZlIHRvIDcxODIgdGhhdCBkZWZpbmVkIGFnZ3JlZ2F0ZWQgc2lnbmF0dXJl cy4gVGhlbiB3ZSdkIGhhdmUgcnVsZXMgb24gd2hhdCB5b3UgY291bGQgY2hhbmdlLiBCdXQgdGhh dCB3b3VsZCBiZWxvbmcgdGhlcmUuIElmIHlvdSB0aGluayB0aG9zZSB3b3VsZCBiZSBnb29kLCB0 aGVuIGFnYWluIHlvdSB3b3VsZCB3YW50IG1ha2UgbWluaW1hbCBjaGFuZ2VzLCBhbmQgbWFpbmx5 IG9ubHkgb2YgY2VydGFpbiB0eXBlcy4gV2hhdCB0eXBlcz8gVGhlcmUgSSBjYW4ndCBoZWxwIHlv dSBhcyBJIGRvbid0IGhhdmUgYSBjYW5kaWRhdGUuDQoNClRoZSBzdW1tYXJ5PyBEb24ndCBjaGFu Z2UgaWYgeW91IGRvbid0IGhhdmUgdG8uIFRoYXQncyByZWNvbW1lbmRlZC4gSWYgeW91IG11c3Qg Y2hhbmdlIHlvdSdyZSBvbiB5b3VyIG93biAod2l0aCB0aGUgc2FtZSByZXN0cmljdGlvbnMgYXMg bmV3IG1lc3NhZ2VzKS4gQWR2aWNlIGxpa2UgImFzIGxpdHRsZSBhcyBwb3NzaWJsZSIgaXMgZ29v ZCwgYnV0IHRoYXQncyBub3QgYWN0dWFsbHkgNTQ0NCBhZHZpY2UuIEFuZCBkb24ndCB1c2UgNzE4 MiBtZXNzYWdlIElDVnMuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KY2hyaXN0b3BoZXIu ZGVhcmxvdmVAZ21haWwuY29tPG1haWx0bzpjaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb20+ IChpUGhvbmUpDQpjaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWs8bWFpbHRvOmNocmlzQG1uZW1v c3luZS5kZW1vbi5jby51az4gKGhvbWUpDQoNCk9uIDE1IEFwciAyMDE2LCBhdCAxOTozNywgU3Rh biBSYXRsaWZmIDxyYXRsaWZmc3RhbkBnbWFpbC5jb208bWFpbHRvOnJhdGxpZmZzdGFuQGdtYWls LmNvbT4+IHdyb3RlOg0KTXkgbWFpbiBjb25jZXJuIGFkZHJlc3NlZCBpbmxpbmUuLi4NCg0KDQpP biBGcmksIEFwciAxNSwgMjAxNiBhdCAxOjQ5IFBNLCBDaHJpc3RvcGhlciBEZWFybG92ZSA8Y2hy aXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tPG1haWx0bzpjaHJpc3RvcGhlci5kZWFybG92ZUBn bWFpbC5jb20+PiB3cm90ZToNCkEgZmV3IGltbWVkaWF0ZSBjb21tZW50cyBpbmxpbmUgYmVsb3cu DQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KY2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwu Y29tPG1haWx0bzpjaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb20+IChpUGhvbmUpDQpjaHJp c0BtbmVtb3N5bmUuZGVtb24uY28udWs8bWFpbHRvOmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51 az4gKGhvbWUpDQoNCk9uIDE1IEFwciAyMDE2LCBhdCAxNToxOCwgTG90dGUgU3RlZW5icmluayA8 bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4uZGU8bWFpbHRvOmxvdHRlLnN0ZWVuYnJpbmtAZnUt YmVybGluLmRlPj4gd3JvdGU6DQpIaSBhbGwsDQoNCnNwYXJrZWQgYnkgdGhlIHJlY2VudGx5IHN0 YXJ0ZWQgV0dMQywgSeKAmXZlIHJldmlld2VkIHRoZSBjdXJyZW50IHJldmlzaW9uIG9mIHRoZSBk cmFmdC4gSeKAmWQgbGlrZSB0byBvZmZlciB0aGUgd29ya2luZyBncm91cCBteSBwZXJzcGVjdGl2 ZSBhcyBzb21lb25lIHdobyBkb2VzbuKAmXQgaGF2ZSBkZWNhZGVzIG9mIHByb3RvY29sIGFuZC9v ciBwYWNrZXQgZm9ybWF0IGRlc2lnbiB1bmRlciB0aGVpciBiZWx0IChpLmUuIHNvbWUgdGhpbmdz IG1pZ2h0IG5vdCBiZSBvYnZpb3VzIHRvIG1lIHRoYXQgYXJlIG9idmlvdXMgdG8gb3RoZXJzKSwg YnV0IGFsc28gYXMgc29tZW9uZSB3aG8gaGFzIHdvcmtlZCB3aXRoIFJGQyA1NDQ0IHdoZW4gaW1w bGVtZW50aW5nIGEgcm91dGluZyBwcm90b2NvbCAoQU9EVnYyKSwgdXBkYXRpbmcgdGhlIHBhY2tl dCBmb3JtYXQgb2YgYSByb3V0aW5nIHByb3RvY29sIChBT0RWdjIgYWdhaW4pIGFuZCAocGFydGlh bGx5KSBpbXBsZW1lbnRpbmcgbXkgb3duIFJGQzU0NDQgYnVpbGRlci9wYXJzZXIuDQoNCk92ZXJh bGwsIEkgdGhpbmsgdGhlIGRvY3VtZW50IGlzIGVhc3kgdG8gcmVhZCBhbmQgZm9sbG93LiBUbyBt ZSwgaXQgY29udGFpbnMgdmFsdWFibGUgaW5mb3JtYXRpb24gYW5kIGd1aWRhbmNlIGFuZCBpbiBz b21lIGNhc2VzIHByZXZlbnRzIHBlb3BsZSBmcm9tIHNob290aW5nIHRoZW1zZWx2ZXMgaW4gdGhl IGZvb3QuDQpJ4oCZbSByZWFsbHkgaGFwcHkgdGhpcyBkb2N1bWVudCBleGlzdHMgYW5kIEnigJlk IGxpa2UgaXQgdG8gbW92ZSBmb3J3YXJkIHNvb24sIGJ1dCBJIGRvIGZlZWwgdGhhdCBpdCBpcyBz dGlsbCBsYWNraW5nIGluIHNvbWUgYXJlYXMsIHdoaWNoIGlzIHdoeSBJIHdhcyBhIGJpdCBzdXJw cmlzZWQgdG8gc2VlIGl0IGdvIHRvIExhc3QgQ2FsbCBhbGwgb2YgYSBzdWRkZW4uDQoNCk5vdCBy ZWFsbHkuIFRoZSBhdXRob3JzIGhhZCBzYWlkIHdoYXQgdGhleSBpbnRlbmRlZCB0byBzYXksIG5v IG9uZSB3YXMgY29tbWVudGluZywgdGltZSBmb3IgV0dMQy4NCg0KRmlyc3QsIHNvbWUgbml0cGlj a3MgYW5kIGNvbW1lbnRzOg0KDQoqIGZyb20gMS4yLjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTEuMi4xPi4gUGFj a2V0L01lc3NhZ2UgRm9ybWF0Og0KDQoNCiAgICAgIFvigKZdIGEgcGFja2V0DQoNCiAgICAgIHRy YW5zbWlzc2lvbiBmb2xsb3dpbmcgYSBzdWNjZXNzZnVsIHBhY2tldCByZWNlcHRpb24gaXMgYnkg ZGVzaWduDQoNCiAgICAgIG9mIGEgbmV3IHBhY2tldCB0aGF0IG1heSBpbmNsdWRlIGFsbCwgc29t ZSwgb3Igbm9uZSBvZiB0aGUNCg0KICAgICAgcmVjZWl2ZWQgbWVzc2FnZXMgWy4uLl0NCg0KSeKA mW0gbm90IGEgbmF0aXZlIHNwZWFrZXIsIGJ1dCB0aGF0IOKAnm9m4oCcIHNlZW1zIG91dCBvZiBw bGFjZS4uLg0KDQpJIGFtIGEgbmF0aXZlIHNwZWFrZXIsIGFuZCBubywgaXQncyBub3QuIFNvbWUg d291bGQgcmVwZWF0IGl0IGFmdGVyIGVhY2ggb2YgYWxsLCBzb21lIGFuZCBub25lLCBhbmQgSSBt aWdodCBzb21ldGltZXMuIEJ1dCBpdCByZWFsbHkgZG9lc24ndCBtYXR0ZXIgd2hpY2ggb2YgdGhl IHR3byBzdHlsZXMgd2UgcGljaywgdGhlIFJGQyBFZGl0b3IgbWF5IHdlbGwgY2hhbmdlIHRvIHRo ZSBvdGhlci4NCg0KKiBSZWdhcmRpbmcgNC4yPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi00LjI+LiBQYWNrZXRzIGFu ZCBNZXNzYWdlczoNCnRoaXMgc2VjdGlvbiB0YWxrcyBhIGxvdCBhYm91dCBob3cgdGhlIG11bHRp cGxleGVyIG9wZXJhdGVzLCBzbyBJIHRoaW5rIGl04oCZZCBiZSBoZWxwZnVsIGlmIGl0cyB0aXRs ZSByZWZsZWN0ZWQgdGhhdC4NCg0KSSdtIG9mIHR3byBvcGluaW9ucyBvbiB0aGF0LiBPbiB0aGUg b25lIGhhbmQgaXQgaXMsIGFzIGl0cyB0aXRsZSBzdWdnZXN0cywgYWJvdXQgdGhlIHBhY2tldCBh bmQgbWVzc2FnZSBsZXZlbCwgYXMgb3Bwb3NlZCB0byBsb3dlciBsZXZlbHMsIGFuZCBpdHMgdGl0 bGUgY29udHJhc3RzIHdpdGggdGhhdCBpZiA0LjMgZm9yIHRoYXQgcmVhc29uLiBPbiB0aGUgb3Ro ZXIgaGFuZCB5b3UgYXJlIHJpZ2h0LCBpdCBkb2VzIGhhdmUgbXVjaCBhYm91dCB0aGUgbXVsdGlw bGV4ZXIuIEEgdGl0bGUgY292ZXJpbmcgYWxsIHRocmVlIHdvdWtkIHN0YXJ0IGdldHRpbmcgY3Vt YmVyc29tZS4gV2lsbCB0YWtlIHRoaXMgb25lIGF3YXkgdG8gdGhpbmsgYWJvdXQuDQoNCiogZnJv bSA0LjQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0 NC11c2FnZS0wMyNzZWN0aW9uLTQuND4uIEFkZHJlc3NlcyBSZXF1aXJlIEF0dHJpYnV0ZXM6DQoN Cg0KICAgQW4gdW5tb2RpZmllZCBleHRlbnNpb24gdG8gTkhEUCB3b3VsZCBpZ25vcmUgc3VjaCBh ZGRyZXNzZXMsDQoNCiAgIGFzIHJlcXVpcmVkLCBhcyBpdCBkb2VzIG5vdCBzdXBwb3J0IHRoYXQg c3BlY2lhbGl6ZWQgcHVycG9zZS4NCg0KQXQgZmlyc3QgZ2xhbmNlLCAodG8gbWUpIHRoaXMgcmVh ZHMgYXMg4oCeQWxsIGFkZHJlc3NlcyB0aGF0IGFyZSBhc3NvY2lhdGVkIHdpdGggYW4gdW5rbm93 biBUTFYgYXJlIGlnbm9yZWTigJwsIHdoaWNoIGlzIG9idmlvdXNseSBub25zZW5zZSAoYnV0IHF1 aXRlIHBhbmljLWluZHVjaW5nIDpEKS4gSeKAmWQgcHJvcG9zZSB0byByZXdvcmQgaXQgdG8gc29t ZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZg0KDQogICBBbiB1bm1vZGlmaWVkIGV4dGVuc2lvbiB0 byBOSERQIHdvdWxkIG5vdCBjb25zaWRlciB0aGlzDQoNCiAgIGFkZHJlc3MgdG8gYmUgb2YgYSBu ZWlnaGJvciwgYXMgaXQgaXMgbGFja2luZyBhIExJTktfU1RBVFVTDQoNCiAgIG9yIE9USEVSX05F SUdIQiBUTFYuDQoNCkkgdGFrZSB5b3VyIHBvaW50LCBidXQgSSB0aGluayB0aGF0IGlmIHRoZSBh ZGRyZXNzIGVuZHMgdXAgd2l0aCBubyByZWxldmFudCBhc3NvY2lhdGVkIFRMVnMgdGhlbiBpdCBp cyBpZ25vcmVkIGlzIGFsc28gYSBwb2ludC4gSSBkYXJlIHNheSB3ZSBjYW4gd29yZHNtaXRoIHNv bWV0aGluZy4NCg0KQWxzbywgSSBkb27igJl0IHF1aXRlIGdldCB3aGVyZSB5b3XigJlyZSBnb2lu ZyB3aXRoIHRoZSBsYXN0IHBhcmFncmFwaCBvZiB0aGF0IHNlY3Rpb24gKOKAnFRoZXNlIHJlc3Ry aWN0aW9ucyBkbyBub3QsIGhvd2V2ZXIsIG1lYW4gdGhhdCBhZGRlZCBpbmZvcm1hdGlvbiBpcw0K DQogICBjb21wbGV0ZWx5IGlnbm9yZWQgZm9yIHB1cnBvc2VzIG9mIHRoZSBiYXNlIHByb3RvY29s LuKAnSkuLi4NCg0KUmVhZCBvbiwgdGhlIHJlc3Qgb2YgdGhlIHBhcmFncmFwaCBkZXNjcmliZXMg dGhlIGNhc2Ugd2hlcmUgbm90LiBCdXQgd2UgbWlnaHQgdGVsZWdyYXBoIHRoYXQgYmV0dGVyIGlu IHRoZSBvcGVuaW5nIHNlbnRlbmNlLg0KDQoqIHJlZ2FyZGluZyB0aGUgbWFwcyBpbiA0LjU8aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0w MyNzZWN0aW9uLTQuNT4uIEluZm9ybWF0aW9uIFJlcHJlc2VudGF0aW9uOg0KSeKAmW0gYWZyYWlk IEkganVzdCBkb27igJl0IHJlYWxseSB1bmRlcnN0YW5kIHRoZSBwdXJwb3NlIG9mIHRoaXMgc2Vj dGlvbiBhbmQgdGhlIG1hcHBpbmcgbm90YXRpb24uIEnigJltIGFzc3VtaW5nIHRoYXQgdGhlIG1h cHMgYXJlIHN1cHBvc2VkIHRvIG9mZmVyIGEgd2F5IG9mIGRlc2NyaWJpbmcgaG93IGEgVExWIHJl bGF0ZXMgdG8gYSBtZXNzYWdlIG9yIGFuIGFkZHJlc3M/DQpJZiBzbywgd2h5IGRvZXMgaXQgb25s eSBtZW50aW9uIGV4dGVuc2lvbiB0eXBlcywgYnV0IG5vdCB0aGUgYmFzaXMgdHlwZXM/DQoNCkl0 IHNheXMgZXh0ZW5kZWQgdHlwZXMsIG1lYW5pbmcgdGhlIGNvbWJpbmF0aW9uIG9mIHRoZSB0d28u IEJ1dCBmdWxsIHR5cGUgd291bGQgYmUgYmV0dGVyLCBhcyBhbG1vc3QgZGVmaW5lZCBpbiA1NDQ0 LiBJbiBmYWN0IEkgdGhpbmsgd2Ugc2hvdWxkIGFkZCBhIGNvbW1lbnQgdG8gdGhlIG5vdGF0aW9u IHNlY3Rpb24uICg1NDQ0IHVzZXMgYSBzeW1ib2xpYyBuYW1lIHJhdGhlciB0aGFuIHRoZSBwaHJh c2UuKQ0KDQpPciBpcyBpdCBzdXBwb3NlZCB0byBiZSB1c2VkIHNvbWV0aGluZyBsaWtlIHRoaXM6 DQoNCkJBU0VfVExWDQoNCk1lc3NhZ2U6DQooYmFzZV90bHZfZXh0ZW5zaW9uX3R5cGVfMSkgLT4g KDIgb2N0ZXRzLCAidmFsdWUgYSB3aGVuIGNvbmRpdGlvbiB4IGlzIG1ldCIpDQooYmFzZV90bHZf ZXh0ZW5zaW9uX3R5cGVfMikgLT4gKDIgb2N0ZXRzLCAidmFsdWUgYiB3aGVuIGNvbmRpdGlvbiB5 IGlzIG1ldCIpDQoNCj8gQWxzbywgSSBkb27igJl0IHF1aXRlIGdldCBob3cgdGhpcyB3b3VsZCBi ZSB1c2VkIGluIGZ1dHVyZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucz8gT3IgYWlkIGluIGltcGxl bWVudGluZyBSRkM1NDQ0IHBhcnNlcnM/DQpBbiBleGFtcGxlIG9yIGEgY2xhcmlmaWNhdGlvbiB3 b3VsZCBiZSB2ZXJ5IGhlbHBmdWwuDQoNCkl0J3MgYSB3YXkgb2YgbG9va2luZyBhdCB0aGluZ3Mu IEJ1dCBub3QgdGhlIG9ubHkgb25lLCBpdCBnb2VzIG9uIHRvIGRpc2N1c3MgdmFyaWFudHMuIEkg dGhpbmsgaXQgbW9zdGx5IGNvbWVzIHVuZGVyIGhlYWRpbmcgb2YgaWYgdXNlZnVsIHVzZSBpdCwg aWYgbm90IHNraXAgaXQuIFdlJ2xsIHRha2UgYW5vdGhlciBsb29rLCBidXQgSSBkb24ndCB0aGlu ayB0aGlzIHdpbGwgZXZlciBiZSBlbGVtZW50YXJ5Lg0KDQoqIHJlZ2FyZGluZyA0LjY8aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNz ZWN0aW9uLTQuNj4uIFRMVnM6DQpJbiBnZW5lcmFsLCBpdOKAmXMgbm90IGNsZWFyIGV2ZXJ5d2hl cmUgaW4gdGhlIHNlY3Rpb24gd2hldGhlciB5b3XigJlyZSB0YWxraW5nIHRvIFJGQzU0NDQgcGFy c2VyL2J1aWxkZXIgaW1wbGVtZW50b3JzIG9yIHByb3RvY29sIGRlc2lnbmVycy4NCg0KDQogICBB IHByb3RvY29sIFNIT1VMRCB1c2UgYW4gZWZmaWNpZW50DQoNCiAgIHJlcHJlc2VudGF0aW9uLCBi dXQgdGhpcyBpcyBhIHF1YWxpdHkgb2YgaW1wbGVtZW50YXRpb24gaXNzdWUuDQoNCknigJltIG5v dCBzdXJlIHdoZXJlIHlvdeKAmXJlIGdvaW5nIHdpdGggdGhlIGxhc3QgcGFydCBvZiB0aGF0IHNl bnRlbmNlPyBJ4oCZZCByZXdvcmQgaXQgdG8gc29tZXRoaW5nIGxpa2Ug4oCeQSBwcm90b2NvbCBT SE9VTEQgdXNlIGFuIGVmZmljaWVudCByZXByZXNlbnRhdGlvbiwgYXZvaWRpbmcgdW5uZWNlc3Nh cmlseSB2ZXJib3NlIHVzZSBvZiBUTFZzIGFuZCBleHRlbnNpb24gdHlwZXMuIEhvd2V2ZXIsIHRo ZSBmaW5hbCBhcnJhbmdlbWVudCBpbiBhIG1lc3NhZ2UtIG9yIGFkZHJlc3NUTFYgYmxvY2sgaXMg IGEgcXVhbGl0eSBvZiBpbXBsZW1lbnRhdGlvbiBpc3N1ZeKAnCAoaW4gY2FzZSB0aGF04oCZcyB3 aGF0IHlvdSBtZWFudCkuDQoNCk5vLCB5b3UncmUgY29uc2lkZXJpbmcgdGhlIHByb3RvY29sIGRl c2lnbi4gVGhpcyBpcyBjb25zaWRlcmluZyB0aGUgcHJvdG9jb2wgb2JqZWN0IHRoYXQgaW1wbGVt ZW50cyB0aGUgcHJvdG9jb2wuIFRoZXJlIGlzbid0IGEgb25lIHRvIG9uZSBtYXBwaW5nIGZyb20g aW5mb3JtYXRpb24gdG8gcmVwcmVzZW50YXRpb24sIGl0J3MgdXAgdG8gdGhlIGltcGxlbWVudGF0 aW9uIHRvIGRvIGl0IGVmZmljaWVudGx5LiBEaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zIG9mIHRo ZSBzYW1lIHByb3RvY29sIHNwZWNpZmljYXRpb24gbWF5IGRvIGJldHRlciBvciB3b3JzZSBoZXJl LiAoVHJpdmlhbCBjYXNlLCBhbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBjaG9vc2UgdG8gbmV2ZXIg Y29tcHJlc3MgYWRkcmVzc2VzLiBCYWQgaWRlYSwgYnV0IGxlZ2FsLikNCg0KQW5kIHRoZW46DQoN Cg0KICAgQQ0KDQogICBwcm90b2NvbCBNVVNUIHJlY29nbml6ZSBhbnkgcGVybWl0dGVkIHJlcHJl c2VudGF0aW9uIG9mIHRoZQ0KDQogICBpbmZvcm1hdGlvbjsgZXZlbiBpZiBpdCBjaG9vc2VzIHRv IChmb3IgZXhhbXBsZSkgb25seSB1c2UgbXVsdGl2YWx1ZQ0KDQogICBUTFZzLCBpdCBNVVNUIHJl Y29nbml6ZSBzaW5nbGUgdmFsdWUgVExWcyAoYW5kIHZpY2UgdmVyc2EpLg0KDQrigKYgSSB0aG91 Z2h0IHByb3RvY29scyB3ZXJlbuKAmXQgc3VwcG9zZWQgdG8gc3BlY2lmeSB3aGV0aGVyIGEgVExW IGlzIGFycmFuZ2VkIChmb3IgZXhhbXBsZSkgYXMgYSBtdWx0aXZhbHVlIFRMVj8hDQoNCkltcGxl bWVudGF0aW9uIGFnYWluLCBub3QgZGVzaWduLg0KDQpBbmQgc28sIHNpbmNlIGEgcHJvdG9jb2wg c2hvdWxkbid0IGJlIGNvbmNlcm5lZCB3aXRoIG11bHRpdmFsdWUgVExWcyBhbmQgdGhlIGxpa2Us IHdvdWxkbuKAmXQgaXQgYmUgdGhlICpSRkM1NDQ0IGltcGxlbWVudGF0aW9uKiB0aGF0IE1VU1Qg cmVjb2duaXplIGFueSBwZXJtaXR0ZWQgcmVwcmVzZW50YXRpb24/DQoNCllvdSdyZSBhc3N1bWlu ZyB0aGF0IHRoZXJlIGlzIGFuIFJGQyA1NDQ0IGltcGxlbWVudGF0aW9uLiBUaGF0J3MgdGhlIHNh bWUgd2F5IHRvIHdvcmsgaWYgeW91IHBsYW4gdG8gaW1wbGVtZW50IG1vcmUgdGhhbiBvbmUgcHJv dG9jb2wuIEJ1dCBub3RoaW5nIHNheXMgeW91IGhhdmUgdG8gZG8gaXQgdGhhdCB3YXkuIFRoZSBh cmNoaXRlY3R1cmUgZGVmaW5lZCBieSA1NDk4IGFkbWl0cyBvZiB0aGUgbXVsdGlwbGV4ZXIgYW5k IHByb3RvY29scywgYW5kIHRodXMgdGhlc2UgYXJlIHJ1bGVzIG9uIHRoZSBwcm90b2NvbC4gSWYg cHJvdG9jb2xzIGRlbGVnYXRlIGFsbCB0aGVpciBjb21tb24gd29yayB0byBzb21ldGhpbmcgKHBh cnNlci9jcmVhdG9yKSB0aGVuIGl0IGluaGVyaXRzIHRob3NlIHJlc3RyaWN0aW9ucywgYnV0IHRo YXQncyBub3QgZGVmaW5lZCwgYW5kIHdlIGNhbid0IGFzc3VtZSBpdC4NCg0KT3IgaXMgdGhpcyBw YXJhZ3JhcGggcmVhbGx5IGp1c3QgYSBjb21wbGljYXRlZCB3YXkgb2Ygc2F5aW5nIOKAnmFzIGEg cHJvdG9jb2wgZGVzaWduZXIsIG1ha2Ugc3VyZSB0byBub3Qgc3BlY2lmeS9yZWx5IG9uIHRoaW5n cyBsaWtlIChmb3IgZXhhbXBsZSkgbXVsdGl2YWx1ZSBUTFZzLCBzaW5jZSB5b3VyIG1lc3NhZ2Vz IGhhdmUgdG8gd29yayB3aXRoICphbnkqIHJlcHJlc2VudGF0aW9u4oCcPyBJZiBzbywgSSB0aGlu ayB0aGF0IHNob3VsZCBiZSBkb25lIGluIGEgbGVzcyBjb21wbGljYXRlZCBmYXNoaW9uIChzZWUg YmVsb3cpLg0KDQoqIHJlZ2FyZGluZyA1PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi01Pi4gU3RydWN0dXJlOg0KU2lu Y2UgdGhpcyBzZWN0aW9uIHRhbGtzIGEgbG90IGFib3V0IGZsYWdzLCBpdOKAmWQgYmUgbmljZSBp ZiBpdHMgdGl0bGUgcmVwcmVzZW50ZWQgdGhhdC4gTWF5YmUgY29uc2lkZXIgcmVuYW1pbmcgaXQg dG8g4oCeU3RydWN0dXJlIGFuZCBGbGFnc+KAnCBvciBzbz8NCg0KSSBtb3N0bHkgZG9uJ3QgYWdy ZWUuIFN0cnVjdHVyZSBpcyB0aGUgc3ViamVjdCwgZmxhZ3MgYXJlIGEgZGV0YWlsLg0KDQoqIGZy b20gNi4xPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0 NDQtdXNhZ2UtMDMjc2VjdGlvbi02LjE+LiBBZGRyZXNzIEJsb2NrIENvbXByZXNzaW9uOg0KDQoN CiAgIENvbXByZXNzaW9uIG9mIGFkZHJlc3NlcyBpbiBhbiBBZGRyZXNzIEJsb2NrIGNvbnNpZGVy cyBhZGRyZXNzZXMgdG8NCg0KICAgY29uc2lzdCBvZiBhIEhlYWQsIGEgTWlkLCBhbmQgYSBUYWls LCB3aGVyZSBhbGwgYWRkcmVzc2VzIGluIGFuDQoNCiAgIEFkZHJlc3MgQmxvY2sgaGF2ZSB0aGUg c2FtZSBIZWFkIGFuZCBUYWlsLCBidXQgZGlmZmVyZW50IE1pZHMuDQoNCg0KSeKAmWQgZmluZCB0 aGlzIHNlbnRlbmNlIGVhc2llciB0byByZWFkIGlmIGl0IHN0YXJ0ZWQgd2l0aCDigJxDb21wcmVz c2lvbiBvZiBhZGRyZXNzZXMgaW4gYW4gQWRkcmVzcyBCbG9jayBpcyBwb3NzaWJsZSB3aGVuIGFk ZHJlc3NlcyBjb25zaXN0IG9mIGEgSGVhZCwgYSBNaWQgW+KApl3igJ0uDQoNCk5vLiBUaGF0J3Mg bWlzc2luZyB0aGUgcG9pbnQgYW5kIG1pc2xlYWRpbmcuIEFkZHJlc3NlcyBhcmUgYWx3YXlzIGNv bnNpZGVyZWQgdG8gaGF2ZSB0aGUgaGVhZC9taWQvdGFpbCBmb3JtYXQuIENvbXByZXNzaW9uIGlz IHBvc3NpYmxlIGlmIGVpdGhlciB0aGUgaGVhZCBvciB0YWlsIChvciBib3RoKSBpcyBub24tZW1w dHkuDQoNCiogZnJvbSA2LjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt bWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTYuMT4uIEFkZHJlc3MgQmxvY2sgQ29tcHJl c3Npb246DQoNCg0KDQogICBQdXR0aW5nIGFkZHJlc3NlcyBpbnRvIGEgbWVzc2FnZSBlZmZpY2ll bnRseSBhbHNvIGhhcyB0byBpbmNsdWRlOg0KDQoNCldoeSDigJ5oYXMgdG/igJw/IEnigJlkIHRo aW5rIHRoYXQgd291bGQgYmUgYSDigJ5tYXnigJwuIE11bHRpcGxlIEFkcmVzcyBCbG9ja3MgYW5k L29yIHJlb3JkZXJpbmcgZG9u4oCZdCBpbmNyZWFzZSBlZmZpY2llbmN5IGluIGFsbCBwb3NzaWJs ZSBjYXNlcy4uLg0KDQpJIHRoaW5rIHRoYXQncyB0aGUgd3JvbmcgY2hhbmdlLiBSYXRoZXIgImlu Y2x1ZGUiIHNob3VsZCBiZSAiY29uc2lkZXIiLg0KDQoqIGZyb20gNi4yPGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi02 LjI+LiBUTFZzOg0KDQogICAgICBbLi4uXSBUaGlzIGlzIGV2ZW4gcG9zc2libGUgaWYgdGhlIE1Q UiBUTFYgc3BlY2lmaWVkIGluDQoNCiAgICAgIE9MU1J2MiBbUkZDNzE4MTxodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNzE4MT5dIGlzIGFkZGVkOyBidXQgaXQgaXMgbm90IHBvc3NpYmxl LCBpbiBnZW5lcmFsLCBpZg0KDQogICAgICB0aGUgTElOS19NRVRSSUMgVExWIGlzIGFsc28gYWRk ZWQuDQoNCldoeSBpcyBpdCBub3QgcG9zc2libGUgZm9yIHRoZSBsYXR0ZXI/IElmIHRoYXQgY291 bGQgYmUgZXhwbGFpbmVkL2hpbnRlZCBhdCBpbiBhIGhhbGYgc2VudGVuY2UsIEkgdGhpbmsgaXTi gJlkIGJlIGhlbHBmdWwgaW5mb3JtYXRpb24gdG8gaGF2ZSBpbiB0aGUgZHJhZnQuDQoNClRoYXQn cyB2ZXJ5IGhhcmQsIGFuZCBub3QganVzdCBiZWNhdXNlIGl0J3MgYSBuZWdhdGl2ZS4gSXQncyBy ZWFsbHkgYW4gb2JzZXJ2YXRpb24gdGhhdCBtb3RpdmF0ZXMgdGhlIGR1c2N1c3Npb24uIEEgaGFs ZiBzZW50ZW5jZSB3b3VsZCBJIHRoaW5rIGNvbmZ1c2UgbW9yZSB0aGFuIGl0IGVubGlnaHRlbnMg KGl0J3MgYmVjYXVzZSB5b3UgaGF2ZSB0b28gbWFueSBjb25zdHJhaW50cyB0byBzYXRpc2Z5IGF0 IG9uY2UgLSBJIGRvdWJ0IHRoYXQgaGVscGVkKS4NCg0KDQogICAgICBJbiBhIHR5cGljYWwgY2Fz ZSB3aGVyZSBhDQoNCiAgICAgIExJTktfU1RBVFVTIFRMViB1c2VzIG9ubHkgdGhlIFZhbHVlcyBI RUFSRCBhbmQgU1lNTUVUUklDLCB3aXRoDQoNCiAgICAgIGVub3VnaCBhZGRyZXNzZXMsIHNvcnRl ZCBhcHByb3ByaWF0ZWx5LCB0d28gc2luZ2xlIHZhbHVlIFRMVnMgY2FuDQoNCiAgICAgIGJlIG1v cmUgZWZmaWNpZW50IHRoYW4gb25lIG11bHRpdmFsdWUgVExWLg0KDQpTYW1lIHRoaW5nOiB3aHk/ DQoNCkhlcmUgSSB0aGluayB0aGlzIHNob3VsZCBiZSBvYnZpb3VzIHRvIGFueW9uZSB3aG8gaGFz IGxvb2tlZCBhdCA1NDQ0Lg0KDQoqIHJlZ2FyZGluZyB0aGUgc2Vjb25kIHBhcmFncmFwaCBmcm9t IDYuMzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0 LXVzYWdlLTAzI3NlY3Rpb24tNi4zPi4gVExWIFZhbHVlcywgaS5lLg0KDQoNCg0KICAgVGhpcyBh cHByb2FjaCB3YXMgc3BlY2lmaWVkIGluIFtSRkM3MTg4PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM3MTg4Pl0sIGFuZCByZXF1aXJlZCBmb3IgcHJvdG9jb2xzDQoNCiAgIHRoYXQgZXh0 ZW5kIFtSRkM2MTMwPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MTMwPl0gYW5kIFtS RkM3MTgxPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTgxPl0uICBJdCBpcyBoZXJl IFJFQ09NTUVOREVEIHRoYXQNCg0KICAgdGhpcyBhcHByb2FjaCBpcyBmb2xsb3dlZCB3aGVuIGRl ZmluaW5nIGFueSBBZGRyZXNzIEJsb2NrIFRMViB0aGF0DQoNCiAgIG1heSBiZSB1c2VkIGJ5IGEg cHJvdG9jb2wgdXNpbmcgW1JGQzU0NDQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU0 NDQ+XS4NCg0KVGhlIHRlcm0g4oCedGhpcyBhcHByb2FjaOKAnCBjb25mdXNlZCBtZSwgc2luY2Ug SSBpbml0aWFsbHkgIHRob3VnaHQgaXQgbWVhbnQg4oCedGhlIGFwcHJvYWNoIGlzIHRvIHVzZSBV TlNQRUNJRklFRCBpbiBhIHdheSB0aGF0IG1ha2VzIHNlbnNl4oCcIHJhdGhlciB0aGFuIOKAnnRo ZSBhcHByb2FjaCBpcyB0byB1c2UgVU5TUEVDSUZJRUTigJwuIE1heWJlIHRoYXQgY291bGQgYmUg cmV3b3JkZWQgdG8gc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZg0KVGhlIFVOU1BFQ0lGSUVE IFRMViBhbmQgaXRzIHVzYWdlIHdhcyBzcGVjaWZpZWQgaW4gW1JGQzcxODhd4oCmDQo/DQoNCk5v LiBUaGVyZSBpcyBubyBVTlNQRUNJRklFRCBUTFYuIFRoZXJlIGlzIGEgcmVjb21tZW5kYXRpb24g dG8gaW5jbHVkZSBhbiBVTlNQRUNJRklFRCB2YWx1ZSBpbiBhIFRMVi4gQnV0IHJlYWxseSwgd2Un dmUgZGVzY3JpYmVkIHRoaXMgb25jZSBpbiA3MTg4LCBpdCdzIHRoZXJlIHRvIHJlYWQuDQoNCiog cmVnYXJkaW5nIDYuMzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5l dC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi4zPi4gVExWIFZhbHVlczoNClRoZSBzZWNvbmQg cGFyYWdyYXBoIGlzIGEgYml0IGNvbmZ1c2luZyBhbmQgc2VlbXMgdG8gZXhwbGFpbmcgcm9naGx5 IHRoZSBzYW1lIHRoaW5ncyBhcyB0aGUgZm91cnRoIHBhcmFncmFwaHMuIEnigJlkIHByb3Bvc2Ug dG8gbWVyZ2UgdGhlIHNlY29uZCBpbnRvIHRoZSBmb3VydGguDQoNCkknbSBub3Qgc3VyZSBJIGV4 YWN0bHkgYWdyZWUsIGJ1dCB0aGUgb3JkZXJpbmcgaW4gdGhhdCBzZWN0aW9uIGNvdWxkIGJlIGlt cHJvdmVkLg0KDQoqIGZyb20gNi40PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi02LjQ+LiBBdXRvbWF0aW9uOg0KDQoN CiAgIFRoZSBwb3NzaWJsZSBnYWluIGRlcGVuZHMgb24gdGhlIGVmZmljaWVuY3kNCg0KICAgb2Yg dGhlIG9yaWdpbmFsIG1lc3NhZ2UgY3JlYXRpb24sDQoNCnRoZSB0ZXJtIOKAnnRoZSBvcmlnaW5h bCBtZXNzYWdlIGNyZWF0aW9u4oCcIHNlZW1zIGEgYml0IGFtYmlndW91c+KAkyBkb2VzIHRoaXMg cmVmZXIgdG8gdGhlIG1lc3NhZ2UgYXMgY3JlYXRlZCBieSBhbiBSRkM1NDQ0IG1lc3NhZ2UgYnVp bGRlciBpbXBsZW1lbnRhdGlvbj8NCg0KWWVzLg0KDQpBZGRpdGlvbmFsbHksIEknbSBjb25jZXJu ZWQgYWJvdXQgdHdvIHRoaW5ncyB0aGF0ICphcmVu4oCZdCogaW4gdGhlIGRyYWZ0Og0KDQoqICBT b21lIG9mIHRoZSBBT0RWdjIgY28tYXV0aG9ycyBhbmQgbWUgaGF2ZSBhc2tlZCBmb3IgYSBsaXN0 IG9mIOKAnmFzIGEgcHJvdG9jb2wsIHlvdSBjYW4gc2V0IGFsbCBvZiB0aGVzZSBmaWVsZHMgb2Yg YSBtZXNzYWdlLCBidXQgcGxlYXNlIGxlYXZlIHRoZSByZXN0IGFsb25l4oCcLCB3aGljaCB3b3Vs ZOKAmXZlIHNhdmVkIHVzIG1hbnkgaG91cnMgb2YgZGlzY3Vzc2lvbnMgKGFuZCBIZW5uaW5nIGEg bG90IG9mIHRpbWUgc3BlbnQgZXhwbGFpbmluZyB0aGVzZSB0aGluZ3PigKYpLiBUaGVzZSByZXF1 ZXN0cyBoYXZlIGJlZW4gbWV0IHdpdGggYSByZWZ1c2FsIHRvIHNwZWNpZnkgYSBjb25jcmV0ZSBB UEksIGFzIHN1Y2ggYW4gZWZmb3J0IGlzIGRlcGVuZGVudCBvbiBvdXRzaWRlIGZhY3RvcnMgc3Vj aCBhcyBwcm9ncmFtbWluZyBsYW5ndWFnZSBvciBzb2Z0d2FyZSBhcmNoaXRlY3R1cmUuIEkgYWdy ZWUgd2l0aCB0aGlzIG5vdGlvbiwgYnV0IGEgcHJvZ3JhbW1pbmctbGFuZ3VhZ2UgZGVwZW5kZW50 IEFQSSBpcyBub3Qgd2hhdCB3ZeKAmXZlIGFza2VkIGZvci4gSeKAmXZlIHRyaWVkIHRvIHN1cHBs eSBhIHNrZXRjaCBvZiB3aGF0IEkgZGlkIGFzayBmb3IgaW4gWzFdLCBidXQgdW5mb3J0dW5hdGVs eSBJIGRpZG7igJl0IGdldCBhbiBhbnN3ZXIgKGFuZCBhcyBmYXIgYXMgSSBjYW4gc2VlIGl0LCB0 aGUgZHJhZnQgd2FzbuKAmXQgY2hhbmdlZCBlaXRoZXIpLiBJIHN0aWxsIHRoaW5rIHRoYXQgc3Vj aCBhIGxpc3QsIGluIHdoYXRldmVyIGZvcm0sIHdvdWxkIGJlIHZlcnkgaGVscGZ1bCBmb3IgZnV0 dXJlIEludGVybmV0LURyYWZ0IGF1dGhvcnMgYW5kIEkgYWxzbyB0aGluayB0aGlzIHJlcXVlc3Qg aXMgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBpbnRlbnRpb25zIHN0YXRlZCBpbiAxLjEgSGlzdG9y eSBhbmQgUHVycG9zZSwgYW5kIEkgdGhpbmsgaXQgc2hvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSBk b2N1bWVudC4NCg0KTm8uIFRoZXJlIGFyZSBtYW55IHJlYXNvbnMgd2h5IHdlJ3JlIGp1c3Qgbm90 IHRvdWNoaW5nIHRoaXMgb25lLg0KDQpPbmUgaXMgdGhhdCBsYW5ndWFnZSBpbmRlcGVuZGVuY2Ug aXMgYSBtaXJhZ2UuIEhvdyB5b3UgZ28gYWJvdXQgdGhpbmdzIGlzIGNvbXBsZXRlbHkgZGlmZmVy ZW50IGluLCBmb3IgZXhhbXBsZSBhbiBvYmplY3Qgb3JpZW50ZWQgbGFuZ3VhZ2UgdGhhbiBvbmUg dGhhdCBpc24ndC4gU2VjdGlvbiA0LjUgc2hvd3MgdGhhdCB0aGVyZSBhcmUgcXVpdGUgZGlmZmVy ZW50IHdheXMgb2YgZG9pbmcgdGhpbmdzIGV2ZW4gZ2l2ZW4gYSBkZWNpc2lvbiB0byB1c2UgYSBt YXAgYXBwcm9hY2gsIGFuZCB0aGVyZSBhcmUgb3RoZXIgYXBwcm9hY2hlcyB0aGFuIHRoYXQuIEl0 IHdvdWxkIGJlIHdyb25nIGFuZCBiZXlvbmQgb3VyIGNvbXBldGVuY2UgdG8gc3VnZ2VzdCBvbmUg b2YgdGhlc2UgYXMgImJlc3QiLiBUaGVyZSdzIHJlYXNvbnMgdGhlIElFVEYgZG9lc24ndCBkbyB0 aGlzLCBhbmQgdGhhdCdzIG9uZS4NCg0KUGx1cywgZnJhbmtseSwgdGhlIHdvcmsgaXQgd291bGQg dGFrZSBpcyBiZXlvbmQgd2hhdCB3ZSBjaG9vc2UgdG8gc3BlbmQuDQoNCg0KPFNwZWFraW5nIGFz IGEgV0cgUGFydGljaXBhbnQ+DQoNCkknbSBjb25mdXNlZCAod2hpY2ggaXMgYW4gYWx0b2dldGhl ciB0b28gY29tbW9uIG9jY3VycmVuY2UgdGhlc2UgZGF5cykuIEkgZ2V0IHRoYXQgd2UgZG9uJ3Qg d2FudCB0byBzcGVjaWZ5IGFuIEFQSS4gQnV0IEkgdGhpbmsgdGhlIGRpc2N1c3Npb24gYWJvdXQg ZmllbGRzIGEgcHJvdG9jb2wgY2FuIGFuZCBjYW4ndCB0b3VjaCBpbiBhIG1lc3NhZ2VzIGlzIGEg Z29vZCB0aGluZyAtIGFuZCBpdCdzIG9uZSBzcG90IHdoZXJlIEksIHRvbywgZmluZCB0aGUgZG9j dW1lbnQgd2FudGluZy4NCg0KVG8gcGFyYXBocmFzZSBzb21ldGhpbmcgSSd2ZSBzYWlkIGJlZm9y ZSwgSSBiZWxpZXZlIHRoYXQgUkZDIDU0NDQgY2hhbmdlcyB0aGUgcmVsYXRpb25zaGlwIHRoYXQg YSByb3V0aW5nIHByb3RvY29sIGhhcyB3aXRoIGFuICJpbnRlcmZhY2UiLiBJJ20gbm90IGNvbW1l bnRpbmcgb24gd2hldGhlciBvciBub3QgdGhhdCdzIGEgZ29vZCB0aGluZywgb3IgYSBiYWQgdGhp bmcgLSBqdXN0IHRoYXQgaXQgZG9lcyBjaGFuZ2UgdGhlIHJlbGF0aW9uc2hpcC4gVGhpcyBjaGFu Z2UgaGFzIGJlZW4gYXQgdGhlIHJvb3Qgb2Ygc29tZSBvZiB0aGUgbG9uZy1ydW5uaW5nIGRpc2N1 c3Npb25zIGFzIHRvIHdoZXRoZXIgcHJvdG9jb2xzIHVuZGVyIGRldmVsb3BtZW50IHdlcmUgUkZD IDU0NDQgY29tcGxpYW50IG9yIG5vdC4gVGhlIGdvYWwgb2YgdGhpcyBkb2N1bWVudCBiZWluZyB0 byBlbGltaW5hdGUgKGl0J3MgYSBnb2FsLCBwcm9iYWJseSBub3QgcmVhY2hhYmxlKSB0aG9zZSBk aXNjdXNzaW9ucywgSSdkIGxpa2UgdG8gc2VlIHRoYXQgaW5mb3JtYXRpb24gaW4gdGhlIGRvY3Vt ZW50IGluIHNvbWUgZm9ybS4NCg0KSSdtIGludGVyZXN0ZWQgaW4gc2VlaW5nIHRoaXMgZG9jdW1l bnQgcHJvZ3Jlc3MsIGFuZCBldmVudHVhbGx5IGJlIHB1Ymxpc2hlZC4gSSB0aGluayBpdCB3aWxs IGhlbHAgZnV0dXJlIHByb3RvY29sIGRlc2lnbmVycyB0byBiZXR0ZXIgdXNlIFJGQyA1NDQ0LiBC dXQgSSB3b3VsZCBsaWtlIHRvIHNlZSAqc29tZXRoaW5nKiBhbG9uZyB0aGUgbGluZXMgb2Ygd2hh dCBMb3R0ZSBpcyByZXF1ZXN0aW5nLCBhcyBJIHRoaW5rIGl0IHdpbGwgaW1wcm92ZSB0aGUgZG9j Lg0KDQpSZWdhcmRzLA0KU3Rhbg0KDQoNCg0KKiBBcyB0aGUgZXhhY3QgcnVsZXMgZm9yIHVzaW5n L3NldHRpbmcgdGhlIGhvcCBjb3VudCAmIGhvcC1saW1pdCBmaWVsZHMgYXJlIGN1cnJlbnRseSBi ZWluZyBkaXNjdXNzZWQgdy8gcmVnYXJkIHRvIEFPRFZ2MiBpbiBhbm90aGVyIHRocmVhZCBbMl3i gJMgc2hvdWxkIGEgZGVmaW5pdGl2ZSBhbnN3ZXIgdG8gdGhhdCBxdWVzdGlvbiBiZSBwYXJ0IG9m IDU0NDQtdXNhZ2U/DQoNCllvdSBkb24ndCB3YW50IHRoYXQuIEJlY2F1c2UgaWYgd2UgZGlkIHNw ZWNpZnkgdGhhdCB5b3UnZCBmaW5kIHlvdXJzZWxmIG1vcmUgY29uc3RyYWluZWQgdGhhbiB5b3Ug d2FudCB0byBiZS4gVGhlcmUgaXMgYSBkZXNpZ24gaW50ZW50IGRlc2NyaWJlZCBpbiA1NDQ0LCBi dXQgaXQgYXNzdW1lcyBpbW11dGFibGUgbWVzc2FnZXMuIFdoaWNoIHlvdSBkb24ndCB3YW50LiBS ZWFsbHksIHdlJ3JlIGRvaW5nIHlvdSBhIGZhdm91ciBieSBub3QgaW1wb3Npbmcgb24geW91Lg0K DQpCZXN0IHJlZ2FyZHMsDQpMb3R0ZQ0KDQpbMV0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21zZzE4MDgyLmh0bWwNClsyXSBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTg2NzQuaHRtbA0KDQoN CkFtIDA2LjA0LjIwMTYgdW0gMTk6MTQgc2NocmllYiBKdXN0aW4gRGVhbiA8YmViZW1hc3RlckBn bWFpbC5jb208bWFpbHRvOmJlYmVtYXN0ZXJAZ21haWwuY29tPj46DQoNClRoZSBjaGFpcnMgYWdy ZWUgdGhhdCBhIDMgd2VlayBXR0xDIGlzIGFwcHJvcHJpYXRlLiAgRXZlcnlvbmUgcGxlYXNlIHJl YWQgdGhlIGRyYWZ0IGVhcmx5IGFuZCBnZXQgY29tbWVudHMgaW4gZWFybHkgc28gdGhhdCB0aGV5 IGNhbiBiZSBhZGRyZXNzZWQgd2l0aGluIHRoZSBsYXN0IGNhbGwgcGVyaW9kLg0KDQpKdXN0aW4N Cg0KT24gV2VkLCBBcHIgNiwgMjAxNiBhdCA3OjQwIEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIg KFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3Zl QGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQpPYnZpb3VzbHkgKzEgdG8gdGhlIHJlcXVlc3QgZm9y IFdHTEMuDQoNCldpdGggcmVnYXJkIHRvIHdoYXQncyBjaGFuZ2VkLCB0ZWNobmljYWxseSB0aGUg b25seSBzaWduaWZpY2FudCB0aGluZyBpcyB0byBtYWtlIGl0IGNsZWFyIHRoYXQgaWYgYSBwcm90 b2NvbCBkZWxpdmVycyBhIG1lc3NhZ2UgdG8gdGhlIG11bHRpcGxleGVyLCB0aGUgbXVsdGlwbGV4 ZXIgbXVzdCBwYXNzIGl0IG9uIHVuY2hhbmdlZCB0byB0aGUgcHJvdG9jb2wgKGFub3RoZXIgaW5z dGFuY2Ugb2YsIGF0IGFub3RoZXIgcm91dGVyKSB1bmNoYW5nZWQuIFdpdGhvdXQgdGhhdCBub3Ro aW5nIHRoYXQgdGhlIHByb3RvY29sIGl0c2VsZiBjaG9vc2VzIHRvIGRvIHdpdGggcmVnYXJkIHRv IHNlY3VyaXR5IG1ha2VzIHNlbnNlLiBUaG91Z2ggdGhlIHByb3RvY29sIGNhbiBhbHRlcm5hdGl2 ZWx5IGxldCB0aGUgbXVsdGlwbGV4ZXIgZG8gdGhlIHNlY3VyaXR5LCA3MTgyIGNhbiBiZSBpbXBs ZW1lbnRlZCBpbiBlaXRoZXIgd2F5LiBUaGlzIGlzbid0IHJlYWxseSBuZXcsIGJ1dCBpdCB3YXNu J3QgZm9ybWFsbHkgc3BlbGxlZCBvdXQuIEl0J3MgcHJlc2VudGVkIGFzIHBhcnQgb2Ygc3BlbGxp bmcgb3V0IG11bHRpcGxleGVyIHJ1bGVzIG1vcmUgY2FyZWZ1bGx5Lg0KDQpCdXQgd2hhdCBhYm91 dCBtZXNzYWdlIG9wdGltaXNhdGlvbj8gVGhhdCdzIGEgZnVuY3Rpb24gb2YgY29uc3RydWN0aW5n IGEgNTQ0NCBtZXNzYWdlLCBub3QgdGhlIG11bHRpcGxleGVyLCBhbmQgaXMgZG93biB0byB0aGF0 IDU0NDQgaW5jbHVkZXMgdHdvIHRoaW5ncyAtIHBhY2tldC9tZXNzYWdlIHN0cnVjdHVyZSAoYW5k IGltcGxpY2l0bHksIGFuZCBpbiBwcmV0dHkgbXVjaCBhbnkgaW1wbGVtZW50YXRpb24gSSB3b3Vs ZCBleHBlY3QgdG8gc2VlLCBhIHBhcnNlciBhbmQgYnVpbGRlciBmb3IgdGhhdCBzdHJ1Y3R1cmUp IGFuZCB0aGUgbXVsdGlwbGV4ZXIuIFNvIHdlIHRvb2sgdGhlIG9wcG9ydHVuaXR5IHRvIHNlcGFy YXRlIG91dCBtb3JlIGNsZWFybHkgYSBkaXNjdXNzaW9uIG9mIHRoZSB0d28sIHdoaWNoIHdlIHRo aW5rIHdpbGwgYmUgaGVscGZ1bC4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3Ig UHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJv cmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVs OiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBT eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywg R3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMu Y29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVk IEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzog MDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRm b3JkLCBTdXJyZXksIEdVMiA3WVANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bWFuZXQtYm91bmNl c0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBVbHJpY2ggSGVyYmVyZw0KU2VudDogMDUgQXByaWwg MjAxNiAyMDowOA0KVG86IG1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NClN1 YmplY3Q6IFttYW5ldF0gV0dMQyByZXF1ZXN0IGZvciBkcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQt dXNhZ2UtMDMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdh bmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50 ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFu eSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb2xsb3cgdGhlICdSZXBv cnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25z IG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KKioqIFdBUk5JTkcg KioqDQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNp ZGUgb3VyIG9yZ2FuaXphdGlvbi4NCg0KDQpIaSwNCg0KQXMgeW91IGhhdmUgc2Vlbiwgd2UgaGF2 ZSBzdWJtaXR0ZWQgYSBuZXcgcmV2aXNpb24gb2YgNTQ0NC11c2FnZS4gVGhlIGF1dGhvcnMgZmVl bCBjb21mb3J0YWJsZSB0aGF0IHdlIGhhdmUgYWRkcmVzc2VkIGFsbCBpc3N1ZXMgYnkgdGhpcyB2 ZXJzaW9uLCBhbmQgd291bGQgbGlrZSB0byBhc2sgdGhlIFdHIGNoYWlycyB0byBpc3N1ZSBhIFdH TEMgb24gdGhpcyBkb2N1bWVudC4gV2hpbGUgaXQgaXMgYSBmYWlybHkgc2hvcnQgZG9jdW1lbnQs IGdpdmVuIHRoYXQgaXQgaXMgSUVURiB3ZWVrIGZvciBzb21lLCB3ZSdkIHN1Z2dlc3QgdGhhdCBh IDMtNCB3ZWVrIFdHTEMgd291bGQgYmUgYXBwcm9wcmlhdGUuDQoNCkJlc3QgcmVnYXJkcw0KVWxy aWNoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpt YW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq DQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUg aW50ZW5kZWQNCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIg c3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4NCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3Ig dXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3INCmRpc3RyaWJ1dGUgaXRzIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQpt YW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1h aWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbWFuZXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGlu ZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCg0KDQoNCg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AEC54GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsInNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1HQjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPknigJltIGFmcmFpZCBJ4oCZbSBub3QgZ2V0dGluZyB0aGUgYXNrIGhl cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5XZSBoYXZlIGEgd2hvbGUgc2VjdGlvbiAxIG9uIGRlc2NyaWJpbmcgdGhl IHVzYWdlIG9mIDU0NDQuICZuYnNwO0luIHNvbWUgZGV0YWlsLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hhdCwgc3Bl Y2lmaWNhbGx5LCBpcyBtaXNzaW5nIC0ganVzdCDigJxleHBsYWluIGJldHRlcuKAnSBpcyBub3Qg aGVscGZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPihJ4oCZdmUgc3BlbnQgbXVjaCBvZiBteSB0aW1lIGV4cGxhaW5p bmcgdGhhdCB0aGVyZSBpcyBubyBtYW5kYXRlZCBwYXJzZXIuIEEgZmV3IHdvcmRzIG9uIHRoYXQg YXJlIHNvbWV0aGluZyB0aGF0IHdlIGNhbiBhZGQuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5p b3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu Y2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQy MTk0ICZuYnNwO3wgJm5ic3A7PGI+RToNCjwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxv dmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4N Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBB cHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJh ZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3 LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5 c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5n bGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJl c2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFN0YW4g UmF0bGlmZiBbbWFpbHRvOnJhdGxpZmZzdGFuQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9i PiAxOSBBcHJpbCAyMDE2IDAwOjA2PGJyPg0KPGI+VG86PC9iPiBEZWFybG92ZSwgQ2hyaXN0b3Bo ZXIgKFVLKTxicj4NCjxiPkNjOjwvYj4gQ2hyaXN0b3BoZXIgRGVhcmxvdmU7IG1hbmV0QGlldGYu b3JnOyBDaHJpc3RvcGhlciBEZWFybG92ZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0 XSBXR0xDIHJlcXVlc3QgZm9yIGRyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQg Mi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIg c3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91 bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+Kioq IFdBUk5JTkcgKioqPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZy b20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0 bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5 IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1l bnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0 aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9u Zz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3Ug Y2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0i aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3Bv dGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2Vt PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxv dw0KPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsv c2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3Vz JTIwRW1haWxzLnBkZiI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXByIDE4LCAy MDE2IGF0IDExOjIzIEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hy aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T2YgY291cnNlIGl0IG1ha2VzIHNlbnNlIC0gYmVjYXVz ZSBpdOKAmXMgYmVlbiBkb25lIGFzIEkgbm90ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+KCpTdGlsbCogc3BlYWtpbmcgYXMgYSBXRyBwYXJ0aWNpcGFudCk6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PSywgSSBn ZXQgdGhhdC4gSXQncyBvbmx5IG1pbmltYWxseSBpbnRlcmVzdGluZyAoSU1PKSwgYnV0IEkgZ2V0 IGl0Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG11 bHRpcGxleGVyIGRvZXNu4oCZdCBhY3R1YWxseSBoYXZlIHRvIHBhcnNlIG1lc3NhZ2VzLCBpdCBu ZWVkcyB0byBncm91cCB0aGVtIGludG8gcGFja2V0cy4gSXQNCiBuZWVkcyB0byBiZSBhYmxlIHRv IHBhcnNlIGEgcGFja2V0IGRvd24gdG8g4oCcaGVyZSBhcmUgdGhlIG1lc3NhZ2Vz4oCdIGFuZCBk ZWxpdmVyIHRoZW0uIFRoZSBtZXNzYWdlcyBjYW4gYmUgc2ltcGxlIGJsb2JzLiBGb3IgdGhhdCBp dCBuZWVkcyB0aGUgbWVzc2FnZSB0eXBlIC0gY29udmVuaWVudGx5IHBsYWNlZCB1cCBmcm9udCBp biB0aGUgbWVzc2FnZSBoZWFkZXIgdG8gYmUgcmVhZCAtIGFuZCB0aGUgbWVzc2FnZSBsZW5ndGgg LSBkaXR0by4gVGhlDQogcGFyc2luZyBvZiB0aGUgbWVzc2FnZXMgaXMgYSBwcm90b2NvbCBwcm9i bGVtLiBJZiBqdXN0IGltcGxlbWVudGluZyBvbmUgcHJvdG9jb2wgaXQgY291bGQgaW5jb3Jwb3Jh dGUgdGhlIHBhcnNlci4gSWYgaW1wbGVtZW50aW5nIG11bHRpcGxlIHByb3RvY29scyB5b3UgY2Fu IGNyZWF0ZSBhbiBpbmRlcGVuZGVudCBwYXJzZXIuIE9yIHlvdSBtYXkgZG8gdGhlIGxhdHRlciBl dmVuIGluIHRoZSBmb3JtZXIgY2FzZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmQgZXZlbiBpZiB3ZSBhbGwg aW1wbGVtZW50ZWQgaW5kZXBlbmRlbnQgcGFyc2VycyB0aGV5IGNhbiBiZSBxdWl0ZSBkaWZmZXJl bnQuIEFzIGluZGVlZCB0aGUgb25lcw0KIHRoYXQgZXhpc3QgYXJlLiBOb3QganVzdCBtZXJlbHkg aW4gQVBJLiBGb3IgZXhhbXBsZSBJIGNvdWxkIHR1cm4gYSBtZXNzYWdlIGludG8gYSBzZXQgb2Yg b2JqZWN0cy4gT3IgSSBjb3VsZCBwcm92aWRlIHBvaW50ZXJzIGludG8gdGhlIGRhdGEgYmxvY2sg dGhhdCByZXByZXNlbnRzIHRoZSBtZXNzYWdlLiZuYnNwOyBBbmQgb3RoZXIgYXBwcm9hY2hlcy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkFuZCBJIHRoaW5rIHdlJ3ZlIGRyaWZ0ZWQgZnJv bSBteSBpbml0aWFsIGFzayAtIHRoYXQgdGhlIHVzYWdlIGRvY3VtZW50IGJldHRlciBkZXNjcmli ZSB0aGUgdXNhZ2Ugb2YgNTQ0NC4gVGhlcmUncyBiZWVuIGEgbG90IGNvbWluZyBvdXQgb2YgdGhl IHZhcmlvdXMgdGhyZWFkcyBvbiB0aGlzIHRvcGljIC0gaG93IDU0NDQgY2hhbmdlcyB0aGUgcmVs YXRpb25zaGlwDQogYmV0d2VlbiBwcm90b2NvbCBhbmQgaW50ZXJmYWNlLCB3aGV0aGVyIGEgcGFy c2VyIGlzIGltcGxlbWVudGVkIG9yIG5vdCwgZXRjLiBUaGUgd2hvbGUgZGlzY3Vzc2lvbiAoYWxs IG9mIHRoZXNlIGRpZmZlcmVudCB0aHJlYWRzIHB1dCB0b2dldGhlcikgKmJlZ3MqIGZvciBzb21l IGFkZGl0aW9uYWwgY2xhcml0eSBpbiB0aGUgZG9jdW1lbnQuIEkndmUgYmVlbiAocG9saXRlbHkp IHR1cm5lZCBhd2F5IHRodXMgZmFyLCBidXQgc3BlYWtpbmcgYXMgYQ0KIFdHIHBhcnRpY2lwYW50 LCBidXQgLSBhZ2FpbiBJIHN0cmVzcyB0aGF0IHRoaXMgaXMgaW50ZXJlc3RpbmcsIGltcG9ydGFu dCBpbmZvcm1hdGlvbiwgYW5kIG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBpbiB0aGlzIGRvY3VtZW50 Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5TdGFuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w 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 b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTdGFuDQogUmF0bGlmZiBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5y YXRsaWZmc3RhbkBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE4IEFwcmlsIDIw MTYgMTQ6MTg8YnI+DQo8Yj5Ubzo8L2I+IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspPGJyPg0K PGI+Q2M6PC9iPiBDaHJpc3RvcGhlciBEZWFybG92ZTsgPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQptYW5ldEBpZXRmLm9yZzwvYT47IENocmlzdG9waGVy IERlYXJsb3ZlPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFuZXRdIFdHTEMgcmVxdWVzdCBm b3IgZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNl bnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8L3NwYW4+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBm cm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFy dG5lciBvciB0aGUgaW50ZXJuZXQuPGJyPg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91 IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5 Ljxicj4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPjwvaT48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L2I+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxv b2sgb3V0IGZvciBpbiBlbWFpbHMNCiB5b3UgcmVjZWl2ZSwgY2xpY2sgPGEgaHJlZj0iaHR0cDov L2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0 cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIiB0YXJnZXQ9Il9ibGFuayI+DQpoZXJlPC9hPi48 YnI+DQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyA8 YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1 cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBF bWFpbHMucGRmIiB0YXJnZXQ9Il9ibGFuayI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2k+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9u IE1vbiwgQXByIDE4LCAyMDE2IGF0IDk6MTMgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdl dD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBoYXMgYmVlbiBwb2ludGVk IG91dCB0byBtZSwgc29tZSBpbXBsZW1lbnRhdGlvbnMgZG9u4oCZdCBkbyB0aGlzLiBJZiB5b3Ug YXJlIGJ1aWxkaW5nIGFuIGltcGxlbWVudGF0aW9uDQogaW4gYSBjb25zdHJhaW5lZCBlbnZpcm9u bWVudCwgeW91IGNhbiBidWlsZCBhIGNvbnN0cmFpbmVkIGltcGxlbWVudGF0aW9uLiBBbmQgc29t ZSBwZW9wbGUgaGF2ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBubywgaXTigJlzIG5vdCBhcHByb3ByaWF0 ZSB0byBzcGVjaWZ5IGFuIGluZGVwZW5kZW50IHBhcnNlciwgb3IgcmVxdWlyZSBvbmUuIFJhdGhl ciB5b3UgbmVlZCB0bw0KIGRlc2lnbiBzbyB0aGF0IHdoZW4gcGVvcGxlIGRvLCBpdCBjYW4gYmUg ZWZmaWNpZW50LiBXaGljaCBpcyB3aGF0IHdlIGhhdmUgYmVlbiBkb2luZy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5PciBpbiBvdGhlciB3b3JkcywgSSBkb27igJl0IHRoaW5rIHRoaXMgc29ydCBvZiBjaGFuZ2Ug aXMgYXBwcm9wcmlhdGUuIFF1aXRlIHRoZSBjb250cmFyeS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlbGws IHdlIGRpc2FncmVlLiBUaGlzIGhhcyBiZWVuIGEgZnVuZGFtZW50YWwgcG9pbnQgb2YgY29udGVu dGlvbiBmb3Igc29tZSBvZiB0aGUgZm9sbG93LW9uIHByb3RvY29scyBhdHRlbXB0aW5nIHRvIHVz ZSA1NDQ0LiBhbmQgSU1PLCB0aGlzIGhhcyB0byBiZSBhZGRyZXNzZWQuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhlIGtleSBwb2ludCBpcyB0aGF0IHdoYXTigJlzIG1hbmRhdGVk IGlzIGEgbXVsdGlwbGV4ZXIgYW5kIGEgZm9ybWF0LiBCdXQgbm90IGFuIGluZGVwZW5kZW50IHBh cnNlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhvdyBjYW4geW91IG1hbmRhdGUg YSBtdWx0aXBsZXhlciwgYnV0IG5vdCBhbiBpbmRlcGVuZGVudCBwYXJzZXI/IFRoaXMgbWFrZXMg bm8gc2Vuc2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5TdGFuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0K PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4N ClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs bGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOzxhIGhyZWY9InRlbDol MkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0IiB0YXJnZXQ9Il9ibGFuayI+JiM0Mzs0NCAoMCkx MjQ1IDI0MjE5NDwvYT4NCiAmbmJzcDt8ICZuYnNwOzxiPkU6IDwvYj48YSBocmVmPSJtYWlsdG86 Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFy bG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2Zv cmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4 SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8 L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxp ZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsg V2FsZXMgTm86IDAxMzM3NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZp Y2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gU3Rhbg0KIFJhdGxpZmYgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cmF0bGlm ZnN0YW5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmF0bGlmZnN0YW5AZ21haWwuY29tPC9h Pl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxOCBBcHJpbCAyMDE2IDE0OjA5PGJyPg0KPGI+VG86PC9i PiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4NCjxiPkNjOjwvYj4gQ2hyaXN0b3BoZXIg RGVhcmxvdmU7IDxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pg0KbWFuZXRAaWV0Zi5vcmc8L2E+OyBDaHJpc3RvcGhlciBEZWFybG92ZTxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW21hbmV0XSBXR0xDIHJlcXVlc3QgZm9yIGRyYWZ0LWlldGYtbWFuZXQtcmZj NTQ0NC11c2FnZS0wMzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sg MS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRl cjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRl cjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlz YXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljxi cj4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxp bmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48YnI+DQpGb3IgaW5mb3JtYXRpb24g cmVnYXJkaW5nIDwvc3Bhbj48L2k+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9iPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzMzMzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzDQog eW91IHJlY2VpdmUsIGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVt cy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdz LnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0KaGVyZTwvYT4uPGJyPg0KSWYgeW91IGZlZWwgdGhlIGVt YWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0 LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVu dHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiIgdGFyZ2V0PSJfYmxh bmsiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBNb24sIEFwciAxOCwgMjAxNiBhdCA0 OjUyIEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNo cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxv dmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IGJlbGlldmUgd2UgY2FuIG9yIHNob3VsZCBzdWdnZXN0 IGFuIGltcGxlbWVudGF0aW9uLiBUaGF04oCZcyBub3Qgd2hhdCB0aGUgSUVURiBkb2VzLCBhbmQg aXQNCiB3b3VsZCBiZSBhIGhhcmQsIHByb2JhYmx5IGltcG9zc2libGUsIHNlbGwsIHRvIHRoZSBJ RVNHLiBUaGF0IHRoZSBvYnZpb3VzIGltcGxlbWVudGF0aW9uIGVtcGxveXMgYW4gaW5kZXBlbmRl bnQgcGFyc2VyIGlzIGFscmVhZHkgc2FpZCAtIGl0IG1heSBiZSBhcHByb3ByaWF0ZSB0byBzdHJl bmd0aGVuIHRoZSB3b3JkcywgYnV0IHRoaXMgc2Vjb25kIEnigJltIG5vdCBzdXJlIGlmIHRoYXTi gJlzIG5lZWRlZCAobm90IGdvdCB0aW1lIHRvIGNoZWNrIGN1cnJlbnQNCiB3b3JkaW5nKS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPihBZ2Fpbiwgd2l0aCBteSBXb3JraW5nIEdyb3VwIFBhcnRpY2lwYW50IGhh dCBvbikgLSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SSBkb24ndCBtZWFuIHRvIHN1Z2dlc3QgYW4gaW1wbGVtZW50YXRpb24u IEF0IGxlYXN0IHRvIG1lLCB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyZSAodGhhdCBvZiBhbiBpbmRl cGVuZGVudCBwYXJzZXIsIHdpdGggYSByZWxpYWJsZSBjb21tdW5pY2F0aW9ucyBtZWNoYW5pc20g dG8gc2FpZCBwYXJzZXIsIHRoYXQNCiBkZWFscyB3aXRoIGxvZ2ljYWwgbWVzc2FnZXMgaW5zdGVh ZCBvZiBwYWNrZXRzLiBJcyBzZXF1ZW5jaW5nIGd1YXJhbnRlZWQ/IEknbSBub3Qgc3VyZSwgdG8g YmUgaG9uZXN0LiBCdXQgb25jZSB0aGUgaW5kZXBlbmRlbnQgcGFyc2VyIGlzIGFzc3VtZWQsIGVu Z2luZWVycyBhbHNvIE1VU1QgYXNzdW1lIHRoYXQgdGhlIHRyYW5zcG9ydCAoYW5kIGl0J3MgdGhl IHRyYW5zcG9ydCBmb3IgY29udHJvbCBwbGFuZSB0cmFmZmljLCBidXQgbm90IGZvciBkYXRhDQog cGxhbmUgdHJhZmZpYyksIGlzICZxdW90O293bmVkJnF1b3Q7IGJ5IHRoZSBpbmRlcGVuZGVudCBw YXJzZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5XaGljaCBsZWFkcyBtZSB0byB0aGUgb3RoZXIgcG9pbnQgSSdtIHRyeWlu ZyB0byBtYWtlIChwZXJoYXBzIGJhZGx5KTogJm5ic3A7QWJzdHJhY3RpbmcgdGhlIHRyYW5zcG9y dCBhd2F5IGZyb20gdGhlIGNvbnRyb2wgcGxhbmUgKmNhbiogZWZmZWN0IHByb3RvY29sIGRlc2ln bi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkkgYmVsaWV2ZSBib3RoIG9mIHRoZXNlIHBvaW50cyBzaG91bGQgYmUgYWRkcmVz c2VkIGluIHRoZSB1c2FnZSBkb2N1bWVudC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlN0YW48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMwMDdFN0UiPi0tDQo8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9w aGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0 ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0Ui Pjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+ VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5i c3A7PGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQiIHRhcmdldD0iX2Js YW5rIj4mIzQzOzQ0ICgwKTEyNDUgMjQyMTk0PC9hPg0KICZuYnNwO3wgJm5ic3A7PGI+RTogPC9i PjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs bGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1z Zm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMu Y29tL2FpIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5i YWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+ QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQg aW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4Qjky Ij5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3Vy cmV5LCBHVTIgN1lQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtYW5ldA0KIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldC1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U3RhbiBSYXRsaWZmPGJyPg0KPGI+ U2VudDo8L2I+IDE2IEFwcmlsIDIwMTYgMTk6MDk8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdG9waGVy IERlYXJsb3ZlPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9yZzwvYT47IENocmlzdG9waGVyIERlYXJsb3Zl PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFuZXRdIFdHTEMgcmVxdWVzdCBmb3IgZHJhZnQt aWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNr Z3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3Rl eHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8L3NwYW4+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O3Rl eHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNp ZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0 aGUgaW50ZXJuZXQuPGJyPg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBj bGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljxicj4NCkZv ciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPjwvaT48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L2I+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZv ciBpbiBlbWFpbHMNCiB5b3UgcmVjZWl2ZSwgY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0 LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVu dHMvUmVkJTIwRmxhZ3MucGRmIiB0YXJnZXQ9Il9ibGFuayI+DQpoZXJlPC9hPi48YnI+DQpJZiB5 b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyA8YSBocmVmPSJo dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90 bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRm IiB0YXJnZXQ9Il9ibGFuayI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2k+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3 aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MS4wcHQgNC4wcHQgMS4wcHQgNC4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4qPGI+KiogPC9iPjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XQVJO SU5HDQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qKio8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkVYVEVS TkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3Jn YW5pemF0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgQXByIDE1LCAyMDE2 IGF0IDM6MjcgUE0sIENocmlzdG9waGVyIERlYXJsb3ZlICZsdDs8YSBocmVmPSJtYWlsdG86Y2hy aXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXNAbW5lbW9zeW5l LmRlbW9uLmNvLnVrPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgeW91IG1lYW4g YnkgdGhlIGNvbmNlcHQgb2YgJnF1b3Q7ZmllbGRzIHRoZSBwcm90b2NvbCBjYW4gYW5kIGNhbid0 IHRvdWNoJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5DQVZFQVQ6IEkgYW0gc3BlYWtpbmcgaGVyZSBhcyBhIFdvcmtpbmcg R3JvdXAgcGFydGljaXBhbnQuIFdpdGggdGhhdCB1bmRlcnN0b29kOg0KPGJyPg0KJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5UVEwgaXMg YSBncmVhdCBleGFtcGxlLCBzaW5jZSB0aGF0IGRpc2N1c3Npb24gYmxldyB0aGUgbWFpbGluZyBs aXN0IHVwIGEgZmV3IG1vbnRocyBhZ28uIEknbSAqbm90KiBzYXlpbmcgbWFuaXB1bGF0aW5nIFRU TCBpcyBhIGdvb2QgdGhpbmcgZm9yIGEgcHJvdG9jb2wgdG8gdHJ5IC0gaW4gdHJ1dGgsIEkgdGhp bmsgaXQncw0KIHByZXR0eSAmcXVvdDtoYWNreSZxdW90Oy4gQnV0IHRoZSBub3Rpb24gd2FzIGZs b2F0ZWQsIGFuZCBpbiB0aGUgY29udGV4dCBvZiB0aGF0IGRpc2N1c3Npb24sIGl0IG1heSB3aWxs IGhhdmUgd29ya2VkLiBUaGUgb3Bwb3NpdGlvbiBvbi1saXN0IHdhcyBmYXN0LCBhbmQgcHJldHR5 IGZvcmNlZnVsLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w cHQiPkkndmUgc2FpZCBiZWZvcmUgLSA1NDQ0LCBlc3BlY2lhbGx5IHdpdGggdGhlIG11bHRpcGxl eGVyLCBjaGFuZ2VzIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBhIHJvdXRpbmcgcHJvdG9jb2wg YW5kIGFuIGludGVyZmFjZS4gSSB0aGluayB0aGUgZG9jdW1lbnQgc2hvdWxkIGhhdmUgc29tZSB0 eXBlIG9mICZxdW90O292ZXJ2aWV3JnF1b3Q7DQogc2VjdGlvbiB3aGljaCBkaXNjdXNzZXMgdGhl c2UgZGlmZmVyZW5jZXMsIGluIG9yZGVyIHRvIGZyYW1lIHRoZSBpc3N1ZSBmb3Igc29tZW9uZSBj b21pbmcgYWxvbmcgd2hvIGhhc24ndCBiZWVuIGEgcGFydCBvZiB0aGUgNTQ0NCBtYWlsIGRpc2N1 c3Npb24uDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ SSdtIHRhbGtpbmcgYWJvdXQgdGhlIHR5cGUgb2Ygb3ZlcnZpZXcgdGhhdCBnb2VzIHNvbWV0aGlu ZyBsaWtlIHRoaXM6DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+JnF1b3Q7VXNlIG9mIFJGQyA1NDQ0IHdpdGggdGhlIG11bHRpcGxleGVyIGZlYXR1cmUg aW1wb3NlcyBkZXNpZ24gcmVxdWlyZW1lbnRzIG9uIHRoZSBwcm90b2NvbC4gVGhlIGFjdHVhbCB0 cmFuc3BvcnQgbWVjaGFuaXNtIGlzIGFic3RyYWN0ZWQgZnJvbSB0aGUgcHJvdG9jb2wuIEZvciBl eGFtcGxlLCByb3V0aW5nIHByb3RvY29scw0KIGFyZSBub3QgYXdhcmUgb2YgcHJlY2lzZWx5IHdo ZW4gYSBtZXNzYWdlIGlzIHNlbnQuIEEgZ29vZCBleGFtcGxlIG9mIG9wZXJhdGlvbiBpbiB0aGlz IG1vZGVsIGlzIFtCR1BdLCB1dGlsaXppbmcgdGhlIFtUQ1BdIHRyYW5zcG9ydC4gVGhpcyBpcyBv cHBvc2VkIHRvIGEgcHJvdG9jb2wgc3VjaCBhcyBbT1NQRl0sIHdoaWNoIGlzIGNhcGFibGUgb2Yg c2VuZGluZyB0cmFmZmljIHdpdGggaXRzIG93biBJUCB0eXBlLiBTaW5jZSB0aGUgdHJhbnNwb3J0 DQogaXMgYWJzdHJhY3RlZCwgcHJvdG9jb2xzIGFyZSBub3QgcHJlc2VudGVkIHdpdGggJnF1b3Q7 cGFja2V0cyZxdW90OywgYW5kIGFyZSBub3QgY2FwYWJsZSBvZiBtYW5pcHVsYXRpbmcgZGF0YSBp dGVtcyBpbiBwYWNrZXQgaGVhZGVycyAoZS5nLiBkYXRhIGl0ZW1zIGF0IHRoZSBJUCBhbmQvb3Ig TUFDIGxheWVycykuJnF1b3Q7PGJyPg0KPGJyPg0KQXMgTG91IEJlcmdlciBwdXQgaXQgdG8gbWUg aW4gdGhlIGNvbnRleHQgb2YgRExFUCAtICZxdW90O1lvdSB3YW50IGFuIGVuZ2luZWVyIHRvIGJl IGFibGUgdG8gcGljayB1cCB0aGlzIGRvY3VtZW50LCB3aXRoIG5vIHByaW9yIGV4cG9zdXJlIHRv IHRoZSB0b3BpYywgYW5kIGNvZGUgYW4gaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbi4mcXVv dDsmbmJzcDsgSSB0aGluayB0aGlzIHR5cGUgb2YgYW4gb3ZlcnZpZXcsIHNldHRpbmcgYmFzaWMg Z3JvdW5kIHJ1bGVzLCB3b3VsZA0KIGhlbHAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPkkndmUgYWxzbyBjb250ZW5kZWQgZm9yIGEgd2hpbGUgbm93IHRo YXQgNTQ0NCwgd2l0aCB0aGUgbXV4LCBlZmZlY3RpdmVseSBmb3JjZXMgYW4gYXJjaGl0ZWN0dXJl IG9uIGltcGxlbWVudGVycyAtIGluIHRoZSBMaW51eCB3b3JsZCwgdGhhdCBhcmNoaXRlY3R1cmUg aXMgYSA1NDQ0IHBhcnNlciBhcyBhbiBpbmRlcGVuZGVudA0KIHByb2Nlc3MsIHdpdGggSVBDIG1l Y2hhbmlzbXMgdG8gdGhlIHJvdXRpbmcgcHJvdG9jb2wocykgaXQgaXMgc2VydmljaW5nLiBUaGUg NTQ0NCBwYXJzZXIgaXRzZWxmICZxdW90O293bnMmcXVvdDsgdGhlIHRyYW5zcG9ydCAodGhlIHNv Y2tldCkuIFRoZSB1c2FnZSBkb2N1bWVudCAqc3Ryb25nbHkgaW5mZXJzKiB0aGF0LiBJIGJlbGll dmUgd2Ugc2hvdWxkIGNvbmNyZXRlbHkgc3RhdGUgaXQsIHNvIHdlIGRvbid0IGhhdmUgdG8gYW5z d2VyIHRoZSBxdWVzdGlvbiBvdmVyDQogYW5kIG92ZXIgYWdhaW4uIDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5TdGFuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hl biBhIHByb3RvY29sIGNyZWF0ZXMgYSBtZXNzYWdlIGZyb20gc2NyYXRjaCBpdCdzIG5vdCBjb25z dHJhaW5lZCBpbiBhbnkgd2F5IEknZCBkZXNjcmliZSBpbiBzdWNoIHRlcm1zLiBTbyBJIGFzc3Vt ZSB5b3UgbWVhbiB3aGVuIGl0IHJlY2VpdmVzIGEgbWVzc2FnZSBhbmQgdGhlbiBzZW5kcyBhIHNp bWlsYXINCiBtZXNzYWdlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VGhlcmUgYXJlIHR3byBjYXNlcyB0aGVyZS4gVW5jaGFuZ2VkICh3 aXRoIHRoZSBzcGVjaWFsIGV4Y2VwdGlvbnMgZm9yIGhvcCBjb3VudCBhbmQgbGltaXQpIGFuZCBu b3QgdW5jaGFuZ2VkLiBUaGUgZm9ybWVyIGlzIGJldHRlciwgYW5kIHRoZXJlJ3MgcmVhbGx5IG5v dGhpbmcgbW9yZSB0byBzYXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5TbyBsZXQncyBjb25zaWRlciB0aGUgbGF0dGVyLiBSZWFsbHkg aXQncyBub3QgdGhlIHNhbWUgbWVzc2FnZSwgaXQncyBhIGJyYW5kIG5ldyBtZXNzYWdlLiBUaGF0 J3MgYSB1c2VmdWwgd2F5IHRvIGxvb2sgYXQgaXQgZnJvbSBhIHNlY3VyaXR5IHBlcnNwZWN0aXZl LCBiZWNhdXNlIGl0IHRlbGxzIHlvdSB0aGF0DQogZW5kIHRvIGVuZCBhdXRoZW50aWNhdGlvbiBp c24ndCBnb2luZyB0byB3b3JrLiBBbmQgd2hhdCBhcmUgdGhlIHJlc3RyaWN0aW9ucyBvbiBicmFu ZCBuZXcgbWVzc2FnZXM/IFRoZSBzYW1lIGFzIG9uIGFueSBuZXcgbWVzc2FnZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9LLCB5b3Ug bWlnaHQgc2F5LCB0cnVlIGJ1dCBkb2VzIHRoYXQgbWVhbiBJIGNhbiBhZGQgdGhpcywgcmVtb3Zl IHRoYXQsIGNoYW5nZSB0aGUgaG9wIGRhdGE/IFllcy4gQnV0IGlzIHRoYXQgYSBnb29kIGlkZWE/ IE5vLiBCdXQgbWF5YmUgeW91IGFyZSBmb3JjZWQgaW50byBpdC4gQnV0IHRoYXQgaXQncyBpbmhl cmVudGx5DQogbm90IGdvb2Qgc3VnZ2VzdHMgdGhlIGNvcm9sbGFyeSB0aGF0IGlmIHlvdSBtdXN0 LCBkbyB0aGUgbWluaW11bSBhbmQgbWFrZSBpdCB0cmFja2FibGUuIEJ1dCB0aGF0J3Mgbm90IGEg NTQ0NCByZXF1aXJlbWVudCwganVzdCBnb29kIHByYWN0aWNlLiBJdCBkb2VzIGJyZWFrIDcxODIg bWVzc2FnZSBJQ1ZzLCBzbyBkb24ndCB1c2UgdGhlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIGNvdWxkLCBoeXBvdGhldGljYWxs eSwgaGF2ZSBzb21lb25lIGNyZWF0ZSBhbiBleHRlbnNpb24gb3IgYWx0ZXJuYXRpdmUgdG8gNzE4 MiB0aGF0IGRlZmluZWQgYWdncmVnYXRlZCBzaWduYXR1cmVzLiBUaGVuIHdlJ2QgaGF2ZSBydWxl cyBvbiB3aGF0IHlvdSBjb3VsZCBjaGFuZ2UuIEJ1dCB0aGF0IHdvdWxkDQogYmVsb25nIHRoZXJl LiBJZiB5b3UgdGhpbmsgdGhvc2Ugd291bGQgYmUgZ29vZCwgdGhlbiBhZ2FpbiB5b3Ugd291bGQg d2FudCBtYWtlIG1pbmltYWwgY2hhbmdlcywgYW5kIG1haW5seSBvbmx5IG9mIGNlcnRhaW4gdHlw ZXMuIFdoYXQgdHlwZXM/IFRoZXJlIEkgY2FuJ3QgaGVscCB5b3UgYXMgSSBkb24ndCBoYXZlIGEg Y2FuZGlkYXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VGhlIHN1bW1hcnk/IERvbid0IGNoYW5nZSBpZiB5b3UgZG9uJ3QgaGF2ZSB0 by4gVGhhdCdzIHJlY29tbWVuZGVkLiBJZiB5b3UgbXVzdCBjaGFuZ2UgeW91J3JlIG9uIHlvdXIg b3duICh3aXRoIHRoZSBzYW1lIHJlc3RyaWN0aW9ucyBhcyBuZXcgbWVzc2FnZXMpLiBBZHZpY2Ug bGlrZSAmcXVvdDthcyBsaXR0bGUgYXMNCiBwb3NzaWJsZSZxdW90OyBpcyBnb29kLCBidXQgdGhh dCdzIG5vdCBhY3R1YWxseSA1NDQ0IGFkdmljZS4gQW5kIGRvbid0IHVzZSA3MTgyIG1lc3NhZ2Ug SUNWcy48YnI+DQo8YnI+DQotLSAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkNocmlzdG9waGVyIERlYXJsb3ZlPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Im1haWx0bzpjaHJpc3Rv cGhlci5kZWFybG92ZUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3RvcGhlci5kZWFy bG92ZUBnbWFpbC5jb208L2E+IChpUGhvbmUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Im1haWx0bzpjaHJpc0BtbmVtb3N5bmUu ZGVtb24uY28udWsiIHRhcmdldD0iX2JsYW5rIj5jaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWs8 L2E+IChob21lKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCk9uIDE1IEFwciAyMDE2LCBhdCAxOTozNywgU3RhbiBSYXRsaWZmICZs dDs8YSBocmVmPSJtYWlsdG86cmF0bGlmZnN0YW5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ cmF0bGlmZnN0YW5AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk15IG1haW4gY29uY2Vy biBhZGRyZXNzZWQgaW5saW5lLi4uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+T24gRnJpLCBBcHIgMTUsIDIwMTYgYXQgMTo0OSBQTSwgQ2hyaXN0b3BoZXIgRGVhcmxvdmUg Jmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5jaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BIGZl dyBpbW1lZGlhdGUgY29tbWVudHMgaW5saW5lIGJlbG93Ljxicj4NCjxicj4NCi0tICZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hyaXN0b3BoZXIg RGVhcmxvdmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGEgaHJlZj0ibWFpbHRvOmNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNvbTwvYT4gKGlQaG9uZSk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEg aHJlZj0ibWFpbHRvOmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51ayIgdGFyZ2V0PSJfYmxhbmsi PmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51azwvYT4gKGhvbWUpPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gMTUgQXByIDIw MTYsIGF0IDE1OjE4LCBMb3R0ZSBTdGVlbmJyaW5rICZsdDs8YSBocmVmPSJtYWlsdG86bG90dGUu c3RlZW5icmlua0BmdS1iZXJsaW4uZGUiIHRhcmdldD0iX2JsYW5rIj5sb3R0ZS5zdGVlbmJyaW5r QGZ1LWJlcmxpbi5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+c3BhcmtlZCBieSB0aGUgcmVjZW50bHkgc3RhcnRlZCBXR0xD LCBJ4oCZdmUgcmV2aWV3ZWQgdGhlIGN1cnJlbnQgcmV2aXNpb24gb2YgdGhlIGRyYWZ0LiBJ4oCZ ZCBsaWtlIHRvIG9mZmVyIHRoZSB3b3JraW5nIGdyb3VwIG15IHBlcnNwZWN0aXZlIGFzIHNvbWVv bmUgd2hvIGRvZXNu4oCZdCBoYXZlIGRlY2FkZXMgb2YNCiBwcm90b2NvbCBhbmQvb3IgcGFja2V0 IGZvcm1hdCBkZXNpZ24gdW5kZXIgdGhlaXIgYmVsdCAoaS5lLiBzb21lIHRoaW5ncyBtaWdodCBu b3QgYmUgb2J2aW91cyB0byBtZSB0aGF0IGFyZSBvYnZpb3VzIHRvIG90aGVycyksIGJ1dCBhbHNv IGFzIHNvbWVvbmUgd2hvIGhhcyB3b3JrZWQgd2l0aCBSRkMgNTQ0NCB3aGVuIGltcGxlbWVudGlu ZyBhIHJvdXRpbmcgcHJvdG9jb2wgKEFPRFZ2MiksIHVwZGF0aW5nIHRoZSBwYWNrZXQgZm9ybWF0 IG9mIGENCiByb3V0aW5nIHByb3RvY29sIChBT0RWdjIgYWdhaW4pIGFuZCAocGFydGlhbGx5KSBp bXBsZW1lbnRpbmcgbXkgb3duIFJGQzU0NDQgYnVpbGRlci9wYXJzZXIuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PdmVyYWxsLCBJIHRo aW5rIHRoZSBkb2N1bWVudCBpcyBlYXN5IHRvIHJlYWQgYW5kIGZvbGxvdy4gVG8gbWUsIGl0IGNv bnRhaW5zIHZhbHVhYmxlIGluZm9ybWF0aW9uIGFuZCBndWlkYW5jZSBhbmQgaW4gc29tZSBjYXNl cyBwcmV2ZW50cyBwZW9wbGUgZnJvbSBzaG9vdGluZyB0aGVtc2VsdmVzIGluIHRoZQ0KIGZvb3Qu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkni gJltIHJlYWxseSBoYXBweSB0aGlzIGRvY3VtZW50IGV4aXN0cyBhbmQgSeKAmWQgbGlrZSBpdCB0 byBtb3ZlIGZvcndhcmQgc29vbiwgYnV0IEkgZG8gZmVlbCB0aGF0IGl0IGlzIHN0aWxsIGxhY2tp bmcgaW4gc29tZSBhcmVhcywgd2hpY2ggaXMgd2h5IEkgd2FzIGEgYml0IHN1cnByaXNlZCB0byBz ZWUgaXQgZ28NCiB0byBMYXN0IENhbGwgYWxsIG9mIGEgc3VkZGVuLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk5vdCByZWFsbHkuIFRoZSBhdXRob3JzIGhhZCBzYWlkIHdoYXQgdGhl eSBpbnRlbmRlZCB0byBzYXksIG5vIG9uZSB3YXMgY29tbWVudGluZywgdGltZSBmb3IgV0dMQy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5GaXJzdCwgc29tZSBuaXRwaWNrcyBhbmQgY29tbWVudHM6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIGZyb20mbmJzcDs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1 NDQ0LXVzYWdlLTAzI3NlY3Rpb24tMS4yLjEiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjEuMi4xPC9zcGFuPjwvYj48L2E+ PGI+Lg0KIFBhY2tldC9NZXNzYWdlIEZvcm1hdDwvYj46PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7W+KApl0gYSBw YWNrZXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdHJhbnNtaXNzaW9uIGZvbGxvd2luZyBhIHN1Y2Nlc3NmdWwgcGFja2V0IHJlY2VwdGlvbiBp cyBieSBkZXNpZ248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgb2YgYSBuZXcgcGFja2V0IHRoYXQgbWF5IGluY2x1ZGUgYWxsLCBzb21lLCBvciBu b25lIG9mIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyByZWNlaXZlZCBtZXNzYWdlcyBbLi4uXTxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SeKAmW0gbm90IGEgbmF0 aXZlIHNwZWFrZXIsIGJ1dCB0aGF0IOKAnm9m4oCcIHNlZW1zIG91dCBvZiBwbGFjZS4uLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5JIGFtIGEgbmF0aXZlIHNwZWFrZXIsIGFuZCBubywgaXQncyBub3QuIFNv bWUgd291bGQgcmVwZWF0IGl0IGFmdGVyIGVhY2ggb2YgYWxsLCBzb21lIGFuZCBub25lLCBhbmQg SSBtaWdodCBzb21ldGltZXMuIEJ1dCBpdCByZWFsbHkgZG9lc24ndCBtYXR0ZXIgd2hpY2ggb2Yg dGhlIHR3byBzdHlsZXMgd2UgcGljaywNCiB0aGUgUkZDIEVkaXRvciBtYXkgd2VsbCBjaGFuZ2Ug dG8gdGhlIG90aGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+KiBSZWdhcmRpbmcmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNC4y IiB0YXJnZXQ9Il9ibGFuayI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3Jh dGlvbjpub25lIj40LjI8L3NwYW4+PC9iPjwvYT48Yj4uDQogUGFja2V0cyBhbmQgTWVzc2FnZXM6 PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij50aGlzIHNlY3Rpb24gdGFsa3MgYSBsb3QgYWJvdXQgaG93IHRoZSBtdWx0aXBsZXhlciBvcGVy YXRlcywgc28gSSB0aGluayBpdOKAmWQgYmUgaGVscGZ1bCBpZiBpdHMgdGl0bGUgcmVmbGVjdGVk IHRoYXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ20gb2YgdHdvIG9waW5pb25zIG9uIHRoYXQuIE9uIHRo ZSBvbmUgaGFuZCBpdCBpcywgYXMgaXRzIHRpdGxlIHN1Z2dlc3RzLCBhYm91dCB0aGUgcGFja2V0 IGFuZCBtZXNzYWdlIGxldmVsLCBhcyBvcHBvc2VkIHRvIGxvd2VyIGxldmVscywgYW5kIGl0cyB0 aXRsZSBjb250cmFzdHMgd2l0aCB0aGF0IGlmIDQuMw0KIGZvciB0aGF0IHJlYXNvbi4gT24gdGhl IG90aGVyIGhhbmQgeW91IGFyZSByaWdodCwgaXQgZG9lcyBoYXZlIG11Y2ggYWJvdXQgdGhlIG11 bHRpcGxleGVyLiBBIHRpdGxlIGNvdmVyaW5nIGFsbCB0aHJlZSB3b3VrZCBzdGFydCBnZXR0aW5n IGN1bWJlcnNvbWUuIFdpbGwgdGFrZSB0aGlzIG9uZSBhd2F5IHRvIHRoaW5rIGFib3V0LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+KiBm cm9tJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt bWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTQuNCIgdGFyZ2V0PSJfYmxhbmsiPjxiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+NC40PC9zcGFuPjwv Yj48L2E+PGI+Lg0KIEFkZHJlc3NlcyBSZXF1aXJlIEF0dHJpYnV0ZXM6PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEFuIHVubW9kaWZpZWQg ZXh0ZW5zaW9uIHRvIE5IRFAgd291bGQgaWdub3JlIHN1Y2ggYWRkcmVzc2VzLDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhcyByZXF1aXJlZCwgYXMgaXQgZG9lcyBub3Qgc3Vw cG9ydCB0aGF0IHNwZWNpYWxpemVkIHB1cnBvc2UuPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkF0IGZpcnN0IGdsYW5jZSwgKHRvIG1l KSB0aGlzIHJlYWRzIGFzIOKAnkFsbCBhZGRyZXNzZXMgdGhhdCBhcmUgYXNzb2NpYXRlZCB3aXRo IGFuIHVua25vd24gVExWIGFyZSBpZ25vcmVk4oCcLCB3aGljaCBpcyBvYnZpb3VzbHkgbm9uc2Vu c2UgKGJ1dCBxdWl0ZSBwYW5pYy1pbmR1Y2luZyA6RCkuIEnigJlkIHByb3Bvc2UNCiB0byByZXdv cmQgaXQgdG8gc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgQW4gdW5tb2RpZmllZCBleHRlbnNp b24gdG8gTkhEUCB3b3VsZCBub3QgY29uc2lkZXIgdGhpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBhZGRyZXNzIHRvIGJlIG9mIGEgbmVpZ2hib3IsIGFzIGl0IGlzIGxhY2tp bmcgYSBMSU5LX1NUQVRVUzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBvciBP VEhFUl9ORUlHSEIgVExWLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRha2UgeW91ciBwb2ludCwgYnV0IEkgdGhp bmsgdGhhdCBpZiB0aGUgYWRkcmVzcyBlbmRzIHVwIHdpdGggbm8gcmVsZXZhbnQgYXNzb2NpYXRl ZCBUTFZzIHRoZW4gaXQgaXMgaWdub3JlZCBpcyBhbHNvIGEgcG9pbnQuIEkgZGFyZSBzYXkgd2Ug Y2FuIHdvcmRzbWl0aCBzb21ldGhpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkFsc28sIEkgZG9u4oCZdCBxdWl0ZSBnZXQgd2hlcmUgeW914oCZ cmUgZ29pbmcgd2l0aCB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgdGhhdCBzZWN0aW9uICjigJw8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhlc2UgcmVzdHJpY3Rpb25zIGRvIG5vdCwgaG93 ZXZlciwgbWVhbiB0aGF0IGFkZGVkIGluZm9ybWF0aW9uDQogaXM8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGNvbXBsZXRlbHkgaWdub3JlZCBmb3IgcHVy cG9zZXMgb2YgdGhlIGJhc2UgcHJvdG9jb2wu4oCdKS4uLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlYWQgb24sIHRoZSByZXN0IG9mIHRoZSBw YXJhZ3JhcGggZGVzY3JpYmVzIHRoZSBjYXNlIHdoZXJlIG5vdC4gQnV0IHdlIG1pZ2h0IHRlbGVn cmFwaCB0aGF0IGJldHRlciBpbiB0aGUgb3BlbmluZyBzZW50ZW5jZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+KiByZWdhcmRpbmcgdGhlIG1hcHMg aW4mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1t YW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNC41IiB0YXJnZXQ9Il9ibGFuayI+PGI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj40LjU8L3NwYW4+PC9i PjwvYT48Yj4uDQogSW5mb3JtYXRpb24gUmVwcmVzZW50YXRpb246PC9iPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J4oCZbSBhZnJhaWQgSSBq dXN0IGRvbuKAmXQgcmVhbGx5IHVuZGVyc3RhbmQgdGhlIHB1cnBvc2Ugb2YgdGhpcyBzZWN0aW9u IGFuZCB0aGUgbWFwcGluZyBub3RhdGlvbi4gSeKAmW0gYXNzdW1pbmcgdGhhdCB0aGUgbWFwcyBh cmUgc3VwcG9zZWQgdG8gb2ZmZXIgYSB3YXkgb2YgZGVzY3JpYmluZyBob3cgYSBUTFYgcmVsYXRl cw0KIHRvIGEgbWVzc2FnZSBvciBhbiBhZGRyZXNzPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiBzbywgd2h5IGRvZXMgaXQgb25s eSBtZW50aW9uIGV4dGVuc2lvbiB0eXBlcywgYnV0IG5vdCB0aGUgYmFzaXMgdHlwZXM/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQg c2F5cyBleHRlbmRlZCB0eXBlcywgbWVhbmluZyB0aGUgY29tYmluYXRpb24gb2YgdGhlIHR3by4g QnV0IGZ1bGwgdHlwZSB3b3VsZCBiZSBiZXR0ZXIsIGFzIGFsbW9zdCBkZWZpbmVkIGluIDU0NDQu IEluIGZhY3QgSSB0aGluayB3ZSBzaG91bGQgYWRkIGEgY29tbWVudCB0byB0aGUgbm90YXRpb24g c2VjdGlvbi4NCiAoNTQ0NCB1c2VzIGEgc3ltYm9saWMgbmFtZSByYXRoZXIgdGhhbiB0aGUgcGhy YXNlLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ T3IgaXMgaXQgc3VwcG9zZWQgdG8gYmUgdXNlZCBzb21ldGhpbmcgbGlrZSB0aGlzOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPkJBU0VfVExWPC9zcGFuPjwvYj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj5NZXNzYWdlOiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPihiYXNlX3Rsdl9leHRlbnNpb25fdHlwZV8xKSAtJmd0 OyAoMiBvY3RldHMsICZxdW90O3ZhbHVlIGEgd2hlbiBjb25kaXRpb24geCBpcyBtZXQmcXVvdDsp PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+KGJhc2VfdGx2X2V4dGVuc2lv bl90eXBlXzIpIC0mZ3Q7ICgyIG9jdGV0cywgJnF1b3Q7dmFsdWUgYiB3aGVuIGNvbmRpdGlvbiB5 IGlzIG1ldCZxdW90Oyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4/IEFsc28sIEkgZG9u4oCZdCBxdWl0ZSBnZXQgaG93IHRo aXMgd291bGQgYmUgdXNlZCBpbiBmdXR1cmUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnM/IE9yIGFp ZCBpbiBpbXBsZW1lbnRpbmcgUkZDNTQ0NCBwYXJzZXJzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbiBleGFtcGxlIG9yIGEgY2xhcmlmaWNh dGlvbiB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQncyBhIHdheSBvZiBsb29raW5nIGF0IHRo aW5ncy4gQnV0IG5vdCB0aGUgb25seSBvbmUsIGl0IGdvZXMgb24gdG8gZGlzY3VzcyB2YXJpYW50 cy4gSSB0aGluayBpdCBtb3N0bHkgY29tZXMgdW5kZXIgaGVhZGluZyBvZiBpZiB1c2VmdWwgdXNl IGl0LCBpZiBub3Qgc2tpcCBpdC4gV2UnbGwgdGFrZSBhbm90aGVyDQogbG9vaywgYnV0IEkgZG9u J3QgdGhpbmsgdGhpcyB3aWxsIGV2ZXIgYmUgZWxlbWVudGFyeS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+KiByZWdhcmRpbmcmbmJzcDs8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVz YWdlLTAzI3NlY3Rpb24tNC42IiB0YXJnZXQ9Il9ibGFuayI+PGI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj40LjY8L3NwYW4+PC9iPjwvYT48Yj4uDQogVExW czo8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkluIGdlbmVyYWwsIGl04oCZcyBub3QgY2xlYXIgZXZlcnl3aGVyZSBpbiB0aGUgc2VjdGlv biB3aGV0aGVyIHlvdeKAmXJlIHRhbGtpbmcgdG8gUkZDNTQ0NCBwYXJzZXIvYnVpbGRlciBpbXBs ZW1lbnRvcnMgb3IgcHJvdG9jb2wgZGVzaWduZXJzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEEgcHJvdG9jb2wgU0hPVUxEIHVzZSBh biBlZmZpY2llbnQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgcmVwcmVzZW50 YXRpb24sIGJ1dCB0aGlzIGlzIGEgcXVhbGl0eSBvZiBpbXBsZW1lbnRhdGlvbiBpc3N1ZS48bzpw PjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJltIG5v dCBzdXJlIHdoZXJlIHlvdeKAmXJlIGdvaW5nIHdpdGggdGhlIGxhc3QgcGFydCBvZiB0aGF0IHNl bnRlbmNlPyBJ4oCZZCByZXdvcmQgaXQgdG8gc29tZXRoaW5nIGxpa2Ug4oCeQSBwcm90b2NvbCBT SE9VTEQgdXNlIGFuIGVmZmljaWVudCByZXByZXNlbnRhdGlvbiwgYXZvaWRpbmcgdW5uZWNlc3Nh cmlseSB2ZXJib3NlDQogdXNlIG9mIFRMVnMgYW5kIGV4dGVuc2lvbiB0eXBlcy4gSG93ZXZlciwg dGhlIGZpbmFsIGFycmFuZ2VtZW50IGluIGEgbWVzc2FnZS0gb3IgYWRkcmVzc1RMViBibG9jayBp cyAmbmJzcDthIHF1YWxpdHkgb2YgaW1wbGVtZW50YXRpb24gaXNzdWXigJwgKGluIGNhc2UgdGhh dOKAmXMgd2hhdCB5b3UgbWVhbnQpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm8sIHlvdSdyZSBjb25zaWRlcmluZyB0 aGUgcHJvdG9jb2wgZGVzaWduLiBUaGlzIGlzIGNvbnNpZGVyaW5nIHRoZSBwcm90b2NvbCBvYmpl Y3QgdGhhdCBpbXBsZW1lbnRzIHRoZSBwcm90b2NvbC4gVGhlcmUgaXNuJ3QgYSBvbmUgdG8gb25l IG1hcHBpbmcgZnJvbSBpbmZvcm1hdGlvbiB0byByZXByZXNlbnRhdGlvbiwNCiBpdCdzIHVwIHRv IHRoZSBpbXBsZW1lbnRhdGlvbiB0byBkbyBpdCBlZmZpY2llbnRseS4gRGlmZmVyZW50IGltcGxl bWVudGF0aW9ucyBvZiB0aGUgc2FtZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIG1heSBkbyBiZXR0 ZXIgb3Igd29yc2UgaGVyZS4gKFRyaXZpYWwgY2FzZSwgYW4gaW1wbGVtZW50YXRpb24gY291bGQg Y2hvb3NlIHRvIG5ldmVyIGNvbXByZXNzIGFkZHJlc3Nlcy4gQmFkIGlkZWEsIGJ1dCBsZWdhbC4p PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZCB0 aGVuOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IEE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgcHJvdG9jb2wgTVVTVCByZWNv Z25pemUgYW55IHBlcm1pdHRlZCByZXByZXNlbnRhdGlvbiBvZiB0aGU8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgaW5mb3JtYXRpb247IGV2ZW4gaWYgaXQgY2hvb3NlcyB0byAo Zm9yIGV4YW1wbGUpIG9ubHkgdXNlIG11bHRpdmFsdWU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgVExWcywgaXQgTVVTVCByZWNvZ25pemUgc2luZ2xlIHZhbHVlIFRMVnMgKGFu ZCB2aWNlIHZlcnNhKS48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPuKApiBJIHRob3VnaHQgcHJvdG9jb2xzIHdlcmVu4oCZdCBzdXBwb3NlZCB0byBz cGVjaWZ5IHdoZXRoZXIgYSBUTFYgaXMgYXJyYW5nZWQgKGZvciBleGFtcGxlKSBhcyBhIG11bHRp dmFsdWUgVExWPyE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkltcGxlbWVudGF0aW9uIGFnYWluLCBub3QgZGVzaWduLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ QW5kIHNvLCBzaW5jZSBhIHByb3RvY29sIHNob3VsZG4ndCBiZSBjb25jZXJuZWQgd2l0aCBtdWx0 aXZhbHVlIFRMVnMgYW5kIHRoZSBsaWtlLCB3b3VsZG7igJl0IGl0IGJlIHRoZSAqUkZDNTQ0NCBp bXBsZW1lbnRhdGlvbiogdGhhdCBNVVNUIHJlY29nbml6ZSBhbnkgcGVybWl0dGVkIHJlcHJlc2Vu dGF0aW9uPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPllvdSdyZSBhc3N1bWluZyB0aGF0IHRoZXJlIGlzIGFu IFJGQyA1NDQ0IGltcGxlbWVudGF0aW9uLiBUaGF0J3MgdGhlIHNhbWUgd2F5IHRvIHdvcmsgaWYg eW91IHBsYW4gdG8gaW1wbGVtZW50IG1vcmUgdGhhbiBvbmUgcHJvdG9jb2wuIEJ1dCBub3RoaW5n IHNheXMgeW91IGhhdmUgdG8gZG8gaXQgdGhhdCB3YXkuDQogVGhlIGFyY2hpdGVjdHVyZSBkZWZp bmVkIGJ5IDU0OTggYWRtaXRzIG9mIHRoZSBtdWx0aXBsZXhlciBhbmQgcHJvdG9jb2xzLCBhbmQg dGh1cyB0aGVzZSBhcmUgcnVsZXMgb24gdGhlIHByb3RvY29sLiBJZiBwcm90b2NvbHMgZGVsZWdh dGUgYWxsIHRoZWlyIGNvbW1vbiB3b3JrIHRvIHNvbWV0aGluZyAocGFyc2VyL2NyZWF0b3IpIHRo ZW4gaXQgaW5oZXJpdHMgdGhvc2UgcmVzdHJpY3Rpb25zLCBidXQgdGhhdCdzIG5vdCBkZWZpbmVk LCBhbmQgd2UNCiBjYW4ndCBhc3N1bWUgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPk9yIGlzIHRoaXMgcGFyYWdyYXBoIHJlYWxseSBqdXN0IGEg Y29tcGxpY2F0ZWQgd2F5IG9mIHNheWluZyDigJ5hcyBhIHByb3RvY29sIGRlc2lnbmVyLCBtYWtl IHN1cmUgdG8gbm90IHNwZWNpZnkvcmVseSBvbiB0aGluZ3MgbGlrZSAoZm9yIGV4YW1wbGUpIG11 bHRpdmFsdWUgVExWcywgc2luY2UgeW91ciBtZXNzYWdlcw0KIGhhdmUgdG8gd29yayB3aXRoICph bnkqIHJlcHJlc2VudGF0aW9u4oCcPyBJZiBzbywgSSB0aGluayB0aGF0IHNob3VsZCBiZSBkb25l IGluIGEgbGVzcyBjb21wbGljYXRlZCBmYXNoaW9uIChzZWUgYmVsb3cpLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIHJl Z2FyZGluZyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi01IiB0YXJnZXQ9Il9ibGFuayI+PGI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj41PC9zcGFuPjwv Yj48L2E+PGI+Lg0KIFN0cnVjdHVyZTo8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNpbmNlIHRoaXMgc2VjdGlvbiB0YWxrcyBhIGxvdCBh Ym91dCBmbGFncywgaXTigJlkIGJlIG5pY2UgaWYgaXRzIHRpdGxlIHJlcHJlc2VudGVkIHRoYXQu IE1heWJlIGNvbnNpZGVyIHJlbmFtaW5nIGl0IHRvJm5ic3A74oCeU3RydWN0dXJlIGFuZCBGbGFn c+KAnCZuYnNwO29yIHNvPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkkgbW9zdGx5IGRvbid0IGFncmVlLiBTdHJ1Y3R1cmUgaXMgdGhl IHN1YmplY3QsIGZsYWdzIGFyZSBhIGRldGFpbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+KiBmcm9tJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9u LTYuMSIgdGFyZ2V0PSJfYmxhbmsiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRl Y29yYXRpb246bm9uZSI+Ni4xPC9zcGFuPjwvYj48L2E+PGI+Lg0KIEFkZHJlc3MgQmxvY2sgQ29t cHJlc3Npb246PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5i c3A7Jm5ic3A7IENvbXByZXNzaW9uIG9mIGFkZHJlc3NlcyBpbiBhbiBBZGRyZXNzIEJsb2NrIGNv bnNpZGVycyBhZGRyZXNzZXMgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg Y29uc2lzdCBvZiBhIEhlYWQsIGEgTWlkLCBhbmQgYSBUYWlsLCB3aGVyZSBhbGwgYWRkcmVzc2Vz IGluIGFuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEFkZHJlc3MgQmxvY2sg aGF2ZSB0aGUgc2FtZSBIZWFkIGFuZCBUYWlsLCBidXQgZGlmZmVyZW50IE1pZHMuPG86cD48L286 cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J 4oCZZCBmaW5kIHRoaXMgc2VudGVuY2UgZWFzaWVyIHRvIHJlYWQgaWYgaXQgc3RhcnRlZCB3aXRo IOKAnENvbXByZXNzaW9uIG9mIGFkZHJlc3NlcyBpbiBhbiBBZGRyZXNzIEJsb2NrIGlzIHBvc3Np YmxlIHdoZW4gYWRkcmVzc2VzIGNvbnNpc3Qgb2YgYSBIZWFkLCBhIE1pZCBb4oCmXeKAnS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5O by4gVGhhdCdzIG1pc3NpbmcgdGhlIHBvaW50IGFuZCBtaXNsZWFkaW5nLiBBZGRyZXNzZXMgYXJl IGFsd2F5cyBjb25zaWRlcmVkIHRvIGhhdmUgdGhlIGhlYWQvbWlkL3RhaWwgZm9ybWF0LiBDb21w cmVzc2lvbiBpcyBwb3NzaWJsZSBpZiBlaXRoZXIgdGhlIGhlYWQgb3IgdGFpbCAob3IgYm90aCkg aXMgbm9uLWVtcHR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4qIGZyb20mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1tYW5ldC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi4xIiB0YXJnZXQ9Il9i bGFuayI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj42 LjE8L3NwYW4+PC9iPjwvYT48Yj4uDQogQWRkcmVzcyBCbG9jayBDb21wcmVzc2lvbjo8L2I+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyBQdXR0aW5nIGFkZHJlc3NlcyBpbnRvIGEgbWVzc2FnZSBlZmZp Y2llbnRseSBhbHNvIGhhcyB0byBpbmNsdWRlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PldoeSDigJ5oYXMgdG/igJw/IEnigJlkIHRoaW5rIHRoYXQgd291bGQgYmUgYSDigJ5tYXnigJwu IE11bHRpcGxlIEFkcmVzcyBCbG9ja3MgYW5kL29yIHJlb3JkZXJpbmcgZG9u4oCZdCBpbmNyZWFz ZSBlZmZpY2llbmN5IGluIGFsbCBwb3NzaWJsZSBjYXNlcy4uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhpbmsgdGhhdCdzIHRo ZSB3cm9uZyBjaGFuZ2UuIFJhdGhlciAmcXVvdDtpbmNsdWRlJnF1b3Q7IHNob3VsZCBiZSAmcXVv dDtjb25zaWRlciZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+KiBmcm9tJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtbWFuZXQtcmZjNTQ0NC11c2FnZS0wMyNzZWN0aW9uLTYuMiIgdGFyZ2V0 PSJfYmxhbmsiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9u ZSI+Ni4yPC9zcGFuPjwvYj48L2E+PGI+Lg0KIFRMVnM6PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWy4uLl0gVGhp cyBpcyBldmVuIHBvc3NpYmxlIGlmIHRoZSBNUFIgVExWIHNwZWNpZmllZCBpbjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPTFNSdjIgWzxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTgxIiB0YXJnZXQ9Il9ibGFuayIg dGl0bGU9IiZxdW90O1RoZSBPcHRpbWl6ZWQgTGluayBTdGF0ZSBSb3V0aW5nIFByb3RvY29sIHZl cnNpb24gMiZxdW90OyI+UkZDNzE4MTwvYT5dIGlzIGFkZGVkOyBidXQgaXQgaXMgbm90IHBvc3Np YmxlLCBpbiBnZW5lcmFsLCBpZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB0aGUgTElOS19NRVRSSUMgVExWIGlzIGFsc28gYWRkZWQuPG86cD48 L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldo eSBpcyBpdCBub3QgcG9zc2libGUgZm9yIHRoZSBsYXR0ZXI/IElmIHRoYXQgY291bGQgYmUgZXhw bGFpbmVkL2hpbnRlZCBhdCBpbiBhIGhhbGYgc2VudGVuY2UsIEkgdGhpbmsgaXTigJlkIGJlIGhl bHBmdWwgaW5mb3JtYXRpb24gdG8gaGF2ZSBpbiB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhdCdzIHZlcnkgaGFy ZCwgYW5kIG5vdCBqdXN0IGJlY2F1c2UgaXQncyBhIG5lZ2F0aXZlLiBJdCdzIHJlYWxseSBhbiBv YnNlcnZhdGlvbiB0aGF0IG1vdGl2YXRlcyB0aGUgZHVzY3Vzc2lvbi4gQSBoYWxmIHNlbnRlbmNl IHdvdWxkIEkgdGhpbmsgY29uZnVzZSBtb3JlIHRoYW4gaXQgZW5saWdodGVucyAoaXQncw0KIGJl Y2F1c2UgeW91IGhhdmUgdG9vIG1hbnkgY29uc3RyYWludHMgdG8gc2F0aXNmeSBhdCBvbmNlIC0g SSBkb3VidCB0aGF0IGhlbHBlZCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cHJlPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbiBhIHR5cGljYWwgY2FzZSB3aGVyZSBhPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExJTktf U1RBVFVTIFRMViB1c2VzIG9ubHkgdGhlIFZhbHVlcyBIRUFSRCBhbmQgU1lNTUVUUklDLCB3aXRo PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVu b3VnaCBhZGRyZXNzZXMsIHNvcnRlZCBhcHByb3ByaWF0ZWx5LCB0d28gc2luZ2xlIHZhbHVlIFRM VnMgY2FuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGJlIG1vcmUgZWZmaWNpZW50IHRoYW4gb25lIG11bHRpdmFsdWUgVExWLjxvOnA+PC9vOnA+ PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TYW1lIHRo aW5nOiB3aHk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SGVyZSBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIG9idmlvdXMgdG8gYW55b25l IHdobyBoYXMgbG9va2VkIGF0IDU0NDQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiogcmVnYXJkaW5nIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGZyb20m bmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5l dC1yZmM1NDQ0LXVzYWdlLTAzI3NlY3Rpb24tNi4zIiB0YXJnZXQ9Il9ibGFuayI+PGI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj42LjM8L3NwYW4+PC9iPjwv YT48Yj4uDQogVExWIFZhbHVlczwvYj4sIGkuZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwcmU+Jm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBUaGlzIGFwcHJvYWNoIHdhcyBzcGVjaWZpZWQgaW4gWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3MTg4IiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IkMuIGFuZCBULiBD bGF1c2VuIj5SRkM3MTg4PC9hPl0sIGFuZCByZXF1aXJlZCBmb3IgcHJvdG9jb2xzPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRoYXQgZXh0ZW5kIFs8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjEzMCIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVv dDtNb2JpbGUgQWQgSG9jIE5ldHdvcmsgKE1BTkVUKSBOZWlnaGJvcmhvb2QgRGlzY292ZXJ5IFBy b3RvY29sIChOSERQKSZxdW90OyI+UkZDNjEzMDwvYT5dIGFuZCBbPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzcxODEiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iJnF1b3Q7 VGhlIE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgUHJvdG9jb2wgdmVyc2lvbiAyJnF1b3Q7 Ij5SRkM3MTgxPC9hPl0uJm5ic3A7IEl0IGlzIGhlcmUgUkVDT01NRU5ERUQgdGhhdDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB0aGlzIGFwcHJvYWNoIGlzIGZvbGxvd2VkIHdo ZW4gZGVmaW5pbmcgYW55IEFkZHJlc3MgQmxvY2sgVExWIHRoYXQ8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgbWF5IGJlIHVzZWQgYnkgYSBwcm90b2NvbCB1c2luZyBbPGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU0NDQiIHRhcmdldD0iX2JsYW5rIiB0 aXRsZT0iJnF1b3Q7R2VuZXJhbGl6ZWQgTUFORVQgUGFja2V0L01lc3NhZ2UgRm9ybWF0JnF1b3Q7 Ij5SRkM1NDQ0PC9hPl0uPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlRoZSB0ZXJtIOKAnnRoaXMgYXBwcm9hY2jigJwgY29uZnVzZWQg bWUsIHNpbmNlIEkgaW5pdGlhbGx5ICZuYnNwO3Rob3VnaHQgaXQgbWVhbnQg4oCedGhlIGFwcHJv YWNoIGlzIHRvIHVzZSBVTlNQRUNJRklFRCBpbiBhIHdheSB0aGF0IG1ha2VzIHNlbnNl4oCcIHJh dGhlciB0aGFuIOKAnnRoZSBhcHByb2FjaCBpcyB0byB1c2UgVU5TUEVDSUZJRUTigJwuDQogTWF5 YmUgdGhhdCBjb3VsZCBiZSByZXdvcmRlZCB0byBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9m Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj5UaGUgVU5TUEVDSUZJRUQgVExW IGFuZCBpdHMgdXNhZ2Ugd2FzIHNwZWNpZmllZCBpbiBbUkZDNzE4OF3igKY8L3NwYW4+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPj88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5Oby4gVGhlcmUgaXMgbm8gVU5TUEVDSUZJRUQgVExWLiBUaGVyZSBpcyBhIHJlY29tbWVuZGF0 aW9uIHRvIGluY2x1ZGUgYW4gVU5TUEVDSUZJRUQgdmFsdWUgaW4gYSBUTFYuIEJ1dCByZWFsbHks IHdlJ3ZlIGRlc2NyaWJlZCB0aGlzIG9uY2UgaW4gNzE4OCwgaXQncyB0aGVyZSB0byByZWFkLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4qIHJlZ2Fy ZGluZyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMjc2VjdGlvbi02LjMiIHRhcmdldD0iX2JsYW5rIj48Yj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjYuMzwvc3Bhbj48 L2I+PC9hPjxiPi4NCiBUTFYgVmFsdWVzOjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHNlY29uZCBwYXJhZ3JhcGggaXMgYSBiaXQg Y29uZnVzaW5nIGFuZCBzZWVtcyB0byBleHBsYWluZyByb2dobHkgdGhlIHNhbWUgdGhpbmdzIGFz IHRoZSBmb3VydGggcGFyYWdyYXBocy4gSeKAmWQgcHJvcG9zZSB0byBtZXJnZSB0aGUgc2Vjb25k IGludG8gdGhlIGZvdXJ0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JJ20gbm90IHN1cmUgSSBleGFjdGx5IGFncmVlLCBidXQgdGhl IG9yZGVyaW5nIGluIHRoYXQgc2VjdGlvbiBjb3VsZCBiZSBpbXByb3ZlZC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+KiBmcm9tJm5ic3A7PGEgbmFt ZT0ibV84ODgyOTgyNzc3NjY2OTg2MTc1X21fMzk3NTQzMDQ3MzQ2MDMzMiI+PC9hPjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNh Z2UtMDMjc2VjdGlvbi02LjQiIHRhcmdldD0iX2JsYW5rIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjYuNDwvc3Bhbj48L2I+PC9hPjxiPi4NCiBBdXRv bWF0aW9uOjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPiZuYnNw OyZuYnNwOyBUaGUgcG9zc2libGUgZ2FpbiBkZXBlbmRzIG9uIHRoZSBlZmZpY2llbmN5PG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlIGNy ZWF0aW9uLDxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj50aGUgdGVybSDigJ50aGUgb3JpZ2luYWwgbWVzc2FnZSBjcmVhdGlvbuKAnCBz ZWVtcyBhIGJpdCBhbWJpZ3VvdXPigJMgZG9lcyB0aGlzIHJlZmVyIHRvIHRoZSBtZXNzYWdlIGFz IGNyZWF0ZWQgYnkgYW4gUkZDNTQ0NCBtZXNzYWdlIGJ1aWxkZXIgaW1wbGVtZW50YXRpb24/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ WWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5B ZGRpdGlvbmFsbHksIEknbSBjb25jZXJuZWQgYWJvdXQgdHdvIHRoaW5ncyB0aGF0ICphcmVu4oCZ dCogaW4gdGhlIGRyYWZ0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+KiAmbmJzcDtTb21lIG9mIHRoZSBBT0RWdjIgY28tYXV0aG9ycyBh bmQgbWUgaGF2ZSBhc2tlZCBmb3IgYSBsaXN0IG9mIOKAnmFzIGEgcHJvdG9jb2wsIHlvdSBjYW4g c2V0IGFsbCBvZiB0aGVzZSBmaWVsZHMgb2YgYSBtZXNzYWdlLCBidXQgcGxlYXNlIGxlYXZlIHRo ZSByZXN0IGFsb25l4oCcLCB3aGljaCB3b3VsZOKAmXZlIHNhdmVkDQogdXMgbWFueSBob3VycyBv ZiBkaXNjdXNzaW9ucyAoYW5kIEhlbm5pbmcgYSBsb3Qgb2YgdGltZSBzcGVudCBleHBsYWluaW5n IHRoZXNlIHRoaW5nc+KApikuIFRoZXNlIHJlcXVlc3RzIGhhdmUgYmVlbiBtZXQgd2l0aCBhIHJl ZnVzYWwgdG8gc3BlY2lmeSBhIGNvbmNyZXRlIEFQSSwgYXMgc3VjaCBhbiBlZmZvcnQgaXMgZGVw ZW5kZW50IG9uIG91dHNpZGUgZmFjdG9ycyBzdWNoIGFzIHByb2dyYW1taW5nIGxhbmd1YWdlIG9y IHNvZnR3YXJlIGFyY2hpdGVjdHVyZS4NCiBJIGFncmVlIHdpdGggdGhpcyBub3Rpb24sIGJ1dCBh IHByb2dyYW1taW5nLWxhbmd1YWdlIGRlcGVuZGVudCBBUEkgaXMgbm90IHdoYXQgd2XigJl2ZSBh c2tlZCBmb3IuIEnigJl2ZSB0cmllZCB0byBzdXBwbHkgYSBza2V0Y2ggb2Ygd2hhdCBJIGRpZCBh c2sgZm9yIGluIFsxXSwgYnV0IHVuZm9ydHVuYXRlbHkgSSBkaWRu4oCZdCBnZXQgYW4gYW5zd2Vy IChhbmQgYXMgZmFyIGFzIEkgY2FuIHNlZSBpdCwgdGhlIGRyYWZ0IHdhc27igJl0IGNoYW5nZWQg ZWl0aGVyKS4NCiBJIHN0aWxsIHRoaW5rIHRoYXQgc3VjaCBhIGxpc3QsIGluIHdoYXRldmVyIGZv cm0sIHdvdWxkIGJlIHZlcnkgaGVscGZ1bCBmb3IgZnV0dXJlIEludGVybmV0LURyYWZ0IGF1dGhv cnMgYW5kIEkgYWxzbyB0aGluayB0aGlzIHJlcXVlc3QgaXMgaW4gYWNjb3JkYW5jZSB3aXRoIHRo ZSBpbnRlbnRpb25zIHN0YXRlZCBpbiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3Vy aWVyIj4xLjEgSGlzdG9yeSBhbmQgUHVycG9zZSwmbmJzcDs8L3NwYW4+YW5kIEkgdGhpbmsNCiBp dCBzaG91bGQgYmUgaW5jbHVkZWQgaW4gdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vLiBUaGVyZSBhcmUgbWFu eSByZWFzb25zIHdoeSB3ZSdyZSBqdXN0IG5vdCB0b3VjaGluZyB0aGlzIG9uZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uZSBpcyB0 aGF0IGxhbmd1YWdlIGluZGVwZW5kZW5jZSBpcyBhIG1pcmFnZS4gSG93IHlvdSBnbyBhYm91dCB0 aGluZ3MgaXMgY29tcGxldGVseSBkaWZmZXJlbnQgaW4sIGZvciBleGFtcGxlIGFuIG9iamVjdCBv cmllbnRlZCBsYW5ndWFnZSB0aGFuIG9uZSB0aGF0IGlzbid0LiBTZWN0aW9uIDQuNSBzaG93cw0K IHRoYXQgdGhlcmUgYXJlIHF1aXRlIGRpZmZlcmVudCB3YXlzIG9mIGRvaW5nIHRoaW5ncyBldmVu IGdpdmVuIGEgZGVjaXNpb24gdG8gdXNlIGEgbWFwIGFwcHJvYWNoLCBhbmQgdGhlcmUgYXJlIG90 aGVyIGFwcHJvYWNoZXMgdGhhbiB0aGF0LiBJdCB3b3VsZCBiZSB3cm9uZyBhbmQgYmV5b25kIG91 ciBjb21wZXRlbmNlIHRvIHN1Z2dlc3Qgb25lIG9mIHRoZXNlIGFzICZxdW90O2Jlc3QmcXVvdDsu IFRoZXJlJ3MgcmVhc29ucyB0aGUgSUVURiBkb2Vzbid0IGRvIHRoaXMsDQogYW5kIHRoYXQncyBv bmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5QbHVzLCBmcmFua2x5LCB0aGUgd29yayBpdCB3b3VsZCB0YWtlIGlzIGJleW9uZCB3aGF0 IHdlIGNob29zZSB0byBzcGVuZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmx0O1NwZWFraW5nIGFz IGEgV0cgUGFydGljaXBhbnQmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ20gY29uZnVzZWQgKHdoaWNoIGlzIGFuIGFsdG9nZXRo ZXIgdG9vIGNvbW1vbiBvY2N1cnJlbmNlIHRoZXNlIGRheXMpLiBJIGdldCB0aGF0IHdlIGRvbid0 IHdhbnQgdG8gc3BlY2lmeSBhbiBBUEkuIEJ1dCBJIHRoaW5rIHRoZSBkaXNjdXNzaW9uIGFib3V0 IGZpZWxkcyBhIHByb3RvY29sIGNhbiBhbmQgY2FuJ3QNCiB0b3VjaCBpbiBhIG1lc3NhZ2VzIGlz IGEgZ29vZCB0aGluZyAtIGFuZCBpdCdzIG9uZSBzcG90IHdoZXJlIEksIHRvbywgZmluZCB0aGUg ZG9jdW1lbnQgd2FudGluZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvIHBhcmFwaHJhc2Ugc29tZXRoaW5nIEkndmUgc2Fp ZCBiZWZvcmUsIEkgYmVsaWV2ZSB0aGF0IFJGQyA1NDQ0IGNoYW5nZXMgdGhlIHJlbGF0aW9uc2hp cCB0aGF0IGEgcm91dGluZyBwcm90b2NvbCBoYXMgd2l0aCBhbiAmcXVvdDtpbnRlcmZhY2UmcXVv dDsuIEknbSBub3QgY29tbWVudGluZyBvbiB3aGV0aGVyIG9yIG5vdA0KIHRoYXQncyBhIGdvb2Qg dGhpbmcsIG9yIGEgYmFkIHRoaW5nIC0ganVzdCB0aGF0IGl0IGRvZXMgY2hhbmdlIHRoZSByZWxh dGlvbnNoaXAuIFRoaXMgY2hhbmdlIGhhcyBiZWVuIGF0IHRoZSByb290IG9mIHNvbWUgb2YgdGhl IGxvbmctcnVubmluZyBkaXNjdXNzaW9ucyBhcyB0byB3aGV0aGVyIHByb3RvY29scyB1bmRlciBk ZXZlbG9wbWVudCB3ZXJlIFJGQyA1NDQ0IGNvbXBsaWFudCBvciBub3QuIFRoZSBnb2FsIG9mIHRo aXMgZG9jdW1lbnQgYmVpbmcNCiB0byBlbGltaW5hdGUgKGl0J3MgYSBnb2FsLCBwcm9iYWJseSBu b3QgcmVhY2hhYmxlKSB0aG9zZSBkaXNjdXNzaW9ucywgSSdkIGxpa2UgdG8gc2VlIHRoYXQgaW5m b3JtYXRpb24gaW4gdGhlIGRvY3VtZW50IGluIHNvbWUgZm9ybS4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkknbSBpbnRlcmVz dGVkIGluIHNlZWluZyB0aGlzIGRvY3VtZW50IHByb2dyZXNzLCBhbmQgZXZlbnR1YWxseSBiZSBw dWJsaXNoZWQuIEkgdGhpbmsgaXQgd2lsbCBoZWxwIGZ1dHVyZSBwcm90b2NvbCBkZXNpZ25lcnMg dG8gYmV0dGVyIHVzZSBSRkMgNTQ0NC4gQnV0IEkgd291bGQgbGlrZSB0byBzZWUgKnNvbWV0aGlu ZyoNCiBhbG9uZyB0aGUgbGluZXMgb2Ygd2hhdCBMb3R0ZSBpcyByZXF1ZXN0aW5nLCBhcyBJIHRo aW5rIGl0IHdpbGwgaW1wcm92ZSB0aGUgZG9jLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U3RhbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4q IEFzIHRoZSBleGFjdCBydWxlcyBmb3IgdXNpbmcvc2V0dGluZyB0aGUgaG9wIGNvdW50ICZhbXA7 IGhvcC1saW1pdCBmaWVsZHMgYXJlIGN1cnJlbnRseSBiZWluZyBkaXNjdXNzZWQgdy8gcmVnYXJk IHRvIEFPRFZ2MiBpbiBhbm90aGVyIHRocmVhZCBbMl3igJMgc2hvdWxkIGEgZGVmaW5pdGl2ZSBh bnN3ZXIgdG8gdGhhdA0KIHF1ZXN0aW9uIGJlIHBhcnQgb2YgNTQ0NC11c2FnZT88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Zb3UgZG9u J3Qgd2FudCB0aGF0LiBCZWNhdXNlIGlmIHdlIGRpZCBzcGVjaWZ5IHRoYXQgeW91J2QgZmluZCB5 b3Vyc2VsZiBtb3JlIGNvbnN0cmFpbmVkIHRoYW4geW91IHdhbnQgdG8gYmUuIFRoZXJlIGlzIGEg ZGVzaWduIGludGVudCBkZXNjcmliZWQgaW4gNTQ0NCwgYnV0IGl0IGFzc3VtZXMgaW1tdXRhYmxl DQogbWVzc2FnZXMuIFdoaWNoIHlvdSBkb24ndCB3YW50LiBSZWFsbHksIHdlJ3JlIGRvaW5nIHlv dSBhIGZhdm91ciBieSBub3QgaW1wb3Npbmcgb24geW91LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkxvdHRlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5bMV0mbmJzcDs8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJl bnQvbXNnMTgwODIuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cxODA4Mi5odG1sPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5bMl0NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cx ODY3NC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTg2NzQuaHRtbDwvYT4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkFtIDA2LjA0LjIwMTYgdW0gMTk6MTQgc2NocmllYiBKdXN0aW4gRGVhbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmJlYmVtYXN0ZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YmViZW1hc3RlckBnbWFpbC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgY2hhaXJzIGFncmVlIHRoYXQgYSAzIHdlZWsgV0dM QyBpcyBhcHByb3ByaWF0ZS4mbmJzcDsgRXZlcnlvbmUgcGxlYXNlIHJlYWQgdGhlIGRyYWZ0IGVh cmx5IGFuZCBnZXQgY29tbWVudHMgaW4gZWFybHkgc28gdGhhdCB0aGV5IGNhbiBiZSBhZGRyZXNz ZWQgd2l0aGluIHRoZSBsYXN0IGNhbGwgcGVyaW9kLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBBcHIgNiwgMjAxNiBhdCA3 OjQwIEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNo cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxv dmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+T2J2aW91c2x5ICYjNDM7MSB0byB0aGUgcmVxdWVzdCBmb3IgV0dMQy48 YnI+DQo8YnI+DQpXaXRoIHJlZ2FyZCB0byB3aGF0J3MgY2hhbmdlZCwgdGVjaG5pY2FsbHkgdGhl IG9ubHkgc2lnbmlmaWNhbnQgdGhpbmcgaXMgdG8gbWFrZSBpdCBjbGVhciB0aGF0IGlmIGEgcHJv dG9jb2wgZGVsaXZlcnMgYSBtZXNzYWdlIHRvIHRoZSBtdWx0aXBsZXhlciwgdGhlIG11bHRpcGxl eGVyIG11c3QgcGFzcyBpdCBvbiB1bmNoYW5nZWQgdG8gdGhlIHByb3RvY29sIChhbm90aGVyIGlu c3RhbmNlIG9mLCBhdCBhbm90aGVyIHJvdXRlcikgdW5jaGFuZ2VkLg0KIFdpdGhvdXQgdGhhdCBu b3RoaW5nIHRoYXQgdGhlIHByb3RvY29sIGl0c2VsZiBjaG9vc2VzIHRvIGRvIHdpdGggcmVnYXJk IHRvIHNlY3VyaXR5IG1ha2VzIHNlbnNlLiBUaG91Z2ggdGhlIHByb3RvY29sIGNhbiBhbHRlcm5h dGl2ZWx5IGxldCB0aGUgbXVsdGlwbGV4ZXIgZG8gdGhlIHNlY3VyaXR5LCA3MTgyIGNhbiBiZSBp bXBsZW1lbnRlZCBpbiBlaXRoZXIgd2F5LiBUaGlzIGlzbid0IHJlYWxseSBuZXcsIGJ1dCBpdCB3 YXNuJ3QgZm9ybWFsbHkNCiBzcGVsbGVkIG91dC4gSXQncyBwcmVzZW50ZWQgYXMgcGFydCBvZiBz cGVsbGluZyBvdXQgbXVsdGlwbGV4ZXIgcnVsZXMgbW9yZSBjYXJlZnVsbHkuPGJyPg0KPGJyPg0K QnV0IHdoYXQgYWJvdXQgbWVzc2FnZSBvcHRpbWlzYXRpb24/IFRoYXQncyBhIGZ1bmN0aW9uIG9m IGNvbnN0cnVjdGluZyBhIDU0NDQgbWVzc2FnZSwgbm90IHRoZSBtdWx0aXBsZXhlciwgYW5kIGlz IGRvd24gdG8gdGhhdCA1NDQ0IGluY2x1ZGVzIHR3byB0aGluZ3MgLSBwYWNrZXQvbWVzc2FnZSBz dHJ1Y3R1cmUgKGFuZCBpbXBsaWNpdGx5LCBhbmQgaW4gcHJldHR5IG11Y2ggYW55IGltcGxlbWVu dGF0aW9uIEkgd291bGQgZXhwZWN0IHRvIHNlZSwNCiBhIHBhcnNlciBhbmQgYnVpbGRlciBmb3Ig dGhhdCBzdHJ1Y3R1cmUpIGFuZCB0aGUgbXVsdGlwbGV4ZXIuIFNvIHdlIHRvb2sgdGhlIG9wcG9y dHVuaXR5IHRvIHNlcGFyYXRlIG91dCBtb3JlIGNsZWFybHkgYSBkaXNjdXNzaW9uIG9mIHRoZSB0 d28sIHdoaWNoIHdlIHRoaW5rIHdpbGwgYmUgaGVscGZ1bC48YnI+DQo8YnI+DQotLTxicj4NCkNo cmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJB RSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KPGJyPg0KVDogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUy OTEyNDUlMjAyNDIxOTQiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzQ0ICgwKTEyNDUgMjQyMTk0PC9h PiAmbmJzcDt8ICZuYnNwO0U6DQo8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwv YT48YnI+DQo8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9y ZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhI Ti48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIiB0YXJnZXQ9Il9i bGFuayI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9hPjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQg SW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2Fs ZXMgTm86IDAxMzM3NDUxPGJyPg0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQ YXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogbWFuZXQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bWFu ZXQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0LWJvdW5jZXNAaWV0Zi5v cmc8L2E+XSBPbiBCZWhhbGYgT2YgVWxyaWNoIEhlcmJlcmc8YnI+DQpTZW50OiAwNSBBcHJpbCAy MDE2IDIwOjA4PGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm1hbmV0QGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFttYW5ldF0gV0dMQyBy ZXF1ZXN0IGZvciBkcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDM8YnI+DQo8YnI+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBU aGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0 aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC48YnI+DQpD b25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywg b3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPGJyPg0KRm9sbG93IHRoZSAnUmVwb3J0IFN1 c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBvbiBy ZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy48YnI+DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCioqKiBX QVJOSU5HICoqKjxicj4NCkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVz IGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCkhpLDxicj4NCjxicj4NCkFzIHlvdSBo YXZlIHNlZW4sIHdlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHJldmlzaW9uIG9mIDU0NDQtdXNhZ2Uu IFRoZSBhdXRob3JzIGZlZWwgY29tZm9ydGFibGUgdGhhdCB3ZSBoYXZlIGFkZHJlc3NlZCBhbGwg aXNzdWVzIGJ5IHRoaXMgdmVyc2lvbiwgYW5kIHdvdWxkIGxpa2UgdG8gYXNrIHRoZSBXRyBjaGFp cnMgdG8gaXNzdWUgYSBXR0xDIG9uIHRoaXMgZG9jdW1lbnQuIFdoaWxlIGl0IGlzIGEgZmFpcmx5 IHNob3J0IGRvY3VtZW50LCBnaXZlbg0KIHRoYXQgaXQgaXMgSUVURiB3ZWVrIGZvciBzb21lLCB3 ZSdkIHN1Z2dlc3QgdGhhdCBhIDMtNCB3ZWVrIFdHTEMgd291bGQgYmUgYXBwcm9wcmlhdGUuPGJy Pg0KPGJyPg0KQmVzdCByZWdhcmRzPGJyPg0KVWxyaWNoPGJyPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5t YW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KVGhpcyBlbWFpbCBhbmQg YW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPg0KcmVj aXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQ8YnI+DQpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFu ZCBub3RpZnkgdGhlIHNlbmRlci48YnI+DQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBp dCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPg0KZGlzdHJpYnV0ZSBpdHMgY29u dGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t YW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbWFuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5l dDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0QGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21hbmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AEC54GLKXM0002VGREEN_-- From nobody Tue Apr 19 02:09: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 C074412D695 for ; Tue, 19 Apr 2016 02:09:33 -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 3Iqa4-sa5RYk for ; Tue, 19 Apr 2016 02:09:31 -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 3128212D936 for ; Tue, 19 Apr 2016 02:09:31 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,506,1454976000"; d="scan'208,217"; a="33805322" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 19 Apr 2016 10:09:29 +0100 X-IronPort-AV: E=Sophos;i="5.24,506,1454976000"; d="scan'208,217";a="114545900" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 19 Apr 2016 10:09:30 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Tue, 19 Apr 2016 10:09:29 +0100 From: "Dearlove, Christopher (UK)" To: Jiazi YI Thread-Topic: [manet] Review of draft-ietf-manet-rfc5444-usage-03 Thread-Index: AQHRmYPi83qX1zKGTE6pZZRlAgZtP5+P2bGggABrqgCAALwyoA== Date: Tue, 19 Apr 2016 09:09:29 +0000 Message-ID: References: <4D088849-F444-4FA3-B0AE-0FD2078A76F5@gmail.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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AEC6CGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Review of draft-ietf-manet-rfc5444-usage-03 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, 19 Apr 2016 09:09:33 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AEC6CGLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 UkVDT01NRU5ERUQgKHdoaWNoIGlzIHRoZSBzYW1lIGFzIFNIT1VMRCkgbWVhbnMgZG8gdGhpcyB1 bmxlc3MgeW91IHVuZGVyc3RhbmQgdGhpcywgYW5kIGtub3cgd2h5IHlvdSBhcmUgbm90IGRvaW5n IGl0LCB3aXRoIGEgZ29vZCByZWFzb24uDQoNClRoYXQgcHJldHR5IG11Y2ggY292ZXJzIHRoZSBz Y2VuYXJpby4gTW9kaWZ5aW5nIG1lc3NhZ2VzIGhhcyBhIHNpZ25pZmljYW50IGRvd25zaWRlLCBz byBkb27igJl0IGRvIGl0IHVubGVzcyB5b3UgbmVlZCB0by4NCg0KUmVhY3RpdmUgcHJvdG9jb2xz IHdpdGggbGluayBtZXRyaWNzIGFyZSBhIGNhc2Ugd2hlcmUgcGVvcGxlIGhhdmUgZG9uZSB0aGF0 IHRyYWRlb2ZmIGFuZCBtYWRlIGEgZGVjaXNpb24gdG8gZG8gb3RoZXJ3aXNlLiBUaGF0IGZpdHMg dGhlIFJFQ09NTUVOREVEIHBhdHRlcm4uIChUaGVyZeKAmXMgbW9yZSB0aGF0IHRoZXkgY291bGQg ZG8sIHN1Y2ggYXMgY29udHJvbGxpbmcgdGhhdCB2YXJpYXRpb24sIGJ1dCB0aGF04oCZcyByZWFs bHkgYmV5b25kIG91ciBzY29wZSBoZXJlLikNCg0KQnV0IGhhdmluZyB0aGlzIGFzIFJFQ09NTUVO REVEIHNob3VsZCBtYWtlIHBlb3BsZSBkZXZpc2luZyBvdGhlciBwcm90b2NvbHMgc3RvcCBhbmQg dGhpbmsgYmVmb3JlIGRvaW5nIGl0IGdyYXR1aXRvdXNseS4NCg0KKFBlcnNvbmFsbHkgSSBjb3Vs ZCBsaXZlIHdpdGhvdXQgdGhlIHN0cm9uZ2x5IGJlZm9yZSBSRUNPTU1FTkRFRCwgYnV0IGF0IGxl YXN0IG9uZSBvdGhlciBhdXRob3Igd2FudGVkIGl0IHRoZXJlLCBhbmQgSSBkaWRu4oCZdCBkZW11 ci4pDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVl cg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoN CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kg UGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5 c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBB cHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxl cyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywg R3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTogeWkuamlhemlAZ21haWwuY29tIFtt YWlsdG86eWkuamlhemlAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgSmlhemkgWUkNClNlbnQ6IDE4 IEFwcmlsIDIwMTYgMjM6NTANClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IEpv aG4gRG93ZGVsbDsgbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFJldmlldyBv ZiBkcmFmdC1pZXRmLW1hbmV0LXJmYzU0NDQtdXNhZ2UtMDMNCg0KDQoqKiogV0FSTklORyAqKioN ClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBl aXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVy IGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFu eSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZs YWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGlj ayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3Vy aXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0 aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDov L2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0 cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQoN Cg0KPiAiSXQgaXMgc3Ryb25nbHkgUkVDT01NRU5ERUQgdGhhdCBtZXNzYWdlcyBhcmUgbm90IG1v ZGlmaWVkIGluIHRoZSBsYXR0ZXIgY2FzZS7igJ0gSeKAmW0gbm90IGZvbGxvd2luZyB0aGlzLiBX aHkgaXMgaXQgb2sgdG8gbW9kaWZ5IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIGltcGFjdGVkIGJ5 IGFuIGV4dGVuc2lvbiB0byB0aGUgaG9zdGVkIHByb3RvY29sLCBidXQgaXTigJlzIG5vdCBvayB0 byBtb2RpZnkgbWVzc2FnZXMgdGhhdCBoYXZlIG5vdCBiZWVuIHN1YmplY3QgdG8gZXh0ZW5zaW9u IHByb2Nlc3Npbmc/IFdoYXQgZG9lcyDigJhtb2RpZnnigJkgbWVhbiBpbiB0aGlzIGNvbnRleHQg YW55d2F5Pw0KDQpCZWNhdXNlIG9uZSBpcyBpbiB0aGUgZW5kcG9pbnQsIG9uZSBpcyBub3QuIElm IHlvdSBtb2RpZnkgbWVzc2FnZXMgYXQgdGhlIGVuZHBvaW50IChlLmcuIE9MU1J2MiBhZGRpbmcg TVBScyB0byBOSERQJ3MgSEVMTE8gbWVzc2FnZXMpIHlvdSBjYW4gYWRkIGFuIElDViBhZnRlcndh cmRzIGFuZCBzdGlsbCBnZXQgZW5kIHRvIGVuZCBzZWN1cml0eS4gSWYgeW91IG1vZGlmeSBpbiBi ZXR3ZWVuIHRoZSB0d28gdGhlbiB5b3UgY2FuJ3QuDQoNCkkgY2FuIHVuZGVyc3RhbmQgZm9yIHRo ZSBwdXJwb3NlIG9mIGludGVncml0eSBjaGVja2luZywgd2UgY291bGRuJ3QgbW9kaWZ5IHdoZW4g dGhlIG1lc3NhZ2VzIGFyZSBiZWluZyBmb3J3YXJkZWQuDQpCdXQgUkZDNTQ0NCBpcyBkZXNpZ25l ZCBmb3IgcmVhY3RpdmUgcHJvdG9jb2wgYWxzbywgd2hpY2ggKGluIG1vc3QgY2FzZXMpLCBieSBu YXR1cmUsIHdpbGwgbW9kaWZ5IHRoZSBtZXNzYWdlIGluIGludGVybWVkaWF0ZSByb3V0ZXJzLiBJ dCBzb3VuZHMgYSBiaXQgc3RyYW5nZSBmb3IgbWUgaWYgc3VjaCBvcGVyYXRpb24gaXMgbm90IHJl Y29tbWVuZGVkIGJ5IFJGQzU0NDQuDQoNCkppYXppDQoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBp ZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQKcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5 IHRoZSBzZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVy cG9zZSBub3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVy IHBlcnNvbi4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioK --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AEC6CGLKXM0002VGREEN_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJFQ09NTUVOREVEICh3aGljaCBpcyB0aGUgc2FtZSBhcyBT SE9VTEQpIG1lYW5zIGRvIHRoaXMgdW5sZXNzIHlvdSB1bmRlcnN0YW5kIHRoaXMsIGFuZCBrbm93 IHdoeSB5b3UgYXJlIG5vdCBkb2luZyBpdCwgd2l0aCBhIGdvb2QgcmVhc29uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhhdCBwcmV0dHkgbXVjaCBjb3ZlcnMgdGhlIHNjZW5hcmlvLiBNb2RpZnlpbmcgbWVzc2FnZXMg aGFzIGEgc2lnbmlmaWNhbnQgZG93bnNpZGUsIHNvIGRvbuKAmXQgZG8gaXQgdW5sZXNzIHlvdSBu ZWVkIHRvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+UmVhY3RpdmUgcHJvdG9jb2xzIHdpdGggbGluayBtZXRyaWNzIGFy ZSBhIGNhc2Ugd2hlcmUgcGVvcGxlIGhhdmUgZG9uZSB0aGF0IHRyYWRlb2ZmIGFuZCBtYWRlIGEg ZGVjaXNpb24gdG8gZG8gb3RoZXJ3aXNlLiBUaGF0IGZpdHMgdGhlIFJFQ09NTUVOREVEIHBhdHRl cm4uDQogKFRoZXJl4oCZcyBtb3JlIHRoYXQgdGhleSBjb3VsZCBkbywgc3VjaCBhcyBjb250cm9s bGluZyB0aGF0IHZhcmlhdGlvbiwgYnV0IHRoYXTigJlzIHJlYWxseSBiZXlvbmQgb3VyIHNjb3Bl IGhlcmUuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+QnV0IGhhdmluZyB0aGlzIGFzIFJFQ09NTUVOREVEIHNob3VsZCBt YWtlIHBlb3BsZSBkZXZpc2luZyBvdGhlciBwcm90b2NvbHMgc3RvcCBhbmQgdGhpbmsgYmVmb3Jl IGRvaW5nIGl0IGdyYXR1aXRvdXNseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPihQZXJzb25hbGx5IEkgY291bGQgbGl2 ZSB3aXRob3V0IHRoZSBzdHJvbmdseSBiZWZvcmUgUkVDT01NRU5ERUQsIGJ1dCBhdCBsZWFzdCBv bmUgb3RoZXIgYXV0aG9yIHdhbnRlZCBpdCB0aGVyZSwgYW5kIEkgZGlkbuKAmXQgZGVtdXIuKTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9vOnA+PC9z cGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0 b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3 RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdE Ij5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAm bmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wgJm5ic3A7PGI+RToNCjwvYj48YSBo cmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3Zl QGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBU ZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48 YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHlsZT0i Y29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRl ZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdp c3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBH VTIgN1lQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IHlpLmppYXppQGdtYWlsLmNvbSBbbWFpbHRvOnlpLmppYXppQGdt YWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmlhemkgWUk8YnI+DQo8Yj5TZW50OjwvYj4g MTggQXByaWwgMjAxNiAyMzo1MDxicj4NCjxiPlRvOjwvYj4gRGVhcmxvdmUsIENocmlzdG9waGVy IChVSyk8YnI+DQo8Yj5DYzo8L2I+IEpvaG4gRG93ZGVsbDsgbWFuZXRAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtbWFuZXQtcmZj NTQ0NC11c2FnZS0wMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEu MHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxp Z246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl Ij4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVz c2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJv bSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3Ms IG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+ PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdz PC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUs DQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3 ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhl cmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMz Mzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGlj aW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0 ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUy MFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bh bj48L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcy Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCiZndDsg JnF1b3Q7SXQgaXMgc3Ryb25nbHkgUkVDT01NRU5ERUQgdGhhdCBtZXNzYWdlcyBhcmUgbm90IG1v ZGlmaWVkIGluIHRoZSBsYXR0ZXIgY2FzZS7igJ0gSeKAmW0gbm90IGZvbGxvd2luZyB0aGlzLiBX aHkgaXMgaXQgb2sgdG8gbW9kaWZ5IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIGltcGFjdGVkIGJ5 IGFuIGV4dGVuc2lvbiB0byB0aGUgaG9zdGVkIHByb3RvY29sLCBidXQgaXTigJlzIG5vdCBvayB0 byBtb2RpZnkgbWVzc2FnZXMgdGhhdCBoYXZlIG5vdCBiZWVuIHN1YmplY3QNCiB0byBleHRlbnNp b24gcHJvY2Vzc2luZz8gV2hhdCBkb2VzIOKAmG1vZGlmeeKAmSBtZWFuIGluIHRoaXMgY29udGV4 dCBhbnl3YXk/PGJyPg0KPGJyPg0KQmVjYXVzZSBvbmUgaXMgaW4gdGhlIGVuZHBvaW50LCBvbmUg aXMgbm90LiBJZiB5b3UgbW9kaWZ5IG1lc3NhZ2VzIGF0IHRoZSBlbmRwb2ludCAoZS5nLiBPTFNS djIgYWRkaW5nIE1QUnMgdG8gTkhEUCdzIEhFTExPIG1lc3NhZ2VzKSB5b3UgY2FuIGFkZCBhbiBJ Q1YgYWZ0ZXJ3YXJkcyBhbmQgc3RpbGwgZ2V0IGVuZCB0byBlbmQgc2VjdXJpdHkuIElmIHlvdSBt b2RpZnkgaW4gYmV0d2VlbiB0aGUgdHdvIHRoZW4geW91IGNhbid0LjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjYW4gdW5kZXJz dGFuZCBmb3IgdGhlIHB1cnBvc2Ugb2YgaW50ZWdyaXR5IGNoZWNraW5nLCB3ZSBjb3VsZG4ndCBt b2RpZnkgd2hlbiB0aGUgbWVzc2FnZXMgYXJlIGJlaW5nIGZvcndhcmRlZC4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBSRkM1NDQ0 IGlzIGRlc2lnbmVkIGZvciByZWFjdGl2ZSBwcm90b2NvbCBhbHNvLCB3aGljaCAoaW4gbW9zdCBj YXNlcyksIGJ5IG5hdHVyZSwgd2lsbCBtb2RpZnkgdGhlIG1lc3NhZ2UgaW4gaW50ZXJtZWRpYXRl IHJvdXRlcnMuIEl0IHNvdW5kcyBhIGJpdCBzdHJhbmdlIGZvciBtZSBpZiBzdWNoIG9wZXJhdGlv biBpcyBub3QgcmVjb21tZW5kZWQgYnkgUkZDNTQ0NC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Smlhemk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cD4qKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxi cj4KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhl IGludGVuZGVkPGJyPgpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJv bSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPgpZb3Ugc2hvdWxkIG5vdCBj b3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPgpkaXN0 cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4KKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8 L3A+PC9ib2R5Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AEC6CGLKXM0002VGREEN_-- From nobody Tue Apr 19 06:05:31 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 0376D12D5BE for ; Tue, 19 Apr 2016 06:05:30 -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 zXEKdA8G_G76 for ; Tue, 19 Apr 2016 06:05:28 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 1B44112D838 for ; Tue, 19 Apr 2016 06:05:28 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id 127so4728729wmz.0 for ; Tue, 19 Apr 2016 06:05: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=2JtupakeJ/9O2X4NSEYCTIYXVtLuROcOPyitQbEUxyU=; b=PF+tQr/1FkzRmBx6BHXu3NLBOuLo6CYH1PQ+Qgt2TyHUy9FMVcZzr2RmH79yXyxMsH y4IioNgtLoX7dSKN/Vsa2LJyeQ7aNxDsabpBxLMbCoCQ4nakkJslkRPpOems4tlhWnZF Io0MTSd7Kn3POZ1vM1xgfSYr9e2jGp0tpVtER0iYRuQ5fcGwPbzp1gIQB+GtQafByMzu HKXCrp5RlU4r6eZJ2ywDqDceCqsocaAugLoF8dGTjXQqVhnOc4Wf4x5ltUAooBiOgd6Q qCFKwtPgk0AS0p28LwuMr1Ih+LUN0lY+Ul357IPXnLtjApn9sDTsaIie9eY+8Tg3M23b ZcLw== 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=2JtupakeJ/9O2X4NSEYCTIYXVtLuROcOPyitQbEUxyU=; b=A260tfOFZZByOenfYPjgaUTPIW2qvdrwteT+RQjAVlEEpfZZCI+ixSI23OR6JP1ood kDK+JYMVpwEWMTllPWpwZX0rpaGgDZSTorxczdqAxHsYsfdJQvf82z6t3gIHQqreU24s 0COfXZMrAii8VoiaVvk7G0T5bnbnPcJYe7Rbvse82oP42IBr1U8eykFWfJRR6yJgCUuz oshENjczTSuzE3Fm6mZbSDSrFEzqBpUIgIO5zxWGz5RknFsHwl5tQw8CTC/MNI3LCCUk Vtoyc/XsPeAHjuI8g9bSRqBi3VkYT63Da+OnjjrYLGlUx9Pbx2nF76hMzC2/G31wYCe3 hGEA== X-Gm-Message-State: AOPr4FU0YEhdkgz1FANkm2aOaRl7DYtwK3GhemIWU8hR8mB+TE9i5NDx4Ro7IRF2lj8XCzP12TvL0ApowDB2XA== MIME-Version: 1.0 X-Received: by 10.28.178.148 with SMTP id b142mr3794691wmf.58.1461071126057; Tue, 19 Apr 2016 06:05:26 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.153.166 with HTTP; Tue, 19 Apr 2016 06:05:26 -0700 (PDT) Date: Tue, 19 Apr 2016 15:05:26 +0200 X-Google-Sender-Auth: 3iw0HET1vVKg8xUtreiiCeFrjvw Message-ID: From: Jiazi YI To: manet Content-Type: multipart/alternative; boundary=001a11443f0075de5e0530d62179 Archived-At: Subject: [manet] Comments on 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: Tue, 19 Apr 2016 13:05:30 -0000 --001a11443f0075de5e0530d62179 Content-Type: text/plain; charset=UTF-8 Hi, I just had a review on the rfc5444-usage draft (-03). I think the draft is in good shape and easy to understand (I need to note here that I haven been working with RFC5444 in the past a few years, so I don't have a pair of fresh eyes on it). section 4.2, bullet 1: Messages MAY also be forwarded by their owning protocol. > It is strongly RECOMMENDED that messages are not modified in the > latter case. I have mentioned this in another thread, regarding the reactive protocol. I think it's OK to put a RECOMMEND/SHOULD here (probably not "strongly"?), but it would be great if we can put a few words explaining the tradeoffs. bullet 5: > If requested by a protocol, the multiplexer SHOULD, and otherwise > MAY, include a Packet Sequence Number in the packet. Although it's a MAY/SHOULD here, I think we need to be clear that the existence of packet sequence number must be consistent, i.e., the multiplexer must not add #seq in this transmission, and omit the #seq in the next transmission (because of MTU limitation, etc.). still section 4.2: The demultiplexer MUST remove any TLVs added to the message by the > multiplexer. The message MUST be passed on to the protocol > exactly as received from (another instance of) the protocol. How a demultiplexer know if a TLV is added by another multiplexer, especially we have different implementations? Is there any flag or signals that we can count on? section 4.5: A message (excluding the Message Header) can thus be represented by > two, possibly multivalued, maps: > o Message: (extended type) -> (length, value) > o Address: (address, extended type) -> (length, value) Why only extended type here (which is optional)? What about the tlv-type? And one more question: Is it possible to build relationship between two addresses in the address block? For example, we have - address-A, address-B, address-C with tlv-type-X, - address-D, address-E, address-F with tlv-type-Y. Can we set up a relation saying that address-A is related to address-D, address-E? For example, the gateway A supports source address with prefix D, E? We can do so by encoding the addresses as data in TLVs, but it seems that it's not recommended. regards Jiazi --001a11443f0075de5e0530d62179 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I just had a review on the rf= c5444-usage draft (-03).=C2=A0

I think the draft i= s in good shape and easy to understand (I need to note here that I haven be= en working with RFC5444 in the past a few years, so I don't have a pair= of fresh eyes on it).

section 4.2,

=
bullet 1:

=C2=A0Messag= es MAY also be forwarded by their owning protocol.
=C2=A0 =C2=A0 =C2=A0 = It is strongly RECOMMENDED that messages are not modified in the
=C2=A0 = =C2=A0 =C2=A0 latter case.

I have mentioned= this in another thread, regarding the reactive protocol. I think it's = OK to put a RECOMMEND/SHOULD here (probably not "strongly"?), but= it would be great if we can put a few words explaining the tradeoffs.=C2= =A0

bullet 5:
=C2=A0
If requested by a protocol, the multiplexer SHOULD, and otherwise<= br>=C2=A0 =C2=A0 =C2=A0 MAY, include a Packet Sequence Number in the packet= .=C2=A0

Although it's a MAY/SHOULD here= , I think we need to be clear that the existence of packet sequence number = must be consistent, i.e., the multiplexer must not add #seq in this transmi= ssion, and omit the #seq in the next transmission (because of MTU limitatio= n, etc.).=C2=A0

still section 4.2:

<= /div>
The demultiplexer MUST remove any TLVs added to = the message by the
=C2=A0 =C2=A0 =C2=A0 multiplexer.=C2=A0 The message M= UST be passed on to the protocol
=C2=A0 =C2=A0 =C2=A0 exactly as receive= d from (another instance of) the protocol.

= How a demultiplexer know if a TLV is added by another multiplexer, especial= ly we have different implementations? Is there any flag or signals that we = can count on? =C2=A0


section = 4.5:

=C2=A0 =C2=A0A message (excl= uding the Message Header) can thus be represented by
=C2=A0 =C2=A0two, p= ossibly multivalued, maps:
=C2=A0 =C2=A0o =C2=A0Message: (extended type)= -> (length, value)
=C2=A0 =C2=A0o =C2=A0Address: (address, extended = type) -> (length, value)

Why only = extended type here (which is optional)? What about the tlv-type?
=
And one more question:
Is it possible to build rel= ationship between two addresses in the address block? For example, we have= =C2=A0
=C2=A0 =C2=A0 - address-A, address-B, address-C with tlv-t= ype-X,=C2=A0
=C2=A0 =C2=A0 - address-D, address-E, address-F with= tlv-type-Y.=C2=A0

Can we set up a relation saying= that address-A is related to address-D, address-E? For example, the gatewa= y A supports source address with prefix D, E?=C2=A0
We can do so = by encoding the addresses as data in TLVs, but it seems that it's not r= ecommended.=C2=A0

regards

Jiazi
=C2=A0


--001a11443f0075de5e0530d62179-- From nobody Tue Apr 19 08:06:32 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 DBAA212DFAD for ; Tue, 19 Apr 2016 08:06:30 -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 AXku2a4O30eU for ; Tue, 19 Apr 2016 08:06:28 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 C8C9C12DF97 for ; Tue, 19 Apr 2016 08:06:27 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id r78so11780740oie.0 for ; Tue, 19 Apr 2016 08:06:27 -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=V1xlphfl72M2bMxYe3Y4/Nkc4tUVZq/5J2NIaBN5+M0=; b=pwzBnnBTqu2eq8c1aRovVeCbrl9PVvMxo49KKlEjRwQ7kjcXb6yrtzHsFOb3WfBBeh 4rTHCT5/XpE/w3gbc6eCdSDlpxYQG1yf2feg+166afayCtW1WQaR+xkM0exXnW5nRf3y CUQ61qmOD88quG/qcwF940kFb6jGq7FoN6NIcUrhYWxrlqlZECVXKlq/N1aIY9tFejmq NqkNGyVhk2NMsHUEJwfQhdXFl2/DYjAEMpCbc4IR3QHAnEf71xkeMTprPddnnWSeEkLF dwr/Ca9dOviIEBiJ3RToyOgtItNgl40i3eSy67RRh4TqKTnEL2bYZstNzTEJbWcX8NI+ glgw== 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=V1xlphfl72M2bMxYe3Y4/Nkc4tUVZq/5J2NIaBN5+M0=; b=UBc4iOK3hKEQeh+L/YbE/4hKIFJnF2l5HeCisacr73QAZWghSMTR76S+e3Q01xP2jj ZYg0OFMYKFKDjrOqFqApPfluRKTt0eTNKl/Bk5sefguk3JZdbKccfIVtM58c4FyVUBU+ vsgKQoLUyqUm8hi/j9G6X2xc7rjWYT1075ejqKjwj9a0lEm+RpIu0x4KETboijri7aXy kb7whYG1ZWz7e/2BAmKIjtX61c74N8pxZJAEgYy50c5vHaRE88Ui6MQQasT10DBqCWgL /aQ/5iOKGpRZEgK5sn85WVrwWF636nSosnWWm38wQK6JJOIK7VpymCwo1Mt8APCp/iVs Phzg== X-Gm-Message-State: AOPr4FX4rcZb5mlj7losm8u6s/tu4UAvD5loCoBvyF0fyAxbN6bAn2CgNJc06pM97GKTGutbU0S+92PsKrG2NA== X-Received: by 10.202.98.133 with SMTP id w127mr1267197oib.136.1461078387201; Tue, 19 Apr 2016 08:06:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.13.200 with HTTP; Tue, 19 Apr 2016 08:05:57 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Tue, 19 Apr 2016 17:05:57 +0200 Message-ID: To: Jiazi YI Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: manet Subject: Re: [manet] Comments on 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: Tue, 19 Apr 2016 15:06:31 -0000 On Tue, Apr 19, 2016 at 3:05 PM, Jiazi YI wrote: >> Messages MAY also be forwarded by their owning protocol. >> It is strongly RECOMMENDED that messages are not modified in the >> latter case. > > > I have mentioned this in another thread, regarding the reactive protocol. I > think it's OK to put a RECOMMEND/SHOULD here (probably not "strongly"?), but > it would be great if we can put a few words explaining the tradeoffs. I think this paragraph has been written in terms of "protocol independent forwarding of messages", based on the message header. What AODVv2 is doing is to generate a new message mostly based on the old message. > bullet 5: > >> >> If requested by a protocol, the multiplexer SHOULD, and otherwise >> MAY, include a Packet Sequence Number in the packet. > > > Although it's a MAY/SHOULD here, I think we need to be clear that the > existence of packet sequence number must be consistent, i.e., the > multiplexer must not add #seq in this transmission, and omit the #seq in the > next transmission (because of MTU limitation, etc.). the multiplexer is the only one that can verify the MTU limitations anyways, especially if a message is forwarded. Because of this a protocol should not make messages too large, they must fit into the smallest MTU in the whole Mesh (including packet level overhead). > still section 4.2: > >> The demultiplexer MUST remove any TLVs added to the message by the >> multiplexer. The message MUST be passed on to the protocol >> exactly as received from (another instance of) the protocol. > > > How a demultiplexer know if a TLV is added by another multiplexer, > especially we have different implementations? Is there any flag or signals > that we can count on? it cannot know. > section 4.5: > >> A message (excluding the Message Header) can thus be represented by >> two, possibly multivalued, maps: >> o Message: (extended type) -> (length, value) >> o Address: (address, extended type) -> (length, value) > > > Why only extended type here (which is optional)? What about the tlv-type? This is the TLV type we are talking about a message contains a mapping from (extended TLV type) to (TLV length, TLV value) > And one more question: > Is it possible to build relationship between two addresses in the address > block? For example, we have > - address-A, address-B, address-C with tlv-type-X, > - address-D, address-E, address-F with tlv-type-Y. there is no syntactic way to do this... you can only do this on semantic level by defining a TLV that announce "pairs/groups" of addresses with its value. And its not nice to parse. > Can we set up a relation saying that address-A is related to address-D, > address-E? For example, the gateway A supports source address with prefix D, > E? > We can do so by encoding the addresses as data in TLVs, but it seems that > it's not recommended. That is exactly what I am doing in my source-IP based routing extension for OLSRv2. Henning Rogge From nobody Tue Apr 19 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 2841D12EE19 for ; Tue, 19 Apr 2016 11:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 NJnBMe8dEmyH for ; Tue, 19 Apr 2016 11:05:52 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 993DE12D82A for ; Tue, 19 Apr 2016 11:05:52 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.67]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1asa1t-0004Fn-W3 for manet@ietf.org; Tue, 19 Apr 2016 14:05:42 -0400 References: <20160419052352.11079.76705.idtracker@ietfa.amsl.com> To: Mobile Ad Hoc Networks mailing list From: "Charles E. Perkins" Organization: Blue Skies X-Forwarded-Message-Id: <20160419052352.11079.76705.idtracker@ietfa.amsl.com> Message-ID: <5716736E.9020401@computer.org> Date: Tue, 19 Apr 2016 11:05:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160419052352.11079.76705.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080701040109080902060105" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac741e6b4ed6792273618d4a529328d77f9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: [manet] Fwd: New Version Notification for draft-perkins-manet-rsw-00.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, 19 Apr 2016 18:05:54 -0000 This is a multi-part message in MIME format. --------------080701040109080902060105 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello folks, This draft presents the RSW additive link metric from IEEE 802.15.10 along with information about how to use it with AODVv2. It basically enables selection of a path with optimal signal strength. It is protocol-independent, and could be included as another metric in the table of AODVv2 metrics, or used by other protocols such as OLSRv2. Regards, Charlie P. -------- Forwarded Message -------- Subject: New Version Notification for draft-perkins-manet-rsw-00.txt Date: Mon, 18 Apr 2016 22:23:52 -0700 From: internet-drafts@ietf.org To: Charles E. Perkins A new version of I-D, draft-perkins-manet-rsw-00.txt has been successfully submitted by Charles E. Perkins and posted to the IETF repository. Name: draft-perkins-manet-rsw Revision: 00 Title: Received Signal Weakness (RSW) Metric Document date: 2016-04-18 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-perkins-manet-rsw-00.txt Status: https://datatracker.ietf.org/doc/draft-perkins-manet-rsw/ Htmlized: https://tools.ietf.org/html/draft-perkins-manet-rsw-00 Abstract: The Received Signal Weakness (RSW) metric is a simple cost metric that enables selection of a route with the high end-to-end signal strength. 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 --------------080701040109080902060105 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hello folks,

This draft presents the RSW additive link metric from IEEE 802.15.10 along with information about how to use it with AODVv2.

It basically enables selection of a path with optimal signal strength.

It is protocol-independent, and could be included as another metric in the table of AODVv2 metrics, or used by other protocols such as OLSRv2.

Regards,
Charlie P.



-------- Forwarded Message --------
Subject: New Version Notification for draft-perkins-manet-rsw-00.txt
Date: Mon, 18 Apr 2016 22:23:52 -0700
From: internet-drafts@ietf.org
To: Charles E. Perkins <charliep@computer.org> 


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

Name:		draft-perkins-manet-rsw
Revision:	00
Title:		Received Signal Weakness (RSW) Metric
Document date:	2016-04-18
Group:		Individual Submission
Pages:		4
URL:            https://www.ietf.org/internet-drafts/draft-perkins-manet-rsw-00.txt
Status:         https://datatracker.ietf.org/doc/draft-perkins-manet-rsw/
Htmlized:       https://tools.ietf.org/html/draft-perkins-manet-rsw-00


Abstract:
   The Received Signal Weakness (RSW) metric is a simple cost metric
   that enables selection of a route with the high end-to-end signal
   strength.

                                                                                  


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


--------------080701040109080902060105-- From nobody Tue Apr 19 12:34: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 2DD7512DB9A for ; Tue, 19 Apr 2016 12:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793, T_KAM_HTML_FONT_INVALID=0.01] 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 MB5fak0guhB6 for ; Tue, 19 Apr 2016 12:34:01 -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 B8A8D12D912 for ; Tue, 19 Apr 2016 12:34:00 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: "'Charles E. Perkins'" , "'Mobile Ad Hoc Networks mailing list'" References: <20160419052352.11079.76705.idtracker@ietfa.amsl.com> <5716736E.9020401@computer.org> In-Reply-To: <5716736E.9020401@computer.org> Date: Tue, 19 Apr 2016 15:34:06 -0400 Message-ID: <05a701d19a72$706520c0$512f6240$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05A8_01D19A50.E9568E00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7ylcJ6U7fUMAGm5FlqUcpTg6iTQIbMsTmnyx1UyA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [manet] Fwd: New Version Notification for draft-perkins-manet-rsw-00.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, 19 Apr 2016 19:34:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05A8_01D19A50.E9568E00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Charlie:=20 =20 Thank you for posting this draft about using received signal strength as = a metric. It could be use by OLSR2 and AODVv2 as a metric. It might = be useful to suggest this metric to the TEAS working group as a TE = signal metric. One question I have about the draft=20 =20 LoopFree(R1,R2):=3D M_rsw(R1) < M_rsw(R2)=20 =20 How does this prove the routes are loop free? =20 =20 Sue=20 =20 From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Charles E. = Perkins Sent: Tuesday, April 19, 2016 2:06 PM To: Mobile Ad Hoc Networks mailing list Subject: [manet] Fwd: New Version Notification for = draft-perkins-manet-rsw-00.txt =20 Hello folks, This draft presents the RSW additive link metric from IEEE 802.15.10 = along with information about how to use it with AODVv2. It basically enables selection of a path with optimal signal strength. It is protocol-independent, and could be included as another metric in = the table of AODVv2 metrics, or used by other protocols such as OLSRv2. Regards, Charlie P. -------- Forwarded Message --------=20 Subject:=20 New Version Notification for draft-perkins-manet-rsw-00.txt Date:=20 Mon, 18 Apr 2016 22:23:52 -0700 From:=20 internet-drafts@ietf.org To:=20 Charles E. Perkins = =20 A new version of I-D, draft-perkins-manet-rsw-00.txt has been successfully submitted by Charles E. Perkins and posted to the IETF repository. =20 Name: draft-perkins-manet-rsw Revision: 00 Title: Received Signal Weakness (RSW) Metric Document date: 2016-04-18 Group: Individual Submission Pages: 4 URL: = https://www.ietf.org/internet-drafts/draft-perkins-manet-rsw-00.txt Status: = https://datatracker.ietf.org/doc/draft-perkins-manet-rsw/ Htmlized: https://tools.ietf.org/html/draft-perkins-manet-rsw-00 =20 =20 Abstract: The Received Signal Weakness (RSW) metric is a simple cost metric that enables selection of a route with the high end-to-end signal strength. =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 =20 =20 ------=_NextPart_000_05A8_01D19A50.E9568E00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Charlie:

 

Thank you for posting this draft about using received signal strength = as a metric.=C2=A0 It could be use by OLSR2 and AODVv2 as a metric. = =C2=A0=C2=A0It might be useful to suggest this metric to the TEAS = working group as a TE signal metric. =C2=A0=C2=A0One question I have = about the draft

 

LoopFree(R1,R2):=3D M_rsw(R1) < M_rsw(R2)

 

How does this prove the routes are loop free? = =C2=A0

 

Sue

 

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Charles = E. Perkins
Sent: Tuesday, April 19, 2016 2:06 PM
To: = Mobile Ad Hoc Networks mailing list
Subject: [manet] Fwd: New = Version Notification for = draft-perkins-manet-rsw-00.txt

 

Hello folks,

This draft presents = the RSW additive link metric from IEEE 802.15.10 along with information = about how to use it with AODVv2.

It basically enables selection = of a path with optimal signal strength.

It is = protocol-independent, and could be included as another metric in the = table of AODVv2 metrics, or used by other protocols such as = OLSRv2.

Regards,
Charlie P.



-------- Forwarded Message -------- =

Subject:

New Version = Notification for = draft-perkins-manet-rsw-00.txt

Date: =

Mon, 18 Apr 2016 22:23:52 = -0700

From:

internet-drafts@ietf.org

To:

Charles E. = Perkins <charliep@computer.org>

 

A new version =
of I-D, draft-perkins-manet-rsw-00.txt
has been =
successfully submitted by Charles E. Perkins and posted to =
the
IETF =
repository.
 
Name:=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
draft-perkins-manet-rsw
Revision:=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 =
00
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 Received Signal Weakness (RSW) Metric
Document =
date: =
2016-04-18
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Individual =
Submission
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 =
4
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 https://www.ietf.org/internet-drafts/draft-perkins-manet-rsw-00.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 https:=
//datatracker.ietf.org/doc/draft-perkins-manet-rsw/
<= pre>Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://t= ools.ietf.org/html/draft-perkins-manet-rsw-00
 
 
Abstract:
=C2=A0=C2=A0 The Received Signal Weakness (RSW) metric is a =
simple cost metric
=C2=A0=C2=A0 that enables =
selection of a route with the high end-to-end =
signal
=C2=A0=C2=A0 =
strength.
 
=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=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=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=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=
=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=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=A0=C2=A0=C2=A0 =

 
 
= 
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
 
 <=
/o:p>

 

 

------=_NextPart_000_05A8_01D19A50.E9568E00-- From nobody Tue Apr 19 13:08: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 B992312E43E for ; Tue, 19 Apr 2016 13:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 BwRYQz8YjcI8 for ; Tue, 19 Apr 2016 13:08:19 -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 058A712E2F3 for ; Tue, 19 Apr 2016 13:08:18 -0700 (PDT) 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 1asbwD-0004OX-Sb; Tue, 19 Apr 2016 16:07:58 -0400 To: Susan Hares , 'Mobile Ad Hoc Networks mailing list' References: <20160419052352.11079.76705.idtracker@ietfa.amsl.com> <5716736E.9020401@computer.org> <05a701d19a72$706520c0$512f6240$@ndzh.com> From: "Charles E. Perkins" Organization: Blue Skies Message-ID: <57169015.8010508@computer.org> Date: Tue, 19 Apr 2016 13:07:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <05a701d19a72$706520c0$512f6240$@ndzh.com> Content-Type: multipart/alternative; boundary="------------080508050504050209080806" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac78663e3d54bc26c5226f1801f95e2b995350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [manet] Fwd: New Version Notification for draft-perkins-manet-rsw-00.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, 19 Apr 2016 20:08:20 -0000 This is a multi-part message in MIME format. --------------080508050504050209080806 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello Sue, I'd be happy to suggest the metric to TEAS. Please send me information about how best to do that. I hope this will also further enable the creation of a registry of protocol-independent metric types. The proof of loop-freedom is inductive and relies on the following characteristics: - The metric is additive - The metric is monotonic and strictly increasing As I remember, you first prove loop-freedom for all routes satisfying Loop_Free() with metric = 1, and from that for all routes with metric = 2, and so on. Since Min_RSW is 1, the RSW metric is indeed strictly increasing. I also have specifications relevant to optimal bandwidth and Expected Retransmission Count, which I will submit soon. If there are comments on this draft, I would want to incorporate the comments also for the other draft. This draft is a reformulation of the IEEE 802.15.10 clause for RSW, but some people might want a 16-bit metric with more bits of resolution. If that is the case, then we could have M_rsw8 and M_rsw16 instead of just M_rsw. But alternatively it could be that no one believes a high-precision measurement of signal strength, which anyway is pretty variable over time. What do you think? Regards, Charlie P. On 4/19/2016 12:34 PM, Susan Hares wrote: > > Charlie: > > Thank you for posting this draft about using received signal strength > as a metric. It could be use by OLSR2 and AODVv2 as a metric. It > might be useful to suggest this metric to the TEAS working group as a > TE signal metric. One question I have about the draft > > LoopFree(R1,R2):= M_rsw(R1) < M_rsw(R2) > > How does this prove the routes are loop free? > > Sue > > *From:*manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Charles E. > Perkins > *Sent:* Tuesday, April 19, 2016 2:06 PM > *To:* Mobile Ad Hoc Networks mailing list > *Subject:* [manet] Fwd: New Version Notification for > draft-perkins-manet-rsw-00.txt > > Hello folks, > > This draft presents the RSW additive link metric from IEEE 802.15.10 > along with information about how to use it with AODVv2. > > It basically enables selection of a path with optimal signal strength. > > It is protocol-independent, and could be included as another metric in > the table of AODVv2 metrics, or used by other protocols such as OLSRv2. > > Regards, > Charlie P. > > > > -------- Forwarded Message -------- > > *Subject: * > > > > New Version Notification for draft-perkins-manet-rsw-00.txt > > *Date: * > > > > Mon, 18 Apr 2016 22:23:52 -0700 > > *From: * > > > > internet-drafts@ietf.org > > *To: * > > > > Charles E. Perkins > > A new version of I-D, draft-perkins-manet-rsw-00.txt > has been successfully submitted by Charles E. Perkins and posted to the > IETF repository. > > Name: draft-perkins-manet-rsw > Revision: 00 > Title: Received Signal Weakness (RSW) Metric > Document date: 2016-04-18 > Group: Individual Submission > Pages: 4 > URL:https://www.ietf.org/internet-drafts/draft-perkins-manet-rsw-00.txt > Status:https://datatracker.ietf.org/doc/draft-perkins-manet-rsw/ > Htmlized:https://tools.ietf.org/html/draft-perkins-manet-rsw-00 > > > Abstract: > The Received Signal Weakness (RSW) metric is a simple cost metric > that enables selection of a route with the high end-to-end signal > strength. > > > > > 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 > > > -- Regards, Charlie P. --------------080508050504050209080806 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello Sue,

I'd be happy to suggest the metric to TEAS.  Please send me information about how best to do that.  I hope this will also further enable the creation of a registry of protocol-independent metric types.

The proof of loop-freedom is inductive and relies on the following characteristics:
- The metric is additive
- The metric is monotonic and strictly increasing
As I remember, you first prove loop-freedom for all routes satisfying Loop_Free() with metric = 1, and from that for all routes with metric = 2, and so on.

Since Min_RSW is 1, the RSW metric is indeed strictly increasing.

I also have specifications relevant to optimal bandwidth and Expected Retransmission Count, which I will submit soon.  If there are comments on this draft, I would want to incorporate the comments also for the other draft.

This draft is a reformulation of the IEEE 802.15.10 clause for RSW, but some people might want a 16-bit metric with more bits of resolution.  If that is the case, then we could have M_rsw8 and M_rsw16 instead of just M_rsw.  But alternatively it could be that no one believes a high-precision measurement of signal strength, which anyway is pretty variable over time.  What do you think? 

Regards,
Charlie P.


On 4/19/2016 12:34 PM, Susan Hares wrote:

Charlie:

 

Thank you for posting this draft about using received signal strength as a metric.  It could be use by OLSR2 and AODVv2 as a metric.   It might be useful to suggest this metric to the TEAS working group as a TE signal metric.   One question I have about the draft

 

LoopFree(R1,R2):= M_rsw(R1) < M_rsw(R2)

 

How does this prove the routes are loop free?  

 

Sue

 

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Charles E. Perkins
Sent: Tuesday, April 19, 2016 2:06 PM
To: Mobile Ad Hoc Networks mailing list
Subject: [manet] Fwd: New Version Notification for draft-perkins-manet-rsw-00.txt

 

Hello folks,

This draft presents the RSW additive link metric from IEEE 802.15.10 along with information about how to use it with AODVv2.

It basically enables selection of a path with optimal signal strength.

It is protocol-independent, and could be included as another metric in the table of AODVv2 metrics, or used by other protocols such as OLSRv2.

Regards,
Charlie P.



-------- Forwarded Message --------

Subject:

New Version Notification for draft-perkins-manet-rsw-00.txt

Date:

Mon, 18 Apr 2016 22:23:52 -0700

From:

internet-drafts@ietf.org

To:

Charles E. Perkins <charliep@computer.org>

 

A new version of I-D, draft-perkins-manet-rsw-00.txt
has been successfully submitted by Charles E. Perkins and posted to the
IETF repository.
 
Name:          draft-perkins-manet-rsw
Revision:      00
Title:         Received Signal Weakness (RSW) Metric
Document date: 2016-04-18
Group:         Individual Submission
Pages:         4
URL:            https://www.ietf.org/internet-drafts/draft-perkins-manet-rsw-00.txt
Status:         https://datatracker.ietf.org/doc/draft-perkins-manet-rsw/
Htmlized:       https://tools.ietf.org/html/draft-perkins-manet-rsw-00
 
 
Abstract:
   The Received Signal Weakness (RSW) metric is a simple cost metric
   that enables selection of a route with the high end-to-end signal
   strength.
 
                                                                                  
 
 
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
 
 

 

 


-- 
Regards,
Charlie P.
--------------080508050504050209080806-- From nobody Tue Apr 19 13:27: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 C5EB812E20D for ; Tue, 19 Apr 2016 13:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793, T_KAM_HTML_FONT_INVALID=0.01] 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 jQ-gb3Rxwbhk for ; Tue, 19 Apr 2016 13:27:17 -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 6FBC112E218 for ; Tue, 19 Apr 2016 13:27:17 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: "'Charles E. Perkins'" , "'Mobile Ad Hoc Networks mailing list'" References: <20160419052352.11079.76705.idtracker@ietfa.amsl.com> <5716736E.9020401@computer.org> <05a701d19a72$706520c0$512f6240$@ndzh.com> <57169015.8010508@computer.org> In-Reply-To: <57169015.8010508@computer.org> Date: Tue, 19 Apr 2016 16:27:23 -0400 Message-ID: <05f901d19a79$e1c74bb0$a555e310$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05FA_01D19A58.5ABA3F90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7ylcJ6U7fUMAGm5FlqUcpTg6iTQIbMsTmARGwuHECvEn4a58OEpjA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [manet] Fwd: New Version Notification for draft-perkins-manet-rsw-00.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, 19 Apr 2016 20:27:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05FA_01D19A58.5ABA3F90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Charlie:=20 =20 On TEAS, you could just send the idea to TEAS. Thank you for the = Loop-Free explanation. I look forward to the optimal bandwidth and = expected retransmission count.=20 =20 Sue=20 =20 From: Charles E. Perkins [mailto:charliep@computer.org]=20 Sent: Tuesday, April 19, 2016 4:08 PM To: Susan Hares; 'Mobile Ad Hoc Networks mailing list' Subject: Re: [manet] Fwd: New Version Notification for = draft-perkins-manet-rsw-00.txt =20 Hello Sue, I'd be happy to suggest the metric to TEAS. Please send me information = about how best to do that. I hope this will also further enable the = creation of a registry of protocol-independent metric types. The proof of loop-freedom is inductive and relies on the following = characteristics: - The metric is additive - The metric is monotonic and strictly increasing As I remember, you first prove loop-freedom for all routes satisfying = Loop_Free() with metric =3D 1, and from that for all routes with metric = =3D 2, and so on. Since Min_RSW is 1, the RSW metric is indeed strictly increasing. I also have specifications relevant to optimal bandwidth and Expected = Retransmission Count, which I will submit soon. If there are comments = on this draft, I would want to incorporate the comments also for the = other draft. This draft is a reformulation of the IEEE 802.15.10 clause for RSW, but = some people might want a 16-bit metric with more bits of resolution. If = that is the case, then we could have M_rsw8 and M_rsw16 instead of just = M_rsw. But alternatively it could be that no one believes a = high-precision measurement of signal strength, which anyway is pretty = variable over time. What do you think? =20 Regards, Charlie P. On 4/19/2016 12:34 PM, Susan Hares wrote: Charlie:=20 =20 Thank you for posting this draft about using received signal strength as = a metric. It could be use by OLSR2 and AODVv2 as a metric. It might = be useful to suggest this metric to the TEAS working group as a TE = signal metric. One question I have about the draft=20 =20 LoopFree(R1,R2):=3D M_rsw(R1) < M_rsw(R2)=20 =20 How does this prove the routes are loop free? =20 =20 Sue=20 =20 From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Charles E. = Perkins Sent: Tuesday, April 19, 2016 2:06 PM To: Mobile Ad Hoc Networks mailing list Subject: [manet] Fwd: New Version Notification for = draft-perkins-manet-rsw-00.txt =20 Hello folks, This draft presents the RSW additive link metric from IEEE 802.15.10 = along with information about how to use it with AODVv2. It basically enables selection of a path with optimal signal strength. It is protocol-independent, and could be included as another metric in = the table of AODVv2 metrics, or used by other protocols such as OLSRv2. Regards, Charlie P. -------- Forwarded Message --------=20 Subject:=20 New Version Notification for draft-perkins-manet-rsw-00.txt Date:=20 Mon, 18 Apr 2016 22:23:52 -0700 From:=20 internet-drafts@ietf.org To:=20 Charles E. Perkins = =20 A new version of I-D, draft-perkins-manet-rsw-00.txt has been successfully submitted by Charles E. Perkins and posted to the IETF repository. =20 Name: draft-perkins-manet-rsw Revision: 00 Title: Received Signal Weakness (RSW) Metric Document date: 2016-04-18 Group: Individual Submission Pages: 4 URL: = https://www.ietf.org/internet-drafts/draft-perkins-manet-rsw-00.txt Status: = https://datatracker.ietf.org/doc/draft-perkins-manet-rsw/ Htmlized: https://tools.ietf.org/html/draft-perkins-manet-rsw-00 =20 =20 Abstract: The Received Signal Weakness (RSW) metric is a simple cost metric that enables selection of a route with the high end-to-end signal strength. =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 =20 =20 --=20 Regards, Charlie P. ------=_NextPart_000_05FA_01D19A58.5ABA3F90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Charlie:

 

On TEAS, you could just send the idea to TEAS.=C2=A0 =C2=A0Thank you = for the Loop-Free explanation. =C2=A0I look forward to the optimal = bandwidth and expected retransmission count.

 

Sue =

 

From: Charles E. Perkins [mailto:charliep@computer.org]
Sent: = Tuesday, April 19, 2016 4:08 PM
To: Susan Hares; 'Mobile Ad = Hoc Networks mailing list'
Subject: Re: [manet] Fwd: New = Version Notification for = draft-perkins-manet-rsw-00.txt

 

Hello Sue,

I'd be happy to suggest = the metric to TEAS.  Please send me information about how best to = do that.  I hope this will also further enable the creation of a = registry of protocol-independent metric types.

The proof of = loop-freedom is inductive and relies on the following = characteristics:
- The metric is additive
- The metric is = monotonic and strictly increasing
As I remember, you first prove = loop-freedom for all routes satisfying Loop_Free() with metric =3D 1, = and from that for all routes with metric =3D 2, and so on.

Since = Min_RSW is 1, the RSW metric is indeed strictly increasing.

I = also have specifications relevant to optimal bandwidth and Expected = Retransmission Count, which I will submit soon.  If there are = comments on this draft, I would want to incorporate the comments also = for the other draft.

This draft is a reformulation of the IEEE = 802.15.10 clause for RSW, but some people might want a 16-bit metric = with more bits of resolution.  If that is the case, then we could = have M_rsw8 and M_rsw16 instead of just M_rsw.  But alternatively = it could be that no one believes a high-precision measurement of signal = strength, which anyway is pretty variable over time.  What do you = think? 

Regards,
Charlie = P.

On 4/19/2016 12:34 = PM, Susan Hares wrote:

Charlie: =

 <= /o:p>

Thank you = for posting this draft about using received signal strength as a = metric.  It could be use by OLSR2 and AODVv2 as a metric. =   It might be useful to suggest this metric to the TEAS = working group as a TE signal metric.   One question I have = about the draft

 <= /o:p>

LoopFree(R1,= R2):=3D M_rsw(R1) < M_rsw(R2)

 <= /o:p>

How does = this prove the routes are loop free?  

 <= /o:p>

Sue =

 <= /o:p>

From:= manet [mailto:manet-bounces@ietf.org]= On Behalf Of Charles E. Perkins
Sent: Tuesday, April = 19, 2016 2:06 PM
To: Mobile Ad Hoc Networks mailing = list
Subject: [manet] Fwd: New Version Notification for = draft-perkins-manet-rsw-00.txt

 <= /o:p>

Hello = folks,

This draft presents the RSW additive link metric from IEEE = 802.15.10 along with information about how to use it with = AODVv2.

It basically enables selection of a path with optimal = signal strength.

It is protocol-independent, and could be = included as another metric in the table of AODVv2 metrics, or used by = other protocols such as OLSRv2.

Regards,
Charlie = P.



----= ---- Forwarded Message --------

Subject: =

New Version = Notification for = draft-perkins-manet-rsw-00.txt

Date: =

Mon, 18 Apr = 2016 22:23:52 -0700

From: =

internet-drafts@ietf.org

To: =

Charles E. = Perkins <charliep@computer.org>

 <= /o:p>

A new version of I-D, =
draft-perkins-manet-rsw-00.txt
has been =
successfully submitted by Charles E. Perkins and posted to =
the
IETF =
repository.
 
Name: &=
nbsp;        =
draft-perkins-manet-rsw
Revision:   &=
nbsp;  =
00
Title:       &=
nbsp; Received Signal Weakness (RSW) =
Metric
Document date: =
2016-04-18
Group:      =
;   Individual =
Submission
Pages:      =
;   =
4
URL:       &nbs=
p;    https://www.ietf.org/internet-drafts/draft-perkins-manet-rsw-00.txt
Status:       =
  https:=
//datatracker.ietf.org/doc/draft-perkins-manet-rsw/
<= pre>Htmlized:       https://t= ools.ietf.org/html/draft-perkins-manet-rsw-00
&n=
bsp;
 
Abstract:
   The Received Signal Weakness (RSW) metric is a =
simple cost metric
   that enables =
selection of a route with the high end-to-end =
signal
   =
strength.
 
  &n=
bsp;           &nb=
sp;           &nbs=
p;            =
;            =
            &=
nbsp;           &n=
bsp;      =

 
 
= 
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
 
 <=
/o:p>

 <= /o:p>

 <= /o:p>



-- =

Regards,
Charlie =
P.
------=_NextPart_000_05FA_01D19A58.5ABA3F90-- From nobody Tue Apr 19 16:29:39 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 4848312B060; Tue, 19 Apr 2016 16:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, 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 eRciwSWWLQ_e; Tue, 19 Apr 2016 16:29:37 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA4612D62F; Tue, 19 Apr 2016 16:29:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CE3CD18000F; Tue, 19 Apr 2016 16:29:04 -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: <20160419232904.CE3CD18000F@rfc-editor.org> Date: Tue, 19 Apr 2016 16:29:04 -0700 (PDT) Archived-At: Cc: manet@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] RFC 7779 on Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2) 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, 19 Apr 2016 23:29:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7779 Title: Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2) Author: H. Rogge, E. Baccelli Status: Experimental Stream: IETF Date: April 2016 Mailbox: henning.rogge@fkie.fraunhofer.de, Emmanuel.Baccelli@inria.fr Pages: 21 Characters: 43953 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-manet-olsrv2-dat-metric-12.txt URL: https://www.rfc-editor.org/info/rfc7779 DOI: http://dx.doi.org/10.17487/RFC7779 This document specifies a Directional Airtime (DAT) link metric for usage in Optimized Link State Routing version 2 (OLSRv2). 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 Tue Apr 19 18:59: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 5FCFB12DB65 for ; Tue, 19 Apr 2016 18:59:54 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 fhkSpU_BScNx for ; Tue, 19 Apr 2016 18:59:52 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 7867B12D605 for ; Tue, 19 Apr 2016 18:59:52 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u3K1xorA026721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 20 Apr 2016 03:59:50 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id u3K1xoQS024460 for ; Wed, 20 Apr 2016 03:59:50 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 4A20662173 for ; Wed, 20 Apr 2016 03:59:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id bvwB0XHIUk5X for ; Wed, 20 Apr 2016 03:59:49 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D5B3B62170 for ; Wed, 20 Apr 2016 03:59:47 +0200 (CEST) Date: Wed, 20 Apr 2016 03:59:48 +0200 Message-ID: <8760vd6nvv.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: manet@ietf.org In-Reply-To: <20160419232904.CE3CD18000F@rfc-editor.org> References: <20160419232904.CE3CD18000F@rfc-editor.org> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 20 Apr 2016 03:59:50 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 20 Apr 2016 03:59:50 +0200 (CEST) X-Miltered: at korolev with ID 5716E296.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5716E296.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5716E296.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5716E296.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5716E296.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5716E296.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [manet] RFC 7779 on Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2) 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, 20 Apr 2016 01:59:54 -0000 Congratulations, Henning! From nobody Tue Apr 19 22:50: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 BA5E512E3AA for ; Tue, 19 Apr 2016 22:50:32 -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 TpCleNNq_cf9 for ; Tue, 19 Apr 2016 22:50:31 -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 0AAA112E3A5 for ; Tue, 19 Apr 2016 22:50:31 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id c126so34295842lfb.2 for ; Tue, 19 Apr 2016 22:50:30 -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=EwUA8VkeEweM6nbpUqGRA9jRZJH/t+4Q7ZuT4VWnhxY=; b=PE8yNsWPvH8cjgnkVC29DgO9hUHoU+CwCV7U3o9Lr+u4eTXp47aaR4dec7hpjntDUq jl/klM75zZJ+dJNjNvtYKpQs4ZyGULjx116oyVmcr8qUQSFOCdTFrdMIC4UGjnSYd5k2 kAoWl9YIdCzZuCpfGL2U33PvuHnPkXApYkvNapXKv4O2UVpNznKFhRTifN2QQ/eDwpwz TeYCB3ke0ToQhGIDh0J8oUuR17Hy/8tU4VvIy3B82xOjouZwfH+VGYjP3Hla1JiTxLTg ciF88WI+VisOXkoiYomnsVqjWCRKmlLlFr+0kRsRXydPBmaP5wEY3XhGQv4tKz/4X7OM 7rkA== 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=EwUA8VkeEweM6nbpUqGRA9jRZJH/t+4Q7ZuT4VWnhxY=; b=kl1wlgGraYidjc90tvgKy+A5CsguypSV3TkP/YgcGApCrn5KKKYf8F86BACMWOvJzY TYafkY9whTo8wcFe+4bFjebvjkP4Uxqk2s1uTxfUMgaxYlJS5gnpqBqSBWXhyWUtJ4pQ E85yKaVbmJEITM04B6NQ/rDyKmO0t3bDhOh/yeHHV8EEA2OhfGAmhuVKKEwNCzd9oEOH mFOnC2GvVjAEjuJsLdo1njqPyd2j/zV+19XXUi+ujIqZ9V8Dai9vC/n6zlSnRV7Bnb/e EJOLH4aWG8EYbO/k6I1sqBhT9QwMMPGcen3aP88d94AJ0jW1ZIc3VldPgkakiEjENocw dn2w== X-Gm-Message-State: AOPr4FWiJZnDFuUrfiKqeS6qd0s1nPvacjx9l9DIjcDAOgFU50NPsbXPGZ8Qf1Q88NnFur4+OgE+ufhReJafzw== X-Received: by 10.25.131.147 with SMTP id f141mr2851822lfd.12.1461131429320; Tue, 19 Apr 2016 22:50:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.24.42 with HTTP; Tue, 19 Apr 2016 22:49:59 -0700 (PDT) In-Reply-To: <571536FC.5050407@earthlink.net> References: <571508C8.3030003@earthlink.net> <571536FC.5050407@earthlink.net> From: Henning Rogge Date: Wed, 20 Apr 2016 07:49:59 +0200 Message-ID: To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 20 Apr 2016 05:50:32 -0000 On Mon, Apr 18, 2016 at 9:35 PM, Charlie Perkins wrote: > Hello Abdussalam, > > Thanks for your support! > > I think that the link metric type table specified in the AODVv2 document > should remain protocol-independent as much as possible. I also support the > OLSRv2 strategy of using additive cost metrics insofar as is possible. Then I would suggest to just copy the OLSRv2 strategy. Define a single PATH_METRIC TLV with a 32 bit unsigned integer inside. This should work out for most (maybe even all) metrics and makes AODVv2 and OLSRv2 link/path metric range compatible. A special deployment that needs to preserve a few more bytes could work on a (transparent) compression scheme for the message format later. Henning From nobody Wed Apr 20 00:08: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 60E9912DDFA for ; Wed, 20 Apr 2016 00:08:35 -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 AWA3LCwSMlx8 for ; Wed, 20 Apr 2016 00:08:32 -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 26FE112DC97 for ; Wed, 20 Apr 2016 00:08:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id E124424097D; Wed, 20 Apr 2016 00:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461136101; bh=XGOdZ9Wo1gPNKTtbmAj1krYjikbrvYxAXxM2+bS0ulQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=dZXfzVGkTqEQ19oq4L6ZWHSHKGeajewejc9BYZ5tQkJranK304CSt7jIAWfsr1GPp hcLW1bSR+15XHrSvtAdMt0aD42+DdFUbSXL1srFBn8yh3lBp/800Ddxu76rCQEPtZW oYwJvJ6kDct2AKqHfMQH3X8uKJlBHLLtZZWmGuJo= 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 A6E6A2464D2; Wed, 20 Apr 2016 00:08:20 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_525FA262-F377-4020-8BCD-057CC822D4D0" From: ietf@thomasclausen.org In-Reply-To: Date: Wed, 20 Apr 2016 09:08:17 +0200 Sendlaterdate: Wed, 20 Apr 2016 09:08:17 +0200 Message-Id: References: <571508C8.3030003@earthlink.net> <571536FC.5050407@earthlink.net> To: Henning Rogge X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Charles Perkins , Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 20 Apr 2016 07:08:35 -0000 --Apple-Mail=_525FA262-F377-4020-8BCD-057CC822D4D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There are three key points that I want to reiterate here - and I think = that I am in part just reiterating some comments that Chris made = earlier: 1) The routing protocol should not be aware of the =E2=80=9Cspecifics=E2=80= =9D of any metric used, but simply its identity and structure=20 This includes both which =E2=80=9Ckind=E2=80=9D (ETT, DAT, taste, = flavour, colour =E2=80=A6) and I would even argue =E2=80=9Chow many bits = it is long". As long as (i) metrics are additive, and (ii) metrics are = carried in a TLV, that is all that is needed: A router receives a message with a TLV: TLV_TYPE =3D Path_Metric TYPE_EXTENSION =3D Path_Metric_Type LENGTH =3D n octets VALUE =3D Metric_Value The TLV_TYPE allows the router to determine that =E2=80=9C= this TLV carries a metric=E2=80=9D. TYPE_EXTENSION allows the router to determine if it can = participate in this=20 topology (process/forward the message), or not = (drop) (LENGTH , VALUE) allows it to allocate appropriate data = structures to do the=20 =E2=80=9Caddition=E2=80=9D (additive metrics) = and determine the updated VALUE if the message is retransmitted 2) Consequently, the registry for link metrics is the Type Extension = registry that is created when allocating the TLV_TYPE =3D Path_Metric That registry should, I believe, in a publication of the routing = protocol specification *NOT* contain references to specific metric types = (ETT, DAT, =E2=80=A6). Take a look at how we did (for LINK_METRIC) in = RFC7181 http://tools.ietf.org/html/rfc7181#section-24 and updated in RFC = 7722 https://tools.ietf.org/html/rfc7722#section-13.3 The idea is to have a set of =E2=80=9Cadministratively assigned=E2=80=9D = meanings defined (for administratively determined topology types).=20 It may be that in a deployment I will administratively assign one of = those to the RFC7799 experimental metric type. Then, down the line, it = may turn out that RFC7799 is a great idea, and a std.track RFC7799bis is = proposed and adopted =E2=80=94 which then could make a reservation of a = LINK_METRIC (or, PATH_METRIC) TLV type for the protocols where it was = found useful. 3) a =E2=80=9Cprotocol independent metrics type registry" is actually = mechanically a bad idea, and is in any event premature at this stage.=20 It may be, for example, that a metric representation works well for a = proactive protocol =E2=80=94 but doesn=E2=80=99t for a reactive = protocol. I would, for example, guess that the representation of =E2=80=9C= link metrics=E2=80=9D in OLSRv2 would not be ideal for path metrics in a = reactive protocol. It would be unfortunate if =E2=80=9Cmaking a = reservation for OLSRv2=E2=80=9D in a registry would squat on the type = space for a reactive protocol (using TLV Type Extensions, there are only = 256 possible =E2=80=A6) Just as it may be that the RFC7799 metric type works great for OLSRv2, = but as it is (as far as I know) not tested in reactive protocols would = be horrible for a reactive protocol. It would be unfortunate if OLSRv2 = making a reservation for that metric type would =E2=80=9Csquat on=E2=80=9D= the type space for a reactive protocol. In conclusion, it would seem reasonable to adopt the approach described = in points 1) and 2) for how to deal with metrics, and to push 3) off the = table.=20 Remember, though, whereas in OLSRv2 the VALUE field formatting is the = =E2=80=9Cexponential format=E2=80=9D that Chris has described (because = it makes sense, for the reasons Chris also enumerated, for OLSRv2), it = may be wise to define the VALUE field as =E2=80=9Can unsigned integer = field of n octets=E2=80=9D for the purposes of a reactive protocol?=20 Although that would likely be informed by what the answer to my question = in = http://mailarchive.ietf.org/arch/msg/manet/gieCZUvocKq-OYKbznHLj-SolzU = = would be? Hope to see this reflected in a forthcoming revision of the document? Best, Thomas > On 20 Apr 2016, at 07:49, Henning Rogge wrote: >=20 > On Mon, Apr 18, 2016 at 9:35 PM, Charlie Perkins > wrote: >> Hello Abdussalam, >>=20 >> Thanks for your support! >>=20 >> I think that the link metric type table specified in the AODVv2 = document >> should remain protocol-independent as much as possible. I also = support the >> OLSRv2 strategy of using additive cost metrics insofar as is = possible. >=20 > Then I would suggest to just copy the OLSRv2 strategy. >=20 > Define a single PATH_METRIC TLV with a 32 bit unsigned integer inside. > This should work out for most (maybe even all) metrics and makes > AODVv2 and OLSRv2 link/path metric range compatible. >=20 > A special deployment that needs to preserve a few more bytes could > work on a (transparent) compression scheme for the message format > later. >=20 > Henning >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_525FA262-F377-4020-8BCD-057CC822D4D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 There are three key points that I want to reiterate here - = and I think that I am in part just reiterating some comments that Chris = made earlier:

1) The routing protocol should not be aware of the = =E2=80=9Cspecifics=E2=80=9D of any metric used, but simply its identity = and structure 
This includes both which = =E2=80=9Ckind=E2=80=9D (ETT, DAT, taste, flavour, colour =E2=80=A6) and = I would even argue =E2=80=9Chow many bits it is long". As long as (i) = metrics are additive, and (ii) metrics are carried in a TLV, that is all = that is needed:

= A router receives a message with a TLV:
= TLV_TYPE =   =3D Path_Metric
= TYPE_EXTENSION =3D Path_Metric_Type
= LENGTH =3D n = octets
VALUE = =3D Metric_Value

= The TLV_TYPE allows the router to determine that =E2=80=9Cthis = TLV carries a metric=E2=80=9D.

TYPE_EXTENSION allows the = router to determine if it can participate in this 
= topology (process/forward the message), or not = (drop)

= (LENGTH , VALUE) allows it to allocate appropriate data = structures to do the 
= =E2=80=9Caddition=E2=80=9D (additive metrics) and determine the = updated VALUE if the message is retransmitted

2) Consequently, the = registry for link metrics is the Type Extension registry that is = created when allocating the TLV_TYPE =3D Path_Metric
That registry should, I believe, in a publication of the = routing protocol specification *NOT* contain references to specific = metric types (ETT, DAT, =E2=80=A6). Take a look at how we did (for = LINK_METRIC)  in RFC7181 http://tools.ietf.org/html/rfc7181#section-24 and updated = in RFC 7722 https://tools.ietf.org/html/rfc7722#section-13.3

The idea is to have a = set of =E2=80=9Cadministratively assigned=E2=80=9D meanings defined (for = administratively determined topology types). 

It may be that in a = deployment I will administratively assign one of those to the RFC7799 = experimental metric  type. Then, down the line, it may turn out = that RFC7799 is a great idea, and a std.track RFC7799bis is proposed and = adopted =E2=80=94 which then could make a reservation of a LINK_METRIC = (or, PATH_METRIC) TLV type for the protocols where it was found = useful.

3) a =E2=80=9Cprotocol independent metrics type = registry" is actually mechanically a bad idea, and is in any event = premature at this stage. 
It may be, for = example, that a metric representation works well for a proactive = protocol =E2=80=94 but doesn=E2=80=99t for a reactive protocol. I would, = for example, guess that the representation of =E2=80=9Clink metrics=E2=80=9D= in OLSRv2 would not be ideal for path metrics in a reactive protocol. = It would be unfortunate if =E2=80=9Cmaking a reservation for OLSRv2=E2=80=9D= in a registry would squat on the type space for a reactive protocol = (using TLV Type Extensions, there are only 256 possible =E2=80=A6)

Just as it may be = that the RFC7799 metric type works great for OLSRv2, but as it is (as = far as I know) not tested in reactive protocols would be horrible for a = reactive protocol. It would be unfortunate if OLSRv2 making a = reservation for that metric type would =E2=80=9Csquat on=E2=80=9D the = type space for a reactive protocol.


In conclusion, it would seem reasonable to adopt the = approach described in points 1) and 2) for how to deal with metrics, and = to push 3) off the table. 
Remember, though, = whereas in OLSRv2 the VALUE field formatting is the =E2=80=9Cexponential = format=E2=80=9D that Chris has described (because it makes sense, for = the reasons Chris also enumerated, for OLSRv2), it may be wise to define = the VALUE field as =E2=80=9Can unsigned integer field of n octets=E2=80=9D= for the purposes of a reactive protocol? 

Although that would likely be informed = by what the answer to my question in http://mailarchive.ietf.org/arch/msg/manet/gieCZUvocKq-OYKbznHL= j-SolzU would be?

Hope to see this reflected in a forthcoming revision of the = document?

Best,

Thomas


On 20 Apr 2016, at 07:49, = Henning Rogge <hrogge@gmail.com> wrote:

On = Mon, Apr 18, 2016 at 9:35 PM, Charlie Perkins
<charles.perkins@earthlink.net> wrote:
Hello Abdussalam,

Thanks for your support!

I think that the link metric type table specified in the = AODVv2 document
should remain protocol-independent as much = as possible.  I also support the
OLSRv2 strategy of = using additive cost metrics insofar as is possible.

Then I would suggest to just copy = the OLSRv2 strategy.

Define a single = PATH_METRIC TLV with a 32 bit unsigned integer inside.
This = should work out for most (maybe even all) metrics and makes
AODVv2 and OLSRv2 link/path metric range compatible.

A special deployment that needs to preserve a = few more bytes could
work on a (transparent) compression = scheme for the message format
later.

Henning

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

= --Apple-Mail=_525FA262-F377-4020-8BCD-057CC822D4D0-- From nobody Wed Apr 20 01:27: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 4FF5D12D8E6 for ; Wed, 20 Apr 2016 01:27:39 -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 s1z5HfM_DcGP for ; Wed, 20 Apr 2016 01:27:37 -0700 (PDT) Received: from mail-qg0-x242.google.com (mail-qg0-x242.google.com [IPv6:2607:f8b0:400d:c04::242]) (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 74DF412D83D for ; Wed, 20 Apr 2016 01:27:37 -0700 (PDT) Received: by mail-qg0-x242.google.com with SMTP id m8so4124386qgd.1 for ; Wed, 20 Apr 2016 01:27:37 -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=mKejKhfw9nqEjbrTc1jjlityfm83dCsaI22tDr+aET0=; b=mI7UIjfSZdsqspgdmgZbe88cd8xKnOm5EjDVu0v8xwub7UyRiDu22rI0jKYyoshC0J pk4EU4j0NxIvSggOruCGyqOBlAtAxCbRy5Hbi7lmd1YePZ9EJnv8hUCZt7ieNmjbEIPp LytMoKC/MyHRYKUmRXfMH+Gql9I1vkPY5j53pcrkilJn5goHLXC3OCT7W7YH203mOu4f vvIv77xvsakLVkkPwYD4o/0zOtZD4HSdPF19nG8o5UA9hNbYPta2M9+ge+eJ/ZVKpLAM ELtPwEgMBwQSKrMZrZg6+rbzauLKlCNLpSvwMUAqoolki93/8nB1yFhNypK2nZhyfqR4 dwtg== 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=mKejKhfw9nqEjbrTc1jjlityfm83dCsaI22tDr+aET0=; b=Pc3d1oN350AmjguBYS9JdFJeA4BdoYxkX2mA/g37MUniOdm6NrmRGyCBdgrIsgWtnA 7GXaUfAd6dEDY8TeXb7UpZO7+0SL4G1myUBqhzm487l6AwthPgrVSMyoKMGxVgfrzjcc 0OXZa9PZGZxS1faLL2oV8b84yTNBPm2WpsP1z9WXtMf0WxBjGT2S92N87dvsgdnPvsy1 qYyQkuANACyq9LX3jj3GRQ25LuP9s4kBgXGSniS7aYoANDud30C4LoIOjBrqrLx/10ZG ZGIOyh0UanNyu3N/YSVnJyGeIVxHYrGiawx+M8TD3GEOKb6JpyWtVfQvXqJUpOL1LQM4 8W0Q== X-Gm-Message-State: AOPr4FUtSEhjiRqbaxFph1jtg5QLKIerv7i7rDIGTJKSx6kmqlm3dGoCiL7hNm8+kxyJiRwk4lI1fMm6rO72Xw== MIME-Version: 1.0 X-Received: by 10.140.130.14 with SMTP id 14mr9480863qhc.85.1461140856591; Wed, 20 Apr 2016 01:27:36 -0700 (PDT) Received: by 10.140.43.131 with HTTP; Wed, 20 Apr 2016 01:27:36 -0700 (PDT) In-Reply-To: <8760vd6nvv.wl-jch@pps.univ-paris-diderot.fr> References: <20160419232904.CE3CD18000F@rfc-editor.org> <8760vd6nvv.wl-jch@pps.univ-paris-diderot.fr> Date: Wed, 20 Apr 2016 10:27:36 +0200 Message-ID: From: Abdussalam Baryun To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=001a1134f182b960f10530e65d36 Archived-At: Cc: manet Subject: Re: [manet] RFC 7779 on Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2) 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, 20 Apr 2016 08:27:39 -0000 --001a1134f182b960f10530e65d36 Content-Type: text/plain; charset=UTF-8 Congratulation Henning, and to all WG. Excellent work, thanks AB On Wed, Apr 20, 2016 at 3:59 AM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > Congratulations, Henning! > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a1134f182b960f10530e65d36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Congratulation Henning, and to all WG. Excellent work= , thanks

AB

On Wed, Apr 20, 2016 at 3:59 AM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
Congratulations, Henning!

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

--001a1134f182b960f10530e65d36-- From nobody Wed Apr 20 02:02: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 B1F5A12D921 for ; Wed, 20 Apr 2016 02:02:56 -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 Og1zz8BhlkwV for ; Wed, 20 Apr 2016 02:02:50 -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 CE10412EA5D for ; Wed, 20 Apr 2016 02:02:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 55BAB245BB5; Wed, 20 Apr 2016 02:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461142969; bh=WM5ipdmSn+lwBDapEEhGh9chk0yCu5xGvyO3DFPe2ME=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=XDT/EHmMheZw2iaFOXI7VwUkslBWCvQgSc3AKSuUSl2+cjoiPe3xRNQt1hz+qXnxe NIlWYgtK+AbkYJdM1AiMeRCtM5aVKQOBTHQW1RRte903FQxJqTIJ6LUUavrdILUjcw RC8iCoHPLMl6oEAxPZI6+Q2HBPYetfIYeTc0ESek= 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 D392B240996; Wed, 20 Apr 2016 02:02:47 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_1894BD07-49E4-47D2-9079-64C4E4BECCC1" From: ietf@thomasclausen.org In-Reply-To: <58FD3C84-52F7-4C5E-B2D0-607FB233524D@thomasclausen.org> Date: Wed, 20 Apr 2016 11:02:45 +0200 Sendlaterdate: Wed, 20 Apr 2016 11:02:45 +0200 Message-Id: <290B6546-9B1B-4554-93F9-8FBC6237D583@thomasclausen.org> References: <20160405101903.773.31003.idtracker@ietfa.amsl.com> <8438BA85-DFC2-4192-84EE-999572C35FD1@fu-berlin.de> <04D7135E-8EDF-49DC-8978-3A1132FF3915@thomasclausen.org> <58FD3C84-52F7-4C5E-B2D0-607FB233524D@thomasclausen.org> To: Christopher Dearlove X-Mailer: Apple Mail (2.3124) Archived-At: Cc: manet , Victoria Mercieca Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-14.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, 20 Apr 2016 09:02:56 -0000 --Apple-Mail=_1894BD07-49E4-47D2-9079-64C4E4BECCC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Looking back over issues that I have raised, I am not sure that I saw = any replies to this, so I went looking in the I-D for some clarification = and some follow-up questions. First, section 9 contains this throw-away comment: Configuring the ENAR as a default router is outside the scope = of this specification. Either I do not understand what you mean by =E2=80=9C=E2=80=A6as a = default router=E2=80=A6=E2=80=9D or there=E2=80=99s a layer of = complexity (that I can guess at) which you=E2=80=99re not telling, but = which really should be called out.=20 My guess would be, that a router inside the MANET will need to = communicate to (say) google, you would do a Route Discovery (RREQ/RREP) = cycle and the ENAR would return a route to 2a00:1450:4007:80e::2003 =E2=80= =94 and then when you 30s later need to communicate to (say) = Facebook.com you would do a Route Discovery (RREQ/RREP) cycle and the = ENAR would return a route to 2a03:2880:20:4f22:face:b00c::25de.=20 I.e. the =E2=80=9C=E2=80=A6as default router=E2=80=A6=E2=80=9D means = that you do not know of any way of making it work such that the ENER an = reply, to the first of these two, with simply 0::0/0, and then have the = routers in the MANET install a route via the ENAR to destinations not = inside the MANET? What I am getting at here is, that if I understand correctly then = connectivity to =E2=80=9Cthe Internet=E2=80=9D is very, very = inefficiently supported =E2=80=94 or, actually, more precisely that = connectivity to any =E2=80=9Cexternal network which can only be captured = by a prefix which also includes destinations inside the MANET=E2=80=9D = is very inefficiently supported (because you cannot install prefix = routes to such a network). If I am understanding this correctly, then it deserves more elaboration = than the throw-away mention at the end of Section 9, cited above, and = certainly this paragraph from the applicability statement needs to = correctly reflect it: AODVv2 is designed for stub or disconnected mobile ad hoc networks, i.e., non-transit networks or those not connected to the internet. AODVv2 can, however, be configured to perform gateway functions when attached to external networks, as discussed in Section 9. Second, section 7.1 specifies for RREQs: AddressList Contains OrigAddr and TargAddr, the source and = destination addresses of the IP packet for which a route is = requested. OrigAddr and TargAddr MUST be routable unicast = addresses. Again, if I have understood correctly, if a router has 255 hosts = attached (say a /56), each of which need to communicate with a server, = then the router must end up generating 255 RREQ/RREP cycles, even though = it may already have an entry for the IP address for the server? The reason why I speculate that this is so is, that RREQ forwarding = installs the =E2=80=9Creverse route=E2=80=9D towards the source, and if = OrigAddr is "the source addresses of the IP packet for which a route is = requested=E2=80=9D address, i.e., there is no way for the RREQ to = request a route to the server =E2=80=9Cat once=E2=80=9D on behalf of = "the entire /56=E2=80=9D behind it? Again, if I am understanding this correctly, then it deserves a bit more = elaboration, notably a framing of the cases discussed in the above, and = a modulation of the statement from the applicability statement that: AODVv2 can, however, be configured to perform gateway functions = when attached to external networks, as discussed in=20 Section 9. Capturing these limitations of gateway functionality? The same, probably, also applies in the opposite direction, i.e., in = case a single =E2=80=9Csource=E2=80=9D needs to communicate with many or = all of a /56, behind a router? Best, Thomas > On 07 Apr 2016, at 23:11, Thomas Heide Clausen = wrote: >=20 > On this whole gateway issue, I am disturbed...most routers would have = one-or-multiple /64-or-shorter, one per non-Manet link (w/ hosts hanging = off) delegated to them, and not just a single /128. >=20 > Needing to communicate with many-to-all hosts on a link is not = uncommon (if the hosts are, e.g., environmental controls in the same = room), and the ability to "get the whole prefix advertised at once" send = an RREQ for the whole prefix - specifically, for not=20 >=20 > Sent from my iPad >=20 > On 07 Apr 2016, at 22:19, Christopher Dearlove = > = wrote: >=20 >> Thanks, that addresses most of the points I made. >>=20 >> Assuming that is that a packet reception for forwarding is the only = option you choose to allow. It's perfectly reasonable for an = implementation to think "wouldn't it be sensible to learn about a = gateway now for various reasons?". Yes, there's the problem of which = subnet to look for (0.0.0.0/0 or something smaller). Yes, I can imagine = you don't want to define this now - unless of course someone in the WG = says they really want it. But I would say, don't close the door on it, = even if not doing it now. >>=20 >> (There are other possibilities that might be useful one day. An RREQ = that looks for more than one address for example - you could trade = latency and overhead by combining RREQs.) >>=20 >> -- =20 >> Christopher Dearlove >> christopher.dearlove@gmail.com = (iPhone) >> chris@mnemosyne.demon.co.uk = (home) >>=20 >> On 7 Apr 2016, at 18:49, Victoria Mercieca > wrote: >>=20 >>> Hi Christopher, >>>=20 >>> On 7 Apr 2016 1:55 pm, "Christopher Dearlove" = > = wrote: >>> > >>> > [This time from a subscribed address.] >>> > >>> > You say you've added a sentence saying AODVv2 doesn't do RREQs for = gateways. What should have happened is a discussion on this list as to = why? is that hard? does anyone have a clever idea to make it not hard? = does anyone need that functionality? and so on. >>> > >>> > For example, here's something that superficially looks like it = might work. Does it, or does it introduce new problems? I don't know. = But this, and likely better ideas, just haven't had discussion here - = and I fear that the people who might have the better ideas have departed = unheard. >>> > >>> > So, a router wants a route to a.b.c.d, and sends an RREQ for that = (/32, or simply omit). Of course any router directly serving that = address just replies. But a router that is serving a.0.0.0/8 could reply = with that address. The originating router of course would use standard = IP maximum prefix length rules. Does that work? Does it help anyone? = Could a router reply a.b.c.d/32 and a.0.0.0/8 in one RREP? Or could it = be allowed to reply a.b.c.d/8 as a shorthand? >>>=20 >>> This is exactly what it does (based on the router client entry = corresponding to TargAddr, e.g if router client entry is a.0.0.0/8, then = the RREP contains a.b.c.d/8). Everyone receiving the RREP can then = install the route to a.0.0.0/8 and therefore avoid a separate RREQ for = (as an example) a.b.c.e in future. Similarly an RREQ contains the prefix = length associated with the router client entry configured for OrigAddr, = and routers processing the RREQ learn the route to OrigAddrs prefix. >>>=20 >>> But you can't intentionally send a RREQ for a prefix because the = RREQ is created when there's a packet to send, you know the destination = address not the prefix associated with it, so TargAddr is a.b.c.d/32. = But even so, you do end up learning a route to a prefix, if TargAddr is = part of a router client entry which is a prefix. >>>=20 >>> Kind regards, >>> Victoria. >>>=20 >>> > And why can't a router request a.b.0.0/16 - and possibly get an = a.0.0.0/8 reply? >>> > >>> > Answers to all of those is "I don't know". But we should have = been having those discussions. >>> > >>> > --=20 >>> > Christopher Dearlove >>> > christopher.dearlove@gmail.com = >>> > >>> > >>> > >>> > -- =20 >>> > Christopher Dearlove >>> > christopher.dearlove@gmail.com = (iPhone) >>> > chris@mnemosyne.demon.co.uk = (home) >>> > On 7 Apr 2016, at 15:49, Lotte Steenbrink = > = wrote: >>> > >>> >> Hi Thomas, >>> >> >>> >>> Am 05.04.2016 um 20:07 schrieb ietf@thomasclausen.org = : >>> >>> >>> >>> Lotte, >>> >>> >>> >>> Thank you for this update. An impressive amount of changes to = the document, according to RFCdiff, and as I can see from your mail that = there is much more to come, >>> >> >>> >> >>> >> Thanks! I=E2=80=99m glad you=E2=80=99re seeing the progress = we=E2=80=99ve made.=20 >>> >> >>> >>> I hope that you forgive me for not jumping at a blow-by-blow = review until a version which the authors themselves consider stable, is = produced. >>> >>> >>> >>> On the point of =E2=80=9Cmuch more to come", there have been = quite a few comments raised by WG participants other than Mr. Dean and = Chris (such as by myself, but not only) =E2=80=94 some of which = intersect some of the below, and for which I do not believe that a = satisfactory resolution has been developed, presented to the WG, and = confirmed. >>> >> >>> >> >>> >> I=E2=80=99m not quite sure which comments exactly you are = referring to? Your last comments that come to mind are the ones in these = threads: >>> >> >>> >> https://www.ietf.org/mail-archive/web/manet/current/msg18055.html = >>> >> https://www.ietf.org/mail-archive/web/manet/current/msg18639.html = >>> >> >>> >> You=E2=80=99ve announced to go through the former in your last = response to the latter, but as far as I can see you haven=E2=80=99t = gotten round to doing that and a lot of points you=E2=80=99ve brought up = have sparked ongoing discussions, so I=E2=80=99ve marked most of your = comments as =E2=80=9Cpending=E2=80=93 still in discussion=E2=80=9D in my = mind.=20 >>> >> Regarding the points you brought up that aren=E2=80=99t affected = by this: >>> >> >>> >> * Metrics=E2=80=93 we=E2=80=99ve had discussions about this many = moons ago with authors on both sides of the fence. Unfortunately I = can=E2=80=99t remember the counter arguments, and I=E2=80=99m still = looking for records of this conversation=E2=80=A6 I=E2=80=99ll get back = to you when I=E2=80=99ve found out more. >>> >> * Prefixes & Gateways: I=E2=80=99ve added a sentence to clarify = that AODVv2 doesn=E2=80=99t do RREQs for gateways, I hop that helps? >>> >> >>> >>> >>> >>> In which revision of the I-D do you plan on addressing those? >>> >>> >>> >> >>> >> If the discussions reach a conclusion by then, I=E2=80=99d be = glad to have them addressed by the next revision. >>> >> >>> >> Best regards, >>> >> Lotte >>> >> >>> >>> Best, >>> >>> >>> >>> Thomas >>> >>> >>> >>> >>> >>> >>> >>>> On Apr 5, 2016, at 12:53, Lotte Steenbrink = > = wrote: >>> >>>> >>> >>>> Hi all, >>> >>>> just a quick summary of what is and what isn=E2=80=99t included = in this update of the draft: >>> >>>> >>> >>>> DONE: >>> >>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>> >>>> * All JWD! comments (i.e. the critical ones) are resolved >>> >>>> * Out of 90 JWD and JWD! comments, 61 are resolved >>> >>>> * The revised security considerations [1] were added (with the = TODOs commented out) >>> >>>> * The following TODO from [1] was resolved:=20 >>> >>>> "This description MUST >>> >>>> include the reasons it was either unreasonable or out of = scope to >>> >>>> attempt to avoid these denial of service attacks." >>> >>>> * Section 9 now contains a statement that AODVv2 doesn=E2=80=99t = support RREQs for prefixes, I hope that clears things up for Thomas. >>> >>>> >>> >>>> TO DO: >>> >>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=20 >>> >>>> * Most notable of the 29 JWDs that are yet to be resolved: >>> >>>> + (is there some table that lists routes that are being waited = on? JWD) We decided to add a separate=20 >>> >>>> RREP table that lists them and I=E2=80=99ve = volunteered to write text for that, but we=E2=80=99re currently = discussing if/how >>> >>>> we might solve this without adding yet another = table. >>> >>>> >>> >>>> + We=E2=80=99re currently discussing the approaching the limit = thing. (i.e. >>> >>>> (There is no defined behavior here. Approaching the limit? = Section 6.5 outlines which messages are more important but now how to = decide to allow them to be transmitted or not. JWD=20 >>> >>>> and >>> >>>> (The undefined approaching the limit thing again JWD) etc >>> >>>> We=E2=80=99ve already clarified the wording = regarding what the limit is and how to prioritize the message types,=20 >>> >>>> what=E2=80=99s left is to define what = =E2=80=9Eapproaching=E2=80=9C means (and whether we need to talk about = approaching rather than >>> >>>> just saying =E2=80=9Ehere=E2=80=99s what to do when = you actually hit the limit"). >>> >>>> >>> >>>> + (I don=E2=80=99t want to spam the list with a = comprehensive list of all of them, but if you=E2=80=99re interested in = seeing them, >>> >>>> please do say so and I=E2=80=99ll send my copy of = Justin=E2=80=99s review containing all TODOs and DONEs to the list) >>> >>>> * some TODOs in security considerations (see [1]) >>> >>>> * since we're waiting for Chris=E2=80=99 feedback regarding the = revised 5444 multiplexer wording, that hasn=E2=80=99t changed yet. >>> >>>> >>> >>>> More details can be found in Appendix A. AODVv2 Draft Updates, = as well as the diff, of course. >>> >>>> >>> >>>> Best regards, >>> >>>> Lotte >>> >>>> >>> >>>> [1] Re: [manet] AODVv2: Security considerations update = https://www.ietf.org/mail-archive/web/manet/current/msg18458.html = >>> >>>> >>> >>>> >>> >>>>> Am 05.04.2016 um 12:19 schrieb internet-drafts@ietf.org = : >>> >>>>> >>> >>>>> >>> >>>>> 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-14.txt >>> >>>>> Pages : 80 >>> >>>>> Date : 2016-04-05 >>> >>>>> >>> >>>>> 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-14 = >>> >>>>> >>> >>>>> A diff from the previous version is available at: >>> >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-14 = >>> >>>>> >>> >>>>> >>> >>>>> 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/ = >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> 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 = --Apple-Mail=_1894BD07-49E4-47D2-9079-64C4E4BECCC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Looking= back over issues that I have raised, I am not sure that I saw any = replies to this, so I went looking in the I-D for some clarification and = some follow-up questions.

First, section 9 contains this throw-away = comment:

   Configuring the ENAR = as a default router is outside the scope of this
=    specification.

Either I do not understand what you = mean by =E2=80=9C=E2=80=A6as a default router=E2=80=A6=E2=80=9D or = there=E2=80=99s a layer of complexity (that I can guess at) which = you=E2=80=99re not telling, but which really should be called = out. 

My = guess would be, that a router inside the MANET will need to communicate = to (say) google, you would do a Route Discovery (RREQ/RREP) cycle and = the ENAR would return a route to  2a00:1450:4007:80e::2003 =E2=80=94 and then when = you 30s later need to communicate to (say) Facebook.com you would do a Route Discovery (RREQ/RREP) = cycle and the ENAR would return a route to 2a03:2880:20:4f22:face:b00c::25de. 

I.e. the =E2=80=9C=E2=80=A6= as default router=E2=80=A6=E2=80=9D means that you do not know of any = way of making it work such that the ENER an reply, to the first of these = two, with simply 0::0/0, and then have the routers in the MANET install = a route via the ENAR to destinations not inside the MANET?

What I am getting at = here is, that if I understand correctly then connectivity to =E2=80=9Cthe = Internet=E2=80=9D is very, very inefficiently supported =E2=80=94 or, = actually, more precisely that connectivity to any =E2=80=9Cexternal = network which can only be captured by a prefix which also includes = destinations inside the MANET=E2=80=9D is very inefficiently supported = (because you cannot install prefix routes to such a network).

If I am understanding = this correctly, then it deserves more elaboration than the throw-away = mention at the end of Section 9, cited above, and certainly this = paragraph from the applicability statement needs to correctly reflect = it:

   AODVv2 is designed for stub or disconnected = mobile ad hoc networks,
   i.e., = non-transit networks or those not connected to the internet.
   AODVv2 can, however, be configured to perform = gateway functions when
   attached to = external networks, as discussed in Section 9.

Second, section 7.1 specifies for = RREQs:

=    AddressList
=       Contains OrigAddr and TargAddr, the source = and destination
      = addresses of the IP packet for which a route is requested.
=       OrigAddr and TargAddr MUST be routable = unicast addresses.


Again, if I have understood correctly, = if a router has 255 hosts attached (say a /56), each of which need to = communicate with a server, then the router must end up generating 255 = RREQ/RREP cycles, even though it may already have an entry for the IP = address for the server?

The reason why I speculate that this is so is, that RREQ = forwarding installs the =E2=80=9Creverse route=E2=80=9D towards the = source, and if OrigAddr is "the source addresses = of the IP packet for which a route is requested=E2=80=9D address, i.e., = there is no way for the RREQ to request a route to the server =E2=80=9Cat = once=E2=80=9D on behalf of "the entire /56=E2=80=9D  behind = it?

Again, if = I am understanding this correctly, then it deserves a bit more = elaboration, notably a framing of the cases discussed in the above, and = a modulation of the statement from the applicability statement = that:

= AODVv2 can, however, be configured to perform gateway functions = when
    attached to external networks, as = discussed in 
Section 9.
Capturing these limitations of gateway = functionality?

The same, probably, also applies in the = opposite direction, i.e., in case a single =E2=80=9Csource=E2=80=9D = needs to communicate with many or all of a /56, behind a = router?

Best,

Thomas


On 07 Apr 2016, at 23:11, Thomas Heide = Clausen <ietf@thomasclausen.org> wrote:

On this whole = gateway issue, I am disturbed...most routers would have one-or-multiple = /64-or-shorter, one per non-Manet link (w/ hosts hanging off) delegated = to them, and not just a single /128.

Needing to communicate with many-to-all = hosts on a link is not uncommon (if the hosts are, e.g., environmental = controls in the same room), and the ability to "get the whole prefix = advertised at once" send an RREQ for the whole prefix - specifically, = for not 

Sent from my iPad

On 07 Apr 2016, at 22:19, Christopher Dearlove <christopher.dearlove@gmail.com> wrote:
Thanks, that addresses most = of the points I made.

Assuming that is that a packet reception for forwarding is = the only option you choose to allow. It's perfectly reasonable for an = implementation to think "wouldn't it be sensible to learn about a = gateway now for various reasons?".  Yes, there's the problem of = which subnet to look for (0.0.0.0/0 or something smaller). Yes, I can = imagine you don't want to define this now - unless of course someone in = the WG says they really want it. But I would say, don't close the door = on it, even if not doing it now.

(There are other possibilities that = might be useful one day. An RREQ that looks for more than one address = for example - you could trade latency and overhead by combining = RREQs.)

--  
Christopher = Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)

On 7 Apr 2016, at 18:49, Victoria Mercieca = <vmercieca0@gmail.com> wrote:

Hi Christopher,

On 7 = Apr 2016 1:55 pm, "Christopher Dearlove" <christopher.dearlove@gmail.com> wrote:
>
> [This time from a subscribed address.]
>
> You say you've added a sentence saying AODVv2 doesn't do RREQs for = gateways. What should have happened is a discussion on this list as to = why? is that hard? does anyone have a clever idea to make it not hard? = does anyone need that functionality? and so on.
>
> For example, here's something that superficially looks like it = might work. Does it, or does it introduce new problems? I don't know. = But this, and likely better ideas, just haven't had discussion here - = and I fear that the people who might have the better ideas have departed = unheard.
>
> So, a router wants a route to a.b.c.d, and sends an RREQ for that = (/32, or simply omit). Of course any router directly serving that = address just replies. But a router that is serving a.0.0.0/8 could reply = with that address. The originating router of course would use standard = IP maximum prefix length rules. Does that work? Does it help anyone? = Could a router reply a.b.c.d/32 and a.0.0.0/8 in one RREP? Or could it = be allowed to reply a.b.c.d/8 as a shorthand?

This is exactly what it does (based on the router client = entry corresponding to TargAddr, e.g if router client entry is = a.0.0.0/8, then the RREP contains a.b.c.d/8). Everyone receiving the = RREP can then install the route to a.0.0.0/8 and therefore avoid a = separate RREQ for (as an example) a.b.c.e in future. Similarly an RREQ = contains the prefix length associated with the router client entry = configured for OrigAddr, and routers processing the RREQ learn the route = to OrigAddrs prefix.

But you can't = intentionally send a RREQ for a prefix because the RREQ is created when = there's a packet to send, you know the destination address not the = prefix associated with it, so TargAddr is a.b.c.d/32. But even so, you = do end up learning a route to a prefix, if TargAddr is part of a router = client entry which is a prefix.

Kind = regards,
Victoria.

> And why can't a router = request a.b.0.0/16 - and possibly get an a.0.0.0/8 reply?
>
> Answers to all of those is "I don't know".  But we should have = been having those discussions.
>
> -- 
> Christopher Dearlove
> = christopher.dearlove@gmail.com
>
>
>
> --  
> Christopher Dearlove
> = christopher.dearlove@gmail.com (iPhone)
> = chris@mnemosyne.demon.co.uk (home)
> On 7 Apr 2016, at 15:49, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:
>
>> Hi Thomas,
>>
>>> Am 05.04.2016 um 20:07 schrieb = ietf@thomasclausen.org:
>>>
>>> Lotte,
>>>
>>> Thank you for this update. An impressive amount of changes = to the document, according to RFCdiff, and as I can see from your mail = that there is much more to come,
>>
>>
>> Thanks! I=E2=80=99m glad you=E2=80=99re seeing the progress = we=E2=80=99ve made. 
>>
>>> I hope that you forgive me for not jumping at a = blow-by-blow review until a version which the authors themselves = consider stable, is produced.
>>>
>>> On the point of =E2=80=9Cmuch more to come", there have = been quite a few comments raised by WG participants other than Mr. Dean = and Chris  (such as by myself, but not only) =E2=80=94 some of = which intersect some of the below, and for which I do not believe that a = satisfactory resolution has been developed, presented to the WG, and = confirmed.
>>
>>
>> I=E2=80=99m not quite sure which comments exactly you are = referring to? Your last comments that come to mind are the ones in these = threads:
>>
>> = https://www.ietf.org/mail-archive/web/manet/current/msg18055.html
>> = https://www.ietf.org/mail-archive/web/manet/current/msg18639.html
>>
>> You=E2=80=99ve announced to go through the former in your last = response to the latter, but as far as I can see you haven=E2=80=99t = gotten round to doing that and a lot of points you=E2=80=99ve brought up = have sparked ongoing discussions, so I=E2=80=99ve marked most of your = comments as =E2=80=9Cpending=E2=80=93 still in discussion=E2=80=9D in my = mind. 
>> Regarding the points you brought up that aren=E2=80=99t = affected by this:
>>
>> * Metrics=E2=80=93 we=E2=80=99ve had discussions about this = many moons ago with authors on both sides of the fence. Unfortunately I = can=E2=80=99t remember the counter arguments, and I=E2=80=99m still = looking for records of this conversation=E2=80=A6 I=E2=80=99ll get back = to you when I=E2=80=99ve found out more.
>> * Prefixes & Gateways: I=E2=80=99ve added a sentence = to clarify that AODVv2 doesn=E2=80=99t do RREQs for gateways, I hop that = helps?
>>
>>>
>>> In which revision of the I-D do you plan on addressing = those?
>>>
>>
>> If the discussions reach a conclusion by then, I=E2=80=99d be = glad to have them addressed by the next revision.
>>
>> Best regards,
>> Lotte
>>
>>> Best,
>>>
>>> Thomas
>>>
>>>
>>>
>>>> On Apr 5, 2016, at 12:53, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:
>>>>
>>>> Hi all,
>>>> just a quick summary of what is and what isn=E2=80=99t = included in this update of the draft:
>>>>
>>>> DONE:
>>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94
>>>> * All JWD! comments (i.e. the critical ones) are = resolved
>>>> * Out of 90 JWD and JWD! comments, 61 are resolved
>>>> * The revised security considerations [1] were added = (with the TODOs commented out)
>>>> * The following TODO from [1] was resolved: 
>>>>    "This description MUST
>>>>    include the reasons it was either = unreasonable or out of scope to
>>>>    attempt to avoid these denial of service = attacks."
>>>> * Section 9 now contains a statement that AODVv2 = doesn=E2=80=99t support RREQs for prefixes, I hope that clears things up = for Thomas.
>>>>
>>>> TO DO:
>>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94 
= >>>> * Most notable of the 29 JWDs that are yet to be = resolved:
>>>> + (is there some table that lists routes that are = being waited on? JWD) We decided to add a separate 
>>>>            RREP table = that lists them and I=E2=80=99ve volunteered to write text for that, but = we=E2=80=99re currently discussing if/how
>>>>            we might solve = this without adding yet another table.
>>>>
>>>> + We=E2=80=99re currently discussing the approaching = the limit thing. (i.e.
>>>>    (There is no defined behavior here. = Approaching the limit? Section 6.5 outlines which messages are more = important but now how to decide to allow them to be transmitted or not. = JWD 
>>>>   and
>>>>   (The undefined approaching the limit thing = again JWD) etc
>>>>            We=E2=80=99ve = already clarified the wording regarding what the limit is and how to = prioritize the message types, 
>>>>            what=E2=80=99s = left is to define what =E2=80=9Eapproaching=E2=80=9C means (and whether = we need to talk about approaching rather than
>>>>            just saying = =E2=80=9Ehere=E2=80=99s what to do when you actually hit the limit").
>>>>
>>>>     + (I don=E2=80=99t want to spam the = list with a comprehensive list of all of them, but if you=E2=80=99re = interested in seeing them,
>>>>            please do say = so and I=E2=80=99ll send my copy of Justin=E2=80=99s review containing = all TODOs and DONEs to the list)
>>>> * some TODOs in security considerations (see [1])
>>>> * since we're waiting for Chris=E2=80=99 feedback = regarding the revised 5444 multiplexer wording, that hasn=E2=80=99t = changed yet.
>>>>
>>>> More details can be found in Appendix A.  = AODVv2 Draft Updates, as well as the diff, of course.
>>>>
>>>> Best regards,
>>>> Lotte
>>>>
>>>> [1] Re: [manet] AODVv2: Security considerations = update https://www.ietf.org/mail-archive/web/manet/current/msg18458.ht= ml
>>>>
>>>>
>>>>> Am 05.04.2016 um 12:19 schrieb internet-drafts@ietf.org:
>>>>>
>>>>>
>>>>> 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
>>>>> =             &n= bsp;           &nbs= p;Stan Ratliff
>>>>> =             &n= bsp;           &nbs= p;John Dowdell
>>>>> =             &n= bsp;           &nbs= p;Lotte Steenbrink
>>>>> =             &n= bsp;           &nbs= p;Victoria Mercieca
>>>>> Filename =        : = draft-ietf-manet-aodvv2-14.txt
>>>>> Pages =           : 80
>>>>> Date =            : = 2016-04-05
>>>>>
>>>>> 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-14
>>>>>
>>>>> A diff from the previous version is available = at:
>>>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-14
>>>>>
>>>>>
>>>>> 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/
>>>>>
>>>>> _______________________________________________
>>>>> 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

= --Apple-Mail=_1894BD07-49E4-47D2-9079-64C4E4BECCC1-- From nobody Wed Apr 20 02:14:31 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 5FB1B12DACC for ; Wed, 20 Apr 2016 02:14:29 -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 uQesjtBsOuIi for ; Wed, 20 Apr 2016 02:14:26 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [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 572F712E0D8 for ; Wed, 20 Apr 2016 02:14:24 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,509,1454976000"; d="scan'208,217"; a="62485036" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 20 Apr 2016 10:14:19 +0100 X-IronPort-AV: E=Sophos;i="5.24,509,1454976000"; d="scan'208,217";a="114733580" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 20 Apr 2016 10:14:19 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Wed, 20 Apr 2016 10:14:19 +0100 From: "Dearlove, Christopher (UK)" To: Jiazi YI , manet Thread-Topic: [manet] Comments on rfc5444-usage Thread-Index: AQHRmjwrTbgcPqBlCUCZlC026bIPO5+SkJ8Q Date: Wed, 20 Apr 2016 09:14:17 +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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AEF2CGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Comments on 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: Wed, 20 Apr 2016 09:14:29 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AEF2CGLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 RXhjZWxsZW50IHBvaW50IGFib3V0IGNvbnNpc3RlbmN5IG9mIHBhY2tldCBzZXF1ZW5jZSBudW1i ZXJzLiBJIHRoaW5rIHRoYXQgYWZ0ZXIgdGhlIE1BWSBhZGQsIHdlIHNob3VsZCBoYXZlIGFuIGlm IGFkZGVkIE1VU1QgY2xhdXNlLg0KDQpXaXRoIHJlZ2FyZCB0byB0aGUgaG93IHRvIGtub3cgaWYg YWRkIGJ5IG11bHRpcGxleGVyLiBJIHRoaW5rIHRoYXQgd291bGQgbWFpbmx5IGJlIGJ5IGV4dGVu c2lvbiAtIGlzIHRoaXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBtdWx0aXBsZXhlciAodGhlbiB0aGUg bXVsdGlwbGV4ZXIgc2hvdWxkIHJlbW92ZSkuIFRoZXJl4oCZcyBhIHNsaWdodCBpc3N1ZSBvdmVy IDcxODIsIGJ1dCB0aGVyZSBpdOKAmXMgcmVhbGx5IGFuIGltcGxlbWVudGF0aW9uIGlzc3VlLiBB bmQgdGhpcyBpcyByZWFsbHkgZm9yIHRoZSBiZW5lZml0IG9mIDcxODIuIFdpbGwgdGhpbmsgYWJv dXQgd29yZGluZy4NCg0KRXh0ZW5kZWQgdHlwZSBoYXMgYmVlbiBkaXNjdXNzZWQgaW4gYW5vdGhl ciBjb3VwbGUgb2YgZW1haWxzLiBUaGlzIG1lYW5zIGV4dGVuZGVkIHR5cGUsIG5vdCB0eXBlIGV4 dGVuc2lvbiwgYnV0IGFjdHVhbGx5IDU0NDQgYWxtb3N0IGJ1dCBub3QgcXVpdGUgY2FsbHMgdGhp cyBhIGZ1bGwgdHlwZS4gKEl04oCZcyBkZWZpbmVkIGJ5IGEgc3ltYm9saWMgbmFtZSwgbm90IHRo YXQgcGhyYXNlLikgU28gd2Ugc2hvdWxkIHN3aXRjaCB0byBmdWxsIHR5cGUgYW5kIGFkZCBhICBj b21tZW50IHRvIHRlcm1pbm9sb2d5LiBBbmQgbWF5YmUgY2hlY2sgaWYgd2XigJl2ZSB1c2VkIGV4 dGVuZGVkIHR5cGUgZWxzZXdoZXJlIChJIG1lYW4gb3RoZXIgUkZDcykuIElmIHNvIGNvbW1lbnQg c29tZXRpbWVzIHJlZmVycmVkIHRvIGFzIGV4dGVuZGVkIHR5cGUsIGlmIG5vdCwgbm90Lg0KDQpU byByZWxhdGUgc2F5IHRocmVlIGFkZHJlc3NlcyBzeW1tZXRyaWNhbGx5LCB3ZSBjb3VsZCBjcmVh dGUgYW4gYXNzb2NpYXRpb24gVExWLCB2YXJpb3VzIGRlc2lnbnMgYmVpbmcgcG9zc2libGUuIEZv ciBleGFtcGxlIFRMViB0eXBlIChvciBmdWxsIHR5cGUpIGluZGljYXRlcyBhc3NvY2lhdGlvbiBt ZWFuaW5nLCBpZiBuZWNlc3NhcnkgVExWIHZhbHVlIGlzIHRoZSBncm91cCBudW1iZXIuIFdlIGNv bnNpZGVyZWQgdGhpcyBpbiBOSERQIHdoZXJlIHdlIHJlcG9ydCBhZGRyZXNzZXMgb2YgbmVpZ2hi b3VycywgYnV0IGRpc2NhcmQgdGhlIChhdmFpbGFibGUpIGluZm9ybWF0aW9uIGFib3V0IHdoaWNo IG9mIHRob3NlIGFkZHJlc3NlcyBiZWxvbmcgdG8gd2hpY2ggbmVpZ2hib3VyLiBCdXQgd2UgZGVj aWRlZCBub3QgdG8gYWRkIGl0IGFzIG5vIG9uZSBoYWQgYSBuZWVkIGZvciBpdC4gV2l0aCBvZiBj b3Vyc2UgdGhlIG9wdGlvbiB0byBhZGQgaWYgdGhhdCBjaGFuZ2VkIChoYXNu4oCZdCBkb25lIHNv IGFzIGZhciBhcyBJIGtub3cpLg0KDQpJZiB5b3Ugd2FudCBhbiBhc3ltbWV0cmljIHJlbGF0aW9u c2hpcCwgdGhhdOKAmXMgbWVzc2llci4gVGhvdWdoIGFueXRoaW5nIGNvdWxkIGJlIGRvbmUgaWYg eW91IHRyeSBoYXJkIGVub3VnaC4gSSB0aGluayBpZiBzb21lb25lIGhhcyBhIGNhc2UsIGxldOKA mXMgbGF5IG91dCB0aGUgcHJvcGVydGllcyBuZWVkZWQgYW5kIGJyYWluc3Rvcm0gYmVzdCB3YXkg dG8gcmVwcmVzZW50LiBUaGF0IG1pZ2h0IHR1cm4gb3V0IHRvIGJlIGFkZHJlc3MgaW4gdmFsdWUs IHdoaWNoIGlzbuKAmXQgZWFzaWx5IGNvbXByZXNzaWJsZSAodGhlcmUgYXJlIGNvbnN0cmFpbnRz IG9uIGRlc2lnbikuIEFuZCBpZiB0aGUgYWRkcmVzc2VzIGFyZSBkaWZmZXJlbnQgc2l6ZXMgKGUu Zy4gSVAgYW5kIE1BQyAtIHRob3VnaCB0aGVyZSBuZWVkcyB0byBiZSBhIGdvb2QgY2FzZSBmb3Ig dGhhdCAtIG9yIElQdjQgYW5kIElQdjYpIHRoZW4gdGhlcmUgaXNu4oCZdCBhbiBhbHRlcm5hdGl2 ZSAodGhhdCBJIGNhbiBzZWUpLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQ cmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9y YXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAg RTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1z Zm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00y IDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2Fp Pg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBp biBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5 IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IG1hbmV0 IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppYXppIFlJDQpT ZW50OiAxOSBBcHJpbCAyMDE2IDE0OjA1DQpUbzogbWFuZXQNClN1YmplY3Q6IFttYW5ldF0gQ29t bWVudHMgb24gcmZjNTQ0NC11c2FnZQ0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdl IG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFu IGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdo ZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRz IG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3Ug Y2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDov L2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0 cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBz dXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50 LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9E ZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCioqKiBXQVJOSU5HICoq Kg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRl IG91ciBvcmdhbml6YXRpb24uDQoNCkhpLA0KDQpJIGp1c3QgaGFkIGEgcmV2aWV3IG9uIHRoZSBy ZmM1NDQ0LXVzYWdlIGRyYWZ0ICgtMDMpLg0KDQpJIHRoaW5rIHRoZSBkcmFmdCBpcyBpbiBnb29k IHNoYXBlIGFuZCBlYXN5IHRvIHVuZGVyc3RhbmQgKEkgbmVlZCB0byBub3RlIGhlcmUgdGhhdCBJ IGhhdmVuIGJlZW4gd29ya2luZyB3aXRoIFJGQzU0NDQgaW4gdGhlIHBhc3QgYSBmZXcgeWVhcnMs IHNvIEkgZG9uJ3QgaGF2ZSBhIHBhaXIgb2YgZnJlc2ggZXllcyBvbiBpdCkuDQoNCnNlY3Rpb24g NC4yLA0KDQpidWxsZXQgMToNCg0KIE1lc3NhZ2VzIE1BWSBhbHNvIGJlIGZvcndhcmRlZCBieSB0 aGVpciBvd25pbmcgcHJvdG9jb2wuDQogICAgICBJdCBpcyBzdHJvbmdseSBSRUNPTU1FTkRFRCB0 aGF0IG1lc3NhZ2VzIGFyZSBub3QgbW9kaWZpZWQgaW4gdGhlDQogICAgICBsYXR0ZXIgY2FzZS4N Cg0KSSBoYXZlIG1lbnRpb25lZCB0aGlzIGluIGFub3RoZXIgdGhyZWFkLCByZWdhcmRpbmcgdGhl IHJlYWN0aXZlIHByb3RvY29sLiBJIHRoaW5rIGl0J3MgT0sgdG8gcHV0IGEgUkVDT01NRU5EL1NI T1VMRCBoZXJlIChwcm9iYWJseSBub3QgInN0cm9uZ2x5Ij8pLCBidXQgaXQgd291bGQgYmUgZ3Jl YXQgaWYgd2UgY2FuIHB1dCBhIGZldyB3b3JkcyBleHBsYWluaW5nIHRoZSB0cmFkZW9mZnMuDQoN CmJ1bGxldCA1Og0KDQpJZiByZXF1ZXN0ZWQgYnkgYSBwcm90b2NvbCwgdGhlIG11bHRpcGxleGVy IFNIT1VMRCwgYW5kIG90aGVyd2lzZQ0KICAgICAgTUFZLCBpbmNsdWRlIGEgUGFja2V0IFNlcXVl bmNlIE51bWJlciBpbiB0aGUgcGFja2V0Lg0KDQpBbHRob3VnaCBpdCdzIGEgTUFZL1NIT1VMRCBo ZXJlLCBJIHRoaW5rIHdlIG5lZWQgdG8gYmUgY2xlYXIgdGhhdCB0aGUgZXhpc3RlbmNlIG9mIHBh Y2tldCBzZXF1ZW5jZSBudW1iZXIgbXVzdCBiZSBjb25zaXN0ZW50LCBpLmUuLCB0aGUgbXVsdGlw bGV4ZXIgbXVzdCBub3QgYWRkICNzZXEgaW4gdGhpcyB0cmFuc21pc3Npb24sIGFuZCBvbWl0IHRo ZSAjc2VxIGluIHRoZSBuZXh0IHRyYW5zbWlzc2lvbiAoYmVjYXVzZSBvZiBNVFUgbGltaXRhdGlv biwgZXRjLikuDQoNCnN0aWxsIHNlY3Rpb24gNC4yOg0KDQpUaGUgZGVtdWx0aXBsZXhlciBNVVNU IHJlbW92ZSBhbnkgVExWcyBhZGRlZCB0byB0aGUgbWVzc2FnZSBieSB0aGUNCiAgICAgIG11bHRp cGxleGVyLiAgVGhlIG1lc3NhZ2UgTVVTVCBiZSBwYXNzZWQgb24gdG8gdGhlIHByb3RvY29sDQog ICAgICBleGFjdGx5IGFzIHJlY2VpdmVkIGZyb20gKGFub3RoZXIgaW5zdGFuY2Ugb2YpIHRoZSBw cm90b2NvbC4NCg0KSG93IGEgZGVtdWx0aXBsZXhlciBrbm93IGlmIGEgVExWIGlzIGFkZGVkIGJ5 IGFub3RoZXIgbXVsdGlwbGV4ZXIsIGVzcGVjaWFsbHkgd2UgaGF2ZSBkaWZmZXJlbnQgaW1wbGVt ZW50YXRpb25zPyBJcyB0aGVyZSBhbnkgZmxhZyBvciBzaWduYWxzIHRoYXQgd2UgY2FuIGNvdW50 IG9uPw0KDQoNCnNlY3Rpb24gNC41Og0KDQogICBBIG1lc3NhZ2UgKGV4Y2x1ZGluZyB0aGUgTWVz c2FnZSBIZWFkZXIpIGNhbiB0aHVzIGJlIHJlcHJlc2VudGVkIGJ5DQogICB0d28sIHBvc3NpYmx5 IG11bHRpdmFsdWVkLCBtYXBzOg0KICAgbyAgTWVzc2FnZTogKGV4dGVuZGVkIHR5cGUpIC0+IChs ZW5ndGgsIHZhbHVlKQ0KICAgbyAgQWRkcmVzczogKGFkZHJlc3MsIGV4dGVuZGVkIHR5cGUpIC0+ IChsZW5ndGgsIHZhbHVlKQ0KDQpXaHkgb25seSBleHRlbmRlZCB0eXBlIGhlcmUgKHdoaWNoIGlz IG9wdGlvbmFsKT8gV2hhdCBhYm91dCB0aGUgdGx2LXR5cGU/DQoNCkFuZCBvbmUgbW9yZSBxdWVz dGlvbjoNCklzIGl0IHBvc3NpYmxlIHRvIGJ1aWxkIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHR3byBh ZGRyZXNzZXMgaW4gdGhlIGFkZHJlc3MgYmxvY2s/IEZvciBleGFtcGxlLCB3ZSBoYXZlDQogICAg LSBhZGRyZXNzLUEsIGFkZHJlc3MtQiwgYWRkcmVzcy1DIHdpdGggdGx2LXR5cGUtWCwNCiAgICAt IGFkZHJlc3MtRCwgYWRkcmVzcy1FLCBhZGRyZXNzLUYgd2l0aCB0bHYtdHlwZS1ZLg0KDQpDYW4g d2Ugc2V0IHVwIGEgcmVsYXRpb24gc2F5aW5nIHRoYXQgYWRkcmVzcy1BIGlzIHJlbGF0ZWQgdG8g YWRkcmVzcy1ELCBhZGRyZXNzLUU/IEZvciBleGFtcGxlLCB0aGUgZ2F0ZXdheSBBIHN1cHBvcnRz IHNvdXJjZSBhZGRyZXNzIHdpdGggcHJlZml4IEQsIEU/DQpXZSBjYW4gZG8gc28gYnkgZW5jb2Rp bmcgdGhlIGFkZHJlc3NlcyBhcyBkYXRhIGluIFRMVnMsIGJ1dCBpdCBzZWVtcyB0aGF0IGl0J3Mg bm90IHJlY29tbWVuZGVkLg0KDQpyZWdhcmRzDQoNCkppYXppDQoNCg0KDQoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpU aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50 ZW5kZWQKcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3Rl bSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0 IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMg dG8gYW55IG90aGVyIHBlcnNvbi4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AEF2CGLKXM0002VGREEN_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkV4Y2VsbGVudCBwb2ludCBhYm91dCBjb25zaXN0ZW5jeSBv ZiBwYWNrZXQgc2VxdWVuY2UgbnVtYmVycy4gSSB0aGluayB0aGF0IGFmdGVyIHRoZSBNQVkgYWRk LCB3ZSBzaG91bGQgaGF2ZSBhbiBpZiBhZGRlZCBNVVNUIGNsYXVzZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldpdGgg cmVnYXJkIHRvIHRoZSBob3cgdG8ga25vdyBpZiBhZGQgYnkgbXVsdGlwbGV4ZXIuIEkgdGhpbmsg dGhhdCB3b3VsZCBtYWlubHkgYmUgYnkgZXh0ZW5zaW9uIC0gaXMgdGhpcyBhbiBleHRlbnNpb24g dG8gdGhlIG11bHRpcGxleGVyICh0aGVuIHRoZSBtdWx0aXBsZXhlcg0KIHNob3VsZCByZW1vdmUp LiBUaGVyZeKAmXMgYSBzbGlnaHQgaXNzdWUgb3ZlciA3MTgyLCBidXQgdGhlcmUgaXTigJlzIHJl YWxseSBhbiBpbXBsZW1lbnRhdGlvbiBpc3N1ZS4gQW5kIHRoaXMgaXMgcmVhbGx5IGZvciB0aGUg YmVuZWZpdCBvZiA3MTgyLiBXaWxsIHRoaW5rIGFib3V0IHdvcmRpbmcuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FeHRl bmRlZCB0eXBlIGhhcyBiZWVuIGRpc2N1c3NlZCBpbiBhbm90aGVyIGNvdXBsZSBvZiBlbWFpbHMu IFRoaXMgbWVhbnMgZXh0ZW5kZWQgdHlwZSwgbm90IHR5cGUgZXh0ZW5zaW9uLCBidXQgYWN0dWFs bHkgNTQ0NCBhbG1vc3QgYnV0IG5vdCBxdWl0ZSBjYWxscyB0aGlzDQogYSBmdWxsIHR5cGUuIChJ dOKAmXMgZGVmaW5lZCBieSBhIHN5bWJvbGljIG5hbWUsIG5vdCB0aGF0IHBocmFzZS4pIFNvIHdl IHNob3VsZCBzd2l0Y2ggdG8gZnVsbCB0eXBlIGFuZCBhZGQgYSZuYnNwOyBjb21tZW50IHRvIHRl cm1pbm9sb2d5LiBBbmQgbWF5YmUgY2hlY2sgaWYgd2XigJl2ZSB1c2VkIGV4dGVuZGVkIHR5cGUg ZWxzZXdoZXJlIChJIG1lYW4gb3RoZXIgUkZDcykuIElmIHNvIGNvbW1lbnQgc29tZXRpbWVzIHJl ZmVycmVkIHRvIGFzIGV4dGVuZGVkDQogdHlwZSwgaWYgbm90LCBub3QuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UbyBy ZWxhdGUgc2F5IHRocmVlIGFkZHJlc3NlcyBzeW1tZXRyaWNhbGx5LCB3ZSBjb3VsZCBjcmVhdGUg YW4gYXNzb2NpYXRpb24gVExWLCB2YXJpb3VzIGRlc2lnbnMgYmVpbmcgcG9zc2libGUuIEZvciBl eGFtcGxlIFRMViB0eXBlIChvciBmdWxsIHR5cGUpIGluZGljYXRlcw0KIGFzc29jaWF0aW9uIG1l YW5pbmcsIGlmIG5lY2Vzc2FyeSBUTFYgdmFsdWUgaXMgdGhlIGdyb3VwIG51bWJlci4gV2UgY29u c2lkZXJlZCB0aGlzIGluIE5IRFAgd2hlcmUgd2UgcmVwb3J0IGFkZHJlc3NlcyBvZiBuZWlnaGJv dXJzLCBidXQgZGlzY2FyZCB0aGUgKGF2YWlsYWJsZSkgaW5mb3JtYXRpb24gYWJvdXQgd2hpY2gg b2YgdGhvc2UgYWRkcmVzc2VzIGJlbG9uZyB0byB3aGljaCBuZWlnaGJvdXIuIEJ1dCB3ZSBkZWNp ZGVkIG5vdCB0byBhZGQNCiBpdCBhcyBubyBvbmUgaGFkIGEgbmVlZCBmb3IgaXQuIFdpdGggb2Yg Y291cnNlIHRoZSBvcHRpb24gdG8gYWRkIGlmIHRoYXQgY2hhbmdlZCAoaGFzbuKAmXQgZG9uZSBz byBhcyBmYXIgYXMgSSBrbm93KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHlvdSB3YW50IGFuIGFzeW1tZXRyaWMg cmVsYXRpb25zaGlwLCB0aGF04oCZcyBtZXNzaWVyLiBUaG91Z2ggYW55dGhpbmcgY291bGQgYmUg ZG9uZSBpZiB5b3UgdHJ5IGhhcmQgZW5vdWdoLiBJIHRoaW5rIGlmIHNvbWVvbmUgaGFzIGEgY2Fz ZSwgbGV04oCZcyBsYXkgb3V0IHRoZQ0KIHByb3BlcnRpZXMgbmVlZGVkIGFuZCBicmFpbnN0b3Jt IGJlc3Qgd2F5IHRvIHJlcHJlc2VudC4gVGhhdCBtaWdodCB0dXJuIG91dCB0byBiZSBhZGRyZXNz IGluIHZhbHVlLCB3aGljaCBpc27igJl0IGVhc2lseSBjb21wcmVzc2libGUgKHRoZXJlIGFyZSBj b25zdHJhaW50cyBvbiBkZXNpZ24pLiBBbmQgaWYgdGhlIGFkZHJlc3NlcyBhcmUgZGlmZmVyZW50 IHNpemVzIChlLmcuIElQIGFuZCBNQUMgLSB0aG91Z2ggdGhlcmUgbmVlZHMgdG8gYmUgYSBnb29k DQogY2FzZSBmb3IgdGhhdCAtIG9yIElQdjQgYW5kIElQdjYpIHRoZW4gdGhlcmUgaXNu4oCZdCBh biBhbHRlcm5hdGl2ZSAodGhhdCBJIGNhbiBzZWUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5p b3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu Y2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQy MTk0ICZuYnNwO3wgJm5ic3A7PGI+RToNCjwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxv dmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4N Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBB cHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJh ZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3 LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5 c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5n bGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJl c2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1hbmV0 IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Smlh emkgWUk8YnI+DQo8Yj5TZW50OjwvYj4gMTkgQXByaWwgMjAxNiAxNDowNTxicj4NCjxiPlRvOjwv Yj4gbWFuZXQ8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW21hbmV0XSBDb21tZW50cyBvbiByZmM1NDQ0 LXVzYWdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFk ZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50 ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MzMzOTcyIj4qKiogV0FSTklORyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVt PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9y aWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4 dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRl ciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBh bnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G b3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25n PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+ PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIi PiB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGlj ayA8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9z ZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwvYT4u PC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48 YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBw bGVhc2UgZm9sbG93DQo8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29t L2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUy MFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+ PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzoxLjBwdCA0LjBwdCAxLjBwdCA0LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50 ZXIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPio8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qKg0KPC9zcGFuPjwvc3Ryb25nPjwv c3Bhbj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldBUk5JTkcNCjwvc3Bhbj48 L3N0cm9uZz48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qKio8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RVhU RVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBv cmdhbml6YXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBqdXN0IGhhZCBhIHJl dmlldyBvbiB0aGUgcmZjNTQ0NC11c2FnZSBkcmFmdCAoLTAzKS4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgZHJh ZnQgaXMgaW4gZ29vZCBzaGFwZSBhbmQgZWFzeSB0byB1bmRlcnN0YW5kIChJIG5lZWQgdG8gbm90 ZSBoZXJlIHRoYXQgSSBoYXZlbiBiZWVuIHdvcmtpbmcgd2l0aCBSRkM1NDQ0IGluIHRoZSBwYXN0 IGEgZmV3IHllYXJzLCBzbyBJIGRvbid0IGhhdmUgYSBwYWlyIG9mIGZyZXNoIGV5ZXMgb24gaXQp LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5z ZWN0aW9uIDQuMiw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+YnVsbGV0IDE6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtNZXNzYWdlcyBNQVkgYWxzbyBiZSBm b3J3YXJkZWQgYnkgdGhlaXIgb3duaW5nIHByb3RvY29sLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7IEl0IGlzIHN0cm9uZ2x5IFJFQ09NTUVOREVEIHRoYXQgbWVzc2FnZXMgYXJlIG5vdCBtb2Rp ZmllZCBpbiB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBsYXR0ZXIgY2FzZS48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg aGF2ZSBtZW50aW9uZWQgdGhpcyBpbiBhbm90aGVyIHRocmVhZCwgcmVnYXJkaW5nIHRoZSByZWFj dGl2ZSBwcm90b2NvbC4gSSB0aGluayBpdCdzIE9LIHRvIHB1dCBhIFJFQ09NTUVORC9TSE9VTEQg aGVyZSAocHJvYmFibHkgbm90ICZxdW90O3N0cm9uZ2x5JnF1b3Q7PyksIGJ1dCBpdCB3b3VsZCBi ZSBncmVhdCBpZiB3ZSBjYW4gcHV0IGEgZmV3IHdvcmRzIGV4cGxhaW5pbmcgdGhlIHRyYWRlb2Zm cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5idWxsZXQgNTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgcmVxdWVzdGVkIGJ5IGEgcHJvdG9jb2wsIHRo ZSBtdWx0aXBsZXhlciBTSE9VTEQsIGFuZCBvdGhlcndpc2U8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyBNQVksIGluY2x1ZGUgYSBQYWNrZXQgU2VxdWVuY2UgTnVtYmVyIGluIHRoZSBwYWNrZXQu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbHRob3VnaCBpdCdzIGEgTUFZL1NIT1VMRCBoZXJlLCBJIHRoaW5rIHdlIG5l ZWQgdG8gYmUgY2xlYXIgdGhhdCB0aGUgZXhpc3RlbmNlIG9mIHBhY2tldCBzZXF1ZW5jZSBudW1i ZXIgbXVzdCBiZSBjb25zaXN0ZW50LCBpLmUuLCB0aGUgbXVsdGlwbGV4ZXIgbXVzdCBub3QgYWRk ICNzZXEgaW4gdGhpcyB0cmFuc21pc3Npb24sIGFuZCBvbWl0IHRoZSAjc2VxIGluIHRoZSBuZXh0 IHRyYW5zbWlzc2lvbiAoYmVjYXVzZQ0KIG9mIE1UVSBsaW1pdGF0aW9uLCBldGMuKS4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c3Rp bGwgc2VjdGlvbiA0LjI6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZGVtdWx0aXBsZXhlciBNVVNUIHJlbW92ZSBh bnkgVExWcyBhZGRlZCB0byB0aGUgbWVzc2FnZSBieSB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyBtdWx0aXBsZXhlci4mbmJzcDsgVGhlIG1lc3NhZ2UgTVVTVCBiZSBwYXNzZWQgb24gdG8g dGhlIHByb3RvY29sPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgZXhhY3RseSBhcyByZWNlaXZl ZCBmcm9tIChhbm90aGVyIGluc3RhbmNlIG9mKSB0aGUgcHJvdG9jb2wuPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgYSBkZW11 bHRpcGxleGVyIGtub3cgaWYgYSBUTFYgaXMgYWRkZWQgYnkgYW5vdGhlciBtdWx0aXBsZXhlciwg ZXNwZWNpYWxseSB3ZSBoYXZlIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnM/IElzIHRoZXJlIGFu eSBmbGFnIG9yIHNpZ25hbHMgdGhhdCB3ZSBjYW4gY291bnQgb24/ICZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2Vj dGlvbiA0LjU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7QSBtZXNzYWdlIChleGNsdWRpbmcgdGhl IE1lc3NhZ2UgSGVhZGVyKSBjYW4gdGh1cyBiZSByZXByZXNlbnRlZCBieTxicj4NCiZuYnNwOyAm bmJzcDt0d28sIHBvc3NpYmx5IG11bHRpdmFsdWVkLCBtYXBzOjxicj4NCiZuYnNwOyAmbmJzcDtv ICZuYnNwO01lc3NhZ2U6IChleHRlbmRlZCB0eXBlKSAtJmd0OyAobGVuZ3RoLCB2YWx1ZSk8YnI+ DQombmJzcDsgJm5ic3A7byAmbmJzcDtBZGRyZXNzOiAoYWRkcmVzcywgZXh0ZW5kZWQgdHlwZSkg LSZndDsgKGxlbmd0aCwgdmFsdWUpPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoeSBvbmx5IGV4dGVuZGVkIHR5cGUg aGVyZSAod2hpY2ggaXMgb3B0aW9uYWwpPyBXaGF0IGFib3V0IHRoZSB0bHYtdHlwZT88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIG9uZSBt b3JlIHF1ZXN0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SXMgaXQgcG9zc2libGUgdG8gYnVpbGQgcmVsYXRpb25zaGlwIGJldHdlZW4gdHdv IGFkZHJlc3NlcyBpbiB0aGUgYWRkcmVzcyBibG9jaz8gRm9yIGV4YW1wbGUsIHdlIGhhdmUmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDsgLSBhZGRyZXNzLUEsIGFkZHJlc3MtQiwgYWRkcmVzcy1DIHdpdGggdGx2LXR5 cGUtWCwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsgLSBhZGRyZXNzLUQsIGFkZHJlc3MtRSwgYWRkcmVzcy1GIHdp dGggdGx2LXR5cGUtWS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q2FuIHdlIHNldCB1cCBhIHJlbGF0aW9uIHNheWluZyB0aGF0IGFk ZHJlc3MtQSBpcyByZWxhdGVkIHRvIGFkZHJlc3MtRCwgYWRkcmVzcy1FPyBGb3IgZXhhbXBsZSwg dGhlIGdhdGV3YXkgQSBzdXBwb3J0cyBzb3VyY2UgYWRkcmVzcyB3aXRoIHByZWZpeCBELCBFPyZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2UgY2FuIGRvIHNvIGJ5IGVuY29kaW5nIHRoZSBhZGRyZXNzZXMgYXMgZGF0YSBpbiBUTFZzLCBi dXQgaXQgc2VlbXMgdGhhdCBpdCdzIG5vdCByZWNvbW1lbmRlZC4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVnYXJkczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaWF6aTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+KioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8 YnI+ClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRo ZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZy b20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj4KWW91IHNob3VsZCBub3Qg Y29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcjxicj4KZGlz dHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+CioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq PC9wPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AEF2CGLKXM0002VGREEN_-- From nobody Wed Apr 20 02:50: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 9E58912DACF for ; Wed, 20 Apr 2016 02:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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, NORMAL_HTTP_TO_IP=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 rdopjYiHTNts for ; Wed, 20 Apr 2016 02:50:17 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 B51B312DE9C for ; Wed, 20 Apr 2016 02:50:12 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id n62so52446216vkb.0 for ; Wed, 20 Apr 2016 02:50:12 -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=IjKQHtx8EHHU/XTJjN/O3RTzDN4UmmVvKThU0/WibRA=; b=AzjmMhG9WEPV7ApQ9W1eeRcKglxRQbTupvvqy8GJ2vJeTZNz5hkAYADy7xDMlFG80/ nEhBIO92KrNiwvBCsQHKTeSeWHFd0OIBGXGNWg+a8seTaP7vmaLB5bDHu8HkQ/EMlPEM KaIMj7lkGrXWK5MVv0uEZjktAx11pJAI6ZmOU2pbHQNZDiFBqWGF4XP2LG0MpeRbUY/g RWcIzEqEOwlt1v8pTEBfdKUw1dsW2nyzZXXU1uQUfIjvjR7UfUctWU/xAR3XOTqKW6ZE CrBzrSrewU2EJVXDDd6N/Zyh0jYjFGvYE8UbjKd8QzcxYcxtUx5Q3UpLVJiO7exO9b25 aqYw== 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=IjKQHtx8EHHU/XTJjN/O3RTzDN4UmmVvKThU0/WibRA=; b=XLCJV0Dh9J07p98Hjyn9HewLdCYP9Kr0GKOr1B3lRzoir3QJWsnT2lqaNvZrqKSO3O yKUtJ9hw+Tc0WTdXj7ryvjuC9sGiSZityaMN4Tec8oqBwQIxmNi0JF7ddO7TpgIByXda eF6lQP2zerMQpobx7o9PBgPa4SGS1ZvOPAeMIa2AlRjafnvOMFplAG8x9HhT40rDj54p KThlzf1T+lRKVxxwDuXN1Jai8GM3lfpZLgLZBcwqnfKxWhRami65jAKw9nvl/VzFWVnJ 5WiS4bkGG9GCQUKg3fcioY448wupYBhHBfikDvTFg5uhDpMOtibLEE4t9QjUxGNlztAR 4wXQ== X-Gm-Message-State: AOPr4FUyR0xRtgSgskIzv9BfRcuNC70Q+gxrsvqsSjVNyhhAw6P4TKYMk9HLLXxPiLoCZ1DFy8bLJsSF9ZA5eA== MIME-Version: 1.0 X-Received: by 10.176.4.20 with SMTP id 20mr4194929uav.125.1461145811837; Wed, 20 Apr 2016 02:50:11 -0700 (PDT) Received: by 10.176.68.65 with HTTP; Wed, 20 Apr 2016 02:50:11 -0700 (PDT) In-Reply-To: <290B6546-9B1B-4554-93F9-8FBC6237D583@thomasclausen.org> References: <20160405101903.773.31003.idtracker@ietfa.amsl.com> <8438BA85-DFC2-4192-84EE-999572C35FD1@fu-berlin.de> <04D7135E-8EDF-49DC-8978-3A1132FF3915@thomasclausen.org> <58FD3C84-52F7-4C5E-B2D0-607FB233524D@thomasclausen.org> <290B6546-9B1B-4554-93F9-8FBC6237D583@thomasclausen.org> Date: Wed, 20 Apr 2016 10:50:11 +0100 Message-ID: From: Victoria Mercieca To: ietf@thomasclausen.org Content-Type: multipart/alternative; boundary=001a114fd886146a0a0530e78548 Archived-At: Cc: Christopher Dearlove , manet Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-14.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, 20 Apr 2016 09:50:24 -0000 --001a114fd886146a0a0530e78548 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Thomas, See comments in line... On Wed, Apr 20, 2016 at 10:02 AM, wrote: > Hi, > > Looking back over issues that I have raised, I am not sure that I saw any > replies to this, so I went looking in the I-D for some clarification and > some follow-up questions. > > *First, section 9 contains this throw-away comment:* > > Configuring the ENAR as a default router is outside the scope of this > specification. > > Either I do not understand what you mean by =E2=80=9C=E2=80=A6as a defaul= t router=E2=80=A6=E2=80=9D or > there=E2=80=99s a layer of complexity (that I can guess at) which you=E2= =80=99re not > telling, but which really should be called out. > > My guess would be, that a router inside the MANET will need to communicat= e > to (say) google, you would do a Route Discovery (RREQ/RREP) cycle and the > ENAR would return a route to 2a00:1450:4007:80e::2003 =E2=80=94 and then= when > you 30s later need to communicate to (say) Facebook.com > you would do a Route Discovery (RREQ/RREP) cycle > and the ENAR would return a route to 2a03:2880:20:4f22:face:b00c::25de. > > I.e. the =E2=80=9C=E2=80=A6as default router=E2=80=A6=E2=80=9D means that= you do not know of any way of > making it work such that the ENER an reply, to the first of these two, wi= th > simply 0::0/0, and then have the routers in the MANET install a route via > the ENAR to destinations not inside the MANET? > > What I am getting at here is, that if I understand correctly then > connectivity to =E2=80=9Cthe Internet=E2=80=9D is very, very inefficientl= y supported =E2=80=94 or, > actually, more precisely that connectivity to any =E2=80=9Cexternal netwo= rk which > can only be captured by a prefix which also includes destinations inside > the MANET=E2=80=9D is very inefficiently supported (because you cannot in= stall > prefix routes to such a network). > > If I am understanding this correctly, then it deserves more elaboration > than the throw-away mention at the end of Section 9, cited above, and > certainly this paragraph from the applicability statement needs to > correctly reflect it: > > AODVv2 is designed for stub or disconnected mobile ad hoc networks, > i.e., non-transit networks or those not connected to the internet. > AODVv2 can, however, be configured to perform gateway functions when > attached to external networks, as discussed in Section 9. > > *Second, section 7.1 specifies for RREQs:* > > AddressList > Contains OrigAddr and TargAddr, the source and destination > addresses of the IP packet for which a route is requested. > OrigAddr and TargAddr MUST be routable unicast addresses. > > > Again, if I have understood correctly, if a router has 255 hosts attached > (say a /56), each of which need to communicate with a server, then the > router must end up generating 255 RREQ/RREP cycles, even though it may > already have an entry for the IP address for the server? > > No. While OrigAddr and TargAddr are the source and destination addresses of the IP packet for which a route is requested, we also include in a RREQ the prefix length for OrigAddr, which is the prefix length as seen in the corresponding Router Client entry on RREQ_Gen. So, any routers receiving the RREQ learn a route to the whole prefix. This is what happens: 1) packet arrives e.g. from source 10.0.0.1 and to destination 20.0.0.2 2) router has no route to 20.0.0.2 3) router matches source address 10.0.0.0 to router client entry 10.0.0.0/8 (therefore will send a RREQ) 4) router creates RREQ using OrigAddr =3D 10.0.0.1 and OrigPrefixLen =3D 8. 5) receiving routers learn route to 10.0.0.0/8. However, because initially you have this single IP packet with a specific destination IP address, you can't intentionally send a RREQ for the whole prefix associated with TargAddr. But the route you get back in a RREP has TargAddr and TargPrefixLen (which corresponds to the router client entry at RREP_Gen), which combined represents the route to the prefix TargAddr is part of, which is what gets installed at each router receiving the RREP. Perhaps this would be clearer, if instead of including the data packet's source IP address as the OrigAddr in a RREQ, we used the corresponding router client entry as OrigAddr? Step 4 above would become: 4) router creates RREQ using OrigAddr =3D 10.0.0.0 and OrigPrefixLen =3D 8. Similarly for RREP and TargAddr. Perhaps to make it completely clear, we could rename OrigAddr to OrigPrefix in a RREQ, and TargAddr to TargPrefix in a RREP. So the RREQ contains OrigPrefix, OrigPrefixLen and TargAddr. And the RREP contains OrigPrefix, OrigPrefixLen, TargPrefix, TargPrefixLen. What do you think of this suggestion? This links in to the gateway question... I think the ENAR could potentially respond to a route request for an external address by sending a RREP containing the default route. It's equivalent to the requested TargAddr being part of a router client entry for a prefix on RREP_Gen. Using the current rules, the ENAR would attempt to send a RREP with TargAddr set to match TargAddr in the RREQ, and TargPrefixLen of 0. Even if the RREP contained TargAddr =3D 0.0.0.0 and TargPrefixLen of 0, RREQ_Gen could still match this with the RREQ it had sent and consider the route request fulfilled. Do you see a problem with this? We would need to update the wording and the current use of Prefix Length, since we currently interpret a prefix length of 0, and also the omission of prefix length value, to mean the full address length. Kind Regards, Victoria. The reason why I speculate that this is so is, that RREQ forwarding > installs the =E2=80=9Creverse route=E2=80=9D towards the source, and if O= rigAddr is "the > *source* addresses of the IP packet for which a route is requested=E2=80= =9D > address, i.e., there is no way for the RREQ to request a route to the > server =E2=80=9Cat once=E2=80=9D on behalf of "the entire /56=E2=80=9D b= ehind it? > > Again, if I am understanding this correctly, then it deserves a bit more > elaboration, notably a framing of the cases discussed in the above, and a > modulation of the statement from the applicability statement that: > > AODVv2 can, however, be configured to perform gateway functions when > attached to external networks, as discussed in > Section 9. > > Capturing these limitations of gateway functionality? > > The same, probably, also applies in the opposite direction, i.e., in case > a single =E2=80=9Csource=E2=80=9D needs to communicate with many or all o= f a /56, behind a > router? > > Best, > > Thomas > > > On 07 Apr 2016, at 23:11, Thomas Heide Clausen > wrote: > > On this whole gateway issue, I am disturbed...most routers would have > one-or-multiple /64-or-shorter, one per non-Manet link (w/ hosts hanging > off) delegated to them, and not just a single /128. > > Needing to communicate with many-to-all hosts on a link is not uncommon > (if the hosts are, e.g., environmental controls in the same room), and th= e > ability to "get the whole prefix advertised at once" send an RREQ for the > whole prefix - specifically, for not > > Sent from my iPad > > On 07 Apr 2016, at 22:19, Christopher Dearlove < > christopher.dearlove@gmail.com> wrote: > > Thanks, that addresses most of the points I made. > > Assuming that is that a packet reception for forwarding is the only optio= n > you choose to allow. It's perfectly reasonable for an implementation to > think "wouldn't it be sensible to learn about a gateway now for various > reasons?". Yes, there's the problem of which subnet to look for ( > 0.0.0.0/0 or something smaller). Yes, I can imagine you don't want to > define this now - unless of course someone in the WG says they really wan= t > it. But I would say, don't close the door on it, even if not doing it now= . > > (There are other possibilities that might be useful one day. An RREQ that > looks for more than one address for example - you could trade latency and > overhead by combining RREQs.) > > -- > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) > > On 7 Apr 2016, at 18:49, Victoria Mercieca wrote: > > Hi Christopher, > > On 7 Apr 2016 1:55 pm, "Christopher Dearlove" < > christopher.dearlove@gmail.com> wrote: > > > > [This time from a subscribed address.] > > > > You say you've added a sentence saying AODVv2 doesn't do RREQs for > gateways. What should have happened is a discussion on this list as to wh= y? > is that hard? does anyone have a clever idea to make it not hard? does > anyone need that functionality? and so on. > > > > For example, here's something that superficially looks like it might > work. Does it, or does it introduce new problems? I don't know. But this, > and likely better ideas, just haven't had discussion here - and I fear th= at > the people who might have the better ideas have departed unheard. > > > > So, a router wants a route to a.b.c.d, and sends an RREQ for that (/32, > or simply omit). Of course any router directly serving that address just > replies. But a router that is serving a.0.0.0/8 could reply with that > address. The originating router of course would use standard IP maximum > prefix length rules. Does that work? Does it help anyone? Could a router > reply a.b.c.d/32 and a.0.0.0/8 in one RREP? Or could it be allowed to rep= ly > a.b.c.d/8 as a shorthand? > > This is exactly what it does (based on the router client entry > corresponding to TargAddr, e.g if router client entry is a.0.0.0/8, then > the RREP contains a.b.c.d/8). Everyone receiving the RREP can then instal= l > the route to a.0.0.0/8 and therefore avoid a separate RREQ for (as an > example) a.b.c.e in future. Similarly an RREQ contains the prefix length > associated with the router client entry configured for OrigAddr, and > routers processing the RREQ learn the route to OrigAddrs prefix. > > But you can't intentionally send a RREQ for a prefix because the RREQ is > created when there's a packet to send, you know the destination address n= ot > the prefix associated with it, so TargAddr is a.b.c.d/32. But even so, yo= u > do end up learning a route to a prefix, if TargAddr is part of a router > client entry which is a prefix. > > Kind regards, > Victoria. > > > And why can't a router request a.b.0.0/16 - and possibly get an > a.0.0.0/8 reply? > > > > Answers to all of those is "I don't know". But we should have been > having those discussions. > > > > -- > > Christopher Dearlove > > christopher.dearlove@gmail.com > > > > > > > > -- > > Christopher Dearlove > > christopher.dearlove@gmail.com (iPhone) > > chris@mnemosyne.demon.co.uk (home) > > On 7 Apr 2016, at 15:49, Lotte Steenbrink > wrote: > > > >> Hi Thomas, > >> > >>> Am 05.04.2016 um 20:07 schrieb ietf@thomasclausen.org: > >>> > >>> Lotte, > >>> > >>> Thank you for this update. An impressive amount of changes to the > document, according to RFCdiff, and as I can see from your mail that ther= e > is much more to come, > >> > >> > >> Thanks! I=E2=80=99m glad you=E2=80=99re seeing the progress we=E2=80= =99ve made. > >> > >>> I hope that you forgive me for not jumping at a blow-by-blow review > until a version which the authors themselves consider stable, is produced= . > >>> > >>> On the point of =E2=80=9Cmuch more to come", there have been quite a = few > comments raised by WG participants other than Mr. Dean and Chris (such a= s > by myself, but not only) =E2=80=94 some of which intersect some of the be= low, and > for which I do not believe that a satisfactory resolution has been > developed, presented to the WG, and confirmed. > >> > >> > >> I=E2=80=99m not quite sure which comments exactly you are referring to= ? Your > last comments that come to mind are the ones in these threads: > >> > >> https://www.ietf.org/mail-archive/web/manet/current/msg18055.html > >> https://www.ietf.org/mail-archive/web/manet/current/msg18639.html > >> > >> You=E2=80=99ve announced to go through the former in your last respons= e to the > latter, but as far as I can see you haven=E2=80=99t gotten round to doing= that and > a lot of points you=E2=80=99ve brought up have sparked ongoing discussion= s, so I=E2=80=99ve > marked most of your comments as =E2=80=9Cpending=E2=80=93 still in discus= sion=E2=80=9D in my mind. > >> Regarding the points you brought up that aren=E2=80=99t affected by th= is: > >> > >> * Metrics=E2=80=93 we=E2=80=99ve had discussions about this many moons= ago with authors > on both sides of the fence. Unfortunately I can=E2=80=99t remember the co= unter > arguments, and I=E2=80=99m still looking for records of this conversation= =E2=80=A6 I=E2=80=99ll get > back to you when I=E2=80=99ve found out more. > >> * Prefixes & Gateways: I=E2=80=99ve added a sentence to clarify that A= ODVv2 > doesn=E2=80=99t do RREQs for gateways, I hop that helps? > >> > >>> > >>> In which revision of the I-D do you plan on addressing those? > >>> > >> > >> If the discussions reach a conclusion by then, I=E2=80=99d be glad to = have them > addressed by the next revision. > >> > >> Best regards, > >> Lotte > >> > >>> Best, > >>> > >>> Thomas > >>> > >>> > >>> > >>>> On Apr 5, 2016, at 12:53, Lotte Steenbrink < > lotte.steenbrink@fu-berlin.de> wrote: > >>>> > >>>> Hi all, > >>>> just a quick summary of what is and what isn=E2=80=99t included in t= his > update of the draft: > >>>> > >>>> DONE: > >>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94 > >>>> * All JWD! comments (i.e. the critical ones) are resolved > >>>> * Out of 90 JWD and JWD! comments, 61 are resolved > >>>> * The revised security considerations [1] were added (with the TODOs > commented out) > >>>> * The following TODO from [1] was resolved: > >>>> "This description MUST > >>>> include the reasons it was either unreasonable or out of scope to > >>>> attempt to avoid these denial of service attacks." > >>>> * Section 9 now contains a statement that AODVv2 doesn=E2=80=99t sup= port > RREQs for prefixes, I hope that clears things up for Thomas. > >>>> > >>>> TO DO: > >>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94 > >>>> * Most notable of the 29 JWDs that are yet to be resolved: > >>>> + (is there some table that lists routes that are being waited on? > JWD) We decided to add a separate > >>>> RREP table that lists them and I=E2=80=99ve volunteered t= o write > text for that, but we=E2=80=99re currently discussing if/how > >>>> we might solve this without adding yet another table. > >>>> > >>>> + We=E2=80=99re currently discussing the approaching the limit thing= . (i.e. > >>>> (There is no defined behavior here. Approaching the limit? Sectio= n > 6.5 outlines which messages are more important but now how to decide to > allow them to be transmitted or not. JWD > >>>> and > >>>> (The undefined approaching the limit thing again JWD) etc > >>>> We=E2=80=99ve already clarified the wording regarding wha= t the > limit is and how to prioritize the message types, > >>>> what=E2=80=99s left is to define what =E2=80=9Eapproachin= g=E2=80=9C means (and > whether we need to talk about approaching rather than > >>>> just saying =E2=80=9Ehere=E2=80=99s what to do when you a= ctually hit the > limit"). > >>>> > >>>> + (I don=E2=80=99t want to spam the list with a comprehensive li= st of all > of them, but if you=E2=80=99re interested in seeing them, > >>>> please do say so and I=E2=80=99ll send my copy of Justin= =E2=80=99s review > containing all TODOs and DONEs to the list) > >>>> * some TODOs in security considerations (see [1]) > >>>> * since we're waiting for Chris=E2=80=99 feedback regarding the revi= sed 5444 > multiplexer wording, that hasn=E2=80=99t changed yet. > >>>> > >>>> More details can be found in Appendix A. AODVv2 Draft Updates, as > well as the diff, of course. > >>>> > >>>> Best regards, > >>>> Lotte > >>>> > >>>> [1] Re: [manet] AODVv2: Security considerations update > https://www.ietf.org/mail-archive/web/manet/current/msg18458.html > >>>> > >>>> > >>>>> Am 05.04.2016 um 12:19 schrieb internet-drafts@ietf.org: > >>>>> > >>>>> > >>>>> 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-14.txt > >>>>> Pages : 80 > >>>>> Date : 2016-04-05 > >>>>> > >>>>> 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-14 > >>>>> > >>>>> A diff from the previous version is available at: > >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-14 > >>>>> > >>>>> > >>>>> 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/ > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > > > --001a114fd886146a0a0530e78548 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Thomas,

See comments in line...

On Wed, Apr 20,= 2016 at 10:02 AM, <ietf@thomasclausen.org> wrote:
=
Hi,

Looking back over issues that I have rais= ed, I am not sure that I saw any replies to this, so I went looking in the = I-D for some clarification and some follow-up questions.

First, section 9 contains this throw-away comment:
=
=C2=A0 =C2= =A0Configuring the ENAR as a default router is outside the scope of this
=C2=A0 =C2=A0specifica= tion.

Either I do not understand what you mean by = =E2=80=9C=E2=80=A6as a default router=E2=80=A6=E2=80=9D or there=E2=80=99s = a layer of complexity (that I can guess at) which you=E2=80=99re not tellin= g, but which really should be called out.=C2=A0

My= guess would be, that a router inside the MANET will need to communicate to= (say) google, you would do a Route Discovery (RREQ/RREP) cycle and the ENA= R would return a route to =C2=A02a00:1450:4007:80e::2003=C2=A0=E2=80=94 and then when you 30s = later need to communicate to (say) Facebook.com you would do a Route Discovery (RREQ/RREP) cyc= le and the ENAR would return a route to=C2=A02a03:2880:20:4f22:face:b00c::25de.=C2=A0

I.e. the =E2=80=9C=E2=80=A6as default router=E2=80=A6=E2= =80=9D means that you do not know of any way of making it work such that th= e ENER an reply, to the first of these two, with simply 0::0/0, and then ha= ve the routers in the MANET install a route via the ENAR to destinations no= t inside the MANET?

What I am getting at here is, = that if I understand correctly then connectivity to =E2=80=9Cthe Internet= =E2=80=9D is very, very inefficiently supported =E2=80=94 or, actually, mor= e precisely that connectivity to any =E2=80=9Cexternal network which can on= ly be captured by a prefix which also includes destinations inside the MANE= T=E2=80=9D is very inefficiently supported (because you cannot install pref= ix routes to such a network).

If I am understandin= g this correctly, then it deserves more elaboration than the throw-away men= tion at the end of Section 9, cited above, and certainly this paragraph fro= m the applicability statement needs to correctly reflect it:

=
=C2=A0 =C2=A0AODVv2 is designed for stub or disconnected mo= bile ad hoc networks,
=C2=A0 =C2=A0i.e., non-transit networks or = those not connected to the internet.
=C2=A0 =C2=A0AODVv2 can, how= ever, be configured to perform gateway functions when
=C2=A0 =C2= =A0attached to external networks, as discussed in Section 9.

=
Second, section 7.1 specifies for RREQs:

=C2=A0 =C2=A0AddressL= ist
=C2=A0 =C2=A0 = =C2=A0 Contains OrigAddr and TargAddr, the source and destination
=C2=A0 =C2=A0 =C2=A0 address= es of the IP packet for which a route is requested.
=C2=A0 =C2=A0 =C2=A0 OrigAddr and TargAd= dr MUST be routable unicast addresses.


A= gain, if I have understood correctly, if a router has 255 hosts attached (s= ay a /56), each of which need to communicate with a server, then the router= must end up generating 255 RREQ/RREP cycles, even though it may already ha= ve an entry for the IP address for the server?


No. While OrigAddr and TargAddr are the source an= d destination addresses of the IP packet for which a route is requested, we= also include in a RREQ the prefix length for OrigAddr, which is the prefix= length as seen in the corresponding Router Client entry on RREQ_Gen. So, a= ny routers receiving the RREQ learn a route to the whole prefix.

Th= is is what happens:
1) packet arrives e.g. from source 10.0.0.1 and to d= estination 20.0.0.2
2) router has no route to 20.0.0.2
3) router= matches source address 10.0.0.0 to router client entry 10.0.0.0/8 (therefore will send a RREQ)
4) router creates RREQ using OrigAddr =3D 10.0.0.1 and OrigPrefixLen= =3D 8.
5) receiving routers learn route to 10.0.0.0/8.

However, b= ecause initially you have this single IP packet with a specific destination= IP address, you can't intentionally send a RREQ for the whole prefix a= ssociated with TargAddr. But the route you get back in a RREP has TargAddr = and TargPrefixLen (which corresponds to the router client entry at RREP_Gen= ), which combined represents the route to the prefix TargAddr is part of, w= hich is what gets installed at each router receiving the RREP.

Perhaps this would be clearer, if instead of including the= data packet's source IP address as the OrigAddr in a RREQ, we used the= corresponding router client entry as OrigAddr? Step 4 above would become:<= br>4) router creates RREQ using OrigAddr =3D 10.0.0.0 and OrigPrefixLen =3D= 8.
Similarly for RREP and TargAddr.=C2=A0
Perhaps to mak= e it completely clear, we could rename OrigAddr to OrigPrefix in a RREQ, an= d TargAddr to TargPrefix in a RREP. So the RREQ contains OrigPrefix, OrigPr= efixLen and TargAddr. And the RREP contains OrigPrefix, OrigPrefixLen, Targ= Prefix, TargPrefixLen.
What do you think of this suggestion?


=
This links in to the gateway question...
I think t= he ENAR could potentially respond to a route request for an external addres= s by sending a RREP containing the default route. It's equivalent to th= e requested TargAddr being part of a router client entry for a prefix on RR= EP_Gen. Using the current rules, the ENAR would attempt to send a RREP with= TargAddr set to match TargAddr in the RREQ, and TargPrefixLen of 0. Even i= f the RREP contained TargAddr =3D 0.0.0.0 and TargPrefixLen of 0, RREQ_Gen = could still match this with the RREQ it had sent and consider the route req= uest fulfilled. Do you see a problem with this? We would need to update the= wording and the current use of Prefix Length, since we currently interpret= a prefix length of 0, and also the omission of prefix length value, to mea= n the full address length.

Kind Regards,
Victoria.
=

=
The reason why I s= peculate that this is so is, that RREQ forwarding installs the =E2=80=9Crev= erse route=E2=80=9D towards the source, and if OrigAddr is "the sou= rce=C2=A0addresses of the IP packet for which a route is requested=E2= =80=9D address, i.e., there is no way for the RREQ to request a route to th= e server =E2=80=9Cat once=E2=80=9D on behalf of "the entire /56=E2=80= =9D =C2=A0behind it?

Again, if I am understanding = this correctly, then it deserves a bit more elaboration, notably a framing = of the cases discussed in the above, and a modulation of the statement from= the applicability statement that:

AODVv2 can, however, be configured to pe= rform gateway functions when
=C2=A0 =C2=A0 attached to external networks, as discussed in=C2=A0<= /div> Section 9.

=
Capturing these limitations of gateway functionality?
=
The same, probably, also applies in the opposite direct= ion, i.e., in case a single =E2=80=9Csource=E2=80=9D needs to communicate w= ith many or all of a /56, behind a router?

B= est,

Thomas


On 07 Apr 2016, at 23:11, Thomas Heide Cla= usen <ietf@t= homasclausen.org> wrote:

On thi= s whole gateway issue, I am disturbed...most routers would have one-or-mult= iple /64-or-shorter, one per non-Manet link (w/ hosts hanging off) delegate= d to them, and not just a single /128.

Needing to = communicate with many-to-all hosts on a link is not uncommon (if the hosts = are, e.g., environmental controls in the same room), and the ability to &qu= ot;get the whole prefix advertised at once" send an RREQ for the whole= prefix - specifically, for not=C2=A0

Sent from my iPad
=

On 07 Apr 2016, at 22:19, Christopher Dearlove <christopher.dearlove@g= mail.com> wrote:

Th= anks, that addresses most of the points I made.

As= suming that is that a packet reception for forwarding is the only option yo= u choose to allow. It's perfectly reasonable for an implementation to t= hink "wouldn't it be sensible to learn about a gateway now for var= ious reasons?".=C2=A0 Yes, there's the problem of which subnet to = look for (0.0.0.0/0 or s= omething smaller). Yes, I can imagine you don't want to define this now= - unless of course someone in the WG says they really want it. But I would= say, don't close the door on it, even if not doing it now.
<= br>
(There are other possibilities that might be useful one day. = An RREQ that looks for more than one address for example - you could trade = latency and overhead by combining RREQs.)

-- =C2=A0
Christopher = Dearlove

On 7 Apr 2016, at 18:49, Victoria= Mercieca <vme= rcieca0@gmail.com> wrote:

Hi Christopher,

On 7 Apr 2016 1:55 pm, &= quot;Christopher Dearlove" <christopher.dearlove@gmail.com> wrote:<= br> >
> [This time from a subscribed address.]
>
> You say you've added a sentence saying AODVv2 doesn't do RREQs= for gateways. What should have happened is a discussion on this list as to= why? is that hard? does anyone have a clever idea to make it not hard? doe= s anyone need that functionality? and so on.
>
> For example, here's something that superficially looks like it mig= ht work. Does it, or does it introduce new problems? I don't know. But = this, and likely better ideas, just haven't had discussion here - and I= fear that the people who might have the better ideas have departed unheard= .
>
> So, a router wants a route to a.b.c.d, and sends an RREQ for that (/32= , or simply omit). Of course any router directly serving that address just = replies. But a router that is serving a.0.0.0/8 could reply with that addre= ss. The originating router of course would use standard IP maximum prefix l= ength rules. Does that work? Does it help anyone? Could a router reply a.b.= c.d/32 and a.0.0.0/8 in one RREP? Or could it be allowed to reply a.b.c.d/8= as a shorthand?

This is exactly what it does (based on t= he router client entry corresponding to TargAddr, e.g if router client entr= y is a.0.0.0/8, then the RREP contains a.b.c.d/8). Everyone receiving the R= REP can then install the route to a.0.0.0/8 and therefore avoid a separate = RREQ for (as an example) a.b.c.e in future. Similarly an RREQ contains the = prefix length associated with the router client entry configured for OrigAd= dr, and routers processing the RREQ learn the route to OrigAddrs prefix.

But you can't intentionally send a RREQ for a prefix be= cause the RREQ is created when there's a packet to send, you know the d= estination address not the prefix associated with it, so TargAddr is a.b.c.= d/32. But even so, you do end up learning a route to a prefix, if TargAddr = is part of a router client entry which is a prefix.

Kind = regards,
Victoria.

> And why can't a router request a.b.0.= 0/16 - and possibly get an a.0.0.0/8 reply?
>
> Answers to all of those is "I don't know".=C2=A0 But we = should have been having those discussions.
>
> --=C2=A0
> Christopher Dearlove
> ch= ristopher.dearlove@gmail.com
>
>
>
> -- =C2=A0
> Christopher Dearlove
> ch= ristopher.dearlove@gmail.com (iPhone)
> chris= @mnemosyne.demon.co.uk (home)
> On 7 Apr 2016, at 15:49, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:
>
>> Hi Thomas,
>>
>>> Am 05.04.2016 um 20:07 schrieb ietf@thomasclausen.org:
>>>
>>> Lotte,
>>>
>>> Thank you for this update. An impressive amount of changes to = the document, according to RFCdiff, and as I can see from your mail that th= ere is much more to come,
>>
>>
>> Thanks! I=E2=80=99m glad you=E2=80=99re seeing the progress we=E2= =80=99ve made.=C2=A0
>>
>>> I hope that you forgive me for not jumping at a blow-by-blow r= eview until a version which the authors themselves consider stable, is prod= uced.
>>>
>>> On the point of =E2=80=9Cmuch more to come", there have b= een quite a few comments raised by WG participants other than Mr. Dean and = Chris =C2=A0(such as by myself, but not only) =E2=80=94 some of which inter= sect some of the below, and for which I do not believe that a satisfactory = resolution has been developed, presented to the WG, and confirmed.
>>
>>
>> I=E2=80=99m not quite sure which comments exactly you are referrin= g to? Your last comments that come to mind are the ones in these threads: >>
>> https://www.ietf.org/mail-archive/web/manet/c= urrent/msg18055.html
>> https://www.ietf.org/mail-archive/web/manet/c= urrent/msg18639.html
>>
>> You=E2=80=99ve announced to go through the former in your last res= ponse to the latter, but as far as I can see you haven=E2=80=99t gotten rou= nd to doing that and a lot of points you=E2=80=99ve brought up have sparked= ongoing discussions, so I=E2=80=99ve marked most of your comments as =E2= =80=9Cpending=E2=80=93 still in discussion=E2=80=9D in my mind.=C2=A0
>> Regarding the points you brought up that aren=E2=80=99t affected b= y this:
>>
>> * Metrics=E2=80=93 we=E2=80=99ve had discussions about this many m= oons ago with authors on both sides of the fence. Unfortunately I can=E2=80= =99t remember the counter arguments, and I=E2=80=99m still looking for reco= rds of this conversation=E2=80=A6 I=E2=80=99ll get back to you when I=E2=80= =99ve found out more.
>> *=C2=A0Prefixes & Gateways: I=E2=80=99ve added a sentence to c= larify that AODVv2 doesn=E2=80=99t do RREQs for gateways, I hop that helps?=
>>
>>>
>>> In which revision of the I-D do you plan on addressing those?<= br> >>>
>>
>> If the discussions reach a conclusion by then, I=E2=80=99d be glad= to have them addressed by the next revision.
>>
>> Best regards,
>> Lotte
>>
>>> Best,
>>>
>>> Thomas
>>>
>>>
>>>
>>>> On Apr 5, 2016, at 12:53, Lotte Steenbrink <lotte.steenbrink@fu= -berlin.de> wrote:
>>>>
>>>> Hi all,
>>>> just a quick summary of what is and what isn=E2=80=99t inc= luded in this update of the draft:
>>>>
>>>> DONE:
>>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94
>>>> * All JWD! comments (i.e. the critical ones) are resolved<= br> >>>> * Out of 90 JWD and JWD! comments, 61 are resolved
>>>> * The revised security considerations [1] were added (with= the TODOs commented out)
>>>> * The following TODO from [1] was resolved:=C2=A0
>>>> =C2=A0 =C2=A0"This description MUST
>>>> =C2=A0 =C2=A0include the reasons it was either unreasonabl= e or out of scope to
>>>> =C2=A0 =C2=A0attempt to avoid these denial of service atta= cks."
>>>> * Section 9 now contains a statement that AODVv2 doesn=E2= =80=99t support RREQs for prefixes, I hope that clears things up for Thomas= .
>>>>
>>>> TO DO:
>>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=C2=A0
>>>> * Most notable of the 29 JWDs that are yet to be resolved:=
>>>> +=C2=A0(is there some table that lists routes that are bei= ng waited on? JWD)=C2=A0We decided to add a separate=C2=A0
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RREP table that l= ists them and I=E2=80=99ve volunteered to write text for that, but we=E2=80= =99re currently discussing if/how
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we might solve th= is without adding yet another table.
>>>>
>>>> + We=E2=80=99re currently discussing the approaching the l= imit thing. (i.e.
>>>> =C2=A0 =C2=A0(There is no defined behavior here. Approachi= ng the limit? Section 6.5 outlines which messages are more important but no= w how to decide to allow them to be transmitted or not. JWD=C2=A0
>>>> =C2=A0=C2=A0and
>>>> =C2=A0=C2=A0(The undefined approaching the limit thing aga= in JWD) etc
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We=E2=80=99ve alr= eady clarified the wording regarding what the limit is and how to prioritiz= e the message types,=C2=A0
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0what=E2=80=99s le= ft is to define what =E2=80=9Eapproaching=E2=80=9C means (and whether we ne= ed to talk about approaching rather than
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0just saying =E2= =80=9Ehere=E2=80=99s what to do when you actually hit the limit").
>>>>
>>>> =C2=A0 =C2=A0 +=C2=A0(I don=E2=80=99t want to spam the lis= t with a comprehensive list of all of them, but if you=E2=80=99re intereste= d in seeing them,
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0please do say so = and I=E2=80=99ll send my copy of Justin=E2=80=99s review containing all TOD= Os and DONEs to the list)
>>>> * some TODOs in security considerations (see [1])
>>>> * since we're waiting for Chris=E2=80=99 feedback rega= rding the revised 5444 multiplexer wording, that hasn=E2=80=99t changed yet= .
>>>>
>>>> More details can be found in=C2=A0Appendix A.=C2=A0 AODVv2= Draft Updates,=C2=A0as well as the diff, of course.
>>>>
>>>> Best regards,
>>>> Lotte
>>>>
>>>> [1] Re: [manet] AODVv2: Security considerations update=C2= =A0https://www.ietf.org/mail-archive/web/manet/current= /msg18458.html
>>>>
>>>>
>>>>> Am 05.04.2016 um 12:19 schrieb=C2=A0internet-drafts@ietf.org: >>>>>
>>>>>
>>>>> A New Internet-Draft is available from the on-line Int= ernet-Drafts directories.
>>>>> This draft is a work item of the Mobile Ad-hoc Network= s of the IETF.
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Title =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Ad Hoc On-demand Di= stance Vector Version 2 (AODVv2) Routing
>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Authors =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Charles E. Perkins
>>>>> =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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Stan Ratliff
>>>>> =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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0John Dowdell
>>>>> =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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Lotte Steenbrink
>>>>> =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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Victoria Mercieca
>>>>> Filename =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: d= raft-ietf-manet-aodvv2-14.txt
>>>>> Pages =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0: 80
>>>>> Date =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0: 2016-04-05
>>>>>
>>>>> Abstract:
>>>>> =C2=A0=C2=A0The Ad Hoc On-demand Distance Vector Versi= on 2 (AODVv2) routing
>>>>> =C2=A0=C2=A0protocol is intended for use by mobile rou= ters in wireless, multihop
>>>>> =C2=A0=C2=A0networks.=C2=A0 AODVv2 determines unicast = routes among AODVv2 routers
>>>>> =C2=A0=C2=A0within the network in an on-demand fashion= .
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ie= tf-manet-aodvv2/
>>>>>
>>>>> There's also a htmlized version available at:
>>>>> https://tools.ietf.org/html/draft-ietf-manet= -aodvv2-14
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> https://www.ietf.org/rfcdiff?url2=3D= draft-ietf-manet-aodvv2-14
>>>>>
>>>>>
>>>>> 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/
>>>>>
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> ma= net@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 maili= ng list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/ma= net


--001a114fd886146a0a0530e78548-- From nobody Wed Apr 20 02:54: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 8968112E72F for ; Wed, 20 Apr 2016 02:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 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, TRACKER_ID=1.306] autolearn=no 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 zlAh5s0KdWxJ for ; Wed, 20 Apr 2016 02:54:40 -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 6B96312DBD6 for ; Wed, 20 Apr 2016 02:54:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 35EE6245BB5; Wed, 20 Apr 2016 02:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461146080; bh=IOUI89wV105DeQXIXjpPZxbt1vimpQUhOEMpRjj0MbQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=LG14hTQlSBfepZJY+hvGPtK87oERnSX6GLgfhnlZBZBLJvM0lz6PBwnOswsukvlGu ijhR0C06pAR34R+3viXnAGUukXzfRDtz5Qe+Gjqztr1a+Tr15C0hRv25L6cbLvgA/M vR1WEvEyxjZLfWs4pKIBzKO6oK6lddQwIgHpHUTw= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [172.20.10.14] (unknown [37.162.205.154]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 45E2C24097D; Wed, 20 Apr 2016 02:54:38 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-3D55A268-6EA1-43A1-B62A-63B1538E0012 Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (13E238) In-Reply-To: Date: Wed, 20 Apr 2016 11:54:34 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org> To: Lotte Steenbrink Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items) 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, 20 Apr 2016 09:54:45 -0000 --Apple-Mail-3D55A268-6EA1-43A1-B62A-63B1538E0012 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Lotte, all, > On 19 Mar 2016, at 12:34, Lotte Steenbrink = wrote: >=20 > Hi Thomas, > thank you for reviewing AODVv2 yet again :) Some answers below: >=20 >> Am 17.03.2016 um 17:00 schrieb ietf@thomasclausen.org: >>=20 >> Dear all, >>=20 >> Apologies for not having gotten this done sooner - day-job leaving few sp= are cycles. >>=20 >> I=E2=80=99ve previously offered reviews and comments, and some of those h= ave been addressed in the latest I-D =E2=80=94 others have not, but should b= e. I recall that there was some mail attempting to rebut parts of the review= , and I will dig it out and reply to that. >=20 > That wold be great. I am finding a bit of time here and there when there are holes in the agenda= , and am (as you likely have noticed) backtracking through emails when I get= a chance. Apologies, I hope that I will get to these emails this, or next w= eek, but day-job eats in to the available time ;( >> Forwarding-vs-regeneration >> Recent exchanges on the list made me understand that protocol control mes= sages are *not* forwarded, but are consumed at each hop, then a new message w= ith (almost-but-not-quite) the same content is generated and transmitted. >=20 > That=E2=80=99s what we=E2=80=99ve been trying to say all along! I=E2=80=99= m really glad we=E2=80=99re having this conversation. Then, let us have it -- it's a central point to get right. >> I have thought some more on this (& read some of the exchanges on the lis= t on this topic by Chris, Ulrich, and others), and I am convinced that this i= s not the right way to go, at least for the following reasons: >>=20 >>=20 >> o It renders the hop-limit/hop-count fields in the RFC5444 me= ssage header useless. >> This would not be bad if the functionality offered by those= fields was not useful >> =E2=80=94 sadly, it is. For example, for scope limited floo= ding (expanding ring search, and=20 >> such) which may be of interest, and which require hop-limit= .=20 >> A hop-count field may also provide a =E2=80=9Ccheap=E2=80=9D= (in terms of overhead) additional piece >> of information to use conjunctively with a =E2=80=9Creal=E2= =80=9D metric. >=20 > I agree on the usefulness, which is why we were puzzled when we were told w= e weren=E2=80=99t allowed to use those fields (or, rather, that we were usin= g them wrong, but that the right way to use them doesn=E2=80=99t work for AO= Dvv2). I believe Vicky has written about this in more detail in previous dis= cussions, and we were/are looking forward to reading your answers... So, the source generates a message, the message is forwarded through the net= work, with each intermediate router decrementing the hop limit and increment= ing the hop count. As stated in the 5444-Usage document, when forwarding a message, the hop-lim= it/hop-count are modified, the rest of the message SHOULD not be.=20 That is specifically, one thing where I kinda would like 5444-usage to go fu= rther is "the message structure MUST in all conditions preserved when forwar= ding" - but still say "and it is RECOMMENDED that the value field of TLVs ar= e also not modified". What this buys is several things, in the context of this protocol: o hop-limit/hop-count could be useful for the usual=20 purposes (ensuring that messages do not live forever,=20 scope-limited flooding, ...) o if the accumulated path metric is stored in a TLV value fie= ld, that=20 value field can (with suitable disclaimer to call out "we k= now it is RECOMMENDED to not do this, but here's why we are OK in doi= ng it anyways") be modified when forwarding the message, and o as that path metric field is in a message whose structure d= oes not change, it will be "at the same place in the byte-stream" a= t each hop, which =09 o allows useful things such as deriving from RFC7182 a form o= f "when calculating the ICV, zero out that field in the messa= ge ' when validating an ICV, also zero out that field" -- which goe= s one step further (when coupled with a time stamp) than simple tran= sitive trust,=20 but also o allows even more fancy and useful (albeit experimental) thi= ngs such as aggregate signatures to work correctly. Furthermore..... >> The only practical solution would be to re-introduce these f= unctions by way of inserting a >> MessageTLV =E2=80=94 which (i) is not specified in this doc= ument, and (ii) which would just >> serve to render messages bigger than strictly needed. >=20 > Exactly; we=E2=80=99d really like to avoid this as well. >=20 ... It avoids the above, and.... >>=20 >> Scope limited flooding does seem to be a necessary require= ment, if for no >> other reason than to prevent information from =E2=80=9Ccirc= ulating forever in the network=E2=80=9D. >=20 > AODVv2=E2=80=99s duplicated detection hopefully should take care of that. I= irc, We interpreted your earlier E-Mails to (implicitly) mean that you think= we should rely on that, since you said we can=E2=80=99t use the hop-limit/h= op-count fields. >=20 ....if done (proper forwarding with preservation of the structure, rather th= an regeneration which opens up the "this is a new message with potentially n= ew structure" can of worms) as I describe, also addresses the above. With respect to what I said earlier when I said "can't use hop-limit/hop-cou= nt fields"....when you regenerate, you absolutely, definitely, can't. When you "regenerate" a message, that means "you construct a brand new messa= ge" which may shuffle addresses inside address blocks, or between address bl= ocks, shuffle TLVs differently than they were originally, even use TLVs of d= ifferent structure (e.g., single-value TLVs instead of multi-value TLVs).=20= This means that some assumptions (such as when producing an ICV for the mess= age, which depends on the byte order) don't hold. Well, they may not hold, s= o that means we can't assume that they do. Which means that the originator o= f a message cannot generate an ICV that can be correctly interpreted (which i= s what my next section in my original mail was about). Which means, in conclusion, that the information in the message profoundly c= hange -- and therefore these hop-count/hop-limit values do not even apply to= "the information".=20 However if proper forwarding with preservation of the structure, rather than= regeneration which opens up the "this is a new message with potentially new= structure" can of worms, as I (& Ulrich & others) have suggested, is taken t= o heart, it also addresses the issue below regarding end-to-end authenticati= on (which, while still hard, is possible). A couple of more comments below >>=20 >> o It makes end-to-end authentication unnecessarily hard. >> I think Chris called this out already, but it bears repeati= ng: S generates a message=20 >> (say, a RREQ), and includes an ICV calculated over the cont= ent of the message. >> For any recipient to be able to validate the ICV, the messa= ge has to be exactly >> the same =E2=80=94 not just in content, but in structure =E2= =80=94 as what was generated. >>=20 >> =E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforward= ing=E2=80=9D messages means, that the intermediate >> router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose a d= ifferent structure (e.g., include TLVs >> in a different order). >>=20 >> The proposal from https://tools.ietf.org/html/draft-perkins= -manet-aodv-e2esec-00 >> is to add constraints on (i) the set of elements to include= in a signature and (ii) the >> order of these elements. >>=20 >> One problem with that approach is (i): if an extension adds= a message TLV, or an=20 >> Address TLV, to a message, then that will not be =E2=80=9Cc= overed=E2=80=9D by the proposed e2esec TLV. >> Rather for *each* extension developed, an =E2=80=9Cupdates e= 2esec=E2=80=9D clause needs to be done. >>=20 >> I=E2=80=99d say that this approach would be prone to errors= =E2=80=94 and add entropy to the process >> of designing protocol extensions. The alternative, a messag= e being generated by the >> source and *forwarded* (as we do in OLSRv2, for example) wo= uld allow ICV TLVs=20 >> (even, allow reuse of those specified for OLSRv2) for cover= ing a message and=20 >> extensions. >>=20 >> =E2=80=9CBut what about the metrics value which will change= on each hop=E2=80=9D, you may say? >> Fortunately, that is relatively easy to handle: simply zero= out the value of that TLV when >> generating or verifying the ICV MessageTLV. And use Packet-= TLVs for hop-by-hop=20 >> authentication, if needed (but, see below). >>=20 >> o It prevents the use of more clever/advanced signature schem= es/ICVs >> Aggregate signature algorithms ( https://crypto.stanford.ed= u/~dabo/papers/aggsurvey.pdf) >> exist, and an interesting use-case can be found in also rea= ctive protocols, allowing verifying >> not =E2=80=9Cjust=E2=80=9D the end points, but also the int= ermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D >> discussed above, or something smarter). >> Regeneration of messages, rather than forwarding, renders t= hat impossible (or, if used, >> updating to https://tools.ietf.org/html/draft-perkins-mane= t-aodv-e2esec-00) >>=20 >> There are other reasons, but the above are those that jump at me as immed= iate show-stoppers. >>=20 >> I do honestly not see what possible benefit there is from =E2=80=9Cregene= ration=E2=80=9D =E2=80=94 but I see very clear inconveniences, and security i= s not the least of these. Insisting on =E2=80=9Cregeneration=E2=80=9D requir= es development of =E2=80=9Cnon-general workarounds=E2=80=9D as pointed out a= bove. >=20 > The possible benefit is that we need to accumulate & transport metric valu= es somehow, and we can=E2=80=99t do that without regenerating at least parts= of the message. > If we=E2=80=99re missing a solution here, please share it with us. >=20 Done in the above. >>=20 >> Security Considerations >=20 > Just for context=E2=80=99s sake, did you review the security consideration= s in draft-ietf-manet-aodvv2-13 or the ones proposed in the thread =E2=80=9E= AODVv2: Security considerations update=E2=80=9C? I did. It still is a far cry from passing the bar. I've posted on why in the= past, and some more in this mail (which also contains some suggestions). I would suggest that settling the rearchitecturing to do forwarding, as I de= scribe in the above, should be done, which would ease the security considera= tions issue considerably (and which would be necessary even if ignoring the s= ecurity considerations, IMO, for this doc to go anywhere).=20 With a new version covering that, the authors (I wanted to write "you", but d= ecided to be inclusive) could you go look at the different security emails a= nd perhaps start a separate thread on that, towards a resolution? Best, Thomas >=20 >> This is an always thorny subject. When OLSRv2 was going through the proce= ss we got a thorough education in how little we knew about security from the= SEC-ADs, and had to spend about a year or so developing RFC7183. The bottom= line is, that this protocol needs its =E2=80=9CRFC7183 equivalent=E2=80=9D= , either as part of the main document, or as an independent document. curren= tly, that is not the case. >>=20 >> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration from R= FC7183 might be aw good idea, as that was the most recent that went through t= he SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to implement=E2=80= =9D security mechanism most be specified (I think the right term was =E2=80=9C= MUST implement, SHOULD use=E2=80=9D), in sufficient detail to ensure interop= erable implementations. >>=20 >> As an example, both [RFC6130] and [RFC7181] set out that that: >>=20 >> On receiving a ... message, a router MUST first check if the >> message is invalid for processing by this router >>=20 >> and then proceed to give a number of conditions that, each, will lead to a= rejection of the message as "badly formed and therefore invalid for process= ing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That gave a =E2=80= =9Chook=E2=80=9D for RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem= for message generation. >>=20 >> If I was to do RFC7181/RFC6130 today, I would include that directly into t= he protocol specifications. It turned out to be more overhead (and slow down= publication anyways) to do it as separate documents. >>=20 >> Secondly, we need to be a lot more rigid in terms of what ICVs, Timestamp= s, etc. are added/removed, and what that brings. >>=20 >> For example (with the assumption that messages are *forwarded* and *not* r= egenerated), this could be one option: >>=20 >> o When a RREQ, RREP message is generated, add an ICV M= essage TLV, which is calculated >> =E2=80=A6(take inspiration from RFC7183 here) >>=20 >> o When a RREQ, RREP message is transmitted (by the s= ource, or forwarded by an intermediary) >> in an RFC5444 packet, an ICV Packet TLV is added to= the packet, which is calculated =E2=80=A6 >>=20 >> o When an RFC5444 packet is received, validate the IC= V Packet TLV and if the ICV doesn=E2=80=99t validate, >> discard the contained messages. >>=20 >> o When receiving a RREQ/RREP (either as destination, o= r as an intermediary), validate the ICV Message TLV=20 >> and if the ICV doesn=E2=80=99t validate,= discard the message, do not process, do not forward. >>=20 >> This is a different (and more flexible?) model than =E2=80=9Cjust=E2=80=9D= transitive trust and =E2=80=9Cjust=E2=80=9D end-to-end trust discussed prev= iously, and is enabled by the =E2=80=9Cforwarding=E2=80=9D bit described pre= viously. >>=20 >> Metrics >> I have asked this numerous times, but have not gotten any answer so I am e= scalating this again. Why is this document having a normative reference to R= FC6551? >>=20 >> [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., >> and D. Barthel, "Routing Metrics Used for Path Calculation >> in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/ >> RFC6551, March 2012, >> . >>=20 >>=20 >> Unless I am mistaken, this is not the ROLL WG. And the abstract to RFC655= 1 explicitly reads: >>=20 >> Low-Power and Lossy Networks (LLNs) have unique characteristics >> compared with traditional wired and ad hoc networks that require the >> specification of new routing metrics and constraints. =20 >> Which explicitly is disclaiming that these metrics are not applicable in a= d hoc networks =E2=80=94 and, I am wondering, what has changed since the pub= lication of RFC6551 to suddenly make these applicable? >>=20 >> I am also wondering if looking at (and, perhaps, using?) the same metric= type TLV type as in OLSRv2 is not a possibility? >>=20 >> Either way, referencing RFC6551 here is wrong. >>=20 >> RFC6621 (SMF) usage >> As late as earlier this month, RFC6621 reared its head again on the maili= ng list. I understand that the authors are set on using flooding reduction a= s part of RREQ distribution. If that is the case, then this protocol MUST sp= ecify that flooding reduction.=20 >>=20 >> Saying =E2=80=9CUse RFC6621=E2=80=9D won=E2=80=99t work, for reasons Chri= s point out in an email earlier to the list: >>> The network does not and fundamentally cannot offer multicast suppressio= n to AODVv2. This isn't a hard concept, but seems to keep having to be said.= AODVv2 messages are carried in 5444 packets, and those only travel one hop.= That doesn't allow for suppression. Furthermore AODVv2 is creating new mess= ages each hop. That needs AODVv2 specific handling. >>=20 >>=20 >> And quoting an email from myself: >>> If protocol X relies on using a flooding operation, then it certainly is= protocol X's responsibility to specify the flooding operation (or, at leas= t, the requirements to the flooding operation ) for correct functioning of p= rotocol X. >>=20 >> I=E2=80=99ve previously pointed out that RFC6621 requires some degree of c= onfiguration (can=E2=80=99t just, for example, pick two different relay set s= election algorithms, as that may produce a disconnected flooding domain). >>=20 >> In other words, what the authors propose in https://tools.ietf.org/html/d= raft-perkins-manet-using-rfc6621-00 is insufficient. >>=20 >> Multiple interfaces configured with the same address(es) - & RFC6621 >> I think that it has been established that the ability to use the same add= ress on multiple interfaces is a requirement. It=E2=80=99s not clear to me t= hat a single way of doing so has been proposed, nor that the =E2=80=9Coperat= ing conditions=E2=80=9D are called out (for example, will it work if router= A and router B both have two interfaces, and that all 4 interfaces use the s= ame IP address?) >>=20 >> This is not entirely unrelated to flooding reduction and RFC6621. One of t= he complexities is to get that just right: OLSRv2 - for example - calculates= Flooding-MPRs per interface, and RFC6130 is careful in how it detects bidir= ectionality of links.=20 >>=20 >> I have not worked out all the details of how this impacts this protocol =E2= =80=94 but, it requires attention. Especially when wanting to be able to say= =E2=80=9C=E2=80=A6use RFC6621=E2=80=9D, then the interface configuration co= nstraints when faced with multiple interfaces must be worked out. >>=20 >> Prefixes & Gateways >> A question to my mind, and I am not sure I know how to answer that from r= eading the draft since it is not discussed in section 9 (at least), is: =E2=80= =9CWhat happens if I send a RREQ to a prefix=E2=80=9D (i.e., a /<128 in IPv6= )? >>=20 >> o If the whole prefix is part of the attached network set of a= single router,=20 >> then I expect to get a single RREP back, is that the case? >>=20 >> o If "half the prefix" is part of the attached network set o= f a single router,=20 >> and the other half is part of the attached network set of a= nother single router,=20 >> then I expect two RREPs, is that the case? >>=20 >> o More generally, will I get a tree build through the network= here? >=20 > AODVv2 currently doesn=E2=80=99t support RREQs for prefixes. I=E2=80=99ve a= lready added =E2=80=9EIf RteMsg is a RREQ, RteMsg.TargPrefixLen SHOULD equal= address length.=E2=80=9C to RteMsg.TargPrefixLen in section 4.6. Multicast R= oute Message Table in response to Justin=E2=80=99s comments, but I=E2=80=99l= l go through the draft again and see where we need to state this more clearl= y. >=20 > Best regards, > Lotte Steenbrink >=20 >>=20 >> Section 9 (or, the whole spec) is also not explicit enough about multiple= "default gateways" =E2=80=94 i.e., the external network being =E2=80=9Cthe= rest of the Internet=E2=80=9D, and there being multiple gateways to the Int= ernet. I understand how the RREQ gets to the gateway, and how the gateway de= termines if it should respond (the destination is not part of =E2=80=9Cthe M= ANET prefix, with which it is configured=E2=80=9D). >>=20 >> But, if A is close to GW1, and B is close to GW2, but A and B being far f= ar apart (according to the metric used) within the MANET, then it would be p= referential for the route from A to B to go via GW1-=E2=80=9Cthe-Internet=E2= =80=9D-GW2?=20 >>=20 >> Is this a supported configuration?=20 >> o If yes, how is it (seq# wise, I would expect some complicat= ions) handled?=20 >> o If not, where is it stated that this configuration is not p= ossible with this protocol? >>=20 >>=20 >> The applicability statement says: >>=20 >> AODVv2 is designed for stub or disconnected mobile ad hoc networks, >> i.e., non-transit networks or those not connected to the internet. >> AODVv2 can, however, be configured to perform gateway functions when >> attached to external networks, as discussed in Section 9. >>=20 >> I believe that the scenario I describe is indeed a stub network (and not a= transit network)? >>=20 >> =E2=80=94 =E2=80=94 =E2=80=94=20 >>=20 >> As I indicated, these are the big-picture issues that I have gotten aroun= d to thinking about enough to write up. I=E2=80=99m not through working thro= ugh the document, but those were the ones that came to mind, and which seem i= mperative to resolve. >>=20 >> Best, >>=20 >> Thomas >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail-3D55A268-6EA1-43A1-B62A-63B1538E0012 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Lotte, all,

On 19 Mar 2016, at 12:34, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:

Hi Thomas,
thank you for reviewing AODVv2 yet again :) Some answers below:


D= ear all,

Apologies for n= ot having gotten this done sooner - day-job leaving few spare cycles.
<= div class=3D"">
I=E2=80=99ve previously o= ffered reviews and comments, and some of those have been addressed in the la= test I-D =E2=80=94 others have not, but should be. I recall that there was s= ome mail attempting to rebut parts of the review, and I will dig it out and r= eply to that.


That wold be great.

I am finding a bit of time here and there whe= n there are holes in the agenda, and am (as you likely have noticed) backtra= cking through emails when I get a chance. Apologies, I hope that I will get t= o these emails this, or next week, but day-job eats in to the available time= ;(

Forwarding-vs-regeneration=
Recent exchanges on the list made me understand th= at protocol control messages are *not* forwarded, but are consumed at each h= op, then a new message with (almost-but-not-quite) the same content is gener= ated and transmitted.

That=E2=80=99s what we=E2=80=99ve been trying to say all along! I=E2=80= =99m really glad we=E2=80=99re having this conversation.

Then, let us have it -- it's a central point= to get right.

=
I have thought some more on this (& r= ead some of the exchanges on the list on this topic by Chris, Ulrich, and ot= hers), and I am convinced that this is not the right way to go, at least for the following reasons:

o It ren= ders the hop-limit/hop-count fields in the RFC5444 message header useless.
This would not be bad if the functionality offered b= y those fields was not useful
=E2=80=94 sadly, it i= s. For example, for scope limited flooding (expanding ring search, and =
such) which may be of interest, and which require ho= p-limit. 
A hop-count field may also provide a= =E2=80=9Ccheap=E2=80=9D (in terms of overhead) additional piece
= of information to use conjunctively with a =E2=80=9Creal=E2=80=9D me= tric.


I agree on the usefulness, which is why we were p= uzzled when we were told we weren=E2=80=99t allowed to use those fields (or,= rather, that we were using them wrong, but that the right way to use them d= oesn=E2=80=99t work for AODvv2). I believe Vicky has written about this in m= ore detail in previous discussions, and we were/are looking forward to readi= ng your answers...

So, th= e source generates a message, the message is forwarded through the network, w= ith each intermediate router decrementing the hop limit and incrementing the= hop count.

As stated in the 5444-Usage document, w= hen forwarding a message, the hop-limit/hop-count are modified, the rest of t= he message SHOULD not be. 

That is specificall= y, one thing where I kinda would like 5444-usage to go further is "the messa= ge structure MUST in all conditions preserved when forwarding" - but still s= ay "and it is RECOMMENDED that the value field of TLVs are also not modified= ".

What this buys is several things, in the context= of this protocol:

o hop-limit/hop-count could be useful for the u= sual 
purposes (ensuring that messages do not live forever= , 
= scope-limited flooding, ...)

o if the accumulated p= ath metric is stored in a TLV value field, that 
value field c= an (with suitable disclaimer to call out "we know it is
RECOMMENDED t= o not do this, but here's why we are OK in doing
it anyways")= be modified when forwarding the message, and

o as that path metric f= ield is in a message whose structure does not
change, it will be "= at the same place in the byte-stream" at each hop,
which
<= div>
o allo= ws useful things such as deriving from RFC7182 a form of
"whe= n calculating the ICV, zero out that field in the message ' when
<= span class=3D"Apple-tab-span" style=3D"white-space:pre">   validating an ICV, also zero out that field" -- which goes one st= ep
=   further (when coupled with a time stamp) than simple transiti= ve trust, 
  but also

o allows even more fancy and u= seful (albeit experimental) things such
as aggregate signatures to w= ork correctly.

Furthermore.....

The only practical solution would be to re-introduce these functions by w= ay of inserting a
MessageTLV =E2=80=94 which (i) is no= t specified in this document, and (ii) which would just
serve to render messages bigger than strictly needed.
<= /blockquote>

Exactly; we=E2=80=99d really like= to avoid this as well.

<= div>
... It avoids the above, and....


Scope limited flooding  does seem to be= a necessary requirement, if for no
other reason than to= prevent information from =E2=80=9Ccirculating forever in the network=E2=80=9D= .

AODVv2=E2=80=99= s duplicated detection hopefully should take care of that. Iirc, We interpre= ted your earlier E-Mails to (implicitly) mean that you think we should rely o= n that, since you said we can=E2=80=99t use the hop-limit/hop-count fields.<= /div>

....if don= e (proper forwarding with preservation of the structure, rather than regener= ation which opens up the "this is a new message with potentially new structu= re" can of worms) as I describe, also addresses the above.

With respe= ct to what I said earlier when I said "can't use hop-limit/hop-count fields"= ....when you regenerate, you absolutely, definitely, can't.

=
When you "reg= enerate" a message, that means "you construct a brand new message" which may= shuffle addresses inside address blocks, or between address blocks, shuffle= TLVs differently than they were originally, even use TLVs of different stru= cture (e.g., single-value TLVs instead of multi-value TLVs). 

This m= eans that some assumptions (such as when producing an ICV for the message, w= hich depends on the byte order) don't hold. Well, they may not hold, so that= means we can't assume that they do. Which means that the originator of a me= ssage cannot generate an ICV that can be correctly interpreted (which is wha= t my next section in my original mail was about).

Which means, in conclus= ion,  that the information in the message profoundly change -- and ther= efore these hop-count/hop-limit values do not even apply to "the information= ". 

However if proper forwarding with preservation of the struc= ture, rather than regeneration which opens up the "this is a new message wit= h potentially new structure" can of worms, as I (& Ulrich & others) h= ave suggested, is taken to heart, it also addresses the issue below regardin= g end-to-end authentication (which, while still hard, is possible).

A cou= ple of more comments below


=
= o It makes end-to-end authentication unnecessa= rily hard.
I think Chris called this out alread= y, but it bears repeating: S generates a message 
= (say, a RREQ), and includes an ICV calculated over the content of the me= ssage.
For any recipient to be able to validate the= ICV, the message has to be exactly
the same =E2=80=94 n= ot just in content, but in structure =E2=80=94 as what was generated.
<= div class=3D"">
=E2=80=9CRegeneratin= g=E2=80=9D rather than =E2=80=9Cforwarding=E2=80=9D messages means, that the= intermediate
router =E2=80=9Cregenerating=E2=80=9D= the RREQ may chose a different structure (e.g., include TLVs
= in a different order).

= The proposal from https://tools.ietf.org/html/draft-p= erkins-manet-aodv-e2esec-00
is to add constraint= s on (i) the set of elements to include in a signature and (ii) the
= order of these elements.

<= div class=3D"">= One problem with that approach is (i): if an extension a= dds a message TLV, or an 
Address TLV, to a me= ssage, then that will not be =E2=80=9Ccovered=E2=80=9D by the proposed e2ese= c TLV.
Rather for *each* extension developed, an =E2= =80=9Cupdates e2esec=E2=80=9D clause needs to be done.
=
I=E2=80=99d say that this approach w= ould be prone to errors =E2=80=94 and add entropy to the process
= of designing protocol extensions. The alternative, a message being g= enerated by the
source and *forwarded* (as we do in O= LSRv2, for example) would allow ICV TLVs 
(eve= n, allow reuse of those specified for OLSRv2) for covering a message and&nbs= p;
extensions.

= =E2=80=9CBut what about the metrics value which will change o= n each hop=E2=80=9D, you may say?
Fortunately, that is= relatively easy to handle: simply zero out the value of that TLV when
=
= generating or verifying the ICV MessageTLV. And use Packet-T= LVs for hop-by-hop 
authentication, if needed (b= ut, see below).

o It prevents the use of more clever/advanced signature schemes/ICVs
Aggregate signature algorithms ( http= s://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
exist, and an interesting use-case can be found in also reactive protoco= ls, allowing verifying
not =E2=80=9Cjust=E2=80=9D t= he end points, but also the intermediaries (again, with the appropriate =E2=80= =9Czero out=E2=80=9D
discussed above, or something smarte= r).
Regeneration of messages, rather than forwarding, re= nders that impossible (or, if used,
updating to  https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)<= /div>

There are other re= asons, but the above are those that jump at me as immediate show-stoppers.

I do honestly not s= ee what possible benefit there is from =E2=80=9Cregeneration=E2=80=9D =E2=80= =94 but I see very clear inconveniences, and security is not the least of th= ese. Insisting on =E2=80=9Cregeneration=E2=80=9D requires development of =E2= =80=9Cnon-general workarounds=E2=80=9D as pointed out above.

The possible benefit is that w= e need to accumulate & transport metric values somehow, and we can=E2=80= =99t do that without regenerating at least parts of the message.
I= f we=E2=80=99re missing a solution here, please share it with us.


Done in the above.


Security Considerations
<= br class=3D"">
Just for context=E2=80=99s sake, did you review the= security considerations in draft-ietf-manet-aodvv2-13 or the ones prop= osed in the thread =E2=80=9EAODVv2: Security considerations update=E2=80=9C?=

I did. It still is a far= cry from passing the bar. I've posted on why in the past, and some more in t= his mail (which also contains some suggestions).

I w= ould suggest that settling the rearchitecturing to do forwarding, as I describe in the above, s= hould be done, which would ease the security considerations issue considerab= ly (and which would be necessary even if ignoring the security consideration= s, IMO, for this doc to go anywhere). 

With a new version covering t= hat, the authors (I wanted to write "you", but decided to be inclusive) coul= d you go look at the different security emails and perhaps start= a separate thread on that, towards a resolution?

<= br>
Best,

Thomas



This is an always thorny subject. When OLSRv2 was g= oing through the process we got a thorough education in how little we knew a= bout security from the SEC-ADs, and had to spend about a year or so developi= ng RFC7183. The bottom line is, that this protocol needs its =E2=80=9CRFC718= 3  equivalent=E2=80=9D, either as part of the main document, or as an i= ndependent document. currently, that is not the case.
<= br class=3D"">
A minima, looking at BCP72 and BCP107 =E2= =80=94 taking inspiration from RFC7183 might be aw good idea, as that was th= e most recent that went through the SEC AD. Regardless of how, however, a =E2= =80=9Cmandatory to implement=E2=80=9D security mechanism most be specified (= I think the right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D), in= sufficient detail to ensure interoperable implementations.

As an example, both [RFC6130] and [RFC7181] set out that that:

  &n= bsp;   On receiving a ... message, a router MUST first check if the
      message is invalid for processing by t= his router

and the= n proceed to give a number of conditions that, each, will lead to a rejectio= n of the message as "badly formed and therefore invalid for processing=E2=80= =9D =E2=80=94 a list which RFC7183 then amended. That gave a =E2=80=9Chook=E2= =80=9D for RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for messa= ge generation.

If I= was to do RFC7181/RFC6130 today, I would include that directly into the pro= tocol specifications. It turned out to be more overhead (and slow down publi= cation anyways) to do it as separate documents.
<= br class=3D"">
Secondly, we need to be a lot more rigid= in terms of what ICVs, Timestamps, etc. are added/removed, and what that br= ings.

For example (= with the assumption that messages are *forwarded* and *not* regenerated), th= is could be one option:

o When= a RREQ, RREP message is generated, add an ICV Message TLV, which is calcula= ted <this way>
 =E2=80=A6(take inspira= tion from RFC7183 here)

o When= a RREQ, RREP message is transmitted  (by the source, or forwarded by a= n intermediary)
in an RFC5444 packet, an ICV= Packet TLV is added to the packet, which is calculated <this way> =E2= =80=A6

o When an RFC5444 pack= et is received, validate the ICV Packet TLV <this way> and if the ICV d= oesn=E2=80=99t validate,
discard the containe= d messages.

o When receivi= ng a RREQ/RREP (either as destination, or as an intermediary), validate the I= CV Message TLV 
<this way> and if the I= CV doesn=E2=80=99t validate, discard the message, do not process, do not for= ward.

This is a di= fferent (and more flexible?) model than =E2=80=9Cjust=E2=80=9D transitive tr= ust and =E2=80=9Cjust=E2=80=9D end-to-end trust discussed previously, and is= enabled by the =E2=80=9Cforwarding=E2=80=9D bit described previously.
=

Metrics
I have asked this numerous times, bu= t have not gotten any answer so I am escalating this again. Why is this docu= ment having a normative reference to RFC6551?

   [RFC6551]  Vasseur, JP., E=
d., Kim, M., Ed., Pister, K., Dejean, N.,
              and D. Barthel, "Routing Metrics Used for Path Calculation
              in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/
              RFC=
6551, March 2012,
              <http://www.rfc-editor.org/info/rfc6551>.


U= nless I am mistaken, this is not the ROLL WG. And the abstract to RFC6551 ex= plicitly reads:

Low= -Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints.
Which explicitly is disclaiming that these metrics are not applicable in ad hoc networks =E2=80=94 and, I am wond= ering, what has changed since the publication of RFC6551 to suddenly make th= ese applicable?

&n= bsp;I am also wondering if looking at (and, perhaps, using?) the same metric= type TLV type as in OLSRv2 is not a possibility?

Either way, referencing RFC6551 here i= s wrong.

RFC6621 (SMF) usage
As late as= earlier this month, RFC6621 reared its head again on the mailing list. I un= derstand that the authors are set on using flooding reduction as part of RRE= Q distribution. If that is the case, then this protocol MUST specify that fl= ooding reduction. 

Saying =E2=80=9CUse RFC6621=E2=80=9D won=E2=80=99t work, for reasons C= hris point out in an email earlier to the list:
The network does not and fundamentally cannot o= ffer multicast suppression to AODVv2. This isn't a hard concept, but seems t= o keep having to be said. AODVv2 messages are carried in 5444 packets, a= nd those only travel one hop. That doesn't allow for suppression. Furth= ermore AODVv2 is creating new messages each hop. That needs AODVv2 specific h= andling.

And quoting an email from myself:
If protocol X relies on using a flooding operation, then i= t certainly is protocol X's responsibility to  specify the flooding ope= ration (or, at least, the requirements to the flooding operation ) for c= orrect functioning of protocol X.

=
I=E2=80=99ve previously pointed out that RFC6621 requi= res some degree of configuration (can=E2=80=99t just, for example, pick two d= ifferent relay set selection algorithms, as that may produce a disconnected f= looding domain).

I= n other words, what the authors propose in https://tools.ie= tf.org/html/draft-perkins-manet-using-rfc6621-00 is insufficient.

Multiple interfaces configured with the same address(es) - & RFC= 6621
I think that it has been established that t= he ability to use the same address on multiple interfaces is a requirement. I= t=E2=80=99s not clear to me that a single way of doing so has been proposed,= nor that the =E2=80=9Coperating conditions=E2=80=9D are called out (for exa= mple, will it work  if router A and router B both have two interfaces, a= nd that all 4 interfaces use the same IP address?)

This is not entirely unrelated to flooding r= eduction and RFC6621. One of the complexities is to get that just right: OLS= Rv2 - for example - calculates Flooding-MPRs per interface, and RFC6130 is c= areful in how it detects bidirectionality of links. 

I have not worked out all the detail= s of how this impacts this protocol =E2=80=94 but, it requires attention. Es= pecially when wanting to be able to say =E2=80=9C=E2=80=A6use RFC6621=E2=80=9D= , then the interface configuration constraints when faced with multiple inte= rfaces must be worked out.

Prefixes & Gateways
A question to my mind, and I am not sure I know how to answer t= hat from reading the draft since it is not discussed in section 9 (at least)= , is: =E2=80=9CWhat happens if I send a RREQ to a prefix=E2=80=9D (i.e., a /= <128 in IPv6)?

= o If the whole= prefix is part of the attached network set of a single router, 
<= div class=3D"">= then I expect to get a single RREP back, is that the case?

o If "half the prefix"  is part o= f the attached network set of a single router, 
and t= he other half is part of the attached network set of another  single ro= uter, 
then I expect two RREPs, is that the case?

o More generally, will I get a tree bu= ild through the network here?

AODVv2 currently doesn=E2=80=99t support RREQs for prefixes. I= =E2=80=99ve already added =E2=80=9EIf RteM= sg is a RREQ, RteMsg.TargPrefixLen SHOULD equal address length.=E2=80= =9C to RteMsg.TargPrefixLen in section 4.6. Multicast Route Message Table in response to Justin= =E2=80=99s comments, but I=E2=80=99ll go through the draft again and see whe= re we need to state this more clearly.

B= est regards,
Lotte Steenbrink

<= div class=3D"">
Section 9 (or, the whole= spec) is also not explicit enough about multiple  "default gateways" =E2= =80=94 i.e., the external network being =E2=80=9Cthe rest of the Internet=E2= =80=9D, and there being multiple gateways to the Internet. I understand how t= he RREQ gets to the gateway, and how the gateway determines if it should res= pond (the destination is not part of =E2=80=9Cthe MANET prefix, with which i= t is configured=E2=80=9D).

But, if A is close to GW1, and B is close to GW2, but A and B being= far far apart (according to the metric used) within the MANET, then it woul= d be preferential for the route from A to B to go via GW1-=E2=80=9Cthe-Inter= net=E2=80=9D-GW2? 

Is this a supported configuration? 
o If yes, how is it (s= eq# wise, I would expect some complications) handled? 
o If not, wher= e is it stated that this configuration is not possible with this protocol?


The applicability statement says:
   A=
ODVv2 is designed for stub or disconnected mobile ad hoc networks,
   i.e., non-transit networks or those not connected to the internet.
   AODVv2 can, however, be configured to perform gateway functions when
   attached to external networks, as discussed in Section 9.=

I believe t= hat the scenario I describe is indeed a stub network (and not a transit netw= ork)?

=E2=80=94 =E2= =80=94 =E2=80=94 

As I indicated, these are the big-picture issues that I have gotten aroun= d to thinking about enough to write up. I=E2=80=99m not through working thro= ugh the document, but those were the ones that came to mind, and which seem i= mperative to resolve.

Best,

Thomas



________________________________= _______________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/li= stinfo/manet

= --Apple-Mail-3D55A268-6EA1-43A1-B62A-63B1538E0012-- From nobody Wed Apr 20 03:30:39 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 49EA512EE3C for ; Wed, 20 Apr 2016 03:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.609 X-Spam-Level: X-Spam-Status: No, score=-6.609 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, TRACKER_ID=1.306] 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 sjHzkb_r4mfY for ; Wed, 20 Apr 2016 03:30:33 -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 B294712EE3A for ; Wed, 20 Apr 2016 03:30:32 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,509,1454976000"; d="scan'208,217"; a="62531591" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 20 Apr 2016 11:30:31 +0100 X-IronPort-AV: E=Sophos;i="5.24,509,1454976000"; d="scan'208,217";a="114754639" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 20 Apr 2016 11:30:30 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Wed, 20 Apr 2016 11:30:31 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Clausen , Lotte Steenbrink Thread-Topic: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items) Thread-Index: AQHRmuq4sr6y+au39kGswdQyX9PrDp+SpNaA Date: Wed, 20 Apr 2016 10:30:29 +0000 Message-ID: References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org> <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> In-Reply-To: <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AF005GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items) 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, 20 Apr 2016 10:30:38 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AF005GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Q2FuIEkganVzdCBzYXkgaXTigJlzIHF1aXRlIGhhcmQgdG8gd29yayBvdXQgd2hvIGlzIHNheWlu ZyB3aGF0IGluIHRoZXNlIGV4Y2hhbmdlcy4gSeKAmW0gaGF2aW5nIHRvIGd1ZXNzIHNvbWUgb24g dGhlIGJhc2lzIG9mIOKAnHRoYXQgc291bmRzIGxpa2UgVGhvbWFz4oCdIG9yIOKAnHRoYXQgc291 bmRzIGxpa2UgTG90dGXigJ0uDQoNCldoYXQgSeKAmW0gbm90IGNsZWFyIG9uIGlzIHdoYXQgY29u Y2x1c2lvbiwgaWYgYW55LCB5b3XigJl2ZSBkcmF3biBvbiBob3AgY291bnQvbGltaXQuDQoNCkFz IEkgc2VlIGl0LCBpZiB0aGUgcHJvdG9jb2wgcmVjZWl2ZXMgYSBtZXNzYWdlIHRoZW4gc2VuZHMg YSBtZXNzYWdlIHNpbWlsYXIgYnV0IG5vdCBpZGVudGljYWwgdG8gdGhhdCBvdXQsIHRoYXQgY2Fu IGJlIHJldmlld2VkIGFzIGNyZWF0aW5nIGEgbmV3IG1lc3NhZ2UuIEl0IGlzIGEgbmV3IG1lc3Nh Z2UgYXMgZmFyIGFzIDcxODIgaXMgY29uY2VybmVkLg0KDQpCdXQgdGhlIHByb3RvY29sIGNvdWxk IGltcG9zZSBzb21lIHJlc3RyaWN0aW9ucy4gRm9yIGV4YW1wbGUg4oCcdGhlIG9ubHkgdGhpbmcg YWxsb3dlZCB0byBiZSBjaGFuZ2VkIGlzIHRoaXMgZmllbGQgaW4gdGhpcyBUTFbigJ0uIFdoaWNo IGl0IHdvdWxkIHRoZXJlZm9yZSBiZSBhIGdvb2QgaWRlYSBmb3IgdGhlIGNyZWF0b3Igb2YgdGhl IG1lc3NhZ2UgdG8gaW5jbHVkZSwgZXZlbiBpZiBpdCB0aHVzIG5lZWRlZCB0byBpbmNsdWRlIGEg bGluayBtZXRyaWMgb2YgemVyby4gKFdoaWNoIGlzIGEgZGVzaWduIHBvaW50IC0geW91IG1pZ2h0 IG5lZWQgdG8gYWxsb3cgdGhhdCBpbiBtZXRyaWMgc3BlY2lmaWNhdGlvbi4pIEJ1dCB5b3Ugd291 bGQgbmVlZCB0byBzdGF0ZSB0aGF0LiBUaGF0IGVuYWJsZXMgc29tZSBmdXR1cmUgZGVzaWducyAt IG5vdCA3MTgyLCBwb3NzaWJseSBhbiBleHRlbnNpb24gdG8gNzE4MiwgcG9zc2libHkgc29tZXRo aW5nIG5ldy4gVGhlcmUgaXMgYSBwcm9ibGVtIHRoYXQgdGhpcyBpZGVhIHdvdWxkIGJlIHB1dHRp bmcgaW4gYSBuZWVkIHRvIHVuZGVyc3RhbmQgc3BlY2lmaWMgVExWcywgd2hpY2ggaXMgdW5kZXNp cmFibGUuIEkgaGF2ZSBzb21lIGlkZWFzIHRoZXJlLCBzdWNoIGFzIHVzaW5nIHRoZSBwcm90b2Nv bC1zcGVjaWZpYyBzcGFjZSwgYnV0IHRoaXMgaXNu4oCZdCBhIGZpdmUgbWludXRlIGpvYiwgYW5k IG5lZWRzIHRvIGJlIGdvdCByaWdodC4gV2hpbGUgbm93IGlzIG5vdCB0aGUgdGltZSB0byBkZWZp bmUgdGhpcywgc29tZSBkZWNpc2lvbnMgY291bGQgcmVhbGx5IGltcGFjdCBvbiBmdXR1cmUgZGVz aWducy4gRm9yIGV4YW1wbGUgcHV0dGluZyBhbnl0aGluZyB3YW50aW5nIHRvIGJlIG11dGFibGUg c3R1Y2sgaW4gdGhlIG1pZGRsZSBvZiBhbGwgdGhlIG90aGVyIFRMVnMgd291bGQgYmUgY29uc3Ry YWluaW5nLiBNYWtpbmcgYWxsIGludGVuZGVkIHRvIGJlIG11dGFibGUgYnkgdGhpcyBwcm90b2Nv bCBUTFZzIGluIHRoZSBwcm90b2NvbCBzcGVjaWZpYyBzcGFjZSBpcyBwcm9iYWJseSB0aGUgbGVh c3QgYmFkIGlkZWEsIGFzIHRoYXQgY291bGQgYmUgZ2VuZXJhbGlzZWQgKGVpdGhlciBtYWtpbmcg dGhhdCBzcGFjZSBub3QgY292ZXJlZCBieSB0aGlzIGh5cG90aGV0aWNhbCA3MTgyIHZhcmlhbnQs IG9yIHNwbGl0dGluZyBpdCkuDQoNClRoYXQgbGVhdmVzIGhvcCBjb3VudC9saW1pdC4gVGVjaG5p Y2FsbHkgeW91IHdvdWxkbuKAmXQgaW5jcmVtZW50L2RlY3JlbWVudCwgYXMgaXTigJlzIGEgbmV3 IG1lc3NhZ2UuIEJ1dCB5b3UgY2FuIHNlbmQgYW55IGhvcCBsaW1pdCBvbiBhbnkgbmV3IG1lc3Nh Z2UsIHNvIHRoYXQgY291bGQgYmUgb25lIGxlc3MgdGhhbiB0aGUgb25lIHlvdSByZWNlaXZlZC4g SG9wIGNvdW50IGlzIGEgYml0IG1vcmUgYXJndWFibGUuIEnigJltIG5vdCBzdXJlIGhvdyBjbGVh cmx5IGl0cyBtZWFuaW5nIGlzIGluZGljYXRlZCwgd2hldGhlciBpdCBpcyBhIOKAnHJlYWzigJ0g aG9wIGNvdW50IG9mIHRoaXMgbWVzc2FnZS4gQnV0IGlmIHlvdSBuZWVkZWQgdG8gSSB3b3VsZG7i gJl0IGJlIHRvbyBzdHJvbmdseSBhZ2FpbnN0IGRvaW5nIHdoYXQgbG9va3MgbGlrZSBpbmNyZW1l bnRpbmcgdGhhdCwgYXMgbG9uZyBhcyBjYXJlZnVsbHkgZXhwbGFpbmVkLiAoQSBrZXkgcXVlc3Rp b24gaXMgaWYgeW91IHVzZSA1NDk3IFRMVnMuIEluIHRoYXQgY2FzZSBJIHRoaW5rIC0gY29tYmlu ZWQgd2l0aCB0aGUg4oCcb25seSBjaGFuZ2Ugb25lIHRoaW5nIGFib3Zl4oCdIHRoYXQgeW91IG5l ZWQgdG8gYXBwZWFyIHRvIGluY3JlbWVudCBob3AgbGltaXQsIGkuZS4gY3JlYXRlIGEgbmV3IG1l c3NhZ2Ugd2l0aCBhIG5vbi16ZXJvIGhvcCBjb3VudC4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJs b3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs bGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0 NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJp cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxp Z2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2Zv cmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVz eXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQN ClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBP ZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0K DQpGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBUaG9tYXMgQ2xhdXNlbg0KU2VudDogMjAgQXByaWwgMjAxNiAxMDo1NQ0KVG86IExvdHRlIFN0 ZWVuYnJpbmsNCkNjOiBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdA0KU3ViamVj dDogW21hbmV0XSBPbiBGb3J3YXJkaW5nLWFuZC1yZWdlbmVyYXRpb24gKHdhczogUmU6IGRyYWZ0 LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEgY291cGxlIG9mIGJpZyB0aWNrZXQgSXRl bXMpDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91 dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBv ciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNs aWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5m b3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGlu IGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5 c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBG bGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBm b2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93 d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3Vz cGljaW91cyUyMEVtYWlscy5wZGY+Lg0KKioqIFdBUk5JTkcgKioqDQpFWFRFUk5BTCBFTUFJTCAt LSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbi4N Cg0KTG90dGUsIGFsbCwNCg0KT24gMTkgTWFyIDIwMTYsIGF0IDEyOjM0LCBMb3R0ZSBTdGVlbmJy aW5rIDxsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZTxtYWlsdG86bG90dGUuc3RlZW5icmlu a0BmdS1iZXJsaW4uZGU+PiB3cm90ZToNCkhpIFRob21hcywNCnRoYW5rIHlvdSBmb3IgcmV2aWV3 aW5nIEFPRFZ2MiB5ZXQgYWdhaW4gOikgU29tZSBhbnN3ZXJzIGJlbG93Og0KDQpBbSAxNy4wMy4y MDE2IHVtIDE3OjAwIHNjaHJpZWIgaWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzxtYWlsdG86aWV0ZkB0 aG9tYXNjbGF1c2VuLm9yZz46DQoNCkRlYXIgYWxsLA0KDQpBcG9sb2dpZXMgZm9yIG5vdCBoYXZp bmcgZ290dGVuIHRoaXMgZG9uZSBzb29uZXIgLSBkYXktam9iIGxlYXZpbmcgZmV3IHNwYXJlIGN5 Y2xlcy4NCg0KSeKAmXZlIHByZXZpb3VzbHkgb2ZmZXJlZCByZXZpZXdzIGFuZCBjb21tZW50cywg YW5kIHNvbWUgb2YgdGhvc2UgaGF2ZSBiZWVuIGFkZHJlc3NlZCBpbiB0aGUgbGF0ZXN0IEktRCDi gJQgb3RoZXJzIGhhdmUgbm90LCBidXQgc2hvdWxkIGJlLiBJIHJlY2FsbCB0aGF0IHRoZXJlIHdh cyBzb21lIG1haWwgYXR0ZW1wdGluZyB0byByZWJ1dCBwYXJ0cyBvZiB0aGUgcmV2aWV3LCBhbmQg SSB3aWxsIGRpZyBpdCBvdXQgYW5kIHJlcGx5IHRvIHRoYXQuDQoNCg0KVGhhdCB3b2xkIGJlIGdy ZWF0Lg0KDQpJIGFtIGZpbmRpbmcgYSBiaXQgb2YgdGltZSBoZXJlIGFuZCB0aGVyZSB3aGVuIHRo ZXJlIGFyZSBob2xlcyBpbiB0aGUgYWdlbmRhLCBhbmQgYW0gKGFzIHlvdSBsaWtlbHkgaGF2ZSBu b3RpY2VkKSBiYWNrdHJhY2tpbmcgdGhyb3VnaCBlbWFpbHMgd2hlbiBJIGdldCBhIGNoYW5jZS4g QXBvbG9naWVzLCBJIGhvcGUgdGhhdCBJIHdpbGwgZ2V0IHRvIHRoZXNlIGVtYWlscyB0aGlzLCBv ciBuZXh0IHdlZWssIGJ1dCBkYXktam9iIGVhdHMgaW4gdG8gdGhlIGF2YWlsYWJsZSB0aW1lIDso DQoNCg0KRm9yd2FyZGluZy12cy1yZWdlbmVyYXRpb24NClJlY2VudCBleGNoYW5nZXMgb24gdGhl IGxpc3QgbWFkZSBtZSB1bmRlcnN0YW5kIHRoYXQgcHJvdG9jb2wgY29udHJvbCBtZXNzYWdlcyBh cmUgKm5vdCogZm9yd2FyZGVkLCBidXQgYXJlIGNvbnN1bWVkIGF0IGVhY2ggaG9wLCB0aGVuIGEg bmV3IG1lc3NhZ2Ugd2l0aCAoYWxtb3N0LWJ1dC1ub3QtcXVpdGUpIHRoZSBzYW1lIGNvbnRlbnQg aXMgZ2VuZXJhdGVkIGFuZCB0cmFuc21pdHRlZC4NCg0KVGhhdOKAmXMgd2hhdCB3ZeKAmXZlIGJl ZW4gdHJ5aW5nIHRvIHNheSBhbGwgYWxvbmchIEnigJltIHJlYWxseSBnbGFkIHdl4oCZcmUgaGF2 aW5nIHRoaXMgY29udmVyc2F0aW9uLg0KDQpUaGVuLCBsZXQgdXMgaGF2ZSBpdCAtLSBpdCdzIGEg Y2VudHJhbCBwb2ludCB0byBnZXQgcmlnaHQuDQoNCg0KSSBoYXZlIHRob3VnaHQgc29tZSBtb3Jl IG9uIHRoaXMgKCYgcmVhZCBzb21lIG9mIHRoZSBleGNoYW5nZXMgb24gdGhlIGxpc3Qgb24gdGhp cyB0b3BpYyBieSBDaHJpcywgVWxyaWNoLCBhbmQgb3RoZXJzKSwgYW5kIEkgYW0gY29udmluY2Vk IHRoYXQgdGhpcyBpcyBub3QgdGhlIHJpZ2h0IHdheSB0byBnbywgYXQgbGVhc3QgZm9yIHRoZSBm b2xsb3dpbmcgcmVhc29uczoNCg0KDQogICAgICAgICAgICBvICAgICAgICAgIEl0IHJlbmRlcnMg dGhlIGhvcC1saW1pdC9ob3AtY291bnQgZmllbGRzIGluIHRoZSBSRkM1NDQ0IG1lc3NhZ2UgaGVh ZGVyIHVzZWxlc3MuDQogICAgICAgICAgICAgICAgICAgICAgICBUaGlzIHdvdWxkIG5vdCBiZSBi YWQgaWYgdGhlIGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBieSB0aG9zZSBmaWVsZHMgd2FzIG5vdCB1 c2VmdWwNCiAgICAgICAgICAgICAgICAgICAgICAgIOKAlCBzYWRseSwgaXQgaXMuIEZvciBleGFt cGxlLCBmb3Igc2NvcGUgbGltaXRlZCBmbG9vZGluZyAoZXhwYW5kaW5nIHJpbmcgc2VhcmNoLCBh bmQNCiAgICAgICAgICAgICAgICAgICAgICAgIHN1Y2gpIHdoaWNoIG1heSBiZSBvZiBpbnRlcmVz dCwgYW5kIHdoaWNoIHJlcXVpcmUgaG9wLWxpbWl0Lg0KICAgICAgICAgICAgICAgICAgICAgICAg QSBob3AtY291bnQgZmllbGQgbWF5IGFsc28gcHJvdmlkZSBhIOKAnGNoZWFw4oCdIChpbiB0ZXJt cyBvZiBvdmVyaGVhZCkgYWRkaXRpb25hbCBwaWVjZQ0KICAgICAgICAgICAgICAgICAgICAgICAg b2YgaW5mb3JtYXRpb24gdG8gdXNlIGNvbmp1bmN0aXZlbHkgd2l0aCBhIOKAnHJlYWzigJ0gbWV0 cmljLg0KDQoNCkkgYWdyZWUgb24gdGhlIHVzZWZ1bG5lc3MsIHdoaWNoIGlzIHdoeSB3ZSB3ZXJl IHB1enpsZWQgd2hlbiB3ZSB3ZXJlIHRvbGQgd2Ugd2VyZW7igJl0IGFsbG93ZWQgdG8gdXNlIHRo b3NlIGZpZWxkcyAob3IsIHJhdGhlciwgdGhhdCB3ZSB3ZXJlIHVzaW5nIHRoZW0gd3JvbmcsIGJ1 dCB0aGF0IHRoZSByaWdodCB3YXkgdG8gdXNlIHRoZW0gZG9lc27igJl0IHdvcmsgZm9yIEFPRHZ2 MikuIEkgYmVsaWV2ZSBWaWNreSBoYXMgd3JpdHRlbiBhYm91dCB0aGlzIGluIG1vcmUgZGV0YWls IGluIHByZXZpb3VzIGRpc2N1c3Npb25zLCBhbmQgd2Ugd2VyZS9hcmUgbG9va2luZyBmb3J3YXJk IHRvIHJlYWRpbmcgeW91ciBhbnN3ZXJzLi4uDQoNClNvLCB0aGUgc291cmNlIGdlbmVyYXRlcyBh IG1lc3NhZ2UsIHRoZSBtZXNzYWdlIGlzIGZvcndhcmRlZCB0aHJvdWdoIHRoZSBuZXR3b3JrLCB3 aXRoIGVhY2ggaW50ZXJtZWRpYXRlIHJvdXRlciBkZWNyZW1lbnRpbmcgdGhlIGhvcCBsaW1pdCBh bmQgaW5jcmVtZW50aW5nIHRoZSBob3AgY291bnQuDQoNCkFzIHN0YXRlZCBpbiB0aGUgNTQ0NC1V c2FnZSBkb2N1bWVudCwgd2hlbiBmb3J3YXJkaW5nIGEgbWVzc2FnZSwgdGhlIGhvcC1saW1pdC9o b3AtY291bnQgYXJlIG1vZGlmaWVkLCB0aGUgcmVzdCBvZiB0aGUgbWVzc2FnZSBTSE9VTEQgbm90 IGJlLg0KDQpUaGF0IGlzIHNwZWNpZmljYWxseSwgb25lIHRoaW5nIHdoZXJlIEkga2luZGEgd291 bGQgbGlrZSA1NDQ0LXVzYWdlIHRvIGdvIGZ1cnRoZXIgaXMgInRoZSBtZXNzYWdlIHN0cnVjdHVy ZSBNVVNUIGluIGFsbCBjb25kaXRpb25zIHByZXNlcnZlZCB3aGVuIGZvcndhcmRpbmciIC0gYnV0 IHN0aWxsIHNheSAiYW5kIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIHZhbHVlIGZpZWxkIG9m IFRMVnMgYXJlIGFsc28gbm90IG1vZGlmaWVkIi4NCg0KV2hhdCB0aGlzIGJ1eXMgaXMgc2V2ZXJh bCB0aGluZ3MsIGluIHRoZSBjb250ZXh0IG9mIHRoaXMgcHJvdG9jb2w6DQoNCiAgICAgICAgICAg IG8gICAgICAgICAgaG9wLWxpbWl0L2hvcC1jb3VudCBjb3VsZCBiZSB1c2VmdWwgZm9yIHRoZSB1 c3VhbA0KICAgICAgICAgICAgICAgICAgICAgICAgcHVycG9zZXMgKGVuc3VyaW5nIHRoYXQgbWVz c2FnZXMgZG8gbm90IGxpdmUgZm9yZXZlciwNCiAgICAgICAgICAgICAgICAgICAgICAgIHNjb3Bl LWxpbWl0ZWQgZmxvb2RpbmcsIC4uLikNCg0KICAgICAgICAgICAgbyAgICAgICAgICBpZiB0aGUg YWNjdW11bGF0ZWQgcGF0aCBtZXRyaWMgaXMgc3RvcmVkIGluIGEgVExWIHZhbHVlIGZpZWxkLCB0 aGF0DQogICAgICAgICAgICAgICAgICAgICAgICB2YWx1ZSBmaWVsZCBjYW4gKHdpdGggc3VpdGFi bGUgZGlzY2xhaW1lciB0byBjYWxsIG91dCAid2Uga25vdyBpdCBpcw0KICAgICAgICAgICAgICAg ICAgICAgICAgUkVDT01NRU5ERUQgdG8gbm90IGRvIHRoaXMsIGJ1dCBoZXJlJ3Mgd2h5IHdlIGFy ZSBPSyBpbiBkb2luZw0KICAgICAgICAgICAgICAgICAgICAgICAgaXQgYW55d2F5cyIpIGJlIG1v ZGlmaWVkIHdoZW4gZm9yd2FyZGluZyB0aGUgbWVzc2FnZSwgYW5kDQoNCiAgICAgICAgICAgIG8g ICAgICAgICAgYXMgdGhhdCBwYXRoIG1ldHJpYyBmaWVsZCBpcyBpbiBhIG1lc3NhZ2Ugd2hvc2Ug c3RydWN0dXJlIGRvZXMgbm90DQogICAgICAgICAgICAgICAgICAgICAgICBjaGFuZ2UsIGl0IHdp bGwgYmUgImF0IHRoZSBzYW1lIHBsYWNlIGluIHRoZSBieXRlLXN0cmVhbSIgYXQgZWFjaCBob3As DQogICAgICAgICAgICAgICAgICAgICAgICB3aGljaA0KDQogICAgICAgICAgICBvICAgICAgICAg IGFsbG93cyB1c2VmdWwgdGhpbmdzIHN1Y2ggYXMgZGVyaXZpbmcgZnJvbSBSRkM3MTgyIGEgZm9y bSBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgIndoZW4gY2FsY3VsYXRpbmcgdGhlIElDViwg emVybyBvdXQgdGhhdCBmaWVsZCBpbiB0aGUgbWVzc2FnZSAnIHdoZW4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgdmFsaWRhdGluZyBhbiBJQ1YsIGFsc28gemVybyBvdXQgdGhhdCBmaWVsZCIg LS0gd2hpY2ggZ29lcyBvbmUgc3RlcA0KICAgICAgICAgICAgICAgICAgICAgICAgICBmdXJ0aGVy ICh3aGVuIGNvdXBsZWQgd2l0aCBhIHRpbWUgc3RhbXApIHRoYW4gc2ltcGxlIHRyYW5zaXRpdmUg dHJ1c3QsDQogICAgICAgICAgICAgICAgICAgICAgICAgIGJ1dCBhbHNvDQoNCiAgICAgICAgICAg IG8gICAgICAgICAgYWxsb3dzIGV2ZW4gbW9yZSBmYW5jeSBhbmQgdXNlZnVsIChhbGJlaXQgZXhw ZXJpbWVudGFsKSB0aGluZ3Mgc3VjaA0KICAgICAgICAgICAgICAgICAgICAgICAgYXMgYWdncmVn YXRlIHNpZ25hdHVyZXMgdG8gd29yayBjb3JyZWN0bHkuDQoNCkZ1cnRoZXJtb3JlLi4uLi4NCg0K DQogICAgICAgICAgICAgICAgICAgICAgICBUaGUgb25seSBwcmFjdGljYWwgc29sdXRpb24gd291 bGQgYmUgdG8gcmUtaW50cm9kdWNlIHRoZXNlIGZ1bmN0aW9ucyBieSB3YXkgb2YgaW5zZXJ0aW5n IGENCiAgICAgICAgICAgICAgICAgICAgICAgIE1lc3NhZ2VUTFYg4oCUIHdoaWNoIChpKSBpcyBu b3Qgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQsIGFuZCAoaWkpIHdoaWNoIHdvdWxkIGp1c3QN CiAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZlIHRvIHJlbmRlciBtZXNzYWdlcyBiaWdnZXIg dGhhbiBzdHJpY3RseSBuZWVkZWQuDQoNCkV4YWN0bHk7IHdl4oCZZCByZWFsbHkgbGlrZSB0byBh dm9pZCB0aGlzIGFzIHdlbGwuDQoNCg0KLi4uIEl0IGF2b2lkcyB0aGUgYWJvdmUsIGFuZC4uLi4N Cg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIFNjb3BlIGxpbWl0ZWQgZmxvb2RpbmcgIGRv ZXMgc2VlbSB0byBiZSBhIG5lY2Vzc2FyeSByZXF1aXJlbWVudCwgaWYgZm9yIG5vDQogICAgICAg ICAgICAgICAgICAgICAgICBvdGhlciByZWFzb24gdGhhbiB0byBwcmV2ZW50IGluZm9ybWF0aW9u IGZyb20g4oCcY2lyY3VsYXRpbmcgZm9yZXZlciBpbiB0aGUgbmV0d29ya+KAnS4NCg0KQU9EVnYy 4oCZcyBkdXBsaWNhdGVkIGRldGVjdGlvbiBob3BlZnVsbHkgc2hvdWxkIHRha2UgY2FyZSBvZiB0 aGF0LiBJaXJjLCBXZSBpbnRlcnByZXRlZCB5b3VyIGVhcmxpZXIgRS1NYWlscyB0byAoaW1wbGlj aXRseSkgbWVhbiB0aGF0IHlvdSB0aGluayB3ZSBzaG91bGQgcmVseSBvbiB0aGF0LCBzaW5jZSB5 b3Ugc2FpZCB3ZSBjYW7igJl0IHVzZSB0aGUgaG9wLWxpbWl0L2hvcC1jb3VudCBmaWVsZHMuDQoN Cg0KLi4uLmlmIGRvbmUgKHByb3BlciBmb3J3YXJkaW5nIHdpdGggcHJlc2VydmF0aW9uIG9mIHRo ZSBzdHJ1Y3R1cmUsIHJhdGhlciB0aGFuIHJlZ2VuZXJhdGlvbiB3aGljaCBvcGVucyB1cCB0aGUg InRoaXMgaXMgYSBuZXcgbWVzc2FnZSB3aXRoIHBvdGVudGlhbGx5IG5ldyBzdHJ1Y3R1cmUiIGNh biBvZiB3b3JtcykgYXMgSSBkZXNjcmliZSwgYWxzbyBhZGRyZXNzZXMgdGhlIGFib3ZlLg0KDQpX aXRoIHJlc3BlY3QgdG8gd2hhdCBJIHNhaWQgZWFybGllciB3aGVuIEkgc2FpZCAiY2FuJ3QgdXNl IGhvcC1saW1pdC9ob3AtY291bnQgZmllbGRzIi4uLi53aGVuIHlvdSByZWdlbmVyYXRlLCB5b3Ug YWJzb2x1dGVseSwgZGVmaW5pdGVseSwgY2FuJ3QuDQoNCg0KV2hlbiB5b3UgInJlZ2VuZXJhdGUi IGEgbWVzc2FnZSwgdGhhdCBtZWFucyAieW91IGNvbnN0cnVjdCBhIGJyYW5kIG5ldyBtZXNzYWdl IiB3aGljaCBtYXkgc2h1ZmZsZSBhZGRyZXNzZXMgaW5zaWRlIGFkZHJlc3MgYmxvY2tzLCBvciBi ZXR3ZWVuIGFkZHJlc3MgYmxvY2tzLCBzaHVmZmxlIFRMVnMgZGlmZmVyZW50bHkgdGhhbiB0aGV5 IHdlcmUgb3JpZ2luYWxseSwgZXZlbiB1c2UgVExWcyBvZiBkaWZmZXJlbnQgc3RydWN0dXJlIChl LmcuLCBzaW5nbGUtdmFsdWUgVExWcyBpbnN0ZWFkIG9mIG11bHRpLXZhbHVlIFRMVnMpLg0KDQoN ClRoaXMgbWVhbnMgdGhhdCBzb21lIGFzc3VtcHRpb25zIChzdWNoIGFzIHdoZW4gcHJvZHVjaW5n IGFuIElDViBmb3IgdGhlIG1lc3NhZ2UsIHdoaWNoIGRlcGVuZHMgb24gdGhlIGJ5dGUgb3JkZXIp IGRvbid0IGhvbGQuIFdlbGwsIHRoZXkgbWF5IG5vdCBob2xkLCBzbyB0aGF0IG1lYW5zIHdlIGNh bid0IGFzc3VtZSB0aGF0IHRoZXkgZG8uIFdoaWNoIG1lYW5zIHRoYXQgdGhlIG9yaWdpbmF0b3Ig b2YgYSBtZXNzYWdlIGNhbm5vdCBnZW5lcmF0ZSBhbiBJQ1YgdGhhdCBjYW4gYmUgY29ycmVjdGx5 IGludGVycHJldGVkICh3aGljaCBpcyB3aGF0IG15IG5leHQgc2VjdGlvbiBpbiBteSBvcmlnaW5h bCBtYWlsIHdhcyBhYm91dCkuDQoNCg0KV2hpY2ggbWVhbnMsIGluIGNvbmNsdXNpb24sICB0aGF0 IHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgbWVzc2FnZSBwcm9mb3VuZGx5IGNoYW5nZSAtLSBhbmQg dGhlcmVmb3JlIHRoZXNlIGhvcC1jb3VudC9ob3AtbGltaXQgdmFsdWVzIGRvIG5vdCBldmVuIGFw cGx5IHRvICJ0aGUgaW5mb3JtYXRpb24iLg0KDQoNCkhvd2V2ZXIgaWYgcHJvcGVyIGZvcndhcmRp bmcgd2l0aCBwcmVzZXJ2YXRpb24gb2YgdGhlIHN0cnVjdHVyZSwgcmF0aGVyIHRoYW4gcmVnZW5l cmF0aW9uIHdoaWNoIG9wZW5zIHVwIHRoZSAidGhpcyBpcyBhIG5ldyBtZXNzYWdlIHdpdGggcG90 ZW50aWFsbHkgbmV3IHN0cnVjdHVyZSIgY2FuIG9mIHdvcm1zLCBhcyBJICgmIFVscmljaCAmIG90 aGVycykgaGF2ZSBzdWdnZXN0ZWQsIGlzIHRha2VuIHRvIGhlYXJ0LCBpdCBhbHNvIGFkZHJlc3Nl cyB0aGUgaXNzdWUgYmVsb3cgcmVnYXJkaW5nIGVuZC10by1lbmQgYXV0aGVudGljYXRpb24gKHdo aWNoLCB3aGlsZSBzdGlsbCBoYXJkLCBpcyBwb3NzaWJsZSkuDQoNCg0KQSBjb3VwbGUgb2YgbW9y ZSBjb21tZW50cyBiZWxvdw0KDQoNCg0KICAgICAgICAgICAgbyAgICAgICAgICBJdCBtYWtlcyBl bmQtdG8tZW5kIGF1dGhlbnRpY2F0aW9uIHVubmVjZXNzYXJpbHkgaGFyZC4NCiAgICAgICAgICAg ICAgICAgICAgICAgIEkgdGhpbmsgQ2hyaXMgY2FsbGVkIHRoaXMgb3V0IGFscmVhZHksIGJ1dCBp dCBiZWFycyByZXBlYXRpbmc6IFMgZ2VuZXJhdGVzIGEgbWVzc2FnZQ0KICAgICAgICAgICAgICAg ICAgICAgICAgKHNheSwgYSBSUkVRKSwgYW5kIGluY2x1ZGVzIGFuIElDViBjYWxjdWxhdGVkIG92 ZXIgdGhlIGNvbnRlbnQgb2YgdGhlIG1lc3NhZ2UuDQogICAgICAgICAgICAgICAgICAgICAgICBG b3IgYW55IHJlY2lwaWVudCB0byBiZSBhYmxlIHRvIHZhbGlkYXRlIHRoZSBJQ1YsIHRoZSBtZXNz YWdlIGhhcyB0byBiZSBleGFjdGx5DQogICAgICAgICAgICAgICAgICAgICAgICB0aGUgc2FtZSDi gJQgbm90IGp1c3QgaW4gY29udGVudCwgYnV0IGluIHN0cnVjdHVyZSDigJQgYXMgd2hhdCB3YXMg Z2VuZXJhdGVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICDigJxSZWdlbmVyYXRpbmfigJ0g cmF0aGVyIHRoYW4g4oCcZm9yd2FyZGluZ+KAnSBtZXNzYWdlcyBtZWFucywgdGhhdCB0aGUgaW50 ZXJtZWRpYXRlDQogICAgICAgICAgICAgICAgICAgICAgICByb3V0ZXIg4oCccmVnZW5lcmF0aW5n 4oCdIHRoZSBSUkVRIG1heSBjaG9zZSBhIGRpZmZlcmVudCBzdHJ1Y3R1cmUgKGUuZy4sIGluY2x1 ZGUgVExWcw0KICAgICAgICAgICAgICAgICAgICAgICAgaW4gYSBkaWZmZXJlbnQgb3JkZXIpLg0K DQogICAgICAgICAgICAgICAgICAgICAgICBUaGUgcHJvcG9zYWwgZnJvbSBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMA0KICAgICAg ICAgICAgICAgICAgICAgICAgaXMgdG8gYWRkIGNvbnN0cmFpbnRzIG9uIChpKSB0aGUgc2V0IG9m IGVsZW1lbnRzIHRvIGluY2x1ZGUgaW4gYSBzaWduYXR1cmUgYW5kIChpaSkgdGhlDQogICAgICAg ICAgICAgICAgICAgICAgICBvcmRlciBvZiB0aGVzZSBlbGVtZW50cy4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgT25lIHByb2JsZW0gd2l0aCB0aGF0IGFwcHJvYWNoIGlzIChpKTogaWYgYW4g ZXh0ZW5zaW9uIGFkZHMgYSBtZXNzYWdlIFRMViwgb3IgYW4NCiAgICAgICAgICAgICAgICAgICAg ICAgIEFkZHJlc3MgVExWLCB0byBhIG1lc3NhZ2UsIHRoZW4gdGhhdCB3aWxsIG5vdCBiZSDigJxj b3ZlcmVk4oCdIGJ5IHRoZSBwcm9wb3NlZCBlMmVzZWMgVExWLg0KICAgICAgICAgICAgICAgICAg ICAgICAgUmF0aGVyIGZvciAqZWFjaCogZXh0ZW5zaW9uIGRldmVsb3BlZCwgYW4g4oCcdXBkYXRl cyBlMmVzZWPigJ0gY2xhdXNlIG5lZWRzIHRvIGJlIGRvbmUuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgIEnigJlkIHNheSB0aGF0IHRoaXMgYXBwcm9hY2ggd291bGQgYmUgcHJvbmUgdG8gZXJy b3JzIOKAlCBhbmQgYWRkIGVudHJvcHkgdG8gdGhlIHByb2Nlc3MNCiAgICAgICAgICAgICAgICAg ICAgICAgIG9mIGRlc2lnbmluZyBwcm90b2NvbCBleHRlbnNpb25zLiBUaGUgYWx0ZXJuYXRpdmUs IGEgbWVzc2FnZSBiZWluZyBnZW5lcmF0ZWQgYnkgdGhlDQogICAgICAgICAgICAgICAgICAgICAg ICBzb3VyY2UgYW5kICpmb3J3YXJkZWQqIChhcyB3ZSBkbyBpbiBPTFNSdjIsIGZvciBleGFtcGxl KSB3b3VsZCBhbGxvdyBJQ1YgVExWcw0KICAgICAgICAgICAgICAgICAgICAgICAgKGV2ZW4sIGFs bG93IHJldXNlIG9mIHRob3NlIHNwZWNpZmllZCBmb3IgT0xTUnYyKSBmb3IgY292ZXJpbmcgYSBt ZXNzYWdlIGFuZA0KICAgICAgICAgICAgICAgICAgICAgICAgZXh0ZW5zaW9ucy4NCg0KICAgICAg ICAgICAgICAgICAgICAgICAg4oCcQnV0IHdoYXQgYWJvdXQgdGhlIG1ldHJpY3MgdmFsdWUgd2hp Y2ggd2lsbCBjaGFuZ2Ugb24gZWFjaCBob3DigJ0sIHlvdSBtYXkgc2F5Pw0KICAgICAgICAgICAg ICAgICAgICAgICAgRm9ydHVuYXRlbHksIHRoYXQgaXMgcmVsYXRpdmVseSBlYXN5IHRvIGhhbmRs ZTogc2ltcGx5IHplcm8gb3V0IHRoZSB2YWx1ZSBvZiB0aGF0IFRMViB3aGVuDQogICAgICAgICAg ICAgICAgICAgICAgICBnZW5lcmF0aW5nIG9yIHZlcmlmeWluZyB0aGUgSUNWIE1lc3NhZ2VUTFYu IEFuZCB1c2UgUGFja2V0LVRMVnMgZm9yIGhvcC1ieS1ob3ANCiAgICAgICAgICAgICAgICAgICAg ICAgIGF1dGhlbnRpY2F0aW9uLCBpZiBuZWVkZWQgKGJ1dCwgc2VlIGJlbG93KS4NCg0KICAgICAg ICAgICAgbyAgICAgICAgICBJdCBwcmV2ZW50cyB0aGUgdXNlIG9mIG1vcmUgY2xldmVyL2FkdmFu Y2VkIHNpZ25hdHVyZSBzY2hlbWVzL0lDVnMNCiAgICAgICAgICAgICAgICAgICAgICAgIEFnZ3Jl Z2F0ZSBzaWduYXR1cmUgYWxnb3JpdGhtcyAoIGh0dHBzOi8vY3J5cHRvLnN0YW5mb3JkLmVkdS9+ ZGFiby9wYXBlcnMvYWdnc3VydmV5LnBkZikNCiAgICAgICAgICAgICAgICAgICAgICAgIGV4aXN0 LCBhbmQgYW4gaW50ZXJlc3RpbmcgdXNlLWNhc2UgY2FuIGJlIGZvdW5kIGluIGFsc28gcmVhY3Rp dmUgcHJvdG9jb2xzLCBhbGxvd2luZyB2ZXJpZnlpbmcNCiAgICAgICAgICAgICAgICAgICAgICAg IG5vdCDigJxqdXN04oCdIHRoZSBlbmQgcG9pbnRzLCBidXQgYWxzbyB0aGUgaW50ZXJtZWRpYXJp ZXMgKGFnYWluLCB3aXRoIHRoZSBhcHByb3ByaWF0ZSDigJx6ZXJvIG91dOKAnQ0KICAgICAgICAg ICAgICAgICAgICAgICAgZGlzY3Vzc2VkIGFib3ZlLCBvciBzb21ldGhpbmcgc21hcnRlcikuDQog ICAgICAgICAgICAgICAgICAgICAgICBSZWdlbmVyYXRpb24gb2YgbWVzc2FnZXMsIHJhdGhlciB0 aGFuIGZvcndhcmRpbmcsIHJlbmRlcnMgdGhhdCBpbXBvc3NpYmxlIChvciwgaWYgdXNlZCwNCiAg ICAgICAgICAgICAgICAgICAgICAgIHVwZGF0aW5nIHRvICBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMCkNCg0KVGhlcmUgYXJlIG90 aGVyIHJlYXNvbnMsIGJ1dCB0aGUgYWJvdmUgYXJlIHRob3NlIHRoYXQganVtcCBhdCBtZSBhcyBp bW1lZGlhdGUgc2hvdy1zdG9wcGVycy4NCg0KSSBkbyBob25lc3RseSBub3Qgc2VlIHdoYXQgcG9z c2libGUgYmVuZWZpdCB0aGVyZSBpcyBmcm9tIOKAnHJlZ2VuZXJhdGlvbuKAnSDigJQgYnV0IEkg c2VlIHZlcnkgY2xlYXIgaW5jb252ZW5pZW5jZXMsIGFuZCBzZWN1cml0eSBpcyBub3QgdGhlIGxl YXN0IG9mIHRoZXNlLiBJbnNpc3Rpbmcgb24g4oCccmVnZW5lcmF0aW9u4oCdIHJlcXVpcmVzIGRl dmVsb3BtZW50IG9mIOKAnG5vbi1nZW5lcmFsIHdvcmthcm91bmRz4oCdIGFzIHBvaW50ZWQgb3V0 IGFib3ZlLg0KDQpUaGUgcG9zc2libGUgYmVuZWZpdCBpcyB0aGF0IHdlIG5lZWQgdG8gYWNjdW11 bGF0ZSAmIHRyYW5zcG9ydCBtZXRyaWMgdmFsdWVzIHNvbWVob3csIGFuZCB3ZSBjYW7igJl0IGRv IHRoYXQgd2l0aG91dCByZWdlbmVyYXRpbmcgYXQgbGVhc3QgcGFydHMgb2YgdGhlIG1lc3NhZ2Uu DQpJZiB3ZeKAmXJlIG1pc3NpbmcgYSBzb2x1dGlvbiBoZXJlLCBwbGVhc2Ugc2hhcmUgaXQgd2l0 aCB1cy4NCg0KDQpEb25lIGluIHRoZSBhYm92ZS4NCg0KDQoNClNlY3VyaXR5IENvbnNpZGVyYXRp b25zDQoNCkp1c3QgZm9yIGNvbnRleHTigJlzIHNha2UsIGRpZCB5b3UgcmV2aWV3IHRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBpbiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyBvciB0aGUg b25lcyBwcm9wb3NlZCBpbiB0aGUgdGhyZWFkIOKAnkFPRFZ2MjogU2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgdXBkYXRl4oCcPw0KDQpJIGRpZC4gSXQgc3RpbGwgaXMgYSBmYXIgY3J5IGZyb20gcGFz c2luZyB0aGUgYmFyLiBJJ3ZlIHBvc3RlZCBvbiB3aHkgaW4gdGhlIHBhc3QsIGFuZCBzb21lIG1v cmUgaW4gdGhpcyBtYWlsICh3aGljaCBhbHNvIGNvbnRhaW5zIHNvbWUgc3VnZ2VzdGlvbnMpLg0K DQpJIHdvdWxkIHN1Z2dlc3QgdGhhdCBzZXR0bGluZyB0aGUgcmVhcmNoaXRlY3R1cmluZyB0byBk byBmb3J3YXJkaW5nLCBhcyBJIGRlc2NyaWJlIGluIHRoZSBhYm92ZSwgc2hvdWxkIGJlIGRvbmUs IHdoaWNoIHdvdWxkIGVhc2UgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGlzc3VlIGNvbnNp ZGVyYWJseSAoYW5kIHdoaWNoIHdvdWxkIGJlIG5lY2Vzc2FyeSBldmVuIGlmIGlnbm9yaW5nIHRo ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywgSU1PLCBmb3IgdGhpcyBkb2MgdG8gZ28gYW55d2hl cmUpLg0KDQoNCldpdGggYSBuZXcgdmVyc2lvbiBjb3ZlcmluZyB0aGF0LCB0aGUgYXV0aG9ycyAo SSB3YW50ZWQgdG8gd3JpdGUgInlvdSIsIGJ1dCBkZWNpZGVkIHRvIGJlIGluY2x1c2l2ZSkgY291 bGQgeW91IGdvIGxvb2sgYXQgdGhlIGRpZmZlcmVudCBzZWN1cml0eSBlbWFpbHMgYW5kIHBlcmhh cHMgc3RhcnQgYSBzZXBhcmF0ZSB0aHJlYWQgb24gdGhhdCwgdG93YXJkcyBhIHJlc29sdXRpb24/ DQoNCg0KQmVzdCwNCg0KVGhvbWFzDQoNCg0KDQoNCg0KVGhpcyBpcyBhbiBhbHdheXMgdGhvcm55 IHN1YmplY3QuIFdoZW4gT0xTUnYyIHdhcyBnb2luZyB0aHJvdWdoIHRoZSBwcm9jZXNzIHdlIGdv dCBhIHRob3JvdWdoIGVkdWNhdGlvbiBpbiBob3cgbGl0dGxlIHdlIGtuZXcgYWJvdXQgc2VjdXJp dHkgZnJvbSB0aGUgU0VDLUFEcywgYW5kIGhhZCB0byBzcGVuZCBhYm91dCBhIHllYXIgb3Igc28g ZGV2ZWxvcGluZyBSRkM3MTgzLiBUaGUgYm90dG9tIGxpbmUgaXMsIHRoYXQgdGhpcyBwcm90b2Nv bCBuZWVkcyBpdHMg4oCcUkZDNzE4MyAgZXF1aXZhbGVudOKAnSwgZWl0aGVyIGFzIHBhcnQgb2Yg dGhlIG1haW4gZG9jdW1lbnQsIG9yIGFzIGFuIGluZGVwZW5kZW50IGRvY3VtZW50LiBjdXJyZW50 bHksIHRoYXQgaXMgbm90IHRoZSBjYXNlLg0KDQpBIG1pbmltYSwgbG9va2luZyBhdCBCQ1A3MiBh bmQgQkNQMTA3IOKAlCB0YWtpbmcgaW5zcGlyYXRpb24gZnJvbSBSRkM3MTgzIG1pZ2h0IGJlIGF3 IGdvb2QgaWRlYSwgYXMgdGhhdCB3YXMgdGhlIG1vc3QgcmVjZW50IHRoYXQgd2VudCB0aHJvdWdo IHRoZSBTRUMgQUQuIFJlZ2FyZGxlc3Mgb2YgaG93LCBob3dldmVyLCBhIOKAnG1hbmRhdG9yeSB0 byBpbXBsZW1lbnTigJ0gc2VjdXJpdHkgbWVjaGFuaXNtIG1vc3QgYmUgc3BlY2lmaWVkIChJIHRo aW5rIHRoZSByaWdodCB0ZXJtIHdhcyDigJxNVVNUIGltcGxlbWVudCwgU0hPVUxEIHVzZeKAnSks IGluIHN1ZmZpY2llbnQgZGV0YWlsIHRvIGVuc3VyZSBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0 aW9ucy4NCg0KQXMgYW4gZXhhbXBsZSwgYm90aCBbUkZDNjEzMF0gYW5kIFtSRkM3MTgxXSBzZXQg b3V0IHRoYXQgdGhhdDoNCg0KICAgICAgT24gcmVjZWl2aW5nIGEgLi4uIG1lc3NhZ2UsIGEgcm91 dGVyIE1VU1QgZmlyc3QgY2hlY2sgaWYgdGhlDQogICAgICBtZXNzYWdlIGlzIGludmFsaWQgZm9y IHByb2Nlc3NpbmcgYnkgdGhpcyByb3V0ZXINCg0KYW5kIHRoZW4gcHJvY2VlZCB0byBnaXZlIGEg bnVtYmVyIG9mIGNvbmRpdGlvbnMgdGhhdCwgZWFjaCwgd2lsbCBsZWFkIHRvIGEgcmVqZWN0aW9u IG9mIHRoZSBtZXNzYWdlIGFzICJiYWRseSBmb3JtZWQgYW5kIHRoZXJlZm9yZSBpbnZhbGlkIGZv ciBwcm9jZXNzaW5n4oCdIOKAlCBhIGxpc3Qgd2hpY2ggUkZDNzE4MyB0aGVuIGFtZW5kZWQuIFRo YXQgZ2F2ZSBhIOKAnGhvb2vigJ0gZm9yIFJGQzcxODMgZm9yIGluc2VydGluZyDigJxyZWplY3Rp b27igJ0uIElkZW0gZm9yIG1lc3NhZ2UgZ2VuZXJhdGlvbi4NCg0KSWYgSSB3YXMgdG8gZG8gUkZD NzE4MS9SRkM2MTMwIHRvZGF5LCBJIHdvdWxkIGluY2x1ZGUgdGhhdCBkaXJlY3RseSBpbnRvIHRo ZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucy4gSXQgdHVybmVkIG91dCB0byBiZSBtb3JlIG92ZXJo ZWFkIChhbmQgc2xvdyBkb3duIHB1YmxpY2F0aW9uIGFueXdheXMpIHRvIGRvIGl0IGFzIHNlcGFy YXRlIGRvY3VtZW50cy4NCg0KU2Vjb25kbHksIHdlIG5lZWQgdG8gYmUgYSBsb3QgbW9yZSByaWdp ZCBpbiB0ZXJtcyBvZiB3aGF0IElDVnMsIFRpbWVzdGFtcHMsIGV0Yy4gYXJlIGFkZGVkL3JlbW92 ZWQsIGFuZCB3aGF0IHRoYXQgYnJpbmdzLg0KDQpGb3IgZXhhbXBsZSAod2l0aCB0aGUgYXNzdW1w dGlvbiB0aGF0IG1lc3NhZ2VzIGFyZSAqZm9yd2FyZGVkKiBhbmQgKm5vdCogcmVnZW5lcmF0ZWQp LCB0aGlzIGNvdWxkIGJlIG9uZSBvcHRpb246DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIG8g ICAgICAgICAgV2hlbiBhIFJSRVEsIFJSRVAgbWVzc2FnZSBpcyBnZW5lcmF0ZWQsIGFkZCBhbiBJ Q1YgTWVzc2FnZSBUTFYsIHdoaWNoIGlzIGNhbGN1bGF0ZWQgPHRoaXMgd2F5Pg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIOKApih0YWtlIGluc3BpcmF0aW9uIGZyb20gUkZD NzE4MyBoZXJlKQ0KDQogICAgICAgICAgICAgICAgICAgICAgICBvICAgICAgICAgIFdoZW4gYSBS UkVRLCBSUkVQIG1lc3NhZ2UgaXMgdHJhbnNtaXR0ZWQgIChieSB0aGUgc291cmNlLCBvciBmb3J3 YXJkZWQgYnkgYW4gaW50ZXJtZWRpYXJ5KQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaW4gYW4gUkZDNTQ0NCBwYWNrZXQsIGFuIElDViBQYWNrZXQgVExWIGlzIGFkZGVkIHRv IHRoZSBwYWNrZXQsIHdoaWNoIGlzIGNhbGN1bGF0ZWQgPHRoaXMgd2F5PiDigKYNCg0KICAgICAg ICAgICAgICAgICAgICAgICAgbyAgICAgICAgICBXaGVuIGFuIFJGQzU0NDQgcGFja2V0IGlzIHJl Y2VpdmVkLCB2YWxpZGF0ZSB0aGUgSUNWIFBhY2tldCBUTFYgPHRoaXMgd2F5PiBhbmQgaWYgdGhl IElDViBkb2VzbuKAmXQgdmFsaWRhdGUsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBkaXNjYXJkIHRoZSBjb250YWluZWQgbWVzc2FnZXMuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgIG8gICAgICAgICAgV2hlbiByZWNlaXZpbmcgYSBSUkVRL1JSRVAgKGVpdGhlciBhcyBk ZXN0aW5hdGlvbiwgb3IgYXMgYW4gaW50ZXJtZWRpYXJ5KSwgdmFsaWRhdGUgdGhlIElDViBNZXNz YWdlIFRMVg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHRoaXMgd2F5PiBh bmQgaWYgdGhlIElDViBkb2VzbuKAmXQgdmFsaWRhdGUsIGRpc2NhcmQgdGhlIG1lc3NhZ2UsIGRv IG5vdCBwcm9jZXNzLCBkbyBub3QgZm9yd2FyZC4NCg0KVGhpcyBpcyBhIGRpZmZlcmVudCAoYW5k IG1vcmUgZmxleGlibGU/KSBtb2RlbCB0aGFuIOKAnGp1c3TigJ0gdHJhbnNpdGl2ZSB0cnVzdCBh bmQg4oCcanVzdOKAnSBlbmQtdG8tZW5kIHRydXN0IGRpc2N1c3NlZCBwcmV2aW91c2x5LCBhbmQg aXMgZW5hYmxlZCBieSB0aGUg4oCcZm9yd2FyZGluZ+KAnSBiaXQgZGVzY3JpYmVkIHByZXZpb3Vz bHkuDQoNCk1ldHJpY3MNCkkgaGF2ZSBhc2tlZCB0aGlzIG51bWVyb3VzIHRpbWVzLCBidXQgaGF2 ZSBub3QgZ290dGVuIGFueSBhbnN3ZXIgc28gSSBhbSBlc2NhbGF0aW5nIHRoaXMgYWdhaW4uIFdo eSBpcyB0aGlzIGRvY3VtZW50IGhhdmluZyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDNjU1 MT8NCg0KDQogICBbUkZDNjU1MV0gIFZhc3NldXIsIEpQLiwgRWQuLCBLaW0sIE0uLCBFZC4sIFBp c3RlciwgSy4sIERlamVhbiwgTi4sDQoNCiAgICAgICAgICAgICAgYW5kIEQuIEJhcnRoZWwsICJS b3V0aW5nIE1ldHJpY3MgVXNlZCBmb3IgUGF0aCBDYWxjdWxhdGlvbg0KDQogICAgICAgICAgICAg IGluIExvdy1Qb3dlciBhbmQgTG9zc3kgTmV0d29ya3MiLCBSRkMgNjU1MTxodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNjU1MT4sIERPSSAxMC4xNzQ4Ny8NCg0KICAgICAgICAgICAgICBS RkM2NTUxPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTUxPiwgTWFyY2ggMjAxMiwN Cg0KICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzY1NTE+ Lg0KDQoNClVubGVzcyBJIGFtIG1pc3Rha2VuLCB0aGlzIGlzIG5vdCB0aGUgUk9MTCBXRy4gQW5k IHRoZSBhYnN0cmFjdCB0byBSRkM2NTUxIGV4cGxpY2l0bHkgcmVhZHM6DQoNCg0KICAgTG93LVBv d2VyIGFuZCBMb3NzeSBOZXR3b3JrcyAoTExOcykgaGF2ZSB1bmlxdWUgY2hhcmFjdGVyaXN0aWNz DQoNCiAgIGNvbXBhcmVkIHdpdGggdHJhZGl0aW9uYWwgd2lyZWQgYW5kIGFkIGhvYyBuZXR3b3Jr cyB0aGF0IHJlcXVpcmUgdGhlDQoNCiAgIHNwZWNpZmljYXRpb24gb2YgbmV3IHJvdXRpbmcgbWV0 cmljcyBhbmQgY29uc3RyYWludHMuDQpXaGljaCBleHBsaWNpdGx5IGlzIGRpc2NsYWltaW5nIHRo YXQgdGhlc2UgbWV0cmljcyBhcmUgbm90IGFwcGxpY2FibGUgaW4gYWQgaG9jIG5ldHdvcmtzIOKA lCBhbmQsIEkgYW0gd29uZGVyaW5nLCB3aGF0IGhhcyBjaGFuZ2VkIHNpbmNlIHRoZSBwdWJsaWNh dGlvbiBvZiBSRkM2NTUxIHRvIHN1ZGRlbmx5IG1ha2UgdGhlc2UgYXBwbGljYWJsZT8NCg0KIEkg YW0gYWxzbyB3b25kZXJpbmcgaWYgbG9va2luZyBhdCAoYW5kLCBwZXJoYXBzLCB1c2luZz8pIHRo ZSBzYW1lIG1ldHJpYyB0eXBlIFRMViB0eXBlIGFzIGluIE9MU1J2MiBpcyBub3QgYSBwb3NzaWJp bGl0eT8NCg0KRWl0aGVyIHdheSwgcmVmZXJlbmNpbmcgUkZDNjU1MSBoZXJlIGlzIHdyb25nLg0K DQpSRkM2NjIxIChTTUYpIHVzYWdlDQpBcyBsYXRlIGFzIGVhcmxpZXIgdGhpcyBtb250aCwgUkZD NjYyMSByZWFyZWQgaXRzIGhlYWQgYWdhaW4gb24gdGhlIG1haWxpbmcgbGlzdC4gSSB1bmRlcnN0 YW5kIHRoYXQgdGhlIGF1dGhvcnMgYXJlIHNldCBvbiB1c2luZyBmbG9vZGluZyByZWR1Y3Rpb24g YXMgcGFydCBvZiBSUkVRIGRpc3RyaWJ1dGlvbi4gSWYgdGhhdCBpcyB0aGUgY2FzZSwgdGhlbiB0 aGlzIHByb3RvY29sIE1VU1Qgc3BlY2lmeSB0aGF0IGZsb29kaW5nIHJlZHVjdGlvbi4NCg0KU2F5 aW5nIOKAnFVzZSBSRkM2NjIx4oCdIHdvbuKAmXQgd29yaywgZm9yIHJlYXNvbnMgQ2hyaXMgcG9p bnQgb3V0IGluIGFuIGVtYWlsIGVhcmxpZXIgdG8gdGhlIGxpc3Q6DQpUaGUgbmV0d29yayBkb2Vz IG5vdCBhbmQgZnVuZGFtZW50YWxseSBjYW5ub3Qgb2ZmZXIgbXVsdGljYXN0IHN1cHByZXNzaW9u IHRvIEFPRFZ2Mi4gVGhpcyBpc24ndCBhIGhhcmQgY29uY2VwdCwgYnV0IHNlZW1zIHRvIGtlZXAg aGF2aW5nIHRvIGJlIHNhaWQuIEFPRFZ2MiBtZXNzYWdlcyBhcmUgY2FycmllZCBpbiA1NDQ0IHBh Y2tldHMsIGFuZCB0aG9zZSBvbmx5IHRyYXZlbCBvbmUgaG9wLiBUaGF0IGRvZXNuJ3QgYWxsb3cg Zm9yIHN1cHByZXNzaW9uLiBGdXJ0aGVybW9yZSBBT0RWdjIgaXMgY3JlYXRpbmcgbmV3IG1lc3Nh Z2VzIGVhY2ggaG9wLiBUaGF0IG5lZWRzIEFPRFZ2MiBzcGVjaWZpYyBoYW5kbGluZy4NCg0KQW5k IHF1b3RpbmcgYW4gZW1haWwgZnJvbSBteXNlbGY6DQpJZiBwcm90b2NvbCBYIHJlbGllcyBvbiB1 c2luZyBhIGZsb29kaW5nIG9wZXJhdGlvbiwgdGhlbiBpdCBjZXJ0YWlubHkgaXMgcHJvdG9jb2wg WCdzIHJlc3BvbnNpYmlsaXR5IHRvICBzcGVjaWZ5IHRoZSBmbG9vZGluZyBvcGVyYXRpb24gKG9y LCBhdCBsZWFzdCwgdGhlIHJlcXVpcmVtZW50cyB0byB0aGUgZmxvb2Rpbmcgb3BlcmF0aW9uICkg Zm9yIGNvcnJlY3QgZnVuY3Rpb25pbmcgb2YgcHJvdG9jb2wgWC4NCg0KSeKAmXZlIHByZXZpb3Vz bHkgcG9pbnRlZCBvdXQgdGhhdCBSRkM2NjIxIHJlcXVpcmVzIHNvbWUgZGVncmVlIG9mIGNvbmZp Z3VyYXRpb24gKGNhbuKAmXQganVzdCwgZm9yIGV4YW1wbGUsIHBpY2sgdHdvIGRpZmZlcmVudCBy ZWxheSBzZXQgc2VsZWN0aW9uIGFsZ29yaXRobXMsIGFzIHRoYXQgbWF5IHByb2R1Y2UgYSBkaXNj b25uZWN0ZWQgZmxvb2RpbmcgZG9tYWluKS4NCg0KSW4gb3RoZXIgd29yZHMsIHdoYXQgdGhlIGF1 dGhvcnMgcHJvcG9zZSBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVya2lu cy1tYW5ldC11c2luZy1yZmM2NjIxLTAwIGlzIGluc3VmZmljaWVudC4NCg0KTXVsdGlwbGUgaW50 ZXJmYWNlcyBjb25maWd1cmVkIHdpdGggdGhlIHNhbWUgYWRkcmVzcyhlcykgLSAmIFJGQzY2MjEN CkkgdGhpbmsgdGhhdCBpdCBoYXMgYmVlbiBlc3RhYmxpc2hlZCB0aGF0IHRoZSBhYmlsaXR5IHRv IHVzZSB0aGUgc2FtZSBhZGRyZXNzIG9uIG11bHRpcGxlIGludGVyZmFjZXMgaXMgYSByZXF1aXJl bWVudC4gSXTigJlzIG5vdCBjbGVhciB0byBtZSB0aGF0IGEgc2luZ2xlIHdheSBvZiBkb2luZyBz byBoYXMgYmVlbiBwcm9wb3NlZCwgbm9yIHRoYXQgdGhlIOKAnG9wZXJhdGluZyBjb25kaXRpb25z 4oCdIGFyZSBjYWxsZWQgb3V0IChmb3IgZXhhbXBsZSwgd2lsbCBpdCB3b3JrICBpZiByb3V0ZXIg QSBhbmQgcm91dGVyIEIgYm90aCBoYXZlIHR3byBpbnRlcmZhY2VzLCBhbmQgdGhhdCBhbGwgNCBp bnRlcmZhY2VzIHVzZSB0aGUgc2FtZSBJUCBhZGRyZXNzPykNCg0KVGhpcyBpcyBub3QgZW50aXJl bHkgdW5yZWxhdGVkIHRvIGZsb29kaW5nIHJlZHVjdGlvbiBhbmQgUkZDNjYyMS4gT25lIG9mIHRo ZSBjb21wbGV4aXRpZXMgaXMgdG8gZ2V0IHRoYXQganVzdCByaWdodDogT0xTUnYyIC0gZm9yIGV4 YW1wbGUgLSBjYWxjdWxhdGVzIEZsb29kaW5nLU1QUnMgcGVyIGludGVyZmFjZSwgYW5kIFJGQzYx MzAgaXMgY2FyZWZ1bCBpbiBob3cgaXQgZGV0ZWN0cyBiaWRpcmVjdGlvbmFsaXR5IG9mIGxpbmtz Lg0KDQpJIGhhdmUgbm90IHdvcmtlZCBvdXQgYWxsIHRoZSBkZXRhaWxzIG9mIGhvdyB0aGlzIGlt cGFjdHMgdGhpcyBwcm90b2NvbCDigJQgYnV0LCBpdCByZXF1aXJlcyBhdHRlbnRpb24uIEVzcGVj aWFsbHkgd2hlbiB3YW50aW5nIHRvIGJlIGFibGUgdG8gc2F5IOKAnOKApnVzZSBSRkM2NjIx4oCd LCB0aGVuIHRoZSBpbnRlcmZhY2UgY29uZmlndXJhdGlvbiBjb25zdHJhaW50cyB3aGVuIGZhY2Vk IHdpdGggbXVsdGlwbGUgaW50ZXJmYWNlcyBtdXN0IGJlIHdvcmtlZCBvdXQuDQoNClByZWZpeGVz ICYgR2F0ZXdheXMNCkEgcXVlc3Rpb24gdG8gbXkgbWluZCwgYW5kIEkgYW0gbm90IHN1cmUgSSBr bm93IGhvdyB0byBhbnN3ZXIgdGhhdCBmcm9tIHJlYWRpbmcgdGhlIGRyYWZ0IHNpbmNlIGl0IGlz IG5vdCBkaXNjdXNzZWQgaW4gc2VjdGlvbiA5IChhdCBsZWFzdCksIGlzOiDigJxXaGF0IGhhcHBl bnMgaWYgSSBzZW5kIGEgUlJFUSB0byBhIHByZWZpeOKAnSAoaS5lLiwgYSAvPDEyOCBpbiBJUHY2 KT8NCg0KICAgICAgICAgICAgbyAgICAgICAgICBJZiB0aGUgd2hvbGUgcHJlZml4IGlzIHBhcnQg b2YgdGhlIGF0dGFjaGVkIG5ldHdvcmsgc2V0IG9mIGEgc2luZ2xlIHJvdXRlciwNCiAgICAgICAg ICAgICAgICAgICAgICAgIHRoZW4gSSBleHBlY3QgdG8gZ2V0IGEgc2luZ2xlIFJSRVAgYmFjaywg aXMgdGhhdCB0aGUgY2FzZT8NCg0KICAgICAgICAgICAgbyAgICAgICAgICBJZiAiaGFsZiB0aGUg cHJlZml4IiAgaXMgcGFydCBvZiB0aGUgYXR0YWNoZWQgbmV0d29yayBzZXQgb2YgYSBzaW5nbGUg cm91dGVyLA0KICAgICAgICAgICAgICAgICAgICAgICAgYW5kIHRoZSBvdGhlciBoYWxmIGlzIHBh cnQgb2YgdGhlIGF0dGFjaGVkIG5ldHdvcmsgc2V0IG9mIGFub3RoZXIgIHNpbmdsZSByb3V0ZXIs DQogICAgICAgICAgICAgICAgICAgICAgICB0aGVuIEkgZXhwZWN0IHR3byBSUkVQcywgaXMgdGhh dCB0aGUgY2FzZT8NCg0KICAgICAgICAgICAgbyAgICAgICAgICBNb3JlIGdlbmVyYWxseSwgd2ls bCBJIGdldCBhIHRyZWUgYnVpbGQgdGhyb3VnaCB0aGUgbmV0d29yayBoZXJlPw0KDQpBT0RWdjIg Y3VycmVudGx5IGRvZXNu4oCZdCBzdXBwb3J0IFJSRVFzIGZvciBwcmVmaXhlcy4gSeKAmXZlIGFs cmVhZHkgYWRkZWQg4oCeSWYgUnRlTXNnIGlzIGEgUlJFUSwgUnRlTXNnLlRhcmdQcmVmaXhMZW4g U0hPVUxEIGVxdWFsIGFkZHJlc3MgbGVuZ3RoLuKAnCB0byBSdGVNc2cuVGFyZ1ByZWZpeExlbiBp biBzZWN0aW9uIDQuNjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5l dC1hb2R2djItMTMjc2VjdGlvbi00LjY+LiBNdWx0aWNhc3QgUm91dGUgTWVzc2FnZSBUYWJsZSBp biByZXNwb25zZSB0byBKdXN0aW7igJlzIGNvbW1lbnRzLCBidXQgSeKAmWxsIGdvIHRocm91Z2gg dGhlIGRyYWZ0IGFnYWluIGFuZCBzZWUgd2hlcmUgd2UgbmVlZCB0byBzdGF0ZSB0aGlzIG1vcmUg Y2xlYXJseS4NCg0KQmVzdCByZWdhcmRzLA0KTG90dGUgU3RlZW5icmluaw0KDQoNCg0KU2VjdGlv biA5IChvciwgdGhlIHdob2xlIHNwZWMpIGlzIGFsc28gbm90IGV4cGxpY2l0IGVub3VnaCBhYm91 dCBtdWx0aXBsZSAgImRlZmF1bHQgZ2F0ZXdheXMiIOKAlCBpLmUuLCB0aGUgZXh0ZXJuYWwgbmV0 d29yayBiZWluZyDigJx0aGUgcmVzdCBvZiB0aGUgSW50ZXJuZXTigJ0sIGFuZCB0aGVyZSBiZWlu ZyBtdWx0aXBsZSBnYXRld2F5cyB0byB0aGUgSW50ZXJuZXQuIEkgdW5kZXJzdGFuZCBob3cgdGhl IFJSRVEgZ2V0cyB0byB0aGUgZ2F0ZXdheSwgYW5kIGhvdyB0aGUgZ2F0ZXdheSBkZXRlcm1pbmVz IGlmIGl0IHNob3VsZCByZXNwb25kICh0aGUgZGVzdGluYXRpb24gaXMgbm90IHBhcnQgb2Yg4oCc dGhlIE1BTkVUIHByZWZpeCwgd2l0aCB3aGljaCBpdCBpcyBjb25maWd1cmVk4oCdKS4NCg0KQnV0 LCBpZiBBIGlzIGNsb3NlIHRvIEdXMSwgYW5kIEIgaXMgY2xvc2UgdG8gR1cyLCBidXQgQSBhbmQg QiBiZWluZyBmYXIgZmFyIGFwYXJ0IChhY2NvcmRpbmcgdG8gdGhlIG1ldHJpYyB1c2VkKSB3aXRo aW4gdGhlIE1BTkVULCB0aGVuIGl0IHdvdWxkIGJlIHByZWZlcmVudGlhbCBmb3IgdGhlIHJvdXRl IGZyb20gQSB0byBCIHRvIGdvIHZpYSBHVzEt4oCcdGhlLUludGVybmV04oCdLUdXMj8NCg0KSXMg dGhpcyBhIHN1cHBvcnRlZCBjb25maWd1cmF0aW9uPw0KICAgICAgICAgICAgbyAgICAgICAgICBJ ZiB5ZXMsIGhvdyBpcyBpdCAoc2VxIyB3aXNlLCBJIHdvdWxkIGV4cGVjdCBzb21lIGNvbXBsaWNh dGlvbnMpIGhhbmRsZWQ/DQogICAgICAgICAgICBvICAgICAgICAgIElmIG5vdCwgd2hlcmUgaXMg aXQgc3RhdGVkIHRoYXQgdGhpcyBjb25maWd1cmF0aW9uIGlzIG5vdCBwb3NzaWJsZSB3aXRoIHRo aXMgcHJvdG9jb2w/DQoNCg0KVGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHNheXM6DQoNCg0K ICAgQU9EVnYyIGlzIGRlc2lnbmVkIGZvciBzdHViIG9yIGRpc2Nvbm5lY3RlZCBtb2JpbGUgYWQg aG9jIG5ldHdvcmtzLA0KDQogICBpLmUuLCBub24tdHJhbnNpdCBuZXR3b3JrcyBvciB0aG9zZSBu b3QgY29ubmVjdGVkIHRvIHRoZSBpbnRlcm5ldC4NCg0KICAgQU9EVnYyIGNhbiwgaG93ZXZlciwg YmUgY29uZmlndXJlZCB0byBwZXJmb3JtIGdhdGV3YXkgZnVuY3Rpb25zIHdoZW4NCg0KICAgYXR0 YWNoZWQgdG8gZXh0ZXJuYWwgbmV0d29ya3MsIGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDk8aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzI3NlY3Rp b24tOT4uDQoNCkkgYmVsaWV2ZSB0aGF0IHRoZSBzY2VuYXJpbyBJIGRlc2NyaWJlIGlzIGluZGVl ZCBhIHN0dWIgbmV0d29yayAoYW5kIG5vdCBhIHRyYW5zaXQgbmV0d29yayk/DQoNCuKAlCDigJQg 4oCUDQoNCkFzIEkgaW5kaWNhdGVkLCB0aGVzZSBhcmUgdGhlIGJpZy1waWN0dXJlIGlzc3VlcyB0 aGF0IEkgaGF2ZSBnb3R0ZW4gYXJvdW5kIHRvIHRoaW5raW5nIGFib3V0IGVub3VnaCB0byB3cml0 ZSB1cC4gSeKAmW0gbm90IHRocm91Z2ggd29ya2luZyB0aHJvdWdoIHRoZSBkb2N1bWVudCwgYnV0 IHRob3NlIHdlcmUgdGhlIG9uZXMgdGhhdCBjYW1lIHRvIG1pbmQsIGFuZCB3aGljaCBzZWVtIGlt cGVyYXRpdmUgdG8gcmVzb2x2ZS4NCg0KQmVzdCwNCg0KVGhvbWFzDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0 DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqClRoaXMgZW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZApyZWNpcGll bnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkg dGhlIHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJw b3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIg cGVyc29uLgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKgo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AF005GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bh bjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVt YWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2FuIEkganVz dCBzYXkgaXTigJlzIHF1aXRlIGhhcmQgdG8gd29yayBvdXQgd2hvIGlzIHNheWluZyB3aGF0IGlu IHRoZXNlIGV4Y2hhbmdlcy4gSeKAmW0gaGF2aW5nIHRvIGd1ZXNzIHNvbWUgb24gdGhlIGJhc2lz IG9mIOKAnHRoYXQgc291bmRzIGxpa2UgVGhvbWFz4oCdIG9yIOKAnHRoYXQNCiBzb3VuZHMgbGlr ZSBMb3R0ZeKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXQgSeKAmW0gbm90IGNsZWFyIG9uIGlzIHdoYXQgY29u Y2x1c2lvbiwgaWYgYW55LCB5b3XigJl2ZSBkcmF3biBvbiBob3AgY291bnQvbGltaXQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5BcyBJIHNlZSBpdCwgaWYgdGhlIHByb3RvY29sIHJlY2VpdmVzIGEgbWVzc2FnZSB0aGVu IHNlbmRzIGEgbWVzc2FnZSBzaW1pbGFyIGJ1dCBub3QgaWRlbnRpY2FsIHRvIHRoYXQgb3V0LCB0 aGF0IGNhbiBiZSByZXZpZXdlZCBhcyBjcmVhdGluZyBhIG5ldyBtZXNzYWdlLg0KIEl0IGlzIGEg bmV3IG1lc3NhZ2UgYXMgZmFyIGFzIDcxODIgaXMgY29uY2VybmVkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0IHRo ZSBwcm90b2NvbCBjb3VsZCBpbXBvc2Ugc29tZSByZXN0cmljdGlvbnMuIEZvciBleGFtcGxlIOKA nHRoZSBvbmx5IHRoaW5nIGFsbG93ZWQgdG8gYmUgY2hhbmdlZCBpcyB0aGlzIGZpZWxkIGluIHRo aXMgVExW4oCdLiBXaGljaCBpdCB3b3VsZCB0aGVyZWZvcmUgYmUgYQ0KIGdvb2QgaWRlYSBmb3Ig dGhlIGNyZWF0b3Igb2YgdGhlIG1lc3NhZ2UgdG8gaW5jbHVkZSwgZXZlbiBpZiBpdCB0aHVzIG5l ZWRlZCB0byBpbmNsdWRlIGEgbGluayBtZXRyaWMgb2YgemVyby4gKFdoaWNoIGlzIGEgZGVzaWdu IHBvaW50IC0geW91IG1pZ2h0IG5lZWQgdG8gYWxsb3cgdGhhdCBpbiBtZXRyaWMgc3BlY2lmaWNh dGlvbi4pIEJ1dCB5b3Ugd291bGQgbmVlZCB0byBzdGF0ZSB0aGF0LiBUaGF0IGVuYWJsZXMgc29t ZSBmdXR1cmUgZGVzaWducw0KIC0gbm90IDcxODIsIHBvc3NpYmx5IGFuIGV4dGVuc2lvbiB0byA3 MTgyLCBwb3NzaWJseSBzb21ldGhpbmcgbmV3LiBUaGVyZSBpcyBhIHByb2JsZW0gdGhhdCB0aGlz IGlkZWEgd291bGQgYmUgcHV0dGluZyBpbiBhIG5lZWQgdG8gdW5kZXJzdGFuZCBzcGVjaWZpYyBU TFZzLCB3aGljaCBpcyB1bmRlc2lyYWJsZS4gSSBoYXZlIHNvbWUgaWRlYXMgdGhlcmUsIHN1Y2gg YXMgdXNpbmcgdGhlIHByb3RvY29sLXNwZWNpZmljIHNwYWNlLCBidXQgdGhpcw0KIGlzbuKAmXQg YSBmaXZlIG1pbnV0ZSBqb2IsIGFuZCBuZWVkcyB0byBiZSBnb3QgcmlnaHQuIFdoaWxlIG5vdyBp cyBub3QgdGhlIHRpbWUgdG8gZGVmaW5lIHRoaXMsIHNvbWUgZGVjaXNpb25zIGNvdWxkIHJlYWxs eSBpbXBhY3Qgb24gZnV0dXJlIGRlc2lnbnMuIEZvciBleGFtcGxlIHB1dHRpbmcgYW55dGhpbmcg d2FudGluZyB0byBiZSBtdXRhYmxlIHN0dWNrIGluIHRoZSBtaWRkbGUgb2YgYWxsIHRoZSBvdGhl ciBUTFZzIHdvdWxkIGJlIGNvbnN0cmFpbmluZy4NCiBNYWtpbmcgYWxsIGludGVuZGVkIHRvIGJl IG11dGFibGUgYnkgdGhpcyBwcm90b2NvbCBUTFZzIGluIHRoZSBwcm90b2NvbCBzcGVjaWZpYyBz cGFjZSBpcyBwcm9iYWJseSB0aGUgbGVhc3QgYmFkIGlkZWEsIGFzIHRoYXQgY291bGQgYmUgZ2Vu ZXJhbGlzZWQgKGVpdGhlciBtYWtpbmcgdGhhdCBzcGFjZSBub3QgY292ZXJlZCBieSB0aGlzIGh5 cG90aGV0aWNhbCA3MTgyIHZhcmlhbnQsIG9yIHNwbGl0dGluZyBpdCkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGF0 IGxlYXZlcyBob3AgY291bnQvbGltaXQuIFRlY2huaWNhbGx5IHlvdSB3b3VsZG7igJl0IGluY3Jl bWVudC9kZWNyZW1lbnQsIGFzIGl04oCZcyBhIG5ldyBtZXNzYWdlLiBCdXQgeW91IGNhbiBzZW5k IGFueSBob3AgbGltaXQgb24gYW55IG5ldyBtZXNzYWdlLCBzbyB0aGF0DQogY291bGQgYmUgb25l IGxlc3MgdGhhbiB0aGUgb25lIHlvdSByZWNlaXZlZC4gSG9wIGNvdW50IGlzIGEgYml0IG1vcmUg YXJndWFibGUuIEnigJltIG5vdCBzdXJlIGhvdyBjbGVhcmx5IGl0cyBtZWFuaW5nIGlzIGluZGlj YXRlZCwgd2hldGhlciBpdCBpcyBhIOKAnHJlYWzigJ0gaG9wIGNvdW50IG9mIHRoaXMgbWVzc2Fn ZS4gQnV0IGlmIHlvdSBuZWVkZWQgdG8gSSB3b3VsZG7igJl0IGJlIHRvbyBzdHJvbmdseSBhZ2Fp bnN0IGRvaW5nIHdoYXQgbG9va3MgbGlrZQ0KIGluY3JlbWVudGluZyB0aGF0LCBhcyBsb25nIGFz IGNhcmVmdWxseSBleHBsYWluZWQuIChBIGtleSBxdWVzdGlvbiBpcyBpZiB5b3UgdXNlIDU0OTcg VExWcy4gSW4gdGhhdCBjYXNlIEkgdGhpbmsgLSBjb21iaW5lZCB3aXRoIHRoZSDigJxvbmx5IGNo YW5nZSBvbmUgdGhpbmcgYWJvdmXigJ0gdGhhdCB5b3UgbmVlZCB0byBhcHBlYXIgdG8gaW5jcmVt ZW50IGhvcCBsaW1pdCwgaS5lLiBjcmVhdGUgYSBuZXcgbWVzc2FnZSB3aXRoIGEgbm9uLXplcm8g aG9wDQogY291bnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3 RSI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFs IEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9y aWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNC RUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wg Jm5ic3A7PGI+RToNCjwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVt cy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs bGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1z Zm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMu Y29tL2FpIj48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2Fp PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGll ZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBX YWxlcyBObzogMDEzMzc0NTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmss IEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGhvbWFzIENsYXVzZW48YnI+DQo8Yj5TZW50Ojwv Yj4gMjAgQXByaWwgMjAxNiAxMDo1NTxicj4NCjxiPlRvOjwvYj4gTG90dGUgU3RlZW5icmluazxi cj4NCjxiPkNjOjwvYj4gTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3Q8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW21hbmV0XSBPbiBGb3J3YXJkaW5nLWFuZC1yZWdlbmVyYXRpb24gKHdh czogUmU6IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEgY291cGxlIG9mIGJp ZyB0aWNrZXQgSXRlbXMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2Vu dGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPG86cD48L286 cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRl cjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5p c2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48 L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxi cj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBj bGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48 L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+ DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBl bWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5i YWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVk JTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0 aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0cDovL2lu dHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9E b2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiI+DQp0aGlz IHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp bmc6MS4wcHQgNC4wcHQgMS4wcHQgNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qPHN0cm9uZz48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+KioNCjwvc3Bhbj48L3N0cm9uZz48L3NwYW4+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5XQVJOSU5HDQo8L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KioqPC9z cGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmln aW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Mb3R0ZSwgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJB cHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPk9uIDE5IE1hciAyMDE2LCBhdCAxMjozNCwgTG90dGUgU3RlZW5icmlu ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRlIj5sb3R0 ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBUaG9tYXMsPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbmsgeW91IGZvciByZXZpZXdp bmcgQU9EVnYyIHlldCBhZ2FpbiA6KSBTb21lIGFuc3dlcnMgYmVsb3c6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbSAxNy4wMy4yMDE2IHVt IDE3OjAwIHNjaHJpZWIgPGEgaHJlZj0ibWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmciPg0K aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzwvYT46PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5EZWFyIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFwb2xvZ2llcyBmb3Igbm90IGhhdmluZyBnb3R0ZW4gdGhpcyBkb25l IHNvb25lciAtIGRheS1qb2IgbGVhdmluZyBmZXcgc3BhcmUgY3ljbGVzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZdmUgcHJldmlvdXNs eSBvZmZlcmVkIHJldmlld3MgYW5kIGNvbW1lbnRzLCBhbmQgc29tZSBvZiB0aG9zZSBoYXZlIGJl ZW4gYWRkcmVzc2VkIGluIHRoZSBsYXRlc3QgSS1EIOKAlCBvdGhlcnMgaGF2ZSBub3QsIGJ1dCBz aG91bGQgYmUuIEkgcmVjYWxsIHRoYXQgdGhlcmUgd2FzIHNvbWUgbWFpbCBhdHRlbXB0aW5nIHRv IHJlYnV0IHBhcnRzIG9mIHRoZSByZXZpZXcsIGFuZCBJIHdpbGwgZGlnIGl0IG91dCBhbmQNCiBy ZXBseSB0byB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHdvbGQgYmUg Z3JlYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBmaW5kaW5nIGEgYml0IG9m IHRpbWUgaGVyZSBhbmQgdGhlcmUgd2hlbiB0aGVyZSBhcmUgaG9sZXMgaW4gdGhlIGFnZW5kYSwg YW5kIGFtIChhcyB5b3UgbGlrZWx5IGhhdmUgbm90aWNlZCkgYmFja3RyYWNraW5nIHRocm91Z2gg ZW1haWxzIHdoZW4gSSBnZXQgYSBjaGFuY2UuIEFwb2xvZ2llcywgSSBob3BlIHRoYXQgSSB3aWxs IGdldCB0byB0aGVzZSBlbWFpbHMgdGhpcywgb3IgbmV4dCB3ZWVrLCBidXQNCiBkYXktam9iIGVh dHMgaW4gdG8gdGhlIGF2YWlsYWJsZSB0aW1lIDsoPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi Pjx1PkZvcndhcmRpbmctdnMtcmVnZW5lcmF0aW9uPC91PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlY2VudCBleGNoYW5nZXMgb24gdGhl IGxpc3QgbWFkZSBtZSB1bmRlcnN0YW5kIHRoYXQgcHJvdG9jb2wgY29udHJvbCBtZXNzYWdlcyBh cmUgKm5vdCogZm9yd2FyZGVkLCBidXQgYXJlIGNvbnN1bWVkIGF0IGVhY2ggaG9wLCB0aGVuIGEg bmV3IG1lc3NhZ2Ugd2l0aCAoYWxtb3N0LWJ1dC1ub3QtcXVpdGUpIHRoZSBzYW1lIGNvbnRlbnQg aXMgZ2VuZXJhdGVkIGFuZCB0cmFuc21pdHRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYXTigJlzIHdoYXQgd2XigJl2ZSBiZWVuIHRyeWluZyB0byBzYXkgYWxsIGFsb25nISBJ4oCZ bSByZWFsbHkgZ2xhZCB3ZeKAmXJlIGhhdmluZyB0aGlzIGNvbnZlcnNhdGlvbi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGVuLCBsZXQgdXMgaGF2ZSBpdCAtLSBpdCdzIGEgY2VudHJhbCBwb2ludCB0byBnZXQg cmlnaHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHRob3VnaHQgc29t ZSBtb3JlIG9uIHRoaXMgKCZhbXA7IHJlYWQgc29tZSBvZiB0aGUgZXhjaGFuZ2VzIG9uIHRoZSBs aXN0IG9uIHRoaXMgdG9waWMgYnkgQ2hyaXMsIFVscmljaCwgYW5kIG90aGVycyksIGFuZCBJIGFt IGNvbnZpbmNlZCB0aGF0IHRoaXMgaXMgbm90IHRoZSByaWdodCB3YXkgdG8gZ28sJm5ic3A7PGI+ YXQgbGVhc3Q8L2I+Jm5ic3A7Zm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0i YXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+bzxzcGFuIGNsYXNzPSJhcHBsZS10YWIt c3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PGI+SXQgcmVuZGVycyB0aGUgaG9wLWxpbWl0L2hvcC1jb3VudCBmaWVsZHMg aW4gdGhlIFJGQzU0NDQgbWVzc2FnZSBoZWFkZXIgdXNlbGVzcy48L2I+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQpUaGlzIHdvdWxkIG5v dCBiZSBiYWQgaWYgdGhlIGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBieSB0aG9zZSBmaWVsZHMgd2Fz IG5vdCB1c2VmdWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj4NCuKAlCBzYWRseSwgaXQgaXMuIEZvciBleGFtcGxlLCBmb3Igc2NvcGUgbGlt aXRlZCBmbG9vZGluZyAoZXhwYW5kaW5nIHJpbmcgc2VhcmNoLCBhbmQmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJh cHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCnN1Y2gpIHdo aWNoIG1heSBiZSBvZiBpbnRlcmVzdCwgYW5kIHdoaWNoIHJlcXVpcmUgaG9wLWxpbWl0LiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFu Pg0KQSBob3AtY291bnQgZmllbGQgbWF5IGFsc28gcHJvdmlkZSBhIOKAnGNoZWFw4oCdIChpbiB0 ZXJtcyBvZiBvdmVyaGVhZCkgYWRkaXRpb25hbCBwaWVjZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFu Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0Kb2YgaW5mb3JtYXRpb24gdG8gdXNl IGNvbmp1bmN0aXZlbHkgd2l0aCBhIOKAnHJlYWzigJ0gbWV0cmljLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGFncmVlIG9uIHRoZSB1c2VmdWxuZXNzLCB3aGljaCBpcyB3aHkgd2Ug d2VyZSBwdXp6bGVkIHdoZW4gd2Ugd2VyZSB0b2xkIHdlIHdlcmVu4oCZdCBhbGxvd2VkIHRvIHVz ZSB0aG9zZSBmaWVsZHMgKG9yLCByYXRoZXIsIHRoYXQgd2Ugd2VyZSB1c2luZyB0aGVtIHdyb25n LCBidXQgdGhhdCB0aGUgcmlnaHQgd2F5IHRvIHVzZSB0aGVtIGRvZXNu4oCZdCB3b3JrIGZvciBB T0R2djIpLiBJIGJlbGlldmUgVmlja3kgaGFzDQogd3JpdHRlbiBhYm91dCB0aGlzIGluIG1vcmUg ZGV0YWlsIGluIHByZXZpb3VzIGRpc2N1c3Npb25zLCBhbmQgd2Ugd2VyZS9hcmUgbG9va2luZyBm b3J3YXJkIHRvIHJlYWRpbmcgeW91ciBhbnN3ZXJzLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIHRoZSBz b3VyY2UgZ2VuZXJhdGVzIGEgbWVzc2FnZSwgdGhlIG1lc3NhZ2UgaXMgZm9yd2FyZGVkIHRocm91 Z2ggdGhlIG5ldHdvcmssIHdpdGggZWFjaCBpbnRlcm1lZGlhdGUgcm91dGVyIGRlY3JlbWVudGlu ZyB0aGUgaG9wIGxpbWl0IGFuZCBpbmNyZW1lbnRpbmcgdGhlIGhvcCBjb3VudC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgc3RhdGVkIGlu IHRoZSA1NDQ0LVVzYWdlIGRvY3VtZW50LCB3aGVuIGZvcndhcmRpbmcgYSBtZXNzYWdlLCB0aGUg aG9wLWxpbWl0L2hvcC1jb3VudCBhcmUgbW9kaWZpZWQsIHRoZSByZXN0IG9mIHRoZSBtZXNzYWdl IFNIT1VMRCBub3QgYmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgaXMgc3BlY2lmaWNhbGx5LCBvbmUgdGhpbmcgd2hlcmUg SSBraW5kYSB3b3VsZCBsaWtlIDU0NDQtdXNhZ2UgdG8gZ28gZnVydGhlciBpcyAmcXVvdDt0aGUg bWVzc2FnZSBzdHJ1Y3R1cmUgTVVTVCBpbiBhbGwgY29uZGl0aW9ucyBwcmVzZXJ2ZWQgd2hlbiBm b3J3YXJkaW5nJnF1b3Q7IC0gYnV0IHN0aWxsIHNheSAmcXVvdDthbmQgaXQgaXMgUkVDT01NRU5E RUQgdGhhdCB0aGUgdmFsdWUgZmllbGQgb2YgVExWcyBhcmUgYWxzbyBub3QNCiBtb2RpZmllZCZx dW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2hhdCB0aGlzIGJ1eXMgaXMgc2V2ZXJhbCB0aGluZ3MsIGluIHRoZSBjb250ZXh0IG9mIHRo aXMgcHJvdG9jb2w6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5v PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5ob3AtbGltaXQvaG9wLWNvdW50IGNv dWxkIGJlIHVzZWZ1bCBmb3IgdGhlIHVzdWFsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQpwdXJwb3NlcyAoZW5zdXJpbmcgdGhh dCBtZXNzYWdlcyBkbyBub3QgbGl2ZSBmb3JldmVyLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1z cGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0Kc2NvcGUtbGltaXRlZCBmbG9v ZGluZywgLi4uKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+bzxz cGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+aWYgdGhlIGFjY3VtdWxhdGVkIHBhdGgg bWV0cmljIGlzIHN0b3JlZCBpbiBhIFRMViB2YWx1ZSBmaWVsZCwgdGhhdCZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9 ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KdmFsdWUg ZmllbGQgY2FuICh3aXRoIHN1aXRhYmxlIGRpc2NsYWltZXIgdG8gY2FsbCBvdXQgJnF1b3Q7d2Ug a25vdyBpdCBpczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPg0KUkVDT01NRU5ERUQgdG8gbm90IGRvIHRoaXMsIGJ1dCBoZXJlJ3Mgd2h5IHdl IGFyZSBPSyBpbiBkb2luZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPg0KaXQgYW55d2F5cyZxdW90OykgYmUgbW9kaWZpZWQgd2hlbiBmb3J3 YXJkaW5nIHRoZSBtZXNzYWdlLCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPm88c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPmFzIHRoYXQgcGF0 aCBtZXRyaWMgZmllbGQgaXMgaW4gYSBtZXNzYWdlIHdob3NlIHN0cnVjdHVyZSBkb2VzIG5vdDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g Y2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0K Y2hhbmdlLCBpdCB3aWxsIGJlICZxdW90O2F0IHRoZSBzYW1lIHBsYWNlIGluIHRoZSBieXRlLXN0 cmVhbSZxdW90OyBhdCBlYWNoIGhvcCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCndoaWNoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ bzxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+YWxsb3dzIHVzZWZ1bCB0aGluZ3Mg c3VjaCBhcyBkZXJpdmluZyBmcm9tIFJGQzcxODIgYSBmb3JtIG9mPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFi LXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQomcXVvdDt3aGVuIGNhbGN1 bGF0aW5nIHRoZSBJQ1YsIHplcm8gb3V0IHRoYXQgZmllbGQgaW4gdGhlIG1lc3NhZ2UgJyB3aGVu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ DQombmJzcDsgdmFsaWRhdGluZyBhbiBJQ1YsIGFsc28gemVybyBvdXQgdGhhdCBmaWVsZCZxdW90 OyAtLSB3aGljaCBnb2VzIG9uZSBzdGVwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQombmJzcDsgZnVydGhlciAod2hlbiBjb3VwbGVkIHdp dGggYSB0aW1lIHN0YW1wKSB0aGFuIHNpbXBsZSB0cmFuc2l0aXZlIHRydXN0LCZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KJm5i c3A7IGJ1dCBhbHNvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5v PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5hbGxvd3MgZXZlbiBtb3JlIGZhbmN5 IGFuZCB1c2VmdWwgKGFsYmVpdCBleHBlcmltZW50YWwpIHRoaW5ncyBzdWNoPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBw bGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQphcyBhZ2dyZWdh dGUgc2lnbmF0dXJlcyB0byB3b3JrIGNvcnJlY3RseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnVydGhlcm1vcmUuLi4uLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NClRoZSBvbmx5IHByYWN0aWNhbCBzb2x1dGlvbiB3 b3VsZCBiZSB0byByZS1pbnRyb2R1Y2UgdGhlc2UgZnVuY3Rpb25zIGJ5IHdheSBvZiBpbnNlcnRp bmcgYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9z cGFuPg0KTWVzc2FnZVRMViDigJQgd2hpY2ggKGkpIGlzIG5vdCBzcGVjaWZpZWQgaW4gdGhpcyBk b2N1bWVudCwgYW5kIChpaSkgd2hpY2ggd291bGQganVzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFu Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0Kc2VydmUgdG8gcmVuZGVyIG1lc3Nh Z2VzIGJpZ2dlciB0aGFuIHN0cmljdGx5IG5lZWRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkV4YWN0bHk7IHdl4oCZZCByZWFsbHkgbGlrZSB0byBhdm9pZCB0aGlzIGFzIHdlbGwuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4u Li4gSXQgYXZvaWRzIHRoZSBhYm92ZSwgYW5kLi4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPC9zcGFuPg0KU2NvcGUgbGltaXRlZCBmbG9vZGluZyAmbmJzcDtkb2VzIHNlZW0gdG8g YmUgYSBuZWNlc3NhcnkgcmVxdWlyZW1lbnQsIGlmIGZvciBubzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1z cGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0Kb3RoZXIgcmVhc29uIHRoYW4g dG8gcHJldmVudCBpbmZvcm1hdGlvbiBmcm9tIOKAnGNpcmN1bGF0aW5nIGZvcmV2ZXIgaW4gdGhl IG5ldHdvcmvigJ0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BT0RWdjLigJlzIGR1cGxp Y2F0ZWQgZGV0ZWN0aW9uIGhvcGVmdWxseSBzaG91bGQgdGFrZSBjYXJlIG9mIHRoYXQuIElpcmMs IFdlIGludGVycHJldGVkIHlvdXIgZWFybGllciBFLU1haWxzIHRvIChpbXBsaWNpdGx5KSBtZWFu IHRoYXQgeW91IHRoaW5rIHdlIHNob3VsZCByZWx5IG9uIHRoYXQsIHNpbmNlIHlvdSBzYWlkIHdl IGNhbuKAmXQgdXNlIHRoZSBob3AtbGltaXQvaG9wLWNvdW50IGZpZWxkcy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi4uLi5pZiBkb25l IChwcm9wZXIgZm9yd2FyZGluZyB3aXRoIHByZXNlcnZhdGlvbiBvZiB0aGUgc3RydWN0dXJlLCBy YXRoZXIgdGhhbiByZWdlbmVyYXRpb24gd2hpY2ggb3BlbnMgdXAgdGhlICZxdW90O3RoaXMgaXMg YSBuZXcgbWVzc2FnZSB3aXRoIHBvdGVudGlhbGx5IG5ldyBzdHJ1Y3R1cmUmcXVvdDsgY2FuIG9m IHdvcm1zKSBhcyBJIGRlc2NyaWJlLCBhbHNvIGFkZHJlc3NlcyB0aGUgYWJvdmUuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGggcmVzcGVj dCB0byB3aGF0IEkgc2FpZCBlYXJsaWVyIHdoZW4gSSBzYWlkICZxdW90O2Nhbid0IHVzZSBob3At bGltaXQvaG9wLWNvdW50IGZpZWxkcyZxdW90Oy4uLi53aGVuIHlvdSByZWdlbmVyYXRlLCB5b3Ug YWJzb2x1dGVseSwgZGVmaW5pdGVseSwgY2FuJ3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4geW91ICZxdW90O3JlZ2VuZXJh dGUmcXVvdDsgYSBtZXNzYWdlLCB0aGF0IG1lYW5zICZxdW90O3lvdSBjb25zdHJ1Y3QgYSBicmFu ZCBuZXcgbWVzc2FnZSZxdW90OyB3aGljaCBtYXkgc2h1ZmZsZSBhZGRyZXNzZXMgaW5zaWRlIGFk ZHJlc3MgYmxvY2tzLCBvciBiZXR3ZWVuIGFkZHJlc3MgYmxvY2tzLCBzaHVmZmxlIFRMVnMgZGlm ZmVyZW50bHkgdGhhbiB0aGV5IHdlcmUgb3JpZ2luYWxseSwgZXZlbiB1c2UgVExWcyBvZiBkaWZm ZXJlbnQNCiBzdHJ1Y3R1cmUgKGUuZy4sIHNpbmdsZS12YWx1ZSBUTFZzIGluc3RlYWQgb2YgbXVs dGktdmFsdWUgVExWcykuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbWVhbnMgdGhhdCBzb21lIGFzc3VtcHRpb25z IChzdWNoIGFzIHdoZW4gcHJvZHVjaW5nIGFuIElDViBmb3IgdGhlIG1lc3NhZ2UsIHdoaWNoIGRl cGVuZHMgb24gdGhlIGJ5dGUgb3JkZXIpIGRvbid0IGhvbGQuIFdlbGwsIHRoZXkgbWF5IG5vdCBo b2xkLCBzbyB0aGF0IG1lYW5zIHdlIGNhbid0IGFzc3VtZSB0aGF0IHRoZXkgZG8uIFdoaWNoIG1l YW5zIHRoYXQgdGhlIG9yaWdpbmF0b3Igb2YgYSBtZXNzYWdlDQogY2Fubm90IGdlbmVyYXRlIGFu IElDViB0aGF0IGNhbiBiZSBjb3JyZWN0bHkgaW50ZXJwcmV0ZWQgKHdoaWNoIGlzIHdoYXQgbXkg bmV4dCBzZWN0aW9uIGluIG15IG9yaWdpbmFsIG1haWwgd2FzIGFib3V0KS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpY2ggbWVh bnMsIGluIGNvbmNsdXNpb24sICZuYnNwO3RoYXQgdGhlIGluZm9ybWF0aW9uIGluIHRoZSBtZXNz YWdlIHByb2ZvdW5kbHkgY2hhbmdlIC0tIGFuZCB0aGVyZWZvcmUgdGhlc2UgaG9wLWNvdW50L2hv cC1saW1pdCB2YWx1ZXMgZG8gbm90IGV2ZW4gYXBwbHkgdG8gJnF1b3Q7dGhlIGluZm9ybWF0aW9u JnF1b3Q7LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyJm5ic3A7aWYgcHJvcGVyIGZvcndhcmRpbmcgd2l0aCBw cmVzZXJ2YXRpb24gb2YgdGhlIHN0cnVjdHVyZSwgcmF0aGVyIHRoYW4gcmVnZW5lcmF0aW9uIHdo aWNoIG9wZW5zIHVwIHRoZSAmcXVvdDt0aGlzIGlzIGEgbmV3IG1lc3NhZ2Ugd2l0aCBwb3RlbnRp YWxseSBuZXcgc3RydWN0dXJlJnF1b3Q7IGNhbiBvZiB3b3JtcywgYXMgSSAoJmFtcDsgVWxyaWNo ICZhbXA7IG90aGVycykgaGF2ZSBzdWdnZXN0ZWQsIGlzIHRha2VuIHRvIGhlYXJ0LA0KIGl0IGFs c28gYWRkcmVzc2VzIHRoZSBpc3N1ZSBiZWxvdyByZWdhcmRpbmcgZW5kLXRvLWVuZCBhdXRoZW50 aWNhdGlvbiAod2hpY2gsIHdoaWxlIHN0aWxsIGhhcmQsIGlzIHBvc3NpYmxlKS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBjb3Vw bGUgb2YgbW9yZSBjb21tZW50cyBiZWxvdzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPm88c3BhbiBj bGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxiPjx1Pkl0IG1ha2VzIGVuZC10by1lbmQgYXV0 aGVudGljYXRpb24gdW5uZWNlc3NhcmlseSBoYXJkLjwvdT48L2I+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFi LXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQpJIHRoaW5rIENocmlzIGNh bGxlZCB0aGlzIG91dCBhbHJlYWR5LCBidXQgaXQgYmVhcnMgcmVwZWF0aW5nOiBTIGdlbmVyYXRl cyBhIG1lc3NhZ2UmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj4NCihzYXksIGEgUlJFUSksIGFuZCBpbmNsdWRlcyBhbiBJQ1YgY2Fs Y3VsYXRlZCBvdmVyIHRoZSBjb250ZW50IG9mIHRoZSBtZXNzYWdlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRh Yi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KRm9yIGFueSByZWNpcGll bnQgdG8gYmUgYWJsZSB0byB2YWxpZGF0ZSB0aGUgSUNWLCB0aGUgbWVzc2FnZSBoYXMgdG8gYmUg ZXhhY3RseTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PC9zcGFuPg0KdGhlIHNhbWUg4oCUIG5vdCBqdXN0IGluIGNvbnRlbnQsIGJ1dCBpbiBzdHJ1Y3R1 cmUg4oCUIGFzIHdoYXQgd2FzIGdlbmVyYXRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0K4oCcUmVnZW5lcmF0aW5n4oCdIHJhdGhl ciB0aGFuIOKAnGZvcndhcmRpbmfigJ0gbWVzc2FnZXMgbWVhbnMsIHRoYXQgdGhlIGludGVybWVk aWF0ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9z cGFuPg0Kcm91dGVyIOKAnHJlZ2VuZXJhdGluZ+KAnSB0aGUgUlJFUSBtYXkgY2hvc2UgYSBkaWZm ZXJlbnQgc3RydWN0dXJlIChlLmcuLCBpbmNsdWRlIFRMVnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3Bh biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCmluIGEgZGlmZmVyZW50IG9yZGVy KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9z cGFuPg0KVGhlIHByb3Bvc2FsIGZyb20mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMCI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlcmtpbnMtbWFuZXQtYW9kdi1lMmVzZWMtMDA8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBj bGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQpp cyB0byBhZGQgY29uc3RyYWludHMgb24gKGkpIHRoZSBzZXQgb2YgZWxlbWVudHMgdG8gaW5jbHVk ZSBpbiBhIHNpZ25hdHVyZSBhbmQgKGlpKSB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCm9yZGVyIG9mIHRoZXNlIGVsZW1lbnRzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ DQpPbmUmbmJzcDtwcm9ibGVtIHdpdGggdGhhdCBhcHByb2FjaCBpcyAoaSk6IGlmIGFuIGV4dGVu c2lvbiBhZGRzIGEgbWVzc2FnZSBUTFYsIG9yIGFuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw YW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQpBZGRyZXNzIFRMViwgdG8gYSBt ZXNzYWdlLCB0aGVuIHRoYXQgd2lsbCBub3QgYmUg4oCcY292ZXJlZOKAnSBieSB0aGUgcHJvcG9z ZWQgZTJlc2VjIFRMVi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvc3Bhbj4NClJhdGhlciBmb3IgKmVhY2gqIGV4dGVuc2lvbiBkZXZlbG9wZWQsIGFu IOKAnHVwZGF0ZXMgZTJlc2Vj4oCdIGNsYXVzZSBuZWVkcyB0byBiZSBkb25lLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0i YXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQpJ4oCZZCBz YXkgdGhhdCB0aGlzIGFwcHJvYWNoIHdvdWxkIGJlIHByb25lIHRvIGVycm9ycyDigJQgYW5kIGFk ZCBlbnRyb3B5IHRvIHRoZSBwcm9jZXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQpvZiBkZXNpZ25pbmcgcHJvdG9jb2wgZXh0ZW5zaW9u cy4gVGhlIGFsdGVybmF0aXZlLCBhIG1lc3NhZ2UgYmVpbmcgZ2VuZXJhdGVkIGJ5IHRoZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0Kc291 cmNlIGFuZCAqZm9yd2FyZGVkKiAoYXMgd2UgZG8gaW4gT0xTUnYyLCBmb3IgZXhhbXBsZSkgd291 bGQgYWxsb3cgSUNWIFRMVnMmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCihldmVuLCBhbGxvdyByZXVzZSBvZiB0aG9zZSBzcGVj aWZpZWQgZm9yIE9MU1J2MikgZm9yIGNvdmVyaW5nIGEgbWVzc2FnZSBhbmQmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNz PSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCmV4dGVu c2lvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj4NCuKAnEJ1dCB3aGF0IGFib3V0IHRoZSBtZXRyaWNzIHZhbHVlIHdoaWNoIHdpbGwg Y2hhbmdlIG9uIGVhY2ggaG9w4oCdLCB5b3UgbWF5IHNheT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3Bh biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCkZvcnR1bmF0ZWx5LCB0aGF0IGlz IHJlbGF0aXZlbHkgZWFzeSB0byBoYW5kbGU6IHNpbXBseSB6ZXJvIG91dCB0aGUgdmFsdWUgb2Yg dGhhdCBUTFYgd2hlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPC9zcGFuPg0KZ2VuZXJhdGluZyBvciB2ZXJpZnlpbmcgdGhlIElDViBNZXNzYWdlVExW LiBBbmQgdXNlIFBhY2tldC1UTFZzIGZvciBob3AtYnktaG9wJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQphdXRoZW50aWNhdGlv biwgaWYgbmVlZGVkIChidXQsIHNlZSBiZWxvdykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj5vPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48Yj48 dT5JdCBwcmV2ZW50cyB0aGUgdXNlIG9mIG1vcmUgY2xldmVyL2FkdmFuY2VkIHNpZ25hdHVyZSBz Y2hlbWVzL0lDVnM8L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPg0KQWdncmVnYXRlIHNpZ25hdHVyZSBhbGdvcml0aG1zICgmbmJz cDs8YSBocmVmPSJodHRwczovL2NyeXB0by5zdGFuZm9yZC5lZHUvfmRhYm8vcGFwZXJzL2FnZ3N1 cnZleS5wZGYiPmh0dHBzOi8vY3J5cHRvLnN0YW5mb3JkLmVkdS9+ZGFiby9wYXBlcnMvYWdnc3Vy dmV5LnBkZjwvYT4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L3NwYW4+DQpleGlzdCwgYW5kIGFuIGludGVyZXN0aW5nIHVzZS1jYXNlIGNhbiBiZSBm b3VuZCBpbiBhbHNvIHJlYWN0aXZlIHByb3RvY29scywgYWxsb3dpbmcgdmVyaWZ5aW5nPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFz cz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQpub3Qg 4oCcanVzdOKAnSB0aGUgZW5kIHBvaW50cywgYnV0IGFsc28gdGhlIGludGVybWVkaWFyaWVzIChh Z2Fpbiwgd2l0aCB0aGUgYXBwcm9wcmlhdGUg4oCcemVybyBvdXTigJ08bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10 YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCmRpc2N1c3NlZCBhYm92 ZSwgb3Igc29tZXRoaW5nIHNtYXJ0ZXIpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KUmVnZW5lcmF0aW9uIG9mIG1lc3NhZ2VzLCByYXRo ZXIgdGhhbiBmb3J3YXJkaW5nLCByZW5kZXJzIHRoYXQgaW1wb3NzaWJsZSAob3IsIGlmIHVzZWQs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ DQp1cGRhdGluZyB0byAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMCI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXBlcmtpbnMtbWFuZXQtYW9kdi1lMmVzZWMtMDA8L2E+KTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUgb3Ro ZXIgcmVhc29ucywgYnV0IHRoZSBhYm92ZSBhcmUgdGhvc2UgdGhhdCBqdW1wIGF0IG1lIGFzIGlt bWVkaWF0ZSBzaG93LXN0b3BwZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIGhvbmVzdGx5IG5vdCBzZWUgd2hhdCBwb3NzaWJsZSBi ZW5lZml0IHRoZXJlIGlzIGZyb20g4oCccmVnZW5lcmF0aW9u4oCdIOKAlCBidXQgSSBzZWUgdmVy eSBjbGVhciBpbmNvbnZlbmllbmNlcywgYW5kIHNlY3VyaXR5IGlzIG5vdCB0aGUgbGVhc3Qgb2Yg dGhlc2UuIEluc2lzdGluZyBvbiDigJxyZWdlbmVyYXRpb27igJ0gcmVxdWlyZXMgZGV2ZWxvcG1l bnQgb2Yg4oCcbm9uLWdlbmVyYWwgd29ya2Fyb3VuZHPigJ0gYXMgcG9pbnRlZA0KIG91dCBhYm92 ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwb3NzaWJsZSBiZW5lZml0IGlzIHRo YXQgd2UgbmVlZCB0byBhY2N1bXVsYXRlICZhbXA7IHRyYW5zcG9ydCBtZXRyaWMgdmFsdWVzIHNv bWVob3csIGFuZCB3ZSBjYW7igJl0IGRvIHRoYXQgd2l0aG91dCByZWdlbmVyYXRpbmcgYXQgbGVh c3QgcGFydHMgb2YgdGhlIG1lc3NhZ2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZeKAmXJlIG1pc3NpbmcgYSBzb2x1dGlvbiBoZXJlLCBw bGVhc2Ugc2hhcmUgaXQgd2l0aCB1cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvbmUgaW4gdGhlIGFib3ZlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHU+U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3U+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBmb3IgY29udGV4dOKAmXMgc2FrZSwg ZGlkIHlvdSByZXZpZXcgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluJm5ic3A7ZHJhZnQt aWV0Zi1tYW5ldC1hb2R2djItMTMgb3IgdGhlIG9uZXMgcHJvcG9zZWQgaW4gdGhlIHRocmVhZCDi gJ5BT0RWdjI6IFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHVwZGF0ZeKAnD88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGRpZC4gSXQgc3RpbGwgaXMgYSBmYXIgY3J5IGZyb20gcGFzc2luZyB0aGUgYmFyLiBJJ3Zl IHBvc3RlZCBvbiB3aHkgaW4gdGhlIHBhc3QsIGFuZCBzb21lIG1vcmUgaW4gdGhpcyBtYWlsICh3 aGljaCBhbHNvIGNvbnRhaW5zIHNvbWUgc3VnZ2VzdGlvbnMpLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIHN1Z2dlc3QgdGhhdCBz ZXR0bGluZyB0aGUgcmVhcmNoaXRlY3R1cmluZyB0byBkbyBmb3J3YXJkaW5nLCBhcyBJIGRlc2Ny aWJlIGluIHRoZSBhYm92ZSwgc2hvdWxkIGJlIGRvbmUsIHdoaWNoIHdvdWxkIGVhc2UgdGhlIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIGlzc3VlIGNvbnNpZGVyYWJseSAoYW5kIHdoaWNoIHdvdWxk IGJlIG5lY2Vzc2FyeSBldmVuIGlmIGlnbm9yaW5nIHRoZSBzZWN1cml0eQ0KIGNvbnNpZGVyYXRp b25zLCBJTU8sIGZvciB0aGlzIGRvYyB0byBnbyBhbnl3aGVyZSkuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGggYSBu ZXcgdmVyc2lvbiBjb3ZlcmluZyB0aGF0LCB0aGUgYXV0aG9ycyAoSSB3YW50ZWQgdG8gd3JpdGUg JnF1b3Q7eW91JnF1b3Q7LCBidXQgZGVjaWRlZCB0byBiZSBpbmNsdXNpdmUpIGNvdWxkJm5ic3A7 eW91IGdvIGxvb2sgYXQgdGhlIGRpZmZlcmVudCBzZWN1cml0eSBlbWFpbHMgYW5kIHBlcmhhcHMg c3RhcnQgYSBzZXBhcmF0ZSB0aHJlYWQgb24gdGhhdCwgdG93YXJkcyBhIHJlc29sdXRpb24/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVz dCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhvbWFzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGFuIGFsd2F5cyB0aG9ybnkg c3ViamVjdC4gV2hlbiBPTFNSdjIgd2FzIGdvaW5nIHRocm91Z2ggdGhlIHByb2Nlc3Mgd2UgZ290 IGEgdGhvcm91Z2ggZWR1Y2F0aW9uIGluIGhvdyBsaXR0bGUgd2Uga25ldyBhYm91dCBzZWN1cml0 eSBmcm9tIHRoZSBTRUMtQURzLCBhbmQgaGFkIHRvIHNwZW5kIGFib3V0IGEgeWVhciBvciBzbyBk ZXZlbG9waW5nIFJGQzcxODMuIFRoZSBib3R0b20gbGluZSBpcywgdGhhdA0KIHRoaXMgcHJvdG9j b2wgbmVlZHMgaXRzIOKAnFJGQzcxODMgJm5ic3A7ZXF1aXZhbGVudOKAnSwgZWl0aGVyIGFzIHBh cnQgb2YgdGhlIG1haW4gZG9jdW1lbnQsIG9yIGFzIGFuIGluZGVwZW5kZW50IGRvY3VtZW50LiBj dXJyZW50bHksIHRoYXQgaXMgbm90IHRoZSBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIG1pbmltYSwgbG9va2luZyBhdCBCQ1A3MiBh bmQgQkNQMTA3IOKAlCB0YWtpbmcgaW5zcGlyYXRpb24gZnJvbSBSRkM3MTgzIG1pZ2h0IGJlIGF3 IGdvb2QgaWRlYSwgYXMgdGhhdCB3YXMgdGhlIG1vc3QgcmVjZW50IHRoYXQgd2VudCB0aHJvdWdo IHRoZSBTRUMgQUQuIFJlZ2FyZGxlc3Mgb2YgaG93LCBob3dldmVyLCBhIOKAnG1hbmRhdG9yeSB0 byBpbXBsZW1lbnTigJ0gc2VjdXJpdHkgbWVjaGFuaXNtIG1vc3QgYmUgc3BlY2lmaWVkDQogKEkg dGhpbmsgdGhlIHJpZ2h0IHRlcm0gd2FzIOKAnE1VU1QgaW1wbGVtZW50LCBTSE9VTEQgdXNl4oCd KSwgaW4gc3VmZmljaWVudCBkZXRhaWwgdG8gZW5zdXJlIGludGVyb3BlcmFibGUgaW1wbGVtZW50 YXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGFuIGV4YW1wbGUsIGJvdGgg W1JGQzYxMzBdIGFuZCBbUkZDNzE4MV0gc2V0IG91dCB0aGF0IHRoYXQ6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyBPbiByZWNlaXZpbmcgYSAuLi4gbWVzc2FnZSwgYSByb3V0ZXIgTVVTVCBmaXJz dCBjaGVjayBpZiB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IG1lc3NhZ2UgaXMgaW52YWxpZCBmb3IgcHJv Y2Vzc2luZyBieSB0aGlzIHJvdXRlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgdGhlbiBwcm9jZWVkIHRvIGdpdmUgYSBudW1iZXIgb2Yg Y29uZGl0aW9ucyB0aGF0LCBlYWNoLCB3aWxsIGxlYWQgdG8gYSByZWplY3Rpb24gb2YgdGhlIG1l c3NhZ2UgYXMgJnF1b3Q7YmFkbHkgZm9ybWVkIGFuZCB0aGVyZWZvcmUgaW52YWxpZCBmb3IgcHJv Y2Vzc2luZ+KAnSDigJQgYSBsaXN0IHdoaWNoIFJGQzcxODMgdGhlbiBhbWVuZGVkLiBUaGF0IGdh dmUgYSDigJxob29r4oCdIGZvciBSRkM3MTgzIGZvciBpbnNlcnRpbmcNCiDigJxyZWplY3Rpb27i gJ0uIElkZW0gZm9yIG1lc3NhZ2UgZ2VuZXJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgSSB3YXMgdG8gZG8gUkZDNzE4MS9SRkM2 MTMwIHRvZGF5LCBJIHdvdWxkIGluY2x1ZGUgdGhhdCBkaXJlY3RseSBpbnRvIHRoZSBwcm90b2Nv bCBzcGVjaWZpY2F0aW9ucy4gSXQgdHVybmVkIG91dCB0byBiZSBtb3JlIG92ZXJoZWFkIChhbmQg c2xvdyBkb3duIHB1YmxpY2F0aW9uIGFueXdheXMpIHRvIGRvIGl0IGFzIHNlcGFyYXRlIGRvY3Vt ZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TZWNvbmRseSwgd2UgbmVlZCB0byBiZSBhIGxvdCBtb3JlIHJpZ2lkIGluIHRl cm1zIG9mIHdoYXQgSUNWcywgVGltZXN0YW1wcywgZXRjLiBhcmUgYWRkZWQvcmVtb3ZlZCwgYW5k IHdoYXQgdGhhdCBicmluZ3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkZvciBleGFtcGxlICh3aXRoIHRoZSBhc3N1bXB0aW9uIHRoYXQgbWVz c2FnZXMgYXJlICpmb3J3YXJkZWQqIGFuZCAqbm90KiByZWdlbmVyYXRlZCksIHRoaXMgY291bGQg YmUgb25lIG9wdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPg0KbzxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5XaGVu IGEgUlJFUSwgUlJFUCBtZXNzYWdlIGlzIGdlbmVyYXRlZCwgYWRkIGFuIElDViBNZXNzYWdlIFRM Viwgd2hpY2ggaXMgY2FsY3VsYXRlZCAmbHQ7dGhpcyB3YXkmZ3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFi LXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPiZu YnNwO+KApih0YWtlIGluc3BpcmF0aW9uIGZyb20gUkZDNzE4MyBoZXJlKTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBw bGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQpvPHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPldoZW4gYSBSUkVRLCBSUkVQIG1lc3NhZ2UgaXMgdHJh bnNtaXR0ZWQgJm5ic3A7KGJ5IHRoZSBzb3VyY2UsIG9yIGZvcndhcmRlZCBieSBhbiBpbnRlcm1l ZGlhcnkpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPmluIGFuIFJGQzU0NDQgcGFja2V0LCBhbiBJQ1YgUGFja2V0 IFRMViBpcyBhZGRlZCB0byB0aGUgcGFja2V0LCB3aGljaCBpcyBjYWxjdWxhdGVkICZsdDt0aGlz IHdheSZndDsg4oCmPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvc3Bhbj4NCm88c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+V2hlbiBh biBSRkM1NDQ0IHBhY2tldCBpcyByZWNlaXZlZCwgdmFsaWRhdGUgdGhlIElDViBQYWNrZXQgVExW ICZsdDt0aGlzIHdheSZndDsgYW5kIGlmIHRoZSBJQ1YgZG9lc27igJl0IHZhbGlkYXRlLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj5kaXNjYXJkIHRoZSBjb250YWluZWQgbWVzc2FnZXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBs ZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCm88c3BhbiBjbGFz cz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+V2hlbiByZWNlaXZpbmcgYSBSUkVRL1JSRVAgKGVpdGhl ciBhcyBkZXN0aW5hdGlvbiwgb3IgYXMgYW4gaW50ZXJtZWRpYXJ5KSwgdmFsaWRhdGUgdGhlIElD ViBNZXNzYWdlIFRMViZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj4mbHQ7dGhpcyB3YXkmZ3Q7IGFuZCBp ZiB0aGUgSUNWIGRvZXNu4oCZdCB2YWxpZGF0ZSwgZGlzY2FyZCB0aGUgbWVzc2FnZSwgZG8gbm90 IHByb2Nlc3MsIGRvIG5vdCBmb3J3YXJkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGEgZGlmZmVyZW50IChhbmQgbW9yZSBmbGV4 aWJsZT8pIG1vZGVsIHRoYW4g4oCcanVzdOKAnSB0cmFuc2l0aXZlIHRydXN0IGFuZCDigJxqdXN0 4oCdIGVuZC10by1lbmQgdHJ1c3QgZGlzY3Vzc2VkIHByZXZpb3VzbHksIGFuZCBpcyBlbmFibGVk IGJ5IHRoZSDigJxmb3J3YXJkaW5n4oCdIGJpdCBkZXNjcmliZWQgcHJldmlvdXNseS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHU+TWV0 cmljczwvdT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGhhdmUgYXNrZWQgdGhpcyBudW1lcm91cyB0aW1lcywgYnV0IGhhdmUgbm90IGdv dHRlbiBhbnkgYW5zd2VyIHNvIEkgYW0gZXNjYWxhdGluZyB0aGlzIGFnYWluLiBXaHkgaXMgdGhp cyBkb2N1bWVudCBoYXZpbmcgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIFJGQzY1NTE/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5cyI+Jm5ic3A7Jm5ic3A7IFs8YSBuYW1lPSJyZWYtUkZDNjU1MSIgaWQ9InJlZi1SRkM2 NTUxIj5SRkM2NTUxPC9hPl0mbmJzcDsgVmFzc2V1ciwgSlAuLCBFZC4sIEtpbSwgTS4sIEVkLiwg UGlzdGVyLCBLLiwgRGVqZWFuLCBOLiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kIEQuIEJhcnRo ZWwsICZxdW90O1JvdXRpbmcgTWV0cmljcyBVc2VkIGZvciBQYXRoIENhbGN1bGF0aW9uPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGluIExvdy1Qb3dlciBhbmQgTG9zc3kgTmV0d29ya3MmcXVvdDssIDxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTUxIj5SRkMgNjU1MTwvYT4s IERPSSAxMC4xNzQ4Ny88bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzY1NTEiPlJGQzY1NTE8L2E+LCBNYXJjaCAyMDEyLDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZv L3JmYzY1NTEiPmh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM2NTUxPC9hPiZndDsu PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Vbmxlc3MgSSBhbSBtaXN0YWtlbiwgdGhpcyBpcyBub3QgdGhlIFJPTEwgV0cuIEFuZCB0aGUg YWJzdHJhY3QgdG8gUkZDNjU1MSBleHBsaWNpdGx5IHJlYWRzOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d2hpdGUtc3Bh Y2U6cHJlLXdyYXAiPiZuYnNwOyZuYnNwOyBMb3ctUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzIChM TE5zKSBoYXZlIHVuaXF1ZSBjaGFyYWN0ZXJpc3RpY3M8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgY29tcGFyZWQgd2l0aCB0cmFkaXRpb25hbCB3aXJlZCBhbmQgYWQgaG9jIG5l dHdvcmtzIHRoYXQgcmVxdWlyZSB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsgc3BlY2lmaWNhdGlvbiBvZiBuZXcgcm91dGluZyBtZXRyaWNzIGFuZCBjb25zdHJhaW50cy4m bmJzcDsgPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGlj aCBleHBsaWNpdGx5IGlzIGRpc2NsYWltaW5nIHRoYXQgdGhlc2UgbWV0cmljcyBhcmU8Yj48dT4g bm90IGFwcGxpY2FibGUgaW4gYWQgaG9jIG5ldHdvcmtzPC91PjwvYj4g4oCUIGFuZCwgSSBhbSB3 b25kZXJpbmcsIHdoYXQgaGFzIGNoYW5nZWQgc2luY2UgdGhlIHB1YmxpY2F0aW9uIG9mIFJGQzY1 NTEgdG8gc3VkZGVubHkgbWFrZSB0aGVzZSBhcHBsaWNhYmxlPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtJIGFtIGFsc28gd29uZGVy aW5nIGlmIGxvb2tpbmcgYXQgKGFuZCwgcGVyaGFwcywgdXNpbmc/KSB0aGUgc2FtZSBtZXRyaWMg dHlwZSBUTFYgdHlwZSBhcyBpbiBPTFNSdjIgaXMgbm90IGEgcG9zc2liaWxpdHk/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RWl0 aGVyIHdheSwgcmVmZXJlbmNpbmcgUkZDNjU1MSBoZXJlIGlzIHdyb25nLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48dT5SRkM2NjIxIChT TUYpIHVzYWdlPC91PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFzIGxhdGUgYXMgZWFybGllciB0aGlzIG1vbnRoLCBSRkM2NjIxIHJlYXJl ZCBpdHMgaGVhZCBhZ2FpbiBvbiB0aGUgbWFpbGluZyBsaXN0LiBJIHVuZGVyc3RhbmQgdGhhdCB0 aGUgYXV0aG9ycyBhcmUgc2V0IG9uIHVzaW5nIGZsb29kaW5nIHJlZHVjdGlvbiBhcyBwYXJ0IG9m IFJSRVEgZGlzdHJpYnV0aW9uLiBJZiB0aGF0IGlzIHRoZSBjYXNlLCB0aGVuIHRoaXMgcHJvdG9j b2wgTVVTVCBzcGVjaWZ5IHRoYXQNCiBmbG9vZGluZyByZWR1Y3Rpb24uJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNheWluZyDigJxV c2UgUkZDNjYyMeKAnSB3b27igJl0IHdvcmssIGZvciByZWFzb25zIENocmlzIHBvaW50IG91dCBp biBhbiBlbWFpbCBlYXJsaWVyIHRvIHRoZSBsaXN0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbmV0d29yayBkb2VzIG5vdCBhbmQgZnVu ZGFtZW50YWxseSBjYW5ub3Qgb2ZmZXIgbXVsdGljYXN0IHN1cHByZXNzaW9uIHRvIEFPRFZ2Mi4g VGhpcyBpc24ndCBhIGhhcmQgY29uY2VwdCwgYnV0IHNlZW1zIHRvIGtlZXAmbmJzcDtoYXZpbmcg dG8gYmUgc2FpZC4gQU9EVnYyIG1lc3NhZ2VzIGFyZSBjYXJyaWVkIGluIDU0NDQgcGFja2V0cywg YW5kIHRob3NlIG9ubHkgdHJhdmVsIG9uZSBob3AuIFRoYXQgZG9lc24ndA0KIGFsbG93IGZvciBz dXBwcmVzc2lvbi4mbmJzcDtGdXJ0aGVybW9yZSBBT0RWdjIgaXMgY3JlYXRpbmcgbmV3IG1lc3Nh Z2VzIGVhY2ggaG9wLiBUaGF0IG5lZWRzIEFPRFZ2MiBzcGVjaWZpYyBoYW5kbGluZy48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QW5kIHF1b3RpbmcgYW4gZW1haWwgZnJvbSBteXNlbGY6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHByb3RvY29sIFggcmVsaWVz IG9uIHVzaW5nIGEgZmxvb2Rpbmcgb3BlcmF0aW9uLCB0aGVuIGl0IGNlcnRhaW5seSBpcyBwcm90 b2NvbCBYJ3MgcmVzcG9uc2liaWxpdHkgdG8gJm5ic3A7c3BlY2lmeSB0aGUgZmxvb2Rpbmcgb3Bl cmF0aW9uIChvciwgYXQgbGVhc3QsJm5ic3A7dGhlIHJlcXVpcmVtZW50cyB0byB0aGUgZmxvb2Rp bmcgb3BlcmF0aW9uICkgZm9yIGNvcnJlY3QgZnVuY3Rpb25pbmcgb2YgcHJvdG9jb2wgWC48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmXZl IHByZXZpb3VzbHkgcG9pbnRlZCBvdXQgdGhhdCBSRkM2NjIxIHJlcXVpcmVzIHNvbWUgZGVncmVl IG9mIGNvbmZpZ3VyYXRpb24gKGNhbuKAmXQganVzdCwgZm9yIGV4YW1wbGUsIHBpY2sgdHdvIGRp ZmZlcmVudCByZWxheSBzZXQgc2VsZWN0aW9uIGFsZ29yaXRobXMsIGFzIHRoYXQgbWF5IHByb2R1 Y2UgYSBkaXNjb25uZWN0ZWQgZmxvb2RpbmcgZG9tYWluKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gb3RoZXIgd29yZHMsIHdoYXQgdGhl IGF1dGhvcnMgcHJvcG9zZSBpbiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1wZXJraW5zLW1hbmV0LXVzaW5nLXJmYzY2MjEtMDAiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1wZXJraW5zLW1hbmV0LXVzaW5nLXJmYzY2MjEtMDA8L2E+Jm5i c3A7aXMgaW5zdWZmaWNpZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48dT5NdWx0aXBsZSBpbnRlcmZhY2VzIGNvbmZpZ3VyZWQgd2l0 aCB0aGUgc2FtZSBhZGRyZXNzKGVzKSAtICZhbXA7IFJGQzY2MjE8L3U+PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGF0IGl0 IGhhcyBiZWVuIGVzdGFibGlzaGVkIHRoYXQgdGhlIGFiaWxpdHkgdG8gdXNlIHRoZSBzYW1lIGFk ZHJlc3Mgb24gbXVsdGlwbGUgaW50ZXJmYWNlcyBpcyBhIHJlcXVpcmVtZW50LiBJdOKAmXMgbm90 IGNsZWFyIHRvIG1lIHRoYXQgYSBzaW5nbGUgd2F5IG9mIGRvaW5nIHNvIGhhcyBiZWVuIHByb3Bv c2VkLCBub3IgdGhhdCB0aGUg4oCcb3BlcmF0aW5nIGNvbmRpdGlvbnPigJ0gYXJlIGNhbGxlZA0K IG91dCAoZm9yIGV4YW1wbGUsIHdpbGwgaXQgd29yayAmbmJzcDtpZiByb3V0ZXIgQSBhbmQgcm91 dGVyIEIgYm90aCBoYXZlIHR3byBpbnRlcmZhY2VzLCBhbmQgdGhhdCBhbGwgNCBpbnRlcmZhY2Vz IHVzZSB0aGUgc2FtZSBJUCBhZGRyZXNzPyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBub3QgZW50aXJlbHkgdW5yZWxhdGVkIHRv IGZsb29kaW5nIHJlZHVjdGlvbiBhbmQgUkZDNjYyMS4gT25lIG9mIHRoZSBjb21wbGV4aXRpZXMg aXMgdG8gZ2V0IHRoYXQganVzdCByaWdodDogT0xTUnYyIC0gZm9yIGV4YW1wbGUgLSBjYWxjdWxh dGVzIEZsb29kaW5nLU1QUnMgcGVyIGludGVyZmFjZSwgYW5kIFJGQzYxMzAgaXMgY2FyZWZ1bCBp biBob3cgaXQgZGV0ZWN0cyBiaWRpcmVjdGlvbmFsaXR5DQogb2YgbGlua3MuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBu b3Qgd29ya2VkIG91dCBhbGwgdGhlIGRldGFpbHMgb2YgaG93IHRoaXMgaW1wYWN0cyB0aGlzIHBy b3RvY29sIOKAlCBidXQsIGl0IHJlcXVpcmVzIGF0dGVudGlvbi4gRXNwZWNpYWxseSB3aGVuIHdh bnRpbmcgdG8gYmUgYWJsZSB0byBzYXkg4oCc4oCmdXNlIFJGQzY2MjHigJ0sIHRoZW4gdGhlIGlu dGVyZmFjZSBjb25maWd1cmF0aW9uIGNvbnN0cmFpbnRzIHdoZW4gZmFjZWQgd2l0aCBtdWx0aXBs ZSBpbnRlcmZhY2VzDQogbXVzdCBiZSB3b3JrZWQgb3V0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48dT5QcmVmaXhlcyAmYW1wOyBHYXRl d2F5czwvdT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BIHF1ZXN0aW9uIHRvIG15IG1pbmQsIGFuZCBJIGFtIG5vdCBzdXJlIEkga25vdyBo b3cgdG8gYW5zd2VyIHRoYXQgZnJvbSByZWFkaW5nIHRoZSBkcmFmdCBzaW5jZSBpdCBpcyBub3Qg ZGlzY3Vzc2VkIGluIHNlY3Rpb24gOSAoYXQgbGVhc3QpLCBpczog4oCcV2hhdCBoYXBwZW5zIGlm IEkgc2VuZCBhIFJSRVEgdG8gYSBwcmVmaXjigJ0gKGkuZS4sIGEgLyZsdDsxMjggaW4gSVB2Nik/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5vPHNwYW4gY2xhc3M9 ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5JZiB0aGUgd2hvbGUgcHJlZml4IGlzIHBhcnQgb2YgdGhl IGF0dGFjaGVkIG5ldHdvcmsgc2V0IG9mIGEgc2luZ2xlIHJvdXRlciwmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJh cHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCnRoZW4gSSBl eHBlY3QgdG8gZ2V0IGEgc2luZ2xlIFJSRVAgYmFjaywgaXMgdGhhdCB0aGUgY2FzZT88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPm88c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPklmICZxdW90O2hhbGYgdGhlIHByZWZpeCZxdW90OyAmbmJzcDtpcyBw YXJ0IG9mIHRoZSBhdHRhY2hlZCBuZXR3b3JrIHNldCBvZiBhIHNpbmdsZSByb3V0ZXIsJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ DQphbmQgdGhlIG90aGVyIGhhbGYgaXMgcGFydCBvZiB0aGUgYXR0YWNoZWQgbmV0d29yayBzZXQg b2YgYW5vdGhlciAmbmJzcDtzaW5nbGUgcm91dGVyLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1z cGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KdGhlbiBJIGV4cGVjdCB0d28g UlJFUHMsIGlzIHRoYXQgdGhlIGNhc2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj5vPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5Nb3JlIGdlbmVy YWxseSwgd2lsbCBJIGdldCBhIHRyZWUgYnVpbGQgdGhyb3VnaCB0aGUgbmV0d29yayBoZXJlPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QU9EVnYyIGN1cnJlbnRseSBkb2VzbuKAmXQgc3Vw cG9ydCBSUkVRcyBmb3IgcHJlZml4ZXMuIEnigJl2ZSBhbHJlYWR5IGFkZGVkIOKAnjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj5JZiBSdGVNc2cgaXMgYSBSUkVRLCBSdGVNc2cuVGFy Z1ByZWZpeExlbiBTSE9VTEQgZXF1YWwgYWRkcmVzcyBsZW5ndGguPC9zcGFuPuKAnCB0byBSdGVN c2cuVGFyZ1ByZWZpeExlbiBpbiBzZWN0aW9uJm5ic3A7PGEgbmFtZT0ic2VjdGlvbi00LjYiPjwv YT48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1h b2R2djItMTMjc2VjdGlvbi00LjYiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRl Y29yYXRpb246bm9uZSI+NC42PC9zcGFuPjwvYj48L2E+PGI+Lg0KIE11bHRpY2FzdCBSb3V0ZSBN ZXNzYWdlIFRhYmxlPC9iPiZuYnNwO2luIHJlc3BvbnNlIHRvIEp1c3RpbuKAmXMgY29tbWVudHMs IGJ1dCBJ4oCZbGwgZ28gdGhyb3VnaCB0aGUgZHJhZnQgYWdhaW4gYW5kIHNlZSB3aGVyZSB3ZSBu ZWVkIHRvIHN0YXRlIHRoaXMgbW9yZSBjbGVhcmx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Mb3R0ZSBTdGVlbmJyaW5rPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5TZWN0aW9uIDkgKG9yLCB0aGUgd2hvbGUgc3BlYykgaXMgYWxzbyBub3QgZXhwbGljaXQgZW5v dWdoIGFib3V0IG11bHRpcGxlICZuYnNwOyZxdW90O2RlZmF1bHQgZ2F0ZXdheXMmcXVvdDsg4oCU IGkuZS4sIHRoZSBleHRlcm5hbCBuZXR3b3JrIGJlaW5nIOKAnHRoZSByZXN0IG9mIHRoZSBJbnRl cm5ldOKAnSwgYW5kIHRoZXJlIGJlaW5nIG11bHRpcGxlIGdhdGV3YXlzIHRvIHRoZSBJbnRlcm5l dC4gSSB1bmRlcnN0YW5kIGhvdyB0aGUgUlJFUSBnZXRzDQogdG8gdGhlIGdhdGV3YXksIGFuZCBo b3cgdGhlIGdhdGV3YXkgZGV0ZXJtaW5lcyBpZiBpdCBzaG91bGQgcmVzcG9uZCAodGhlIGRlc3Rp bmF0aW9uIGlzIG5vdCBwYXJ0IG9mIOKAnHRoZSBNQU5FVCBwcmVmaXgsIHdpdGggd2hpY2ggaXQg aXMgY29uZmlndXJlZOKAnSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkJ1dCwgaWYgQSBpcyBjbG9zZSB0byBHVzEsIGFuZCBCIGlzIGNsb3Nl IHRvIEdXMiwgYnV0IEEgYW5kIEIgYmVpbmcgZmFyIGZhciBhcGFydCAoYWNjb3JkaW5nIHRvIHRo ZSBtZXRyaWMgdXNlZCkgd2l0aGluIHRoZSBNQU5FVCwgdGhlbiBpdCB3b3VsZCBiZSBwcmVmZXJl bnRpYWwgZm9yIHRoZSByb3V0ZSBmcm9tIEEgdG8gQiB0byBnbyB2aWEgR1cxLeKAnHRoZS1JbnRl cm5ldOKAnS1HVzI/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPklzIHRoaXMgYSBzdXBwb3J0ZWQgY29uZmlndXJhdGlvbj8mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5vPHNwYW4gY2xhc3M9ImFw cGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj5JZiB5ZXMsIGhvdyBpcyBpdCAoc2VxIyB3aXNlLCBJIHdvdWxk IGV4cGVjdCBzb21lIGNvbXBsaWNhdGlvbnMpIGhhbmRsZWQ/Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+bzxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+SWYgbm90LCB3aGVyZSBpcyBpdCBzdGF0ZWQgdGhhdCB0aGlzIGNvbmZpZ3VyYXRpb24g aXMgbm90IHBvc3NpYmxlIHdpdGggdGhpcyBwcm90b2NvbD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYXBwbGljYWJpbGl0eSBzdGF0 ZW1lbnQgc2F5czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0i cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4mbmJzcDsmbmJzcDsgQU9EVnYyIGlzIGRlc2lnbmVk IGZvciBzdHViIG9yIGRpc2Nvbm5lY3RlZCBtb2JpbGUgYWQgaG9jIG5ldHdvcmtzLDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPiZuYnNwOyZu YnNwOyBpLmUuLCBub24tdHJhbnNpdCBuZXR3b3JrcyBvciB0aG9zZSBub3QgY29ubmVjdGVkIHRv IHRoZSBpbnRlcm5ldC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj4mbmJzcDsmbmJzcDsgQU9EVnYyIGNhbiwgaG93ZXZlciwgYmUgY29uZmln dXJlZCB0byBwZXJmb3JtIGdhdGV3YXkgZnVuY3Rpb25zIHdoZW48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4mbmJzcDsmbmJzcDsgYXR0YWNo ZWQgdG8gZXh0ZXJuYWwgbmV0d29ya3MsIGFzIGRpc2N1c3NlZCBpbiA8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMjc2VjdGlvbi05 Ij5TZWN0aW9uIDk8L2E+LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgYmVsaWV2ZSB0aGF0IHRoZSBzY2VuYXJpbyBJIGRlc2NyaWJlIGlz IGluZGVlZCBhIHN0dWIgbmV0d29yayAoYW5kIG5vdCBhIHRyYW5zaXQgbmV0d29yayk/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAlCDigJQg 4oCUJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFzIEkgaW5kaWNhdGVkLCB0aGVzZSBhcmUgdGhlIGJpZy1waWN0dXJlIGlzc3VlcyB0 aGF0IEkgaGF2ZSBnb3R0ZW4gYXJvdW5kIHRvIHRoaW5raW5nIGFib3V0IGVub3VnaCB0byB3cml0 ZSB1cC4gSeKAmW0gbm90IHRocm91Z2ggd29ya2luZyB0aHJvdWdoIHRoZSBkb2N1bWVudCwgYnV0 IHRob3NlIHdlcmUgdGhlIG9uZXMgdGhhdCBjYW1lIHRvIG1pbmQsIGFuZCB3aGljaCBzZWVtIGlt cGVyYXRpdmUgdG8gcmVzb2x2ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvbWFzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwPioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPgpUaGlzIGVt YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQ8 YnI+CnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lz dGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+CllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3Ig dXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+CmRpc3RyaWJ1dGUgaXRz IGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uPGJyPgoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvcD48L2JvZHk+ DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923AF005GLKXM0002VGREEN_-- From nobody Wed Apr 20 05:49: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 0CB0F12D800 for ; Wed, 20 Apr 2016 05:49:01 -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 o6aHaKICgg63 for ; Wed, 20 Apr 2016 05:48:58 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7595912D52B for ; Wed, 20 Apr 2016 05:48:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VEfQg+VuqEixsECvWokG/Bi1gIPcQkOudwBu30O/8o3+ymqUQIgJBNLWgpfMCbz0; 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-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1asrYT-0000Gp-Av; Wed, 20 Apr 2016 08:48:29 -0400 To: Henning Rogge References: <571508C8.3030003@earthlink.net> <571536FC.5050407@earthlink.net> From: Charlie Perkins Message-ID: <57177A9A.90709@earthlink.net> Date: Wed, 20 Apr 2016 05:48:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7c8b8eddafe2818088e294679de2073f0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 20 Apr 2016 12:49:01 -0000 Hello Henning, It is wrong to require all metrics to be 32 bits. We already have a number of examples where 8 bit metrics work well. Regards, Charlie P. On 4/19/2016 10:49 PM, Henning Rogge wrote: > On Mon, Apr 18, 2016 at 9:35 PM, Charlie Perkins > wrote: >> Hello Abdussalam, >> >> Thanks for your support! >> >> I think that the link metric type table specified in the AODVv2 document >> should remain protocol-independent as much as possible. I also support the >> OLSRv2 strategy of using additive cost metrics insofar as is possible. > Then I would suggest to just copy the OLSRv2 strategy. > > Define a single PATH_METRIC TLV with a 32 bit unsigned integer inside. > This should work out for most (maybe even all) metrics and makes > AODVv2 and OLSRv2 link/path metric range compatible. > > A special deployment that needs to preserve a few more bytes could > work on a (transparent) compression scheme for the message format > later. > > Henning > From nobody Wed Apr 20 05:53: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 8053F12D540 for ; Wed, 20 Apr 2016 05:53:56 -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 5o8dzWIhONGC for ; Wed, 20 Apr 2016 05:53:55 -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 9F53B12B028 for ; Wed, 20 Apr 2016 05:53:54 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id j11so40254705lfb.1 for ; Wed, 20 Apr 2016 05:53: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:from:date:message-id:subject:to :cc; bh=HTGP5ZceCqzfICztLMfnHGYI0JvpK+LijuAkQOYkjyk=; b=IxJZ8SQVr7QhGmAU/YZmnqaa8Pxz9mONqH95P1bozs78OMJybE/5S2Vr/q1xrTXE/r EqU4io7lMyM4+gMiroLfQwT7SnvGRnMqxRGnek0wp9jLqTd8qhJpVryaiN2FT50/yPqB HCcSDtehfoJNUkc7DkyVrqU6piJmoiiGcf/0pZ33Wkj2gTLNfQa3F5Zout+p+tPrZzC2 //djgP6CBJNzQ/fBcx7c5RipBVPU4GlwmZztFawGoWCTGFqza7JM0II86i09mQtqhNkG Hmj46kkkOPsLX895zhAni8DzUstTRzAetm0PJ5ND72uhipV0ujCWRib5EmccrLDOd71p Ytxw== 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=HTGP5ZceCqzfICztLMfnHGYI0JvpK+LijuAkQOYkjyk=; b=HUzI3+5BnaL2rPoexhFk2Tc8dvWyqYn40VctEYnoq4yKBrdtGy8GavymAI/RNvJMj3 I2G2ni1wV/kprJSxev2e8P18oeXR5XoMrjDSRrwtATRi38rEf0DEdMfNXCjjx/eTA0lx r0VoV+bUV/vT48DX4iFunSSnxnqlWzRLHx4ZyFb7ySfE8v66lv8RSIvit2ysyYl6I1jt AJY4KJcc+dgVB1/jgFTvj1+k9pzkY/vlTf45m9XzYxC7crkhGwKr9cWDs4Eh3hCmfbPH 265T6hmNGMzccV7Ro5xJibZ1HQvpBert+ilDz5sZuO8UOF9w6A8EfRUAhcTssnDJIPxO pz5A== X-Gm-Message-State: AOPr4FULpTFw8fin86DKcV3NpXCDsgpMwZGFDupi2graaIAlzu9llT+PDv33MqBThe7y6edYC4BaXpQhSIQayA== X-Received: by 10.25.218.75 with SMTP id r72mr3586315lfg.139.1461156832872; Wed, 20 Apr 2016 05:53:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.24.42 with HTTP; Wed, 20 Apr 2016 05:53:23 -0700 (PDT) In-Reply-To: <57177A9A.90709@earthlink.net> References: <571508C8.3030003@earthlink.net> <571536FC.5050407@earthlink.net> <57177A9A.90709@earthlink.net> From: Henning Rogge Date: Wed, 20 Apr 2016 14:53:23 +0200 Message-ID: To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 20 Apr 2016 12:53:56 -0000 On Wed, Apr 20, 2016 at 2:48 PM, Charlie Perkins wrote: > Hello Henning, > > It is wrong to require all metrics to be 32 bits. We already have a number > of examples where 8 bit metrics work well. Of course you could say "metric value has variable length", but this would make a generic AODV2 implementation a pain in the ass. Ever done 17 byte additions? or 23 byte network-to-host byteorder conversion? If you want variable length, just keep this in mind (or only allow 1, 2 and 4 byte metric size). Henning From nobody Wed Apr 20 07:01:51 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 6999312EF1E for ; Wed, 20 Apr 2016 07:01:49 -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 zhs8oKlTZ9EX for ; Wed, 20 Apr 2016 07:01:43 -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 F281B12EF0E for ; Wed, 20 Apr 2016 07:01:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,509,1454976000"; d="scan'208";a="62639264" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 20 Apr 2016 15:01:41 +0100 X-IronPort-AV: E=Sophos;i="5.24,509,1454976000"; d="scan'208";a="114808037" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 20 Apr 2016 15:01:36 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0248.002; Wed, 20 Apr 2016 15:01:31 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , Charlie Perkins Thread-Topic: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics Thread-Index: AQHRmY5icHfeUArH5kuyP0m9D3y0IJ+QCMaAgAAGQQCAAj4LgIAAdOoAgAABYoCAACC6cA== Date: Wed, 20 Apr 2016 14:01:31 +0000 Message-ID: References: <571508C8.3030003@earthlink.net> <571536FC.5050407@earthlink.net> <57177A9A.90709@earthlink.net> 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: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 20 Apr 2016 14:01:49 -0000 I've half types and deleted two replies, one agreeing more with Henning tha= n Charlie, and one saying actually you can get the best of both worlds. But= halfway through the latter I decided it wasn't the best of both worlds but= a compromise. So on balance, all 32 bits is easier to implement, and avoid pretty much al= l problems. At a small overhead cost. On the other hand you could write cod= e that is mostly metric type unaware (isolating it to the corner - outside = and on the border of the routing protocol) despite having variable metric l= engths (all a multiple of 8 bits) because the length is carried in the TLV = - the L in fact. You'd rely on that matching your local decision, otherwise= fail. (The possibility of fail being one issue.) But I'm far from sold on = that. I thought about an approach that goes "all metric types are 32 bits". But i= f when I'm constructing my message I notice that all my metric values (per = TLV - so possibly just the one) can be sent in 1, 2 or 3 octets then I use = that. On reception I expand to 32 bits. I know at least one person here wil= l dislike that, and it has problems with the maximally immutable message ap= proach. Or in short, nothing is ideal. At this point I'd be very tempted to say get= something down, and the easiest something is always 32 bits. -- = 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 Henning Rogge Sent: 20 April 2016 13:53 To: Charlie Perkins Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 regi= stry for link metrics ----------------------! 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. On Wed, Apr 20, 2016 at 2:48 PM, Charlie Perkins wrote: > Hello Henning, > > It is wrong to require all metrics to be 32 bits. We already have a = > number of examples where 8 bit metrics work well. Of course you could say "metric value has variable length", but this would = make a generic AODV2 implementation a pain in the ass. Ever done 17 byte additions? or 23 byte network-to-host byteorder conversio= n? If you want variable length, just keep this in mind (or only allow 1, 2 and 4 byte metric size). Henning _______________________________________________ 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 Apr 20 07:16:00 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 BDDFA12D1B7 for ; Wed, 20 Apr 2016 07:15: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 fFwOKrO1Z2Sj for ; Wed, 20 Apr 2016 07:15:57 -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 7170512DD83 for ; Wed, 20 Apr 2016 07:15:57 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id 2so53499011ioy.1 for ; Wed, 20 Apr 2016 07:15:57 -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=bD/tbfeqcBHBDIUh6Rj2bDisx75V4tylc1XbsOu8GGQ=; b=afHug5NtvHm3Ukl7u0XViG3caXo+9/p2Sbu8JXYSla3rSQcgkLMUnQaVw26y30PvOa pjnWYxZNPAFXivMlILE3gnGt3YM+wHFCbQuBzQyB9uApw99ELVTi1lTY98+5IFWdnCPr Y8F/vYGd9vK5fOaaXGTz8el3g8pRS1Dfj9HeqZ+9v5cuBPJ/bCCBRgJW61tQGQfSGIBY t3nAZnWOmu6+J+E+K9tgGaLpzmico75HV5HtucnpxdFogafwRdTzWWtEwW3BSsRMDxiF WUEoCDJBaZPARwDkPrGcUsWZ5bfAQvSbIr/Xltz2we6O9xdLELr/LoVu3kVKKEuX+as4 bgnw== 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=bD/tbfeqcBHBDIUh6Rj2bDisx75V4tylc1XbsOu8GGQ=; b=C9kiOo7L0nk2Tx26UY/uoRvcBF7tTIw/xID0p9fMOgUck0ou5bC5g7XAMWAHvNOAbt UNIfm7QZDmGcook69bs8Bn2MAotPPG6JMwc5PL52ypW4rupk1QHcFcqbqZEq2wfWzYEN k0t/FC1yNkDeZYCCPqwwh/4M/8giHBjNFGXesIpt7xhVMF3Vn0HIhQm9R66JPRrwBZ4W FphLZAt0GkSAowPMxQTFFb4psxyPUvPS7boKneuwSIsBAp/nnxkDhH3ei7lq28+SierU W0TFkR5walnrGHpUZ2Em8DYwJeCTCnZVeffOxNAUibyLj/Z2zl/Z5/yNoNLYzDIRUC2z TsAg== X-Gm-Message-State: AOPr4FXI2gn/PBxnbkrJndgndVyzzKAgwuJOrc2nP6v1px8qm+GNePSJlShrAai0IPduwxPYVZtKgUeG1wHg2g== MIME-Version: 1.0 X-Received: by 10.107.173.69 with SMTP id w66mr11352646ioe.182.1461161756656; Wed, 20 Apr 2016 07:15:56 -0700 (PDT) Received: by 10.79.72.68 with HTTP; Wed, 20 Apr 2016 07:15:56 -0700 (PDT) In-Reply-To: References: <571508C8.3030003@earthlink.net> <571536FC.5050407@earthlink.net> <57177A9A.90709@earthlink.net> Date: Wed, 20 Apr 2016 10:15:56 -0400 Message-ID: From: Stan Ratliff To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a114464f4772f1f0530eb3bb6 Archived-At: Cc: Charlie Perkins , Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 20 Apr 2016 14:15:59 -0000 --001a114464f4772f1f0530eb3bb6 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 20, 2016 at 10:01 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: [snip] > Or in short, nothing is ideal. At this point I'd be very tempted to say > get something down, and the easiest something is always 32 bits. > > [snip] +1. Except I'm not "very tempted to say"; I'm just flat-out saying it: "Get something down, and the easiest something is always 32 bits." ;-) ;-) Regards, Stan --001a114464f4772f1f0530eb3bb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 20, 2016 at 10:01 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

=
[snip]=C2=A0
Or in short, nothing is ideal. At this point I'd be very tempted to say= get something down, and the easiest something is always 32 bits.

[snip]

+1.=C2=A0
E= xcept I'm not "very tempted to say"; I'm just flat-out sa= ying it: "Get something down, and the easiest something is always 32 b= its."
;-) ;-)

Regards,
Stan=C2= =A0
--001a114464f4772f1f0530eb3bb6-- From nobody Wed Apr 20 07:17: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 A75D112EF3F for ; Wed, 20 Apr 2016 07:17: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 naGXHh-ZyN-q for ; Wed, 20 Apr 2016 07:17:25 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 94ABA12E716 for ; Wed, 20 Apr 2016 07:17:25 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id n63so14737941qkf.0 for ; Wed, 20 Apr 2016 07:17:25 -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=Tkcwv82HYCtmiJL5z3ncSqR18fIJDvZK6rd0CJ5+vS4=; b=fw2i7OFXX//mOy7ZMpJ2dPlR7uapftUhe8mzu8ijT3acErhhLmfWYZw8Re9DYWa3aU OVR7nS68dixNX5lI4I6JFfJNh/UbhKEjJlFzM8sVovaCPewHFijjdP6s7MHXw0c5AcMw Ph70aw33ZUnRhyfjCslqxqor5zZsVL2nGIN1F72scKSWtoimFDj99gf8B3MOj5UDccwx 9ZRLJzNthBC0ImsirvIaJpmzFZaCIMF6Ttda+ZwkiMMUgU2doZ0tUjF/fdthU5Nn78Xq 40izB5lw97XWxZRWWH/Kaj5BR0dD/i1LulMjuhlrnC9dBT+Edx4YkvKydr4zHybcIj0C ikXA== 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=Tkcwv82HYCtmiJL5z3ncSqR18fIJDvZK6rd0CJ5+vS4=; b=LjnuXShAKZE1u37MbiWvUIRCMzjtrT1bSTpeKll5qIhyCwBW5qz4adFrNut4+nvuXw tOgYuyRksucQZe0y14NxejnARv10Ja/O6zusZcePqJPp2RKGMRV1G+nX5If3wJ0dP9Z+ 7qx/LydsXrXpSux1Un/PxDztJnjUE5QuYWQ02SQFGLsQYzKbG8IrT1i8jpdRDyPH/CMo A8bVyip0tSp7jK7rZG9W6pOgQAJ6Ao/o7nIVlybZ1ClWRAVHHtBITNe20Uxev8n0F4CY M8pqn6ZbekHyJ3hpDzdDVKaa5gg+ypdq+hSBpw3yBcJRenTvhfMsbOFP4oYM0iPU/dlp tYqA== X-Gm-Message-State: AOPr4FWhpENYGlRUDus/8NnWrbkVNAmw3W7XDWpf5w61miq1FgJKVMHy/E2QxAjwYr91RZ/FQU9ZeZ0VbSLJmg== MIME-Version: 1.0 X-Received: by 10.55.80.86 with SMTP id e83mr11543431qkb.91.1461161844620; Wed, 20 Apr 2016 07:17:24 -0700 (PDT) Received: by 10.140.43.131 with HTTP; Wed, 20 Apr 2016 07:17:24 -0700 (PDT) Date: Wed, 20 Apr 2016 16:17:24 +0200 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=001a114a6a96b543950530eb409b Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: [manet] Received Signal Weakness - RSW metric (was Re: Fwd: New Version Notification for draft-perkins-manet-rsw-00.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, 20 Apr 2016 14:17:27 -0000 --001a114a6a96b543950530eb409b Content-Type: text/plain; charset=UTF-8 Hi Charlie, This RSW is new metric, so I want to think of the RSW in different way and please give me your feedback, because maybe you thought about this and you have reasons to make it the way it is in the draft. We need to have a reference between strong/strength and weak/poor signal, let me name it the power threshold or reference P_ref. So the power level measurement is to be normalised between -1 and 1. This threshold can be determined by the subnet technology used. What you think if we change the measure idea to: In order to fit in eight bits, the received power measurement is normalized to be within the range from 0 to 1, where the minimum measurable power P_min maps to 1 (the highest cost value) and the maximum measurable power P_max maps to 0 (the lowest cost value). In other words, the measured received power P_meas maps to a normalized value P_norm = (P_max - P_meas) / (P_max - P_min). Change-to> In order to fit in eight bits, the received power measurement is normalized to be within the range from -1 to 1, where the minimum measurable power P_min maps to 1 (the highest cost value) and the maximum measurable power P_max maps to -1 (the lowest cost value). In other words, the measured received power P_meas maps to a normalized value P_norm = (P_ref - P_meas) / (P_max - P_min). AB On Tue, Apr 19, 2016 at 8:05 PM, Charles E. Perkins wrote: > Hello folks, > > This draft presents the RSW additive link metric from IEEE 802.15.10 along > with information about how to use it with AODVv2. > > It basically enables selection of a path with optimal signal strength. > > It is protocol-independent, and could be included as another metric in the > table of AODVv2 metrics, or used by other protocols such as OLSRv2. > > Regards, > Charlie P. > > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-perkins-manet-rsw-00.txt > Date: Mon, 18 Apr 2016 22:23:52 -0700 > From: internet-drafts@ietf.org > To: Charles E. Perkins > > A new version of I-D, draft-perkins-manet-rsw-00.txt > has been successfully submitted by Charles E. Perkins and posted to the > IETF repository. > > Name: draft-perkins-manet-rsw > Revision: 00 > Title: Received Signal Weakness (RSW) Metric > Document date: 2016-04-18 > Group: Individual Submission > Pages: 4 > URL: https://www.ietf.org/internet-drafts/draft-perkins-manet-rsw-00.txt > Status: https://datatracker.ietf.org/doc/draft-perkins-manet-rsw/ > Htmlized: https://tools.ietf.org/html/draft-perkins-manet-rsw-00 > > > Abstract: > The Received Signal Weakness (RSW) metric is a simple cost metric > that enables selection of a route with the high end-to-end signal > strength. > > > > > 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 > > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a114a6a96b543950530eb409b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Charlie,

This RSW is new metric,= so I want to think of the RSW in different way and please give me your fee= dback, because maybe you thought about this and you have reasons to make it= the way it is in the draft. We need to have a reference between strong/str= ength and weak/poor signal, let me name it the power threshold or reference= =C2=A0 P_ref. So the power level measurement is to be normalised between -1= and 1. This threshold can be determined by the subnet technology used.
=
What you think if we change the measure idea to:
 In order
   to fit in eight bits, the received power measurement is normalized to
   be within the range from 0 to 1, where the minimum measurable power
   P_min maps to 1 (the highest cost value) and the maximum measurable
   power P_max maps to 0 (the lowest cost value).  In other words, the
   measured received power P_meas maps to a normalized value P_norm =3D
   (P_max - P_meas) / (P_max - P_min).

Change-=
to>
 In order
   to fit in eight bits, the received power measurement is normalized to
   be within the range from -1 to 1, where the minimum measurable power
   P_min maps to 1 (the highest cost value) and the maximum measurable
   power P_max maps to -1 (the lowest cost value).  In other words, the
   measured received power P_meas maps to a normalized value P_norm =3D
   (P_ref - P_meas) / (P_max - P_min).

<= pre class=3D"">
AB


On Tue, Apr 19, 2016 at 8:05 PM, Ch= arles E. Perkins <charliep@computer.org> wrote:
=20 =20 =20
Hello folks,

This draft presents the RSW additive link metric from IEEE 802.15.10 along with information about how to use it with AODVv2.

It basically enables selection of a path with optimal signal strength.

It is protocol-independent, and could be included as another metric in the table of AODVv2 metrics, or used by other protocols such as OLSRv2.

Regards,
Charlie P.



-------- Forwarded Message --------
Subject: New Version Notification for draft-perkins-manet-rsw-00.txt
Date: Mon, 18 Apr 2016 22:23:52 -0700
From: internet-drafts@ietf.org
To: Charles E. Perkins <charliep@computer.org> 


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

Name:		draft-perkins-manet-rsw
Revision:	00
Title:		Received Signal Weakness (RSW) Metric
Document date:	2016-04-18
Group:		Individual Submission
Pages:		4
URL:            https://www.ietf.org/internet-drafts=
/draft-perkins-manet-rsw-00.txt
Status:         https://datatracker.ietf.org/doc/draft-perkins=
-manet-rsw/
Htmlized:       https://tools.ietf.org/html/draft-perkins-manet-r=
sw-00


Abstract:
   The Received Signal Weakness (RSW) metric is a simple cost metric
   that enables selection of a route with the high end-to-end signal
   strength.

                                                                           =
      =20


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.

The IETF Secretariat



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


--001a114a6a96b543950530eb409b-- From nobody Wed Apr 20 07:26:05 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 E4AFF12DE54 for ; Wed, 20 Apr 2016 07:26:03 -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 tEpmkcqL_iIv for ; Wed, 20 Apr 2016 07:26:01 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::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 0E52A12D843 for ; Wed, 20 Apr 2016 07:26:01 -0700 (PDT) Received: by mail-lb0-x236.google.com with SMTP id ys16so10292956lbb.3 for ; Wed, 20 Apr 2016 07:26:00 -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=iNg3ZHj7D8G52yf8ZjNqzuT8CorzzJmhJIN+5GCgH1Q=; b=P7A2oqE3qTaKpZYc2i8Y2CXuTWOMCfrED843L6izybD/ps5+vvXS8yS0TBnMlWI3b0 VxmpMZRwO4eTb8A7fQcTtwdLSpl9oA2J/OUCTC2qyOhjS1WxjGkcQqkR1kkGd/KCstxo zuEKt5N7zzLi/TmaILji0j1A0PJRqDqpmMW2eY4MklngpCbva2bRFHkCbaXT1HaIegST 99GuCBnI3GUK83sVbkXK9a+TUHG/Ida5cpzqD4QrNlNo+DDI0TAfMGGMbA6j1uh7ezY9 SBtrdZKnY+OD/TlKOAUYJJwB3XTHOUwJHsNf+4cE785ZMW28elpubqwU2kvgMxaACuCt Ni1A== 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=iNg3ZHj7D8G52yf8ZjNqzuT8CorzzJmhJIN+5GCgH1Q=; b=dFjnBP4SRKt8+W8rE+vvN6b2+sEyWVtXTFME/CyvOQbrDJAPAqZC3K/UqRbO9pPVYg VSyhWYCoc7KG9wf0cUyGbEBIxV5XAAqUAM+sYGqb+EfjQ565zpZxSS/f4M+j5EJp9yYV 91c7yb+ak6LmynFvBHhC/LwkXYCkRfYUKahqG2x8H0NRohRfPE+hksvgkxyLM0alWz41 eqIiEPtAUTTQRxRmRkW1BzdPgskqO/voWHk66ee3rl4mNXNEo930D0DDNKKBtJ4VQf6I 43G3P0RRxsChJ78Dju/T63Tmc6M3ueKhEyx5jD2blRzSfNSbn/HURGgE53f257rY9fdv FkSg== X-Gm-Message-State: AOPr4FU998jv7SccIkq+UtW9VCNWlykrt8BXfOttRrdgIbFBq2tlrNIyL0ZWAxi0V5brX4MnFQfPLlhJ7T9VVw== X-Received: by 10.112.84.105 with SMTP id x9mr3998099lby.23.1461162359066; Wed, 20 Apr 2016 07:25:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.24.42 with HTTP; Wed, 20 Apr 2016 07:25:29 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Wed, 20 Apr 2016 16:25:29 +0200 Message-ID: To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=001a1134d33c5f179f0530eb5fa0 Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Received Signal Weakness - RSW metric (was Re: Fwd: New Version Notification for draft-perkins-manet-rsw-00.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, 20 Apr 2016 14:26:04 -0000 --001a1134d33c5f179f0530eb5fa0 Content-Type: text/plain; charset=UTF-8 Hi, this makes no sense. You should check your math again, it doesn't work out. You waste range for no reason. Henning On Wed, Apr 20, 2016 at 4:17 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Charlie, > > This RSW is new metric, so I want to think of the RSW in different way and > please give me your feedback, because maybe you thought about this and you > have reasons to make it the way it is in the draft. We need to have a > reference between strong/strength and weak/poor signal, let me name it the > power threshold or reference P_ref. So the power level measurement is to > be normalised between -1 and 1. This threshold can be determined by the > subnet technology used. > > What you think if we change the measure idea to: > > In order > to fit in eight bits, the received power measurement is normalized to > be within the range from 0 to 1, where the minimum measurable power > P_min maps to 1 (the highest cost value) and the maximum measurable > power P_max maps to 0 (the lowest cost value). In other words, the > measured received power P_meas maps to a normalized value P_norm = > (P_max - P_meas) / (P_max - P_min). > > Change-to> > In order > to fit in eight bits, the received power measurement is normalized to > be within the range from -1 to 1, where the minimum measurable power > P_min maps to 1 (the highest cost value) and the maximum measurable > power P_max maps to -1 (the lowest cost value). In other words, the > measured received power P_meas maps to a normalized value P_norm = > (P_ref - P_meas) / (P_max - P_min). > > > > AB > > > > On Tue, Apr 19, 2016 at 8:05 PM, Charles E. Perkins > wrote: > >> Hello folks, >> >> This draft presents the RSW additive link metric from IEEE 802.15.10 >> along with information about how to use it with AODVv2. >> >> It basically enables selection of a path with optimal signal strength. >> >> It is protocol-independent, and could be included as another metric in >> the table of AODVv2 metrics, or used by other protocols such as OLSRv2. >> >> Regards, >> Charlie P. >> >> >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for draft-perkins-manet-rsw-00.txt >> Date: Mon, 18 Apr 2016 22:23:52 -0700 >> From: internet-drafts@ietf.org >> To: Charles E. Perkins >> >> A new version of I-D, draft-perkins-manet-rsw-00.txt >> has been successfully submitted by Charles E. Perkins and posted to the >> IETF repository. >> >> Name: draft-perkins-manet-rsw >> Revision: 00 >> Title: Received Signal Weakness (RSW) Metric >> Document date: 2016-04-18 >> Group: Individual Submission >> Pages: 4 >> URL: https://www.ietf.org/internet-drafts/draft-perkins-manet-rsw-00.txt >> Status: https://datatracker.ietf.org/doc/draft-perkins-manet-rsw/ >> Htmlized: https://tools.ietf.org/html/draft-perkins-manet-rsw-00 >> >> >> Abstract: >> The Received Signal Weakness (RSW) metric is a simple cost metric >> that enables selection of a route with the high end-to-end signal >> strength. >> >> >> >> >> 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 >> >> >> >> >> >> >> _______________________________________________ >> 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 > > --001a1134d33c5f179f0530eb5fa0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,<= /div>

this m= akes no sense.

You should check your math again, it doesn't work out. You was= te range for no reason.

Henning

On Wed, Apr 20, 2016 at 4:17 PM, Abdussalam Baryun = <abdussalambaryun@gmail.com> wrote:
Hi Charlie,

Thi= s RSW is new metric, so I want to think of the RSW in different way and ple= ase give me your feedback, because maybe you thought about this and you hav= e reasons to make it the way it is in the draft. We need to have a referenc= e between strong/strength and weak/poor signal, let me name it the power th= reshold or reference=C2=A0 P_ref. So the power level measurement is to be n= ormalised between -1 and 1. This threshold can be determined by the subnet = technology used.

What you think if we change the measure idea = to:
 In order
   to fit in eight bits, the received power measurement is normalized to
   be within the range from 0 to 1, where the minimum measurable power
   P_min maps to 1 (the highest cost value) and the maximum measurable
   power P_max maps to 0 (the lowest cost value).  In other words, the
   measured received power P_meas maps to a normalized value P_norm =3D
   (P_max - P_meas) / (P_max - P_min).

Change-to>
 =
In order
   to fit in eight bits, the received power measurement is normalized to
   be within the range from -1 to 1, where the minimum measurable power
   P_min maps to 1 (the highest cost value) and the maximum measurable
   power P_max maps to -1 (the lowest cost value).  In other words, the
   measured received power P_meas maps to a normalized value P_norm =3D
   (P_ref - P_meas) / (P_max - P_min).


AB


On Tue, Apr 19, 2016 at 8:05 PM, Charles E. Perkins <charliep@c=
omputer.org> wrote:

 =20

   =20
 =20
  

    Hello folks,

    

    This draft presents the RSW additive link metric from IEEE 802.15.10
    along with information about how to use it with AODVv2.

    

    It basically enables selection of a path with optimal signal
    strength.

    

    It is protocol-independent, and could be included as another metric
    in the table of AODVv2 metrics, or used by other protocols such as
    OLSRv2.

    

    Regards,

    Charlie P.

    

    


      

      -------- Forwarded Message --------
      

        
          

            Subject:
            
            New Version Notification for
              draft-perkins-manet-rsw-00.txt
          

          

            Date: 
            Mon, 18 Apr 2016 22:23:52 -0700
          

          

            From: 
            internet-drafts@ietf.org
          

          

            To: 
            Charles E. Perkins <charliep@computer.org>
          

        
      

      

      

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

Name:		draft-perkins-manet-rsw
Revision:	00
Title:		Received Signal Weakness (RSW) Metric
Document date:	2016-04-18
Group:		Individual Submission
Pages:		4
URL:            https://www.ietf.org/internet-drafts=
/draft-perkins-manet-rsw-00.txt
Status:         https://datatracker.ietf.org/doc/draft-perkins=
-manet-rsw/
Htmlized:       https://tools.ietf.org/html/draft-perkins-manet-r=
sw-00


Abstract:
   The Received Signal Weakness (RSW) metric is a simple cost metric
   that enables selection of a route with the high end-to-end signal
   strength.

                                                                           =
      =20


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.

The IETF Secretariat




      

    

    

  



_______________________________________________

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


--001a1134d33c5f179f0530eb5fa0-- From nobody Wed Apr 20 08:06: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 C20D512DE49 for ; Wed, 20 Apr 2016 08:06:01 -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 Q0iwJiOhND_h for ; Wed, 20 Apr 2016 08:06:00 -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 AAA0212DBDC for ; Wed, 20 Apr 2016 08:06:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7EFE9240996; Wed, 20 Apr 2016 08:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461164760; bh=qK8ujGIi6pPXCwjm+c1cRZogczp/Z4ycGhFqQfJW1rE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=kuxdLa2LAjozNv0bHjgEMNq1+inyFyBdRVGeOWP+zwmz0kz+OYFcdnd4I3FyS2Kyy d6R/jq1a2sSHlBFbj1MoThmJZKHqatIUD/v9n8a3KCGsJyJ9AxpB8+d+PTHrArwDaf KCcyBT3iuuuc1bYZK7M71GaP6rMDWvOIiLEw+zrs= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (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 6D1B02464D2; Wed, 20 Apr 2016 08:05:59 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_691A7AE4-81AF-443F-9191-E29964E7802B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: ietf@thomasclausen.org In-Reply-To: Date: Wed, 20 Apr 2016 17:05:57 +0200 Message-Id: References: <571508C8.3030003@earthlink.net> <571536FC.5050407@earthlink.net> <57177A9A.90709@earthlink.net> To: Stan Ratliff X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Charles Perkins , Christopher Dearlove , Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 20 Apr 2016 15:06:02 -0000 --Apple-Mail=_691A7AE4-81AF-443F-9191-E29964E7802B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 20, 2016, at 16:15, Stan Ratliff wrote: >=20 >=20 > On Wed, Apr 20, 2016 at 10:01 AM, Dearlove, Christopher (UK) = > = wrote: >=20 > [snip]=20 > Or in short, nothing is ideal. At this point I'd be very tempted to = say get something down, and the easiest something is always 32 bits. >=20 > [snip] >=20 > +1.=20 > Except I'm not "very tempted to say"; I'm just flat-out saying As WG chair, or as document author? > it: "Get something down, and the easiest something is always 32 bits." > ;-) ;-) >=20 Disagree. I posted, earlier today and in another thread, a proposal that = could be a (sort of) compromise. For sure, if all you need is an octet, = then you shouldn=E2=80=99t have to have 4 forced upon you, when there is = an alternative. --Apple-Mail=_691A7AE4-81AF-443F-9191-E29964E7802B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 20, 2016, at 16:15, Stan Ratliff <ratliffstan@gmail.com> wrote:


On Wed, Apr 20, 2016 at 10:01 AM, Dearlove, = Christopher (UK) <chris.dearlove@baesystems.com> wrote:

[snip] 
Or in short, nothing is ideal. At this point I'd be very tempted to say = get something down, and the easiest something is always 32 bits.

[snip]

+1. 
Except I'm not "very tempted to say"; I'm just flat-out = saying

As WG chair, or as document author?

it: "Get something down, and the = easiest something is always 32 bits."
;-) = ;-)


Disagree. I posted, earlier today and in another = thread, a proposal that could be a (sort of) compromise. For sure, if = all you need is an octet, then you shouldn=E2=80=99t have to have 4 = forced upon you, when there is an alternative.


= --Apple-Mail=_691A7AE4-81AF-443F-9191-E29964E7802B-- From nobody Wed Apr 20 08:19: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 B866D12F026 for ; Wed, 20 Apr 2016 08:19:47 -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 aKlea2mQXTMb for ; Wed, 20 Apr 2016 08:19:46 -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 E9BED12EF43 for ; Wed, 20 Apr 2016 08:15:53 -0700 (PDT) Received: by mail-ig0-x236.google.com with SMTP id f1so131114910igr.1 for ; Wed, 20 Apr 2016 08:15:53 -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=gr+nQCkKt471HOlwhajwg6K4GnPpS2yOEJw9ab1q/jM=; b=CdId9xQVFAnufKDdrp4n714tUt5vOulFEycP6o7oAUSlcX7Mq6NB4fCKLX2rqQ7XId hB7Vm5taTegb9RrDzTtIGuamq0EyLbxLGCoVaIk18jlqM6G5puXbwGi1NPtrrO2Tp0dC XWjg7oYnBGYJQj4rzxO9t+QrrYI+MIrQF7UbUDpSb7bUEkr7ycPovbd+I/tk9qmnZurW DZWQ5tS1fWATqpttpXpWVfeVkf0+doJ7Mz3mHL/uM4pIyPoy50M8KsOKNHPqtIi3jo7n 5IJAQe8MHpLRQM6/d+M0aIYsuqkYtpSg6mMHNnoslyYNsvBBe5Ss72eSPQzP7PacEvuD UYbw== 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=gr+nQCkKt471HOlwhajwg6K4GnPpS2yOEJw9ab1q/jM=; b=a25Ukv4HJ379bNMe3t075JNGvo+3jjQWW2zBH8YLwDSGCyYQ9BbvAUFD8ZGN2vZPKL zFoxupKJmVWB9505b29PKyTwoN8BRaJpPs623yTkV+16B1614VHulV+Wk2tv20Sw7fIF CxwakKEYrSYJHtB0997UKfavAjtE/+GLosLl/HRVwQQzFcukeRhCHEUgQsd4Y1TgGkYI Aim6McRik0XJp2zSVZKc21ooIudHqxwFLA73l5yaqORv4GyfyTRDIx4XMYbdZI7WrxvG VuxNW+2Vv7b6pJOMraHVAOjGZ8OKpyJ6/5rIaGnlzy9sDjc/MhAjnrkH0jw8maJFOx1N b3+A== X-Gm-Message-State: AOPr4FWdwiEVmSRsmB3RAINuA2gNT2Ev5LVHlzNnn/TGMUIBMNDH2rMcxhByo1kwS+Qo6nf3EA8QB4z/+6ec8g== MIME-Version: 1.0 X-Received: by 10.50.108.106 with SMTP id hj10mr4083012igb.36.1461165353236; Wed, 20 Apr 2016 08:15:53 -0700 (PDT) Received: by 10.79.72.68 with HTTP; Wed, 20 Apr 2016 08:15:53 -0700 (PDT) In-Reply-To: References: <571508C8.3030003@earthlink.net> <571536FC.5050407@earthlink.net> <57177A9A.90709@earthlink.net> Date: Wed, 20 Apr 2016 11:15:53 -0400 Message-ID: From: Stan Ratliff To: Thomas Clausen Content-Type: multipart/alternative; boundary=089e01536be6d681eb0530ec1177 Archived-At: Cc: Charles Perkins , Christopher Dearlove , Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 20 Apr 2016 15:19:47 -0000 --089e01536be6d681eb0530ec1177 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 20, 2016 at 11:05 AM, wrote: > > On Apr 20, 2016, at 16:15, Stan Ratliff wrote: > > > On Wed, Apr 20, 2016 at 10:01 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > [snip] > >> Or in short, nothing is ideal. At this point I'd be very tempted to say >> get something down, and the easiest something is always 32 bits. >> >> [snip] > > +1. > Except I'm not "very tempted to say"; I'm just flat-out saying > > > As WG chair, or as document author? > We've been through this. I've already explicitly recused myself from char duties with regard to AODVv2, Therefore, there is no need to do so on each and every email. > > it: "Get something down, and the easiest something is always 32 bits." > ;-) ;-) > > > Disagree. I posted, earlier today and in another thread, a proposal that > could be a (sort of) compromise. For sure, if all you need is an octet, > then you shouldn=E2=80=99t have to have 4 forced upon you, when there is = an > alternative. > Then I guess there's yet another item on which we disagree. Stan --089e01536be6d681eb0530ec1177 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 20, 2016 at 11:05 AM, <ietf@thomasclausen.org>= ; wrote:

On Apr 20, 2016, at 16:1= 5, Stan Ratliff <ratliffstan@gmail.com> wrote:


On Wed, Apr 20,= 2016 at 10:01 AM, Dearlove, Christopher (UK) <chris.dearlove@= baesystems.com> wrote:

[snip]=C2=A0
Or in short, nothing is ideal. At this point I'd be very tempted to say= get something down, and the easiest something is always 32 bits.

[snip]

+1.=C2=A0
E= xcept I'm not "very tempted to say"; I'm just flat-out sa= ying

As WG c= hair, or as document author?

We= 've been through this. I've already explicitly recused myself from = char duties with regard to AODVv2, Therefore, there is no need to do so on = each and every email.
=C2=A0
=

it: "Get something down, and the easiest something is always 3= 2 bits."
;-) ;-)


Disagree. I posted, earlier today and in= another thread, a proposal that could be a (sort of) compromise. For sure,= if all you need is an octet, then you shouldn=E2=80=99t have to have 4 for= ced upon you, when there is an alternative.
Then I guess there's yet another item on which we disagree= .=C2=A0

Stan
=C2=A0

--089e01536be6d681eb0530ec1177-- From nobody Wed Apr 20 08:40: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 8A0B012D790 for ; Wed, 20 Apr 2016 08:40:26 -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, NORMAL_HTTP_TO_IP=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 ll54ixtONIdn for ; Wed, 20 Apr 2016 08:40:22 -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 BE94C12D0F5 for ; Wed, 20 Apr 2016 08:33:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 397CB240828; Wed, 20 Apr 2016 08:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461166386; bh=8/iyC5NA1HKzPDxb4hClcOBap2AXlA6MedUnzLGmniM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=AamwEkPXOfciGXwddFfoO3/3qJJPb4q8XJezhrt1joY4Ut9UuGac0R1FtVLZOM4qt Um1bvm/k31EWSkKy0c2ceZv7jgemTtLNjVEKgUhzjYGr5GpgKU9Vk5wiQ1ZhELmPHj Zq8706DtFa4uM/wXFS7CNajya8c5Nec8xIV4OlmQ= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (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 94A9E240150; Wed, 20 Apr 2016 08:33:04 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0A99D2C6-3288-4F09-86FD-DB991DF1D4FA" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: ietf@thomasclausen.org In-Reply-To: Date: Wed, 20 Apr 2016 17:33:03 +0200 Message-Id: References: <20160405101903.773.31003.idtracker@ietfa.amsl.com> <8438BA85-DFC2-4192-84EE-999572C35FD1@fu-berlin.de> <04D7135E-8EDF-49DC-8978-3A1132FF3915@thomasclausen.org> <58FD3C84-52F7-4C5E-B2D0-607FB233524D@thomasclausen.org> <290B6546-9B1B-4554-93F9-8FBC6237D583@thomasclausen.org> To: Victoria Mercieca X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Christopher Dearlove , manet Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-14.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, 20 Apr 2016 15:40:26 -0000 --Apple-Mail=_0A99D2C6-3288-4F09-86FD-DB991DF1D4FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Victoria, Apologies for the delayed reply, I had a business lunch, and then a bit = of road to cover before I could sit down and type. > On Apr 20, 2016, at 11:50, Victoria Mercieca = wrote: >=20 > Hi Thomas, >=20 > See comments in line... >=20 >=20 > On Wed, Apr 20, 2016 at 10:02 AM, > wrote: > Hi, >=20 > Looking back over issues that I have raised, I am not sure that I saw = any replies to this, so I went looking in the I-D for some clarification = and some follow-up questions. >=20 > First, section 9 contains this throw-away comment: >=20 > Configuring the ENAR as a default router is outside the scope = of this > specification. >=20 > Either I do not understand what you mean by =E2=80=9C=E2=80=A6as a = default router=E2=80=A6=E2=80=9D or there=E2=80=99s a layer of = complexity (that I can guess at) which you=E2=80=99re not telling, but = which really should be called out.=20 >=20 > My guess would be, that a router inside the MANET will need to = communicate to (say) google, you would do a Route Discovery (RREQ/RREP) = cycle and the ENAR would return a route to 2a00:1450:4007:80e::2003 =E2=80= =94 and then when you 30s later need to communicate to (say) = Facebook.com you would do a Route Discovery = (RREQ/RREP) cycle and the ENAR would return a route to = 2a03:2880:20:4f22:face:b00c::25de.=20 >=20 > I.e. the =E2=80=9C=E2=80=A6as default router=E2=80=A6=E2=80=9D means = that you do not know of any way of making it work such that the ENER an = reply, to the first of these two, with simply 0::0/0, and then have the = routers in the MANET install a route via the ENAR to destinations not = inside the MANET? >=20 > What I am getting at here is, that if I understand correctly then = connectivity to =E2=80=9Cthe Internet=E2=80=9D is very, very = inefficiently supported =E2=80=94 or, actually, more precisely that = connectivity to any =E2=80=9Cexternal network which can only be captured = by a prefix which also includes destinations inside the MANET=E2=80=9D = is very inefficiently supported (because you cannot install prefix = routes to such a network). >=20 > If I am understanding this correctly, then it deserves more = elaboration than the throw-away mention at the end of Section 9, cited = above, and certainly this paragraph from the applicability statement = needs to correctly reflect it: >=20 > AODVv2 is designed for stub or disconnected mobile ad hoc networks, > i.e., non-transit networks or those not connected to the internet. > AODVv2 can, however, be configured to perform gateway functions = when > attached to external networks, as discussed in Section 9. >=20 > Second, section 7.1 specifies for RREQs: >=20 > AddressList > Contains OrigAddr and TargAddr, the source and = destination > addresses of the IP packet for which a route is = requested. > OrigAddr and TargAddr MUST be routable unicast = addresses. >=20 >=20 > Again, if I have understood correctly, if a router has 255 hosts = attached (say a /56), each of which need to communicate with a server, = then the router must end up generating 255 RREQ/RREP cycles, even though = it may already have an entry for the IP address for the server? >=20 >=20 > No. While OrigAddr and TargAddr are the source and destination = addresses of the IP packet for which a route is requested, we also = include in a RREQ the prefix length for OrigAddr, which is the prefix = length as seen in the corresponding Router Client entry on RREQ_Gen. So, = any routers receiving the RREQ learn a route to the whole prefix.=20 >=20 > This is what happens: > 1) packet arrives e.g. from source 10.0.0.1 and to destination = 20.0.0.2 > 2) router has no route to 20.0.0.2 > 3) router matches source address 10.0.0.0 to router client entry = 10.0.0.0/8 (therefore will send a RREQ) > 4) router creates RREQ using OrigAddr =3D 10.0.0.1 and OrigPrefixLen =3D= 8. > 5) receiving routers learn route to 10.0.0.0/8 . >=20 So that=E2=80=99s the good news =E2=80=94 glad to read that, thank you = for that explanation. Now, why did that not jump out at me when I read through the document, = either in a protocol overview sorta section, or in the =E2=80=9Cgateway = to external networks=E2=80=9D sorta section? That would be the sort that = definitely should be called out. > However, because initially you have this single IP packet with a = specific destination IP address, you can't intentionally send a RREQ for = the whole prefix associated with TargAddr. But the route you get back in = a RREP has TargAddr and TargPrefixLen (which corresponds to the router = client entry at RREP_Gen), which combined represents the route to the = prefix TargAddr is part of, which is what gets installed at each router = receiving the RREP. I do not like that asymmetry, though, but that may be because I have = IPv6 on my mind here: a host, which is sitting behind a router, will be = on a link - with said link have a /64. If, by some magic, I know that I = will need to talk to (more than one destination on) =E2=80=9Cthat = link=E2=80=9D, then it=E2=80=99s somewhat counterintuitive to have to = send an RREQ to a random address from within that link, hoping that the = router will respond. =20 > Perhaps this would be clearer, if instead of including the data = packet's source IP address as the OrigAddr in a RREQ, we used the = corresponding router client entry as OrigAddr? > Step 4 above would become: > 4) router creates RREQ using OrigAddr =3D 10.0.0.0 and OrigPrefixLen =3D= 8. > Similarly for RREP and TargAddr. =20 > Perhaps to make it completely clear, we could rename OrigAddr to = OrigPrefix in a RREQ, and TargAddr to TargPrefix in a RREP. So the RREQ = contains OrigPrefix, OrigPrefixLen and TargAddr. And the RREP contains = OrigPrefix, OrigPrefixLen, TargPrefix, TargPrefixLen. > What do you think of this suggestion? If I understand correctly (the =E2=80=9CRouter Client=E2=80=9D = terminology remains extremely confusing), then the host (a /128) = connected to a router with a link with a prefix (a p/64), is represented = by an =E2=80=9Centry=E2=80=9D (p/64) in the router?. So you suggest to = send p/64 as OrigAddr in place of the /128 (in which case that likely = should be OrigPrefix?=20 That, at least, would make it a lot clearer what actually happens, = especially in intermediate routers who install a reverse route back to = the OrigAddr (OrigPrefix). > This links in to the gateway question=E2=80=A6 Well, in a sense, IPv6 makes the router =E2=80=9Cby default=E2=80=9D a = gateway to an external, non-/128 prefix, so =E2=80=A6 ;) > I think the ENAR could potentially respond to a route request for an = external address by sending a RREP containing the default route. It's = equivalent to the requested TargAddr being part of a router client entry = for a prefix on RREP_Gen. Using the current rules, the ENAR would = attempt to send a RREP with TargAddr set to match TargAddr in the RREQ, = and TargPrefixLen of 0. TargPrefixLen of 0? Should that not be of 128 (a host route is a /128)? = Well, I guess TargPrefixLen of 0 would make any advertisement into =E2=80=9C= a default route=E2=80=9D, but I like the below (advertising 0/0) better. > Even if the RREP contained TargAddr =3D 0.0.0.0 and TargPrefixLen of = 0, RREQ_Gen could still match this with the RREQ it had sent and = consider the route request fulfilled. Do you see a problem with this? We = would need to update the wording and the current use of Prefix Length, = since we currently interpret a prefix length of 0, and also the omission = of prefix length value, to mean the full address length. Hm, I think that something like that could work in terms of advertising = a gateway into the network. The problem would be, how would you treat = that on the router? Installing 0/0 into the FIB would cause your router = to never send RREQs again ;)=20 You would have to be keeping the 0/0 in your RIB, when getting a FIB = miss then =E2=80=9Clook in if this destination is expected = to be inside the MANET=E2=80=9D and unless that tells you = =E2=80=9Cno, it isn't=E2=80=9D, could you use the 0/0 entry.=20 But then again, the destination *could* still be reachable as a = =E2=80=9Clocally attached network=E2=80=9D to another router (say, your = laptop) which I could reach within the MANET =E2=80=94 but also, via = Lotte=E2=80=99s laptop which is advertising 0/0. So I guess my conclusion is: YES, but with some verbiage framing the = addressing model (=E2=80=9CThe MANET has a prefix p::/$LENGTH. All = destinations within that prefix are inside the MANET and a router MUST = NOT use a 0/0 prefix for reaching them. All other prefixes are fair = game=E2=80=9D). I don=E2=80=99t think that it=E2=80=99s necessary to document *all* = addressing models that *could* work in the next revision, but this would = be a fantastic thing to get started addressing. What=E2=80=99s in the = doc doesn=E2=80=99t really do much. This does something, subject to = refinement as we go along? And even better, I *think* that it can be generalized to the case = (Lotte=E2=80=99s Laptop) mentioned above, although I have not thought = that through completely. Very glad that we=E2=80=99re seeing progress on gateways, finally, thank = you for taking this up. Best, Thomas >=20 > Kind Regards, > Victoria. >=20 >=20 > The reason why I speculate that this is so is, that RREQ forwarding = installs the =E2=80=9Creverse route=E2=80=9D towards the source, and if = OrigAddr is "the source addresses of the IP packet for which a route is = requested=E2=80=9D address, i.e., there is no way for the RREQ to = request a route to the server =E2=80=9Cat once=E2=80=9D on behalf of = "the entire /56=E2=80=9D behind it? >=20 > Again, if I am understanding this correctly, then it deserves a bit = more elaboration, notably a framing of the cases discussed in the above, = and a modulation of the statement from the applicability statement that: >=20 > AODVv2 can, however, be configured to perform gateway functions = when > attached to external networks, as discussed in=20 > Section 9. >=20 > Capturing these limitations of gateway functionality? >=20 > The same, probably, also applies in the opposite direction, i.e., in = case a single =E2=80=9Csource=E2=80=9D needs to communicate with many or = all of a /56, behind a router? >=20 > Best, >=20 > Thomas >=20 >=20 >> On 07 Apr 2016, at 23:11, Thomas Heide Clausen = > wrote: >>=20 >> On this whole gateway issue, I am disturbed...most routers would have = one-or-multiple /64-or-shorter, one per non-Manet link (w/ hosts hanging = off) delegated to them, and not just a single /128. >>=20 >> Needing to communicate with many-to-all hosts on a link is not = uncommon (if the hosts are, e.g., environmental controls in the same = room), and the ability to "get the whole prefix advertised at once" send = an RREQ for the whole prefix - specifically, for not=20 >>=20 >> Sent from my iPad >>=20 >> On 07 Apr 2016, at 22:19, Christopher Dearlove = > = wrote: >>=20 >>> Thanks, that addresses most of the points I made. >>>=20 >>> Assuming that is that a packet reception for forwarding is the only = option you choose to allow. It's perfectly reasonable for an = implementation to think "wouldn't it be sensible to learn about a = gateway now for various reasons?". Yes, there's the problem of which = subnet to look for (0.0.0.0/0 or something smaller). = Yes, I can imagine you don't want to define this now - unless of course = someone in the WG says they really want it. But I would say, don't close = the door on it, even if not doing it now. >>>=20 >>> (There are other possibilities that might be useful one day. An RREQ = that looks for more than one address for example - you could trade = latency and overhead by combining RREQs.) >>>=20 >>> -- =20 >>> Christopher Dearlove >>> christopher.dearlove@gmail.com = (iPhone) >>> chris@mnemosyne.demon.co.uk = (home) >>>=20 >>> On 7 Apr 2016, at 18:49, Victoria Mercieca > wrote: >>>=20 >>>> Hi Christopher, >>>>=20 >>>> On 7 Apr 2016 1:55 pm, "Christopher Dearlove" = > = wrote: >>>> > >>>> > [This time from a subscribed address.] >>>> > >>>> > You say you've added a sentence saying AODVv2 doesn't do RREQs = for gateways. What should have happened is a discussion on this list as = to why? is that hard? does anyone have a clever idea to make it not = hard? does anyone need that functionality? and so on. >>>> > >>>> > For example, here's something that superficially looks like it = might work. Does it, or does it introduce new problems? I don't know. = But this, and likely better ideas, just haven't had discussion here - = and I fear that the people who might have the better ideas have departed = unheard. >>>> > >>>> > So, a router wants a route to a.b.c.d, and sends an RREQ for that = (/32, or simply omit). Of course any router directly serving that = address just replies. But a router that is serving a.0.0.0/8 could reply = with that address. The originating router of course would use standard = IP maximum prefix length rules. Does that work? Does it help anyone? = Could a router reply a.b.c.d/32 and a.0.0.0/8 in one RREP? Or could it = be allowed to reply a.b.c.d/8 as a shorthand? >>>>=20 >>>> This is exactly what it does (based on the router client entry = corresponding to TargAddr, e.g if router client entry is a.0.0.0/8, then = the RREP contains a.b.c.d/8). Everyone receiving the RREP can then = install the route to a.0.0.0/8 and therefore avoid a separate RREQ for = (as an example) a.b.c.e in future. Similarly an RREQ contains the prefix = length associated with the router client entry configured for OrigAddr, = and routers processing the RREQ learn the route to OrigAddrs prefix. >>>>=20 >>>> But you can't intentionally send a RREQ for a prefix because the = RREQ is created when there's a packet to send, you know the destination = address not the prefix associated with it, so TargAddr is a.b.c.d/32. = But even so, you do end up learning a route to a prefix, if TargAddr is = part of a router client entry which is a prefix. >>>>=20 >>>> Kind regards, >>>> Victoria.=20 >>>>=20 >>>> > And why can't a router request a.b.0.0/16 - and possibly get an = a.0.0.0/8 reply? >>>> > >>>> > Answers to all of those is "I don't know". But we should have = been having those discussions. >>>> > >>>> > --=20 >>>> > Christopher Dearlove >>>> >=C2=A0christopher.dearlove@gmail.com = >>>> > >>>> > >>>> > >>>> > -- =20 >>>> > Christopher Dearlove >>>> >=C2=A0christopher.dearlove@gmail.com = (iPhone) >>>> >=C2=A0chris@mnemosyne.demon.co.uk = (home) >>>> > On 7 Apr 2016, at 15:49, Lotte Steenbrink = > = wrote: >>>> > >>>> >> Hi Thomas, >>>> >> >>>> >>> Am 05.04.2016 um 20:07 schrieb=C2=A0ietf@thomasclausen.org = : >>>> >>> >>>> >>> Lotte, >>>> >>> >>>> >>> Thank you for this update. An impressive amount of changes to = the document, according to RFCdiff, and as I can see from your mail that = there is much more to come, >>>> >> >>>> >> >>>> >> Thanks! I=E2=80=99m glad you=E2=80=99re seeing the progress = we=E2=80=99ve made.=20 >>>> >> >>>> >>> I hope that you forgive me for not jumping at a blow-by-blow = review until a version which the authors themselves consider stable, is = produced. >>>> >>> >>>> >>> On the point of =E2=80=9Cmuch more to come", there have been = quite a few comments raised by WG participants other than Mr. Dean and = Chris (such as by myself, but not only) =E2=80=94 some of which = intersect some of the below, and for which I do not believe that a = satisfactory resolution has been developed, presented to the WG, and = confirmed. >>>> >> >>>> >> >>>> >> I=E2=80=99m not quite sure which comments exactly you are = referring to? Your last comments that come to mind are the ones in these = threads: >>>> >> >>>> = >>=C2=A0https://www.ietf.org/mail-archive/web/manet/current/msg18055.html = >>>> = >>=C2=A0https://www.ietf.org/mail-archive/web/manet/current/msg18639.html = >>>> >> >>>> >> You=E2=80=99ve announced to go through the former in your last = response to the latter, but as far as I can see you haven=E2=80=99t = gotten round to doing that and a lot of points you=E2=80=99ve brought up = have sparked ongoing discussions, so I=E2=80=99ve marked most of your = comments as =E2=80=9Cpending=E2=80=93 still in discussion=E2=80=9D in my = mind.=20 >>>> >> Regarding the points you brought up that aren=E2=80=99t affected = by this: >>>> >> >>>> >> * Metrics=E2=80=93 we=E2=80=99ve had discussions about this many = moons ago with authors on both sides of the fence. Unfortunately I = can=E2=80=99t remember the counter arguments, and I=E2=80=99m still = looking for records of this conversation=E2=80=A6 I=E2=80=99ll get back = to you when I=E2=80=99ve found out more. >>>> >> * Prefixes & Gateways: I=E2=80=99ve added a sentence to clarify = that AODVv2 doesn=E2=80=99t do RREQs for gateways, I hop that helps? >>>> >> >>>> >>> >>>> >>> In which revision of the I-D do you plan on addressing those? >>>> >>> >>>> >> >>>> >> If the discussions reach a conclusion by then, I=E2=80=99d be = glad to have them addressed by the next revision. >>>> >> >>>> >> Best regards, >>>> >> Lotte >>>> >> >>>> >>> Best, >>>> >>> >>>> >>> Thomas >>>> >>> >>>> >>> >>>> >>> >>>> >>>> On Apr 5, 2016, at 12:53, Lotte Steenbrink = > = wrote: >>>> >>>> >>>> >>>> Hi all, >>>> >>>> just a quick summary of what is and what isn=E2=80=99t = included in this update of the draft: >>>> >>>> >>>> >>>> DONE: >>>> >>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>>> >>>> * All JWD! comments (i.e. the critical ones) are resolved >>>> >>>> * Out of 90 JWD and JWD! comments, 61 are resolved >>>> >>>> * The revised security considerations [1] were added (with the = TODOs commented out) >>>> >>>> * The following TODO from [1] was resolved:=20 >>>> >>>> "This description MUST >>>> >>>> include the reasons it was either unreasonable or out of = scope to >>>> >>>> attempt to avoid these denial of service attacks." >>>> >>>> * Section 9 now contains a statement that AODVv2 doesn=E2=80=99t= support RREQs for prefixes, I hope that clears things up for Thomas. >>>> >>>> >>>> >>>> TO DO: >>>> >>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=20 >>>> >>>> * Most notable of the 29 JWDs that are yet to be resolved: >>>> >>>> + (is there some table that lists routes that are being waited = on? JWD) We decided to add a separate=20 >>>> >>>> RREP table that lists them and I=E2=80=99ve = volunteered to write text for that, but we=E2=80=99re currently = discussing if/how >>>> >>>> we might solve this without adding yet another = table. >>>> >>>> >>>> >>>> + We=E2=80=99re currently discussing the approaching the limit = thing. (i.e. >>>> >>>> (There is no defined behavior here. Approaching the limit? = Section 6.5 outlines which messages are more important but now how to = decide to allow them to be transmitted or not. JWD=20 >>>> >>>> and >>>> >>>> (The undefined approaching the limit thing again JWD) etc >>>> >>>> We=E2=80=99ve already clarified the wording = regarding what the limit is and how to prioritize the message types,=20 >>>> >>>> what=E2=80=99s left is to define what = =E2=80=9Eapproaching=E2=80=9C means (and whether we need to talk about = approaching rather than >>>> >>>> just saying =E2=80=9Ehere=E2=80=99s what to do when = you actually hit the limit"). >>>> >>>> >>>> >>>> + (I don=E2=80=99t want to spam the list with a = comprehensive list of all of them, but if you=E2=80=99re interested in = seeing them, >>>> >>>> please do say so and I=E2=80=99ll send my copy of = Justin=E2=80=99s review containing all TODOs and DONEs to the list) >>>> >>>> * some TODOs in security considerations (see [1]) >>>> >>>> * since we're waiting for Chris=E2=80=99 feedback regarding = the revised 5444 multiplexer wording, that hasn=E2=80=99t changed yet. >>>> >>>> >>>> >>>> More details can be found in Appendix A. AODVv2 Draft = Updates, as well as the diff, of course. >>>> >>>> >>>> >>>> Best regards, >>>> >>>> Lotte >>>> >>>> >>>> >>>> [1] Re: [manet] AODVv2: Security considerations update = https://www.ietf.org/mail-archive/web/manet/current/msg18458.html = >>>> >>>> >>>> >>>> >>>> >>>>> Am 05.04.2016 um 12:19 schrieb internet-drafts@ietf.org = : >>>> >>>>> >>>> >>>>> >>>> >>>>> 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-14.txt >>>> >>>>> Pages : 80 >>>> >>>>> Date : 2016-04-05 >>>> >>>>> >>>> >>>>> 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: >>>> >>>>>=C2=A0https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2/ = >>>> >>>>> >>>> >>>>> There's also a htmlized version available at: >>>> >>>>>=C2=A0https://tools.ietf.org/html/draft-ietf-manet-aodvv2-14 = >>>> >>>>> >>>> >>>>> A diff from the previous version is available at: >>>> >>>>>=C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv= 2-14 >>>> >>>>> >>>> >>>>> >>>> >>>>> Please note that it may take a couple of minutes from the = time of submission >>>> >>>>> until the htmlized version and diff are available = at=C2=A0tools.ietf.org . >>>> >>>>> >>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>> >>>>>=C2=A0ftp://ftp.ietf.org/internet-drafts/ = >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> manet mailing list >>>> >>>>>=C2=A0manet@ietf.org >>>> >>>>>=C2=A0https://www.ietf.org/mailman/listinfo/manet = >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> manet mailing list >>>> >>>>=C2=A0manet@ietf.org >>>> >>>>=C2=A0https://www.ietf.org/mailman/listinfo/manet = >>>> >>> >>>> >>> >>>> >> >>>> >> _______________________________________________ >>>> >> manet mailing list >>>> >>=C2=A0manet@ietf.org >>>> >>=C2=A0https://www.ietf.org/mailman/listinfo/manet = >>>> > >>>> > >>>> > _______________________________________________ >>>> > manet mailing list >>>> >=C2=A0manet@ietf.org >>>> >=C2=A0https://www.ietf.org/mailman/listinfo/manet = _____________________________= __________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet = --Apple-Mail=_0A99D2C6-3288-4F09-86FD-DB991DF1D4FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Victoria,

Apologies for the delayed reply, I had a business lunch, and = then a bit of road to cover before I could sit down and type.

On Apr 20, 2016, at 11:50, Victoria Mercieca = <vmercieca0@gmail.com> wrote:

Hi = Thomas,

See comments in line...


On Wed, Apr 20, 2016 at 10:02 AM,  <ietf@thomasclausen.org> wrote:
Hi,

Looking back over issues that I have = raised, I am not sure that I saw any replies to this, so I went looking = in the I-D for some clarification and some follow-up = questions.

First, section 9 contains this throw-away = comment:

   Configuring the ENAR as a default = router is outside the scope of this
  =  specification.

Either I do not understand what you mean by =E2=80=9C=E2=80=A6a= s a default router=E2=80=A6=E2=80=9D or there=E2=80=99s a layer of = complexity (that I can guess at) which you=E2=80=99re not telling, but = which really should be called out. 

My guess would be, that a router inside = the MANET will need to communicate to (say) google, you would do a Route = Discovery (RREQ/RREP) cycle and the ENAR would return a route to =  2a00:1450:4007:80e::2003 =E2=80=94 and then when = you 30s later need to communicate to (say) Facebook.com you would do a Route = Discovery (RREQ/RREP) cycle and the ENAR would return a route = to 2a03:2880:20:4f22:face:b00c::25de. 

I.e. the =E2=80=9C=E2=80=A6= as default router=E2=80=A6=E2=80=9D means that you do not know of any = way of making it work such that the ENER an reply, to the first of these = two, with simply 0::0/0, and then have the routers in the MANET install = a route via the ENAR to destinations not inside the MANET?

What I am getting at = here is, that if I understand correctly then connectivity to =E2=80=9Cthe = Internet=E2=80=9D is very, very inefficiently supported =E2=80=94 or, = actually, more precisely that connectivity to any =E2=80=9Cexternal = network which can only be captured by a prefix which also includes = destinations inside the MANET=E2=80=9D is very inefficiently supported = (because you cannot install prefix routes to such a network).

If I am understanding = this correctly, then it deserves more elaboration than the throw-away = mention at the end of Section 9, cited above, and certainly this = paragraph from the applicability statement needs to correctly reflect = it:

   AODVv2 is designed for stub or disconnected = mobile ad hoc networks,
   i.e., = non-transit networks or those not connected to the internet.
   AODVv2 can, however, be configured to perform = gateway functions when
   attached to = external networks, as discussed in Section 9.

Second, section 7.1 specifies for = RREQs:

=    AddressList
  =     Contains = OrigAddr and TargAddr, the source and destination
=       addresses of the IP packet = for which a route is requested.
  =     OrigAddr = and TargAddr MUST be routable unicast addresses.


Again, if I have understood correctly, if a router has 255 = hosts attached (say a /56), each of which need to communicate with a = server, then the router must end up generating 255 RREQ/RREP cycles, = even though it may already have an entry for the IP address for the = server?


No. While OrigAddr and TargAddr are the source and = destination addresses of the IP packet for which a route is requested, = we also include in a RREQ the prefix length for OrigAddr, which is the = prefix length as seen in the corresponding Router Client entry on = RREQ_Gen. So, any routers receiving the RREQ learn a route to the whole = prefix. 

This is = what happens:
1) packet arrives e.g. from source 10.0.0.1 = and to destination 20.0.0.2
2) router has = no route to 20.0.0.2
3) router matches source address = 10.0.0.0 to router client entry 10.0.0.0/8 (therefore will send a = RREQ)
4) router creates RREQ using OrigAddr =3D = 10.0.0.1 and OrigPrefixLen =3D 8.
5) = receiving routers learn route to 10.0.0.0/8.


So that=E2=80=99s the good news =E2=80=94 glad to read = that, thank you for that explanation.

Now, why did that not jump out at me when I read = through the document, either in a protocol overview sorta section, or in = the =E2=80=9Cgateway to external networks=E2=80=9D sorta section? That = would be the sort that definitely should be called out.

However, = because initially you have this single IP packet with a specific = destination IP address, you can't intentionally send a RREQ for the = whole prefix associated with TargAddr. But the route you get back in a = RREP has TargAddr and TargPrefixLen (which corresponds to the router = client entry at RREP_Gen), which combined represents the route to the = prefix TargAddr is part of, which is what gets installed at each router = receiving the RREP.

I do not like that asymmetry, though, but that may be = because I have IPv6 on my mind here: a host, which is sitting behind a = router, will be on a link - with said link have a /64. If, by some = magic, I know that I will need to talk to (more than one destination on) = =E2=80=9Cthat link=E2=80=9D, then it=E2=80=99s somewhat counterintuitive = to have to send an RREQ to a random address from within that link, = hoping that the router will respond.
 
Perhaps = this would be clearer, if instead of including the data packet's source = IP address as the OrigAddr in a RREQ, we used the corresponding router = client entry as = OrigAddr?
Step 4 = above would become:
4) router creates RREQ using OrigAddr = =3D 10.0.0.0 and OrigPrefixLen =3D 8.
Similarly for RREP and TargAddr.  
Perhaps to = make it completely clear, we could rename OrigAddr to OrigPrefix in a = RREQ, and TargAddr to TargPrefix in a RREP. So the RREQ contains = OrigPrefix, OrigPrefixLen and TargAddr. And the RREP contains = OrigPrefix, OrigPrefixLen, TargPrefix, TargPrefixLen.
What = do you think of this suggestion?

If I understand correctly (the =E2=80=9CRouter = Client=E2=80=9D terminology remains extremely confusing), then the host = (a /128) connected to a router with a link with a prefix (a p/64), is = represented by an =E2=80=9Centry=E2=80=9D (p/64) in the router?. So you = suggest to  send p/64 as OrigAddr in place of the /128 (in which = case that likely should be OrigPrefix? 

That, at least, would make it a lot clearer what = actually happens, especially in intermediate routers who install a = reverse route back to the OrigAddr (OrigPrefix).

This = links in to the gateway = question=E2=80=A6

Well, in a sense, IPv6 makes the router =E2=80=9Cby = default=E2=80=9D a gateway to an external, non-/128 prefix, so =E2=80=A6 = ;)

I think = the ENAR could potentially respond to a route request for an external = address by sending a RREP containing the default route. It's equivalent = to the requested TargAddr being part of a router client entry for a = prefix on RREP_Gen. Using the current rules, the ENAR would attempt to = send a RREP with TargAddr set to match TargAddr in the RREQ, and = TargPrefixLen of 0.

TargPrefixLen of 0? Should that not be of 128 (a host = route is a /128)? Well, I guess TargPrefixLen of 0 would make any = advertisement into =E2=80=9Ca default route=E2=80=9D, but I like the = below (advertising 0/0) better.

Even if = the RREP contained TargAddr =3D 0.0.0.0 and TargPrefixLen of 0, RREQ_Gen = could still match this with the RREQ it had sent and consider the route = request fulfilled. Do you see a problem with this? We would need to = update the wording and the current use of Prefix Length, since we = currently interpret a prefix length of 0, and also the omission of = prefix length value, to mean the full address length.

Hm, I think that something like that could work in = terms of advertising a gateway into the network. The problem would be, = how would you treat that on the router? Installing 0/0 into the FIB = would cause your router to never send RREQs again ;) 

You would have to be keeping the 0/0 in your RIB, = when getting a FIB miss then =E2=80=9Clook in <something> if this = destination is expected to be inside the MANET=E2=80=9D and unless that = <something> tells you =E2=80=9Cno, it isn't=E2=80=9D, could you = use the 0/0 entry. 

But then = again, the destination *could* still be reachable as a =E2=80=9Clocally = attached network=E2=80=9D to another router (say, your laptop) which I = could reach within the MANET =E2=80=94 but also, via Lotte=E2=80=99s = laptop which is advertising 0/0.

So = I guess my conclusion is: YES, but with some verbiage framing the = addressing model (=E2=80=9CThe MANET has a prefix p::/$LENGTH. All = destinations within that prefix are inside the MANET and a router MUST = NOT use a 0/0 prefix for reaching them. All other prefixes are fair = game=E2=80=9D).

I don=E2=80=99t = think that it=E2=80=99s necessary to document *all* addressing models = that *could* work in the next revision, but this would be a fantastic = thing to get started addressing.  What=E2=80=99s in the doc = doesn=E2=80=99t really do much. This does something, subject to = refinement as we go along?

And even = better, I *think* that it can be generalized to the case (Lotte=E2=80=99s = Laptop) mentioned above, although I have not thought that through = completely.

Very glad that we=E2=80=99= re seeing progress on gateways, finally, thank you for taking this = up.

Best,

Thomas



Kind Regards,
Victoria.


The reason why I speculate that this is = so is, that RREQ forwarding installs the =E2=80=9Creverse route=E2=80=9D = towards the source, and if OrigAddr is "the source addresses of the IP packet for which a route = is requested=E2=80=9D address, i.e., there is no way for the RREQ to = request a route to the server =E2=80=9Cat once=E2=80=9D on behalf of = "the entire /56=E2=80=9D  behind it?

Again, if I am understanding this = correctly, then it deserves a bit more elaboration, notably a framing of = the cases discussed in the above, and a modulation of the statement from = the applicability statement that:

AODVv2 can, = however, be configured to perform gateway functions when
   = attached to external networks, as discussed = in 
= Section 9.

Capturing these limitations of gateway = functionality?

The same, probably, also applies in the = opposite direction, i.e., in case a single =E2=80=9Csource=E2=80=9D = needs to communicate with many or all of a /56, behind a = router?

Best,

Thomas


On 07 Apr 2016, at 23:11, Thomas Heide = Clausen <ietf@thomasclausen.org> wrote:

On this whole = gateway issue, I am disturbed...most routers would have one-or-multiple = /64-or-shorter, one per non-Manet link (w/ hosts hanging off) delegated = to them, and not just a single /128.

Needing to communicate with many-to-all = hosts on a link is not uncommon (if the hosts are, e.g., environmental = controls in the same room), and the ability to "get the whole prefix = advertised at once" send an RREQ for the whole prefix - specifically, = for not 

Sent from my = iPad

On 07 Apr 2016, at 22:19, = Christopher Dearlove <christopher.dearlove@gmail.com> = wrote:

Thanks, that addresses most = of the points I made.

Assuming that is that a packet reception for forwarding is = the only option you choose to allow. It's perfectly reasonable for an = implementation to think "wouldn't it be sensible to learn about a = gateway now for various reasons?".  Yes, there's the problem of = which subnet to look for (0.0.0.0/0 or something smaller). Yes, = I can imagine you don't want to define this now - unless of course = someone in the WG says they really want it. But I would say, don't close = the door on it, even if not doing it now.

(There are other possibilities that = might be useful one day. An RREQ that looks for more than one address = for example - you could trade latency and overhead by combining = RREQs.)

--  
Christopher = Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)

On 7 Apr 2016, at 18:49, Victoria Mercieca = <vmercieca0@gmail.com> wrote:

Hi Christopher,

On 7 = Apr 2016 1:55 pm, "Christopher Dearlove" <christopher.dearlove@gmail.com> wrote:
>
> [This time from a subscribed = address.]
>
> You say you've added a = sentence saying AODVv2 doesn't do RREQs for gateways. What should have = happened is a discussion on this list as to why? is that hard? does = anyone have a clever idea to make it not hard? does anyone need that = functionality? and so on.
>
> For = example, here's something that superficially looks like it might work. = Does it, or does it introduce new problems? I don't know. But this, and = likely better ideas, just haven't had discussion here - and I fear that = the people who might have the better ideas have departed unheard.
>
> So, a router wants a route to = a.b.c.d, and sends an RREQ for that (/32, or simply omit). Of course any = router directly serving that address just replies. But a router that is = serving a.0.0.0/8 could reply with that address. The originating router = of course would use standard IP maximum prefix length rules. Does that = work? Does it help anyone? Could a router reply a.b.c.d/32 and a.0.0.0/8 = in one RREP? Or could it be allowed to reply a.b.c.d/8 as a = shorthand?

This is exactly what it does = (based on the router client entry corresponding to TargAddr, e.g if = router client entry is a.0.0.0/8, then the RREP contains a.b.c.d/8). = Everyone receiving the RREP can then install the route to a.0.0.0/8 and = therefore avoid a separate RREQ for (as an example) a.b.c.e in future. = Similarly an RREQ contains the prefix length associated with the router = client entry configured for OrigAddr, and routers processing the RREQ = learn the route to OrigAddrs prefix.

But = you can't intentionally send a RREQ for a prefix because the RREQ is = created when there's a packet to send, you know the destination address = not the prefix associated with it, so TargAddr is a.b.c.d/32. But even = so, you do end up learning a route to a prefix, if TargAddr is part of a = router client entry which is a prefix.

Kind = regards,
Victoria. 

> And why can't a router request a.b.0.0/16 - and possibly = get an a.0.0.0/8 reply?
>
> Answers to = all of those is "I don't know".  But we should have been having = those discussions.
>
> -- 
> Christopher Dearlove
> christopher.dearlove@gmail.co= m
>
>
>
> --  
> Christopher Dearlove
> christopher.dearlove@gmail.co= m (iPhone)
> chris@mnemosyne.demon.co.uk (home)
> On 7 Apr 2016, at 15:49, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:
>
>> Hi Thomas,
>>
>>> Am 05.04.2016 um 20:07 = schrieb ietf@thomasclausen.org:>>>
>>> Lotte,
>>>
>>> Thank you for this = update. An impressive amount of changes to the document, according to = RFCdiff, and as I can see from your mail that there is much more to = come,
>>
>>
>>= Thanks! I=E2=80=99m glad you=E2=80=99re seeing the progress we=E2=80=99ve= made. 
>>
>>> I hope = that you forgive me for not jumping at a blow-by-blow review until a = version which the authors themselves consider stable, is produced.
>>>
>>> On the point of = =E2=80=9Cmuch more to come", there have been quite a few comments raised = by WG participants other than Mr. Dean and Chris  (such as by = myself, but not only) =E2=80=94 some of which intersect some of the = below, and for which I do not believe that a satisfactory resolution has = been developed, presented to the WG, and confirmed.
>>
>>
>> I=E2=80=99= m not quite sure which comments exactly you are referring to? Your last = comments that come to mind are the ones in these threads:
>>
>> https://www.ietf.org/mail-arc= hive/web/manet/current/msg18055.html
>> https://www.ietf.org/mail-arc= hive/web/manet/current/msg18639.html
>>
>> You=E2=80=99ve announced to go through the former in = your last response to the latter, but as far as I can see you haven=E2=80=99= t gotten round to doing that and a lot of points you=E2=80=99ve brought = up have sparked ongoing discussions, so I=E2=80=99ve marked most of your = comments as =E2=80=9Cpending=E2=80=93 still in discussion=E2=80=9D in my = mind. 
>> Regarding the points you brought up = that aren=E2=80=99t affected by this:
>>
>> * Metrics=E2=80=93 we=E2=80=99ve had discussions = about this many moons ago with authors on both sides of the fence. = Unfortunately I can=E2=80=99t remember the counter arguments, and I=E2=80=99= m still looking for records of this conversation=E2=80=A6 I=E2=80=99ll = get back to you when I=E2=80=99ve found out more.
>> = * Prefixes & Gateways: I=E2=80=99ve added a sentence to clarify = that AODVv2 doesn=E2=80=99t do RREQs for gateways, I hop that helps?
>>
>>>
>>> = In which revision of the I-D do you plan on addressing those?
>>>
>>
>> If = the discussions reach a conclusion by then, I=E2=80=99d be glad to have = them addressed by the next revision.
>>
>> Best regards,
>> Lotte
>>
>>> Best,
>>>
>>> Thomas
>>>
>>>
>>>
>>>> On Apr 5, 2016, = at 12:53, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:
>>>>
>>>> Hi all,
>>>> just a quick summary of what is and what = isn=E2=80=99t included in this update of the draft:
>>>>
>>>> DONE:
>>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94
>>>> * All JWD! comments (i.e. the critical ones) = are resolved
>>>> * Out of 90 JWD and JWD! = comments, 61 are resolved
>>>> * The revised = security considerations [1] were added (with the TODOs commented out)
>>>> * The following TODO from [1] was = resolved: 
>>>>    "This = description MUST
>>>>    include the = reasons it was either unreasonable or out of scope to
>>>>    attempt to avoid these denial = of service attacks."
>>>> * Section 9 now = contains a statement that AODVv2 doesn=E2=80=99t support RREQs for = prefixes, I hope that clears things up for Thomas.
>>>>
>>>> TO DO:
>>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94 
>>>> * Most notable of the 29 JWDs that are yet = to be resolved:
>>>> + (is there some = table that lists routes that are being waited on? JWD) We decided = to add a separate 
>>>>     =        RREP table that lists them and I=E2=80=99ve = volunteered to write text for that, but we=E2=80=99re currently = discussing if/how
>>>>       =      we might solve this without adding yet another = table.
>>>>
>>>> + = We=E2=80=99re currently discussing the approaching the limit thing. = (i.e.
>>>>    (There is no defined = behavior here. Approaching the limit? Section 6.5 outlines which = messages are more important but now how to decide to allow them to be = transmitted or not. JWD 
>>>> =   and
>>>>   (The = undefined approaching the limit thing again JWD) etc
>>>>           =  We=E2=80=99ve already clarified the wording regarding what the = limit is and how to prioritize the message types, 
>>>>           =  what=E2=80=99s left is to define what =E2=80=9Eapproaching=E2=80=9C = means (and whether we need to talk about approaching rather than
>>>>           =  just saying =E2=80=9Ehere=E2=80=99s what to do when you actually = hit the limit").
>>>>
>>>>     + (I don=E2=80=99t want = to spam the list with a comprehensive list of all of them, but if = you=E2=80=99re interested in seeing them,
>>>> =            please do say so and I=E2=80=99ll= send my copy of Justin=E2=80=99s review containing all TODOs and DONEs = to the list)
>>>> * some TODOs in security = considerations (see [1])
>>>> * since we're = waiting for Chris=E2=80=99 feedback regarding the revised 5444 = multiplexer wording, that hasn=E2=80=99t changed yet.
>>>>
>>>> More details = can be found in Appendix A.  AODVv2 Draft Updates, as = well as the diff, of course.
>>>>
>>>> Best regards,
>>>> = Lotte
>>>>
>>>> [1] = Re: [manet] AODVv2: Security considerations update https://www.ietf.org/mail-archive/web/manet/current/msg18458.ht= ml
>>>>
>>>>
>>>>> Am 05.04.2016 um 12:19 schrieb internet-drafts@ietf.org:
>>>>>
>>>>>
>>>>> 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
>>>>> =             &n= bsp;           &nbs= p;Stan Ratliff
>>>>> =             &n= bsp;           &nbs= p;John Dowdell
>>>>> =             &n= bsp;           &nbs= p;Lotte Steenbrink
>>>>> =             &n= bsp;           &nbs= p;Victoria Mercieca
>>>>> Filename =        : = draft-ietf-manet-aodvv2-14.txt
>>>>> Pages =           : 80
>>>>> Date =            : = 2016-04-05
>>>>>
>>>>> 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/d= raft-ietf-manet-aodvv2-14
>>>>>
>>>>> A diff from the previous version is = available at:
>>>>> https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-manet-aodvv2-14
>>>>>
>>>>>
>>>>> 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-d= rafts/
>>>>>
>>>>> = _______________________________________________
>>>>> 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

= --Apple-Mail=_0A99D2C6-3288-4F09-86FD-DB991DF1D4FA-- From nobody Wed Apr 20 08:41: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 442AC12EE83 for ; Wed, 20 Apr 2016 08:41:14 -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 33AWHMCcyFvD for ; Wed, 20 Apr 2016 08:41:12 -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 3DF3B12EFFD for ; Wed, 20 Apr 2016 08:35:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 10E4E240828; Wed, 20 Apr 2016 08:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461166513; bh=aKwqS8KjmYnFWQF8StVYJ+K9Y4vnfbhW3VbcgfOT6wg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=OQhmzInOwphidlDSqZYNphjreI2qszbJGoUTQWeUzckJuSyNPd3WljSNj2S1Vopnf +QZIWvveoGOHVr/m4aVImI+GJKuHYh9fdARr4da104i3mzwjLsBEyQIFc4rpjcegK+ wiwAf98TTPXjC1sCGz3S9a8/kNvJJWR7Bd60CRg4= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (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 C778D245BB5; Wed, 20 Apr 2016 08:35:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9DEE2C53-16C9-4F38-9124-15BB70B03F06" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: ietf@thomasclausen.org In-Reply-To: Date: Wed, 20 Apr 2016 17:35:10 +0200 Message-Id: References: <571508C8.3030003@earthlink.net> <571536FC.5050407@earthlink.net> <57177A9A.90709@earthlink.net> To: Stan Ratliff X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Charles Perkins , Christopher Dearlove , Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 20 Apr 2016 15:41:14 -0000 --Apple-Mail=_9DEE2C53-16C9-4F38-9124-15BB70B03F06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 20, 2016, at 17:15, Stan Ratliff wrote: >=20 >=20 >=20 > On Wed, Apr 20, 2016 at 11:05 AM, > wrote: >=20 >> On Apr 20, 2016, at 16:15, Stan Ratliff > wrote: >>=20 >>=20 >> On Wed, Apr 20, 2016 at 10:01 AM, Dearlove, Christopher (UK) = > = wrote: >>=20 >> [snip]=20 >> Or in short, nothing is ideal. At this point I'd be very tempted to = say get something down, and the easiest something is always 32 bits. >>=20 >> [snip] >>=20 >> +1.=20 >> Except I'm not "very tempted to say"; I'm just flat-out saying >=20 > As WG chair, or as document author? >=20 > We've been through this. I've already explicitly recused myself from = char duties with regard to AODVv2, Therefore, there is no need to do so = on each and every email. > =20 >=20 >> it: "Get something down, and the easiest something is always 32 = bits." >> ;-) ;-) >>=20 >=20 > Disagree. I posted, earlier today and in another thread, a proposal = that could be a (sort of) compromise. For sure, if all you need is an = octet, then you shouldn=E2=80=99t have to have 4 forced upon you, when = there is an alternative. >=20 > Then I guess there's yet another item on which we disagree.=20 >=20 Which is why it is important to be very clear what hat is worn. > Stan --Apple-Mail=_9DEE2C53-16C9-4F38-9124-15BB70B03F06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 20, 2016, at 17:15, Stan Ratliff <ratliffstan@gmail.com> wrote:



On = Wed, Apr 20, 2016 at 11:05 AM,  <ietf@thomasclausen.org> wrote:

On Apr = 20, 2016, at 16:15, Stan Ratliff <ratliffstan@gmail.com> wrote:


On Wed, = Apr 20, 2016 at 10:01 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

[snip] 
Or in short, nothing is ideal. At this point I'd be = very tempted to say get something down, and the easiest something is = always 32 bits.

[snip]

+1. 
Except I'm not "very tempted = to say"; I'm just flat-out = saying
As WG chair, or as document = author?

We've been through this. I've already explicitly recused = myself from char duties with regard to AODVv2, Therefore, there is no = need to do so on each and every email.
 

it: "Get something down, and the = easiest something is always 32 bits."
;-) = ;-)


Disagree. I posted, earlier today and in = another thread, a proposal that could be a (sort of) compromise. For = sure, if all you need is an octet, then you shouldn=E2=80=99t have to = have 4 forced upon you, when there is an = alternative.

Then I guess there's yet another item = on which we disagree. 


Which = is why it is important to be very clear what hat is worn.

Stan

= --Apple-Mail=_9DEE2C53-16C9-4F38-9124-15BB70B03F06-- From nobody Wed Apr 20 08:42:31 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 41A7D12DF86 for ; Wed, 20 Apr 2016 08:42:30 -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 QrZGvh5clAsT for ; Wed, 20 Apr 2016 08:42:28 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 8A40E12DF01 for ; Wed, 20 Apr 2016 08:39:06 -0700 (PDT) Received: by mail-qg0-x22a.google.com with SMTP id d90so794586qgd.3 for ; Wed, 20 Apr 2016 08:39:06 -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=8dtVXAbKMNq9qYWQOJKG0pCJ7QsxfLlMJM05+17oHvE=; b=khH1JzuzL0UZoRAbkLOPCZ2xL1bRi6VMtntQZn7uPA6nOzl2t2FhQbdc4v1EjgaIF/ F5PI8SQIXHRrTqz3JUVDPtANI9/s3dZsvx49bwrNt6E4H7TebdPLTj7+Y9MN9gup9KVX TbFgRMc4M25vGWkMCEeEMVdUYbWsGc60nENQYtMROzF+lx4U4cmMYTTC7IriRnhDYGjE wWDO6kSmMSWP3iIw5/jdefOEr3EqAhBy9c7JfAbR0Vcs0GYpML7AFkNS8Wci36YaT3Aw jmmE3DC+xCmvQlPAz+wwts+IJu+ABnsF5g4VmWkD2I3XR9NhVZ61ac6b0foHYsYp15/5 OMkA== 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=8dtVXAbKMNq9qYWQOJKG0pCJ7QsxfLlMJM05+17oHvE=; b=L/jQwZB/s9UvdztMHNsRg1KJtjFEV8SlBOhq9rzcdYAWa2J5qjZ5R59HxFqqjjW8XK DH3jAQL9XUrROwC2vxNOZwJ1I02kVXCHyGCwwjvbADt2KsIEHX4mnydYwo3sA6gUnl6Z S+IRMjwozu37x4Wu5rPUgVkl9bdE6BPmbawvGN9oBwXefyoE6gv+zxiHPvPlhNcNLh9f wk8XLEsrANervjGEpSS6bSGUsLCZ9k7dbA4qkM3arGGka5uc5RkMC8jPluJAG4hBhCSU LMSRq8JoLcIc6XiyhidPNvHUDSoEnKziouOnrOH9Zqa/hL/VpC4TqKrCz3jbHVdFdNcM td8g== X-Gm-Message-State: AOPr4FVJd7s8LONSG5NmP7kSer7KwM+c5Cfj4mLDYSXOGumDcTbVJRjbfYmyBTmx1Qvghiia0WXgvZS8rctooQ== MIME-Version: 1.0 X-Received: by 10.140.100.225 with SMTP id s88mr11486699qge.76.1461166745692; Wed, 20 Apr 2016 08:39:05 -0700 (PDT) Received: by 10.140.43.131 with HTTP; Wed, 20 Apr 2016 08:39:05 -0700 (PDT) In-Reply-To: References: <571508C8.3030003@earthlink.net> <571536FC.5050407@earthlink.net> <57177A9A.90709@earthlink.net> Date: Wed, 20 Apr 2016 17:39:05 +0200 Message-ID: From: Abdussalam Baryun To: Stan Ratliff Content-Type: multipart/alternative; boundary=001a1134f5fcd5b7070530ec64f9 Archived-At: Cc: Charles Perkins , Christopher Dearlove , Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 20 Apr 2016 15:42:30 -0000 --001a1134f5fcd5b7070530ec64f9 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 20, 2016 at 5:15 PM, Stan Ratliff wrote: > > > > On Wed, Apr 20, 2016 at 11:05 AM, wrote: > >> >> On Apr 20, 2016, at 16:15, Stan Ratliff wrote: >> >> >> On Wed, Apr 20, 2016 at 10:01 AM, Dearlove, Christopher (UK) < >> chris.dearlove@baesystems.com> wrote: >> >> [snip] >> >>> Or in short, nothing is ideal. At this point I'd be very tempted to say >>> get something down, and the easiest something is always 32 bits. >>> >>> [snip] >> >> +1. >> Except I'm not "very tempted to say"; I'm just flat-out saying >> >> >> As WG chair, or as document author? >> > > We've been through this. I've already explicitly recused myself from char > duties with regard to AODVv2, Therefore, there is no need to do so on each > and every email. > > > nice one :-). Yes we got through this, when I see your email saying you are a participant I get a feeling that you are not the chair and also not other positions. I agree any participant does not need to do that, but if he is a chair speaking he/she needs to write/say that the chair is speaking/writting. AB --001a1134f5fcd5b7070530ec64f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 20, 2016 at 5:15 PM, Stan Ratliff <ratliffstan@gmail.c= om> wrote:



On Wed, Apr 20, 2016 at 11:05 AM, <ietf@thomasclausen.org= > wrote:

On Apr 20, 2016, = at 16:15, Stan Ratliff <ratliffstan@gmail.com> wrote:


On Wed,= Apr 20, 2016 at 10:01 AM, Dearlove, Christopher (UK) <= ;chris.d= earlove@baesystems.com> wrote:

[snip]= =C2=A0
Or in short, nothing is ideal. At this point I'd be very tempted to say= get something down, and the easiest something is always 32 bits.

[snip]

+1.=C2=A0
E= xcept I'm not "very tempted to say"; I'm just flat-out sa= ying

As WG c= hair, or as document author?

=
We've been through this. I've already explicitly recused mysel= f from char duties with regard to AODVv2, Therefore, there is no need to do= so on each and every email.
=C2=A0
=

nice one :-). Yes we= got through this, when I see your email saying you are a participant I get= a feeling that you are not the chair and also not other positions. I agree= any participant does not need to do that, but if he is a chair speaking he= /she needs to write/say that the chair is speaking/writting.

<= div>AB
--001a1134f5fcd5b7070530ec64f9-- From nobody Wed Apr 20 08:45: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 5A8BB12D152 for ; Wed, 20 Apr 2016 08:45:40 -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 O-v9TiwFbbD3 for ; Wed, 20 Apr 2016 08:45:34 -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 2773912D0F5 for ; Wed, 20 Apr 2016 08:45:34 -0700 (PDT) Received: by mail-ig0-x236.google.com with SMTP id f1so131941442igr.1 for ; Wed, 20 Apr 2016 08:45: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=EZbY0ofic4ZtHojQKcLHdVzorue54Yx/kxLh6yyDcNs=; b=o4NL6NH42a38USGyUFP8cV5TJiPfoq5qHFw/fvXYal9L5jT18eZlHgSjOMNmZdgpgX MPSQZg1zwPq3J6zgmdb7R/7sWnE5C2u2G1gQZFe8xgiCA9XT9hBcJxCsr0CB83C3uRoN N/TqbtzIQLZ/H+7XCQ54lxEV2bElelCP7DUjZpHyPkDg7fCZ7/8FYLoZR3mDzDgjAlxB BXT4czymYYyU36uSoD5l9J5FftpVIfx5vmBYXsmfYiTFwz9IunjUGutHOoRCWJZS9BHZ rSXleCgOOKmHxW3heWyEGyTjII+rMHaBo4Ngo6DXg8rpdx8ICM0BacCyT+1vIEIHlyRh 8TOQ== 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=EZbY0ofic4ZtHojQKcLHdVzorue54Yx/kxLh6yyDcNs=; b=gVwnboJQw1myw9rIZ530Fn3znFwbyQp2YZstKEQzkakhXkUJ9TfDQwlcEsnxLq5287 loOePX57PwM69EXu2biV+XY4rRZu/XsjEpCo3Mte15uHFKhR3LqAWngDYrERlWcL1TD7 wcA0tE+pGmA6+IzS6AJMTcdDm1HXdRqVf5cBJYCJQ6vIpBZuPzTZ1qiP6quk5W06JO98 yIaexfpp9BKqUeZQpzYPdD/4igrsTfR1GCe2torTE7liiz3KiQB5vYto4RQ+ncpL9Rw7 L2M9oQYAjS/tNHgbChhKFMu3dXAl/xc3DiYhAFtP3th4jc6vVpeqWB9CDOVYFDAxaPeM kcWw== X-Gm-Message-State: AOPr4FW9xR1XC7fvoq1fJYZtdedDm1voF3UnQyREjriH0i+MUKa7/m//h4kUUoeNcIICZgxwQfuD7tLMAZVeoQ== MIME-Version: 1.0 X-Received: by 10.50.72.107 with SMTP id c11mr4456529igv.85.1461167132047; Wed, 20 Apr 2016 08:45:32 -0700 (PDT) Received: by 10.79.72.68 with HTTP; Wed, 20 Apr 2016 08:45:31 -0700 (PDT) In-Reply-To: References: <571508C8.3030003@earthlink.net> <571536FC.5050407@earthlink.net> <57177A9A.90709@earthlink.net> Date: Wed, 20 Apr 2016 11:45:31 -0400 Message-ID: From: Stan Ratliff To: Thomas Clausen Content-Type: multipart/alternative; boundary=047d7bdc15badd006e0530ec7b47 Archived-At: Cc: Charles Perkins , Christopher Dearlove , Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Resolution for whether or not to use the RFC 6551 registry for link metrics 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, 20 Apr 2016 15:45:40 -0000 --047d7bdc15badd006e0530ec7b47 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 20, 2016 at 11:35 AM, wrote: > > On Apr 20, 2016, at 17:15, Stan Ratliff wrote: > > > > On Wed, Apr 20, 2016 at 11:05 AM, wrote: > >> >> On Apr 20, 2016, at 16:15, Stan Ratliff wrote: >> >> >> On Wed, Apr 20, 2016 at 10:01 AM, Dearlove, Christopher (UK) < >> chris.dearlove@baesystems.com> wrote: >> >> [snip] >> >>> Or in short, nothing is ideal. At this point I'd be very tempted to say >>> get something down, and the easiest something is always 32 bits. >>> >>> [snip] >> >> +1. >> Except I'm not "very tempted to say"; I'm just flat-out saying >> >> >> As WG chair, or as document author? >> > > We've been through this. I've already explicitly recused myself from char > duties with regard to AODVv2, Therefore, there is no need to do so on eac= h > and every email. > > >> >> it: "Get something down, and the easiest something is always 32 bits." >> ;-) ;-) >> >> >> Disagree. I posted, earlier today and in another thread, a proposal that >> could be a (sort of) compromise. For sure, if all you need is an octet, >> then you shouldn=E2=80=99t have to have 4 forced upon you, when there is= an >> alternative. >> > > Then I guess there's yet another item on which we disagree. > > > Which is why it is important to be very clear what hat is worn. > > It *IS* clear. --047d7bdc15badd006e0530ec7b47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 20, 2016 at 11:35 AM, <ietf@thomasclausen.org>= ; wrote:

On Apr 20, 2016, at 17:1= 5, Stan Ratliff <ratliffstan@gmail.com> wrote:



On Wed, Apr 20, 2016 at 11:05 AM,=C2=A0= =C2=A0<ietf@thomasclausen.org>=C2=A0wrote:

On Apr 20, 2016, at 16:15, Stan R= atliff <ratli= ffstan@gmail.com> wrote:


On Wed, Apr 20, 2016 at = 10:01 AM, Dearlove, Christopher (UK)=C2=A0&l= t;chris.= dearlove@baesystems.com>=C2=A0wrote:
[snip]=C2=A0
Or in short, nothing is idea= l. At this point I'd be very tempted to say get something down, and the= easiest something is always 32 bits.

[snip]
=

+1.=C2=A0
Except I'm not "very tempt= ed to say"; I'm just flat-out saying
=

As WG chair, or as document author?
=

We've been through this. I'v= e already explicitly recused myself from char duties with regard to AODVv2,= Therefore, there is no need to do so on each and every email.
= =C2=A0

<= blockquote type=3D"cite">
it: "Get something down, and the e= asiest something is always 32 bits."
;-) ;-)

<= /div>

Disagree. I = posted, earlier today and in another thread, a proposal that could be a (so= rt of) compromise. For sure, if all you need is an octet, then you shouldn= =E2=80=99t have to have 4 forced upon you, when there is an alternative.

Then I guess there's yet anot= her item on which we disagree.=C2=A0


Which is why it is important to be very clear what ha= t is worn.


It *IS* clear.

--047d7bdc15badd006e0530ec7b47-- From nobody Wed Apr 20 08:45: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 CE26712DCDC for ; Wed, 20 Apr 2016 08:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 HjNI8Qao7TXJ for ; Wed, 20 Apr 2016 08:45:40 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 788F612D0F5 for ; Wed, 20 Apr 2016 08:45:40 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.67]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1asuJq-0003l5-Bt; Wed, 20 Apr 2016 11:45:34 -0400 To: Abdussalam Baryun References: From: "Charles E. Perkins" Organization: Blue Skies Message-ID: <5717A415.5040309@computer.org> Date: Wed, 20 Apr 2016 08:45:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010308050808020803070801" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac792df5d25e33477d4e755479b9bb57b7b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] Received Signal Weakness - RSW metric (was Re: Fwd: New Version Notification for draft-perkins-manet-rsw-00.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, 20 Apr 2016 15:45:47 -0000 This is a multi-part message in MIME format. --------------010308050808020803070801 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello Abdussalam, It's convenient to have 0 <= P_norm <= 1 . This allows for simple use of the exponent. Regards, Charlie P. On 4/20/2016 7:17 AM, Abdussalam Baryun wrote: > Hi Charlie, > > This RSW is new metric, so I want to think of the RSW in different way > and please give me your feedback, because maybe you thought about this > and you have reasons to make it the way it is in the draft. We need to > have a reference between strong/strength and weak/poor signal, let me > name it the power threshold or reference P_ref. So the power level > measurement is to be normalised between -1 and 1. This threshold can > be determined by the subnet technology used. > > What you think if we change the measure idea to: > In order > to fit in eight bits, the received power measurement is normalized to > be within the range from 0 to 1, where the minimum measurable power > P_min maps to 1 (the highest cost value) and the maximum measurable > power P_max maps to 0 (the lowest cost value). In other words, the > measured received power P_meas maps to a normalized value P_norm = > (P_max - P_meas) / (P_max - P_min). > > Change-to> > In order > to fit in eight bits, the received power measurement is normalized to > be within the range from -1 to 1, where the minimum measurable power > P_min maps to 1 (the highest cost value) and the maximum measurable > power P_max maps to -1 (the lowest cost value). In other words, the > measured received power P_meas maps to a normalized value P_norm = > (P_ref - P_meas) / (P_max - P_min). > AB > > > On Tue, Apr 19, 2016 at 8:05 PM, Charles E. Perkins > > wrote: > > Hello folks, > > This draft presents the RSW additive link metric from IEEE > 802.15.10 along with information about how to use it with AODVv2. > > It basically enables selection of a path with optimal signal strength. > > It is protocol-independent, and could be included as another > metric in the table of AODVv2 metrics, or used by other protocols > such as OLSRv2. > > Regards, > Charlie P. > > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-perkins-manet-rsw-00.txt > Date: Mon, 18 Apr 2016 22:23:52 -0700 > From: internet-drafts@ietf.org > To: Charles E. Perkins > > > > > A new version of I-D, draft-perkins-manet-rsw-00.txt > has been successfully submitted by Charles E. Perkins and posted to the > IETF repository. > > Name: draft-perkins-manet-rsw > Revision: 00 > Title: Received Signal Weakness (RSW) Metric > Document date: 2016-04-18 > Group: Individual Submission > Pages: 4 > URL:https://www.ietf.org/internet-drafts/draft-perkins-manet-rsw-00.txt > Status:https://datatracker.ietf.org/doc/draft-perkins-manet-rsw/ > Htmlized:https://tools.ietf.org/html/draft-perkins-manet-rsw-00 > > > Abstract: > The Received Signal Weakness (RSW) metric is a simple cost metric > that enables selection of a route with the high end-to-end signal > strength. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available attools.ietf.org . > > The IETF Secretariat > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > -- Regards, Charlie P. --------------010308050808020803070801 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello Abdussalam,

It's convenient to have 0 <= P_norm <= 1  .  This allows for simple use of the exponent.

Regards,
Charlie P.

On 4/20/2016 7:17 AM, Abdussalam Baryun wrote:
Hi Charlie,

This RSW is new metric, so I want to think of the RSW in different way and please give me your feedback, because maybe you thought about this and you have reasons to make it the way it is in the draft. We need to have a reference between strong/strength and weak/poor signal, let me name it the power threshold or reference  P_ref. So the power level measurement is to be normalised between -1 and 1. This threshold can be determined by the subnet technology used.

What you think if we change the measure idea to:
 In order
   to fit in eight bits, the received power measurement is normalized to
   be within the range from 0 to 1, where the minimum measurable power
   P_min maps to 1 (the highest cost value) and the maximum measurable
   power P_max maps to 0 (the lowest cost value).  In other words, the
   measured received power P_meas maps to a normalized value P_norm =
   (P_max - P_meas) / (P_max - P_min).


Change-to>
 In order
   to fit in eight bits, the received power measurement is normalized to
   be within the range from -1 to 1, where the minimum measurable power
   P_min maps to 1 (the highest cost value) and the maximum measurable
   power P_max maps to -1 (the lowest cost value).  In other words, the
   measured received power P_meas maps to a normalized value P_norm =
   (P_ref - P_meas) / (P_max - P_min).


        

        
AB


        

        


          
On Tue, Apr 19, 2016 at 8:05 PM,
            Charles E. Perkins <charliep@computer.org>
            wrote:

            

              
 Hello folks,

                

                This draft presents the RSW additive link metric from
                IEEE 802.15.10 along with information about how to use
                it with AODVv2.

                

                It basically enables selection of a path with optimal
                signal strength.

                

                It is protocol-independent, and could be included as
                another metric in the table of AODVv2 metrics, or used
                by other protocols such as OLSRv2.

                

                Regards,

                Charlie P.

                

                


                  

                  -------- Forwarded Message --------
                  

                    
                      

                        Subject: 
                        New Version Notification for
                          draft-perkins-manet-rsw-00.txt
                      

                      

                        Date: 
                        Mon, 18 Apr 2016 22:23:52 -0700
                      

                      

                        From: 
                        internet-drafts@ietf.org
                      

                      

                        To: 
                        Charles E. Perkins <charliep@computer.org>
                      

                    
                  

                  

                  

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

Name:		draft-perkins-manet-rsw
Revision:	00
Title:		Received Signal Weakness (RSW) Metric
Document date:	2016-04-18
Group:		Individual Submission
Pages:		4
URL:            https://www.ietf.org/internet-drafts/draft-perkins-manet-rsw-00.txt
Status:         https://datatracker.ietf.org/doc/draft-perkins-manet-rsw/
Htmlized:       https://tools.ietf.org/html/draft-perkins-manet-rsw-00


Abstract:
   The Received Signal Weakness (RSW) metric is a simple cost metric
   that enables selection of a route with the high end-to-end signal
   strength.

                                                                                  


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




                  

                

                

              

              

              _______________________________________________

              manet mailing list

              manet@ietf.org

              https://www.ietf.org/mailman/listinfo/manet

              

            

          

          

        

      

    

    

    
-- 
Regards,
Charlie P.

  


--------------010308050808020803070801--


From nobody Wed Apr 20 08:53: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 B477612D7DF for ; Wed, 20 Apr 2016 08:53:13 -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 eB2kv6f5RGYn for ; Wed, 20 Apr 2016 08:53:12 -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 1678812D86F for ; Wed, 20 Apr 2016 08:53:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id DC6E0240150; Wed, 20 Apr 2016 08:53:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461167591; bh=o07dzQFJWj3vmPShuiBefY0ApE0oR6wFk5elsY7IiIw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=MVuDJ355eLeC6G2VpYAZIMs42KNJ0RO3WrktAgYNmB2BUmvKw9CYJAAugCRGb79BZ G8/eXGtcVkuWTyrN0lttx3kRV80UrwmWxFDUgYbA9I9unmgC/4iCQr1CgAvB/Zb9VD pacARVHilOmNx1skb2kxbrrd5iI4wvYOvFnyQAe8=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.147.111] (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 CAD08240996; Wed, 20 Apr 2016 08:53:10 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0F8B0BDA-293A-44D5-9F11-F7236B2B98A1"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: ietf@thomasclausen.org
In-Reply-To: 
Date: Wed, 20 Apr 2016 17:53:09 +0200
Message-Id: <7BB65BEE-0057-4165-B853-8DD54F864031@thomasclausen.org>
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <1AACF97D-5BE6-450A-8474-AE698D2100D5@thomasclausen.org>  <86E88A09-8C13-4049-AD0D-3C164C5E5E61@thomasclausen.org> 
To: Justin Dean 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items
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, 20 Apr 2016 15:53:13 -0000

--Apple-Mail=_0F8B0BDA-293A-44D5-9F11-F7236B2B98A1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Justin, all,

Apologies for the delayed response to this. Day-job, and all that, I =
know you know what I=E2=80=99m talking about=E2=80=A6

> On Mar 23, 2016, at 13:59, Justin Dean  wrote:
>=20
> On Tue, Mar 22, 2016 at 5:04 PM, Thomas Heide Clausen =
> wrote:
>=20
>=20
> On 22 Mar 2016, at 21:51, Justin Dean > wrote:
>=20
>> I think you're misunderstanding my point. It's my opinion that it's =
past time to come up with some elegant and complex solution to fix this =
issue. Simple and safe solutions should be preferred as we'd likely miss =
something. This is regardless of when the outstanding problem was first =
raised.
>>=20
>=20
> My point is that it is an issue that must be addressed: the =
requirements that multiple interfaces can be sharing the same address is =
old, I have raised it multiple times over the years. OLSRv2 was built to =
support it. Henning reported an additional use case.
>=20
> The WG chair suggesting to disallow it, or to "bridge it", is *not* =
solving the issue raised. It is the WG chair ignoring legitimate =
requirements from the WG, which does not strike me as aligned with =
proper process.
>=20
> The WG chair saying "it is past time to solve" a long raised (and =
ignored) issue does not strike me as being aligned with proper process =
either.
>=20
> Thomas
>=20
> Since you seem quite passionate about this issue let's work on fixing =
it then.=20

Thanks, appreciate it.

> I looked back over NHDP to see how we "solved" this issue (vaguely =
remembering something about limiting the address assignment when two =
interfaces on a node could reach the same medium but was unable to find =
that).

I have not looked it up, but the trick is indeed in that area, plus what =
you write below also.

Part of the motivation is, that if you do not do that, you may =
(potentially) break MPR flooding (remember, the race condition diagrams =
=E2=80=A6?), so restrictions like that are in order.

> It works because we tag neighboring addresses with either link or =
neighbor status based on the incoming interface on which we received =
hello messages.
> It seems to me that if AODVv2 limited RREP messages to the interface =
on which the RREQ came in on (multicast or otherwise) that this would =
fix the issue.

Did anyone work through that/if this approach would work? I haven=E2=80=99=
t actually constructed a proof, but for a network without reduced relay =
set flooding optimizations, I=E2=80=99ve not been able to find a =
counter-example which would easily break it [as described above], which =
is at least a good thing ;)

Now, as to how to implement it=E2=80=A6.

> To do this the Neighbor Table (section 6.3) would have to be updated =
to include the local interface on which this neighbor is associated =
with.=20
> When attempting to check bidirectionality messages would only be sent =
out on the listed interface.  This would be similar to the link table in =
NHDP and link tlv types.

Would that not entail an additional restriction required, such that the =
neighbor (as identified by an address) is reachable only over one, but =
not the other, interface? I.e., if the same address is used for two =
interfaces on a router, then those two must unequivocally be on =
different channels?

It seems that this avenue would be well worth developing, actually.

Best,

Thomas=20


>=20
> Justin


--Apple-Mail=_0F8B0BDA-293A-44D5-9F11-F7236B2B98A1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Justin, all,

Apologies for the delayed response to this. Day-job, and all =
that, I know you know what I=E2=80=99m talking about=E2=80=A6

On Mar 23, 2016, at 13:59, Justin Dean <bebemaster@gmail.com> wrote:

On Tue, Mar 22, 2016 at =
5:04 PM, Thomas Heide Clausen <ietf@thomasclausen.org> wrote:


On 22 Mar 2016, at 21:51, Justin Dean <bebemaster@gmail.com> wrote:

I think you're misunderstanding my point. It's my =
opinion that it's past time to come up with some elegant and complex =
solution to fix this issue. Simple and safe solutions should be =
preferred as we'd likely miss something. This is regardless of when the =
outstanding problem was first raised.
My point is that it is an issue =
that must be addressed: the requirements that multiple interfaces can be =
sharing the same address is old, I have raised it multiple times over =
the years. OLSRv2 was built to support it. Henning reported an =
additional use case.

The WG chair suggesting to disallow it, or to "bridge it", is =
*not* solving the issue raised. It is the WG chair ignoring legitimate =
requirements from the WG, which does not strike me as aligned with =
proper process.

The WG chair saying "it is past time to solve" a long raised =
(and ignored) issue does not strike me as being aligned with proper =
process either.

Thomas

Since you seem quite =
passionate about this issue let's work on fixing it =
then. 

Thanks, appreciate it.

 I =
looked back over NHDP to see how we "solved" this issue (vaguely =
remembering something about limiting the address assignment when two =
interfaces on a node could reach the same medium but was unable to find =
that).

I have not looked it up, but the trick is indeed in =
that area, plus what you write below also.

Part of the motivation is, that if you do not do =
that, you may (potentially) break MPR flooding (remember, the race =
condition diagrams =E2=80=A6?), so restrictions like that are in =
order.

It =
works because we tag neighboring addresses with either link or neighbor =
status based on the incoming interface on which we received hello =
messages.
 It =
seems to me that if AODVv2 limited RREP messages to the interface on =
which the RREQ came in on (multicast or otherwise) that this would fix =
the issue.

Did anyone work through that/if this approach =
would work? I haven=E2=80=99t actually constructed a proof, but for a =
network without reduced relay set flooding optimizations, I=E2=80=99ve =
not been able to find a counter-example which would easily break it [as =
described above], which is at least a good thing ;)

Now, as to how to implement it=E2=80=A6.
<=
br class=3D"">
To do =
this the Neighbor Table (section 6.3) would have to be updated to =
include the local interface on which this neighbor is associated =
with. 
 When =
attempting to check bidirectionality messages would only be sent out on =
the listed interface.  This would be similar to the link table in =
NHDP and link tlv types.

Would that not entail an additional restriction =
required, such that the neighbor (as identified by an address) is =
reachable only over one, but not the other, interface? I.e., if the same =
address is used for two interfaces on a router, then those two must =
unequivocally be on different channels?

It seems that this avenue would be well worth =
developing, actually.

Best,

Thomas 



Justin

=

--Apple-Mail=_0F8B0BDA-293A-44D5-9F11-F7236B2B98A1--


From nobody Wed Apr 20 09:06: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 0D6A112DA64 for ; Wed, 20 Apr 2016 09:06:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.395
X-Spam-Level: 
X-Spam-Status: No, score=-1.395 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, TRACKER_ID=1.306] autolearn=no 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 O5_M-wWrVWqc for ; Wed, 20 Apr 2016 09:05:59 -0700 (PDT)
Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (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 E1F7712D9AE for ; Wed, 20 Apr 2016 09:05:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 69FD8D5B62A; Wed, 20 Apr 2016 09:05:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461168357; bh=jK5Oqj+KlosqqWv4ouzCgBM7FAKAi1C/iRguHTTKU2w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ILm5703AYArlXOtHuAw3Qzs/mRpqKXryZ2ZAH/IB8uuICZ/E/RbKPQdaao4vH64wX WtjEz9m+V7hbT2+ev7Q6+1UvxaRk6rlZ/lvT0NjREhFxsf33iDwg1GBlEmkcZcZXDy T+rkx0vytntjjEQE17ff/S2uojqBvFty0s5GWKP4=
X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net
Received: from [192.168.147.111] (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 mailb1.tigertech.net (Postfix) with ESMTPSA id 6DC2FD40DB5; Wed, 20 Apr 2016 09:05:55 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_74B250BC-6EDB-4390-802A-5A50F2BE98F4"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: ietf@thomasclausen.org
In-Reply-To: 
Date: Wed, 20 Apr 2016 18:05:53 +0200
Message-Id: <05889ADB-283D-4D52-A357-6BB3FB415926@thomasclausen.org>
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> 
To: Christopher Dearlove 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 20 Apr 2016 16:06:02 -0000

--Apple-Mail=_74B250BC-6EDB-4390-802A-5A50F2BE98F4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Chris, all,

> On Apr 20, 2016, at 12:30, Dearlove, Christopher (UK) =
 wrote:
>=20
> Can I just say it=E2=80=99s quite hard to work out who is saying what =
in these exchanges. I=E2=80=99m having to guess some on the basis of =
=E2=80=9Cthat sounds like Thomas=E2=80=9D or =E2=80=9Cthat sounds like =
Lotte=E2=80=9D.

I think that your MUA is slightly broken, then, but when I have doubts I =
hit the archives, which correctly shows who says what =E2=80=94 here=E2=80=
=99s the archive for the message in question:

	=
http://mailarchive.ietf.org/arch/msg/manet/MCxWf0tLc9Q7Ix_XW_0lAPyHIdc =



> =20
> What I=E2=80=99m not clear on is what conclusion, if any, you=E2=80=99ve=
 drawn on hop count/limit.
> =20
> As I see it, if the protocol receives a message then sends a message =
similar but not identical to that out, that can be reviewed as creating =
a new message. It is a new message as far as 7182 is concerned.

Hence why I wrote (or, I think I wrote) 7182-derived TLV.

> =20
> But the protocol could impose some restrictions. For example =E2=80=9Cth=
e only thing allowed to be changed is this field in this TLV=E2=80=9D. =
Which it would therefore be a good idea for the creator of the message =
to include, even if it thus needed to include a link metric of zero. =
(Which is a design point - you might need to allow that in metric =
specification.) But you would need to state that. That enables some =
future designs - not 7182, possibly an extension to 7182, possibly =
something new.

YES, that=E2=80=99s my point.

> There is a problem that this idea would be putting in a need to =
understand specific TLVs, which is undesirable. I have some ideas there, =
such as using the protocol-specific space, but this isn=E2=80=99t a five =
minute job, and needs to be got right. While now is not the time to =
define this, some decisions could really impact on future designs. For =
example putting anything wanting to be mutable stuck in the middle of =
all the other TLVs would be constraining. Making all intended to be =
mutable by this protocol TLVs in the protocol specific space is probably =
the least bad idea, as that could be generalised (either making that =
space not covered by this hypothetical 7182 variant, or splitting it).

My position on that would be =E2=80=9Cnever change the structure of the =
message in transit=E2=80=9D and =E2=80=9Cnever change the length on a =
TLV in transit=E2=80=9D, and you=E2=80=99d have done a fairly good job =
of making it possible to do *something* clever for ICVs: the mutating =
field, which would be in a fixed position in the byte stream, you could =
zero that out, or do something else. 7182 does not do that. But =
something else might.

Not having that constraint means that =E2=80=9Csomething else=E2=80=9D =
would be impossible, would impede on extensibility.

> =20
> That leaves hop count/limit. Technically you wouldn=E2=80=99t =
increment/decrement, as it=E2=80=99s a new message. But you can send any =
hop limit on any new message, so that could be one less than the one you =
received. Hop count is a bit more arguable. I=E2=80=99m not sure how =
clearly its meaning is indicated, whether it is a =E2=80=9Creal=E2=80=9D =
hop count of this message. But if you needed to I wouldn=E2=80=99t be =
too strongly against doing what looks like incrementing that, as long as =
carefully explained.

Yes, I agree that that can be arguable.

Again, here my position is: if you change the slightest in the =
*structure* of the message, then a hop-count increment would be invalid =
(illegal? ;) )=20

Which is to say: regeneration =3D> don=E2=80=99t use hop-count/hop-limit =
(in my opinion).

> (A key question is if you use 5497 TLVs. In that case I think - =
combined with the =E2=80=9Conly change one thing above=E2=80=9D that you =
need to appear to increment hop limit, i.e. create a new message with a =
non-zero hop count.

Indeed, good catch. This document does, indeed, cite RFC5497 =
normatively. I=E2=80=99d not seen that interaction, but you are right it =
has to be matched up. I=E2=80=99ve not checked that/if it is.

Best,

Thomas

> =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 Thomas Clausen
> Sent: 20 April 2016 10:55
> To: Lotte Steenbrink
> Cc: Mobile Ad Hoc Networks mailing list
> Subject: [manet] On Forwarding-and-regeneration (was: Re: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
> =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
> Lotte, all,
> =20
> On 19 Mar 2016, at 12:34, Lotte Steenbrink =
> =
wrote:
>=20
> Hi Thomas,
> thank you for reviewing AODVv2 yet again :) Some answers below:
> =20
> Am 17.03.2016 um 17:00 schrieb ietf@thomasclausen.org =
:
> =20
> Dear all,
> =20
> Apologies for not having gotten this done sooner - day-job leaving few =
spare cycles.
> =20
> I=E2=80=99ve previously offered reviews and comments, and some of =
those have been addressed in the latest I-D =E2=80=94 others have not, =
but should be. I recall that there was some mail attempting to rebut =
parts of the review, and I will dig it out and reply to that.
> =20
> =20
> That wold be great.
> =20
> I am finding a bit of time here and there when there are holes in the =
agenda, and am (as you likely have noticed) backtracking through emails =
when I get a chance. Apologies, I hope that I will get to these emails =
this, or next week, but day-job eats in to the available time ;(
>=20
>=20
> Forwarding-vs-regeneration
> Recent exchanges on the list made me understand that protocol control =
messages are *not* forwarded, but are consumed at each hop, then a new =
message with (almost-but-not-quite) the same content is generated and =
transmitted.
> =20
> That=E2=80=99s what we=E2=80=99ve been trying to say all along! I=E2=80=99=
m really glad we=E2=80=99re having this conversation.
> =20
> Then, let us have it -- it's a central point to get right.
>=20
>=20
> I have thought some more on this (& read some of the exchanges on the =
list on this topic by Chris, Ulrich, and others), and I am convinced =
that this is not the right way to go, at least for the following =
reasons:
> =20
> =20
>             o          It renders the hop-limit/hop-count fields in =
the RFC5444 message header useless.
>                         This would not be bad if the functionality =
offered by those fields was not useful
>                         =E2=80=94 sadly, it is. For example, for scope =
limited flooding (expanding ring search, and=20
>                         such) which may be of interest, and which =
require hop-limit.=20
>                         A hop-count field may also provide a =
=E2=80=9Ccheap=E2=80=9D (in terms of overhead) additional piece
>                         of information to use conjunctively with a =
=E2=80=9Creal=E2=80=9D metric.
> =20
> =20
> I agree on the usefulness, which is why we were puzzled when we were =
told we weren=E2=80=99t allowed to use those fields (or, rather, that we =
were using them wrong, but that the right way to use them doesn=E2=80=99t =
work for AODvv2). I believe Vicky has written about this in more detail =
in previous discussions, and we were/are looking forward to reading your =
answers...
> =20
> So, the source generates a message, the message is forwarded through =
the network, with each intermediate router decrementing the hop limit =
and incrementing the hop count.
> =20
> As stated in the 5444-Usage document, when forwarding a message, the =
hop-limit/hop-count are modified, the rest of the message SHOULD not be.=20=

> =20
> That is specifically, one thing where I kinda would like 5444-usage to =
go further is "the message structure MUST in all conditions preserved =
when forwarding" - but still say "and it is RECOMMENDED that the value =
field of TLVs are also not modified".
> =20
> What this buys is several things, in the context of this protocol:
> =20
>             o          hop-limit/hop-count could be useful for the =
usual=20
>                         purposes (ensuring that messages do not live =
forever,=20
>                         scope-limited flooding, ...)
> =20
>             o          if the accumulated path metric is stored in a =
TLV value field, that=20
>                         value field can (with suitable disclaimer to =
call out "we know it is
>                         RECOMMENDED to not do this, but here's why we =
are OK in doing
>                         it anyways") be modified when forwarding the =
message, and
> =20
>             o          as that path metric field is in a message whose =
structure does not
>                         change, it will be "at the same place in the =
byte-stream" at each hop,
>                         which
>            =20
>             o          allows useful things such as deriving from =
RFC7182 a form of
>                         "when calculating the ICV, zero out that field =
in the message ' when
>                           validating an ICV, also zero out that field" =
-- which goes one step
>                           further (when coupled with a time stamp) =
than simple transitive trust,=20
>                           but also
> =20
>             o          allows even more fancy and useful (albeit =
experimental) things such
>                         as aggregate signatures to work correctly.
> =20
> Furthermore.....
>=20
>=20
>                         The only practical solution would be to =
re-introduce these functions by way of inserting a
>                         MessageTLV =E2=80=94 which (i) is not =
specified in this document, and (ii) which would just
>                         serve to render messages bigger than strictly =
needed.
> =20
> Exactly; we=E2=80=99d really like to avoid this as well.
> =20
> =20
> ... It avoids the above, and....
>=20
>=20
> =20
>                         Scope limited flooding  does seem to be a =
necessary requirement, if for no
>                         other reason than to prevent information from =
=E2=80=9Ccirculating forever in the network=E2=80=9D.
> =20
> AODVv2=E2=80=99s duplicated detection hopefully should take care of =
that. Iirc, We interpreted your earlier E-Mails to (implicitly) mean =
that you think we should rely on that, since you said we can=E2=80=99t =
use the hop-limit/hop-count fields.
> =20
> =20
> ....if done (proper forwarding with preservation of the structure, =
rather than regeneration which opens up the "this is a new message with =
potentially new structure" can of worms) as I describe, also addresses =
the above.
> =20
> With respect to what I said earlier when I said "can't use =
hop-limit/hop-count fields"....when you regenerate, you absolutely, =
definitely, can't.
>=20
>=20
> When you "regenerate" a message, that means "you construct a brand new =
message" which may shuffle addresses inside address blocks, or between =
address blocks, shuffle TLVs differently than they were originally, even =
use TLVs of different structure (e.g., single-value TLVs instead of =
multi-value TLVs).=20
>=20
>=20
> This means that some assumptions (such as when producing an ICV for =
the message, which depends on the byte order) don't hold. Well, they may =
not hold, so that means we can't assume that they do. Which means that =
the originator of a message cannot generate an ICV that can be correctly =
interpreted (which is what my next section in my original mail was =
about).
>=20
>=20
> Which means, in conclusion,  that the information in the message =
profoundly change -- and therefore these hop-count/hop-limit values do =
not even apply to "the information".=20
>=20
>=20
> However if proper forwarding with preservation of the structure, =
rather than regeneration which opens up the "this is a new message with =
potentially new structure" can of worms, as I (& Ulrich & others) have =
suggested, is taken to heart, it also addresses the issue below =
regarding end-to-end authentication (which, while still hard, is =
possible).
>=20
>=20
> A couple of more comments below
>=20
>=20
> =20
>             o          It makes end-to-end authentication =
unnecessarily hard.
>                         I think Chris called this out already, but it =
bears repeating: S generates a message=20
>                         (say, a RREQ), and includes an ICV calculated =
over the content of the message.
>                         For any recipient to be able to validate the =
ICV, the message has to be exactly
>                         the same =E2=80=94 not just in content, but in =
structure =E2=80=94 as what was generated.
> =20
>                         =E2=80=9CRegenerating=E2=80=9D rather than =
=E2=80=9Cforwarding=E2=80=9D messages means, that the intermediate
>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ =
may chose a different structure (e.g., include TLVs
>                         in a different order).
> =20
>                         The proposal from =
https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00 =

>                         is to add constraints on (i) the set of =
elements to include in a signature and (ii) the
>                         order of these elements.
> =20
>                         One problem with that approach is (i): if an =
extension adds a message TLV, or an=20
>                         Address TLV, to a message, then that will not =
be =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>                         Rather for *each* extension developed, an =
=E2=80=9Cupdates e2esec=E2=80=9D clause needs to be done.
> =20
>                         I=E2=80=99d say that this approach would be =
prone to errors =E2=80=94 and add entropy to the process
>                         of designing protocol extensions. The =
alternative, a message being generated by the
>                         source and *forwarded* (as we do in OLSRv2, =
for example) would allow ICV TLVs=20
>                         (even, allow reuse of those specified for =
OLSRv2) for covering a message and=20
>                         extensions.
> =20
>                         =E2=80=9CBut what about the metrics value =
which will change on each hop=E2=80=9D, you may say?
>                         Fortunately, that is relatively easy to =
handle: simply zero out the value of that TLV when
>                         generating or verifying the ICV MessageTLV. =
And use Packet-TLVs for hop-by-hop=20
>                         authentication, if needed (but, see below).
> =20
>             o          It prevents the use of more clever/advanced =
signature schemes/ICVs
>                         Aggregate signature algorithms ( =
https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf =
)
>                         exist, and an interesting use-case can be =
found in also reactive protocols, allowing verifying
>                         not =E2=80=9Cjust=E2=80=9D the end points, but =
also the intermediaries (again, with the appropriate =E2=80=9Czero =
out=E2=80=9D
>                         discussed above, or something smarter).
>                         Regeneration of messages, rather than =
forwarding, renders that impossible (or, if used,
>                         updating to  =
https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00 =
)
> =20
> There are other reasons, but the above are those that jump at me as =
immediate show-stoppers.
> =20
> I do honestly not see what possible benefit there is from =
=E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear =
inconveniences, and security is not the least of these. Insisting on =
=E2=80=9Cregeneration=E2=80=9D requires development of =E2=80=9Cnon-genera=
l workarounds=E2=80=9D as pointed out above.
> =20
> The possible benefit is that we need to accumulate & transport metric =
values somehow, and we can=E2=80=99t do that without regenerating at =
least parts of the message.
> If we=E2=80=99re missing a solution here, please share it with us.
> =20
> =20
> Done in the above.
>=20
>=20
> =20
> Security Considerations
> =20
> Just for context=E2=80=99s sake, did you review the security =
considerations in draft-ietf-manet-aodvv2-13 or the ones proposed in the =
thread =E2=80=9EAODVv2: Security considerations update=E2=80=9C?
> =20
> I did. It still is a far cry from passing the bar. I've posted on why =
in the past, and some more in this mail (which also contains some =
suggestions).
> =20
> I would suggest that settling the rearchitecturing to do forwarding, =
as I describe in the above, should be done, which would ease the =
security considerations issue considerably (and which would be necessary =
even if ignoring the security considerations, IMO, for this doc to go =
anywhere).=20
>=20
>=20
> With a new version covering that, the authors (I wanted to write =
"you", but decided to be inclusive) could you go look at the different =
security emails and perhaps start a separate thread on that, towards a =
resolution?
> =20
> =20
> Best,
> =20
> Thomas
> =20
>=20
>=20
>=20
>=20
> This is an always thorny subject. When OLSRv2 was going through the =
process we got a thorough education in how little we knew about security =
from the SEC-ADs, and had to spend about a year or so developing =
RFC7183. The bottom line is, that this protocol needs its =E2=80=9CRFC7183=
  equivalent=E2=80=9D, either as part of the main document, or as an =
independent document. currently, that is not the case.
> =20
> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration =
from RFC7183 might be aw good idea, as that was the most recent that =
went through the SEC AD. Regardless of how, however, a =E2=80=9Cmandatory =
to implement=E2=80=9D security mechanism most be specified (I think the =
right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D), in =
sufficient detail to ensure interoperable implementations.
> =20
> As an example, both [RFC6130] and [RFC7181] set out that that:
> =20
>       On receiving a ... message, a router MUST first check if the
>       message is invalid for processing by this router
> =20
> and then proceed to give a number of conditions that, each, will lead =
to a rejection of the message as "badly formed and therefore invalid for =
processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That =
gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting =E2=80=9Crejection=
=E2=80=9D. Idem for message generation.
> =20
> If I was to do RFC7181/RFC6130 today, I would include that directly =
into the protocol specifications. It turned out to be more overhead (and =
slow down publication anyways) to do it as separate documents.
> =20
> Secondly, we need to be a lot more rigid in terms of what ICVs, =
Timestamps, etc. are added/removed, and what that brings.
> =20
> For example (with the assumption that messages are *forwarded* and =
*not* regenerated), this could be one option:
> =20
>                         o          When a RREQ, RREP message is =
generated, add an ICV Message TLV, which is calculated 
>                                      =E2=80=A6(take inspiration from =
RFC7183 here)
> =20
>                         o          When a RREQ, RREP message is =
transmitted  (by the source, or forwarded by an intermediary)
>                                     in an RFC5444 packet, an ICV =
Packet TLV is added to the packet, which is calculated  =E2=80=A6=

> =20
>                         o          When an RFC5444 packet is received, =
validate the ICV Packet TLV  and if the ICV doesn=E2=80=99t =
validate,
>                                     discard the contained messages.
> =20
>                         o          When receiving a RREQ/RREP (either =
as destination, or as an intermediary), validate the ICV Message TLV=20
>                                      and if the ICV =
doesn=E2=80=99t validate, discard the message, do not process, do not =
forward.
> =20
> This is a different (and more flexible?) model than =E2=80=9Cjust=E2=80=9D=
 transitive trust and =E2=80=9Cjust=E2=80=9D end-to-end trust discussed =
previously, and is enabled by the =E2=80=9Cforwarding=E2=80=9D bit =
described previously.
> =20
> Metrics
> I have asked this numerous times, but have not gotten any answer so I =
am escalating this again. Why is this document having a normative =
reference to RFC6551?
> =20
>    [RFC6551 <>]  Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, =
N.,
>               and D. Barthel, "Routing Metrics Used for Path =
Calculation
>               in Low-Power and Lossy Networks", RFC 6551 =
, DOI 10.17487/
>               RFC6551 , March =
2012,
>               >.
> =20
> =20
> Unless I am mistaken, this is not the ROLL WG. And the abstract to =
RFC6551 explicitly reads:
> =20
>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>    compared with traditional wired and ad hoc networks that require =
the
>    specification of new routing metrics and constraints. =20
> Which explicitly is disclaiming that these metrics are not applicable =
in ad hoc networks=E2=80=94 and, I am wondering, what has changed since =
the publication of RFC6551 to suddenly make these applicable?
> =20
>  I am also wondering if looking at (and, perhaps, using?) the same =
metric type TLV type as in OLSRv2 is not a possibility?
> =20
> Either way, referencing RFC6551 here is wrong.
> =20
> RFC6621 (SMF) usage
> As late as earlier this month, RFC6621 reared its head again on the =
mailing list. I understand that the authors are set on using flooding =
reduction as part of RREQ distribution. If that is the case, then this =
protocol MUST specify that flooding reduction.=20
> =20
> Saying =E2=80=9CUse RFC6621=E2=80=9D won=E2=80=99t work, for reasons =
Chris point out in an email earlier to the list:
> The network does not and fundamentally cannot offer multicast =
suppression to AODVv2. This isn't a hard concept, but seems to keep =
having to be said. AODVv2 messages are carried in 5444 packets, and =
those only travel one hop. That doesn't allow for suppression. =
Furthermore AODVv2 is creating new messages each hop. That needs AODVv2 =
specific handling.
> =20
> And quoting an email from myself:
> If protocol X relies on using a flooding operation, then it certainly =
is protocol X's responsibility to  specify the flooding operation (or, =
at least, the requirements to the flooding operation ) for correct =
functioning of protocol X.
> =20
> I=E2=80=99ve previously pointed out that RFC6621 requires some degree =
of configuration (can=E2=80=99t just, for example, pick two different =
relay set selection algorithms, as that may produce a disconnected =
flooding domain).
> =20
> In other words, what the authors propose in =
https://tools.ietf.org/html/draft-perkins-manet-using-rfc6621-00 =
 is =
insufficient.
> =20
> Multiple interfaces configured with the same address(es) - & RFC6621
> I think that it has been established that the ability to use the same =
address on multiple interfaces is a requirement. It=E2=80=99s not clear =
to me that a single way of doing so has been proposed, nor that the =
=E2=80=9Coperating conditions=E2=80=9D are called out (for example, will =
it work  if router A and router B both have two interfaces, and that all =
4 interfaces use the same IP address?)
> =20
> This is not entirely unrelated to flooding reduction and RFC6621. One =
of the complexities is to get that just right: OLSRv2 - for example - =
calculates Flooding-MPRs per interface, and RFC6130 is careful in how it =
detects bidirectionality of links.=20
> =20
> I have not worked out all the details of how this impacts this =
protocol =E2=80=94 but, it requires attention. Especially when wanting =
to be able to say =E2=80=9C=E2=80=A6use RFC6621=E2=80=9D, then the =
interface configuration constraints when faced with multiple interfaces =
must be worked out.
> =20
> Prefixes & Gateways
> A question to my mind, and I am not sure I know how to answer that =
from reading the draft since it is not discussed in section 9 (at =
least), is: =E2=80=9CWhat happens if I send a RREQ to a prefix=E2=80=9D =
(i.e., a /<128 in IPv6)?
> =20
>             o          If the whole prefix is part of the attached =
network set of a single router,=20
>                         then I expect to get a single RREP back, is =
that the case?
> =20
>             o          If "half the prefix"  is part of the attached =
network set of a single router,=20
>                         and the other half is part of the attached =
network set of another  single router,=20
>                         then I expect two RREPs, is that the case?
> =20
>             o          More generally, will I get a tree build through =
the network here?
> =20
> AODVv2 currently doesn=E2=80=99t support RREQs for prefixes. I=E2=80=99v=
e already added =E2=80=9EIf RteMsg is a RREQ, RteMsg.TargPrefixLen =
SHOULD equal address length.=E2=80=9C to RteMsg.TargPrefixLen in section =
 <>4.6 =
. =
Multicast Route Message Table in response to Justin=E2=80=99s comments, =
but I=E2=80=99ll go through the draft again and see where we need to =
state this more clearly.
> =20
> Best regards,
> Lotte Steenbrink
>=20
>=20
> =20
> Section 9 (or, the whole spec) is also not explicit enough about =
multiple  "default gateways" =E2=80=94 i.e., the external network being =
=E2=80=9Cthe rest of the Internet=E2=80=9D, and there being multiple =
gateways to the Internet. I understand how the RREQ gets to the gateway, =
and how the gateway determines if it should respond (the destination is =
not part of =E2=80=9Cthe MANET prefix, with which it is configured=E2=80=9D=
).
> =20
> But, if A is close to GW1, and B is close to GW2, but A and B being =
far far apart (according to the metric used) within the MANET, then it =
would be preferential for the route from A to B to go via =
GW1-=E2=80=9Cthe-Internet=E2=80=9D-GW2?=20
> =20
> Is this a supported configuration?=20
>             o          If yes, how is it (seq# wise, I would expect =
some complications) handled?=20
>             o          If not, where is it stated that this =
configuration is not possible with this protocol?
> =20
> =20
> The applicability statement says:
> =20
>    AODVv2 is designed for stub or disconnected mobile ad hoc networks,
>    i.e., non-transit networks or those not connected to the internet.
>    AODVv2 can, however, be configured to perform gateway functions =
when
>    attached to external networks, as discussed in Section 9 =
.
> =20
> I believe that the scenario I describe is indeed a stub network (and =
not a transit network)?
> =20
> =E2=80=94 =E2=80=94 =E2=80=94=20
> =20
> As I indicated, these are the big-picture issues that I have gotten =
around to thinking about enough to write up. I=E2=80=99m not through =
working through the document, but those were the ones that came to mind, =
and which seem imperative to resolve.
> =20
> Best,
> =20
> Thomas
> =20
> =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=_74B250BC-6EDB-4390-802A-5A50F2BE98F4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Chris, all,


 
Security =
Considerations
 
Just for context=E2=80=99s sake, did you review the =
security considerations in draft-ietf-manet-aodvv2-13 or the ones =
proposed in the thread =E2=80=9EAODVv2: Security considerations =
update=E2=80=9C?
 
 
I would suggest that settling the rearchitecturing to =
do forwarding, as I describe in the above, should be done, which would =
ease the security considerations issue considerably (and which would be =
necessary even if ignoring the security considerations, IMO, for this =
doc to go anywhere). 


With a new version covering that, the =
authors (I wanted to write "you", but decided to be inclusive) =
could you go look at the different security emails and perhaps =
start a separate thread on that, towards a resolution?
 
Best,
 
Thomas
 




This =
is an always thorny subject. When OLSRv2 was going through the process =
we got a thorough education in how little we knew about security from =
the SEC-ADs, and had to spend about a year or so developing RFC7183. The =
bottom line is, that this protocol needs its =E2=80=9CRFC7183 =
 equivalent=E2=80=9D, either as part of the main document, or as an =
independent document. currently, that is not the case.
A minima, looking at BCP72 and BCP107 =E2=80=
=94 taking inspiration from RFC7183 might be aw good idea, as that was =
the most recent that went through the SEC AD. Regardless of how, =
however, a =E2=80=9Cmandatory to implement=E2=80=9D security mechanism =
most be specified (I think the right term was =E2=80=9CMUST implement, =
SHOULD use=E2=80=9D), in sufficient detail to ensure interoperable =
implementations.
As an example, both [RFC6130] and =
[RFC7181] set out that that:
 
      On receiving a ... message, a =
router MUST first check if the
      =
message is invalid for processing by this router
and then proceed to give a number of =
conditions that, each, will lead to a rejection of the message as "badly =
formed and therefore invalid for processing=E2=80=9D =E2=80=94 a list =
which RFC7183 then amended. That gave a =E2=80=9Chook=E2=80=9D for =
RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message =
generation.
 
If I was to do RFC7181/RFC6130 today, I would include =
that directly into the protocol specifications. It turned out to be more =
overhead (and slow down publication anyways) to do it as separate =
documents.
 
Secondly, we need to be a lot more rigid in terms of =
what ICVs, Timestamps, etc. are added/removed, and what that brings.
For example (with the assumption that =
messages are *forwarded* and *not* regenerated), this could be one =
option:
 
        &=
nbsp;           &nb=
sp;   o        &=
nbsp; When a =
RREQ, RREP message is generated, add an ICV Message TLV, which is =
calculated <this way>
        &=
nbsp;           &nb=
sp;            =
;    =E2=80=A6(take =
inspiration from RFC7183 here)
 
        &=
nbsp;           &nb=
sp;   o        &=
nbsp; When a =
RREQ, RREP message is transmitted  (by the source, or forwarded by =
an intermediary)
        &=
nbsp;           &nb=
sp;            =
;   in =
an RFC5444 packet, an ICV Packet TLV is added to the packet, which is =
calculated <this way> =E2=80=A6
        &=
nbsp;           &nb=
sp;   o        &=
nbsp; When an =
RFC5444 packet is received, validate the ICV Packet TLV <this way> =
and if the ICV doesn=E2=80=99t validate,
 
        &=
nbsp;           &nb=
sp;   o        &=
nbsp; When =
receiving a RREQ/RREP (either as destination, or as an intermediary), =
validate the ICV Message TLV 
        &=
nbsp;           &nb=
sp;            =
;   <this way> and =
if the ICV doesn=E2=80=99t validate, discard the message, do not =
process, do not forward.
 
This is a different (and more flexible?) model than =
=E2=80=9Cjust=E2=80=9D transitive trust and =E2=80=9Cjust=E2=80=9D =
end-to-end trust discussed previously, and is enabled by the =
=E2=80=9Cforwarding=E2=80=9D bit described previously.
Metrics
I have asked this =
numerous times, but have not gotten any answer so I am escalating this =
again. Why is this document having a normative reference to RFC6551?
   [RFC6551]  =
Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
          &nb=
sp;   and D. Barthel, "Routing Metrics Used for Path =
Calculation
          &nb=
sp;   in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/
          &nb=
sp;   RFC6551, March 2012,
          &nb=
sp;   <http://www.rfc-editor.org/info/rfc6551>.
 
 
Unless I am mistaken, this is not the ROLL WG. And =
the abstract to RFC6551 explicitly reads:
 
   Low-Power and Lossy Networks (LLNs) have unique =
characteristics
   compared with traditional wired and ad hoc =
networks that require the
   specification of new routing metrics and =
constraints.  
Which explicitly is disclaiming that =
these metrics are not applicable in ad hoc =
networks=E2=80=94 and, I am wondering, what has changed since =
the publication of RFC6551 to suddenly make these applicable?
 
 I am also wondering if looking at =
(and, perhaps, using?) the same metric type TLV type as in OLSRv2 is not =
a possibility?
 
Either way, referencing RFC6551 here is wrong.
 
RFC6621 (SMF) =
usage
As late as earlier this month, RFC6621 =
reared its head again on the mailing list. I understand that the authors =
are set on using flooding reduction as part of RREQ distribution. If =
that is the case, then this protocol MUST specify that flooding =
reduction. 
 
Saying =E2=80=9CUse RFC6621=E2=80=9D won=E2=80=99t =
work, for reasons Chris point out in an email earlier to the list:
The network does not and fundamentally =
cannot offer multicast suppression to AODVv2. This isn't a hard concept, =
but seems to keep having to be said. AODVv2 messages are carried in =
5444 packets, and those only travel one hop. That doesn't allow for =
suppression. Furthermore AODVv2 is creating new messages each hop. =
That needs AODVv2 specific handling.
 
And quoting an email from myself:
If protocol X relies on using a flooding =
operation, then it certainly is protocol X's responsibility to =
 specify the flooding operation (or, at least, the =
requirements to the flooding operation ) for correct functioning of =
protocol X.
 
I=E2=80=99ve =
previously pointed out that RFC6621 requires some degree of =
configuration (can=E2=80=99t just, for example, pick two different relay =
set selection algorithms, as that may produce a disconnected flooding =
domain).
 
In other words, what the authors propose in https://tools.ietf.org/html/draft-perkins-manet-using-rfc6621-0=
0 is insufficient.
 
Multiple interfaces =
configured with the same address(es) - & RFC6621
I think that it has been established that the ability to use =
the same address on multiple interfaces is a requirement. It=E2=80=99s =
not clear to me that a single way of doing so has been proposed, nor =
that the =E2=80=9Coperating conditions=E2=80=9D are called out (for =
example, will it work  if router A and router B both have two =
interfaces, and that all 4 interfaces use the same IP address?)
 
This is not entirely unrelated to =
flooding reduction and RFC6621. One of the complexities is to get that =
just right: OLSRv2 - for example - calculates Flooding-MPRs per =
interface, and RFC6130 is careful in how it detects bidirectionality of =
links. 
 
I have not worked out all the details of how this =
impacts this protocol =E2=80=94 but, it requires attention. Especially =
when wanting to be able to say =E2=80=9C=E2=80=A6use RFC6621=E2=80=9D, =
then the interface configuration constraints when faced with multiple =
interfaces must be worked out.
 
Prefixes & =
Gateways
A question to my mind, and I am not sure =
I know how to answer that from reading the draft since it is not =
discussed in section 9 (at least), is: =E2=80=9CWhat happens if I send a =
RREQ to a prefix=E2=80=9D (i.e., a /<128 in IPv6)?
 
        &=
nbsp;   o        &=
nbsp; If the =
whole prefix is part of the attached network set of a single =
router, 
        &=
nbsp;           &nb=
sp;   then I expect to get =
a single RREP back, is that the case?
 
        &=
nbsp;   o        &=
nbsp; If "half =
the prefix"  is part of the attached network set of a single =
router, 
        &=
nbsp;           &nb=
sp;   and the other half =
is part of the attached network set of another  single =
router, 
        &=
nbsp;           &nb=
sp;   then I expect two =
RREPs, is that the case?
 
        &=
nbsp;   o        &=
nbsp; More =
generally, will I get a tree build through the network here?
 
AODVv2 currently doesn=E2=80=99t support RREQs for =
prefixes. I=E2=80=99ve already added =E2=80=9EIf RteMsg is a RREQ, RteMsg.TargPrefixLen SHOULD =
equal address length.=E2=80=9C to RteMsg.TargPrefixLen in =
section 4.6. Multicast Route Message =
Table in response to Justin=E2=80=99s comments, but I=E2=80=99ll =
go through the draft again and see where we need to state this more =
clearly.
 
Best regards,
Lotte Steenbrink


 
Section 9 (or, the whole spec) is also not explicit =
enough about multiple  "default gateways" =E2=80=94 i.e., the =
external network being =E2=80=9Cthe rest of the Internet=E2=80=9D, and =
there being multiple gateways to the Internet. I understand how the RREQ =
gets to the gateway, and how the gateway determines if it should respond =
(the destination is not part of =E2=80=9Cthe MANET prefix, with which it =
is configured=E2=80=9D).
 
But, if A is close to GW1, and B is close to GW2, but =
A and B being far far apart (according to the metric used) within the =
MANET, then it would be preferential for the route from A to B to go via =
GW1-=E2=80=9Cthe-Internet=E2=80=9D-GW2? 
 
Is this a supported =
configuration? 
        &=
nbsp;   o        &=
nbsp; If yes, =
how is it (seq# wise, I would expect some complications) =
handled? 
        &=
nbsp;   o        &=
nbsp; If not, =
where is it stated that this configuration is not possible with this =
protocol?
 
 
The applicability =
statement says:
 
   AODVv2 is designed =
for stub or disconnected mobile ad hoc networks,
   i.e., non-transit networks or those not =
connected to the internet.
   =
AODVv2 can, however, be configured to perform gateway functions when
   attached to external networks, as discussed in =
Section =
9.
 
I believe that the scenario I describe is indeed a =
stub network (and not a transit network)?
 
=E2=80=94 =E2=80=94 =E2=80=94 
 
As I indicated, these are the big-picture =
issues that I have gotten around to thinking about enough to write up. =
I=E2=80=99m not through working through the document, but those were the =
ones that came to mind, and which seem imperative to resolve.
 
Best,
 
Thomas
 
 
 
_______________________________________________
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=_74B250BC-6EDB-4390-802A-5A50F2BE98F4--



From nobody Wed Apr 20 09:12:15 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 83EDC12E498; Wed, 20 Apr 2016 09:12:14 -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: <20160420161214.759.27670.idtracker@ietfa.amsl.com>
Date: Wed, 20 Apr 2016 09:12:14 -0700
Archived-At: 
Cc: manet@ietf.org
Subject: [manet] I-D Action: draft-ietf-manet-aodvv2-15.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, 20 Apr 2016 16:12:14 -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-15.txt
	Pages           : 78
	Date            : 2016-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.


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-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-aodvv2-15


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 Apr 20 10:31: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 C07AE12EF81 for ; Wed, 20 Apr 2016 10:31:14 -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 j-xcRMpAjA_w for ; Wed, 20 Apr 2016 10:31:09 -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 A64D712EF7F for ; Wed, 20 Apr 2016 10:31:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6A7522464D2 for ; Wed, 20 Apr 2016 10:31:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461173460; bh=GMX/LwgpuMmXuKjgn/NfeJuzZeI5nPKBULCnk7PTcMQ=; h=From:Subject:Date:References:In-Reply-To:To:From; b=DENTgzzPR+0cg4PGtwHNmoZqBJlH+qyTGeOaOqtzhbfgXdbkpLGOYB3oNZvhPMwWA y956AHo7fCKkVPIFwqwBjAxABtUB2YJu9oLbVMF9TLNR6ffsShs2qtUMZcI/DBzKN0 MNPxvVxi9Xs+8hGLKnbUERiFW9p+I5aUo+QOdyt4=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [10.159.70.58] (unknown [37.160.173.6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A894D24026F for ; Wed, 20 Apr 2016 10:30:59 -0700 (PDT)
From: Thomas Heide Clausen 
Content-Type: multipart/alternative; boundary=Apple-Mail-C34B6EC3-AEEC-4309-809A-361846AD62E4
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Message-Id: <20DE293D-DD2E-42C1-A105-8DE1DFC0ED04@thomasclausen.org>
Date: Wed, 20 Apr 2016 19:30:56 +0200
References: <20160420161214.759.27670.idtracker@ietfa.amsl.com>
In-Reply-To: <20160420161214.759.27670.idtracker@ietfa.amsl.com>
To: manet@ietf.org
X-Mailer: iPhone Mail (13E238)
Archived-At: 
Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-15.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, 20 Apr 2016 17:31:15 -0000

--Apple-Mail-C34B6EC3-AEEC-4309-809A-361846AD62E4
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

 Hi,

I can see a new revision has been spun of this document. Thanks, good job be=
ing reactive (pun intended). =20

As a cursory glance confirms that the issues discussed today on the list are=
 of course not addressed -- which of course is totally understandable: there=
 were quite a few, and they were literally just raised or reopened. I gather=
 that the authors had planed to spin this revision for a while, so just "poo=
r timing" on my part i guess.=20

To avoid another bout of poor timing, when do you (=3Dauthors) guesstimate t=
o spin the next version, and have you identified the list of issues that you=
 plan on emphasizing and therefore want the WGs attention to? I'd do my darn=
est to try and get my comments out (even, with a margin to discuss and act o=
n them) ...

On another topic, I see that the document status now is indicated as Experim=
ental - and that the changes section in the end confirms this to be intentio=
nal.=20

I think that is a good strategy (so, thanks, guys) since the past years have=
 indicated that there remain numerous things still to resolve with this prot=
ocol.=20

One question, though, if I may? The only discussion of "the experiment" that=
 I can find is this:

> The purpose of the experiment with AODVv2 is to gain information on the be=
havior of the protocol in real-world deployments, furthering the knowledge b=
ase of both reactive protocols in general, and with AODVv2 in particular. An=
other goal of the experiment is to determine if sufficient demand exists for=
 the AODVv2 protocol to prompt an effort to bring the protocol to Standards T=
rack.


I wonder in which ways this experiment is different from the one already ena=
bled by the existing experimental AODV RFC3561?

I'll get on with a more detailed reading of -15.=20

Best,

Thomas

> On 20 avr. 2016, at 18:12, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts directo=
ries.
> 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 (AODVv=
2) Routing
>        Authors         : Charles E. Perkins
>                          Stan Ratliff
>                          John Dowdell
>                          Lotte Steenbrink
>                          Victoria Mercieca
>    Filename        : draft-ietf-manet-aodvv2-15.txt
>    Pages           : 78
>    Date            : 2016-04-20
>=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-15
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-15
>=20
>=20
> Please note that it may take a couple of minutes from the time of submissi=
on
> 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

--Apple-Mail-C34B6EC3-AEEC-4309-809A-361846AD62E4
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


 Hi,

I c=
an see a new revision has been spun of this document. Thanks, good job being=
 reactive (pun intended).  

As a cursory glanc=
e confirms that the issues discussed today on the list are of course not add=
ressed -- which of course is totally understandable: there were quite a few,=
 and they were literally just raised or reopened. I gather that the authors h=
ad planed to spin this revision for a while, so just "poor timing" on my par=
t i guess. 

To avoid another bout of poor timi=
ng, when do you (=3Dauthors) guesstimate to spin the next version, and have y=
ou identified the list of issues that you plan on emphasizing and therefore w=
ant the WGs attention to? I'd do my darnest to try and get my comments out (=
even, with a margin to discuss and act on them) ...

On another topic, I see that the document status now is indicated as Experi=
mental - and that the changes section in the end confirms this to be intenti=
onal. 

I think that is a good strategy (so, th=
anks, guys) since the past years have indicated that there remain numerous t=
hings still to resolve with this protocol. 

On=
e question, though, if I may? The only discussion of "the experiment" that I=
 can find is this:

The purpose of the ex=
periment
   with AODVv2 is to gain information on the behavior of the protocol in
   real-world deployments, furthering the knowledge base of both
   reactive protocols in general, and with AODVv2 in particular.
   Another goal of the experiment is to determine if sufficient demand
   exists for the AODVv2 protocol to prompt an effort to bring the
   protocol to Standards Track.
<=
br>
I wonder in which ways this experiment is different from the o=
ne already enabled by the existing experimental AODV RFC3561?

=

I'll get on with a more detailed reading of -15. 
=

Best,

Thomas

On 20 avr=
. 2016, at 18:12, internet-draft=
s@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Dra=
fts directories.
This draft is a work item of the Mobile Ad-=
hoc Networks of the IETF.

   &nbs=
p;    Title        &n=
bsp;  : Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routin=
g
        Authors  &=
nbsp;      : Charles E. Perkins
             &=
nbsp;            =
;Stan Ratliff
        &nb=
sp;            &=
nbsp;    John Dowdell
    =
;            &nb=
sp;         Lotte Steenbrink
           &=
nbsp;            =
;  Victoria Mercieca
    Filename  =
      : draft-ietf-manet-aodvv2-15.txt<=
br>    Pages         =
;  : 78
    Date     =
;       : 2016-04-20

Abstract:
   The Ad Hoc On-demand Dis=
tance Vector Version 2 (AODVv2) routing
   protoco=
l 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 fas=
hion.


The IETF datatracker=
 status page for this draft is:
https://datatracker.ietf.org/doc/d=
raft-ietf-manet-aodvv2/

There's also a h=
tmlized version available at:
https://tools.ietf.org/html/draft-ietf-=
manet-aodvv2-15

A diff from the previou=
s version is available at:
https://www.ietf.org/rfcdiff?url2=3D=
draft-ietf-manet-aodvv2-15


<=
span>Please note that it may take a couple of minutes from the time of submi=
ssion
until the htmlized version and diff are available at <=
a href=3D"http://tools.ietf.org">tools.ietf.org.
=

Internet-Drafts are also available by anonymous FTP at:
=
ftp://ftp.ietf.org/int=
ernet-drafts/

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

--Apple-Mail-C34B6EC3-AEEC-4309-809A-361846AD62E4--


From nobody Wed Apr 20 10:41: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 1CADF12EFD5 for ; Wed, 20 Apr 2016 10:41: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 Le4CxyAV8m4U for ; Wed, 20 Apr 2016 10:41:02 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001: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 135AD12EFD2 for ; Wed, 20 Apr 2016 10:41:02 -0700 (PDT)
Received: by mail-ig0-x22b.google.com with SMTP id m9so43757230ige.1 for ; Wed, 20 Apr 2016 10:41:02 -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=llAVeDjHW6KImuQue6ftqEeGVAaNhtSNfV42yWTcMpk=; b=d5UAp6iQ7pTEtG9l9m0VbR+RJwy7Mp56gSG2kf3TAol7p4RibIH+coMAUyPjBFJ46p foRyxL1lq58HHnSQvVMjQjf2ez87P+gFVf3ehkyWTNxht3QlyXG1t4D65v2c8Gs+dsWO h0vL6TQGfT3W0uN5ezGwK5tjOcuglW4PQLNiFyen0YuX+IrQioqiW5D59hZO0Ukaqo+u /aWNWmVRz9bSd00K+XeEkG/FaWiI70MZoaG+JSsGB5iiE1QteP87ikjJO+nyjyF7QNW0 TOBVmLzo24vuOjulOLr/KJQLGHcc6r4Bo557TTZdU3M749nroaSUOBU7J7StjNRYIAI+ r+3w==
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=llAVeDjHW6KImuQue6ftqEeGVAaNhtSNfV42yWTcMpk=; b=OTyhzCh9wDrDiZkavYBk50gYwOlG+Xp5Th+he8cO86z8Hnhj7YeUeBTP3TK9LBVRhg kuIG+zNnFJ/1mU+tN0zI7q8w2//FJsTFnmGWlgwTNGMluxWZpivECy3kNYIa1lstqcml pjwE7n0XSU/M9z+sc0s6h2WoU/YOII5WTlSkFFCGT58hONH8u7HUXH9OZtZM4XBuclQf l/uypk1EqLEFZsSNEmMr0zgPlqRFm0mLHoami7vJxzSj0DXVFLvpFYVzp7ROJ31YNYXL 9RXVasroZ76zuN/kdh6TkJBrPm4bmp66uiISsShQVhZMFwUKASEG0rfRSL8z7XoWbuue 7MKg==
X-Gm-Message-State: AOPr4FWmyAj3A3jGsTpSAttdTJ2gQYy8QXLlQ4gstZBC8T51YqqBUPU4f66epJ1XhvyBHC2mrB8X3STs36HgvQ==
MIME-Version: 1.0
X-Received: by 10.50.108.106 with SMTP id hj10mr4847684igb.36.1461174060479; Wed, 20 Apr 2016 10:41:00 -0700 (PDT)
Received: by 10.79.72.68 with HTTP; Wed, 20 Apr 2016 10:41:00 -0700 (PDT)
Date: Wed, 20 Apr 2016 13:41:00 -0400
Message-ID: 
From: Stan Ratliff 
To: MANET IETF 
Content-Type: multipart/alternative; boundary=089e01536be6d480240530ee1852
Archived-At: 
Subject: [manet] AODVv2-15
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, 20 Apr 2016 17:41:13 -0000

--089e01536be6d480240530ee1852
Content-Type: text/plain; charset=UTF-8

Hello all,

As you've seen, a new version of the AODVv2 draft has been posted. Some of
the items addressed are:

1. First up, the status of the document has been changed from Standards
Track to Experimental.
2. Metrics have been addressed, in an attempt to resolve most (if not all)
of the review comments.
3. There has been work in the multicast RREQ/RREP area.
4. The remainder of Justin's last review comments were addressed.

I'm positive I'm leaving some things out, but that's the part of the list I
can remember.

Given the scope change on the document (from Standards Track to
Experimental), we authors are asking for WGLC on the document.

Regards,
Stan

--089e01536be6d480240530ee1852
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hello all,=C2=A0

As you've seen, a =
new version of the AODVv2 draft has been posted. Some of the items addresse=
d are:=C2=A0

1. First up, the status of the docume=
nt has been changed from Standards Track to Experimental.=C2=A0
2=
. Metrics have been addressed, in an attempt to resolve most (if not all) o=
f the review comments.=C2=A0
3. There has been work in the multic=
ast RREQ/RREP area.=C2=A0
4. The remainder of Justin's last r=
eview comments were addressed.=C2=A0

I'm posit=
ive I'm leaving some things out, but that's the part of the list I =
can remember.=C2=A0

Given the scope change on the =
document (from Standards Track to Experimental), we authors are asking for =
WGLC on the document.=C2=A0

Regards,
Sta=
n


--089e01536be6d480240530ee1852--


From nobody Wed Apr 20 10:50:53 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 E510312DF28 for ; Wed, 20 Apr 2016 10:50:52 -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 zkC9hgtn19oT for ; Wed, 20 Apr 2016 10:50:51 -0700 (PDT)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c: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 A4ECB12DDC7 for ; Wed, 20 Apr 2016 10:50:51 -0700 (PDT)
Received: by mail-vk0-x230.google.com with SMTP id n62so68433434vkb.0 for ; Wed, 20 Apr 2016 10:50:51 -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=UGprHvkIfSOEvioI/Au+FCS7fGFKn6waZgOLweCzRnE=; b=tan7mgnSzknrx7jX0QimMxOGck0BclZeGSwNd7zpM+qvEm0aYyYEbXu3j7yfwzZIxV /zusjpfKC0tQCeOxVH+oEOdaU7QOLz+XDhxc618mK8ktZxnrREHn0ITuTu3wMqdhlPtB RvHVELNvLJClm6iQL+kqBaXB7ozViLmdEVSWB3OXKwcZECFeQnKbgoA1xoOGQomU5+av sQC8CprYbs5+y6VLFqTci+2m6CnlSP96xw2+ajJNkR+Sqor20dfrjWb/kRL4LsAZM1fw qCyXB5+qB8eWnSe2nPmKwkDyDaGRbaMFmEM3Lb3Y3iEiETuQrgRFd+BuP2tUqDVnBDJX 70og==
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=UGprHvkIfSOEvioI/Au+FCS7fGFKn6waZgOLweCzRnE=; b=cBgaA6w3ducnFDdHKwQL7oGHf2vq2ntUIruXX6FQIJYOYC6zHBooQGDsmoYRW3iRYK Gh53eZYvmOaPzo37QL74bU8zMZb1MmJ+3eZRvqvADFu0UrohDW63xGMnis22NNg1TW9v QUaMZNnNrAlzGChEZa51BL8PLC1A2OYUc5Wel3Dsl4SZ1GI6e7hkQGX0SFOC2Hgsiawz vWcWZuMsAFsvsxgvcfPu4LD+fdJZWibweRmopiZEk/ETk+2nBx8JDOoVT3G7XuS5tBYV 33X2Yt0Cgi5HiqbHdqCwSyRoDAcoghppHfX9X808yBOOQYOCIeD9Yo1RykB8v5yxBvQD AoRA==
X-Gm-Message-State: AOPr4FWT13IFMj64EDrrd/eO002YlnbEG1C1E+ugplw/fG9eFrSHN2xmoEzqWrtP+CBV5UIZh9kOF4IWPtaeXA==
MIME-Version: 1.0
X-Received: by 10.31.108.152 with SMTP id j24mr1255100vki.105.1461174650834; Wed, 20 Apr 2016 10:50:50 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Wed, 20 Apr 2016 10:50:50 -0700 (PDT)
Date: Wed, 20 Apr 2016 13:50:50 -0400
Message-ID: 
From: Justin Dean 
To: Thomas Heide Clausen 
Content-Type: multipart/alternative; boundary=001a1147a3500497650530ee3ca2
Archived-At: 
Cc: "manet@ietf.org" 
Subject: [manet] New AODVv2 draft and status
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, 20 Apr 2016 17:50:53 -0000

--001a1147a3500497650530ee3ca2
Content-Type: text/plain; charset=UTF-8

As Thomas has noted the status has changed to experimental.  You beat the
authors to the punch in noticing that before they posted up an overview
email.  In short, we, the working group are out of time. It's now time to
finish this document.  Not all open issues (ones brought up today or not
decided upon) metrics, security, and a few others have not been
incorporated into this updated draft.  Regardless we are out of time and we
need to move on to other work specifically having a new charter finished
and approved before the next IETF.

So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended status
change, updates to the draft, and my review, and continued intense work
from the editorship team and the working group there is a chance of
success.  The working group will have 2 weeks to provide input at which
time I'll make the call to pass it on up to the IESG or remove it as a WG
item and hand it back to the authors to do with it what they will.

Due to the short timeline we will also need to discuss and come to
consensus on a new WG charter. I'll start that in another email thread.

Justin

p.s. I'm looking forward to continued positive discussions and
improvements.  AODVv2 I STRONGLY encourage you to use (almost exclusively
to the extent possible) the MANET list for all future AODVv2 discussions
within this last call period.

--001a1147a3500497650530ee3ca2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


As Thomas has noted the status =
has changed to experimental.=C2=A0 You beat the authors to the punch in not=
icing that before they posted up an overview email.=C2=A0 In short, we, the=
 working group are out of time. It's now time to finish this document.=
=C2=A0 Not all open issues (ones brought up today or not decided upon) metr=
ics, security, and a few others have not been incorporated into this update=
d draft.=C2=A0 Regardless we are out of time and we need to move on to othe=
r work specifically having a new charter finished and approved before the n=
ext IETF. 

So, I'll be issuing a 2 week WGLC on AODVv2.=C2=A0 Gi=
ven the intended status change, updates to the draft, and my review, and co=
ntinued intense work from the editorship team and the working group there i=
s a chance of success.=C2=A0 The working group will have 2 weeks to provide=
 input at which time I'll make the call to pass it on up to the IESG or=
 remove it as a WG item and hand it back to the authors to do with it what =
they will.

Due to the short timeline we will also need to discuss an=
d come to consensus on a new WG charter. I'll start that in another ema=
il thread.

Justin

p.s. I'm looking forward to continued p=
ositive discussions and improvements.=C2=A0 AODVv2 I STRONGLY encourage you=
 to use (almost exclusively to the extent possible) the MANET list for all =
future AODVv2 discussions within this last call period.


--001a1147a3500497650530ee3ca2--


From nobody Wed Apr 20 10:56: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 6C4C512E23D for ; Wed, 20 Apr 2016 10:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level: 
X-Spam-Status: No, score=-2.702 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, 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 HXygcl-QvLEV for ; Wed, 20 Apr 2016 10:56:19 -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 1BE7C12DFD7 for ; Wed, 20 Apr 2016 10:56:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 01BB124676C; Wed, 20 Apr 2016 10:56:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461174978; bh=1JoF67FInuilbTzM1uQ4FGq4aXURIQbZB+4tIpalwKI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=UNTNKP+0A3e33CoF5VF+RlBy9wow4SWkMeVRFlPtyA4tWhZZZhGRJmR41B+k3TyU5 mvjkQUC80rNe37jAz1wnpLnLiArNo4gu0G86URixt8ViD3LcfP+vLZkcjSz4NekY+6 5dJipNAR04NJaRRqIPCnl9L4sqg/PG/2+fiY8JgI=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.147.111] (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 4702E240996; Wed, 20 Apr 2016 10:56:17 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: ietf@thomasclausen.org
In-Reply-To: 
Date: Wed, 20 Apr 2016 19:56:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6968333C-E246-4510-BD63-694E5F346228@thomasclausen.org>
References: 
To: Stan Ratliff 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: MANET IETF 
Subject: Re: [manet] AODVv2-15
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, 20 Apr 2016 17:56:20 -0000

Hi Stan, all,

Just as I was about to turn off the screen and leave the office=E2=80=A6.

> On Apr 20, 2016, at 19:41, Stan Ratliff  wrote:
>=20
> Hello all,=20
>=20
> As you've seen, a new version of the AODVv2 draft has been posted. =
Some of the items addressed are:=20
>=20
> 1. First up, the status of the document has been changed from =
Standards Track to Experimental.=20
> 2. Metrics have been addressed, in an attempt to resolve most (if not =
all) of the review comments.=20
> 3. There has been work in the multicast RREQ/RREP area.=20
> 4. The remainder of Justin's last review comments were addressed.=20
>=20
> I'm positive I'm leaving some things out, but that's the part of the =
list I can remember.=20
>=20
> Given the scope change on the document (from Standards Track to =
Experimental), we authors are asking for WGLC on the document.=20

That=E2=80=99s a surprising request to see.

All due respect, that seems quite premature: there are still several =
outstanding issues on which I (and others) was engaging with the authors =
on the list, as late as a couple of hours ago, that have not been =
addressed nor discussed and closed =E2=80=94 and which I believe should =
be addressed before WGLC. Even if the target maturity level is =
Experimental.

Best,

Thomas




From nobody Wed Apr 20 11:10: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 1963612DE0C for ; Wed, 20 Apr 2016 11:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level: 
X-Spam-Status: No, score=-2.702 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, 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 XlMqEtlrnLBe for ; Wed, 20 Apr 2016 11:10:36 -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 F400612E374 for ; Wed, 20 Apr 2016 11:10:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B79D124097D; Wed, 20 Apr 2016 11:10:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461175831; bh=qPucjJoyBnu8jEkxQTdz08CKiKc3jddSNjhCRthLkKI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=URNfqNorKpiTcgdvOcIVZ1FnPzvdMnIV0gFZfb6wWZ0Ga31KFCBDrfD/pJJ0VOf4/ EM9C9OQM1hdtNG91/VGqkHrV5amioxfIQK0CQzPYX8tq0hGPBrjY9KAQLhfaX2IiYo rud68Cus+ZSL9mtKbGQJhnhupaExYM0KKpLOgtww=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.147.111] (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 0A27D254964; Wed, 20 Apr 2016 11:10:30 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: ietf@thomasclausen.org
In-Reply-To: 
Date: Wed, 20 Apr 2016 20:10:29 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2055300A-2F04-4D99-9F81-02F66AB88FFB@thomasclausen.org>
References: 
To: Justin Dean 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 20 Apr 2016 18:10:39 -0000

Justin,

> On Apr 20, 2016, at 19:50, Justin Dean  wrote:
>=20
> As Thomas has noted the status has changed to experimental.  You beat =
the authors to the punch in noticing that before they posted up an =
overview email.  In short, we, the working group are out of time. It's =
now time to finish this document.  Not all open issues (ones brought up =
today or not decided upon) metrics, security, and a few others have not =
been incorporated into this updated draft.  Regardless we are out of =
time and we need to move on to other work specifically having a new =
charter finished and approved before the next IETF.=20
>=20
> So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended =
status change, updates to the draft, and my review, and continued =
intense work from the editorship team and the working group there is a =
chance of success.  The working group will have 2 weeks to provide input =
at which time I'll make the call to pass it on up to the IESG or remove =
it as a WG item and hand it back to the authors to do with it what they =
will.

What the heck? A WGLC is simply inappropriate at this stage, for reasons =
including the following:

	o	There were core algorithmic changes between -14 and -15 =
(message processing, =E2=80=A6)=20
		that have not been discussed,  let alone not reviewed =
(multicast processing, for example)=20
		on the list.

	o	There are *many* unresolved issues in this document (I =
just did a quick RFCdiff), despite
		the changes between -14 and -15, and discussion of some =
of these is ongoing on the list.
		None of those issues are new, but have been raised in =
the far past, on the list =E2=80=A6

	o	The document is 78 pages long.

Those three combined means that the document should not be WGLCed, =
certainly not with only a 2 week lead time, at this juncture.

Best,

Thomas

> Due to the short timeline we will also need to discuss and come to =
consensus on a new WG charter. I'll start that in another email thread.
>=20
> Justin
>=20
> p.s. I'm looking forward to continued positive discussions and =
improvements.  AODVv2 I STRONGLY encourage you to use (almost =
exclusively to the extent possible) the MANET list for all future AODVv2 =
discussions within this last call period.


From nobody Wed Apr 20 11:17: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 A6D9212E0D5 for ; Wed, 20 Apr 2016 11:17:39 -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 xeYZsLofJcS6 for ; Wed, 20 Apr 2016 11:17:38 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 BC3FC12D53B for ; Wed, 20 Apr 2016 11:17:37 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id e185so69280294vkb.1 for ; Wed, 20 Apr 2016 11:17:37 -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=+w2V0+5qzJXLp7m7Q+NZXYm3mxYrV46CHQcXDmjjyVg=; b=DEDX8DZ3jJCuAl1mrWPTzYMGBghukcz3XI4CoSJBzS0zqd/iVHB7E+gtoN2TMsPZij GvbYytUNq5CMPa9yPxUfXrNp4MOdNpWMiTV4Wlt1GkkOKSaQwHqbMZu6fHZiqv2L1AFv aILJU25SRwFr6wpuVIMVSgu2bT/wvMZj8bDddWD34KkkiaBR32FpvGXUir0rgrNSBwOq rTld9H+Lqtcliyi2oC/f0KOVAbtoZ3LjYAt6TP3xJfgFo6xPXAxAD2UldVdxvkCQSur7 LVQQXl4QfMqdmLyayIYQltENLiOJRWrROFOlp9htdygnQnr1IdiOhpgcfENJxN0Ps/Ys QiMg==
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=+w2V0+5qzJXLp7m7Q+NZXYm3mxYrV46CHQcXDmjjyVg=; b=EPu3CsCFQAx1mGsXVq/NwoXh1SRb/onuMvlIbQnJgtn9uO0zkVe6DezBRnbjIHe52J SQhfTB1FQa9/GhL42u+Wogdl6zNa18YcY9uTWG450slWwKYZommA8i1buyq3+gPR7/dz UNaTSAvA/oIkisBcnoisYKoo/pwbekp7edY597Ud+oOZSTaUoFY5PbSoCz+5wIdGMI8y ijDtm0oT3yBsN2fdvM5LubzaXPibP8I0H+IP47cgvkmHZ7aIiin6jx7dljLXMy7Ym3rN Ibhji7jw8uUHbAaOSAesJqjfwo1lAddXA5Zz5Y3168TwnPRVWSMRPav00XqrKtUMHAPt 6xKQ==
X-Gm-Message-State: AOPr4FVkYZ1mvPU2mBzSo50Dm7E1yU3U+z5SjNO5mvP5n/bZ74WBM3evOf78VFolvH3tKwp/DG12kvyCsDFZYQ==
MIME-Version: 1.0
X-Received: by 10.31.129.211 with SMTP id c202mr4879568vkd.52.1461176256773; Wed, 20 Apr 2016 11:17:36 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Wed, 20 Apr 2016 11:17:36 -0700 (PDT)
In-Reply-To: <2055300A-2F04-4D99-9F81-02F66AB88FFB@thomasclausen.org>
References:  <2055300A-2F04-4D99-9F81-02F66AB88FFB@thomasclausen.org>
Date: Wed, 20 Apr 2016 14:17:36 -0400
Message-ID: 
From: Justin Dean 
To: Thomas Heide Clausen 
Content-Type: multipart/alternative; boundary=001a11458262bd48aa0530ee9b6a
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 20 Apr 2016 18:17:39 -0000

--001a11458262bd48aa0530ee9b6a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

We are out of time.  This WGLC is the final 2 weeks one way or another.
You're comments are valid and understood we just don't have any more time.
How things go depends on the working group and the editorship team.  WGLC
doesn't mean that the draft is finished, it's a means for the chair to
explicitly poll the WG when I feel a document has a chance to find
consensus.  Also, we are out of time.

Justin

On Wed, Apr 20, 2016 at 2:10 PM,  wrote:

> Justin,
>
> > On Apr 20, 2016, at 19:50, Justin Dean  wrote:
> >
> > As Thomas has noted the status has changed to experimental.  You beat
> the authors to the punch in noticing that before they posted up an overvi=
ew
> email.  In short, we, the working group are out of time. It's now time to
> finish this document.  Not all open issues (ones brought up today or not
> decided upon) metrics, security, and a few others have not been
> incorporated into this updated draft.  Regardless we are out of time and =
we
> need to move on to other work specifically having a new charter finished
> and approved before the next IETF.
> >
> > So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended status
> change, updates to the draft, and my review, and continued intense work
> from the editorship team and the working group there is a chance of
> success.  The working group will have 2 weeks to provide input at which
> time I'll make the call to pass it on up to the IESG or remove it as a WG
> item and hand it back to the authors to do with it what they will.
>
> What the heck? A WGLC is simply inappropriate at this stage, for reasons
> including the following:
>
>         o       There were core algorithmic changes between -14 and -15
> (message processing, =E2=80=A6)
>                 that have not been discussed,  let alone not reviewed
> (multicast processing, for example)
>                 on the list.
>
>         o       There are *many* unresolved issues in this document (I
> just did a quick RFCdiff), despite
>                 the changes between -14 and -15, and discussion of some o=
f
> these is ongoing on the list.
>                 None of those issues are new, but have been raised in the
> far past, on the list =E2=80=A6
>
>         o       The document is 78 pages long.
>
> Those three combined means that the document should not be WGLCed,
> certainly not with only a 2 week lead time, at this juncture.
>
> Best,
>
> Thomas
>
> > Due to the short timeline we will also need to discuss and come to
> consensus on a new WG charter. I'll start that in another email thread.
> >
> > Justin
> >
> > p.s. I'm looking forward to continued positive discussions and
> improvements.  AODVv2 I STRONGLY encourage you to use (almost exclusively
> to the extent possible) the MANET list for all future AODVv2 discussions
> within this last call period.
>
>

--001a11458262bd48aa0530ee9b6a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


We are out of time.=C2=A0 This WGLC is the final 2 weeks o=
ne way or another.=C2=A0 You're comments are valid and understood we ju=
st don't have any more time.=C2=A0 How things go depends on the working=
 group and the editorship team.=C2=A0 WGLC doesn't mean that the draft =
is finished, it's a means for the chair to explicitly poll the WG when =
I feel a document has a chance to find consensus.=C2=A0 Also, we are out of=
 time.

Justin

On Wed, Apr 20, 2016 at 2:10 PM,  <ietf@thomasclausen.org> wrote:
Justin,



> On Apr 20, 2016, at 19:50, Justin Dean <bebemaster@gmail.com> wrote:

>

> As Thomas has noted the status has changed to experimental.=C2=A0 You =
beat the authors to the punch in noticing that before they posted up an ove=
rview email.=C2=A0 In short, we, the working group are out of time. It'=
s now time to finish this document.=C2=A0 Not all open issues (ones brought=
 up today or not decided upon) metrics, security, and a few others have not=
 been incorporated into this updated draft.=C2=A0 Regardless we are out of =
time and we need to move on to other work specifically having a new charter=
 finished and approved before the next IETF.

>

> So, I'll be issuing a 2 week WGLC on AODVv2.=C2=A0 Given the inten=
ded status change, updates to the draft, and my review, and continued inten=
se work from the editorship team and the working group there is a chance of=
 success.=C2=A0 The working group will have 2 weeks to provide input at whi=
ch time I'll make the call to pass it on up to the IESG or remove it as=
 a WG item and hand it back to the authors to do with it what they will.


What the heck? A WGLC is simply inappropriate at this stage, for rea=
sons including the following:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 =C2=A0 =C2=A0 =C2=A0There were core alg=
orithmic changes between -14 and -15 (message processing, =E2=80=A6)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that have not been =
discussed,=C2=A0 let alone not reviewed (multicast processing, for example)=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 on the list.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 =C2=A0 =C2=A0 =C2=A0There are *many* un=
resolved issues in this document (I just did a quick RFCdiff), despite

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the changes between=
 -14 and -15, and discussion of some of these is ongoing on the list.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 None of those issue=
s are new, but have been raised in the far past, on the list =E2=80=A6



=C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 =C2=A0 =C2=A0 =C2=A0The document is 78 =
pages long.



Those three combined means that the document should not be WGLCed, certainl=
y not with only a 2 week lead time, at this juncture.



Best,



Thomas




> Due to the short timeline we will also need to discuss and come to con=
sensus on a new WG charter. I'll start that in another email thread.
>

> Justin

>

> p.s. I'm looking forward to continued positive discussions and imp=
rovements.=C2=A0 AODVv2 I STRONGLY encourage you to use (almost exclusively=
 to the extent possible) the MANET list for all future AODVv2 discussions w=
ithin this last call period.







--001a11458262bd48aa0530ee9b6a--


From nobody Wed Apr 20 11:36: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 C49AB12E8B0 for ; Wed, 20 Apr 2016 11:36: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, 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 StiOakY7ed25 for ; Wed, 20 Apr 2016 11:36:42 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 A36B412E836 for ; Wed, 20 Apr 2016 11:36:41 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id v188so215046100wme.1 for ; Wed, 20 Apr 2016 11:36:41 -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=P/MPE0FdlGJ2e66Jllt9d3nlZQlwPMUANRjh3y3FNiA=; b=oXfcDx5DW5thwAQeXjKoHTBa1C3VewMzjAA5J55yxzlAKwaxXWSBmCcrxzdwNVc7u5 Bx1sOb98PnqakbrhclGenmqee02tyY28/Y8lOvCXiEQgRSq814qTI7daNvW3Qj4MTxEt IPAje8hQa/psrW8HmCYtpACn1bhx4vKLK0HKWivF0e/n+CdaTZFyL1RtDIAcccAYL7OU n5fux3OTrr1p3HsM8BukadMVA5fMvpp+S9w3XEWqDbPsfYN+kJGQSCNK6l9fC4Wjryxt v+Nc+CGnMT8zHtwkzK4/LWqqbz96Yw1MMH8G946C7P4TIPmDnN3nIxV4VTnFiOssxkR2 SKlA==
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=P/MPE0FdlGJ2e66Jllt9d3nlZQlwPMUANRjh3y3FNiA=; b=MHFRKdI8p4a3YjrFMnPM12Xia74hiefKNPtd0rP0rkMtuf2kIdTvOi0/V03i93y097 fDnE8D6JfmiH67NXW4dcT+wIl6oIUY9so8mgI8iFclLZH+AU7bQf5J1b0V0yo/OoENbz XW2/v5DkyoL+OOnQJduaz+8GHwsnBjbWRJS0o3u7p8ogBWKnsbXEfi3anXNSSET3+w0w hqyYN4Oun4bzx1Rotd0jPsFENBjV6LyAJ2tSn3rM9iIWqsgsgzTwUd5hFctPjgXn6fab jCwQR9j/hgaKpWThbmvIq/GopHtST/Ifb2jz0kznqw+o4OMuESM4niPSzGoLrK93+q1F LAXw==
X-Gm-Message-State: AOPr4FX5pt06SXx7gizJurYJYF2LwGX7yBB/Xkh7kopQvqGNR63AXXQPCgJDAKpQAnnEEQ==
X-Received: by 10.194.58.114 with SMTP id p18mr9639836wjq.84.1461177400208; Wed, 20 Apr 2016 11:36:40 -0700 (PDT)
Received: from [10.7.198.214] (82-132-212-79.dab.02.net. [82.132.212.79]) by smtp.gmail.com with ESMTPSA id r8sm4169305wme.14.2016.04.20.11.36.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2016 11:36:39 -0700 (PDT)
References: 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPhone Mail (13E238)
From: Christopher Dearlove 
Date: Wed, 20 Apr 2016 19:36:35 +0100
To: Justin Dean 
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 20 Apr 2016 18:36:44 -0000

This is the cart before the horse. I'm pretty sure every IETF guideline says=
 get the document right, not rush to a deadline.

Is the document right? I don't know. It would be hard enough with a more usu=
al four week deadline (even 5444 usage, a much simpler document, got three) a=
nd had the authors been engaging here. As it is, they have persistently decl=
ined do do so except on a few points when pushed. Despite continual requests=
 and appeals to the WG chair to make that happen. And the authors have been m=
aking functional changes right up to now. To expect the WG to give a reasone=
d view of the document in two weeks, even at experimental status, is just no=
t going to be possible. Document shepherd, when appointed, please note.

Incidentally - and obviously I haven't read the draft (and right now I'm not=
 committing to do so in the timescale) - the last draft I was an author of t=
hat left the WG in experimental state, there was a requirement to add a desc=
ription of the experiment. (It actually made experimental harder work than s=
tandards track in material to write.) But whether that will be required here=
, no idea.

-- =20
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)

> On 20 Apr 2016, at 18:50, Justin Dean  wrote:
>=20
> As Thomas has noted the status has changed to experimental.  You beat the a=
uthors to the punch in noticing that before they posted up an overview email=
.  In short, we, the working group are out of time. It's now time to finish t=
his document.  Not all open issues (ones brought up today or not decided upo=
n) metrics, security, and a few others have not been incorporated into this u=
pdated draft.  Regardless we are out of time and we need to move on to other=
 work specifically having a new charter finished and approved before the nex=
t IETF.=20
>=20
> So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended status ch=
ange, updates to the draft, and my review, and continued intense work from t=
he editorship team and the working group there is a chance of success.  The w=
orking group will have 2 weeks to provide input at which time I'll make the c=
all to pass it on up to the IESG or remove it as a WG item and hand it back t=
o the authors to do with it what they will.
>=20
> Due to the short timeline we will also need to discuss and come to consens=
us on a new WG charter. I'll start that in another email thread.
>=20
> Justin
>=20
> p.s. I'm looking forward to continued positive discussions and improvement=
s.  AODVv2 I STRONGLY encourage you to use (almost exclusively to the extent=
 possible) the MANET list for all future AODVv2 discussions within this last=
 call period.
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From nobody Wed Apr 20 11:46: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 14CC812E3BC for ; Wed, 20 Apr 2016 11:46:19 -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 y1QNUhDotzQ6 for ; Wed, 20 Apr 2016 11:46:16 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d: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 0620312E37E for ; Wed, 20 Apr 2016 11:46:16 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id q76so7541649qke.2 for ; Wed, 20 Apr 2016 11:46:15 -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=kqRIcZuDwmgX3wAHyiyDXw6sPOcnquswqAyR9SRD/7g=; b=Z436BZdCkIdm+C0J+2UM+I6/ITw5WMP1f/JbXxm5vfvvtvzHVu85AwbJWg78brhrpG itjyyHFvNkn/lCngVVixKpZkTn3gz2vVglp6U5ftDXh+IYYUErW34IBTNsyvNLq6xpJb 0VT0N/2sxcLiMly4GphK1vPa3+otD3TEObIEqEeCrVALYWm5JD+pumKLfyou42xGuq6D NikpH95+oc0b60fASJclSC8ujue5RIVKJLX1rwMRVtuEbNYhTYgW/fe1wgcia2JV4xC1 +UQlCuBafnVJqIO7N9BKeswMaah9KPwotNpROUDb2y5gbsTF51jmcLys3QHgUMgi3DmN 6hOw==
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=kqRIcZuDwmgX3wAHyiyDXw6sPOcnquswqAyR9SRD/7g=; b=cDyTMrxfzryT72392PFAkUbeyFmfSYAa1eiiqIXjoFV2Sh/5mhjujsMzTScqPZoQvD TSCDO/t9esksmZonCsso3K9oJAz6PdqVBuFbHoRBzh7m22ev63tyZftkNIOTDfxqZPRB dPdMzHJMlazA29U4sMdXDp2PGd7mmdWyMv1w2eQkw6Hv0aaiJd/FgliWnySje/u8/7Sz dtLjCI3lIjSuitNfPsx/wKXswZwZUMuesTqZtcw0rGsRRTWD9Pp6cTkweHpKHOK91Teo TVEdzVd8kQPyMP5TgLWCRPDuOh1JJXHKPopTXVKsUemOHKpZwMCjF5se+aMrJx9tVPlq TnRg==
X-Gm-Message-State: AOPr4FUGDOoF5NumqdXxt2T4LiGeseFuLuxOwiUBEjzDfibrxUHOwY4Po0xq3BaCwzycTQmbcALYjLBtor5PsQ==
MIME-Version: 1.0
X-Received: by 10.55.80.86 with SMTP id e83mr13498810qkb.91.1461177975091; Wed, 20 Apr 2016 11:46:15 -0700 (PDT)
Received: by 10.140.43.131 with HTTP; Wed, 20 Apr 2016 11:46:15 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 20 Apr 2016 20:46:15 +0200
Message-ID: 
From: Abdussalam Baryun 
To: Stan Ratliff 
Content-Type: multipart/alternative; boundary=001a114a6a9628be510530ef02f5
Archived-At: 
Cc: MANET IETF 
Subject: Re: [manet] AODVv2-15
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, 20 Apr 2016 18:46:19 -0000

--001a114a6a9628be510530ef02f5
Content-Type: text/plain; charset=UTF-8

Hi Stan,

I think the WG has to discuss if they agree to change the status to
experimental. For me I don't agree, also want to know why the authors want
to do last call quickly while we are doing good discussion in the group.

AB

On Wed, Apr 20, 2016 at 7:41 PM, Stan Ratliff  wrote:

> Hello all,
>
> As you've seen, a new version of the AODVv2 draft has been posted. Some of
> the items addressed are:
>
> 1. First up, the status of the document has been changed from Standards
> Track to Experimental.
> 2. Metrics have been addressed, in an attempt to resolve most (if not all)
> of the review comments.
> 3. There has been work in the multicast RREQ/RREP area.
> 4. The remainder of Justin's last review comments were addressed.
>
> I'm positive I'm leaving some things out, but that's the part of the list
> I can remember.
>
> Given the scope change on the document (from Standards Track to
> Experimental), we authors are asking for WGLC on the document.
>
> Regards,
> Stan
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>

--001a114a6a9628be510530ef02f5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Stan,

I think the WG has to disc=
uss if they agree to change the status to experimental. For me I don't =
agree, also want to know why the authors want to do last call quickly while=
 we are doing good discussion in the group. 

AB

On Wed, Apr 20, 2016 a=
t 7:41 PM, Stan Ratliff <ratliffstan@gmail.com> wrote:
Hello all,=C2=A0

=

As you've seen, a new version of the AODVv2 draft has been p=
osted. Some of the items addressed are:=C2=A0

1. F=
irst up, the status of the document has been changed from Standards Track t=
o Experimental.=C2=A0
2. Metrics have been addressed, in an attem=
pt to resolve most (if not all) of the review comments.=C2=A0
3. =
There has been work in the multicast RREQ/RREP area.=C2=A0
4. The=
 remainder of Justin's last review comments were addressed.=C2=A0
=


I'm positive I'm leaving some things out, but t=
hat's the part of the list I can remember.=C2=A0

Given the scope change on the document (from Standards Track to Experime=
ntal), we authors are asking for WGLC on the document.=C2=A0

=

Regards,
Stan


_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet





--001a114a6a9628be510530ef02f5--


From nobody Wed Apr 20 11:51: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 867C712E835 for ; Wed, 20 Apr 2016 11:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=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 Ka4QmRkBfRGK for ; Wed, 20 Apr 2016 11:51:26 -0700 (PDT)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 3C91512E648 for ; Wed, 20 Apr 2016 11:51:26 -0700 (PDT)
Received: by mail-vk0-x22b.google.com with SMTP id n67so61750276vkf.3 for ; Wed, 20 Apr 2016 11:51:26 -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=+vkKvlWaXXA2xg6m6Zrs9jQZBAavusHhSgz1W3GPESU=; b=Dpncu9N5CLdn6ONaC1BTHjV7XohpwiYUUW4YUOlEJZ9KQ+nhv/zxBwoe7d/um6vSqS K7IIObNsc5lGQoKP581HTurfUAF2YBGgyP5xc4SCw9Am4kfAqv5mVZoTpp4O37KfKiq+ RrVQinuy/z0wKCTL1XL0KXMNQtiNScXAVf+6hiNSUrojVqKjxSi+l4Qzuwn3yqtMVfsU JAxc/S4xoXMYmF9oOQiyeADuHpxnw+0LXaFRwR/se8AHszFhSSqTIotTjpF/c5NUnv7/ c+XQiHuTbbHTo+l5hEpAR0rLqofBkX2NdEhEWE3tlTSYcCrFRJEvubxyfUN2loEGzqZ1 zNaw==
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=+vkKvlWaXXA2xg6m6Zrs9jQZBAavusHhSgz1W3GPESU=; b=LM/BBP29ICTqRR1e+dUsZM0OXdQQRWYYAZCxL9zrvZZnrLeGJwylduZ6/2gCeUPTEx fdIMjEyFHQgiRkA5J98nUt0ltM5hnwfv/XKoIGb2AyKhkSPPv6f1qYWFqaDMxjUhCayy Sd0u+AzKnbtDW+82F5khSAB71PqB7dLWHui7ZY8hVNm7QoUlDD4PyAyaPEz1XtytER0A apb8i1LfXgOWOfkEbfQzdJHnVl3tKTljHXQ84eys5HvhBxKeduOi4UoUF/berwAOBuur aO6SZMSgt0gQ8I6gv7DHdFMNgIknJOpq8Kk5XCiulbZJ/VqVTmzs2txVy8+DFagjU1Mk Y4aw==
X-Gm-Message-State: AOPr4FVxH8nU4s4Ta8k71PNlMcBnIir3vI++Crf3CC2auSPS37LgjW4fVk3LqF0n+DWfLf4S/4oiC9yQw7vEdg==
MIME-Version: 1.0
X-Received: by 10.31.129.211 with SMTP id c202mr4951328vkd.52.1461178285387; Wed, 20 Apr 2016 11:51:25 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Wed, 20 Apr 2016 11:51:25 -0700 (PDT)
In-Reply-To: 
References:  
Date: Wed, 20 Apr 2016 14:51:25 -0400
Message-ID: 
From: Justin Dean 
To: Christopher Dearlove 
Content-Type: multipart/alternative; boundary=001a11458262a773660530ef142a
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 20 Apr 2016 18:51:28 -0000

--001a11458262a773660530ef142a
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 20, 2016 at 2:36 PM, Christopher Dearlove <
christopher.dearlove@gmail.com> wrote:

> This is the cart before the horse. I'm pretty sure every IETF guideline
> says get the document right, not rush to a deadline.
>
> 10+ years isn't rushing.


> Is the document right? I don't know. It would be hard enough with a more
> usual four week deadline (even 5444 usage, a much simpler document, got
> three) and had the authors been engaging here. As it is, they have
> persistently declined do do so except on a few points when pushed. Despite
> continual requests and appeals to the WG chair to make that happen. And the
> authors have been making functional changes right up to now. To expect the
> WG to give a reasoned view of the document in two weeks, even at
> experimental status, is just not going to be possible. Document shepherd,
> when appointed, please note.
>
> As for the maturity of the document there was some helpful and useful
discussions this morning before the new draft was released so issues
remain.  I hope those discussions continue and consensus reached on
appropriate fixes.  That being said I did give a pretty indepth review and
while I found numerous issues many of them have been addressed in the newer
draft.  Do I think it's perfect?  Nope but I do think it's approaching the
levels seen in other ietf documents.
Shepherd will be sure to note the objections to issuing of WGLC and the
timeline provided by multiple WG members;  If the document gets there, I'll
still need consensus even if rough from the WG before I'll pass it along.

I'd much rather spend our remaining time on technical issues.

Justin

Incidentally - and obviously I haven't read the draft (and right now I'm
> not committing to do so in the timescale) - the last draft I was an author
> of that left the WG in experimental state, there was a requirement to add a
> description of the experiment. (It actually made experimental harder work
> than standards track in material to write.) But whether that will be
> required here, no idea.
>
> --
> Christopher Dearlove
> christopher.dearlove@gmail.com (iPhone)
> chris@mnemosyne.demon.co.uk (home)
>
> > On 20 Apr 2016, at 18:50, Justin Dean  wrote:
> >
> > As Thomas has noted the status has changed to experimental.  You beat
> the authors to the punch in noticing that before they posted up an overview
> email.  In short, we, the working group are out of time. It's now time to
> finish this document.  Not all open issues (ones brought up today or not
> decided upon) metrics, security, and a few others have not been
> incorporated into this updated draft.  Regardless we are out of time and we
> need to move on to other work specifically having a new charter finished
> and approved before the next IETF.
> >
> > So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended status
> change, updates to the draft, and my review, and continued intense work
> from the editorship team and the working group there is a chance of
> success.  The working group will have 2 weeks to provide input at which
> time I'll make the call to pass it on up to the IESG or remove it as a WG
> item and hand it back to the authors to do with it what they will.
> >
> > Due to the short timeline we will also need to discuss and come to
> consensus on a new WG charter. I'll start that in another email thread.
> >
> > Justin
> >
> > p.s. I'm looking forward to continued positive discussions and
> improvements.  AODVv2 I STRONGLY encourage you to use (almost exclusively
> to the extent possible) the MANET list for all future AODVv2 discussions
> within this last call period.
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www.ietf.org/mailman/listinfo/manet
>

--001a11458262a773660530ef142a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Wed, Apr 20, 2016 at 2:36 PM, Christopher Dearlove <=
;christ=
opher.dearlove@gmail.com> wrote:
This is the cart before the horse. I'm pretty sure every IETF gui=
deline says get the document right, not rush to a deadline.


10+ years isn't rushing.
=C2=A0

Is the document right? I don't know. It would be hard enough with a mor=
e usual four week deadline (even 5444 usage, a much simpler document, got t=
hree) and had the authors been engaging here. As it is, they have persisten=
tly declined do do so except on a few points when pushed. Despite continual=
 requests and appeals to the WG chair to make that happen. And the authors =
have been making functional changes right up to now. To expect the WG to gi=
ve a reasoned view of the document in two weeks, even at experimental statu=
s, is just not going to be possible. Document shepherd, when appointed, ple=
ase note.


As for the maturity of the document there was some he=
lpful and useful discussions this morning before the new draft was released=
 so issues remain.=C2=A0 I hope those discussions continue and consensus re=
ached on appropriate fixes.=C2=A0 That being said I did give a pretty indep=
th review and while I found numerous issues many of them have been addresse=
d in the newer draft.=C2=A0 Do I think it's perfect?=C2=A0 Nope but I d=
o think it's approaching the levels seen in other ietf documents.
Sh=
epherd will be sure to note the objections to issuing of WGLC and the timel=
ine provided by multiple WG members; =C2=A0If the document gets there, I=
9;ll still need consensus even if rough from the WG before I'll pass it=
 along.

I'd much rather spend our remaining time on technical is=
sues.
=C2=A0
Justin

christopher.dearlove@gmai=
l.com (iPhone)

chris@mnemosyne.demon.co.uk<=
/a> (home)




> On 20 Apr 2016, at 18:50, Justin Dean <bebemaster@gmail.com> wrote:

>

> As Thomas has noted the status has changed to experimental.=C2=A0 You =
beat the authors to the punch in noticing that before they posted up an ove=
rview email.=C2=A0 In short, we, the working group are out of time. It'=
s now time to finish this document.=C2=A0 Not all open issues (ones brought=
 up today or not decided upon) metrics, security, and a few others have not=
 been incorporated into this updated draft.=C2=A0 Regardless we are out of =
time and we need to move on to other work specifically having a new charter=
 finished and approved before the next IETF.

>

> So, I'll be issuing a 2 week WGLC on AODVv2.=C2=A0 Given the inten=
ded status change, updates to the draft, and my review, and continued inten=
se work from the editorship team and the working group there is a chance of=
 success.=C2=A0 The working group will have 2 weeks to provide input at whi=
ch time I'll make the call to pass it on up to the IESG or remove it as=
 a WG item and hand it back to the authors to do with it what they will.
>

> Due to the short timeline we will also need to discuss and come to con=
sensus on a new WG charter. I'll start that in another email thread.
>

> Justin

>

> p.s. I'm looking forward to continued positive discussions and imp=
rovements.=C2=A0 AODVv2 I STRONGLY encourage you to use (almost exclusively=
 to the extent possible) the MANET list for all future AODVv2 discussions w=
ithin this last call period.


> __________________=
_____________________________

> manet mailing list

> manet@ietf.org

> https://www.ietf.org/mailman/listinfo/manet





--001a11458262a773660530ef142a--


From nobody Wed Apr 20 11:54: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 9082212E08B for ; Wed, 20 Apr 2016 11:54:16 -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 kq3r-Vx_oZdL for ; Wed, 20 Apr 2016 11:54:15 -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 294AD12DD31 for ; Wed, 20 Apr 2016 11:54:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EEF86245BB5; Wed, 20 Apr 2016 11:54:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461178454; bh=os4unQBotKo4HuBaRq/X7RpgSAqk2+aude4qBC2Ws54=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=mAdsNTGDsnF0MAGdygA0pJQ5qOUMTIQW6kijc2PlfVnWaMFm1toQGsvWsizKqppVa CDT4sydYp1SKX6vwIKTLtBdGmTP15I8iKfi2TJ/u89Xigt68iLX5GYzHNk2awn90l7 AutF09QcYx4MNH9kpUjsszQnMLnSR/z8yA/hlw8k=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.147.204] (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 4CDCB2510C6; Wed, 20 Apr 2016 11:54:14 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-5EFA89F1-55D6-4828-A625-28A30FF1BC58
Mime-Version: 1.0 (1.0)
From: Thomas Clausen 
X-Mailer: iPad Mail (13E238)
In-Reply-To: 
Date: Wed, 20 Apr 2016 20:54:12 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <40660D3F-F7BE-447A-93DC-1439C6215B04@thomasclausen.org>
References:  <2055300A-2F04-4D99-9F81-02F66AB88FFB@thomasclausen.org> 
To: Justin Dean 
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 20 Apr 2016 18:54:16 -0000

--Apple-Mail-5EFA89F1-55D6-4828-A625-28A30FF1BC58
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Justin, all

You are asking the WG to do in two weeks, what the authors have just not don=
e in 3 (or, to be fair, more like 10...) years: discuss the document on the m=
anet@ietf.org list, and resolve all issues - issues, which you know exist, b=
ecause they have been raised on the list....for, if not 10 years, then at th=
e least 4-5 years.

Except, the WG gets two weeks to do so.=20

If you (as chair) feel the document is not right, pull it.=20
If you (as chair) in the past have felt it wasn't going in the right decisio=
n, you could have stepped on the authors earlier, or replaced them, or spoke=
n to your AD, or to the WG, or something else.

But to expect the WG to resolve this document in 2 weeks, after having been k=
ept in the dark (apparently the document was discussed in some other, closed=
, forum -- with the WG chairs knowledge) for years, is simply not reasonable=
, and is simply not possible.

I believe, in fact, it would give cause for an appeal. Document shepherd, if=
/when appointed, take notice.

Thomas


> On 20 Apr 2016, at 20:17, Justin Dean  wrote:
>=20
> We are out of time.  This WGLC is the final 2 weeks one way or another.  Y=
ou're comments are valid and understood we just don't have any more time.  H=
ow things go depends on the working group and the editorship team.  WGLC doe=
sn't mean that the draft is finished, it's a means for the chair to explicit=
ly poll the WG when I feel a document has a chance to find consensus.  Also,=
 we are out of time.
>=20
> Justin
>=20
>> On Wed, Apr 20, 2016 at 2:10 PM,  wrote:
>> Justin,
>>=20
>> > On Apr 20, 2016, at 19:50, Justin Dean  wrote:
>> >
>> > As Thomas has noted the status has changed to experimental.  You beat t=
he authors to the punch in noticing that before they posted up an overview e=
mail.  In short, we, the working group are out of time. It's now time to fin=
ish this document.  Not all open issues (ones brought up today or not decide=
d upon) metrics, security, and a few others have not been incorporated into t=
his updated draft.  Regardless we are out of time and we need to move on to o=
ther work specifically having a new charter finished and approved before the=
 next IETF.
>> >
>> > So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended status=
 change, updates to the draft, and my review, and continued intense work fro=
m the editorship team and the working group there is a chance of success.  T=
he working group will have 2 weeks to provide input at which time I'll make t=
he call to pass it on up to the IESG or remove it as a WG item and hand it b=
ack to the authors to do with it what they will.
>>=20
>> What the heck? A WGLC is simply inappropriate at this stage, for reasons i=
ncluding the following:
>>=20
>>         o       There were core algorithmic changes between -14 and -15 (=
message processing, =E2=80=A6)
>>                 that have not been discussed,  let alone not reviewed (mu=
lticast processing, for example)
>>                 on the list.
>>=20
>>         o       There are *many* unresolved issues in this document (I ju=
st did a quick RFCdiff), despite
>>                 the changes between -14 and -15, and discussion of some o=
f these is ongoing on the list.
>>                 None of those issues are new, but have been raised in the=
 far past, on the list =E2=80=A6
>>=20
>>         o       The document is 78 pages long.
>>=20
>> Those three combined means that the document should not be WGLCed, certai=
nly not with only a 2 week lead time, at this juncture.
>>=20
>> Best,
>>=20
>> Thomas
>>=20
>> > Due to the short timeline we will also need to discuss and come to cons=
ensus on a new WG charter. I'll start that in another email thread.
>> >
>> > Justin
>> >
>> > p.s. I'm looking forward to continued positive discussions and improvem=
ents.  AODVv2 I STRONGLY encourage you to use (almost exclusively to the ext=
ent possible) the MANET list for all future AODVv2 discussions within this l=
ast call period.
>=20

--Apple-Mail-5EFA89F1-55D6-4828-A625-28A30FF1BC58
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Justin, all

You are asking the WG to d=
o in two weeks, what the authors have just not done in 3 (or, to be fair, mo=
re like 10...) years: discuss the document on the manet@ietf.org list, and resolve all issues - issues, which you k=
now exist, because they have been raised on the list....for, if not 10 years=
, then at the least 4-5 years.

Except, the WG gets two weeks to do so. =
;

If you (as chair) feel the document is not right, pull it. 
If you (as chair) in the past have felt it wasn'=
t going in the right decision, you could have stepped on the authors earlier=
, or replaced them, or spoken to your AD, or to the WG, or something else.

=
But to expect the WG to resolve this document in 2 weeks, after having been k=
ept in the dark (apparently the document was discussed in some other, closed=
, forum -- with the WG chairs knowledge) for years, is simply not reasonable=
, and is simply not possible.

=

I believe, in fact, it would give cause for a=
n appeal. Document shepherd, if/when appointed, take notice.

Thomas


On 20 Apr 2016, at 20:17, Justin Dean <bebemaster@gmail.com> wrote:

We are out of time.  This WGLC is th=
e final 2 weeks one way or another.  You're comments are valid and unde=
rstood we just don't have any more time.  How things go depends on the w=
orking group and the editorship team.  WGLC doesn't mean that the draft=
 is finished, it's a means for the chair to explicitly poll the WG when I fe=
el a document has a chance to find consensus.  Also, we are out of time=
.

Justin

On Wed, Apr 20, 2016 at 2:10 PM,  <ietf@thomasclausen.org> wrote:
Justin,



> On Apr 20, 2016, at 19:50, Justin Dean <bebemaster@gmail.com> wrote:

>

> As Thomas has noted the status has changed to experimental.  You b=
eat the authors to the punch in noticing that before they posted up an overv=
iew email.  In short, we, the working group are out of time. It's now t=
ime to finish this document.  Not all open issues (ones brought up toda=
y or not decided upon) metrics, security, and a few others have not been inc=
orporated into this updated draft.  Regardless we are out of time and w=
e need to move on to other work specifically having a new charter finished a=
nd approved before the next IETF.

>

> So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended s=
tatus change, updates to the draft, and my review, and continued intense wor=
k from the editorship team and the working group there is a chance of succes=
s.  The working group will have 2 weeks to provide input at which time I=
'll make the call to pass it on up to the IESG or remove it as a WG item and=
 hand it back to the authors to do with it what they will.



What the heck? A WGLC is simply inappropriate at this stage, for reas=
ons including the following:



        o       There were core algo=
rithmic changes between -14 and -15 (message processing, =E2=80=A6)

                that have not been d=
iscussed,  let alone not reviewed (multicast processing, for example)
                on the list.



        o       There are *many* unr=
esolved issues in this document (I just did a quick RFCdiff), despite

                the changes between -=
14 and -15, and discussion of some of these is ongoing on the list.

                None of those issues=
 are new, but have been raised in the far past, on the list =E2=80=A6



        o       The document is 78 p=
ages long.



Those three combined means that the document should not be WGLCed, certainly=
 not with only a 2 week lead time, at this juncture.



Best,



Thomas




> Due to the short timeline we will also need to discuss and come to cons=
ensus on a new WG charter. I'll start that in another email thread.

>

> Justin

>

> p.s. I'm looking forward to continued positive discussions and improvem=
ents.  AODVv2 I STRONGLY encourage you to use (almost exclusively to th=
e extent possible) the MANET list for all future AODVv2 discussions within t=
his last call period.







=

--Apple-Mail-5EFA89F1-55D6-4828-A625-28A30FF1BC58--


From nobody Wed Apr 20 11:58: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 0CDE212E377 for ; Wed, 20 Apr 2016 11:58: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 UqoRH7gA7cLu for ; Wed, 20 Apr 2016 11:58:52 -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 2F35212E450 for ; Wed, 20 Apr 2016 11:58:52 -0700 (PDT)
Received: by mail-vk0-x22e.google.com with SMTP id e185so70680807vkb.1 for ; Wed, 20 Apr 2016 11:58: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=eb9QSTQjKMXaHEhMUP/dhStdqdAUJYecnD75U2S9idg=; b=rHamKjGsJQgLBzdKsXHTwC0jOAmWYgUdBaD/JL+xofpCdjVoXXCeaiBmX2NZk7V1hE burItnof7rYxtJlfVQZol4RF42+USrggtLiR4vwu2ScFvAo4U9HwiHRg6oHn5QmJQL5o z/WGPAvpXQZUsbGLPEW5EyLDu5NdeaQ6dxdBCCSlGVMxenyuVGxttO4Q+GpqT59pqMzC wioHbwaCpgpy4pZ8Q5hOfBTCRm42oDjC1VrTDD1FK/Wkxx+X07V4wwPFM55VsBN5QrlG 0fnAu955HXpTRjvJnuuA3qYuRhQAblnORJ8O1qK5Zn0IOvClPFZ5tc/2CRVKN1MCh9I2 1lCQ==
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=eb9QSTQjKMXaHEhMUP/dhStdqdAUJYecnD75U2S9idg=; b=HWOfiQp+jqZ/WJTUz5EeAXnA0Pfo9fucZdOaS7imqx56RaKrpakfw8Wc62ge+S3EvD +nav84SM1EhKwdQBOdOzRnD9LQb4ZwkULkD1MeM9bOw61w3W4/7Qbvcs+9gwKAUwWbpq mCfSpxyEiQo70OOjMqrWB2Zzvqf/R2JxFhvqhcajorzBjFV094LyORYYA4n/dh7bcgEc yEcxvjtkX4uQP5akd7PvzgZPIh8093+N+Rthv76iwVKta8CCTwIm0K5MltvODtPNOSk+ BE4OTLtNe+BV6B9tTVRET5vhMctCbkI5IkyFJ7L5myQZ4qb/kMlcdWErLlVtU6ccjqdi Pg3A==
X-Gm-Message-State: AOPr4FVXtK0xmbCMI0pHgyqNsGsdXZRBsQ3/jYUBND+nIt9bIbVMOPF5mXzQHipVt94aCdcvBLisd2GQgAxBvg==
MIME-Version: 1.0
X-Received: by 10.176.1.105 with SMTP id 96mr5064710uak.54.1461178731213; Wed, 20 Apr 2016 11:58:51 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Wed, 20 Apr 2016 11:58:51 -0700 (PDT)
In-Reply-To: 
References:  
Date: Wed, 20 Apr 2016 14:58:51 -0400
Message-ID: 
From: Justin Dean 
To: Abdussalam Baryun 
Content-Type: multipart/alternative; boundary=001a1142fcb43a3d870530ef2f59
Archived-At: 
Cc: MANET IETF 
Subject: Re: [manet] AODVv2-15
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, 20 Apr 2016 18:58:54 -0000

--001a1142fcb43a3d870530ef2f59
Content-Type: text/plain; charset=UTF-8

The document is not ready for standards track publication.  If the working
group insists on keeping it standards track I'll release it from the WG
back to the authors now.  Lack of implementations, maturity and zero chance
of getting WG consensus in any reasonable time frame (reasonable in that it
wouldn't kill the WG as a whole) make this impossible.  If you'd like I can
add your complaint to the notes to be listed by the shepherd of objections
on process if we get to that point.

On Wed, Apr 20, 2016 at 2:46 PM, Abdussalam Baryun <
abdussalambaryun@gmail.com> wrote:

> Hi Stan,
>
> I think the WG has to discuss if they agree to change the status to
> experimental. For me I don't agree, also want to know why the authors want
> to do last call quickly while we are doing good discussion in the group.
>
> AB
>
> On Wed, Apr 20, 2016 at 7:41 PM, Stan Ratliff 
> wrote:
>
>> Hello all,
>>
>> As you've seen, a new version of the AODVv2 draft has been posted. Some
>> of the items addressed are:
>>
>> 1. First up, the status of the document has been changed from Standards
>> Track to Experimental.
>> 2. Metrics have been addressed, in an attempt to resolve most (if not
>> all) of the review comments.
>> 3. There has been work in the multicast RREQ/RREP area.
>> 4. The remainder of Justin's last review comments were addressed.
>>
>> I'm positive I'm leaving some things out, but that's the part of the list
>> I can remember.
>>
>> Given the scope change on the document (from Standards Track to
>> Experimental), we authors are asking for WGLC on the document.
>>
>> Regards,
>> Stan
>>
>> _______________________________________________
>> 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
>
>

--001a1142fcb43a3d870530ef2f59
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The document is not ready for standards track publication.=
=C2=A0 If the working group insists on keeping it standards track I'll =
release it from the WG back to the authors now.=C2=A0 Lack of implementatio=
ns, maturity and zero chance of getting WG consensus in any reasonable time=
 frame (reasonable in that it wouldn't kill the WG as a whole) make thi=
s impossible.=C2=A0 If you'd like I can add your complaint to the notes=
 to be listed by the shepherd of objections on process if we get to that po=
int.

On Wed,=
 Apr 20, 2016 at 2:46 PM, Abdussalam Baryun <abdussalambaryun@g=
mail.com> wrote:
Hi Stan,

I think the WG has to discuss if t=
hey agree to change the status to experimental. For me I don't agree, a=
lso want to know why the authors want to do last call quickly while we are =
doing good discussion in the group. 

AB

On Wed, Apr 20, 2016 at 7:41 PM, S=
tan Ratliff <ratliffstan@gmail.com> wrote:
He=
llo all,=C2=A0

As you've seen, a new version of the =
AODVv2 draft has been posted. Some of the items addressed are:=C2=A0
<=
div>
1. First up, the status of the document has been changed=
 from Standards Track to Experimental.=C2=A0
2. Metrics have been=
 addressed, in an attempt to resolve most (if not all) of the review commen=
ts.=C2=A0
3. There has been work in the multicast RREQ/RREP area.=
=C2=A0
4. The remainder of Justin's last review comments were=
 addressed.=C2=A0

I'm positive I'm leaving=
 some things out, but that's the part of the list I can remember.=C2=A0=


Given the scope change on the document (from Stan=
dards Track to Experimental), we authors are asking for WGLC on the documen=
t.=C2=A0

Regards,
Stan


__________________________________________=
_____

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





--001a1142fcb43a3d870530ef2f59--


From nobody Wed Apr 20 12:08: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 C579912E3D0 for ; Wed, 20 Apr 2016 12:08: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 Vp41IjNI2WlC for ; Wed, 20 Apr 2016 12:08:54 -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 B65AA12D611 for ; Wed, 20 Apr 2016 12:08:54 -0700 (PDT)
Received: by mail-vk0-x22c.google.com with SMTP id e185so71033632vkb.1 for ; Wed, 20 Apr 2016 12:08: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=YATaNWrk+B6w8RSuRwWy9RpoGFyJqljiTuBrBkco+Pc=; b=JdK3Adr/9J9sil17DUaV2Z311ugDFDmOl11J3sMRl9NjemzkAr3GxovTN0cHKzprKq NXSXzkDQIFAvcRZMhy3CgY5a1qge1MCQGGxC8NfHXqMRC1JmPeWq0RWvepQuKux1tdjj KpJZeJ6CIyh+iptacOY60W69SYk13ri2UUMSfajU2aPtWELv9WtWzdAdxriOZGtrOgRz pihTxh59isYHvUt/vg9zuTVu+HQ8Xq3F06HhYFco9xbzT8Nauop/by5QgXkhbk6SHh6C djv+krofFAabGgcpaklVBhun0DvcQ6PEVz+KcgBG6GN2bBc17aYbbTQVhcR1TH9q8N0x 26dw==
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=YATaNWrk+B6w8RSuRwWy9RpoGFyJqljiTuBrBkco+Pc=; b=CLRMi6d2hu+8QCCn/9Cvg5sg13Zi7dC/VVBY0Sk8Knn+Ne0wqM6H7LMae5EheZAs8D Sqex0KyHO76Ol8RG3qYsG2eGrfj+x/DBYvuYgmk/lJyL9tqs8UDQUmaILYK291Mw76qm unimtbdR1qwRU+teENtLlfX/96c+TMFNac8QYbpbINfCxg+/7SI4nDxkvuMgodbS4RCN moGuvHvilPQ+05lziokWRzHWgXxjzFpDb3Ztf+IEFhhUBWO/1D/Go3M0nCpexe5bn+Q4 LkLxvjz2J6OeYr+2nKKVpNZxFoiEDDhLLSi6Kavs68a6SVUzGRWkGB24CHWf8YYv7uWU MEGQ==
X-Gm-Message-State: AOPr4FVaAPteUiQ/SqRoU3EeDCoFwM+RcCo0uAene74zv266imUFJ3As60IYZvB3VsCdzIxa+G7x2iqnumku2g==
MIME-Version: 1.0
X-Received: by 10.31.157.67 with SMTP id g64mr5425826vke.79.1461179333838; Wed, 20 Apr 2016 12:08:53 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Wed, 20 Apr 2016 12:08:53 -0700 (PDT)
In-Reply-To: <77D03509-AFF7-4A6E-A688-3950EB4F5319@mnemosyne.demon.co.uk>
References:    <77D03509-AFF7-4A6E-A688-3950EB4F5319@mnemosyne.demon.co.uk>
Date: Wed, 20 Apr 2016 15:08:53 -0400
Message-ID: 
From: Justin Dean 
To: Christopher Dearlove 
Content-Type: multipart/alternative; boundary=001a11414f7825a2c40530ef5317
Archived-At: 
Cc: Christopher Dearlove , "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 20 Apr 2016 19:08:56 -0000

--001a11414f7825a2c40530ef5317
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 20, 2016 at 3:06 PM, Christopher Dearlove <
chris@mnemosyne.demon.co.uk> wrote:

> No, ten years isn't rushing. Two weeks is.
>
> It's clear you've made a decision. I disagree with it, but I'm not
> expecting to change it. If I have any input in that time, I'll let you have
> it. Or that I haven't been able to. I've made my observations at this
> point, I'll make anything else technical I come across, and I'll let the
> system handle it. But my experience makes me predict a rough road ahead.
>
> Thank you.

Justin

--001a11414f7825a2c40530ef5317
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On W=
ed, Apr 20, 2016 at 3:06 PM, Christopher Dearlove <chris@mnemosy=
ne.demon.co.uk> wrote:
No, ten years isn't rushing. Two weeks is.

It's clear you've made a decision. I disagree with =
it, but I'm not expecting to change it. If I have any input in that tim=
e, I'll let you have it. Or that I haven't been able to. I've m=
ade my observations at this point, I'll make anything else technical I =
come across, and I'll let the system handle it. But my experience makes=
 me predict a rough road ahead.
Thank you. =C2=A0

Justi=
n


--001a11414f7825a2c40530ef5317--


From nobody Wed Apr 20 12:09:09 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 4240212DFD8 for ; Wed, 20 Apr 2016 12:09:08 -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 hfb2Oux5wNMH for ; Wed, 20 Apr 2016 12:09:01 -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 7BF9812E3D0 for ; Wed, 20 Apr 2016 12:09:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9DC71240828; Wed, 20 Apr 2016 12:08:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461179339; bh=mCMIIrxNKER23ZnWKwf+MVzTDpDcaB3YxwVagFMiYNs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=R1Dogox5FeIwQPxU40j5RcjY7IAm8bldFR3UXV83T6wN2cMdWJUKd2Ealefxl/c8N B0NF4PCH1X1p0sUj2ypYchO2jAXPssIMCLF+WFFMrN4qfVufoQpdqwvVY7giAVEAkd U7mKVuw5N2T8IkXK5eg2Nb2O62RRNHzFpM4e/VuU=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.147.204] (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 04CCC240150; Wed, 20 Apr 2016 12:08:59 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-7B5E5C85-5BF0-4706-8AC1-4A87524FB5D2
Mime-Version: 1.0 (1.0)
From: Thomas Clausen 
X-Mailer: iPad Mail (13E238)
In-Reply-To: 
Date: Wed, 20 Apr 2016 21:08:56 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <93C8D245-22E3-48DC-83BC-E0E7674C319C@thomasclausen.org>
References:   
To: Justin Dean 
Archived-At: 
Cc: Christopher Dearlove , "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 20 Apr 2016 19:09:08 -0000

--Apple-Mail-7B5E5C85-5BF0-4706-8AC1-4A87524FB5D2
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Justin,

> On 20 Apr 2016, at 20:51, Justin Dean  wrote:
>=20
>=20
>> On Wed, Apr 20, 2016 at 2:36 PM, Christopher Dearlove  wrote:
>> This is the cart before the horse. I'm pretty sure every IETF guideline s=
ays get the document right, not rush to a deadline.
>>=20
> 10+ years isn't rushing.=20



> I'd much rather spend our remaining time on technical issues.
> =20

Sorry, no.

The authors having, for 10+ years (as you note yourself), not been discussin=
g technical issues with the WG, but in a private forum apparently with your k=
nowledge/blessing, and the successive WG chairs (you included) having let th=
em get away with it means, that when *you* issue a WGLC under these conditio=
ns, you do get to discuss those process issues.

Thomas


> Justin
>=20
>> Incidentally - and obviously I haven't read the draft (and right now I'm n=
ot committing to do so in the timescale) - the last draft I was an author of=
 that left the WG in experimental state, there was a requirement to add a de=
scription of the experiment. (It actually made experimental harder work than=
 standards track in material to write.) But whether that will be required he=
re, no idea.
>>=20
>> --
>> Christopher Dearlove
>> christopher.dearlove@gmail.com (iPhone)
>> chris@mnemosyne.demon.co.uk (home)
>>=20
>> > On 20 Apr 2016, at 18:50, Justin Dean  wrote:
>> >
>> > As Thomas has noted the status has changed to experimental.  You beat t=
he authors to the punch in noticing that before they posted up an overview e=
mail.  In short, we, the working group are out of time. It's now time to fin=
ish this document.  Not all open issues (ones brought up today or not decide=
d upon) metrics, security, and a few others have not been incorporated into t=
his updated draft.  Regardless we are out of time and we need to move on to o=
ther work specifically having a new charter finished and approved before the=
 next IETF.
>> >
>> > So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended status=
 change, updates to the draft, and my review, and continued intense work fro=
m the editorship team and the working group there is a chance of success.  T=
he working group will have 2 weeks to provide input at which time I'll make t=
he call to pass it on up to the IESG or remove it as a WG item and hand it b=
ack to the authors to do with it what they will.
>> >
>> > Due to the short timeline we will also need to discuss and come to cons=
ensus on a new WG charter. I'll start that in another email thread.
>> >
>> > Justin
>> >
>> > p.s. I'm looking forward to continued positive discussions and improvem=
ents.  AODVv2 I STRONGLY encourage you to use (almost exclusively to the ext=
ent possible) the MANET list for all future AODVv2 discussions within this l=
ast call period.
>> > _______________________________________________
>> > 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-7B5E5C85-5BF0-4706-8AC1-4A87524FB5D2
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Justin,

On 20 Apr 2016, at 20:51, Justin Dean <bebemaster@gmail.com> wrote:

=


On Wed, Apr 20, 2016 at 2:36 PM, Christopher Dearlo=
ve <christopher.dearlove@gmail.com> wrote:
This is the cart before the horse. I'm pretty sur=
e every IETF guideline says get the document right, not rush to a deadline.<=
br>

10+ years isn't rushing. 
=


<SNIP>

<=
div>
<=
div>I'd much rather spend our remaining time on technical issues.
=
 

Sor=
ry, no.

The authors having, for 10+ years (as you note y=
ourself), not been discussing technical issues with the WG, but in a private=
 forum apparently with your knowledge/blessing, and the successive WG chairs=
 (you included) having let them get away with it means, that when *you* issu=
e a WGLC under these conditions, you do get to discuss those process issues.=


Thomas


Justin


Incidentally - and obviously I haven't read the draft (and right now I'm not=
 committing to do so in the timescale) - the last draft I was an author of t=
hat left the WG in experimental state, there was a requirement to add a desc=
ription of the experiment. (It actually made experimental harder work than s=
tandards track in material to write.) But whether that will be required here=
, no idea.



--

Christopher Dearlove

christopher.dearlove@gmail=
.com (iPhone)

chris@mnemosyne.demon.co.uk (home)




> On 20 Apr 2016, at 18:50, Justin Dean <bebemaster@gmail.com> wrote:

>

> As Thomas has noted the status has changed to experimental.  You b=
eat the authors to the punch in noticing that before they posted up an overv=
iew email.  In short, we, the working group are out of time. It's now t=
ime to finish this document.  Not all open issues (ones brought up toda=
y or not decided upon) metrics, security, and a few others have not been inc=
orporated into this updated draft.  Regardless we are out of time and w=
e need to move on to other work specifically having a new charter finished a=
nd approved before the next IETF.

>

> So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended s=
tatus change, updates to the draft, and my review, and continued intense wor=
k from the editorship team and the working group there is a chance of succes=
s.  The working group will have 2 weeks to provide input at which time I=
'll make the call to pass it on up to the IESG or remove it as a WG item and=
 hand it back to the authors to do with it what they will.

>

> Due to the short timeline we will also need to discuss and come to cons=
ensus on a new WG charter. I'll start that in another email thread.

>

> Justin

>

> p.s. I'm looking forward to continued positive discussions and improvem=
ents.  AODVv2 I STRONGLY encourage you to use (almost exclusively to th=
e extent possible) the MANET list for all future AODVv2 discussions within t=
his last call period.


> ___________________=
____________________________

> 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-7B5E5C85-5BF0-4706-8AC1-4A87524FB5D2--


From nobody Wed Apr 20 12:10: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 CA75A12E3A2 for ; Wed, 20 Apr 2016 12:10:20 -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 1EDiORbEbqnO for ; Wed, 20 Apr 2016 12:10:18 -0700 (PDT)
Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 C60BA12E0C0 for ; Wed, 20 Apr 2016 12:10:17 -0700 (PDT)
Received: by mail-wm0-x244.google.com with SMTP id e201so12865296wme.2 for ; Wed, 20 Apr 2016 12:10:17 -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=Dcywh76KFE55tgKZovJ25rXuJPrBTrU0RVL+PIk39ps=; b=0VIx5YQ+9rbq7XRzSB76n/xjjw3xwscA6AV5w7XIIU/f4npx0RR6Yat3EFEZrd6dLw OyAK6K8jWsi1H3dmjf9wEvFHDiKeMbNf+rVxVFRINSqLUzD5xu41+GPhH2TU8AY4afWC 45H83BMXUfk1k4sHLyO8ZHsCsj64+drGh76hC23BgsePwg+yFLRktNSahTCqchB1Roj4 1t68hAm72Gkjffw+6zhrUHM9XSdulkRyE6bNFkJb8ahHDMEJXxNYeuIjdT5ebkghvSud rfRLgR2A6n4nDr3Oyu2s9gY/qRZAIaZ0MHQf5cOEZBWvTsG/gaGfzWGvgMZPi2zl9Wd2 BquQ==
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=Dcywh76KFE55tgKZovJ25rXuJPrBTrU0RVL+PIk39ps=; b=P3LpqVEhV1e1k2LBczwOMBsHQUavqYf7NiIuXCDoR7f5frvuXXGIg4XOD5Xd+zd7aj z8ETeiVXQhW+j0Bjajv4Ij3OMLMQqT6JmUk+JMn9yIjGq/crLzlGnzaYlcRDSh3M4/H/ dBt6XFUXKFwnM8fPAz+VJ2X5d2uHEhcrTvveidlgj5PtSqPbML1tA8kzLhmTg1Zdz6JV rYRSV5tg4j8bY+qv3W43TEri4wgfH3pwa9+4pME/E4I3XOp9ARhKZ5fhaPiKIHB9wIRw St6l71oex4DNKWCPw92zucrpvI+eP7LKAlnjbaY1+AM27afvll8+Db09ZJcaqSXJ8wVt fCuw==
X-Gm-Message-State: AOPr4FXpW8BG983SocgLo4TA3zAG1/2gRhzGf5IRUrKTL+5LXFBONg6hrF/gE2SNDovjYA==
X-Received: by 10.28.4.194 with SMTP id 185mr10154355wme.11.1461179416218; Wed, 20 Apr 2016 12:10:16 -0700 (PDT)
Received: from [10.8.198.83] (82-132-221-12.dab.02.net. [82.132.221.12]) by smtp.gmail.com with ESMTPSA id f8sm7033481wjm.13.2016.04.20.12.10.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2016 12:10:15 -0700 (PDT)
References:  <2055300A-2F04-4D99-9F81-02F66AB88FFB@thomasclausen.org>  <40660D3F-F7BE-447A-93DC-1439C6215B04@thomasclausen.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <40660D3F-F7BE-447A-93DC-1439C6215B04@thomasclausen.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-87968617-623B-4B5B-AD92-1B4B03F0ED33
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPhone Mail (13E238)
From: Christopher Dearlove 
Date: Wed, 20 Apr 2016 20:10:11 +0100
To: Thomas Clausen 
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 20 Apr 2016 19:10:20 -0000

--Apple-Mail-87968617-623B-4B5B-AD92-1B4B03F0ED33
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I'm a step back from that. I expect, if we get there, the document shepherd t=
o note however many people express dissatisfaction with the timescale (and a=
spects of process) but that's as far as I'm going to take it. (At standards t=
rack would have been a different issue.)

-- =20
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)

> On 20 Apr 2016, at 19:54, Thomas Clausen  wrote:
>=20
> Justin, all
>=20
> You are asking the WG to do in two weeks, what the authors have just not d=
one in 3 (or, to be fair, more like 10...) years: discuss the document on th=
e manet@ietf.org list, and resolve all issues - issues, which you know exist=
, because they have been raised on the list....for, if not 10 years, then at=
 the least 4-5 years.
>=20
> Except, the WG gets two weeks to do so.=20
>=20
> If you (as chair) feel the document is not right, pull it.=20
> If you (as chair) in the past have felt it wasn't going in the right decis=
ion, you could have stepped on the authors earlier, or replaced them, or spo=
ken to your AD, or to the WG, or something else.
>=20
> But to expect the WG to resolve this document in 2 weeks, after having bee=
n kept in the dark (apparently the document was discussed in some other, clo=
sed, forum -- with the WG chairs knowledge) for years, is simply not reasona=
ble, and is simply not possible.
>=20
> I believe, in fact, it would give cause for an appeal. Document shepherd, i=
f/when appointed, take notice.
>=20
> Thomas
>=20
>=20
>> On 20 Apr 2016, at 20:17, Justin Dean  wrote:
>>=20
>> We are out of time.  This WGLC is the final 2 weeks one way or another.  Y=
ou're comments are valid and understood we just don't have any more time.  H=
ow things go depends on the working group and the editorship team.  WGLC doe=
sn't mean that the draft is finished, it's a means for the chair to explicit=
ly poll the WG when I feel a document has a chance to find consensus.  Also,=
 we are out of time.
>>=20
>> Justin
>>=20
>>> On Wed, Apr 20, 2016 at 2:10 PM,  wrote:
>>> Justin,
>>>=20
>>> > On Apr 20, 2016, at 19:50, Justin Dean  wrote:
>>> >
>>> > As Thomas has noted the status has changed to experimental.  You beat t=
he authors to the punch in noticing that before they posted up an overview e=
mail.  In short, we, the working group are out of time. It's now time to fin=
ish this document.  Not all open issues (ones brought up today or not decide=
d upon) metrics, security, and a few others have not been incorporated into t=
his updated draft.  Regardless we are out of time and we need to move on to o=
ther work specifically having a new charter finished and approved before the=
 next IETF.
>>> >
>>> > So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended statu=
s change, updates to the draft, and my review, and continued intense work fr=
om the editorship team and the working group there is a chance of success.  T=
he working group will have 2 weeks to provide input at which time I'll make t=
he call to pass it on up to the IESG or remove it as a WG item and hand it b=
ack to the authors to do with it what they will.
>>>=20
>>> What the heck? A WGLC is simply inappropriate at this stage, for reasons=
 including the following:
>>>=20
>>>         o       There were core algorithmic changes between -14 and -15 (=
message processing, =E2=80=A6)
>>>                 that have not been discussed,  let alone not reviewed (m=
ulticast processing, for example)
>>>                 on the list.
>>>=20
>>>         o       There are *many* unresolved issues in this document (I j=
ust did a quick RFCdiff), despite
>>>                 the changes between -14 and -15, and discussion of some o=
f these is ongoing on the list.
>>>                 None of those issues are new, but have been raised in th=
e far past, on the list =E2=80=A6
>>>=20
>>>         o       The document is 78 pages long.
>>>=20
>>> Those three combined means that the document should not be WGLCed, certa=
inly not with only a 2 week lead time, at this juncture.
>>>=20
>>> Best,
>>>=20
>>> Thomas
>>>=20
>>> > Due to the short timeline we will also need to discuss and come to con=
sensus on a new WG charter. I'll start that in another email thread.
>>> >
>>> > Justin
>>> >
>>> > p.s. I'm looking forward to continued positive discussions and improve=
ments.  AODVv2 I STRONGLY encourage you to use (almost exclusively to the ex=
tent possible) the MANET list for all future AODVv2 discussions within this l=
ast call period.
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

--Apple-Mail-87968617-623B-4B5B-AD92-1B4B03F0ED33
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I'm a step back from that. I expect, i=
f we get there, the document shepherd to note however many people express di=
ssatisfaction with the timescale (and aspects of process) but that's as far a=
s I'm going to take it. (At standards track would have been a different issu=
e.)

--  
Christopher Dearlove

On 20 Apr 2016, at 19:54, Thomas Claus=
en <ietf@thomasclausen.org&=
gt; wrote:


Justin, all

You are asking the WG to do in two weeks, what the authors ha=
ve just not done in 3 (or, to be fair, more like 10...) years: discuss the d=
ocument on the manet@ietf.org list, an=
d resolve all issues - issues, which you know exist, because they have been r=
aised on the list....for, if not 10 years, then at the least 4-5 years.

Exc=
ept, the WG gets two weeks to do so. 

If you (as chair) feel the docum=
ent is not right, pull it. 
If you (=
as chair) in the past have felt it wasn't going in the right decision, you c=
ould have stepped on the authors earlier, or replaced them, or spoken to you=
r AD, or to the WG, or something else.
<=
br>
But to expect the WG to resolve this=
 document in 2 weeks, after having been kept in the dark (apparently the doc=
ument was discussed in some other, closed, forum -- with the WG chairs knowl=
edge) for years, is simply not reasonable, and is simply not possible.
=


I be=
lieve, in fact, it would give cause for an appeal. Document shepherd, if/whe=
n appointed, take notice.

Thomas


On 20 Apr 2016, at 20:17, J=
ustin Dean <bebemaster@gmail.com<=
/a>> wrote:


On Wed, Apr 20, 2016 at 2:10 PM, =
 <ietf@thomasclausen.org> wrote:
Justin,



> On Apr 20, 2016, at 19:50, Justin Dean <bebemaster@gmail.com> wrote:

>

> As Thomas has noted the status has changed to experimental.  You b=
eat the authors to the punch in noticing that before they posted up an overv=
iew email.  In short, we, the working group are out of time. It's now t=
ime to finish this document.  Not all open issues (ones brought up toda=
y or not decided upon) metrics, security, and a few others have not been inc=
orporated into this updated draft.  Regardless we are out of time and w=
e need to move on to other work specifically having a new charter finished a=
nd approved before the next IETF.

>

> So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended s=
tatus change, updates to the draft, and my review, and continued intense wor=
k from the editorship team and the working group there is a chance of succes=
s.  The working group will have 2 weeks to provide input at which time I=
'll make the call to pass it on up to the IESG or remove it as a WG item and=
 hand it back to the authors to do with it what they will.



What the heck? A WGLC is simply inappropriate at this stage, for reas=
ons including the following:



        o       There were core algo=
rithmic changes between -14 and -15 (message processing, =E2=80=A6)

                that have not been d=
iscussed,  let alone not reviewed (multicast processing, for example)
                on the list.



        o       There are *many* unr=
esolved issues in this document (I just did a quick RFCdiff), despite

                the changes between -=
14 and -15, and discussion of some of these is ongoing on the list.

                None of those issues=
 are new, but have been raised in the far past, on the list =E2=80=A6



        o       The document is 78 p=
ages long.



Those three combined means that the document should not be WGLCed, certainly=
 not with only a 2 week lead time, at this juncture.



Best,



Thomas




> Due to the short timeline we will also need to discuss and come to cons=
ensus on a new WG charter. I'll start that in another email thread.

>

> Justin

>

> p.s. I'm looking forward to continued positive discussions and improvem=
ents.  AODVv2 I STRONGLY encourage you to use (almost exclusively to th=
e extent possible) the MANET list for all future AODVv2 discussions within t=
his last call period.







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

--Apple-Mail-87968617-623B-4B5B-AD92-1B4B03F0ED33--


From nobody Wed Apr 20 12:20: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 9641812E043 for ; Wed, 20 Apr 2016 12:20:32 -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 mZsWIBWvGAzQ for ; Wed, 20 Apr 2016 12:20:31 -0700 (PDT)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c: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 AA86412E24F for ; Wed, 20 Apr 2016 12:20:30 -0700 (PDT)
Received: by mail-vk0-x230.google.com with SMTP id n67so62625267vkf.3 for ; Wed, 20 Apr 2016 12:20:30 -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=liDfxXpUnpuyo9vXfhIC+91yOcIFaNVBD46UlpsCo3E=; b=r6iC+jATCVwDkkdoJqEYVKsl//0CJdpBVG0uRgtk1aHiNTR6820NZwuAO5MojX80Qt 7ICICspy6zzQDI4Ffl3kB0Ih4quySezNgO4XBqej0TVsjAoU5BrP32yEZt4oCP/CsM1O lzXIvDud9F1frmCxrEBefuWEkBMbdjHbIbS17LXNwzjyPEb3CxDW6HFzmkbEQjsyF+bf Kugg4NSSWYsBxpNmt57uIdnAtpUoF12BSjzHzacSIXbgBzUvd6mlXLdpVTteIXClG5Ii V3rqLXr64ZlUqPbx6nic75Ou+PRAHDPdhzEVnO6ODm4cToRCz5fRne2F9bdeHSN9mAIY QQrw==
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=liDfxXpUnpuyo9vXfhIC+91yOcIFaNVBD46UlpsCo3E=; b=jLcFdPF5Q1Ohq7/zOE1wziSd6w2gG747P84x1MGHtMuxSB0fmS8SjKN+kGqlRuBpv3 tc+dXjbXm55ugmadOnD1XhvX/Eom0oQdwEQrnRJytvydEUQEyF69pw7jF2ALrI8xR6/G 3bIRfnr7GbBQsLmwJC/phqVv7NlbEmWmnRUVJndtHF1T0qady7I/iVgONb+wP0PYcwMb LyKe9LeNZtSpWgLjmMWhGtAC48QpNymDvP3/dLth/7X7eJlRh7zcyLxnPIaKKdOi7ZIP n/97E7dLIvnnMRple/lkcHfg7heKBWBzP88IwxUmdlxxXxGT+6kEQMSwd1fc31/larQ2 vP2Q==
X-Gm-Message-State: AOPr4FWfNPPKxqPE6TN2mhbmvLie1+CQiS1Je1wCcP0yBKkzpFOFOUKeqnUBQ+tbuS0XFprNV9TxiiyhhtT7Fg==
MIME-Version: 1.0
X-Received: by 10.31.157.67 with SMTP id g64mr5452464vke.79.1461180029856; Wed, 20 Apr 2016 12:20:29 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Wed, 20 Apr 2016 12:20:29 -0700 (PDT)
In-Reply-To: <93C8D245-22E3-48DC-83BC-E0E7674C319C@thomasclausen.org>
References:    <93C8D245-22E3-48DC-83BC-E0E7674C319C@thomasclausen.org>
Date: Wed, 20 Apr 2016 15:20:29 -0400
Message-ID: 
From: Justin Dean 
To: Thomas Clausen 
Content-Type: multipart/alternative; boundary=001a11414f78a1f6de0530ef7c00
Archived-At: 
Cc: Christopher Dearlove , "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 20 Apr 2016 19:20:32 -0000

--001a11414f78a1f6de0530ef7c00
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 20, 2016 at 3:08 PM, Thomas Clausen 
wrote:

> Justin,
>
> On 20 Apr 2016, at 20:51, Justin Dean  wrote:
>
>
> On Wed, Apr 20, 2016 at 2:36 PM, Christopher Dearlove <
> christopher.dearlove@gmail.com> wrote:
>
>> This is the cart before the horse. I'm pretty sure every IETF guideline
>> says get the document right, not rush to a deadline.
>>
>> 10+ years isn't rushing.
>
>
> 
>
> I'd much rather spend our remaining time on technical issues.
>
>
>
> Sorry, no.
>
> The authors having, for 10+ years (as you note yourself), not been
> discussing technical issues with the WG, but in a private forum apparently
> with your knowledge/blessing, and the successive WG chairs (you included)
> having let them get away with it means, that when *you* issue a WGLC under
> these conditions, you do get to discuss those process issues.
>
> Thomas
>

Technical discussions have been had on this list as was happening this
morning. Any many times in the past.  Yes there is a list the AODVv2 team
uses.  Yes I am aware of that list.  I can ask them to shut it down but
they could just communicate in another way without my knowledge if they so
choose.  I don't follow that list actively only to monitor amount of
activity but you've no way of of knowing that's true so point taken.  I
have repeatedly asked them to use THIS list more.  In this we are in
agreement.

Justin

--001a11414f78a1f6de0530ef7c00
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



=
On Wed, Apr 20, 2016 at 3:08 PM, Thomas Clausen <thomas@thomasclaus=
en.org> wrote:
Justin,

On 20 Apr 2016=
, at 20:51, Justin Dean <bebemaster@gmail.com> wrote:


On Wed, Apr 20, 2016 at 2:36 PM, Christopher Dearlove <christopher.dearlove@gmail.com> wrote:
This is the cart before the horse. I'm pretty sure ev=
ery IETF guideline says get the document right, not rush to a deadline.


10+ years isn't rushing.=C2=A0
<=
/div>

<SNIP>
<=
br>
I'd much rather spend our remaining =
time on technical issues.
=C2=A0

Sorry, no.

The=
 authors having, for 10+ years (as you note yourself), not been discussing =
technical issues with the WG, but in a private forum apparently with your k=
nowledge/blessing, and the successive WG chairs (you included) having let t=
hem get away with it means, that when *you* issue a WGLC under these condit=
ions, you do get to discuss those process issues.

Thomas

Technical discussions have been had on this list =
as was happening this morning. Any many times in the past.=C2=A0 Yes there =
is a list the AODVv2 team uses.=C2=A0 Yes I am aware of that list.=C2=A0 I =
can ask them to shut it down but they could just communicate in another way=
 without my knowledge if they so choose.=C2=A0 I don't follow that list=
 actively only to monitor amount of activity but you've no way of of kn=
owing that's true so point taken.=C2=A0 I have repeatedly asked them to=
 use THIS list more.=C2=A0 In this we are in agreement. =C2=A0

Justi=
n


--001a11414f78a1f6de0530ef7c00--


From nobody Wed Apr 20 12:24:24 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 715C112E3B3 for ; Wed, 20 Apr 2016 12:24:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=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 L4QiswJLKf-z for ; Wed, 20 Apr 2016 12:24:08 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 3766E12E145 for ; Wed, 20 Apr 2016 12:24:07 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id f89so47345817ioi.0 for ; Wed, 20 Apr 2016 12:24:07 -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=kQayiLti8gv0qyFKG6Phn3+v0jS3na8xPGpHpDz3kjM=; b=UIjDQBZNWgEzcgUKtoS1ljUU/MuQCECeDeZYAIxAAPm/UzwOiSvYfN0WpyC+FabIn/ zujhCrK9CkPnsld1POeYs1vdnQzKd34LJwEyv7wMPs/phqMyETiaOwU52BxjcLHnT84d oebMi4McnyTY2Z8KKEpa87WzS9fFrI8At2P9LvTUurpLjnrG25+T1KEraF3O58VeRKbO zDIFbepso7Yi0EaOlzgO+As60jmCn8nNF1weNeRPoWfTaoIZ7e4A2mmk4UwYE3XeREeR aTM6r0St+lWy2ZwI2YmiibNbYUElI5QNiNh8uqdokjHsszADL++HChIxhgmu6b8cDHzD gDUw==
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=kQayiLti8gv0qyFKG6Phn3+v0jS3na8xPGpHpDz3kjM=; b=Ds56N91yMwCms7zw47NBuk8nrYgnc5zqVRrhozjo/35Dlx2EvkwAqX3yHq+p69v84g VdqdbsNPAHVDo/xIBQsjWujROL24SJI1XXn4rFnbUPlGanI2Kuzm/StnExNmd77s+6Mu qzbsjdq1mf4DhiBcMc+e4aVemF49PDqkpddbQxz87iO520jFRFTag2EEQx8ALbLMQ4yd pj4AyighhJyJ5zvyqu2Dg4Wgdq4HFgVMhlBLd2h2N7ngcjsS50hCGK3R852Nhof3AzI0 tJJrsveCRCiCnkd0HlA8PTktARUkaChUAKioNt+7S0N7rvlCSV2EbHZnPinaBEm1ifv7 70YA==
X-Gm-Message-State: AOPr4FU3FD3UjhvWT9RiOpb7tgfpbcl29NN+p6SkxMs6NhW4U4OeV5w1Q1n116gPHpEgLYGW3m4k/fyBtFVAdA==
MIME-Version: 1.0
X-Received: by 10.107.173.69 with SMTP id w66mr13141586ioe.182.1461180246499;  Wed, 20 Apr 2016 12:24:06 -0700 (PDT)
Received: by 10.79.72.68 with HTTP; Wed, 20 Apr 2016 12:24:06 -0700 (PDT)
In-Reply-To: <93C8D245-22E3-48DC-83BC-E0E7674C319C@thomasclausen.org>
References:    <93C8D245-22E3-48DC-83BC-E0E7674C319C@thomasclausen.org>
Date: Wed, 20 Apr 2016 15:24:06 -0400
Message-ID: 
From: Stan Ratliff 
To: Thomas Clausen 
Content-Type: multipart/alternative; boundary=001a114464f48baff70530ef8932
Archived-At: 
Cc: Christopher Dearlove , "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 20 Apr 2016 19:24:09 -0000

--001a114464f48baff70530ef8932
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 20, 2016 at 3:08 PM, Thomas Clausen 
wrote:

> Justin,
>
> On 20 Apr 2016, at 20:51, Justin Dean  wrote:
>
>
> On Wed, Apr 20, 2016 at 2:36 PM, Christopher Dearlove <
> christopher.dearlove@gmail.com> wrote:
>
>> This is the cart before the horse. I'm pretty sure every IETF guideline
>> says get the document right, not rush to a deadline.
>>
>> 10+ years isn't rushing.
>
>
> 
>
> I'd much rather spend our remaining time on technical issues.
>
>
>
> Sorry, no.
>
> The authors having, for 10+ years (as you note yourself), not been
> discussing technical issues with the WG, but in a private forum apparently
> with your knowledge/blessing, and the successive WG chairs (you included)
> having let them get away with it means, that when *you* issue a WGLC under
> these conditions, you do get to discuss those process issues.
>
>
Once again, we're plowing ground that's already been plowed, and is a
complete red herring. It's been discussed on this list already - the
authors were *not* engaged in a "private kabal", but in discussions amongst
themselves as to how to address issues. We've said before that perhaps this
strayed into being too closed - but to continue to bash over it is silly.
To attempt to blow it up into something more is to edge closer and closer
to "conspiracy theory" territory.

Stan






> Thomas
>
>
> Justin
>
> Incidentally - and obviously I haven't read the draft (and right now I'm
>> not committing to do so in the timescale) - the last draft I was an author
>> of that left the WG in experimental state, there was a requirement to add a
>> description of the experiment. (It actually made experimental harder work
>> than standards track in material to write.) But whether that will be
>> required here, no idea.
>>
>> --
>> Christopher Dearlove
>> christopher.dearlove@gmail.com (iPhone)
>> chris@mnemosyne.demon.co.uk (home)
>>
>> > On 20 Apr 2016, at 18:50, Justin Dean  wrote:
>> >
>> > As Thomas has noted the status has changed to experimental.  You beat
>> the authors to the punch in noticing that before they posted up an overview
>> email.  In short, we, the working group are out of time. It's now time to
>> finish this document.  Not all open issues (ones brought up today or not
>> decided upon) metrics, security, and a few others have not been
>> incorporated into this updated draft.  Regardless we are out of time and we
>> need to move on to other work specifically having a new charter finished
>> and approved before the next IETF.
>> >
>> > So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended status
>> change, updates to the draft, and my review, and continued intense work
>> from the editorship team and the working group there is a chance of
>> success.  The working group will have 2 weeks to provide input at which
>> time I'll make the call to pass it on up to the IESG or remove it as a WG
>> item and hand it back to the authors to do with it what they will.
>> >
>> > Due to the short timeline we will also need to discuss and come to
>> consensus on a new WG charter. I'll start that in another email thread.
>> >
>> > Justin
>> >
>> > p.s. I'm looking forward to continued positive discussions and
>> improvements.  AODVv2 I STRONGLY encourage you to use (almost exclusively
>> to the extent possible) the MANET list for all future AODVv2 discussions
>> within this last call period.
>> > _______________________________________________
>> > 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
>
>

--001a114464f48baff70530ef8932
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Apr 20, 2016 at 3:08 PM, Thomas Clausen <<=
a href=3D"mailto:thomas@thomasclausen.org" target=3D"_blank">thomas@thomasc=
lausen.org> wrote:
Justin,

On 20 Apr 2016, at 20:51, J=
ustin Dean <be=
bemaster@gmail.com> wrote:


On=
 Wed, Apr 20, 2016 at 2:36 PM, Christopher Dearlove <<=
a href=3D"mailto:christopher.dearlove@gmail.com" target=3D"_blank">christop=
her.dearlove@gmail.com> wrote:
This is the cart before the horse. I'm pretty sure every IETF guide=
line says get the document right, not rush to a deadline.


10+ years isn't rushing.=C2=A0
<=
/div>

<SNIP>

I'd much rather spend our remaining time on technical issues=
.
=C2=A0

<=
/div>
Sorry, no.

The authors having, for 10+ years =
(as you note yourself), not been discussing technical issues with the WG, b=
ut in a private forum apparently with your knowledge/blessing, and the succ=
essive WG chairs (you included) having let them get away with it means, tha=
t when *you* issue a WGLC under these conditions, you do get to discuss tho=
se process issues.


Once again, we're plowing ground that's already been plowed, and=
 is a complete red herring. It's been discussed on this list already - =
the authors were *not* engaged in a "private kabal", but in discu=
ssions amongst themselves as to how to address issues. We've said befor=
e that perhaps this strayed into being too closed - but to continue to bash=
 over it is silly. To attempt to blow it up into something more is to edge =
closer and closer to "conspiracy theory" territory.=C2=A0

Stan




=C2=A0
Thomas


Justin


Incidentally - and obviously I haven't read the draft (and right now I&=
#39;m not committing to do so in the timescale) - the last draft I was an a=
uthor of that left the WG in experimental state, there was a requirement to=
 add a description of the experiment. (It actually made experimental harder=
 work than standards track in material to write.) But whether that will be =
required here, no idea.



--

Christopher Dearlove

christo=
pher.dearlove@gmail.com (iPhone)

chris@mnem=
osyne.demon.co.uk (home)




> On 20 Apr 2016, at 18:50, Justin Dean <bebemaster@gmail.com> wrote:

>

> As Thomas has noted the status has changed to experimental.=C2=A0 You =
beat the authors to the punch in noticing that before they posted up an ove=
rview email.=C2=A0 In short, we, the working group are out of time. It'=
s now time to finish this document.=C2=A0 Not all open issues (ones brought=
 up today or not decided upon) metrics, security, and a few others have not=
 been incorporated into this updated draft.=C2=A0 Regardless we are out of =
time and we need to move on to other work specifically having a new charter=
 finished and approved before the next IETF.

>

> So, I'll be issuing a 2 week WGLC on AODVv2.=C2=A0 Given the inten=
ded status change, updates to the draft, and my review, and continued inten=
se work from the editorship team and the working group there is a chance of=
 success.=C2=A0 The working group will have 2 weeks to provide input at whi=
ch time I'll make the call to pass it on up to the IESG or remove it as=
 a WG item and hand it back to the authors to do with it what they will.
>

> Due to the short timeline we will also need to discuss and come to con=
sensus on a new WG charter. I'll start that in another email thread.
>

> Justin

>

> p.s. I'm looking forward to continued positive discussions and imp=
rovements.=C2=A0 AODVv2 I STRONGLY encourage you to use (almost exclusively=
 to the extent possible) the MANET list for all future AODVv2 discussions w=
ithin this last call period.


> _______________________________________________<=
br>
> 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>

_________________________________________=
______

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet





--001a114464f48baff70530ef8932--


From nobody Wed Apr 20 12:47: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 E2F7C12E4EC for ; Wed, 20 Apr 2016 12:47:03 -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 wJKBAzC-TEpe for ; Wed, 20 Apr 2016 12:47:02 -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 3DA1212E4AB for ; Wed, 20 Apr 2016 12:47:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F3C2624676C; Wed, 20 Apr 2016 12:47:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461181622; bh=KtQ5RBZKP3KusDhLIGPYU6TzmmXAz/E7yZtk7+bHpDo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=fotyajNgzj2PAh4e4sUdOe3fyZN1hZ+34RG6FbJD5SWYzgRC+StUiUIbh7PgfMg0E +9n1/DSP+XTphhoQGATReWWe7qBIw7soYK5mzwa4sMUNxhj1qrM4s0htLOE2gpRJGM 2BV0YL6vZIJpD5nF//eeGGQS01/paMIygNMYN4Y4=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.147.204] (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 2B0F22510C6; Wed, 20 Apr 2016 12:47:01 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-8E096E1F-AE46-4B10-8C5C-05347718A1D0
Mime-Version: 1.0 (1.0)
From: Thomas Clausen 
X-Mailer: iPad Mail (13E238)
In-Reply-To: 
Date: Wed, 20 Apr 2016 21:46:58 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <37562940-8363-40E5-B53D-B602AE8ED4FB@thomasclausen.org>
References:    <93C8D245-22E3-48DC-83BC-E0E7674C319C@thomasclausen.org> 
To: Justin Dean 
Archived-At: 
Cc: Christopher Dearlove , "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 20 Apr 2016 19:47:04 -0000

--Apple-Mail-8E096E1F-AE46-4B10-8C5C-05347718A1D0
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable


> On 20 Apr 2016, at 21:20, Justin Dean  wrote:
>=20
>=20
>> On Wed, Apr 20, 2016 at 3:08 PM, Thomas Clausen  wrote:
>> Justin,
>>=20
>>> On 20 Apr 2016, at 20:51, Justin Dean  wrote:
>>>=20
>>>=20
>>>> On Wed, Apr 20, 2016 at 2:36 PM, Christopher Dearlove  wrote:
>>>> This is the cart before the horse. I'm pretty sure every IETF guideline=
 says get the document right, not rush to a deadline.
>>>>=20
>>> 10+ years isn't rushing.=20
>>=20
>> 
>>=20
>>> I'd much rather spend our remaining time on technical issues.
>>> =20
>>=20
>> Sorry, no.
>>=20
>> The authors having, for 10+ years (as you note yourself), not been discus=
sing technical issues with the WG, but in a private forum apparently with yo=
ur knowledge/blessing, and the successive WG chairs (you included) having le=
t them get away with it means, that when *you* issue a WGLC under these cond=
itions, you do get to discuss those process issues.
>>=20
>> Thomas
>=20
> Technical discussions have been had on this list as was happening this mor=
ning. Any many times in the past.=20
> Yes there is a list the AODVv2 team uses.  Yes I am aware of that list.  I=
 can ask them to shut it down but they could just communicate in another way=
 without my knowledge if they so choose.

On the above, no, you are wrong. As WG chair, you can do much more than thro=
w up your arms in despair, and then watch the train-wreck unfold.

For example, you instruct the authors to communicate and discuss issues on t=
he WG list, openly. If they don't (regardless of if they discuss on another l=
ist, which you are on, or not) then as WG chair you say:

	Guys, this is a WG document. You are not developing this document w=
ithin the WG,
	despite my instructions. Thank you for your effort, you are hereby r=
eplaced by=20
	Pierre, Paul and Pascale, as authors.

Since I am not on that "secret list", I do not know - but you presumably do.=
 Outside of these process issues, have AODVv2 protocol design and  document e=
diting issues been, in majority, discussed on the "secret list" or on the MA=
NET list?

In the past, there have been reviews posted to this document and its predece=
ssor, on the Manet list, which were ignored for months, years, and even demi=
-decades.

Issues and reviews have been brought up, the resolutions of which have not b=
een discussed on the Manet list, but rather the authors have dumped a monoli=
thic "here's a new version" without explanation, on the Manet list.

Rather than discussing with the WG on the Manet list, e.g., regarding 5444-u=
sage, metrics, security, ..., the authors of this document have been working=
 in a private forum, often on misunderstandings.

And, various WG participants have been asking, begging, insisting that thing=
s should not be discussed in private, to no avail.

All this adds up to "a non IETF protocol, brought in for publication as an R=
FC" - which is what the Independent Stream or AD sponsorship (if IETF review=
 is desired) is for.=20

WGLCing this document is not appropriate.

Thomas

>   I don't follow that list actively only to monitor amount of activity but=
 you've no way of of knowing that's true so point taken.  I have repeatedly a=
sked them to use THIS list more.  In this we are in agreement. =20


> Justin

--Apple-Mail-8E096E1F-AE46-4B10-8C5C-05347718A1D0
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 20 Apr 20=
16, at 21:20, Justin Dean <bebema=
ster@gmail.com> wrote:


On W=
ed, Apr 20, 2016 at 3:08 PM, Thomas Clausen <thomas@thomasclausen.org=
> wrote:
Justin,

On 20 Apr 2016, at 20:5=
1, Justin Dean <bebemaster@gmail.com> wrote:

=


O=
n Wed, Apr 20, 2016 at 2:36 PM, Christopher Dearlove <<=
a href=3D"mailto:christopher.dearlove@gmail.com" target=3D"_blank">christoph=
er.dearlove@gmail.com> wrote:
This is the cart before the horse. I'm pretty sure every IETF guideline say=
s get the document right, not rush to a deadline.


10+ years isn't rushing. 
=


<SNIP>

I'd much rather spend our remaining time on tech=
nical issues.
 

Sorry, no.

The authors havin=
g, for 10+ years (as you note yourself), not been discussing technical issue=
s with the WG, but in a private forum apparently with your knowledge/blessin=
g, and the successive WG chairs (you included) having let them get away with=
 it means, that when *you* issue a WGLC under these conditions, you do get t=
o discuss those process issues.

Thomas

Technical discussions have been had on this list as was happening this=
 morning. Any many times in the past. 
 Yes there is a list the AODVv=
2 team uses.  Yes I am aware of that list.  I can ask them to shut=
 it down but they could just communicate in another way without my knowledge=
 if they so choose.

On the above, no, you are wrong. As WG chair, you can do much more than thr=
ow up your arms in despair, and then watch the train-wreck unfold.

For example, you instruct the authors to communicate and dis=
cuss issues on the WG list, openly. If they don't (regardless of if they dis=
cuss on another list, which you are on, or not) then as WG chair you say:

	Guys, this is a WG document. You are not developing this d=
ocument within the WG,
	despite my instructions. Thank y=
ou for your effort, you are hereby replaced by 
	Pierre, Paul=
 and Pascale, as authors.

Since I am not on that=
 "secret list", I do not know - but you presumably do. Outside of these proc=
ess issues, have AODVv2 protocol design and  document editing issues be=
en, in majority, discussed on the "secret list" or on the MANET list?=


In the p=
ast, there have been reviews posted to this document and its predecessor, on=
 the Manet list, which were ignored for months, years, and even demi-decades=
.

<=
/span>
I=
ssues and reviews have been brought up, the resolutions of which have not be=
en discussed on the Manet list, but rather the authors have dumped a monolit=
hic "here's a new version" without explanation, on the Manet list.

Rather=
 than discussing with the WG on the Manet list, e.g., regarding 5444-usage, m=
etrics, security, ..., the authors of this document have been working in a p=
rivate forum, often on misunderstandings.

And, various WG participants hav=
e been asking, begging, insisting that things should not be discussed in pri=
vate, to no avail.

All this adds up to "a non IETF protocol, brought in f=
or publication as an RFC" - which is what the Independent Stream or AD spons=
orship (if IETF review is desired) is for. 

=
WGLCing this docum=
ent is not appropriate.

Thomas

  I don't follow that list actively only to monitor amount of=
 activity but you've no way of of knowing that's true so point taken.  I=
 have repeatedly asked them to use THIS list more.  In this we are in a=
greement.  


Justin
=


=

--Apple-Mail-8E096E1F-AE46-4B10-8C5C-05347718A1D0--


From nobody Wed Apr 20 12:52: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 71BC012D996 for ; Wed, 20 Apr 2016 12:52:46 -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 z89csBiphSsA for ; Wed, 20 Apr 2016 12:52:45 -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 3C60A12D677 for ; Wed, 20 Apr 2016 12:52:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 11C7326631C; Wed, 20 Apr 2016 12:52:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461181965; bh=g6UsgouYx/9LhShtQCPn2noA1SdCydvFlh8OwI6kdv8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Vdsi7EOKVZzWSUl2bAJqOntq+5TTGo7zp8IAAdTD1OewDa6iOu2OnIZz3UhU7Y0dp aWSbsQW2mxUj6mUx0LO0nAQPkN7E49pw3uSPKLtBOhBtC1EiwiqHRlcnL+L8ScgvP6 nzyvS2nKqCECH7KSMaG6YIyUu5KP06Vjd++71pE0=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.147.204] (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 72A782464D2; Wed, 20 Apr 2016 12:52:44 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-37132316-BE2A-4F38-80E0-1688FB50B208
Mime-Version: 1.0 (1.0)
From: Thomas Clausen 
X-Mailer: iPad Mail (13E238)
In-Reply-To: 
Date: Wed, 20 Apr 2016 21:52:42 +0200
Content-Transfer-Encoding: 7bit
Message-Id: 
References:    <93C8D245-22E3-48DC-83BC-E0E7674C319C@thomasclausen.org> 
To: Stan Ratliff 
Archived-At: 
Cc: Christopher Dearlove , "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 20 Apr 2016 19:52:46 -0000

--Apple-Mail-37132316-BE2A-4F38-80E0-1688FB50B208
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable


> On 20 Apr 2016, at 21:24, Stan Ratliff  wrote:
>=20
>=20
>=20
>> On Wed, Apr 20, 2016 at 3:08 PM, Thomas Clausen  wrote:
>> Justin,
>>=20
>>> On 20 Apr 2016, at 20:51, Justin Dean  wrote:
>>>=20
>>>=20
>>>> On Wed, Apr 20, 2016 at 2:36 PM, Christopher Dearlove  wrote:
>>>> This is the cart before the horse. I'm pretty sure every IETF guideline=
 says get the document right, not rush to a deadline.
>>> 10+ years isn't rushing.=20
>>=20
>> 
>>=20
>>> I'd much rather spend our remaining time on technical issues.
>>=20
>> Sorry, no.
>>=20
>> The authors having, for 10+ years (as you note yourself), not been discus=
sing technical issues with the WG, but in a private forum apparently with yo=
ur knowledge/blessing, and the successive WG chairs (you included) having le=
t them get away with it means, that when *you* issue a WGLC under these cond=
itions, you do get to discuss those process issues.
>=20
> Once again, we're plowing ground that's already been plowed, and is a comp=
lete red herring. It's been discussed on this list already - the authors wer=
e *not* engaged in a "private kabal", but in discussions amongst themselves a=
s to how to address issues. We've said before that perhaps this strayed into=
 being too closed - but to continue to bash over it is silly. To attempt to b=
low it up into something more is to edge closer and closer to "conspiracy th=
eory" territory.=20
>=20

I'll ignore the condescending tone of your email, but simply say:

If  you indeed were not engaged in a "private kabal", but wanted to do the r=
ight thing then why didn't you just when this was (quoting you) "discussed o=
n the list already", say:

	"oops, sorry, we're shutting the private list and taking all that p=
ublic - now."=20

Nobody *forced* you to keep developing this protocol out-of-view of the publ=
ic and out-of-view of the IETF.

Thomas=

--Apple-Mail-37132316-BE2A-4F38-80E0-1688FB50B208
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 20 Apr 20=
16, at 21:24, Stan Ratliff <ratl=
iffstan@gmail.com> wrote:



On Wed, Apr 20, 2016 at 3:08 PM, Thomas Clausen <thomas@thomascla=
usen.org> wrote:
Justin,

On 20 Apr 2016, at 20:51, Justin=
 Dean <bebemast=
er@gmail.com> wrote:


On Wed, Apr 2=
0, 2016 at 2:36 PM, Christopher Dearlove <christopher.dearlove@=
gmail.com> wrote:
This is the c=
art before the horse. I'm pretty sure every IETF guideline says get the docu=
ment right, not rush to a deadline.


10+ years isn't rushing. 
=


<SNIP>

<=
div>
<=
div>I'd much rather spend our remaining time on technical issues.
=
 

Sor=
ry, no.

The authors having, for 10+ years (as you note y=
ourself), not been discussing technical issues with the WG, but in a private=
 forum apparently with your knowledge/blessing, and the successive WG chairs=
 (you included) having let them get away with it means, that when *you* issu=
e a WGLC under these conditions, you do get to discuss those process issues.=



Once again, we'r=
e plowing ground that's already been plowed, and is a complete red herring. I=
t's been discussed on this list already - the authors were *not* engaged in a=
 "private kabal", but in discussions amongst themselves as to how to address=
 issues. We've said before that perhaps this strayed into being too closed -=
 but to continue to bash over it is silly. To attempt to blow it up into som=
ething more is to edge closer and closer to "conspiracy theory" territory.&n=
bsp;


I'll ignore the condescending tone of your email, but simply say:

<=
/div>
If  you indeed were not engaged in a "private kabal", but wan=
ted to do the right thing then why didn't you just when this was (quoting you) "discussed o=
n the list already", say:

	"oops, sorry, we're shutting the private list and=
 taking all that public - now." 

No=
body *forced* you to keep developing this protocol out-of-view of the public=
 and out-of-view of the IETF.

Thomas
=

--Apple-Mail-37132316-BE2A-4F38-80E0-1688FB50B208--


From nobody Wed Apr 20 13:28:54 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 8253812E5EB for ; Wed, 20 Apr 2016 13:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Level: 
X-Spam-Status: No, score=-15.516 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_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 qPk1wlE2eW52 for ; Wed, 20 Apr 2016 13:28:51 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A67412E5DF for ; Wed, 20 Apr 2016 13:28:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16289; q=dns/txt; s=iport; t=1461184131; x=1462393731; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=RqZnY14ldJIqkNozQ7rkae3D7qDs5QdPLQWhFRJFf0c=; b=Fe8Zda6rPkt7ZGcGkTmjMhodNfMXfFVE0fI9QAOfqg2UEmHnFor5B+f7 oQJNFVro/BAEI7592OZ3LyLWLhxVMhClcXbl1JyLlQk4o/yWme9MD8Ior KQF6sZxuBaaq3kRkJwkMIo/6phFdGFG8QHQ1UjUt4HPLQU/b1d6OURhZ/ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAgDr5RdX/4YNJK1egmxNU30Grg2Ga?= =?us-ascii?q?4RyAQ2BciKFbAKBTjgUAQEBAQEBAWUcC4RCAQEEbhsCAQg/ByERFBECBBOIFQM?= =?us-ascii?q?SDroBDYRwAQEBAQEFAQEBAQEBFgSGIYRLgkGBTQxShSkFh22LMYRAMQGFeoIxg?= =?us-ascii?q?3KBdo8QhjyBE4ddAR4BAUKCBBqBSmyHCz5+AQEB?=
X-IronPort-AV: E=Sophos; i="5.24,510,1454976000"; d="scan'208,217"; a="99415308"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2016 20:28:50 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3KKSow7017321 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 20 Apr 2016 20:28:50 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Apr 2016 15:28:49 -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; Wed, 20 Apr 2016 15:28:49 -0500
From: "Alvaro Retana (aretana)" 
To: "manet@ietf.org" 
Thread-Topic: [manet] New AODVv2 draft and status
Thread-Index: AQHRmy00HZqORbCLoUOtSCgFYaZnfp+TYN+A
Date: Wed, 20 Apr 2016 20:28:49 +0000
Message-ID: 
References: 
In-Reply-To: 
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: multipart/alternative; boundary="_000_D33D4A55120638aretanaciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [manet] New AODVv2 draft and status
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, 20 Apr 2016 20:28:53 -0000

--_000_D33D4A55120638aretanaciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

On 4/20/16, 1:50 PM, "manet on behalf of Justin Dean"  on behalf of bebemaster@gmail.com> wrote:

Hi!

Regardless we are out of time and we need to move on to other work specific=
ally having a new charter finished and approved before the next IETF.

Justin has mentioned several times that "we are out of time".  I think it i=
s important for me to expand on what he means (or at least what I have talk=
ed to the Chairs about).

As all of you know, AODVv2 is the last piece of work that the WG needs to c=
lear before moving on to new topics.  While the current draft was adopted b=
y the WG in 2013, the original draft (draft-ietf-manet-dymo) was first publ=
ished in 2005.  There have been ups and downs in the interest of the WG and=
 the speed at which the authors produce updates and address comments.  The =
WG has considered alternatives and has even seen "lines in the sand" drawn =
and then taken over by time=85

I'm not interested in revisiting the decisions made in the past=85  The cur=
rent facts are that the WG has been involved in discussions around AODVv2 f=
or at least the last year (when I became the responsible AD) and that we do=
n't seem to be significantly closer than we were then to moving on [*].  Th=
is situation has heavily contributed to the WG not meeting for two IETF cyc=
les.

It has become painfully clear to me that the WG may not be able to complete=
 the work it has been chartered with [*].  According to rfc2418 [1], if "=
=85it becomes evident that a working group is unable to complete the work o=
utlined in the charter, =85the working group can either:

   1. Recharter to refocus its tasks,
   2. Choose new Chair(s), or
   3. Disband."

I don't believe that at this point changing the Chairs would help [*].  I d=
o believe that Mobile Ad-Hoc Networking is an important topic for the IETF =
to be involved in, which means that the obvious step forward is to recharte=
r.

Given the still active discussion on AODVv2, I don't think it is the right =
thing to expect it to continue (and be concluded at some point [*]) mixed i=
n with new charter items.  In other words, the WG has to clear the AODVv2 w=
ork item before moving on: (as Justin put it earlier) "pass it on up to the=
 IESG or remove it as a WG item and hand it back to the authors to do with =
it what they will" [2].  As you have already noticed, the chosen path is to=
 attempt to reach WG consensus in the next 2 weeks or give up.

There is no time limit related to how long a WG may discuss a specific topi=
c.  Besides the fact that the WG doesn't seem to be making progress [*], wh=
y the hurry?  IETF 96 is scheduled for the 3rd week in July.  Unless the WG=
 has a new Charter, this will be the 3rd meeting in a row without a manet W=
G session.  As I've been trying to elaborate above: there is no new Charter=
 because the WG hasn't been able to complete the current work.  Going back =
to the options from rfc2418, the next action would then be to close the WG.

[Slight aside:  IETF 96 starts on Jul/18.  The cut-off date to request a WG=
 meeting is Jun/3.  The process to have a new Charter approved and give the=
 WG participants enough time to write new drafts, start new discussions on =
the mailing list, etc., puts us back to the last week in May to have a char=
ter written up that the IESG can review.  This is where the rush comes from=
.]


Let me be clear=85  I think Mobile Ad-Hoc Networking is an important topic =
for the IETF, but the WG hasn't shown an ability to complete the work [*]. =
 Again, in this context "completing the work" is not just tied to a request=
 for publication of AODVv2 (or any specific status) =97 but, as Justin expl=
ained, to the result of the WGLC (which may result in a publication request=
 or in giving up).

Having said all that, the IETF consensus works.  It is completely up to you=
 (the WG) how you want to spend your time.  Some things that come to mind a=
re: discuss the process, discuss the AODVv2 document and try to reach conse=
nsus =97 or at least point at all the reasons it should/should not be publi=
shed (to help Justin with his decision); you could also keep working as usu=
al [*] or even decide to do nothing.  It would be very nice if this WG had =
a new charter and we could all turn to a new page before IETF 96, but clear=
ly that is not a MUST.

Alvaro.


[*] Based on my observation of the discussions on the list, the clear animo=
sity some of the participants express at each other on the list, the opinio=
ns you express of each other, and conversations I've had with several of yo=
u at the IETF, on e-mail, on the phone or while at other venues=85

[1] RFC2418: IETF Working Group Guidelines and Procedures (https://tools.ie=
tf.org/html/rfc2418)
[2] https://mailarchive.ietf.org/arch/msg/manet/3MQgdG7jg0nhKNF2Be9i_S21hx8

--_000_D33D4A55120638aretanaciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <4ECCD1CE12DFE341B9E84A82B727EBC7@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable








On 4/20/16, 1:50 PM, "manet on behalf of Justin Dean" <manet-bounces@ietf.org on behalf of
bebemaster@gmail.com> wrote:=










Hi!









=
Regardless
 we are out of time and we need to move on to other work specifically havin=
g a new charter finished and approved before the next IETF. 










Justin has mentioned several times that "we are out of time". &nb=
sp;I think it is important for me to expand on what he means (or at least w=
hat I have talked to the Chairs about).









As all of you know, AODVv2 is the last piece of work that the WG needs to c=
lear before moving on to new topics.  While the current draft was adop=
ted by the WG in 2013, the original draft (draft-ietf-manet-dymo) was first=
 published in 2005.  There have been
 ups and downs in the interest of the WG and the speed at which the authors=
 produce updates and address comments.  The WG has considered alternat=
ives and has even seen "lines in the sand" drawn and then taken o=
ver by time=85









I'm not interested in revisiting the decisions made in the past=85  Th=
e current facts are that the WG has been involved in discussions around AOD=
Vv2 for at least the last year (when I became the responsible AD) and that =
we don't seem to be significantly closer
 than we were then to moving on [*].  This situation has heavily contr=
ibuted to the WG not meeting for two IETF cycles.








It has become painfully clear to me that the WG may not b=
e able to complete the work it has been chartered with [*].
  According to rfc2418 [1], if "=85it becomes evident that a working group is unable to c=
omplete the work outlined in the charter, =85the working group can either:









   1. Recharter to refocus its =
tasks,



   2. Choose new Chair(s), or



   3. Disband."








I don't believe that at this point changing the Chairs would help [*]. &nbs=
p;I do believe that Mobile Ad-Hoc Networking is an important topic for the =
IETF to be involved in, which means that the obvious step forward is to rec=
harter.









Given the still active discussion on AODVv2, I don't think it is the right =
thing to expect it to continue (and be concluded at some point [*]) mixed i=
n with new charter items.  In other words, the WG has to clear the AOD=
Vv2 work item before moving on: (as Justin
 put it earlier) "pass it on up to the IESG or remove it as a WG item =
and hand it back to the authors to do with it what they will" [2]. &nb=
sp;As you have already noticed, the chosen path is to attempt to reach WG c=
onsensus in the next 2 weeks or give up.









There is no time limit related to how long a WG may discuss a specific topi=
c.  Besides the fact that the WG doesn't seem to be making progress [*=
], why the hurry?  IETF 96 is scheduled for the 3rd week in July. &nbs=
p;Unless the WG has a new Charter, this will be
 the 3rd meeting in a row without a manet WG session.  As I've been tr=
ying to elaborate above: there is no new Charter because the WG hasn't been=
 able to complete the current work.  Going back to the options from rf=
c2418, the next action would then be to close
 the WG.









[Slight aside:  IETF 96 starts on Jul/18.  The cut-off date to re=
quest a WG meeting is Jun/3.  The process to have a new Charter approv=
ed and give the WG participants enough time to write new drafts, start new =
discussions on the mailing list, etc., puts us
 back to the last week in May to have a charter written up that the IESG ca=
n review.  This is where the rush comes from.]















Let me be clear=85  I think Mobile Ad-Hoc Networking is an i=
mportant topic for the IETF, but the WG hasn't shown an ability to complete=
 the work [*].  Again, in this context "completing the work"=
 is not just tied to a request for publication of AODVv2 (or any
 specific status) =97 but, as Justin explained, to the result of the WGLC (=
which may result in a publication request or in giving up).









Having said all that, the IETF consensus works.  It is completely up t=
o you (the WG) how you want to spend your time.  Some things that come=
 to mind are: discuss the process, discuss the AODVv2 document and try to r=
each consensus =97 or at least point at all
 the reasons it should/should not be published (to help Justin with his dec=
ision); you could also keep working as usual [*] or even decide to do nothi=
ng.  It would be very nice if this WG had a new charter and we could a=
ll turn to a new page before IETF 96,
 but clearly that is not a MUST.









Alvaro.















[*] Based on my observation of the discussions on the list, the clear animo=
sity some of the participants express at each other on the list, the opinio=
ns you express of each other, and conversations I've had with several of yo=
u at the IETF, on e-mail, on the
 phone or while at other venues=85









[1] RFC2418: IET=
F Working Group Guidelines and Procedures (https://tools.ietf.org/html/rfc=
2418)





--_000_D33D4A55120638aretanaciscocom_--


From nobody Wed Apr 20 13:50: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 131E312E613 for ; Wed, 20 Apr 2016 13:50:24 -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 h3OPjUaOU7e3 for ; Wed, 20 Apr 2016 13:50:22 -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 BEDD812E4FB for ; Wed, 20 Apr 2016 13:50:21 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id n3so101366660wmn.0 for ; Wed, 20 Apr 2016 13:50:21 -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=4+KloFptP+ucB/DHctDrF6g8LcmLH4Is6xbSdCNjAt8=; b=b3ixvGi4DcbNyXUHgwDPIEYzdy3LY18f8gqKQe/zld1xGFaPojXSZV5Z3sgWKg9BpC yueXVLh2jzyfzK7vAHWlMPIo9dwIV+GZr9JJWxsZf0E7nSE4GJxid5HhNr2h5IBzJwb1 lgpyDkPB6Pb58TwnxUtX5g9lWzMPgeFEyFN1TPmuiz+JqXC9c9q7HTGQ/C9YuxlwYwHi qnOwRc0NGkYkdKvrdVLIctS+CT9JnRi7Ee3RJgW223i9OwaXtkgDr50FeW0OqNGm1X+6 w+BJBuRTwVFlsQvyP7+W+kzf1C1MAZ2kQ7QKlNw3l4C0fIVIas4Fy8fh7KevjRB38/6d 07pg==
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=4+KloFptP+ucB/DHctDrF6g8LcmLH4Is6xbSdCNjAt8=; b=BPBVGvGT2aKyl1LnCJCkDKUikXYD8lehY55EROMamngXG9NMeKPkHqA2vZ5FpKjKfr kuCw5TsBzX+tO5vqpAQLrwRB1CXZZTgGmxIKbsEUeXD214fB8I5hm/HG96a+EzFFp4Oy HRIx/WvmX7fOp4j6JDBnl5x47O3BlqtOK05YSGGG/06NLqJOTWrgtpYCopA0TYiT/z34 gmFWolOFkUOgJawNz1kxLdU4Ct3ERg7aMoYsgp3rNL9iZURxQ+VeIotlHFJL8ttJrtiF BJ/HUaQWZQ9A2imiWYvHI+wGXT+4YH2qoEvKbBHyPQ2gxaiIdGKIY/2/iSK4/PC+Qt3g inRA==
X-Gm-Message-State: AOPr4FVJ3BXVCYYp+pqyTm/SfJZdyFxx+ci0/u9X8aKWGPcjx87xiDPd5h/lTOqjiusSy31SRGVAm1Bz+5CB/w==
MIME-Version: 1.0
X-Received: by 10.194.6.36 with SMTP id x4mr10602244wjx.122.1461185420268; Wed, 20 Apr 2016 13:50:20 -0700 (PDT)
Sender: yi.jiazi@gmail.com
Received: by 10.194.153.166 with HTTP; Wed, 20 Apr 2016 13:50:20 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 20 Apr 2016 22:50:20 +0200
X-Google-Sender-Auth: E2HBufZgvI11IO541Oy-dtceyiE
Message-ID: 
From: Jiazi YI 
To: Justin Dean 
Content-Type: multipart/alternative; boundary=047d7b5d295ced1d460530f0bdff
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 20 Apr 2016 20:50:24 -0000

--047d7b5d295ced1d460530f0bdff
Content-Type: text/plain; charset=UTF-8

Hi Justin, all,

I'm very surprised by the WGLC at this point. At least with my limited IETF
experience, it's out of my understanding. I checked related document, and
found those text in "The Tao of IETF":

When a WG document has been fully discussed, it usually goes through
> Working Group Last Call (often abbreviated as "WGLC"). This is a
> hopefully-final time for the WG to iron out issues. Sometimes, WGLC will
> bring out so many issues that there will be a second WGLC after the
> revisions have been incorporated. There are no formal rules for how a WGLC
> happens, or even if a WGLC is needed: it is up to the WG chairs.



There is no doubt that the document is not fully discussed yet, so we are
in an *unusual* case here. Especially considering the number of significant
issues in the document, even no single comment is raised during the WGLC,
the authors need to produce new revisions to address existed tickets, and
another WGLC is needed.
So I don't really get the point of the WGLC at this point (except "running
out of time").

Anyways, I'm not against the chair's decision at this point. But I would
like my concern to be noted by the document shepherd and the WG (although
they are obvious and have been raised by others):

- There are still significant amount of technical issues to get resolved
before the WGLC.

- As a WG document, the editing process is in lack of transparency. The
authors didn't discuss the comments on the mailing list until very
recently. Most of the time, we see a new revision of the document, telling
us the comments are addressed -- some yes, but lots are not so.
Now the document became experimental and last called -- which is a big
surprise to lots of the WG participants.

- Lack of response from the author team on the comments. Because of the
lack of transparency on the discussion of the technical issues, lots of
comments remains for long time without being discussed or addressed.

- Lack of implementation and experience. I heard there was an
implementation of AODVv2 long time ago, but considering the evolution of
the document, I'm afraid it's not up-to-date? I didn't hear any paper or
document reporting the experience of AODVv2 in the field either.
Of course, considering the document is now in experimental track, this
issue is less important.

(I finished this mail before seeing Alvaro's post, which gives me more
background of the whole issue -- thanks)

A detailed review will be provided later.

best

Jiazi




On Wed, Apr 20, 2016 at 7:50 PM, Justin Dean  wrote:

> As Thomas has noted the status has changed to experimental.  You beat the
> authors to the punch in noticing that before they posted up an overview
> email.  In short, we, the working group are out of time. It's now time to
> finish this document.  Not all open issues (ones brought up today or not
> decided upon) metrics, security, and a few others have not been
> incorporated into this updated draft.  Regardless we are out of time and we
> need to move on to other work specifically having a new charter finished
> and approved before the next IETF.
>
> So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended status
> change, updates to the draft, and my review, and continued intense work
> from the editorship team and the working group there is a chance of
> success.  The working group will have 2 weeks to provide input at which
> time I'll make the call to pass it on up to the IESG or remove it as a WG
> item and hand it back to the authors to do with it what they will.
>
> Due to the short timeline we will also need to discuss and come to
> consensus on a new WG charter. I'll start that in another email thread.
>
> Justin
>
> p.s. I'm looking forward to continued positive discussions and
> improvements.  AODVv2 I STRONGLY encourage you to use (almost exclusively
> to the extent possible) the MANET list for all future AODVv2 discussions
> within this last call period.
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>

--047d7b5d295ced1d460530f0bdff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Justin, all,=C2=A0

I'=
m very surprised by the WGLC at this point. At least with my limited IETF e=
xperience, it's out of my understanding. I checked related document, an=
d found those text in "The Tao of IETF":

When a WG document has been fully discussed, it usually goes t=
hrough Working Group Last Call (often abbreviated as "WGLC"). Thi=
s is a hopefully-final time for the WG to iron out issues. Sometimes, WGLC =
will bring out so many issues that there will be a second WGLC after the re=
visions have been incorporated. There are no formal rules for how a WGLC ha=
ppens, or even if a WGLC is needed: it is up to the WG chairs.=



There is no doubt that the document is n=
ot fully discussed yet, so we are in an *unusual* case here. Especially con=
sidering the number of significant issues in the document, even no single c=
omment is raised during the WGLC, the authors need to produce new revisions=
 to address existed tickets, and another WGLC is needed.=C2=A0
So=
 I don't really get the point of the WGLC at this point (except "r=
unning out of time").=C2=A0

Anyways, I'm =
not against the chair's decision at this point. But I would like my con=
cern to be noted by the document shepherd and the WG (although they are obv=
ious and have been raised by others):

- There are =
still significant amount of technical issues to get resolved before the WGL=
C.=C2=A0

- As a WG document, the editing process i=
s in lack of transparency. The authors didn't discuss the comments on t=
he mailing list until very recently. Most of the time, we see a new revisio=
n of the document, telling us the comments are addressed -- some yes, but l=
ots are not so. =C2=A0
Now the document became experimental and l=
ast called -- which is a big surprise to lots of the WG participants.=C2=A0=


- Lack of response from the author team on the co=
mments. Because of the lack of transparency on the discussion of the techni=
cal issues, lots of comments remains for long time without being discussed =
or addressed.=C2=A0

- Lack of implementation and e=
xperience. I heard there was an implementation of AODVv2 long time ago, but=
 considering the evolution of the document, I'm afraid it's not up-=
to-date? I didn't hear any paper or document reporting the experience o=
f AODVv2 in the field either.=C2=A0
Of course, considering the do=
cument is now in experimental track, this issue is less important.=C2=A0

(I finished this mail before seeing Alvaro's pos=
t, which gives me more background of the whole issue -- thanks)
<=
br>
A detailed review will be provided later.=C2=A0
best

Jiazi




On We=
d, Apr 20, 2016 at 7:50 PM, Justin Dean <bebemaster@gmail.com> wrote:
As Thomas has noted the status has changed to experimental.=C2=A0 You bea=
t the authors to the punch in noticing that before they posted up an overvi=
ew email.=C2=A0 In short, we, the working group are out of time. It's n=
ow time to finish this document.=C2=A0 Not all open issues (ones brought up=
 today or not decided upon) metrics, security, and a few others have not be=
en incorporated into this updated draft.=C2=A0 Regardless we are out of tim=
e and we need to move on to other work specifically having a new charter fi=
nished and approved before the next IETF. 

So, I'll be issuing a=
 2 week WGLC on AODVv2.=C2=A0 Given the intended status change, updates to =
the draft, and my review, and continued intense work from the editorship te=
am and the working group there is a chance of success.=C2=A0 The working gr=
oup will have 2 weeks to provide input at which time I'll make the call=
 to pass it on up to the IESG or remove it as a WG item and hand it back to=
 the authors to do with it what they will.

Due to the short timeline=
 we will also need to discuss and come to consensus on a new WG charter. I&=
#39;ll start that in another email thread.
Justin

p.s. I'm looking forward to continued =
positive discussions and improvements.=C2=A0 AODVv2 I STRONGLY encourage yo=
u to use (almost exclusively to the extent possible) the MANET list for all=
 future AODVv2 discussions within this last call period.


_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet





--047d7b5d295ced1d460530f0bdff--


From nobody Wed Apr 20 15:00: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 00BC212DD49 for ; Wed, 20 Apr 2016 15:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=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 cC71rzQDYGJH for ; Wed, 20 Apr 2016 15:00:26 -0700 (PDT)
Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 79AB312DB00 for ; Wed, 20 Apr 2016 15:00:23 -0700 (PDT)
Received: by mail-wm0-x243.google.com with SMTP id e201so13665216wme.2 for ; Wed, 20 Apr 2016 15:00:23 -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=CpXUhl8uREk4z2Pgx2B1RqcDJ/BPgQUIGFYOfbDkZDA=; b=V2TU5DOOMTclIfM56gUMpAxtQEWedFF9EdSEcDs2qx5js+MRP4c2HaVj0eUKvAq/RO 8GVviWeTzIIb3rJyi69PqjsPw4xf4cQty3E1/j8QwT4HZDBdbyLMfANn2kVpPdG+RFX/ QV7VvoaiyUSstKHiYFBcFFs28vGQDpuVPy+Kewq8dF0YUO/OHsqs+UiqEYbLqp9GTx1Q YM/vYAuB64rRlHHi6FSafQCWAqKhH+iX6K6Kgr//LItmfOCGPn5ptTnK3mF9seKiumo8 R9aK5viZzcRuaK9yeuGitr9VTcVWDW7YD5AZqHEK7krCrteKcBg7V8Ypy7qwxIKphSL0 Tvqw==
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=CpXUhl8uREk4z2Pgx2B1RqcDJ/BPgQUIGFYOfbDkZDA=; b=YUPl1/PzHDEMsj6qerzlazTGmAzbKOkFLFvtGEk/8E7ZMDGDcvpDWcE/jvYEAO/SMq 58kxUUpCBuG8EI2yZje7W6sEOE5O3W9zwRCbQElTO669rsKlN4ox3XUeJIICjb90Ou1H Dm4IO3CsMKcYITn6L1ieOiPlywOSYV5dM8B3tc66livAZ/46ebW0aUz8gfJZQDQf/eud YhWpx0IYh2VUSLAi9raViIAJT2QeTHNCHaBNoex3hMw/chE7FG3buSuF7Nf29kyV9MOP NzmTT1sGQ6DXrSAkqTad+aNMYe8r5vvD31Oe5yxQyQMbXQiecMXmr78LnYtwdKwhG2k8 H7Aw==
X-Gm-Message-State: AOPr4FVzO4oP5q/dIEIZajvQ1FtllOEhiPM0ecEjNBFZJbV0qHJURz/R0plBfYdDITmGAw==
X-Received: by 10.194.100.129 with SMTP id ey1mr3049012wjb.26.1461189622002; Wed, 20 Apr 2016 15:00:22 -0700 (PDT)
Received: from johns-mbp-4.home (host86-157-43-97.range86-157.btcentralplus.com. [86.157.43.97]) by smtp.gmail.com with ESMTPSA id s10sm7641250wjp.3.2016.04.20.15.00.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Apr 2016 15:00:21 -0700 (PDT)
From: John Dowdell 
Content-Type: multipart/alternative; boundary="Apple-Mail=_D0385980-5812-4C34-9E55-520777504B70"
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Date: Wed, 20 Apr 2016 23:00:21 +0100
References:  
To: Justin Dean , "manet@ietf.org" 
In-Reply-To: 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [manet] New AODVv2 draft and status
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, 20 Apr 2016 22:00:28 -0000

--Apple-Mail=_D0385980-5812-4C34-9E55-520777504B70
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi AD, co-chairs and all

Speaking as  a co-author of this document, I have to say I am very =
surprised at the sudden WGLC and labelling as Experimental, not least =
because the first I heard of it was when it was announced on the list =
earlier today. That is not to say that I did not know something like =
this would happen one day, but to come as a fait accompli with such a =
guillotine is a considerable shock. I have read on- and off-list emails =
on this topic this evening and can understand the reasons, but this to =
me is not consensus politics. I agree that those in charge have to make =
decisions, but I disagree that they should be made in isolation from the =
author team and the WG. The WG has not met face to face for two meetings =
so these issues have not been discussed in the normal way, although I am =
pleased that informal meetings have taken place instead.

I was asked to join the three-man author team for AODVv2 following the =
Paris IETF in 2012 that I=E2=80=99m sure many on this list will =
remember. We worked hard, but by the Honolulu meeting in late 2014 it =
was clear we needed additional authors who were used to working at a =
high level of detail. Enter Lotte and Vicky who have provided stellar =
contributions and have way exceeded even my best hopes for making =
progress on this document. Let me also say that all of the authors have =
given significant amounts of their own time to make this document what =
it is today.

As I understand it, it seems likely that this document will now be =
consigned to the dustbin of history, since, despite huge progress having =
been made from what we were handed in 2012, there will be no consensus =
on what to do next. That to me says that this WG holds no value to the =
work that has been carried out, that it is of no worth. As has been =
pointed out elsewhere, this is a large document, although shorter and =
far easier to understand than it used to be, and it takes time to =
review. For the review to be demanded in 2 weeks, especially with the =
5444 usage draft WGLC going on at the same time, it is a tall order.

I would respectfully ask that this decision be reconsidered.

John


> On 20 Apr 2016, at 21:50, Jiazi YI  wrote:
>=20
> Hi Justin, all,=20
>=20
> I'm very surprised by the WGLC at this point. At least with my limited =
IETF experience, it's out of my understanding. I checked related =
document, and found those text in "The Tao of IETF":
>=20
> When a WG document has been fully discussed, it usually goes through =
Working Group Last Call (often abbreviated as "WGLC"). This is a =
hopefully-final time for the WG to iron out issues. Sometimes, WGLC will =
bring out so many issues that there will be a second WGLC after the =
revisions have been incorporated. There are no formal rules for how a =
WGLC happens, or even if a WGLC is needed: it is up to the WG chairs.
>=20
>=20
> There is no doubt that the document is not fully discussed yet, so we =
are in an *unusual* case here. Especially considering the number of =
significant issues in the document, even no single comment is raised =
during the WGLC, the authors need to produce new revisions to address =
existed tickets, and another WGLC is needed.=20
> So I don't really get the point of the WGLC at this point (except =
"running out of time").=20
>=20
> Anyways, I'm not against the chair's decision at this point. But I =
would like my concern to be noted by the document shepherd and the WG =
(although they are obvious and have been raised by others):
>=20
> - There are still significant amount of technical issues to get =
resolved before the WGLC.=20
>=20
> - As a WG document, the editing process is in lack of transparency. =
The authors didn't discuss the comments on the mailing list until very =
recently. Most of the time, we see a new revision of the document, =
telling us the comments are addressed -- some yes, but lots are not so. =20=

> Now the document became experimental and last called -- which is a big =
surprise to lots of the WG participants.=20
>=20
> - Lack of response from the author team on the comments. Because of =
the lack of transparency on the discussion of the technical issues, lots =
of comments remains for long time without being discussed or addressed.=20=

>=20
> - Lack of implementation and experience. I heard there was an =
implementation of AODVv2 long time ago, but considering the evolution of =
the document, I'm afraid it's not up-to-date? I didn't hear any paper or =
document reporting the experience of AODVv2 in the field either.=20
> Of course, considering the document is now in experimental track, this =
issue is less important.=20
>=20
> (I finished this mail before seeing Alvaro's post, which gives me more =
background of the whole issue -- thanks)
>=20
> A detailed review will be provided later.=20
>=20
> best
>=20
> Jiazi
>=20
>=20
>=20
>=20
> On Wed, Apr 20, 2016 at 7:50 PM, Justin Dean > wrote:
> As Thomas has noted the status has changed to experimental.  You beat =
the authors to the punch in noticing that before they posted up an =
overview email.  In short, we, the working group are out of time. It's =
now time to finish this document.  Not all open issues (ones brought up =
today or not decided upon) metrics, security, and a few others have not =
been incorporated into this updated draft.  Regardless we are out of =
time and we need to move on to other work specifically having a new =
charter finished and approved before the next IETF.=20
>=20
> So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended =
status change, updates to the draft, and my review, and continued =
intense work from the editorship team and the working group there is a =
chance of success.  The working group will have 2 weeks to provide input =
at which time I'll make the call to pass it on up to the IESG or remove =
it as a WG item and hand it back to the authors to do with it what they =
will.
>=20
> Due to the short timeline we will also need to discuss and come to =
consensus on a new WG charter. I'll start that in another email thread.
>=20
> Justin
>=20
> p.s. I'm looking forward to continued positive discussions and =
improvements.  AODVv2 I STRONGLY encourage you to use (almost =
exclusively to the extent possible) the MANET list for all future AODVv2 =
discussions within this last call period.
>=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


--Apple-Mail=_D0385980-5812-4C34-9E55-520777504B70
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Hi AD, co-chairs and all

Speaking as  a =
co-author of this document, I have to say I am very surprised at the =
sudden WGLC and labelling as Experimental, not least because the first I =
heard of it was when it was announced on the list earlier today. That is =
not to say that I did not know something like this would happen one day, =
but to come as a fait accompli with such a guillotine is a considerable =
shock. I have read on- and off-list emails on this topic this evening =
and can understand the reasons, but this to me is not consensus =
politics. I agree that those in charge have to make decisions, but I =
disagree that they should be made in isolation from the author team and =
the WG. The WG has not met face to face for two meetings so these issues =
have not been discussed in the normal way, although I am pleased that =
informal meetings have taken place instead.

I was asked to join the three-man =
author team for AODVv2 following the Paris IETF in 2012 that I=E2=80=99m =
sure many on this list will remember. We worked hard, but by the =
Honolulu meeting in late 2014 it was clear we needed additional authors =
who were used to working at a high level of detail. Enter Lotte and =
Vicky who have provided stellar contributions and have way exceeded even =
my best hopes for making progress on this document. Let me also say that =
all of the authors have given significant amounts of their own time to =
make this document what it is today.

As I understand it, it seems likely =
that this document will now be consigned to the dustbin of history, =
since, despite huge progress having been made from what we were handed =
in 2012, there will be no consensus on what to do next. That to me says =
that this WG holds no value to the work that has been carried out, that =
it is of no worth. As has been pointed out elsewhere, this is a large =
document, although shorter and far easier to understand than it used to =
be, and it takes time to review. For the review to be demanded in 2 =
weeks, especially with the 5444 usage draft WGLC going on at the same =
time, it is a tall order.

I would respectfully ask that this decision be =
reconsidered.

John


On =
20 Apr 2016, at 21:50, Jiazi YI <ietf@jiaziyi.com> wrote:

Hi Justin, all, 

I'm very surprised by the WGLC at this =
point. At least with my limited IETF experience, it's out of my =
understanding. I checked related document, and found those text in "The =
Tao of IETF":

When a WG document has been fully =
discussed, it usually goes through Working Group Last Call (often =
abbreviated as "WGLC"). This is a hopefully-final time for the WG to =
iron out issues. Sometimes, WGLC will bring out so many issues that =
there will be a second WGLC after the revisions have been incorporated. =
There are no formal rules for how a WGLC happens, or even if a WGLC is =
needed: it is up to the WG chairs.


There is no doubt that the document is not fully discussed =
yet, so we are in an *unusual* case here. Especially considering the =
number of significant issues in the document, even no single comment is =
raised during the WGLC, the authors need to produce new revisions to =
address existed tickets, and another WGLC is needed. 
So I don't really get the point of the WGLC at this point =
(except "running out of time"). 

Anyways, I'm not against the chair's =
decision at this point. But I would like my concern to be noted by the =
document shepherd and the WG (although they are obvious and have been =
raised by others):

- There are still significant amount of technical issues to =
get resolved before the WGLC. 

- As a WG document, the editing process =
is in lack of transparency. The authors didn't discuss the comments on =
the mailing list until very recently. Most of the time, we see a new =
revision of the document, telling us the comments are addressed -- some =
yes, but lots are not so.  
Now the document =
became experimental and last called -- which is a big surprise to lots =
of the WG participants. 

- Lack of response from the author team =
on the comments. Because of the lack of transparency on the discussion =
of the technical issues, lots of comments remains for long time without =
being discussed or addressed. 

- Lack of implementation and =
experience. I heard there was an implementation of AODVv2 long time ago, =
but considering the evolution of the document, I'm afraid it's not =
up-to-date? I didn't hear any paper or document reporting the experience =
of AODVv2 in the field either. 
Of course, =
considering the document is now in experimental track, this issue is =
less important. 

(I finished this mail before seeing Alvaro's post, which =
gives me more background of the whole issue -- thanks)

A detailed review will =
be provided later. 

best

Jiazi




On Wed, =
Apr 20, 2016 at 7:50 PM, Justin Dean <bebemaster@gmail.com> wrote:
As Thomas has noted the status has changed to =
experimental.  You beat the authors to the punch in noticing that =
before they posted up an overview email.  In short, we, the working =
group are out of time. It's now time to finish this document.  Not =
all open issues (ones brought up today or not decided upon) metrics, =
security, and a few others have not been incorporated into this updated =
draft.  Regardless we are out of time and we need to move on to =
other work specifically having a new charter finished and approved =
before the next IETF. 

So, I'll be issuing =
a 2 week WGLC on AODVv2.  Given the intended status change, updates =
to the draft, and my review, and continued intense work from the =
editorship team and the working group there is a chance of =
success.  The working group will have 2 weeks to provide input at =
which time I'll make the call to pass it on up to the IESG or remove it =
as a WG item and hand it back to the authors to do with it what they =
will.

Due to the short timeline we will =
also need to discuss and come to consensus on a new WG charter. I'll =
start that in another email thread.

Justin

p.s. I'm looking forward to =
continued positive discussions and improvements.  AODVv2 I STRONGLY =
encourage you to use (almost exclusively to the extent possible) the =
MANET list for all future AODVv2 discussions within this last call =
period.


_______________________________________________

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=_D0385980-5812-4C34-9E55-520777504B70--


From nobody Wed Apr 20 17:42: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 0CB0412DA9C for ; Wed, 20 Apr 2016 17:42:40 -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 nmKqpqS9T8ql for ; Wed, 20 Apr 2016 17:42:37 -0700 (PDT)
Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 1744012D79F for ; Wed, 20 Apr 2016 17:42:32 -0700 (PDT)
Received: by mail-qg0-x22e.google.com with SMTP id d90so8771201qgd.3 for ; Wed, 20 Apr 2016 17:42: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=q9ESRdRriUSH7HPhR0O6JG3EPdZ8SdAfof1tq3cE1mY=; b=QaDqeGO0f/XhaqGXoXad/NjdVwnOFQ5F7XQ6Z1zyw1QoWphMwtoTaTNGiI8o6Y/AcI Hszjg/MJyQD8AWLFDCvJ4a82ZA3/vWjP4gelqhBfXapOTiTC7uRTlKoS3WC49Ub68fvY 2KxQRa36UK/ZvSPqxH8qnz3TCqhdqVnnW4Q12N/0cNv+HCZ2LL2XcitzvT3TF8EuMnqV v1uFqV3UK0u2Eyv21FLdeGcKWMw8Dzl20FJHaqGzg0o2nxU92dImithGYMOVI2sjkpxX 4G8p3rJUX+m0b9T5W4Ub5PerzQs0LBtGtsOmYEqApCkC09YT7Pf6JXNr9TE4KCnMzK6m LX8w==
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=q9ESRdRriUSH7HPhR0O6JG3EPdZ8SdAfof1tq3cE1mY=; b=iQ8d5eMakFXFu0LCm05nGfxr2v0KpJc4lRo5VZJv8k+RwdU14VYBGpabBt+lRN50jp jf2Pq2vvpmtAkXjliZgpBieLLtj8vucGvFMbRz8ZMZPmMBv0UQRpyjfpl7zP2G4ZCRn4 ILSFt0vP/gEzjoqiGDhu7QGKC3uAN2K3x6oPMM7EWRaEGJPleDgZ3OqEOHxlkjkTkvsb VPp61EPdU4Y6mIWLkmzY2VITcQHzHt2Rr4VAkSyNwzmlI2nmkF9rByhPsR047l/6WuNO DN5rxXV9fl845nQX/+dTOS4BBve8RpYK481gJV+j5fPli71GjxhZ5WXxSdp3+TJLfvCY 1Y/A==
X-Gm-Message-State: AOPr4FV928boxIgVLyz4Ts6Yc4D6goRwmiUfGBPyA+En0LzXdQVgwCOP+sEBcVMZ46UMFA3iw7lpBph8DVtXvA==
MIME-Version: 1.0
X-Received: by 10.140.35.115 with SMTP id m106mr14296071qgm.13.1461199351240;  Wed, 20 Apr 2016 17:42:31 -0700 (PDT)
Received: by 10.140.43.131 with HTTP; Wed, 20 Apr 2016 17:42:31 -0700 (PDT)
In-Reply-To: 
References:  
Date: Thu, 21 Apr 2016 02:42:31 +0200
Message-ID: 
From: Abdussalam Baryun 
To: Jiazi YI 
Content-Type: multipart/alternative; boundary=001a11c038e046e22d0530f3fcf3
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 21 Apr 2016 00:42:40 -0000

--001a11c038e046e22d0530f3fcf3
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 20, 2016 at 10:50 PM, Jiazi YI  wrote:

> [....]
> - As a WG document, the editing process is in lack of transparency. The
> authors didn't discuss the comments on the mailing list until very
> recently. Most of the time, we see a new revision of the document, telling
> us the comments are addressed -- some yes, but lots are not so.
> Now the document became experimental and last called -- which is a big
> surprise to lots of the WG participants.
>
> - Lack of response from the author team on the comments. Because of the
> lack of transparency on the discussion of the technical issues, lots of
> comments remains for long time without being discussed or addressed.
>
>
I don't agree with you. I know that the WG is responsible to react quickly
of what it adopted, even participants MUST edit the draft by mentioning
clearly what they want to see written exactly in words. Comments should be
addressed by the WG to make it into words in the draft, so the commenters
needs to edit and help writing. If you disagree please point me to the IETF
procedure that authors are alone responsible for addressing all comments
into words. IMO, this authors team do respond and they edit for  WG. I
think we all need to take the responsibility for the WG situation, we also
as WG may need to have a nice meal together in next IETF.

AB

--001a11c038e046e22d0530f3fcf3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Apr 20, 2016 at 10:50 PM, Jiazi YI <ietf@jiaziyi.com> wrote:
[....]
- As a WG document, the editing process is in lack of transparency. The =
authors didn't discuss the comments on the mailing list until very rece=
ntly. Most of the time, we see a new revision of the document, telling us t=
he comments are addressed -- some yes, but lots are not so. =C2=A0
Now the document became experimental and last called -- which is a big su=
rprise to lots of the WG participants.=C2=A0

- Lac=
k of response from the author team on the comments. Because of the lack of =
transparency on the discussion of the technical issues, lots of comments re=
mains for long time without being discussed or addressed.=C2=A0
<=
br>

I don't agree with you.=
 I know that the WG is responsible to react quickly of what it adopted, eve=
n participants MUST edit the draft by mentioning clearly what they want to =
see written exactly in words. Comments should be addressed by the WG to mak=
e it into words in the draft, so the commenters needs to edit and help writ=
ing. If you disagree please point me to the IETF procedure that authors are=
 alone responsible for addressing all comments into words. IMO, this author=
s team do respond and they edit for=C2=A0 WG. I think we all need to take t=
he responsibility for the WG situation, we also as WG may need to have a ni=
ce meal together in next IETF. 

AB 

=C2=
=A0


--001a11c038e046e22d0530f3fcf3--


From nobody Thu Apr 21 02:00:51 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 C4C5612DDDF for ; Thu, 21 Apr 2016 02:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.609
X-Spam-Level: 
X-Spam-Status: No, score=-6.609 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, TRACKER_ID=1.306] 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 Fzh8vsbum0fB for ; Thu, 21 Apr 2016 02:00:43 -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 F371D12DB74 for ; Thu, 21 Apr 2016 02:00:33 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,512,1454976000"; d="scan'208,217"; a="62862701"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 21 Apr 2016 10:00:28 +0100
X-IronPort-AV: E=Sophos;i="5.24,512,1454976000";  d="scan'208,217";a="114913304"
Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 21 Apr 2016 09:59:35 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Thu, 21 Apr 2016 09:59:35 +0100
From: "Dearlove, Christopher (UK)" 
To: "ietf@thomasclausen.org" 
Thread-Topic: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
Thread-Index: AQHRmuq4sr6y+au39kGswdQyX9PrDp+SpNaAgABRmICAASuecA==
Date: Thu, 21 Apr 2016 08:59:34 +0000
Message-ID: 
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org>  <05889ADB-283D-4D52-A357-6BB3FB415926@thomasclausen.org>
In-Reply-To: <05889ADB-283D-4D52-A357-6BB3FB415926@thomasclausen.org>
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B00C7GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 21 Apr 2016 09:00:48 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B00C7GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SeKAmW0gcmVhZGluZyB0aGlzIGluIE91dGxvb2suIChPciByYXRoZXIgaW4gYSBtaXh0dXJlIG9m
IE91dGxvb2sgYW5kIG9uIG15IHBob25lLiBCdXQgdGhpcyBvbmUgaW4gT3V0bG9vay4pIEFuZCBp
biBPdXRsb29rLCBxdWl0ZSBicm9rZW4gd2l0aCBubyBpbmZvcm1hdGlvbiBvbiB3aG8gc2FpZCB3
aGF0Lg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5l
ZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hyaXMuZGVhcmxv
dmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0K
DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5
IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVz
eXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMg
QXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2Fs
ZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmss
IEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IGlldGZAdGhvbWFzY2xhdXNlbi5v
cmcgW21haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3JnXQ0KU2VudDogMjAgQXByaWwgMjAxNiAx
NzowNg0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpDYzogTG90dGUgU3RlZW5icmlu
azsgTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3QNClN1YmplY3Q6IFJlOiBbbWFu
ZXRdIE9uIEZvcndhcmRpbmctYW5kLXJlZ2VuZXJhdGlvbiAod2FzOiBSZTogZHJhZnQtaWV0Zi1t
YW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcykNCg0K
DQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBv
dXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBp
bnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24g
YW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlv
biByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxz
IHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5j
b20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBk
Zj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0
aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsv
c2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3Vz
JTIwRW1haWxzLnBkZj4uDQpDaHJpcywgYWxsLA0KDQpPbiBBcHIgMjAsIDIwMTYsIGF0IDEyOjMw
LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j
b208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQoNCkNhbiBJ
IGp1c3Qgc2F5IGl04oCZcyBxdWl0ZSBoYXJkIHRvIHdvcmsgb3V0IHdobyBpcyBzYXlpbmcgd2hh
dCBpbiB0aGVzZSBleGNoYW5nZXMuIEnigJltIGhhdmluZyB0byBndWVzcyBzb21lIG9uIHRoZSBi
YXNpcyBvZiDigJx0aGF0IHNvdW5kcyBsaWtlIFRob21hc+KAnSBvciDigJx0aGF0IHNvdW5kcyBs
aWtlIExvdHRl4oCdLg0KDQpJIHRoaW5rIHRoYXQgeW91ciBNVUEgaXMgc2xpZ2h0bHkgYnJva2Vu
LCB0aGVuLCBidXQgd2hlbiBJIGhhdmUgZG91YnRzIEkgaGl0IHRoZSBhcmNoaXZlcywgd2hpY2gg
Y29ycmVjdGx5IHNob3dzIHdobyBzYXlzIHdoYXQg4oCUIGhlcmXigJlzIHRoZSBhcmNoaXZlIGZv
ciB0aGUgbWVzc2FnZSBpbiBxdWVzdGlvbjoNCg0KICAgICAgICAgICAgaHR0cDovL21haWxhcmNo
aXZlLmlldGYub3JnL2FyY2gvbXNnL21hbmV0L01DeFdmMHRMYzlRN0l4X1hXXzBsQVB5SElkYzxo
dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL21hbmV0L01DeFdmMHRMYzlRN0l4
X1hXXzBsQVB5SElkYz4NCg0KDQoNCg0KV2hhdCBJ4oCZbSBub3QgY2xlYXIgb24gaXMgd2hhdCBj
b25jbHVzaW9uLCBpZiBhbnksIHlvdeKAmXZlIGRyYXduIG9uIGhvcCBjb3VudC9saW1pdC4NCg0K
QXMgSSBzZWUgaXQsIGlmIHRoZSBwcm90b2NvbCByZWNlaXZlcyBhIG1lc3NhZ2UgdGhlbiBzZW5k
cyBhIG1lc3NhZ2Ugc2ltaWxhciBidXQgbm90IGlkZW50aWNhbCB0byB0aGF0IG91dCwgdGhhdCBj
YW4gYmUgcmV2aWV3ZWQgYXMgY3JlYXRpbmcgYSBuZXcgbWVzc2FnZS4gSXQgaXMgYSBuZXcgbWVz
c2FnZSBhcyBmYXIgYXMgNzE4MiBpcyBjb25jZXJuZWQuDQoNCkhlbmNlIHdoeSBJIHdyb3RlIChv
ciwgSSB0aGluayBJIHdyb3RlKSA3MTgyLWRlcml2ZWQgVExWLg0KDQoNCg0KQnV0IHRoZSBwcm90
b2NvbCBjb3VsZCBpbXBvc2Ugc29tZSByZXN0cmljdGlvbnMuIEZvciBleGFtcGxlIOKAnHRoZSBv
bmx5IHRoaW5nIGFsbG93ZWQgdG8gYmUgY2hhbmdlZCBpcyB0aGlzIGZpZWxkIGluIHRoaXMgVExW
4oCdLiBXaGljaCBpdCB3b3VsZCB0aGVyZWZvcmUgYmUgYSBnb29kIGlkZWEgZm9yIHRoZSBjcmVh
dG9yIG9mIHRoZSBtZXNzYWdlIHRvIGluY2x1ZGUsIGV2ZW4gaWYgaXQgdGh1cyBuZWVkZWQgdG8g
aW5jbHVkZSBhIGxpbmsgbWV0cmljIG9mIHplcm8uIChXaGljaCBpcyBhIGRlc2lnbiBwb2ludCAt
IHlvdSBtaWdodCBuZWVkIHRvIGFsbG93IHRoYXQgaW4gbWV0cmljIHNwZWNpZmljYXRpb24uKSBC
dXQgeW91IHdvdWxkIG5lZWQgdG8gc3RhdGUgdGhhdC4gVGhhdCBlbmFibGVzIHNvbWUgZnV0dXJl
IGRlc2lnbnMgLSBub3QgNzE4MiwgcG9zc2libHkgYW4gZXh0ZW5zaW9uIHRvIDcxODIsIHBvc3Np
Ymx5IHNvbWV0aGluZyBuZXcuDQoNCllFUywgdGhhdOKAmXMgbXkgcG9pbnQuDQoNCg0KVGhlcmUg
aXMgYSBwcm9ibGVtIHRoYXQgdGhpcyBpZGVhIHdvdWxkIGJlIHB1dHRpbmcgaW4gYSBuZWVkIHRv
IHVuZGVyc3RhbmQgc3BlY2lmaWMgVExWcywgd2hpY2ggaXMgdW5kZXNpcmFibGUuIEkgaGF2ZSBz
b21lIGlkZWFzIHRoZXJlLCBzdWNoIGFzIHVzaW5nIHRoZSBwcm90b2NvbC1zcGVjaWZpYyBzcGFj
ZSwgYnV0IHRoaXMgaXNu4oCZdCBhIGZpdmUgbWludXRlIGpvYiwgYW5kIG5lZWRzIHRvIGJlIGdv
dCByaWdodC4gV2hpbGUgbm93IGlzIG5vdCB0aGUgdGltZSB0byBkZWZpbmUgdGhpcywgc29tZSBk
ZWNpc2lvbnMgY291bGQgcmVhbGx5IGltcGFjdCBvbiBmdXR1cmUgZGVzaWducy4gRm9yIGV4YW1w
bGUgcHV0dGluZyBhbnl0aGluZyB3YW50aW5nIHRvIGJlIG11dGFibGUgc3R1Y2sgaW4gdGhlIG1p
ZGRsZSBvZiBhbGwgdGhlIG90aGVyIFRMVnMgd291bGQgYmUgY29uc3RyYWluaW5nLiBNYWtpbmcg
YWxsIGludGVuZGVkIHRvIGJlIG11dGFibGUgYnkgdGhpcyBwcm90b2NvbCBUTFZzIGluIHRoZSBw
cm90b2NvbCBzcGVjaWZpYyBzcGFjZSBpcyBwcm9iYWJseSB0aGUgbGVhc3QgYmFkIGlkZWEsIGFz
IHRoYXQgY291bGQgYmUgZ2VuZXJhbGlzZWQgKGVpdGhlciBtYWtpbmcgdGhhdCBzcGFjZSBub3Qg
Y292ZXJlZCBieSB0aGlzIGh5cG90aGV0aWNhbCA3MTgyIHZhcmlhbnQsIG9yIHNwbGl0dGluZyBp
dCkuDQoNCk15IHBvc2l0aW9uIG9uIHRoYXQgd291bGQgYmUg4oCcbmV2ZXIgY2hhbmdlIHRoZSBz
dHJ1Y3R1cmUgb2YgdGhlIG1lc3NhZ2UgaW4gdHJhbnNpdOKAnSBhbmQg4oCcbmV2ZXIgY2hhbmdl
IHRoZSBsZW5ndGggb24gYSBUTFYgaW4gdHJhbnNpdOKAnSwgYW5kIHlvdeKAmWQgaGF2ZSBkb25l
IGEgZmFpcmx5IGdvb2Qgam9iIG9mIG1ha2luZyBpdCBwb3NzaWJsZSB0byBkbyAqc29tZXRoaW5n
KiBjbGV2ZXIgZm9yIElDVnM6IHRoZSBtdXRhdGluZyBmaWVsZCwgd2hpY2ggd291bGQgYmUgaW4g
YSBmaXhlZCBwb3NpdGlvbiBpbiB0aGUgYnl0ZSBzdHJlYW0sIHlvdSBjb3VsZCB6ZXJvIHRoYXQg
b3V0LCBvciBkbyBzb21ldGhpbmcgZWxzZS4gNzE4MiBkb2VzIG5vdCBkbyB0aGF0LiBCdXQgc29t
ZXRoaW5nIGVsc2UgbWlnaHQuDQoNCk5vdCBoYXZpbmcgdGhhdCBjb25zdHJhaW50IG1lYW5zIHRo
YXQg4oCcc29tZXRoaW5nIGVsc2XigJ0gd291bGQgYmUgaW1wb3NzaWJsZSwgd291bGQgaW1wZWRl
IG9uIGV4dGVuc2liaWxpdHkuDQoNCg0KDQpUaGF0IGxlYXZlcyBob3AgY291bnQvbGltaXQuIFRl
Y2huaWNhbGx5IHlvdSB3b3VsZG7igJl0IGluY3JlbWVudC9kZWNyZW1lbnQsIGFzIGl04oCZcyBh
IG5ldyBtZXNzYWdlLiBCdXQgeW91IGNhbiBzZW5kIGFueSBob3AgbGltaXQgb24gYW55IG5ldyBt
ZXNzYWdlLCBzbyB0aGF0IGNvdWxkIGJlIG9uZSBsZXNzIHRoYW4gdGhlIG9uZSB5b3UgcmVjZWl2
ZWQuIEhvcCBjb3VudCBpcyBhIGJpdCBtb3JlIGFyZ3VhYmxlLiBJ4oCZbSBub3Qgc3VyZSBob3cg
Y2xlYXJseSBpdHMgbWVhbmluZyBpcyBpbmRpY2F0ZWQsIHdoZXRoZXIgaXQgaXMgYSDigJxyZWFs
4oCdIGhvcCBjb3VudCBvZiB0aGlzIG1lc3NhZ2UuIEJ1dCBpZiB5b3UgbmVlZGVkIHRvIEkgd291
bGRu4oCZdCBiZSB0b28gc3Ryb25nbHkgYWdhaW5zdCBkb2luZyB3aGF0IGxvb2tzIGxpa2UgaW5j
cmVtZW50aW5nIHRoYXQsIGFzIGxvbmcgYXMgY2FyZWZ1bGx5IGV4cGxhaW5lZC4NCg0KWWVzLCBJ
IGFncmVlIHRoYXQgdGhhdCBjYW4gYmUgYXJndWFibGUuDQoNCkFnYWluLCBoZXJlIG15IHBvc2l0
aW9uIGlzOiBpZiB5b3UgY2hhbmdlIHRoZSBzbGlnaHRlc3QgaW4gdGhlICpzdHJ1Y3R1cmUqIG9m
IHRoZSBtZXNzYWdlLCB0aGVuIGEgaG9wLWNvdW50IGluY3JlbWVudCB3b3VsZCBiZSBpbnZhbGlk
IChpbGxlZ2FsPyA7KSApDQoNCldoaWNoIGlzIHRvIHNheTogcmVnZW5lcmF0aW9uID0+IGRvbuKA
mXQgdXNlIGhvcC1jb3VudC9ob3AtbGltaXQgKGluIG15IG9waW5pb24pLg0KDQoNCihBIGtleSBx
dWVzdGlvbiBpcyBpZiB5b3UgdXNlIDU0OTcgVExWcy4gSW4gdGhhdCBjYXNlIEkgdGhpbmsgLSBj
b21iaW5lZCB3aXRoIHRoZSDigJxvbmx5IGNoYW5nZSBvbmUgdGhpbmcgYWJvdmXigJ0gdGhhdCB5
b3UgbmVlZCB0byBhcHBlYXIgdG8gaW5jcmVtZW50IGhvcCBsaW1pdCwgaS5lLiBjcmVhdGUgYSBu
ZXcgbWVzc2FnZSB3aXRoIGEgbm9uLXplcm8gaG9wIGNvdW50Lg0KDQpJbmRlZWQsIGdvb2QgY2F0
Y2guIFRoaXMgZG9jdW1lbnQgZG9lcywgaW5kZWVkLCBjaXRlIFJGQzU0OTcgbm9ybWF0aXZlbHku
IEnigJlkIG5vdCBzZWVuIHRoYXQgaW50ZXJhY3Rpb24sIGJ1dCB5b3UgYXJlIHJpZ2h0IGl0IGhh
cyB0byBiZSBtYXRjaGVkIHVwLiBJ4oCZdmUgbm90IGNoZWNrZWQgdGhhdC9pZiBpdCBpcy4NCg0K
QmVzdCwNCg0KVGhvbWFzDQoNCg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQ
cmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9y
YXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAg
RTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh
ZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1z
Zm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00y
IDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2Fp
Pg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBp
biBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5
IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IG1hbmV0
IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRob21hcyBDbGF1
c2VuDQpTZW50OiAyMCBBcHJpbCAyMDE2IDEwOjU1DQpUbzogTG90dGUgU3RlZW5icmluaw0KQ2M6
IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0DQpTdWJqZWN0OiBbbWFuZXRdIE9u
IEZvcndhcmRpbmctYW5kLXJlZ2VuZXJhdGlvbiAod2FzOiBSZTogZHJhZnQtaWV0Zi1tYW5ldC1h
b2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcykNCg0KDQoqKiog
V0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3Jn
YW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5l
dC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxp
bmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdh
cmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSBy
ZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93
d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJ
ZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHBy
b2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJp
dHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1h
aWxzLnBkZj4uDQoqKiogV0FSTklORyAqKioNCkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2Fn
ZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uLg0KDQpMb3R0ZSwgYWxs
LA0KDQpPbiAxOSBNYXIgMjAxNiwgYXQgMTI6MzQsIExvdHRlIFN0ZWVuYnJpbmsgPGxvdHRlLnN0
ZWVuYnJpbmtAZnUtYmVybGluLmRlPG1haWx0bzpsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5k
ZT4+IHdyb3RlOg0KSGkgVGhvbWFzLA0KdGhhbmsgeW91IGZvciByZXZpZXdpbmcgQU9EVnYyIHll
dCBhZ2FpbiA6KSBTb21lIGFuc3dlcnMgYmVsb3c6DQoNCkFtIDE3LjAzLjIwMTYgdW0gMTc6MDAg
c2NocmllYiBpZXRmQHRob21hc2NsYXVzZW4ub3JnPG1haWx0bzppZXRmQHRob21hc2NsYXVzZW4u
b3JnPjoNCg0KRGVhciBhbGwsDQoNCkFwb2xvZ2llcyBmb3Igbm90IGhhdmluZyBnb3R0ZW4gdGhp
cyBkb25lIHNvb25lciAtIGRheS1qb2IgbGVhdmluZyBmZXcgc3BhcmUgY3ljbGVzLg0KDQpJ4oCZ
dmUgcHJldmlvdXNseSBvZmZlcmVkIHJldmlld3MgYW5kIGNvbW1lbnRzLCBhbmQgc29tZSBvZiB0
aG9zZSBoYXZlIGJlZW4gYWRkcmVzc2VkIGluIHRoZSBsYXRlc3QgSS1EIOKAlCBvdGhlcnMgaGF2
ZSBub3QsIGJ1dCBzaG91bGQgYmUuIEkgcmVjYWxsIHRoYXQgdGhlcmUgd2FzIHNvbWUgbWFpbCBh
dHRlbXB0aW5nIHRvIHJlYnV0IHBhcnRzIG9mIHRoZSByZXZpZXcsIGFuZCBJIHdpbGwgZGlnIGl0
IG91dCBhbmQgcmVwbHkgdG8gdGhhdC4NCg0KDQpUaGF0IHdvbGQgYmUgZ3JlYXQuDQoNCkkgYW0g
ZmluZGluZyBhIGJpdCBvZiB0aW1lIGhlcmUgYW5kIHRoZXJlIHdoZW4gdGhlcmUgYXJlIGhvbGVz
IGluIHRoZSBhZ2VuZGEsIGFuZCBhbSAoYXMgeW91IGxpa2VseSBoYXZlIG5vdGljZWQpIGJhY2t0
cmFja2luZyB0aHJvdWdoIGVtYWlscyB3aGVuIEkgZ2V0IGEgY2hhbmNlLiBBcG9sb2dpZXMsIEkg
aG9wZSB0aGF0IEkgd2lsbCBnZXQgdG8gdGhlc2UgZW1haWxzIHRoaXMsIG9yIG5leHQgd2Vlaywg
YnV0IGRheS1qb2IgZWF0cyBpbiB0byB0aGUgYXZhaWxhYmxlIHRpbWUgOygNCg0KDQoNCkZvcndh
cmRpbmctdnMtcmVnZW5lcmF0aW9uDQpSZWNlbnQgZXhjaGFuZ2VzIG9uIHRoZSBsaXN0IG1hZGUg
bWUgdW5kZXJzdGFuZCB0aGF0IHByb3RvY29sIGNvbnRyb2wgbWVzc2FnZXMgYXJlICpub3QqIGZv
cndhcmRlZCwgYnV0IGFyZSBjb25zdW1lZCBhdCBlYWNoIGhvcCwgdGhlbiBhIG5ldyBtZXNzYWdl
IHdpdGggKGFsbW9zdC1idXQtbm90LXF1aXRlKSB0aGUgc2FtZSBjb250ZW50IGlzIGdlbmVyYXRl
ZCBhbmQgdHJhbnNtaXR0ZWQuDQoNClRoYXTigJlzIHdoYXQgd2XigJl2ZSBiZWVuIHRyeWluZyB0
byBzYXkgYWxsIGFsb25nISBJ4oCZbSByZWFsbHkgZ2xhZCB3ZeKAmXJlIGhhdmluZyB0aGlzIGNv
bnZlcnNhdGlvbi4NCg0KVGhlbiwgbGV0IHVzIGhhdmUgaXQgLS0gaXQncyBhIGNlbnRyYWwgcG9p
bnQgdG8gZ2V0IHJpZ2h0Lg0KDQoNCg0KSSBoYXZlIHRob3VnaHQgc29tZSBtb3JlIG9uIHRoaXMg
KCYgcmVhZCBzb21lIG9mIHRoZSBleGNoYW5nZXMgb24gdGhlIGxpc3Qgb24gdGhpcyB0b3BpYyBi
eSBDaHJpcywgVWxyaWNoLCBhbmQgb3RoZXJzKSwgYW5kIEkgYW0gY29udmluY2VkIHRoYXQgdGhp
cyBpcyBub3QgdGhlIHJpZ2h0IHdheSB0byBnbywgYXQgbGVhc3QgZm9yIHRoZSBmb2xsb3dpbmcg
cmVhc29uczoNCg0KDQogICAgICAgICAgICBvICAgICAgICAgIEl0IHJlbmRlcnMgdGhlIGhvcC1s
aW1pdC9ob3AtY291bnQgZmllbGRzIGluIHRoZSBSRkM1NDQ0IG1lc3NhZ2UgaGVhZGVyIHVzZWxl
c3MuDQogICAgICAgICAgICAgICAgICAgICAgICBUaGlzIHdvdWxkIG5vdCBiZSBiYWQgaWYgdGhl
IGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBieSB0aG9zZSBmaWVsZHMgd2FzIG5vdCB1c2VmdWwNCiAg
ICAgICAgICAgICAgICAgICAgICAgIOKAlCBzYWRseSwgaXQgaXMuIEZvciBleGFtcGxlLCBmb3Ig
c2NvcGUgbGltaXRlZCBmbG9vZGluZyAoZXhwYW5kaW5nIHJpbmcgc2VhcmNoLCBhbmQNCiAgICAg
ICAgICAgICAgICAgICAgICAgIHN1Y2gpIHdoaWNoIG1heSBiZSBvZiBpbnRlcmVzdCwgYW5kIHdo
aWNoIHJlcXVpcmUgaG9wLWxpbWl0Lg0KICAgICAgICAgICAgICAgICAgICAgICAgQSBob3AtY291
bnQgZmllbGQgbWF5IGFsc28gcHJvdmlkZSBhIOKAnGNoZWFw4oCdIChpbiB0ZXJtcyBvZiBvdmVy
aGVhZCkgYWRkaXRpb25hbCBwaWVjZQ0KICAgICAgICAgICAgICAgICAgICAgICAgb2YgaW5mb3Jt
YXRpb24gdG8gdXNlIGNvbmp1bmN0aXZlbHkgd2l0aCBhIOKAnHJlYWzigJ0gbWV0cmljLg0KDQoN
CkkgYWdyZWUgb24gdGhlIHVzZWZ1bG5lc3MsIHdoaWNoIGlzIHdoeSB3ZSB3ZXJlIHB1enpsZWQg
d2hlbiB3ZSB3ZXJlIHRvbGQgd2Ugd2VyZW7igJl0IGFsbG93ZWQgdG8gdXNlIHRob3NlIGZpZWxk
cyAob3IsIHJhdGhlciwgdGhhdCB3ZSB3ZXJlIHVzaW5nIHRoZW0gd3JvbmcsIGJ1dCB0aGF0IHRo
ZSByaWdodCB3YXkgdG8gdXNlIHRoZW0gZG9lc27igJl0IHdvcmsgZm9yIEFPRHZ2MikuIEkgYmVs
aWV2ZSBWaWNreSBoYXMgd3JpdHRlbiBhYm91dCB0aGlzIGluIG1vcmUgZGV0YWlsIGluIHByZXZp
b3VzIGRpc2N1c3Npb25zLCBhbmQgd2Ugd2VyZS9hcmUgbG9va2luZyBmb3J3YXJkIHRvIHJlYWRp
bmcgeW91ciBhbnN3ZXJzLi4uDQoNClNvLCB0aGUgc291cmNlIGdlbmVyYXRlcyBhIG1lc3NhZ2Us
IHRoZSBtZXNzYWdlIGlzIGZvcndhcmRlZCB0aHJvdWdoIHRoZSBuZXR3b3JrLCB3aXRoIGVhY2gg
aW50ZXJtZWRpYXRlIHJvdXRlciBkZWNyZW1lbnRpbmcgdGhlIGhvcCBsaW1pdCBhbmQgaW5jcmVt
ZW50aW5nIHRoZSBob3AgY291bnQuDQoNCkFzIHN0YXRlZCBpbiB0aGUgNTQ0NC1Vc2FnZSBkb2N1
bWVudCwgd2hlbiBmb3J3YXJkaW5nIGEgbWVzc2FnZSwgdGhlIGhvcC1saW1pdC9ob3AtY291bnQg
YXJlIG1vZGlmaWVkLCB0aGUgcmVzdCBvZiB0aGUgbWVzc2FnZSBTSE9VTEQgbm90IGJlLg0KDQpU
aGF0IGlzIHNwZWNpZmljYWxseSwgb25lIHRoaW5nIHdoZXJlIEkga2luZGEgd291bGQgbGlrZSA1
NDQ0LXVzYWdlIHRvIGdvIGZ1cnRoZXIgaXMgInRoZSBtZXNzYWdlIHN0cnVjdHVyZSBNVVNUIGlu
IGFsbCBjb25kaXRpb25zIHByZXNlcnZlZCB3aGVuIGZvcndhcmRpbmciIC0gYnV0IHN0aWxsIHNh
eSAiYW5kIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIHZhbHVlIGZpZWxkIG9mIFRMVnMgYXJl
IGFsc28gbm90IG1vZGlmaWVkIi4NCg0KV2hhdCB0aGlzIGJ1eXMgaXMgc2V2ZXJhbCB0aGluZ3Ms
IGluIHRoZSBjb250ZXh0IG9mIHRoaXMgcHJvdG9jb2w6DQoNCiAgICAgICAgICAgIG8gICAgICAg
ICAgaG9wLWxpbWl0L2hvcC1jb3VudCBjb3VsZCBiZSB1c2VmdWwgZm9yIHRoZSB1c3VhbA0KICAg
ICAgICAgICAgICAgICAgICAgICAgcHVycG9zZXMgKGVuc3VyaW5nIHRoYXQgbWVzc2FnZXMgZG8g
bm90IGxpdmUgZm9yZXZlciwNCiAgICAgICAgICAgICAgICAgICAgICAgIHNjb3BlLWxpbWl0ZWQg
Zmxvb2RpbmcsIC4uLikNCg0KICAgICAgICAgICAgbyAgICAgICAgICBpZiB0aGUgYWNjdW11bGF0
ZWQgcGF0aCBtZXRyaWMgaXMgc3RvcmVkIGluIGEgVExWIHZhbHVlIGZpZWxkLCB0aGF0DQogICAg
ICAgICAgICAgICAgICAgICAgICB2YWx1ZSBmaWVsZCBjYW4gKHdpdGggc3VpdGFibGUgZGlzY2xh
aW1lciB0byBjYWxsIG91dCAid2Uga25vdyBpdCBpcw0KICAgICAgICAgICAgICAgICAgICAgICAg
UkVDT01NRU5ERUQgdG8gbm90IGRvIHRoaXMsIGJ1dCBoZXJlJ3Mgd2h5IHdlIGFyZSBPSyBpbiBk
b2luZw0KICAgICAgICAgICAgICAgICAgICAgICAgaXQgYW55d2F5cyIpIGJlIG1vZGlmaWVkIHdo
ZW4gZm9yd2FyZGluZyB0aGUgbWVzc2FnZSwgYW5kDQoNCiAgICAgICAgICAgIG8gICAgICAgICAg
YXMgdGhhdCBwYXRoIG1ldHJpYyBmaWVsZCBpcyBpbiBhIG1lc3NhZ2Ugd2hvc2Ugc3RydWN0dXJl
IGRvZXMgbm90DQogICAgICAgICAgICAgICAgICAgICAgICBjaGFuZ2UsIGl0IHdpbGwgYmUgImF0
IHRoZSBzYW1lIHBsYWNlIGluIHRoZSBieXRlLXN0cmVhbSIgYXQgZWFjaCBob3AsDQogICAgICAg
ICAgICAgICAgICAgICAgICB3aGljaA0KDQogICAgICAgICAgICBvICAgICAgICAgIGFsbG93cyB1
c2VmdWwgdGhpbmdzIHN1Y2ggYXMgZGVyaXZpbmcgZnJvbSBSRkM3MTgyIGEgZm9ybSBvZg0KICAg
ICAgICAgICAgICAgICAgICAgICAgIndoZW4gY2FsY3VsYXRpbmcgdGhlIElDViwgemVybyBvdXQg
dGhhdCBmaWVsZCBpbiB0aGUgbWVzc2FnZSAnIHdoZW4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgdmFsaWRhdGluZyBhbiBJQ1YsIGFsc28gemVybyBvdXQgdGhhdCBmaWVsZCIgLS0gd2hpY2gg
Z29lcyBvbmUgc3RlcA0KICAgICAgICAgICAgICAgICAgICAgICAgICBmdXJ0aGVyICh3aGVuIGNv
dXBsZWQgd2l0aCBhIHRpbWUgc3RhbXApIHRoYW4gc2ltcGxlIHRyYW5zaXRpdmUgdHJ1c3QsDQog
ICAgICAgICAgICAgICAgICAgICAgICAgIGJ1dCBhbHNvDQoNCiAgICAgICAgICAgIG8gICAgICAg
ICAgYWxsb3dzIGV2ZW4gbW9yZSBmYW5jeSBhbmQgdXNlZnVsIChhbGJlaXQgZXhwZXJpbWVudGFs
KSB0aGluZ3Mgc3VjaA0KICAgICAgICAgICAgICAgICAgICAgICAgYXMgYWdncmVnYXRlIHNpZ25h
dHVyZXMgdG8gd29yayBjb3JyZWN0bHkuDQoNCkZ1cnRoZXJtb3JlLi4uLi4NCg0KDQoNCiAgICAg
ICAgICAgICAgICAgICAgICAgIFRoZSBvbmx5IHByYWN0aWNhbCBzb2x1dGlvbiB3b3VsZCBiZSB0
byByZS1pbnRyb2R1Y2UgdGhlc2UgZnVuY3Rpb25zIGJ5IHdheSBvZiBpbnNlcnRpbmcgYQ0KICAg
ICAgICAgICAgICAgICAgICAgICAgTWVzc2FnZVRMViDigJQgd2hpY2ggKGkpIGlzIG5vdCBzcGVj
aWZpZWQgaW4gdGhpcyBkb2N1bWVudCwgYW5kIChpaSkgd2hpY2ggd291bGQganVzdA0KICAgICAg
ICAgICAgICAgICAgICAgICAgc2VydmUgdG8gcmVuZGVyIG1lc3NhZ2VzIGJpZ2dlciB0aGFuIHN0
cmljdGx5IG5lZWRlZC4NCg0KRXhhY3RseTsgd2XigJlkIHJlYWxseSBsaWtlIHRvIGF2b2lkIHRo
aXMgYXMgd2VsbC4NCg0KDQouLi4gSXQgYXZvaWRzIHRoZSBhYm92ZSwgYW5kLi4uLg0KDQoNCg0K
DQogICAgICAgICAgICAgICAgICAgICAgICBTY29wZSBsaW1pdGVkIGZsb29kaW5nICBkb2VzIHNl
ZW0gdG8gYmUgYSBuZWNlc3NhcnkgcmVxdWlyZW1lbnQsIGlmIGZvciBubw0KICAgICAgICAgICAg
ICAgICAgICAgICAgb3RoZXIgcmVhc29uIHRoYW4gdG8gcHJldmVudCBpbmZvcm1hdGlvbiBmcm9t
IOKAnGNpcmN1bGF0aW5nIGZvcmV2ZXIgaW4gdGhlIG5ldHdvcmvigJ0uDQoNCkFPRFZ2MuKAmXMg
ZHVwbGljYXRlZCBkZXRlY3Rpb24gaG9wZWZ1bGx5IHNob3VsZCB0YWtlIGNhcmUgb2YgdGhhdC4g
SWlyYywgV2UgaW50ZXJwcmV0ZWQgeW91ciBlYXJsaWVyIEUtTWFpbHMgdG8gKGltcGxpY2l0bHkp
IG1lYW4gdGhhdCB5b3UgdGhpbmsgd2Ugc2hvdWxkIHJlbHkgb24gdGhhdCwgc2luY2UgeW91IHNh
aWQgd2UgY2Fu4oCZdCB1c2UgdGhlIGhvcC1saW1pdC9ob3AtY291bnQgZmllbGRzLg0KDQoNCi4u
Li5pZiBkb25lIChwcm9wZXIgZm9yd2FyZGluZyB3aXRoIHByZXNlcnZhdGlvbiBvZiB0aGUgc3Ry
dWN0dXJlLCByYXRoZXIgdGhhbiByZWdlbmVyYXRpb24gd2hpY2ggb3BlbnMgdXAgdGhlICJ0aGlz
IGlzIGEgbmV3IG1lc3NhZ2Ugd2l0aCBwb3RlbnRpYWxseSBuZXcgc3RydWN0dXJlIiBjYW4gb2Yg
d29ybXMpIGFzIEkgZGVzY3JpYmUsIGFsc28gYWRkcmVzc2VzIHRoZSBhYm92ZS4NCg0KV2l0aCBy
ZXNwZWN0IHRvIHdoYXQgSSBzYWlkIGVhcmxpZXIgd2hlbiBJIHNhaWQgImNhbid0IHVzZSBob3At
bGltaXQvaG9wLWNvdW50IGZpZWxkcyIuLi4ud2hlbiB5b3UgcmVnZW5lcmF0ZSwgeW91IGFic29s
dXRlbHksIGRlZmluaXRlbHksIGNhbid0Lg0KDQoNCg0KV2hlbiB5b3UgInJlZ2VuZXJhdGUiIGEg
bWVzc2FnZSwgdGhhdCBtZWFucyAieW91IGNvbnN0cnVjdCBhIGJyYW5kIG5ldyBtZXNzYWdlIiB3
aGljaCBtYXkgc2h1ZmZsZSBhZGRyZXNzZXMgaW5zaWRlIGFkZHJlc3MgYmxvY2tzLCBvciBiZXR3
ZWVuIGFkZHJlc3MgYmxvY2tzLCBzaHVmZmxlIFRMVnMgZGlmZmVyZW50bHkgdGhhbiB0aGV5IHdl
cmUgb3JpZ2luYWxseSwgZXZlbiB1c2UgVExWcyBvZiBkaWZmZXJlbnQgc3RydWN0dXJlIChlLmcu
LCBzaW5nbGUtdmFsdWUgVExWcyBpbnN0ZWFkIG9mIG11bHRpLXZhbHVlIFRMVnMpLg0KDQoNCg0K
VGhpcyBtZWFucyB0aGF0IHNvbWUgYXNzdW1wdGlvbnMgKHN1Y2ggYXMgd2hlbiBwcm9kdWNpbmcg
YW4gSUNWIGZvciB0aGUgbWVzc2FnZSwgd2hpY2ggZGVwZW5kcyBvbiB0aGUgYnl0ZSBvcmRlcikg
ZG9uJ3QgaG9sZC4gV2VsbCwgdGhleSBtYXkgbm90IGhvbGQsIHNvIHRoYXQgbWVhbnMgd2UgY2Fu
J3QgYXNzdW1lIHRoYXQgdGhleSBkby4gV2hpY2ggbWVhbnMgdGhhdCB0aGUgb3JpZ2luYXRvciBv
ZiBhIG1lc3NhZ2UgY2Fubm90IGdlbmVyYXRlIGFuIElDViB0aGF0IGNhbiBiZSBjb3JyZWN0bHkg
aW50ZXJwcmV0ZWQgKHdoaWNoIGlzIHdoYXQgbXkgbmV4dCBzZWN0aW9uIGluIG15IG9yaWdpbmFs
IG1haWwgd2FzIGFib3V0KS4NCg0KDQoNCldoaWNoIG1lYW5zLCBpbiBjb25jbHVzaW9uLCAgdGhh
dCB0aGUgaW5mb3JtYXRpb24gaW4gdGhlIG1lc3NhZ2UgcHJvZm91bmRseSBjaGFuZ2UgLS0gYW5k
IHRoZXJlZm9yZSB0aGVzZSBob3AtY291bnQvaG9wLWxpbWl0IHZhbHVlcyBkbyBub3QgZXZlbiBh
cHBseSB0byAidGhlIGluZm9ybWF0aW9uIi4NCg0KDQoNCkhvd2V2ZXIgaWYgcHJvcGVyIGZvcndh
cmRpbmcgd2l0aCBwcmVzZXJ2YXRpb24gb2YgdGhlIHN0cnVjdHVyZSwgcmF0aGVyIHRoYW4gcmVn
ZW5lcmF0aW9uIHdoaWNoIG9wZW5zIHVwIHRoZSAidGhpcyBpcyBhIG5ldyBtZXNzYWdlIHdpdGgg
cG90ZW50aWFsbHkgbmV3IHN0cnVjdHVyZSIgY2FuIG9mIHdvcm1zLCBhcyBJICgmIFVscmljaCAm
IG90aGVycykgaGF2ZSBzdWdnZXN0ZWQsIGlzIHRha2VuIHRvIGhlYXJ0LCBpdCBhbHNvIGFkZHJl
c3NlcyB0aGUgaXNzdWUgYmVsb3cgcmVnYXJkaW5nIGVuZC10by1lbmQgYXV0aGVudGljYXRpb24g
KHdoaWNoLCB3aGlsZSBzdGlsbCBoYXJkLCBpcyBwb3NzaWJsZSkuDQoNCg0KDQpBIGNvdXBsZSBv
ZiBtb3JlIGNvbW1lbnRzIGJlbG93DQoNCg0KDQoNCiAgICAgICAgICAgIG8gICAgICAgICAgSXQg
bWFrZXMgZW5kLXRvLWVuZCBhdXRoZW50aWNhdGlvbiB1bm5lY2Vzc2FyaWx5IGhhcmQuDQogICAg
ICAgICAgICAgICAgICAgICAgICBJIHRoaW5rIENocmlzIGNhbGxlZCB0aGlzIG91dCBhbHJlYWR5
LCBidXQgaXQgYmVhcnMgcmVwZWF0aW5nOiBTIGdlbmVyYXRlcyBhIG1lc3NhZ2UNCiAgICAgICAg
ICAgICAgICAgICAgICAgIChzYXksIGEgUlJFUSksIGFuZCBpbmNsdWRlcyBhbiBJQ1YgY2FsY3Vs
YXRlZCBvdmVyIHRoZSBjb250ZW50IG9mIHRoZSBtZXNzYWdlLg0KICAgICAgICAgICAgICAgICAg
ICAgICAgRm9yIGFueSByZWNpcGllbnQgdG8gYmUgYWJsZSB0byB2YWxpZGF0ZSB0aGUgSUNWLCB0
aGUgbWVzc2FnZSBoYXMgdG8gYmUgZXhhY3RseQ0KICAgICAgICAgICAgICAgICAgICAgICAgdGhl
IHNhbWUg4oCUIG5vdCBqdXN0IGluIGNvbnRlbnQsIGJ1dCBpbiBzdHJ1Y3R1cmUg4oCUIGFzIHdo
YXQgd2FzIGdlbmVyYXRlZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAg4oCcUmVnZW5lcmF0
aW5n4oCdIHJhdGhlciB0aGFuIOKAnGZvcndhcmRpbmfigJ0gbWVzc2FnZXMgbWVhbnMsIHRoYXQg
dGhlIGludGVybWVkaWF0ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgcm91dGVyIOKAnHJlZ2Vu
ZXJhdGluZ+KAnSB0aGUgUlJFUSBtYXkgY2hvc2UgYSBkaWZmZXJlbnQgc3RydWN0dXJlIChlLmcu
LCBpbmNsdWRlIFRMVnMNCiAgICAgICAgICAgICAgICAgICAgICAgIGluIGEgZGlmZmVyZW50IG9y
ZGVyKS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgVGhlIHByb3Bvc2FsIGZyb20gaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlcmtpbnMtbWFuZXQtYW9kdi1lMmVzZWMtMDAN
CiAgICAgICAgICAgICAgICAgICAgICAgIGlzIHRvIGFkZCBjb25zdHJhaW50cyBvbiAoaSkgdGhl
IHNldCBvZiBlbGVtZW50cyB0byBpbmNsdWRlIGluIGEgc2lnbmF0dXJlIGFuZCAoaWkpIHRoZQ0K
ICAgICAgICAgICAgICAgICAgICAgICAgb3JkZXIgb2YgdGhlc2UgZWxlbWVudHMuDQoNCiAgICAg
ICAgICAgICAgICAgICAgICAgIE9uZSBwcm9ibGVtIHdpdGggdGhhdCBhcHByb2FjaCBpcyAoaSk6
IGlmIGFuIGV4dGVuc2lvbiBhZGRzIGEgbWVzc2FnZSBUTFYsIG9yIGFuDQogICAgICAgICAgICAg
ICAgICAgICAgICBBZGRyZXNzIFRMViwgdG8gYSBtZXNzYWdlLCB0aGVuIHRoYXQgd2lsbCBub3Qg
YmUg4oCcY292ZXJlZOKAnSBieSB0aGUgcHJvcG9zZWQgZTJlc2VjIFRMVi4NCiAgICAgICAgICAg
ICAgICAgICAgICAgIFJhdGhlciBmb3IgKmVhY2gqIGV4dGVuc2lvbiBkZXZlbG9wZWQsIGFuIOKA
nHVwZGF0ZXMgZTJlc2Vj4oCdIGNsYXVzZSBuZWVkcyB0byBiZSBkb25lLg0KDQogICAgICAgICAg
ICAgICAgICAgICAgICBJ4oCZZCBzYXkgdGhhdCB0aGlzIGFwcHJvYWNoIHdvdWxkIGJlIHByb25l
IHRvIGVycm9ycyDigJQgYW5kIGFkZCBlbnRyb3B5IHRvIHRoZSBwcm9jZXNzDQogICAgICAgICAg
ICAgICAgICAgICAgICBvZiBkZXNpZ25pbmcgcHJvdG9jb2wgZXh0ZW5zaW9ucy4gVGhlIGFsdGVy
bmF0aXZlLCBhIG1lc3NhZ2UgYmVpbmcgZ2VuZXJhdGVkIGJ5IHRoZQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgc291cmNlIGFuZCAqZm9yd2FyZGVkKiAoYXMgd2UgZG8gaW4gT0xTUnYyLCBmb3Ig
ZXhhbXBsZSkgd291bGQgYWxsb3cgSUNWIFRMVnMNCiAgICAgICAgICAgICAgICAgICAgICAgIChl
dmVuLCBhbGxvdyByZXVzZSBvZiB0aG9zZSBzcGVjaWZpZWQgZm9yIE9MU1J2MikgZm9yIGNvdmVy
aW5nIGEgbWVzc2FnZSBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgIGV4dGVuc2lvbnMuDQoN
CiAgICAgICAgICAgICAgICAgICAgICAgIOKAnEJ1dCB3aGF0IGFib3V0IHRoZSBtZXRyaWNzIHZh
bHVlIHdoaWNoIHdpbGwgY2hhbmdlIG9uIGVhY2ggaG9w4oCdLCB5b3UgbWF5IHNheT8NCiAgICAg
ICAgICAgICAgICAgICAgICAgIEZvcnR1bmF0ZWx5LCB0aGF0IGlzIHJlbGF0aXZlbHkgZWFzeSB0
byBoYW5kbGU6IHNpbXBseSB6ZXJvIG91dCB0aGUgdmFsdWUgb2YgdGhhdCBUTFYgd2hlbg0KICAg
ICAgICAgICAgICAgICAgICAgICAgZ2VuZXJhdGluZyBvciB2ZXJpZnlpbmcgdGhlIElDViBNZXNz
YWdlVExWLiBBbmQgdXNlIFBhY2tldC1UTFZzIGZvciBob3AtYnktaG9wDQogICAgICAgICAgICAg
ICAgICAgICAgICBhdXRoZW50aWNhdGlvbiwgaWYgbmVlZGVkIChidXQsIHNlZSBiZWxvdykuDQoN
CiAgICAgICAgICAgIG8gICAgICAgICAgSXQgcHJldmVudHMgdGhlIHVzZSBvZiBtb3JlIGNsZXZl
ci9hZHZhbmNlZCBzaWduYXR1cmUgc2NoZW1lcy9JQ1ZzDQogICAgICAgICAgICAgICAgICAgICAg
ICBBZ2dyZWdhdGUgc2lnbmF0dXJlIGFsZ29yaXRobXMgKCBodHRwczovL2NyeXB0by5zdGFuZm9y
ZC5lZHUvfmRhYm8vcGFwZXJzL2FnZ3N1cnZleS5wZGYpDQogICAgICAgICAgICAgICAgICAgICAg
ICBleGlzdCwgYW5kIGFuIGludGVyZXN0aW5nIHVzZS1jYXNlIGNhbiBiZSBmb3VuZCBpbiBhbHNv
IHJlYWN0aXZlIHByb3RvY29scywgYWxsb3dpbmcgdmVyaWZ5aW5nDQogICAgICAgICAgICAgICAg
ICAgICAgICBub3Qg4oCcanVzdOKAnSB0aGUgZW5kIHBvaW50cywgYnV0IGFsc28gdGhlIGludGVy
bWVkaWFyaWVzIChhZ2Fpbiwgd2l0aCB0aGUgYXBwcm9wcmlhdGUg4oCcemVybyBvdXTigJ0NCiAg
ICAgICAgICAgICAgICAgICAgICAgIGRpc2N1c3NlZCBhYm92ZSwgb3Igc29tZXRoaW5nIHNtYXJ0
ZXIpLg0KICAgICAgICAgICAgICAgICAgICAgICAgUmVnZW5lcmF0aW9uIG9mIG1lc3NhZ2VzLCBy
YXRoZXIgdGhhbiBmb3J3YXJkaW5nLCByZW5kZXJzIHRoYXQgaW1wb3NzaWJsZSAob3IsIGlmIHVz
ZWQsDQogICAgICAgICAgICAgICAgICAgICAgICB1cGRhdGluZyB0byAgaHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LXBlcmtpbnMtbWFuZXQtYW9kdi1lMmVzZWMtMDApDQoNClRoZXJl
IGFyZSBvdGhlciByZWFzb25zLCBidXQgdGhlIGFib3ZlIGFyZSB0aG9zZSB0aGF0IGp1bXAgYXQg
bWUgYXMgaW1tZWRpYXRlIHNob3ctc3RvcHBlcnMuDQoNCkkgZG8gaG9uZXN0bHkgbm90IHNlZSB3
aGF0IHBvc3NpYmxlIGJlbmVmaXQgdGhlcmUgaXMgZnJvbSDigJxyZWdlbmVyYXRpb27igJ0g4oCU
IGJ1dCBJIHNlZSB2ZXJ5IGNsZWFyIGluY29udmVuaWVuY2VzLCBhbmQgc2VjdXJpdHkgaXMgbm90
IHRoZSBsZWFzdCBvZiB0aGVzZS4gSW5zaXN0aW5nIG9uIOKAnHJlZ2VuZXJhdGlvbuKAnSByZXF1
aXJlcyBkZXZlbG9wbWVudCBvZiDigJxub24tZ2VuZXJhbCB3b3JrYXJvdW5kc+KAnSBhcyBwb2lu
dGVkIG91dCBhYm92ZS4NCg0KVGhlIHBvc3NpYmxlIGJlbmVmaXQgaXMgdGhhdCB3ZSBuZWVkIHRv
IGFjY3VtdWxhdGUgJiB0cmFuc3BvcnQgbWV0cmljIHZhbHVlcyBzb21laG93LCBhbmQgd2UgY2Fu
4oCZdCBkbyB0aGF0IHdpdGhvdXQgcmVnZW5lcmF0aW5nIGF0IGxlYXN0IHBhcnRzIG9mIHRoZSBt
ZXNzYWdlLg0KSWYgd2XigJlyZSBtaXNzaW5nIGEgc29sdXRpb24gaGVyZSwgcGxlYXNlIHNoYXJl
IGl0IHdpdGggdXMuDQoNCg0KRG9uZSBpbiB0aGUgYWJvdmUuDQoNCg0KDQoNClNlY3VyaXR5IENv
bnNpZGVyYXRpb25zDQoNCkp1c3QgZm9yIGNvbnRleHTigJlzIHNha2UsIGRpZCB5b3UgcmV2aWV3
IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0x
MyBvciB0aGUgb25lcyBwcm9wb3NlZCBpbiB0aGUgdGhyZWFkIOKAnkFPRFZ2MjogU2VjdXJpdHkg
Y29uc2lkZXJhdGlvbnMgdXBkYXRl4oCcPw0KDQpJIGRpZC4gSXQgc3RpbGwgaXMgYSBmYXIgY3J5
IGZyb20gcGFzc2luZyB0aGUgYmFyLiBJJ3ZlIHBvc3RlZCBvbiB3aHkgaW4gdGhlIHBhc3QsIGFu
ZCBzb21lIG1vcmUgaW4gdGhpcyBtYWlsICh3aGljaCBhbHNvIGNvbnRhaW5zIHNvbWUgc3VnZ2Vz
dGlvbnMpLg0KDQpJIHdvdWxkIHN1Z2dlc3QgdGhhdCBzZXR0bGluZyB0aGUgcmVhcmNoaXRlY3R1
cmluZyB0byBkbyBmb3J3YXJkaW5nLCBhcyBJIGRlc2NyaWJlIGluIHRoZSBhYm92ZSwgc2hvdWxk
IGJlIGRvbmUsIHdoaWNoIHdvdWxkIGVhc2UgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGlz
c3VlIGNvbnNpZGVyYWJseSAoYW5kIHdoaWNoIHdvdWxkIGJlIG5lY2Vzc2FyeSBldmVuIGlmIGln
bm9yaW5nIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywgSU1PLCBmb3IgdGhpcyBkb2MgdG8g
Z28gYW55d2hlcmUpLg0KDQoNCg0KV2l0aCBhIG5ldyB2ZXJzaW9uIGNvdmVyaW5nIHRoYXQsIHRo
ZSBhdXRob3JzIChJIHdhbnRlZCB0byB3cml0ZSAieW91IiwgYnV0IGRlY2lkZWQgdG8gYmUgaW5j
bHVzaXZlKSBjb3VsZCB5b3UgZ28gbG9vayBhdCB0aGUgZGlmZmVyZW50IHNlY3VyaXR5IGVtYWls
cyBhbmQgcGVyaGFwcyBzdGFydCBhIHNlcGFyYXRlIHRocmVhZCBvbiB0aGF0LCB0b3dhcmRzIGEg
cmVzb2x1dGlvbj8NCg0KDQpCZXN0LA0KDQpUaG9tYXMNCg0KDQoNCg0KDQoNCg0KVGhpcyBpcyBh
biBhbHdheXMgdGhvcm55IHN1YmplY3QuIFdoZW4gT0xTUnYyIHdhcyBnb2luZyB0aHJvdWdoIHRo
ZSBwcm9jZXNzIHdlIGdvdCBhIHRob3JvdWdoIGVkdWNhdGlvbiBpbiBob3cgbGl0dGxlIHdlIGtu
ZXcgYWJvdXQgc2VjdXJpdHkgZnJvbSB0aGUgU0VDLUFEcywgYW5kIGhhZCB0byBzcGVuZCBhYm91
dCBhIHllYXIgb3Igc28gZGV2ZWxvcGluZyBSRkM3MTgzLiBUaGUgYm90dG9tIGxpbmUgaXMsIHRo
YXQgdGhpcyBwcm90b2NvbCBuZWVkcyBpdHMg4oCcUkZDNzE4MyAgZXF1aXZhbGVudOKAnSwgZWl0
aGVyIGFzIHBhcnQgb2YgdGhlIG1haW4gZG9jdW1lbnQsIG9yIGFzIGFuIGluZGVwZW5kZW50IGRv
Y3VtZW50LiBjdXJyZW50bHksIHRoYXQgaXMgbm90IHRoZSBjYXNlLg0KDQpBIG1pbmltYSwgbG9v
a2luZyBhdCBCQ1A3MiBhbmQgQkNQMTA3IOKAlCB0YWtpbmcgaW5zcGlyYXRpb24gZnJvbSBSRkM3
MTgzIG1pZ2h0IGJlIGF3IGdvb2QgaWRlYSwgYXMgdGhhdCB3YXMgdGhlIG1vc3QgcmVjZW50IHRo
YXQgd2VudCB0aHJvdWdoIHRoZSBTRUMgQUQuIFJlZ2FyZGxlc3Mgb2YgaG93LCBob3dldmVyLCBh
IOKAnG1hbmRhdG9yeSB0byBpbXBsZW1lbnTigJ0gc2VjdXJpdHkgbWVjaGFuaXNtIG1vc3QgYmUg
c3BlY2lmaWVkIChJIHRoaW5rIHRoZSByaWdodCB0ZXJtIHdhcyDigJxNVVNUIGltcGxlbWVudCwg
U0hPVUxEIHVzZeKAnSksIGluIHN1ZmZpY2llbnQgZGV0YWlsIHRvIGVuc3VyZSBpbnRlcm9wZXJh
YmxlIGltcGxlbWVudGF0aW9ucy4NCg0KQXMgYW4gZXhhbXBsZSwgYm90aCBbUkZDNjEzMF0gYW5k
IFtSRkM3MTgxXSBzZXQgb3V0IHRoYXQgdGhhdDoNCg0KICAgICAgT24gcmVjZWl2aW5nIGEgLi4u
IG1lc3NhZ2UsIGEgcm91dGVyIE1VU1QgZmlyc3QgY2hlY2sgaWYgdGhlDQogICAgICBtZXNzYWdl
IGlzIGludmFsaWQgZm9yIHByb2Nlc3NpbmcgYnkgdGhpcyByb3V0ZXINCg0KYW5kIHRoZW4gcHJv
Y2VlZCB0byBnaXZlIGEgbnVtYmVyIG9mIGNvbmRpdGlvbnMgdGhhdCwgZWFjaCwgd2lsbCBsZWFk
IHRvIGEgcmVqZWN0aW9uIG9mIHRoZSBtZXNzYWdlIGFzICJiYWRseSBmb3JtZWQgYW5kIHRoZXJl
Zm9yZSBpbnZhbGlkIGZvciBwcm9jZXNzaW5n4oCdIOKAlCBhIGxpc3Qgd2hpY2ggUkZDNzE4MyB0
aGVuIGFtZW5kZWQuIFRoYXQgZ2F2ZSBhIOKAnGhvb2vigJ0gZm9yIFJGQzcxODMgZm9yIGluc2Vy
dGluZyDigJxyZWplY3Rpb27igJ0uIElkZW0gZm9yIG1lc3NhZ2UgZ2VuZXJhdGlvbi4NCg0KSWYg
SSB3YXMgdG8gZG8gUkZDNzE4MS9SRkM2MTMwIHRvZGF5LCBJIHdvdWxkIGluY2x1ZGUgdGhhdCBk
aXJlY3RseSBpbnRvIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucy4gSXQgdHVybmVkIG91dCB0
byBiZSBtb3JlIG92ZXJoZWFkIChhbmQgc2xvdyBkb3duIHB1YmxpY2F0aW9uIGFueXdheXMpIHRv
IGRvIGl0IGFzIHNlcGFyYXRlIGRvY3VtZW50cy4NCg0KU2Vjb25kbHksIHdlIG5lZWQgdG8gYmUg
YSBsb3QgbW9yZSByaWdpZCBpbiB0ZXJtcyBvZiB3aGF0IElDVnMsIFRpbWVzdGFtcHMsIGV0Yy4g
YXJlIGFkZGVkL3JlbW92ZWQsIGFuZCB3aGF0IHRoYXQgYnJpbmdzLg0KDQpGb3IgZXhhbXBsZSAo
d2l0aCB0aGUgYXNzdW1wdGlvbiB0aGF0IG1lc3NhZ2VzIGFyZSAqZm9yd2FyZGVkKiBhbmQgKm5v
dCogcmVnZW5lcmF0ZWQpLCB0aGlzIGNvdWxkIGJlIG9uZSBvcHRpb246DQoNCiAgICAgICAgICAg
ICAgICAgICAgICAgIG8gICAgICAgICAgV2hlbiBhIFJSRVEsIFJSRVAgbWVzc2FnZSBpcyBnZW5l
cmF0ZWQsIGFkZCBhbiBJQ1YgTWVzc2FnZSBUTFYsIHdoaWNoIGlzIGNhbGN1bGF0ZWQgPHRoaXMg
d2F5Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIOKApih0YWtlIGluc3Bp
cmF0aW9uIGZyb20gUkZDNzE4MyBoZXJlKQ0KDQogICAgICAgICAgICAgICAgICAgICAgICBvICAg
ICAgICAgIFdoZW4gYSBSUkVRLCBSUkVQIG1lc3NhZ2UgaXMgdHJhbnNtaXR0ZWQgIChieSB0aGUg
c291cmNlLCBvciBmb3J3YXJkZWQgYnkgYW4gaW50ZXJtZWRpYXJ5KQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgaW4gYW4gUkZDNTQ0NCBwYWNrZXQsIGFuIElDViBQYWNrZXQg
VExWIGlzIGFkZGVkIHRvIHRoZSBwYWNrZXQsIHdoaWNoIGlzIGNhbGN1bGF0ZWQgPHRoaXMgd2F5
PiDigKYNCg0KICAgICAgICAgICAgICAgICAgICAgICAgbyAgICAgICAgICBXaGVuIGFuIFJGQzU0
NDQgcGFja2V0IGlzIHJlY2VpdmVkLCB2YWxpZGF0ZSB0aGUgSUNWIFBhY2tldCBUTFYgPHRoaXMg
d2F5PiBhbmQgaWYgdGhlIElDViBkb2VzbuKAmXQgdmFsaWRhdGUsDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBkaXNjYXJkIHRoZSBjb250YWluZWQgbWVzc2FnZXMuDQoNCiAg
ICAgICAgICAgICAgICAgICAgICAgIG8gICAgICAgICAgV2hlbiByZWNlaXZpbmcgYSBSUkVRL1JS
RVAgKGVpdGhlciBhcyBkZXN0aW5hdGlvbiwgb3IgYXMgYW4gaW50ZXJtZWRpYXJ5KSwgdmFsaWRh
dGUgdGhlIElDViBNZXNzYWdlIFRMVg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPHRoaXMgd2F5PiBhbmQgaWYgdGhlIElDViBkb2VzbuKAmXQgdmFsaWRhdGUsIGRpc2NhcmQg
dGhlIG1lc3NhZ2UsIGRvIG5vdCBwcm9jZXNzLCBkbyBub3QgZm9yd2FyZC4NCg0KVGhpcyBpcyBh
IGRpZmZlcmVudCAoYW5kIG1vcmUgZmxleGlibGU/KSBtb2RlbCB0aGFuIOKAnGp1c3TigJ0gdHJh
bnNpdGl2ZSB0cnVzdCBhbmQg4oCcanVzdOKAnSBlbmQtdG8tZW5kIHRydXN0IGRpc2N1c3NlZCBw
cmV2aW91c2x5LCBhbmQgaXMgZW5hYmxlZCBieSB0aGUg4oCcZm9yd2FyZGluZ+KAnSBiaXQgZGVz
Y3JpYmVkIHByZXZpb3VzbHkuDQoNCk1ldHJpY3MNCkkgaGF2ZSBhc2tlZCB0aGlzIG51bWVyb3Vz
IHRpbWVzLCBidXQgaGF2ZSBub3QgZ290dGVuIGFueSBhbnN3ZXIgc28gSSBhbSBlc2NhbGF0aW5n
IHRoaXMgYWdhaW4uIFdoeSBpcyB0aGlzIGRvY3VtZW50IGhhdmluZyBhIG5vcm1hdGl2ZSByZWZl
cmVuY2UgdG8gUkZDNjU1MT8NCg0KDQogICBbUkZDNjU1MV0gIFZhc3NldXIsIEpQLiwgRWQuLCBL
aW0sIE0uLCBFZC4sIFBpc3RlciwgSy4sIERlamVhbiwgTi4sDQoNCiAgICAgICAgICAgICAgYW5k
IEQuIEJhcnRoZWwsICJSb3V0aW5nIE1ldHJpY3MgVXNlZCBmb3IgUGF0aCBDYWxjdWxhdGlvbg0K
DQogICAgICAgICAgICAgIGluIExvdy1Qb3dlciBhbmQgTG9zc3kgTmV0d29ya3MiLCBSRkMgNjU1
MTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjU1MT4sIERPSSAxMC4xNzQ4Ny8NCg0K
ICAgICAgICAgICAgICBSRkM2NTUxPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTUx
PiwgTWFyY2ggMjAxMiwNCg0KICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9y
Zy9pbmZvL3JmYzY1NTE+Lg0KDQoNClVubGVzcyBJIGFtIG1pc3Rha2VuLCB0aGlzIGlzIG5vdCB0
aGUgUk9MTCBXRy4gQW5kIHRoZSBhYnN0cmFjdCB0byBSRkM2NTUxIGV4cGxpY2l0bHkgcmVhZHM6
DQoNCg0KICAgTG93LVBvd2VyIGFuZCBMb3NzeSBOZXR3b3JrcyAoTExOcykgaGF2ZSB1bmlxdWUg
Y2hhcmFjdGVyaXN0aWNzDQoNCiAgIGNvbXBhcmVkIHdpdGggdHJhZGl0aW9uYWwgd2lyZWQgYW5k
IGFkIGhvYyBuZXR3b3JrcyB0aGF0IHJlcXVpcmUgdGhlDQoNCiAgIHNwZWNpZmljYXRpb24gb2Yg
bmV3IHJvdXRpbmcgbWV0cmljcyBhbmQgY29uc3RyYWludHMuDQpXaGljaCBleHBsaWNpdGx5IGlz
IGRpc2NsYWltaW5nIHRoYXQgdGhlc2UgbWV0cmljcyBhcmUgbm90IGFwcGxpY2FibGUgaW4gYWQg
aG9jIG5ldHdvcmtz4oCUIGFuZCwgSSBhbSB3b25kZXJpbmcsIHdoYXQgaGFzIGNoYW5nZWQgc2lu
Y2UgdGhlIHB1YmxpY2F0aW9uIG9mIFJGQzY1NTEgdG8gc3VkZGVubHkgbWFrZSB0aGVzZSBhcHBs
aWNhYmxlPw0KDQogSSBhbSBhbHNvIHdvbmRlcmluZyBpZiBsb29raW5nIGF0IChhbmQsIHBlcmhh
cHMsIHVzaW5nPykgdGhlIHNhbWUgbWV0cmljIHR5cGUgVExWIHR5cGUgYXMgaW4gT0xTUnYyIGlz
IG5vdCBhIHBvc3NpYmlsaXR5Pw0KDQpFaXRoZXIgd2F5LCByZWZlcmVuY2luZyBSRkM2NTUxIGhl
cmUgaXMgd3JvbmcuDQoNClJGQzY2MjEgKFNNRikgdXNhZ2UNCkFzIGxhdGUgYXMgZWFybGllciB0
aGlzIG1vbnRoLCBSRkM2NjIxIHJlYXJlZCBpdHMgaGVhZCBhZ2FpbiBvbiB0aGUgbWFpbGluZyBs
aXN0LiBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgYXV0aG9ycyBhcmUgc2V0IG9uIHVzaW5nIGZsb29k
aW5nIHJlZHVjdGlvbiBhcyBwYXJ0IG9mIFJSRVEgZGlzdHJpYnV0aW9uLiBJZiB0aGF0IGlzIHRo
ZSBjYXNlLCB0aGVuIHRoaXMgcHJvdG9jb2wgTVVTVCBzcGVjaWZ5IHRoYXQgZmxvb2RpbmcgcmVk
dWN0aW9uLg0KDQpTYXlpbmcg4oCcVXNlIFJGQzY2MjHigJ0gd29u4oCZdCB3b3JrLCBmb3IgcmVh
c29ucyBDaHJpcyBwb2ludCBvdXQgaW4gYW4gZW1haWwgZWFybGllciB0byB0aGUgbGlzdDoNClRo
ZSBuZXR3b3JrIGRvZXMgbm90IGFuZCBmdW5kYW1lbnRhbGx5IGNhbm5vdCBvZmZlciBtdWx0aWNh
c3Qgc3VwcHJlc3Npb24gdG8gQU9EVnYyLiBUaGlzIGlzbid0IGEgaGFyZCBjb25jZXB0LCBidXQg
c2VlbXMgdG8ga2VlcCBoYXZpbmcgdG8gYmUgc2FpZC4gQU9EVnYyIG1lc3NhZ2VzIGFyZSBjYXJy
aWVkIGluIDU0NDQgcGFja2V0cywgYW5kIHRob3NlIG9ubHkgdHJhdmVsIG9uZSBob3AuIFRoYXQg
ZG9lc24ndCBhbGxvdyBmb3Igc3VwcHJlc3Npb24uIEZ1cnRoZXJtb3JlIEFPRFZ2MiBpcyBjcmVh
dGluZyBuZXcgbWVzc2FnZXMgZWFjaCBob3AuIFRoYXQgbmVlZHMgQU9EVnYyIHNwZWNpZmljIGhh
bmRsaW5nLg0KDQpBbmQgcXVvdGluZyBhbiBlbWFpbCBmcm9tIG15c2VsZjoNCklmIHByb3RvY29s
IFggcmVsaWVzIG9uIHVzaW5nIGEgZmxvb2Rpbmcgb3BlcmF0aW9uLCB0aGVuIGl0IGNlcnRhaW5s
eSBpcyBwcm90b2NvbCBYJ3MgcmVzcG9uc2liaWxpdHkgdG8gIHNwZWNpZnkgdGhlIGZsb29kaW5n
IG9wZXJhdGlvbiAob3IsIGF0IGxlYXN0LCB0aGUgcmVxdWlyZW1lbnRzIHRvIHRoZSBmbG9vZGlu
ZyBvcGVyYXRpb24gKSBmb3IgY29ycmVjdCBmdW5jdGlvbmluZyBvZiBwcm90b2NvbCBYLg0KDQpJ
4oCZdmUgcHJldmlvdXNseSBwb2ludGVkIG91dCB0aGF0IFJGQzY2MjEgcmVxdWlyZXMgc29tZSBk
ZWdyZWUgb2YgY29uZmlndXJhdGlvbiAoY2Fu4oCZdCBqdXN0LCBmb3IgZXhhbXBsZSwgcGljayB0
d28gZGlmZmVyZW50IHJlbGF5IHNldCBzZWxlY3Rpb24gYWxnb3JpdGhtcywgYXMgdGhhdCBtYXkg
cHJvZHVjZSBhIGRpc2Nvbm5lY3RlZCBmbG9vZGluZyBkb21haW4pLg0KDQpJbiBvdGhlciB3b3Jk
cywgd2hhdCB0aGUgYXV0aG9ycyBwcm9wb3NlIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1wZXJraW5zLW1hbmV0LXVzaW5nLXJmYzY2MjEtMDAgaXMgaW5zdWZmaWNpZW50Lg0K
DQpNdWx0aXBsZSBpbnRlcmZhY2VzIGNvbmZpZ3VyZWQgd2l0aCB0aGUgc2FtZSBhZGRyZXNzKGVz
KSAtICYgUkZDNjYyMQ0KSSB0aGluayB0aGF0IGl0IGhhcyBiZWVuIGVzdGFibGlzaGVkIHRoYXQg
dGhlIGFiaWxpdHkgdG8gdXNlIHRoZSBzYW1lIGFkZHJlc3Mgb24gbXVsdGlwbGUgaW50ZXJmYWNl
cyBpcyBhIHJlcXVpcmVtZW50LiBJdOKAmXMgbm90IGNsZWFyIHRvIG1lIHRoYXQgYSBzaW5nbGUg
d2F5IG9mIGRvaW5nIHNvIGhhcyBiZWVuIHByb3Bvc2VkLCBub3IgdGhhdCB0aGUg4oCcb3BlcmF0
aW5nIGNvbmRpdGlvbnPigJ0gYXJlIGNhbGxlZCBvdXQgKGZvciBleGFtcGxlLCB3aWxsIGl0IHdv
cmsgIGlmIHJvdXRlciBBIGFuZCByb3V0ZXIgQiBib3RoIGhhdmUgdHdvIGludGVyZmFjZXMsIGFu
ZCB0aGF0IGFsbCA0IGludGVyZmFjZXMgdXNlIHRoZSBzYW1lIElQIGFkZHJlc3M/KQ0KDQpUaGlz
IGlzIG5vdCBlbnRpcmVseSB1bnJlbGF0ZWQgdG8gZmxvb2RpbmcgcmVkdWN0aW9uIGFuZCBSRkM2
NjIxLiBPbmUgb2YgdGhlIGNvbXBsZXhpdGllcyBpcyB0byBnZXQgdGhhdCBqdXN0IHJpZ2h0OiBP
TFNSdjIgLSBmb3IgZXhhbXBsZSAtIGNhbGN1bGF0ZXMgRmxvb2RpbmctTVBScyBwZXIgaW50ZXJm
YWNlLCBhbmQgUkZDNjEzMCBpcyBjYXJlZnVsIGluIGhvdyBpdCBkZXRlY3RzIGJpZGlyZWN0aW9u
YWxpdHkgb2YgbGlua3MuDQoNCkkgaGF2ZSBub3Qgd29ya2VkIG91dCBhbGwgdGhlIGRldGFpbHMg
b2YgaG93IHRoaXMgaW1wYWN0cyB0aGlzIHByb3RvY29sIOKAlCBidXQsIGl0IHJlcXVpcmVzIGF0
dGVudGlvbi4gRXNwZWNpYWxseSB3aGVuIHdhbnRpbmcgdG8gYmUgYWJsZSB0byBzYXkg4oCc4oCm
dXNlIFJGQzY2MjHigJ0sIHRoZW4gdGhlIGludGVyZmFjZSBjb25maWd1cmF0aW9uIGNvbnN0cmFp
bnRzIHdoZW4gZmFjZWQgd2l0aCBtdWx0aXBsZSBpbnRlcmZhY2VzIG11c3QgYmUgd29ya2VkIG91
dC4NCg0KUHJlZml4ZXMgJiBHYXRld2F5cw0KQSBxdWVzdGlvbiB0byBteSBtaW5kLCBhbmQgSSBh
bSBub3Qgc3VyZSBJIGtub3cgaG93IHRvIGFuc3dlciB0aGF0IGZyb20gcmVhZGluZyB0aGUgZHJh
ZnQgc2luY2UgaXQgaXMgbm90IGRpc2N1c3NlZCBpbiBzZWN0aW9uIDkgKGF0IGxlYXN0KSwgaXM6
IOKAnFdoYXQgaGFwcGVucyBpZiBJIHNlbmQgYSBSUkVRIHRvIGEgcHJlZml44oCdIChpLmUuLCBh
IC88MTI4IGluIElQdjYpPw0KDQogICAgICAgICAgICBvICAgICAgICAgIElmIHRoZSB3aG9sZSBw
cmVmaXggaXMgcGFydCBvZiB0aGUgYXR0YWNoZWQgbmV0d29yayBzZXQgb2YgYSBzaW5nbGUgcm91
dGVyLA0KICAgICAgICAgICAgICAgICAgICAgICAgdGhlbiBJIGV4cGVjdCB0byBnZXQgYSBzaW5n
bGUgUlJFUCBiYWNrLCBpcyB0aGF0IHRoZSBjYXNlPw0KDQogICAgICAgICAgICBvICAgICAgICAg
IElmICJoYWxmIHRoZSBwcmVmaXgiICBpcyBwYXJ0IG9mIHRoZSBhdHRhY2hlZCBuZXR3b3JrIHNl
dCBvZiBhIHNpbmdsZSByb3V0ZXIsDQogICAgICAgICAgICAgICAgICAgICAgICBhbmQgdGhlIG90
aGVyIGhhbGYgaXMgcGFydCBvZiB0aGUgYXR0YWNoZWQgbmV0d29yayBzZXQgb2YgYW5vdGhlciAg
c2luZ2xlIHJvdXRlciwNCiAgICAgICAgICAgICAgICAgICAgICAgIHRoZW4gSSBleHBlY3QgdHdv
IFJSRVBzLCBpcyB0aGF0IHRoZSBjYXNlPw0KDQogICAgICAgICAgICBvICAgICAgICAgIE1vcmUg
Z2VuZXJhbGx5LCB3aWxsIEkgZ2V0IGEgdHJlZSBidWlsZCB0aHJvdWdoIHRoZSBuZXR3b3JrIGhl
cmU/DQoNCkFPRFZ2MiBjdXJyZW50bHkgZG9lc27igJl0IHN1cHBvcnQgUlJFUXMgZm9yIHByZWZp
eGVzLiBJ4oCZdmUgYWxyZWFkeSBhZGRlZCDigJ5JZiBSdGVNc2cgaXMgYSBSUkVRLCBSdGVNc2cu
VGFyZ1ByZWZpeExlbiBTSE9VTEQgZXF1YWwgYWRkcmVzcyBsZW5ndGgu4oCcIHRvIFJ0ZU1zZy5U
YXJnUHJlZml4TGVuIGluIHNlY3Rpb24gNC42PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyNzZWN0aW9uLTQuNj4uIE11bHRpY2FzdCBSb3V0ZSBN
ZXNzYWdlIFRhYmxlIGluIHJlc3BvbnNlIHRvIEp1c3RpbuKAmXMgY29tbWVudHMsIGJ1dCBJ4oCZ
bGwgZ28gdGhyb3VnaCB0aGUgZHJhZnQgYWdhaW4gYW5kIHNlZSB3aGVyZSB3ZSBuZWVkIHRvIHN0
YXRlIHRoaXMgbW9yZSBjbGVhcmx5Lg0KDQpCZXN0IHJlZ2FyZHMsDQpMb3R0ZSBTdGVlbmJyaW5r
DQoNCg0KDQoNClNlY3Rpb24gOSAob3IsIHRoZSB3aG9sZSBzcGVjKSBpcyBhbHNvIG5vdCBleHBs
aWNpdCBlbm91Z2ggYWJvdXQgbXVsdGlwbGUgICJkZWZhdWx0IGdhdGV3YXlzIiDigJQgaS5lLiwg
dGhlIGV4dGVybmFsIG5ldHdvcmsgYmVpbmcg4oCcdGhlIHJlc3Qgb2YgdGhlIEludGVybmV04oCd
LCBhbmQgdGhlcmUgYmVpbmcgbXVsdGlwbGUgZ2F0ZXdheXMgdG8gdGhlIEludGVybmV0LiBJIHVu
ZGVyc3RhbmQgaG93IHRoZSBSUkVRIGdldHMgdG8gdGhlIGdhdGV3YXksIGFuZCBob3cgdGhlIGdh
dGV3YXkgZGV0ZXJtaW5lcyBpZiBpdCBzaG91bGQgcmVzcG9uZCAodGhlIGRlc3RpbmF0aW9uIGlz
IG5vdCBwYXJ0IG9mIOKAnHRoZSBNQU5FVCBwcmVmaXgsIHdpdGggd2hpY2ggaXQgaXMgY29uZmln
dXJlZOKAnSkuDQoNCkJ1dCwgaWYgQSBpcyBjbG9zZSB0byBHVzEsIGFuZCBCIGlzIGNsb3NlIHRv
IEdXMiwgYnV0IEEgYW5kIEIgYmVpbmcgZmFyIGZhciBhcGFydCAoYWNjb3JkaW5nIHRvIHRoZSBt
ZXRyaWMgdXNlZCkgd2l0aGluIHRoZSBNQU5FVCwgdGhlbiBpdCB3b3VsZCBiZSBwcmVmZXJlbnRp
YWwgZm9yIHRoZSByb3V0ZSBmcm9tIEEgdG8gQiB0byBnbyB2aWEgR1cxLeKAnHRoZS1JbnRlcm5l
dOKAnS1HVzI/DQoNCklzIHRoaXMgYSBzdXBwb3J0ZWQgY29uZmlndXJhdGlvbj8NCiAgICAgICAg
ICAgIG8gICAgICAgICAgSWYgeWVzLCBob3cgaXMgaXQgKHNlcSMgd2lzZSwgSSB3b3VsZCBleHBl
Y3Qgc29tZSBjb21wbGljYXRpb25zKSBoYW5kbGVkPw0KICAgICAgICAgICAgbyAgICAgICAgICBJ
ZiBub3QsIHdoZXJlIGlzIGl0IHN0YXRlZCB0aGF0IHRoaXMgY29uZmlndXJhdGlvbiBpcyBub3Qg
cG9zc2libGUgd2l0aCB0aGlzIHByb3RvY29sPw0KDQoNClRoZSBhcHBsaWNhYmlsaXR5IHN0YXRl
bWVudCBzYXlzOg0KDQoNCiAgIEFPRFZ2MiBpcyBkZXNpZ25lZCBmb3Igc3R1YiBvciBkaXNjb25u
ZWN0ZWQgbW9iaWxlIGFkIGhvYyBuZXR3b3JrcywNCg0KICAgaS5lLiwgbm9uLXRyYW5zaXQgbmV0
d29ya3Mgb3IgdGhvc2Ugbm90IGNvbm5lY3RlZCB0byB0aGUgaW50ZXJuZXQuDQoNCiAgIEFPRFZ2
MiBjYW4sIGhvd2V2ZXIsIGJlIGNvbmZpZ3VyZWQgdG8gcGVyZm9ybSBnYXRld2F5IGZ1bmN0aW9u
cyB3aGVuDQoNCiAgIGF0dGFjaGVkIHRvIGV4dGVybmFsIG5ldHdvcmtzLCBhcyBkaXNjdXNzZWQg
aW4gU2VjdGlvbiA5PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0
LWFvZHZ2Mi0xMyNzZWN0aW9uLTk+Lg0KDQpJIGJlbGlldmUgdGhhdCB0aGUgc2NlbmFyaW8gSSBk
ZXNjcmliZSBpcyBpbmRlZWQgYSBzdHViIG5ldHdvcmsgKGFuZCBub3QgYSB0cmFuc2l0IG5ldHdv
cmspPw0KDQrigJQg4oCUIOKAlA0KDQpBcyBJIGluZGljYXRlZCwgdGhlc2UgYXJlIHRoZSBiaWct
cGljdHVyZSBpc3N1ZXMgdGhhdCBJIGhhdmUgZ290dGVuIGFyb3VuZCB0byB0aGlua2luZyBhYm91
dCBlbm91Z2ggdG8gd3JpdGUgdXAuIEnigJltIG5vdCB0aHJvdWdoIHdvcmtpbmcgdGhyb3VnaCB0
aGUgZG9jdW1lbnQsIGJ1dCB0aG9zZSB3ZXJlIHRoZSBvbmVzIHRoYXQgY2FtZSB0byBtaW5kLCBh
bmQgd2hpY2ggc2VlbSBpbXBlcmF0aXZlIHRvIHJlc29sdmUuDQoNCkJlc3QsDQoNClRob21hcw0K
DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1h
bmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQoqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
Kg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhl
IGludGVuZGVkDQpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBh
cmUgbm90IHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3Vy
IHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuDQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9y
IHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yDQpkaXN0cmlidXRlIGl0cyBj
b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLg0KKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0K

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B00C7GLKXM0002VGREEN_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIg
MiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2Ut
MToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9t
YTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0
eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y
bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox
Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss
IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy
bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ
dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNt
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv
QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv
b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw
YW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bh
bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk
LXNwYWNlO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5
bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsInNl
cmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBU
ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs
bG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh
dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w
cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT
ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk
ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K
PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+
PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxp
bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJltIHJl
YWRpbmcgdGhpcyBpbiBPdXRsb29rLiAoT3IgcmF0aGVyIGluIGEgbWl4dHVyZSBvZiBPdXRsb29r
IGFuZCBvbiBteSBwaG9uZS4gQnV0IHRoaXMgb25lIGluIE91dGxvb2suKSBBbmQgaW4gT3V0bG9v
aywgcXVpdGUgYnJva2VuIHdpdGggbm8gaW5mb3JtYXRpb24NCiBvbiB3aG8gc2FpZCB3aGF0Ljxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8bzpwPjwv
bzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0Ui
PkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4N
CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bh
bj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdE
N0QiPjogJm5ic3A7JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8ICZuYnNwOzxiPkU6DQo8
L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5k
ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxt
c2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENN
MiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl
IExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3
NDUxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5
MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1
cnJleSwgR1UyIDdZUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPiBpZXRmQHRob21hc2NsYXVzZW4ub3JnIFttYWlsdG86aWV0ZkB0aG9tYXNjbGF1
c2VuLm9yZ10NCjxicj4NCjxiPlNlbnQ6PC9iPiAyMCBBcHJpbCAyMDE2IDE3OjA2PGJyPg0KPGI+
VG86PC9iPiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4NCjxiPkNjOjwvYj4gTG90dGUg
U3RlZW5icmluazsgTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3Q8YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gT24gRm9yd2FyZGluZy1hbmQtcmVnZW5lcmF0aW9uICh3
YXM6IFJlOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBi
aWcgdGlja2V0IEl0ZW1zKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNl
bnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50
ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjxvOnA+PC9v
OnA+PC9zcGFuPjwvYj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh
bGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50
ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2Fu
aXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQu
PC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48
YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQg
Y2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48L3NwYW4+
PC9lbT48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFu
Pg0KPC9lbT48L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4g
ZW1haWxzIHlvdSByZWNlaXZlLA0KIGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQu
YmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1Jl
ZCUyMEZsYWdzLnBkZiI+DQpoZXJlPC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwg
dGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9p
bnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMv
RG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPg0KdGhp
cyBwcm9jZXNzPC9hPi48L3NwYW4+PC9lbT48L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzMzMzk3MiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNocmlzLCBhbGwsPG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXByIDIwLCAyMDE2LCBhdCAxMjozMCwgRGVh
cmxvdmUsIENocmlzdG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92
ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DYW4gSSBqdXN0IHNheSBpdOKA
mXMgcXVpdGUgaGFyZCB0byB3b3JrIG91dCB3aG8gaXMgc2F5aW5nIHdoYXQgaW4gdGhlc2UgZXhj
aGFuZ2VzLiBJ4oCZbSBoYXZpbmcgdG8gZ3Vlc3Mgc29tZSBvbiB0aGUgYmFzaXMgb2Yg4oCcdGhh
dCBzb3VuZHMgbGlrZSBUaG9tYXPigJ0gb3Ig4oCcdGhhdA0KIHNvdW5kcyBsaWtlIExvdHRl4oCd
Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhhdCB5b3VyIE1VQSBpcyBzbGlnaHRseSBi
cm9rZW4sIHRoZW4sIGJ1dCB3aGVuIEkgaGF2ZSBkb3VidHMgSSBoaXQgdGhlIGFyY2hpdmVzLCB3
aGljaCBjb3JyZWN0bHkgc2hvd3Mgd2hvIHNheXMgd2hhdCDigJQgaGVyZeKAmXMgdGhlIGFyY2hp
dmUgZm9yIHRoZSBtZXNzYWdlIGluIHF1ZXN0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZl
LmlldGYub3JnL2FyY2gvbXNnL21hbmV0L01DeFdmMHRMYzlRN0l4X1hXXzBsQVB5SElkYyI+PHNw
YW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5odHRwOi8vbWFpbGFy
Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbWFuZXQvTUN4V2YwdExjOVE3SXhfWFdfMGxBUHlISWRj
PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGF0IEnigJlt
IG5vdCBjbGVhciBvbiBpcyB3aGF0IGNvbmNsdXNpb24sIGlmIGFueSwgeW914oCZdmUgZHJhd24g
b24gaG9wIGNvdW50L2xpbWl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+QXMgSSBzZWUgaXQsIGlmIHRoZSBwcm90b2NvbCByZWNlaXZlcyBhIG1lc3NhZ2UgdGhlbiBz
ZW5kcyBhIG1lc3NhZ2Ugc2ltaWxhciBidXQgbm90IGlkZW50aWNhbCB0byB0aGF0IG91dCwgdGhh
dCBjYW4gYmUgcmV2aWV3ZWQgYXMgY3JlYXRpbmcgYSBuZXcgbWVzc2FnZS4NCiBJdCBpcyBhIG5l
dyBtZXNzYWdlIGFzIGZhciBhcyA3MTgyIGlzIGNvbmNlcm5lZC48L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZW5jZSB3aHkgSSB3
cm90ZSAob3IsIEkgdGhpbmsgSSB3cm90ZSkgNzE4Mi1kZXJpdmVkIFRMVi48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCB0aGUgcHJvdG9jb2wgY291bGQgaW1wb3Nl
IHNvbWUgcmVzdHJpY3Rpb25zLiBGb3IgZXhhbXBsZSDigJx0aGUgb25seSB0aGluZyBhbGxvd2Vk
IHRvIGJlIGNoYW5nZWQgaXMgdGhpcyBmaWVsZCBpbiB0aGlzIFRMVuKAnS4gV2hpY2ggaXQgd291
bGQgdGhlcmVmb3JlIGJlIGENCiBnb29kIGlkZWEgZm9yIHRoZSBjcmVhdG9yIG9mIHRoZSBtZXNz
YWdlIHRvIGluY2x1ZGUsIGV2ZW4gaWYgaXQgdGh1cyBuZWVkZWQgdG8gaW5jbHVkZSBhIGxpbmsg
bWV0cmljIG9mIHplcm8uIChXaGljaCBpcyBhIGRlc2lnbiBwb2ludCAtIHlvdSBtaWdodCBuZWVk
IHRvIGFsbG93IHRoYXQgaW4gbWV0cmljIHNwZWNpZmljYXRpb24uKSBCdXQgeW91IHdvdWxkIG5l
ZWQgdG8gc3RhdGUgdGhhdC4gVGhhdCBlbmFibGVzIHNvbWUgZnV0dXJlIGRlc2lnbnMNCiAtIG5v
dCA3MTgyLCBwb3NzaWJseSBhbiBleHRlbnNpb24gdG8gNzE4MiwgcG9zc2libHkgc29tZXRoaW5n
IG5ldy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+WUVTLCB0aGF04oCZcyBteSBwb2ludC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgaXMgYSBwcm9ibGVtIHRoYXQgdGhpcyBpZGVh
IHdvdWxkIGJlIHB1dHRpbmcgaW4gYSBuZWVkIHRvIHVuZGVyc3RhbmQgc3BlY2lmaWMgVExWcywg
d2hpY2ggaXMgdW5kZXNpcmFibGUuIEkgaGF2ZSBzb21lIGlkZWFzIHRoZXJlLCBzdWNoIGFzIHVz
aW5nIHRoZSBwcm90b2NvbC1zcGVjaWZpYw0KIHNwYWNlLCBidXQgdGhpcyBpc27igJl0IGEgZml2
ZSBtaW51dGUgam9iLCBhbmQgbmVlZHMgdG8gYmUgZ290IHJpZ2h0LiBXaGlsZSBub3cgaXMgbm90
IHRoZSB0aW1lIHRvIGRlZmluZSB0aGlzLCBzb21lIGRlY2lzaW9ucyBjb3VsZCByZWFsbHkgaW1w
YWN0IG9uIGZ1dHVyZSBkZXNpZ25zLiBGb3IgZXhhbXBsZSBwdXR0aW5nIGFueXRoaW5nIHdhbnRp
bmcgdG8gYmUgbXV0YWJsZSBzdHVjayBpbiB0aGUgbWlkZGxlIG9mIGFsbCB0aGUgb3RoZXIgVExW
cw0KIHdvdWxkIGJlIGNvbnN0cmFpbmluZy4gTWFraW5nIGFsbCBpbnRlbmRlZCB0byBiZSBtdXRh
YmxlIGJ5IHRoaXMgcHJvdG9jb2wgVExWcyBpbiB0aGUgcHJvdG9jb2wgc3BlY2lmaWMgc3BhY2Ug
aXMgcHJvYmFibHkgdGhlIGxlYXN0IGJhZCBpZGVhLCBhcyB0aGF0IGNvdWxkIGJlIGdlbmVyYWxp
c2VkIChlaXRoZXIgbWFraW5nIHRoYXQgc3BhY2Ugbm90IGNvdmVyZWQgYnkgdGhpcyBoeXBvdGhl
dGljYWwgNzE4MiB2YXJpYW50LCBvciBzcGxpdHRpbmcNCiBpdCkuPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgcG9zaXRpb24g
b24gdGhhdCB3b3VsZCBiZSDigJxuZXZlciBjaGFuZ2UgdGhlIHN0cnVjdHVyZSBvZiB0aGUgbWVz
c2FnZSBpbiB0cmFuc2l04oCdIGFuZCDigJxuZXZlciBjaGFuZ2UgdGhlIGxlbmd0aCBvbiBhIFRM
ViBpbiB0cmFuc2l04oCdLCBhbmQgeW914oCZZCBoYXZlIGRvbmUgYSBmYWlybHkgZ29vZCBqb2Ig
b2YgbWFraW5nIGl0IHBvc3NpYmxlIHRvIGRvICpzb21ldGhpbmcqIGNsZXZlciBmb3IgSUNWczog
dGhlIG11dGF0aW5nDQogZmllbGQsIHdoaWNoIHdvdWxkIGJlIGluIGEgZml4ZWQgcG9zaXRpb24g
aW4gdGhlIGJ5dGUgc3RyZWFtLCB5b3UgY291bGQgemVybyB0aGF0IG91dCwgb3IgZG8gc29tZXRo
aW5nIGVsc2UuIDcxODIgZG9lcyBub3QgZG8gdGhhdC4gQnV0IHNvbWV0aGluZyBlbHNlIG1pZ2h0
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5O
b3QgaGF2aW5nIHRoYXQgY29uc3RyYWludCBtZWFucyB0aGF0IOKAnHNvbWV0aGluZyBlbHNl4oCd
IHdvdWxkIGJlIGltcG9zc2libGUsIHdvdWxkIGltcGVkZSBvbiBleHRlbnNpYmlsaXR5LjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy
Pg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhdCBsZWF2ZXMgaG9wIGNvdW50
L2xpbWl0LiBUZWNobmljYWxseSB5b3Ugd291bGRu4oCZdCBpbmNyZW1lbnQvZGVjcmVtZW50LCBh
cyBpdOKAmXMgYSBuZXcgbWVzc2FnZS4gQnV0IHlvdSBjYW4gc2VuZCBhbnkgaG9wIGxpbWl0IG9u
IGFueSBuZXcgbWVzc2FnZSwgc28gdGhhdA0KIGNvdWxkIGJlIG9uZSBsZXNzIHRoYW4gdGhlIG9u
ZSB5b3UgcmVjZWl2ZWQuIEhvcCBjb3VudCBpcyBhIGJpdCBtb3JlIGFyZ3VhYmxlLiBJ4oCZbSBu
b3Qgc3VyZSBob3cgY2xlYXJseSBpdHMgbWVhbmluZyBpcyBpbmRpY2F0ZWQsIHdoZXRoZXIgaXQg
aXMgYSDigJxyZWFs4oCdIGhvcCBjb3VudCBvZiB0aGlzIG1lc3NhZ2UuIEJ1dCBpZiB5b3UgbmVl
ZGVkIHRvIEkgd291bGRu4oCZdCBiZSB0b28gc3Ryb25nbHkgYWdhaW5zdCBkb2luZyB3aGF0IGxv
b2tzIGxpa2UNCiBpbmNyZW1lbnRpbmcgdGhhdCwgYXMgbG9uZyBhcyBjYXJlZnVsbHkgZXhwbGFp
bmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPlllcywgSSBhZ3JlZSB0aGF0IHRoYXQgY2FuIGJlIGFyZ3VhYmxlLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ2FpbiwgaGVy
ZSBteSBwb3NpdGlvbiBpczogaWYgeW91IGNoYW5nZSB0aGUgc2xpZ2h0ZXN0IGluIHRoZSAqc3Ry
dWN0dXJlKiBvZiB0aGUgbWVzc2FnZSwgdGhlbiBhIGhvcC1jb3VudCBpbmNyZW1lbnQgd291bGQg
YmUgaW52YWxpZCAoaWxsZWdhbD8gOykgKSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGljaCBpcyB0byBzYXk6IHJlZ2VuZXJhdGlv
biA9Jmd0OyBkb27igJl0IHVzZSBob3AtY291bnQvaG9wLWxpbWl0IChpbiBteSBvcGluaW9uKS48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N
Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KEEga2V5IHF1ZXN0
aW9uIGlzIGlmIHlvdSB1c2UgNTQ5NyBUTFZzLiBJbiB0aGF0IGNhc2UgSSB0aGluayAtIGNvbWJp
bmVkIHdpdGggdGhlIOKAnG9ubHkgY2hhbmdlIG9uZSB0aGluZyBhYm92ZeKAnSB0aGF0IHlvdSBu
ZWVkIHRvIGFwcGVhciB0byBpbmNyZW1lbnQgaG9wIGxpbWl0LA0KIGkuZS4gY3JlYXRlIGEgbmV3
IG1lc3NhZ2Ugd2l0aCBhIG5vbi16ZXJvIGhvcCBjb3VudC48L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmRlZWQsIGdvb2QgY2F0
Y2guIFRoaXMgZG9jdW1lbnQgZG9lcywgaW5kZWVkLCBjaXRlIFJGQzU0OTcgbm9ybWF0aXZlbHku
IEnigJlkIG5vdCBzZWVuIHRoYXQgaW50ZXJhY3Rpb24sIGJ1dCB5b3UgYXJlIHJpZ2h0IGl0IGhh
cyB0byBiZSBtYXRjaGVkIHVwLiBJ4oCZdmUgbm90IGNoZWNrZWQgdGhhdC9pZiBpdCBpcy48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhv
bWFzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMDA3RTdFIj4tLTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5p
b3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu
Y2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQy
MTk0ICZuYnNwO3wgJm5ic3A7PGI+RTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+PC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0
ZW1zLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lz
dGVtcy5jb208L3NwYW4+PC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBU
ZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48
YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48L3NwYW4+PG86
cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl
IExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3
NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxk
Zm9yZCwgU3VycmV5LCBHVTIgN1lQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk
aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48
c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYW5ldA0KIFs8YSBocmVmPSJtYWlsdG86bWFuZXQtYm91
bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOm1hbmV0LWJv
dW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5UaG9tYXMgQ2xhdXNlbjxicj4NCjxiPlNlbnQ6
PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4yMCBB
cHJpbCAyMDE2IDEwOjU1PGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Mb3R0ZSBTdGVlbmJyaW5rPGJyPg0KPGI+Q2M6PC9iPjxz
cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Nb2JpbGUgQWQg
SG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNz
PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bbWFuZXRdIE9uIEZvcndhcmRp
bmctYW5kLXJlZ2VuZXJhdGlvbiAod2FzOiBSZTogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMg
cmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcyk8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBi
bGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3Jv
dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNl
bnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZTtiYWNr
Z3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFs
IGluaXRpYWwiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+
VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVp
dGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2Vt
PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFu
eSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0K
PGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nPC9zcGFuPjwvZW0+PHNwYW4g
Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2k+PHN0
cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9z
cGFuPjwvaT48L3N0cm9uZz48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48aT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiZuYnNwOzwvc3Bhbj48L2k+
PC9zcGFuPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPnRoYXQN
CiB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrPC9zcGFu
PjwvZW0+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGk+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4mbmJzcDs8L3NwYW4+PC9pPjwvc3Bhbj48ZW0+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YSBocmVmPSJodHRwOi8v
aW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRz
L0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmhl
cmU8L3NwYW4+PC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlz
IHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3c8L3NwYW4+PC9lbT48c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRw
Oi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGln
aHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIj48
c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50aGlzDQogcHJvY2Vzczwvc3Bhbj48L2E+Ljwvc3Bh
bj48L2VtPjwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MS4wcHQg
NC4wcHQgMS4wcHQgNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIg
c3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KjxzdHJvbmc+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPioq
PC9zcGFuPjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxiPiZu
YnNwOzwvYj48L3NwYW4+PC9zcGFuPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
V0FSTklORzwvc3Bhbj48L3N0cm9uZz48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9iPjwvc3Bhbj48
c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij4qKio8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RVhURVJOQUwgRU1B
SUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRp
b248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4uPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5M
b3R0ZSwgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+T24gMTkgTWFyIDIwMTYsIGF0IDEyOjM0LCBMb3R0ZSBTdGVlbmJyaW5rICZsdDs8YSBocmVm
PSJtYWlsdG86bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4uZGUiPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRlPC9zcGFuPjwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+SGkgVGhvbWFzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYW5rIHlvdSBmb3IgcmV2aWV3aW5nIEFPRFZ2MiB5ZXQg
YWdhaW4gOikgU29tZSBhbnN3ZXJzIGJlbG93OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
QW0gMTcuMDMuMjAxNiB1bSAxNzowMCBzY2hyaWViPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppZXRmQHRob21hc2NsYXVzZW4u
b3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZXRmQHRob21hc2NsYXVzZW4ub3JnPC9z
cGFuPjwvYT46PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkFwb2xvZ2llcyBmb3Igbm90IGhhdmluZyBnb3R0ZW4gdGhpcyBkb25lIHNvb25lciAtIGRheS1q
b2IgbGVhdmluZyBmZXcgc3BhcmUgY3ljbGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
4oCZdmUgcHJldmlvdXNseSBvZmZlcmVkIHJldmlld3MgYW5kIGNvbW1lbnRzLCBhbmQgc29tZSBv
ZiB0aG9zZSBoYXZlIGJlZW4gYWRkcmVzc2VkIGluIHRoZSBsYXRlc3QgSS1EIOKAlCBvdGhlcnMg
aGF2ZSBub3QsIGJ1dCBzaG91bGQgYmUuIEkgcmVjYWxsIHRoYXQgdGhlcmUgd2FzIHNvbWUgbWFp
bCBhdHRlbXB0aW5nIHRvIHJlYnV0IHBhcnRzIG9mIHRoZSByZXZpZXcsIGFuZCBJIHdpbGwgZGln
IGl0IG91dCBhbmQNCiByZXBseSB0byB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHdvbGQg
YmUgZ3JlYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SSBhbSBmaW5kaW5nIGEgYml0IG9mIHRpbWUgaGVyZSBhbmQgdGhlcmUgd2hl
biB0aGVyZSBhcmUgaG9sZXMgaW4gdGhlIGFnZW5kYSwgYW5kIGFtIChhcyB5b3UgbGlrZWx5IGhh
dmUgbm90aWNlZCkgYmFja3RyYWNraW5nIHRocm91Z2ggZW1haWxzIHdoZW4gSSBnZXQgYSBjaGFu
Y2UuIEFwb2xvZ2llcywgSSBob3BlIHRoYXQgSSB3aWxsIGdldCB0byB0aGVzZSBlbWFpbHMgdGhp
cywgb3IgbmV4dCB3ZWVrLCBidXQNCiBkYXktam9iIGVhdHMgaW4gdG8gdGhlIGF2YWlsYWJsZSB0
aW1lIDsoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxiPjx1PkZvcndhcmRpbmctdnMtcmVnZW5lcmF0aW9uPC91PjwvYj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlJlY2VudCBleGNoYW5nZXMgb24gdGhlIGxpc3QgbWFkZSBtZSB1bmRlcnN0YW5kIHRoYXQg
cHJvdG9jb2wgY29udHJvbCBtZXNzYWdlcyBhcmUgKm5vdCogZm9yd2FyZGVkLCBidXQgYXJlIGNv
bnN1bWVkIGF0IGVhY2ggaG9wLCB0aGVuIGEgbmV3IG1lc3NhZ2Ugd2l0aCAoYWxtb3N0LWJ1dC1u
b3QtcXVpdGUpIHRoZSBzYW1lIGNvbnRlbnQgaXMgZ2VuZXJhdGVkIGFuZCB0cmFuc21pdHRlZC48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlRoYXTigJlzIHdoYXQgd2XigJl2ZSBiZWVuIHRyeWluZyB0byBzYXkgYWxsIGFsb25nISBJ4oCZ
bSByZWFsbHkgZ2xhZCB3ZeKAmXJlIGhhdmluZyB0aGlzIGNvbnZlcnNhdGlvbi48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVuLCBsZXQgdXMgaGF2ZSBpdCAt
LSBpdCdzIGEgY2VudHJhbCBwb2ludCB0byBnZXQgcmlnaHQuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+
DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHRo
b3VnaHQgc29tZSBtb3JlIG9uIHRoaXMgKCZhbXA7IHJlYWQgc29tZSBvZiB0aGUgZXhjaGFuZ2Vz
IG9uIHRoZSBsaXN0IG9uIHRoaXMgdG9waWMgYnkgQ2hyaXMsIFVscmljaCwgYW5kIG90aGVycyks
IGFuZCBJIGFtIGNvbnZpbmNlZCB0aGF0IHRoaXMgaXMgbm90IHRoZSByaWdodCB3YXkgdG8gZ28s
Jm5ic3A7PGI+YXQgbGVhc3Q8L2I+Jm5ic3A7Zm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczo8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBw
bGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk
LXNwYWNlIj4mbmJzcDs8L3NwYW4+bzxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxz
cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5JdCByZW5k
ZXJzIHRoZSBob3AtbGltaXQvaG9wLWNvdW50IGZpZWxkcyBpbiB0aGUgUkZDNTQ0NA0KIG1lc3Nh
Z2UgaGVhZGVyIHVzZWxlc3MuPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1z
cGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRoaXMgd291bGQgbm90IGJlIGJhZCBpZiB0aGUg
ZnVuY3Rpb25hbGl0eSBvZmZlcmVkIGJ5IHRob3NlIGZpZWxkcyB3YXMgbm90IHVzZWZ1bDxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu
PuKAlCBzYWRseSwgaXQgaXMuIEZvciBleGFtcGxlLCBmb3Igc2NvcGUgbGltaXRlZCBmbG9vZGlu
ZyAoZXhwYW5kaW5nIHJpbmcgc2VhcmNoLCBhbmQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNz
PSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNs
YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5zdWNoKSB3aGljaCBtYXkg
YmUgb2YgaW50ZXJlc3QsIGFuZCB3aGljaCByZXF1aXJlIGhvcC1saW1pdC4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5B
IGhvcC1jb3VudCBmaWVsZCBtYXkgYWxzbyBwcm92aWRlIGEg4oCcY2hlYXDigJ0gKGluIHRlcm1z
IG9mIG92ZXJoZWFkKSBhZGRpdGlvbmFsIHBpZWNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBw
bGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0i
YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+b2YgaW5mb3JtYXRpb24gdG8gdXNl
IGNvbmp1bmN0aXZlbHkgd2l0aCBhIOKAnHJlYWzigJ0gbWV0cmljLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5JIGFncmVlIG9uIHRoZSB1c2VmdWxuZXNzLCB3aGljaCBpcyB3aHkgd2Ugd2VyZSBwdXp6bGVk
IHdoZW4gd2Ugd2VyZSB0b2xkIHdlIHdlcmVu4oCZdCBhbGxvd2VkIHRvIHVzZSB0aG9zZSBmaWVs
ZHMgKG9yLCByYXRoZXIsIHRoYXQgd2Ugd2VyZSB1c2luZyB0aGVtIHdyb25nLCBidXQgdGhhdCB0
aGUgcmlnaHQgd2F5IHRvIHVzZSB0aGVtIGRvZXNu4oCZdCB3b3JrIGZvciBBT0R2djIpLiBJIGJl
bGlldmUgVmlja3kgaGFzDQogd3JpdHRlbiBhYm91dCB0aGlzIGluIG1vcmUgZGV0YWlsIGluIHBy
ZXZpb3VzIGRpc2N1c3Npb25zLCBhbmQgd2Ugd2VyZS9hcmUgbG9va2luZyBmb3J3YXJkIHRvIHJl
YWRpbmcgeW91ciBhbnN3ZXJzLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+U28sIHRoZSBzb3VyY2UgZ2VuZXJhdGVzIGEgbWVzc2FnZSwgdGhlIG1lc3NhZ2Ug
aXMgZm9yd2FyZGVkIHRocm91Z2ggdGhlIG5ldHdvcmssIHdpdGggZWFjaCBpbnRlcm1lZGlhdGUg
cm91dGVyIGRlY3JlbWVudGluZyB0aGUgaG9wIGxpbWl0IGFuZCBpbmNyZW1lbnRpbmcgdGhlIGhv
cCBjb3VudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgc3RhdGVkIGluIHRoZSA1NDQ0
LVVzYWdlIGRvY3VtZW50LCB3aGVuIGZvcndhcmRpbmcgYSBtZXNzYWdlLCB0aGUgaG9wLWxpbWl0
L2hvcC1jb3VudCBhcmUgbW9kaWZpZWQsIHRoZSByZXN0IG9mIHRoZSBtZXNzYWdlIFNIT1VMRCBu
b3QgYmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgaXMgc3BlY2lmaWNh
bGx5LCBvbmUgdGhpbmcgd2hlcmUgSSBraW5kYSB3b3VsZCBsaWtlIDU0NDQtdXNhZ2UgdG8gZ28g
ZnVydGhlciBpcyAmcXVvdDt0aGUgbWVzc2FnZSBzdHJ1Y3R1cmUgTVVTVCBpbiBhbGwgY29uZGl0
aW9ucyBwcmVzZXJ2ZWQgd2hlbiBmb3J3YXJkaW5nJnF1b3Q7IC0gYnV0IHN0aWxsIHNheSAmcXVv
dDthbmQgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUgdmFsdWUgZmllbGQgb2YgVExWcyBhcmUg
YWxzbyBub3QNCiBtb2RpZmllZCZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hh
dCB0aGlzIGJ1eXMgaXMgc2V2ZXJhbCB0aGluZ3MsIGluIHRoZSBjb250ZXh0IG9mIHRoaXMgcHJv
dG9jb2w6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWIt
c3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj5vPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xh
c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmhvcC1saW1pdC9ob3AtY291
bnQgY291bGQgYmUgdXNlZnVsIGZvciB0aGUgdXN1YWwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNs
YXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFu
IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5wdXJwb3NlcyAoZW5z
dXJpbmcgdGhhdCBtZXNzYWdlcyBkbyBub3QgbGl2ZSBmb3JldmVyLCZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3Nw
YW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnNjb3Bl
LWxpbWl0ZWQgZmxvb2RpbmcsIC4uLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
Y2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm88c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw
YW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
Ozwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+
aWYgdGhlIGFjY3VtdWxhdGVkIHBhdGggbWV0cmljIGlzIHN0b3JlZCBpbiBhIFRMViB2YWx1ZQ0K
IGZpZWxkLCB0aGF0Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4i
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy
dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+dmFsdWUgZmllbGQgY2FuICh3aXRoIHN1aXRhYmxlIGRp
c2NsYWltZXIgdG8gY2FsbCBvdXQgJnF1b3Q7d2Uga25vdyBpdCBpczxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
Y2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNw
YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJFQ09NTUVOREVE
IHRvIG5vdCBkbyB0aGlzLCBidXQgaGVyZSdzIHdoeSB3ZSBhcmUgT0sgaW4gZG9pbmc8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5p
dCBhbnl3YXlzJnF1b3Q7KSBiZSBtb2RpZmllZCB3aGVuIGZvcndhcmRpbmcgdGhlIG1lc3NhZ2Us
IGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw
YW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+bzxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNz
PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5hcyB0aGF0IHBhdGggbWV0cmlj
IGZpZWxkIGlzIGluIGEgbWVzc2FnZSB3aG9zZSBzdHJ1Y3R1cmUNCiBkb2VzIG5vdDxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8
L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmNo
YW5nZSwgaXQgd2lsbCBiZSAmcXVvdDthdCB0aGUgc2FtZSBwbGFjZSBpbiB0aGUgYnl0ZS1zdHJl
YW0mcXVvdDsgYXQgZWFjaCBob3AsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw
YW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29u
dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+d2hpY2g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJh
cHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWIt
c3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj5vPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xh
c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmFsbG93cyB1c2VmdWwgdGhp
bmdzIHN1Y2ggYXMgZGVyaXZpbmcgZnJvbSBSRkM3MTgyIGEgZm9ybQ0KIG9mPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bh
bj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+JnF1b3Q7
d2hlbiBjYWxjdWxhdGluZyB0aGUgSUNWLCB6ZXJvIG91dCB0aGF0IGZpZWxkIGluIHRoZSBtZXNz
YWdlICcgd2hlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+Jm5ic3A7PC9zcGFuPiZuYnNwOyB2YWxpZGF0aW5nIGFuIElDViwgYWxzbyB6ZXJvIG91dCB0
aGF0IGZpZWxkJnF1b3Q7IC0tIHdoaWNoIGdvZXMgb25lIHN0ZXA8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNs
YXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFu
IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbmJzcDsgZnVydGhl
ciAod2hlbiBjb3VwbGVkIHdpdGggYSB0aW1lIHN0YW1wKSB0aGFuIHNpbXBsZSB0cmFuc2l0aXZl
IHRydXN0LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+Jm5ic3A7PC9zcGFuPiZuYnNwOyBidXQgYWxzbzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBj
bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+bzxzcGFuIGNsYXNzPSJh
cHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj5hbGxvd3MgZXZlbiBtb3JlIGZhbmN5IGFuZCB1c2VmdWwgKGFsYmVpdCBleHBl
cmltZW50YWwpDQogdGhpbmdzIHN1Y2g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWIt
c3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5hcyBhZ2dyZWdhdGUgc2lnbmF0dXJlcyB0byB3
b3JrIGNvcnJlY3RseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnVydGhlcm1vcmUuLi4u
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj5UaGUgb25seSBwcmFjdGljYWwgc29sdXRpb24gd291bGQgYmUgdG8gcmUtaW50cm9k
dWNlIHRoZXNlIGZ1bmN0aW9ucyBieSB3YXkgb2YgaW5zZXJ0aW5nIGE8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxz
cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5NZXNzYWdlVExW
IOKAlCB3aGljaCAoaSkgaXMgbm90IHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50LCBhbmQgKGlp
KSB3aGljaCB3b3VsZCBqdXN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4i
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy
dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+c2VydmUgdG8gcmVuZGVyIG1lc3NhZ2VzIGJpZ2dlciB0
aGFuIHN0cmljdGx5IG5lZWRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV4YWN0bHk7IHdl4oCZZCByZWFsbHkgbGlrZSB0byBhdm9p
ZCB0aGlzIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4uLi4gSXQgYXZvaWRzIHRoZSBhYm92ZSwgYW5kLi4uLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy
Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPlNjb3BlIGxpbWl0ZWQgZmxvb2RpbmcgJm5ic3A7ZG9lcyBzZWVtIHRvIGJlIGEgbmVjZXNz
YXJ5IHJlcXVpcmVtZW50LCBpZiBmb3Igbm88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10
YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5vdGhlciByZWFzb24gdGhhbiB0byBwcmV2
ZW50IGluZm9ybWF0aW9uIGZyb20g4oCcY2lyY3VsYXRpbmcgZm9yZXZlciBpbiB0aGUgbmV0d29y
a+KAnS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkFPRFZ2MuKAmXMgZHVwbGljYXRlZCBkZXRlY3Rpb24gaG9wZWZ1bGx5IHNob3VsZCB0
YWtlIGNhcmUgb2YgdGhhdC4gSWlyYywgV2UgaW50ZXJwcmV0ZWQgeW91ciBlYXJsaWVyIEUtTWFp
bHMgdG8gKGltcGxpY2l0bHkpIG1lYW4gdGhhdCB5b3UgdGhpbmsgd2Ugc2hvdWxkIHJlbHkgb24g
dGhhdCwgc2luY2UgeW91IHNhaWQgd2UgY2Fu4oCZdCB1c2UgdGhlIGhvcC1saW1pdC9ob3AtY291
bnQgZmllbGRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Li4uLmlmIGRvbmUgKHByb3BlciBmb3J3YXJkaW5nIHdpdGggcHJlc2VydmF0aW9uIG9mIHRoZSBz
dHJ1Y3R1cmUsIHJhdGhlciB0aGFuIHJlZ2VuZXJhdGlvbiB3aGljaCBvcGVucyB1cCB0aGUgJnF1
b3Q7dGhpcyBpcyBhIG5ldyBtZXNzYWdlIHdpdGggcG90ZW50aWFsbHkgbmV3IHN0cnVjdHVyZSZx
dW90OyBjYW4gb2Ygd29ybXMpIGFzIEkgZGVzY3JpYmUsIGFsc28gYWRkcmVzc2VzIHRoZSBhYm92
ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2l0aCByZXNwZWN0IHRvIHdoYXQgSSBzYWlk
IGVhcmxpZXIgd2hlbiBJIHNhaWQgJnF1b3Q7Y2FuJ3QgdXNlIGhvcC1saW1pdC9ob3AtY291bnQg
ZmllbGRzJnF1b3Q7Li4uLndoZW4geW91IHJlZ2VuZXJhdGUsIHlvdSBhYnNvbHV0ZWx5LCBkZWZp
bml0ZWx5LCBjYW4ndC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hl
biB5b3UgJnF1b3Q7cmVnZW5lcmF0ZSZxdW90OyBhIG1lc3NhZ2UsIHRoYXQgbWVhbnMgJnF1b3Q7
eW91IGNvbnN0cnVjdCBhIGJyYW5kIG5ldyBtZXNzYWdlJnF1b3Q7IHdoaWNoIG1heSBzaHVmZmxl
IGFkZHJlc3NlcyBpbnNpZGUgYWRkcmVzcyBibG9ja3MsIG9yIGJldHdlZW4gYWRkcmVzcyBibG9j
a3MsIHNodWZmbGUgVExWcyBkaWZmZXJlbnRseSB0aGFuIHRoZXkgd2VyZSBvcmlnaW5hbGx5LCBl
dmVuIHVzZSBUTFZzIG9mIGRpZmZlcmVudA0KIHN0cnVjdHVyZSAoZS5nLiwgc2luZ2xlLXZhbHVl
IFRMVnMgaW5zdGVhZCBvZiBtdWx0aS12YWx1ZSBUTFZzKS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N
Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBtZWFucyB0aGF0IHNvbWUgYXNzdW1wdGlvbnMg
KHN1Y2ggYXMgd2hlbiBwcm9kdWNpbmcgYW4gSUNWIGZvciB0aGUgbWVzc2FnZSwgd2hpY2ggZGVw
ZW5kcyBvbiB0aGUgYnl0ZSBvcmRlcikgZG9uJ3QgaG9sZC4gV2VsbCwgdGhleSBtYXkgbm90IGhv
bGQsIHNvIHRoYXQgbWVhbnMgd2UgY2FuJ3QgYXNzdW1lIHRoYXQgdGhleSBkby4gV2hpY2ggbWVh
bnMgdGhhdCB0aGUgb3JpZ2luYXRvciBvZiBhIG1lc3NhZ2UNCiBjYW5ub3QgZ2VuZXJhdGUgYW4g
SUNWIHRoYXQgY2FuIGJlIGNvcnJlY3RseSBpbnRlcnByZXRlZCAod2hpY2ggaXMgd2hhdCBteSBu
ZXh0IHNlY3Rpb24gaW4gbXkgb3JpZ2luYWwgbWFpbCB3YXMgYWJvdXQpLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy
Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGljaCBtZWFucywgaW4gY29uY2x1c2lvbiwgJm5i
c3A7dGhhdCB0aGUgaW5mb3JtYXRpb24gaW4gdGhlIG1lc3NhZ2UgcHJvZm91bmRseSBjaGFuZ2Ug
LS0gYW5kIHRoZXJlZm9yZSB0aGVzZSBob3AtY291bnQvaG9wLWxpbWl0IHZhbHVlcyBkbyBub3Qg
ZXZlbiBhcHBseSB0byAmcXVvdDt0aGUgaW5mb3JtYXRpb24mcXVvdDsuJm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXImbmJzcDtpZiBwcm9wZXIgZm9y
d2FyZGluZyB3aXRoIHByZXNlcnZhdGlvbiBvZiB0aGUgc3RydWN0dXJlLCByYXRoZXIgdGhhbiBy
ZWdlbmVyYXRpb24gd2hpY2ggb3BlbnMgdXAgdGhlICZxdW90O3RoaXMgaXMgYSBuZXcgbWVzc2Fn
ZSB3aXRoIHBvdGVudGlhbGx5IG5ldyBzdHJ1Y3R1cmUmcXVvdDsgY2FuIG9mIHdvcm1zLCBhcyBJ
ICgmYW1wOyBVbHJpY2ggJmFtcDsgb3RoZXJzKSBoYXZlIHN1Z2dlc3RlZCwgaXMgdGFrZW4gdG8g
aGVhcnQsDQogaXQgYWxzbyBhZGRyZXNzZXMgdGhlIGlzc3VlIGJlbG93IHJlZ2FyZGluZyBlbmQt
dG8tZW5kIGF1dGhlbnRpY2F0aW9uICh3aGljaCwgd2hpbGUgc3RpbGwgaGFyZCwgaXMgcG9zc2li
bGUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGNvdXBsZSBvZiBt
b3JlIGNvbW1lbnRzIGJlbG93PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFz
cz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29u
dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+bzxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9z
cGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj48
dT5JdCBtYWtlcyBlbmQtdG8tZW5kIGF1dGhlbnRpY2F0aW9uIHVubmVjZXNzYXJpbHkNCiBoYXJk
LjwvdT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+SSB0aGluayBDaHJpcyBjYWxsZWQgdGhpcyBvdXQgYWxyZWFkeSwgYnV0
IGl0IGJlYXJzIHJlcGVhdGluZzogUyBnZW5lcmF0ZXMgYSBtZXNzYWdlJm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwv
c3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+KHNh
eSwgYSBSUkVRKSwgYW5kIGluY2x1ZGVzIGFuIElDViBjYWxjdWxhdGVkIG92ZXIgdGhlIGNvbnRl
bnQgb2YgdGhlIG1lc3NhZ2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4i
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy
dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Rm9yIGFueSByZWNpcGllbnQgdG8gYmUgYWJsZSB0byB2
YWxpZGF0ZSB0aGUgSUNWLCB0aGUgbWVzc2FnZSBoYXMgdG8gYmUgZXhhY3RseTxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3Nw
YW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnRoZSBz
YW1lIOKAlCBub3QganVzdCBpbiBjb250ZW50LCBidXQgaW4gc3RydWN0dXJlIOKAlCBhcyB3aGF0
IHdhcyBnZW5lcmF0ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJh
cHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNz
PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj7igJxSZWdlbmVyYXRpbmfigJ0g
cmF0aGVyIHRoYW4g4oCcZm9yd2FyZGluZ+KAnSBtZXNzYWdlcyBtZWFucywgdGhhdCB0aGUgaW50
ZXJtZWRpYXRlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+cm91dGVyIOKAnHJlZ2VuZXJhdGluZ+KAnSB0aGUgUlJFUSBtYXkgY2hv
c2UgYSBkaWZmZXJlbnQgc3RydWN0dXJlIChlLmcuLCBpbmNsdWRlIFRMVnM8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFu
PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5pbiBhIGRp
ZmZlcmVudCBvcmRlcikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJh
cHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNz
PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaGUgcHJvcG9zYWwgZnJvbSZu
YnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wZXJraW5zLW1h
bmV0LWFvZHYtZTJlc2VjLTAwIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMDwvc3Bh
bj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+aXMgdG8gYWRkIGNvbnN0cmFpbnRzIG9uIChpKSB0aGUgc2V0IG9mIGVsZW1l
bnRzIHRvIGluY2x1ZGUgaW4gYSBzaWduYXR1cmUgYW5kIChpaSkgdGhlPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48
c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+b3JkZXIgb2Yg
dGhlc2UgZWxlbWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJh
cHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNz
PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5PbmUmbmJzcDtwcm9ibGVtIHdp
dGggdGhhdCBhcHByb2FjaCBpcyAoaSk6IGlmIGFuIGV4dGVuc2lvbiBhZGRzIGEgbWVzc2FnZSBU
TFYsIG9yIGFuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk
LXNwYWNlIj4mbmJzcDs8L3NwYW4+QWRkcmVzcyBUTFYsIHRvIGEgbWVzc2FnZSwgdGhlbiB0aGF0
IHdpbGwgbm90IGJlIOKAnGNvdmVyZWTigJ0gYnkgdGhlIHByb3Bvc2VkIGUyZXNlYyBUTFYuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw
YW4+UmF0aGVyIGZvciAqZWFjaCogZXh0ZW5zaW9uIGRldmVsb3BlZCwgYW4g4oCcdXBkYXRlcyBl
MmVzZWPigJ0gY2xhdXNlIG5lZWRzIHRvIGJlIGRvbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5J
4oCZZCBzYXkgdGhhdCB0aGlzIGFwcHJvYWNoIHdvdWxkIGJlIHByb25lIHRvIGVycm9ycyDigJQg
YW5kIGFkZCBlbnRyb3B5IHRvIHRoZSBwcm9jZXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBw
bGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0i
YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+b2YgZGVzaWduaW5nIHByb3RvY29s
IGV4dGVuc2lvbnMuIFRoZSBhbHRlcm5hdGl2ZSwgYSBtZXNzYWdlIGJlaW5nIGdlbmVyYXRlZCBi
eSB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj5zb3VyY2UgYW5kICpmb3J3YXJkZWQqIChhcyB3ZSBkbyBpbiBPTFNSdjIsIGZv
ciBleGFtcGxlKSB3b3VsZCBhbGxvdyBJQ1YgVExWcyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh
c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4g
Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPihldmVuLCBhbGxvdyBy
ZXVzZSBvZiB0aG9zZSBzcGVjaWZpZWQgZm9yIE9MU1J2MikgZm9yIGNvdmVyaW5nIGEgbWVzc2Fn
ZSBhbmQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPiZuYnNwOzwvc3Bhbj5leHRlbnNpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bh
bj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+4oCcQnV0
IHdoYXQgYWJvdXQgdGhlIG1ldHJpY3MgdmFsdWUgd2hpY2ggd2lsbCBjaGFuZ2Ugb24gZWFjaCBo
b3DigJ0sIHlvdSBtYXkgc2F5PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFu
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkZvcnR1bmF0ZWx5LCB0aGF0IGlzIHJlbGF0aXZlbHkg
ZWFzeSB0byBoYW5kbGU6IHNpbXBseSB6ZXJvIG91dCB0aGUgdmFsdWUgb2YgdGhhdCBUTFYgd2hl
bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7
PC9zcGFuPmdlbmVyYXRpbmcgb3IgdmVyaWZ5aW5nIHRoZSBJQ1YgTWVzc2FnZVRMVi4gQW5kIHVz
ZSBQYWNrZXQtVExWcyBmb3IgaG9wLWJ5LWhvcCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9
ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xh
c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmF1dGhlbnRpY2F0aW9uLCBp
ZiBuZWVkZWQgKGJ1dCwgc2VlIGJlbG93KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm88c3BhbiBjbGFzcz0iYXBwbGUtdGFi
LXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw
YW4+PGI+PHU+SXQgcHJldmVudHMgdGhlIHVzZSBvZiBtb3JlIGNsZXZlci9hZHZhbmNlZCBzaWdu
YXR1cmUNCiBzY2hlbWVzL0lDVnM8L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxl
LXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkFnZ3JlZ2F0ZSBzaWduYXR1cmUgYWxn
b3JpdGhtcyAoJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9jcnlwdG8uc3RhbmZvcmQuZWR1L35kYWJv
L3BhcGVycy9hZ2dzdXJ2ZXkucGRmIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczov
L2NyeXB0by5zdGFuZm9yZC5lZHUvfmRhYm8vcGFwZXJzL2FnZ3N1cnZleS5wZGY8L3NwYW4+PC9h
Pik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj5leGlzdCwgYW5kIGFuIGludGVyZXN0aW5nIHVzZS1jYXNlIGNhbiBiZSBmb3VuZCBp
biBhbHNvIHJlYWN0aXZlIHByb3RvY29scywgYWxsb3dpbmcgdmVyaWZ5aW5nPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bh
bj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+bm90IOKA
nGp1c3TigJ0gdGhlIGVuZCBwb2ludHMsIGJ1dCBhbHNvIHRoZSBpbnRlcm1lZGlhcmllcyAoYWdh
aW4sIHdpdGggdGhlIGFwcHJvcHJpYXRlIOKAnHplcm8gb3V04oCdPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBj
bGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3Bh
biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ZGlzY3Vzc2VkIGFi
b3ZlLCBvciBzb21ldGhpbmcgc21hcnRlcikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUt
dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmVnZW5lcmF0aW9uIG9mIG1lc3NhZ2Vz
LCByYXRoZXIgdGhhbiBmb3J3YXJkaW5nLCByZW5kZXJzIHRoYXQgaW1wb3NzaWJsZSAob3IsIGlm
IHVzZWQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+dXBkYXRpbmcgdG8gJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LXBlcmtpbnMtbWFuZXQtYW9kdi1lMmVzZWMtMDAiPjxzcGFuIHN0eWxl
PSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wZXJraW5z
LW1hbmV0LWFvZHYtZTJlc2VjLTAwPC9zcGFuPjwvYT4pPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlRoZXJlIGFyZSBvdGhlciByZWFzb25zLCBidXQgdGhlIGFib3ZlIGFyZSB0aG9zZSB0aGF0
IGp1bXAgYXQgbWUgYXMgaW1tZWRpYXRlIHNob3ctc3RvcHBlcnMuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkkgZG8gaG9uZXN0bHkgbm90IHNlZSB3aGF0IHBvc3NpYmxlIGJlbmVmaXQgdGhl
cmUgaXMgZnJvbSDigJxyZWdlbmVyYXRpb27igJ0g4oCUIGJ1dCBJIHNlZSB2ZXJ5IGNsZWFyIGlu
Y29udmVuaWVuY2VzLCBhbmQgc2VjdXJpdHkgaXMgbm90IHRoZSBsZWFzdCBvZiB0aGVzZS4gSW5z
aXN0aW5nIG9uIOKAnHJlZ2VuZXJhdGlvbuKAnSByZXF1aXJlcyBkZXZlbG9wbWVudCBvZiDigJxu
b24tZ2VuZXJhbCB3b3JrYXJvdW5kc+KAnSBhcyBwb2ludGVkDQogb3V0IGFib3ZlLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHBv
c3NpYmxlIGJlbmVmaXQgaXMgdGhhdCB3ZSBuZWVkIHRvIGFjY3VtdWxhdGUgJmFtcDsgdHJhbnNw
b3J0IG1ldHJpYyB2YWx1ZXMgc29tZWhvdywgYW5kIHdlIGNhbuKAmXQgZG8gdGhhdCB3aXRob3V0
IHJlZ2VuZXJhdGluZyBhdCBsZWFzdCBwYXJ0cyBvZiB0aGUgbWVzc2FnZS48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklm
IHdl4oCZcmUgbWlzc2luZyBhIHNvbHV0aW9uIGhlcmUsIHBsZWFzZSBzaGFyZSBpdCB3aXRoIHVz
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9uZSBpbiB0
aGUgYWJvdmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48dT5TZWN1cml0eSBDb25z
aWRlcmF0aW9uczwvdT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0IGZvciBjb250ZXh04oCZcyBzYWtlLCBkaWQgeW91IHJl
dmlldyB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4mbmJzcDtkcmFmdC1pZXRmLW1hbmV0
LWFvZHZ2Mi0xMyBvciB0aGUgb25lcyBwcm9wb3NlZCBpbiB0aGUgdGhyZWFkIOKAnkFPRFZ2Mjog
U2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdXBkYXRl4oCcPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZGlkLiBJdCBzdGlsbCBpcyBhIGZhciBjcnkgZnJvbSBw
YXNzaW5nIHRoZSBiYXIuIEkndmUgcG9zdGVkIG9uIHdoeSBpbiB0aGUgcGFzdCwgYW5kIHNvbWUg
bW9yZSBpbiB0aGlzIG1haWwgKHdoaWNoIGFsc28gY29udGFpbnMgc29tZSBzdWdnZXN0aW9ucyku
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgc3VnZ2VzdCB0aGF0IHNldHRsaW5n
IHRoZSByZWFyY2hpdGVjdHVyaW5nIHRvIGRvIGZvcndhcmRpbmcsIGFzIEkgZGVzY3JpYmUgaW4g
dGhlIGFib3ZlLCBzaG91bGQgYmUgZG9uZSwgd2hpY2ggd291bGQgZWFzZSB0aGUgc2VjdXJpdHkg
Y29uc2lkZXJhdGlvbnMgaXNzdWUgY29uc2lkZXJhYmx5IChhbmQgd2hpY2ggd291bGQgYmUgbmVj
ZXNzYXJ5IGV2ZW4gaWYgaWdub3JpbmcgdGhlIHNlY3VyaXR5DQogY29uc2lkZXJhdGlvbnMsIElN
TywgZm9yIHRoaXMgZG9jIHRvIGdvIGFueXdoZXJlKS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi
cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+V2l0aCBhIG5ldyB2ZXJzaW9uIGNvdmVyaW5nIHRoYXQsIHRo
ZSBhdXRob3JzIChJIHdhbnRlZCB0byB3cml0ZSAmcXVvdDt5b3UmcXVvdDssIGJ1dCBkZWNpZGVk
IHRvIGJlIGluY2x1c2l2ZSkgY291bGQmbmJzcDt5b3UgZ28gbG9vayBhdCB0aGUgZGlmZmVyZW50
IHNlY3VyaXR5IGVtYWlscyBhbmQgcGVyaGFwcyBzdGFydCBhIHNlcGFyYXRlIHRocmVhZCBvbiB0
aGF0LCB0b3dhcmRzIGEgcmVzb2x1dGlvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaG9tYXM8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgYW4gYWx3YXlzIHRo
b3JueSBzdWJqZWN0LiBXaGVuIE9MU1J2MiB3YXMgZ29pbmcgdGhyb3VnaCB0aGUgcHJvY2VzcyB3
ZSBnb3QgYSB0aG9yb3VnaCBlZHVjYXRpb24gaW4gaG93IGxpdHRsZSB3ZSBrbmV3IGFib3V0IHNl
Y3VyaXR5IGZyb20gdGhlIFNFQy1BRHMsIGFuZCBoYWQgdG8gc3BlbmQgYWJvdXQgYSB5ZWFyIG9y
IHNvIGRldmVsb3BpbmcgUkZDNzE4My4gVGhlIGJvdHRvbSBsaW5lIGlzLCB0aGF0DQogdGhpcyBw
cm90b2NvbCBuZWVkcyBpdHMg4oCcUkZDNzE4MyAmbmJzcDtlcXVpdmFsZW504oCdLCBlaXRoZXIg
YXMgcGFydCBvZiB0aGUgbWFpbiBkb2N1bWVudCwgb3IgYXMgYW4gaW5kZXBlbmRlbnQgZG9jdW1l
bnQuIGN1cnJlbnRseSwgdGhhdCBpcyBub3QgdGhlIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkEgbWluaW1hLCBsb29raW5nIGF0IEJDUDcyIGFuZCBCQ1AxMDcg4oCUIHRha2luZyBp
bnNwaXJhdGlvbiBmcm9tIFJGQzcxODMgbWlnaHQgYmUgYXcgZ29vZCBpZGVhLCBhcyB0aGF0IHdh
cyB0aGUgbW9zdCByZWNlbnQgdGhhdCB3ZW50IHRocm91Z2ggdGhlIFNFQyBBRC4gUmVnYXJkbGVz
cyBvZiBob3csIGhvd2V2ZXIsIGEg4oCcbWFuZGF0b3J5IHRvIGltcGxlbWVudOKAnSBzZWN1cml0
eSBtZWNoYW5pc20gbW9zdCBiZSBzcGVjaWZpZWQNCiAoSSB0aGluayB0aGUgcmlnaHQgdGVybSB3
YXMg4oCcTVVTVCBpbXBsZW1lbnQsIFNIT1VMRCB1c2XigJ0pLCBpbiBzdWZmaWNpZW50IGRldGFp
bCB0byBlbnN1cmUgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgYW4gZXhhbXBs
ZSwgYm90aCBbUkZDNjEzMF0gYW5kIFtSRkM3MTgxXSBzZXQgb3V0IHRoYXQgdGhhdDo8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IE9uIHJlY2Vp
dmluZyBhIC4uLiBtZXNzYWdlLCBhIHJvdXRlciBNVVNUIGZpcnN0IGNoZWNrIGlmIHRoZTxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgbWVzc2FnZSBpcyBpbnZhbGlkIGZvciBwcm9jZXNz
aW5nIGJ5IHRoaXMgcm91dGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCB0aGVuIHBy
b2NlZWQgdG8gZ2l2ZSBhIG51bWJlciBvZiBjb25kaXRpb25zIHRoYXQsIGVhY2gsIHdpbGwgbGVh
ZCB0byBhIHJlamVjdGlvbiBvZiB0aGUgbWVzc2FnZSBhcyAmcXVvdDtiYWRseSBmb3JtZWQgYW5k
IHRoZXJlZm9yZSBpbnZhbGlkIGZvciBwcm9jZXNzaW5n4oCdIOKAlCBhIGxpc3Qgd2hpY2ggUkZD
NzE4MyB0aGVuIGFtZW5kZWQuIFRoYXQgZ2F2ZSBhIOKAnGhvb2vigJ0gZm9yIFJGQzcxODMgZm9y
IGluc2VydGluZw0KIOKAnHJlamVjdGlvbuKAnS4gSWRlbSBmb3IgbWVzc2FnZSBnZW5lcmF0aW9u
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBJIHdhcyB0byBkbyBSRkM3MTgxL1JGQzYx
MzAgdG9kYXksIEkgd291bGQgaW5jbHVkZSB0aGF0IGRpcmVjdGx5IGludG8gdGhlIHByb3RvY29s
IHNwZWNpZmljYXRpb25zLiBJdCB0dXJuZWQgb3V0IHRvIGJlIG1vcmUgb3ZlcmhlYWQgKGFuZCBz
bG93IGRvd24gcHVibGljYXRpb24gYW55d2F5cykgdG8gZG8gaXQgYXMgc2VwYXJhdGUgZG9jdW1l
bnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY29uZGx5LCB3ZSBuZWVk
IHRvIGJlIGEgbG90IG1vcmUgcmlnaWQgaW4gdGVybXMgb2Ygd2hhdCBJQ1ZzLCBUaW1lc3RhbXBz
LCBldGMuIGFyZSBhZGRlZC9yZW1vdmVkLCBhbmQgd2hhdCB0aGF0IGJyaW5ncy48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGV4YW1wbGUgKHdpdGggdGhlIGFzc3VtcHRpb24gdGhhdCBt
ZXNzYWdlcyBhcmUgKmZvcndhcmRlZCogYW5kICpub3QqIHJlZ2VuZXJhdGVkKSwgdGhpcyBjb3Vs
ZCBiZSBvbmUgb3B0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0i
YXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFz
cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+bzxzcGFuIGNsYXNzPSJhcHBs
ZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj5XaGVuIGEgUlJFUSwgUlJFUCBtZXNzYWdlIGlzIGdlbmVyYXRlZCwgYWRkDQogYW4g
SUNWIE1lc3NhZ2UgVExWLCB3aGljaCBpcyBjYWxjdWxhdGVkICZsdDt0aGlzIHdheSZndDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPiZuYnNwOzwvc3Bhbj4mbmJzcDvigKYodGFrZSBpbnNwaXJhdGlvbiBmcm9tIFJGQzcxODMg
aGVyZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1z
cGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm88c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4i
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwv
c3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2hl
biBhIFJSRVEsIFJSRVAgbWVzc2FnZSBpcyB0cmFuc21pdHRlZCAmbmJzcDsoYnkNCiB0aGUgc291
cmNlLCBvciBmb3J3YXJkZWQgYnkgYW4gaW50ZXJtZWRpYXJ5KTxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh
c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu
PmluIGFuIFJGQzU0NDQgcGFja2V0LCBhbiBJQ1YgUGFja2V0IFRMViBpcyBhZGRlZCB0byB0aGUg
cGFja2V0LCB3aGljaCBpcyBjYWxjdWxhdGVkICZsdDt0aGlzIHdheSZndDsg4oCmPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj5vPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xh
c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldoZW4gYW4gUkZDNTQ0NCBw
YWNrZXQgaXMgcmVjZWl2ZWQsIHZhbGlkYXRlDQogdGhlIElDViBQYWNrZXQgVExWICZsdDt0aGlz
IHdheSZndDsgYW5kIGlmIHRoZSBJQ1YgZG9lc27igJl0IHZhbGlkYXRlLDxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7
PC9zcGFuPmRpc2NhcmQgdGhlIGNvbnRhaW5lZCBtZXNzYWdlcy48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPm88c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2hlbiByZWNlaXZpbmcgYSBSUkVRL1JSRVAg
KGVpdGhlciBhcyBkZXN0aW5hdGlvbiwNCiBvciBhcyBhbiBpbnRlcm1lZGlhcnkpLCB2YWxpZGF0
ZSB0aGUgSUNWIE1lc3NhZ2UgVExWJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUt
dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48
c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0O3RoaXMg
d2F5Jmd0OyBhbmQgaWYgdGhlIElDViBkb2VzbuKAmXQgdmFsaWRhdGUsIGRpc2NhcmQgdGhlIG1l
c3NhZ2UsIGRvIG5vdCBwcm9jZXNzLCBkbyBub3QgZm9yd2FyZC48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+VGhpcyBpcyBhIGRpZmZlcmVudCAoYW5kIG1vcmUgZmxleGlibGU/KSBtb2RlbCB0
aGFuIOKAnGp1c3TigJ0gdHJhbnNpdGl2ZSB0cnVzdCBhbmQg4oCcanVzdOKAnSBlbmQtdG8tZW5k
IHRydXN0IGRpc2N1c3NlZCBwcmV2aW91c2x5LCBhbmQgaXMgZW5hYmxlZCBieSB0aGUg4oCcZm9y
d2FyZGluZ+KAnSBiaXQgZGVzY3JpYmVkIHByZXZpb3VzbHkuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjx1Pk1ldHJpY3M8L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIGFza2VkIHRoaXMg
bnVtZXJvdXMgdGltZXMsIGJ1dCBoYXZlIG5vdCBnb3R0ZW4gYW55IGFuc3dlciBzbyBJIGFtIGVz
Y2FsYXRpbmcgdGhpcyBhZ2Fpbi4gV2h5IGlzIHRoaXMgZG9jdW1lbnQgaGF2aW5nIGEgbm9ybWF0
aXZlIHJlZmVyZW5jZSB0byBSRkM2NTUxPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs
d2F5cyI+Jm5ic3A7Jm5ic3A7IFs8YSBuYW1lPSJyZWYtUkZDNjU1MSIgaWQ9InJlZi1SRkM2NTUx
Ij5SRkM2NTUxPC9hPl0mbmJzcDsgVmFzc2V1ciwgSlAuLCBFZC4sIEtpbSwgTS4sIEVkLiwgUGlz
dGVyLCBLLiwgRGVqZWFuLCBOLiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1i
cmVhay1iZWZvcmU6YWx3YXlzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kIEQuIEJhcnRoZWws
ICZxdW90O1JvdXRpbmcgTWV0cmljcyBVc2VkIGZvciBQYXRoIENhbGN1bGF0aW9uPG86cD48L286
cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IGluIExvdy1Qb3dlciBhbmQgTG9zc3kgTmV0d29ya3MmcXVvdDssIDxhIGhy
ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTUxIj48c3BhbiBzdHlsZT0iY29s
b3I6cHVycGxlIj5SRkMgNjU1MTwvc3Bhbj48L2E+LCBET0kgMTAuMTc0ODcvPG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTUxIj48
c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5SRkM2NTUxPC9zcGFuPjwvYT4sIE1hcmNoIDIwMTIs
PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iu
b3JnL2luZm8vcmZjNjU1MSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL3d3dy5y
ZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzY1NTE8L3NwYW4+PC9hPiZndDsuPG86cD48L286cD48L3By
ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VW5sZXNzIEkgYW0gbWlzdGFrZW4sIHRoaXMgaXMgbm90
IHRoZSBST0xMIFdHLiBBbmQgdGhlIGFic3RyYWN0IHRvIFJGQzY1NTEgZXhwbGljaXRseSByZWFk
czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAi
PiZuYnNwOyZuYnNwOyBMb3ctUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzIChMTE5zKSBoYXZlIHVu
aXF1ZSBjaGFyYWN0ZXJpc3RpY3M8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg
Y29tcGFyZWQgd2l0aCB0cmFkaXRpb25hbCB3aXJlZCBhbmQgYWQgaG9jIG5ldHdvcmtzIHRoYXQg
cmVxdWlyZSB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc3BlY2lmaWNh
dGlvbiBvZiBuZXcgcm91dGluZyBtZXRyaWNzIGFuZCBjb25zdHJhaW50cy4mbmJzcDsgPG86cD48
L286cD48L3ByZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpY2ggZXhw
bGljaXRseSBpcyBkaXNjbGFpbWluZyB0aGF0IHRoZXNlIG1ldHJpY3MgYXJlPHNwYW4gY2xhc3M9
ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGI+PHU+Jm5ic3A7PC91PjwvYj48L3NwYW4+PGI+PHU+
bm90IGFwcGxpY2FibGUgaW4gYWQgaG9jIG5ldHdvcmtzPC91PjwvYj7igJQgYW5kLCBJIGFtIHdv
bmRlcmluZywgd2hhdCBoYXMgY2hhbmdlZCBzaW5jZSB0aGUgcHVibGljYXRpb24gb2YgUkZDNjU1
MSB0byBzdWRkZW5seQ0KIG1ha2UgdGhlc2UgYXBwbGljYWJsZT88bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7SSBhbSBhbHNvIHdvbmRlcmluZyBpZiBsb29raW5nIGF0IChhbmQsIHBl
cmhhcHMsIHVzaW5nPykgdGhlIHNhbWUgbWV0cmljIHR5cGUgVExWIHR5cGUgYXMgaW4gT0xTUnYy
IGlzIG5vdCBhIHBvc3NpYmlsaXR5PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkVpdGhlciB3YXksIHJlZmVyZW5jaW5nIFJGQzY1NTEgaGVyZSBpcyB3cm9uZy48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHU+UkZDNjYyMSAoU01GKSB1c2FnZTwvdT48L2I+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5BcyBsYXRlIGFzIGVhcmxpZXIgdGhpcyBtb250aCwgUkZDNjYyMSByZWFyZWQgaXRzIGhl
YWQgYWdhaW4gb24gdGhlIG1haWxpbmcgbGlzdC4gSSB1bmRlcnN0YW5kIHRoYXQgdGhlIGF1dGhv
cnMgYXJlIHNldCBvbiB1c2luZyBmbG9vZGluZyByZWR1Y3Rpb24gYXMgcGFydCBvZiBSUkVRIGRp
c3RyaWJ1dGlvbi4gSWYgdGhhdCBpcyB0aGUgY2FzZSwgdGhlbiB0aGlzIHByb3RvY29sIE1VU1Qg
c3BlY2lmeSB0aGF0DQogZmxvb2RpbmcgcmVkdWN0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5TYXlpbmcg4oCcVXNlIFJGQzY2MjHigJ0gd29u4oCZdCB3b3JrLCBmb3IgcmVh
c29ucyBDaHJpcyBwb2ludCBvdXQgaW4gYW4gZW1haWwgZWFybGllciB0byB0aGUgbGlzdDo8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+VGhlIG5ldHdvcmsgZG9lcyBub3QgYW5kIGZ1bmRhbWVudGFsbHkgY2Fubm90IG9m
ZmVyIG11bHRpY2FzdCBzdXBwcmVzc2lvbiB0byBBT0RWdjIuIFRoaXMgaXNuJ3QgYSBoYXJkIGNv
bmNlcHQsIGJ1dCBzZWVtcyB0byBrZWVwJm5ic3A7aGF2aW5nIHRvIGJlIHNhaWQuIEFPRFZ2MiBt
ZXNzYWdlcyBhcmUgY2FycmllZCBpbiA1NDQ0IHBhY2tldHMsIGFuZCB0aG9zZSBvbmx5IHRyYXZl
bCBvbmUgaG9wLiBUaGF0IGRvZXNuJ3QNCiBhbGxvdyBmb3Igc3VwcHJlc3Npb24uJm5ic3A7RnVy
dGhlcm1vcmUgQU9EVnYyIGlzIGNyZWF0aW5nIG5ldyBtZXNzYWdlcyBlYWNoIGhvcC4gVGhhdCBu
ZWVkcyBBT0RWdjIgc3BlY2lmaWMgaGFuZGxpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkFuZCBxdW90aW5nIGFuIGVtYWlsIGZyb20gbXlzZWxmOjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5JZiBwcm90b2NvbCBYIHJlbGllcyBvbiB1c2luZyBhIGZsb29kaW5nIG9wZXJhdGlvbiwg
dGhlbiBpdCBjZXJ0YWlubHkgaXMgcHJvdG9jb2wgWCdzIHJlc3BvbnNpYmlsaXR5IHRvICZuYnNw
O3NwZWNpZnkgdGhlIGZsb29kaW5nIG9wZXJhdGlvbiAob3IsIGF0IGxlYXN0LCZuYnNwO3RoZSBy
ZXF1aXJlbWVudHMgdG8gdGhlIGZsb29kaW5nIG9wZXJhdGlvbiApIGZvciBjb3JyZWN0IGZ1bmN0
aW9uaW5nIG9mIHByb3RvY29sIFguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJl2ZSBw
cmV2aW91c2x5IHBvaW50ZWQgb3V0IHRoYXQgUkZDNjYyMSByZXF1aXJlcyBzb21lIGRlZ3JlZSBv
ZiBjb25maWd1cmF0aW9uIChjYW7igJl0IGp1c3QsIGZvciBleGFtcGxlLCBwaWNrIHR3byBkaWZm
ZXJlbnQgcmVsYXkgc2V0IHNlbGVjdGlvbiBhbGdvcml0aG1zLCBhcyB0aGF0IG1heSBwcm9kdWNl
IGEgZGlzY29ubmVjdGVkIGZsb29kaW5nIGRvbWFpbikuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkluIG90aGVyIHdvcmRzLCB3aGF0IHRoZSBhdXRob3JzIHByb3Bvc2UgaW4mbmJzcDs8YSBo
cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC11c2lu
Zy1yZmM2NjIxLTAwIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC11c2luZy1yZmM2NjIxLTAwPC9zcGFuPjwv
YT4mbmJzcDtpcyBpbnN1ZmZpY2llbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjx1
Pk11bHRpcGxlIGludGVyZmFjZXMgY29uZmlndXJlZCB3aXRoIHRoZSBzYW1lIGFkZHJlc3MoZXMp
IC0gJmFtcDsgUkZDNjYyMTwvdT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoYXQgaXQgaGFzIGJl
ZW4gZXN0YWJsaXNoZWQgdGhhdCB0aGUgYWJpbGl0eSB0byB1c2UgdGhlIHNhbWUgYWRkcmVzcyBv
biBtdWx0aXBsZSBpbnRlcmZhY2VzIGlzIGEgcmVxdWlyZW1lbnQuIEl04oCZcyBub3QgY2xlYXIg
dG8gbWUgdGhhdCBhIHNpbmdsZSB3YXkgb2YgZG9pbmcgc28gaGFzIGJlZW4gcHJvcG9zZWQsIG5v
ciB0aGF0IHRoZSDigJxvcGVyYXRpbmcgY29uZGl0aW9uc+KAnSBhcmUgY2FsbGVkDQogb3V0IChm
b3IgZXhhbXBsZSwgd2lsbCBpdCB3b3JrICZuYnNwO2lmIHJvdXRlciBBIGFuZCByb3V0ZXIgQiBi
b3RoIGhhdmUgdHdvIGludGVyZmFjZXMsIGFuZCB0aGF0IGFsbCA0IGludGVyZmFjZXMgdXNlIHRo
ZSBzYW1lIElQIGFkZHJlc3M/KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIG5v
dCBlbnRpcmVseSB1bnJlbGF0ZWQgdG8gZmxvb2RpbmcgcmVkdWN0aW9uIGFuZCBSRkM2NjIxLiBP
bmUgb2YgdGhlIGNvbXBsZXhpdGllcyBpcyB0byBnZXQgdGhhdCBqdXN0IHJpZ2h0OiBPTFNSdjIg
LSBmb3IgZXhhbXBsZSAtIGNhbGN1bGF0ZXMgRmxvb2RpbmctTVBScyBwZXIgaW50ZXJmYWNlLCBh
bmQgUkZDNjEzMCBpcyBjYXJlZnVsIGluIGhvdyBpdCBkZXRlY3RzIGJpZGlyZWN0aW9uYWxpdHkN
CiBvZiBsaW5rcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIG5vdCB3
b3JrZWQgb3V0IGFsbCB0aGUgZGV0YWlscyBvZiBob3cgdGhpcyBpbXBhY3RzIHRoaXMgcHJvdG9j
b2wg4oCUIGJ1dCwgaXQgcmVxdWlyZXMgYXR0ZW50aW9uLiBFc3BlY2lhbGx5IHdoZW4gd2FudGlu
ZyB0byBiZSBhYmxlIHRvIHNheSDigJzigKZ1c2UgUkZDNjYyMeKAnSwgdGhlbiB0aGUgaW50ZXJm
YWNlIGNvbmZpZ3VyYXRpb24gY29uc3RyYWludHMgd2hlbiBmYWNlZCB3aXRoIG11bHRpcGxlIGlu
dGVyZmFjZXMNCiBtdXN0IGJlIHdvcmtlZCBvdXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjx1PlByZWZpeGVzICZhbXA7IEdhdGV3YXlzPC91PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgcXVlc3Rp
b24gdG8gbXkgbWluZCwgYW5kIEkgYW0gbm90IHN1cmUgSSBrbm93IGhvdyB0byBhbnN3ZXIgdGhh
dCBmcm9tIHJlYWRpbmcgdGhlIGRyYWZ0IHNpbmNlIGl0IGlzIG5vdCBkaXNjdXNzZWQgaW4gc2Vj
dGlvbiA5IChhdCBsZWFzdCksIGlzOiDigJxXaGF0IGhhcHBlbnMgaWYgSSBzZW5kIGEgUlJFUSB0
byBhIHByZWZpeOKAnSAoaS5lLiwgYSAvJmx0OzEyOCBpbiBJUHY2KT88bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+
PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm88c3BhbiBj
bGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj4mbmJzcDs8L3NwYW4+SWYgdGhlIHdob2xlIHByZWZpeCBpcyBwYXJ0IG9mIHRoZSBhdHRh
Y2hlZCBuZXR3b3JrIHNldA0KIG9mIGEgc2luZ2xlIHJvdXRlciwmbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFu
PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj50aGVuIEkg
ZXhwZWN0IHRvIGdldCBhIHNpbmdsZSBSUkVQIGJhY2ssIGlzIHRoYXQgdGhlIGNhc2U/PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj5vPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPklmICZxdW90O2hhbGYgdGhlIHByZWZpeCZxdW90
OyAmbmJzcDtpcyBwYXJ0IG9mIHRoZSBhdHRhY2hlZCBuZXR3b3JrIHNldA0KIG9mIGEgc2luZ2xl
IHJvdXRlciwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj5hbmQgdGhlIG90aGVyIGhhbGYgaXMgcGFydCBvZiB0aGUgYXR0
YWNoZWQgbmV0d29yayBzZXQgb2YgYW5vdGhlciAmbmJzcDtzaW5nbGUgcm91dGVyLCZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPnRoZW4gSSBleHBlY3QgdHdvIFJSRVBzLCBpcyB0aGF0IHRoZSBjYXNlPzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwv
c3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+bzxz
cGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Nb3JlIGdlbmVyYWxseSwgd2lsbCBJIGdldCBhIHRyZWUg
YnVpbGQgdGhyb3VnaCB0aGUgbmV0d29yaw0KIGhlcmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BT0RWdjIgY3VycmVudGx5IGRvZXNu
4oCZdCBzdXBwb3J0IFJSRVFzIGZvciBwcmVmaXhlcy4gSeKAmXZlIGFscmVhZHkgYWRkZWQg4oCe
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPklmIFJ0ZU1zZyBpcyBhIFJSRVEsIFJ0
ZU1zZy5UYXJnUHJlZml4TGVuIFNIT1VMRCBlcXVhbCBhZGRyZXNzIGxlbmd0aC48L3NwYW4+4oCc
IHRvIFJ0ZU1zZy5UYXJnUHJlZml4TGVuIGluIHNlY3Rpb24mbmJzcDs8YSBuYW1lPSJzZWN0aW9u
LTQuNiI+PC9hPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm
LW1hbmV0LWFvZHZ2Mi0xMyNzZWN0aW9uLTQuNiI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs
ZTt0ZXh0LWRlY29yYXRpb246bm9uZSI+NC42PC9zcGFuPjwvYj48L2E+PGI+Lg0KIE11bHRpY2Fz
dCBSb3V0ZSBNZXNzYWdlIFRhYmxlPC9iPiZuYnNwO2luIHJlc3BvbnNlIHRvIEp1c3RpbuKAmXMg
Y29tbWVudHMsIGJ1dCBJ4oCZbGwgZ28gdGhyb3VnaCB0aGUgZHJhZnQgYWdhaW4gYW5kIHNlZSB3
aGVyZSB3ZSBuZWVkIHRvIHN0YXRlIHRoaXMgbW9yZSBjbGVhcmx5LjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Mb3R0ZSBTdGVlbmJyaW5rPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9u
IDkgKG9yLCB0aGUgd2hvbGUgc3BlYykgaXMgYWxzbyBub3QgZXhwbGljaXQgZW5vdWdoIGFib3V0
IG11bHRpcGxlICZuYnNwOyZxdW90O2RlZmF1bHQgZ2F0ZXdheXMmcXVvdDsg4oCUIGkuZS4sIHRo
ZSBleHRlcm5hbCBuZXR3b3JrIGJlaW5nIOKAnHRoZSByZXN0IG9mIHRoZSBJbnRlcm5ldOKAnSwg
YW5kIHRoZXJlIGJlaW5nIG11bHRpcGxlIGdhdGV3YXlzIHRvIHRoZSBJbnRlcm5ldC4gSSB1bmRl
cnN0YW5kIGhvdyB0aGUgUlJFUSBnZXRzDQogdG8gdGhlIGdhdGV3YXksIGFuZCBob3cgdGhlIGdh
dGV3YXkgZGV0ZXJtaW5lcyBpZiBpdCBzaG91bGQgcmVzcG9uZCAodGhlIGRlc3RpbmF0aW9uIGlz
IG5vdCBwYXJ0IG9mIOKAnHRoZSBNQU5FVCBwcmVmaXgsIHdpdGggd2hpY2ggaXQgaXMgY29uZmln
dXJlZOKAnSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCwgaWYgQSBpcyBjbG9zZSB0
byBHVzEsIGFuZCBCIGlzIGNsb3NlIHRvIEdXMiwgYnV0IEEgYW5kIEIgYmVpbmcgZmFyIGZhciBh
cGFydCAoYWNjb3JkaW5nIHRvIHRoZSBtZXRyaWMgdXNlZCkgd2l0aGluIHRoZSBNQU5FVCwgdGhl
biBpdCB3b3VsZCBiZSBwcmVmZXJlbnRpYWwgZm9yIHRoZSByb3V0ZSBmcm9tIEEgdG8gQiB0byBn
byB2aWEgR1cxLeKAnHRoZS1JbnRlcm5ldOKAnS1HVzI/Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPklzIHRoaXMgYSBzdXBwb3J0ZWQgY29uZmlndXJhdGlvbj8mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNs
YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5vPHNwYW4gY2xhc3M9ImFw
cGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i
c3A7PC9zcGFuPklmIHllcywgaG93IGlzIGl0IChzZXEjIHdpc2UsIEkgd291bGQgZXhwZWN0IHNv
bWUgY29tcGxpY2F0aW9ucykNCiBoYW5kbGVkPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9
ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm88c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bh
bj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SWYgbm90
LCB3aGVyZSBpcyBpdCBzdGF0ZWQgdGhhdCB0aGlzIGNvbmZpZ3VyYXRpb24gaXMgbm90DQogcG9z
c2libGUgd2l0aCB0aGlzIHByb3RvY29sPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBzYXlzOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9
InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7IEFPRFZ2MiBpcyBkZXNpZ25l
ZCBmb3Igc3R1YiBvciBkaXNjb25uZWN0ZWQgbW9iaWxlIGFkIGhvYyBuZXR3b3Jrcyw8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4mbmJzcDsm
bmJzcDsgaS5lLiwgbm9uLXRyYW5zaXQgbmV0d29ya3Mgb3IgdGhvc2Ugbm90IGNvbm5lY3RlZCB0
byB0aGUgaW50ZXJuZXQuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWst
YmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7IEFPRFZ2MiBjYW4sIGhvd2V2ZXIsIGJlIGNvbmZp
Z3VyZWQgdG8gcGVyZm9ybSBnYXRld2F5IGZ1bmN0aW9ucyB3aGVuPG86cD48L286cD48L3ByZT4N
CjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+Jm5ic3A7Jm5ic3A7IGF0dGFj
aGVkIHRvIGV4dGVybmFsIG5ldHdvcmtzLCBhcyBkaXNjdXNzZWQgaW4gPGEgaHJlZj0iaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzI3NlY3Rpb24t
OSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+U2VjdGlvbiA5PC9zcGFuPjwvYT4uPG86cD48
L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkkgYmVsaWV2ZSB0aGF0IHRoZSBzY2VuYXJpbyBJIGRlc2NyaWJlIGlz
IGluZGVlZCBhIHN0dWIgbmV0d29yayAoYW5kIG5vdCBhIHRyYW5zaXQgbmV0d29yayk/PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAlCDigJQg4oCUJm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkFzIEkgaW5kaWNhdGVkLCB0aGVzZSBhcmUgdGhlIGJpZy1waWN0dXJlIGlzc3Vl
cyB0aGF0IEkgaGF2ZSBnb3R0ZW4gYXJvdW5kIHRvIHRoaW5raW5nIGFib3V0IGVub3VnaCB0byB3
cml0ZSB1cC4gSeKAmW0gbm90IHRocm91Z2ggd29ya2luZyB0aHJvdWdoIHRoZSBkb2N1bWVudCwg
YnV0IHRob3NlIHdlcmUgdGhlIG9uZXMgdGhhdCBjYW1lIHRvIG1pbmQsIGFuZCB3aGljaCBzZWVt
IGltcGVyYXRpdmUgdG8gcmVzb2x2ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvbWFzPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+
DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw
bGUiPm1hbmV0QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9zcGFuPjwvYT48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7
b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQt
c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKjxicj4NClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50
cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZDxicj4NCnJlY2lwaWVudCBhbmQgbWF5
IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPg0KcmVj
aXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBz
ZW5kZXIuPGJyPg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJw
b3NlIG5vciBkaXNjbG9zZSBvcjxicj4NCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBv
dGhlciBwZXJzb24uPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKio8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B00C7GLKXM0002VGREEN_--


From nobody Thu Apr 21 11:24: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 405F512DDF9 for ; Thu, 21 Apr 2016 11:24:06 -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 Z3NewtDl5y_1 for ; Thu, 21 Apr 2016 11:24:05 -0700 (PDT)
Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 BC10112DD97 for ; Thu, 21 Apr 2016 11:24:04 -0700 (PDT)
Received: by mail-wm0-x243.google.com with SMTP id n3so23683429wmn.1 for ; Thu, 21 Apr 2016 11:24:04 -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 :content-transfer-encoding:message-id:references:to; bh=Yti0CudYg4yzJQhT6GifRjjHo9TgWoDv5RwbZrFDdNQ=; b=GQWEwVHUMNWWrJUWjGn4azy/8WcTAmJNxFEbGtprEuznxSBif1EVu6XNY7Ua40J2CG rqqh1+usxfP3VhqWaXc6M9wlKqqQm6WSwlvpBWJ6Z4Ls+Vvac14nu5hTrgSAqUwoLtJC lB1Os4VTcns50sjIrWNP+ddGAuA+9f8/zAvBpZy7u7J3sOe+SP7n4G/2p4AlqSQeTsE5 5Jbeqa5UVQsqSSKUNo7UL6ghRWeUrOoMgyOA3j9MB1tYiwZt/7a7dteKU0+ryUqxDYsO DpnqmUTw58zaV+GUCM7mHiY/hkxJkzitwievrT4RUkuZFrBDV99fxs67JcqM29YDTpuI 8Dhw==
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 :content-transfer-encoding:message-id:references:to; bh=Yti0CudYg4yzJQhT6GifRjjHo9TgWoDv5RwbZrFDdNQ=; b=U3eai74mZYpoIOcI1LxPNUqi/vw9JaKroy64TRLZCwbCr3PHBpbl15XkLQTrIDlI1E rJF5t/clkolAIcDCOFWgo5S7pZOoS/SySgKYIvrJ5SjSbvQn7MtYHjYy0c09HT5QV5i9 /XMc5rmGr4dm7IDfuiuYGR6cXZu/l+x4mVsFx0haVWX1KZU98PCRDQLv1tRRdA/Vr+XW AJABMX5yoXRg5buQQA2H3AT/EvHDoT/I9OY639b3EwpOI1dK/foRWZPZvPqdXNhcrFGQ 8Fpom71EQzKJbLpWe3aW9lTez1aNMhzc5C7TWEUkf15yk4mJG97QBW/18G/hc5JO+2ah VXyg==
X-Gm-Message-State: AOPr4FWuKVUKxJMFgOzO59f5KB0V8nxIQhv6DbEYGgJbj8Js0wO19YdUYzPMsqrH3zOtpg==
X-Received: by 10.28.102.6 with SMTP id a6mr38873197wmc.75.1461263043213; Thu, 21 Apr 2016 11:24:03 -0700 (PDT)
Received: from johns-mbp-4.home (host86-157-43-97.range86-157.btcentralplus.com. [86.157.43.97]) by smtp.gmail.com with ESMTPSA id e12sm4474858wma.15.2016.04.21.11.24.01 for  (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Apr 2016 11:24:02 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Dowdell 
In-Reply-To: 
Date: Thu, 21 Apr 2016 19:24:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <927E6489-D927-4670-A24C-5A5D9B58C05D@gmail.com>
References:   
To: "manet@ietf.org" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [manet] New AODVv2 draft and status
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, 21 Apr 2016 18:24:06 -0000

All

I believe we=E2=80=99re going about this the wrong way, and we=E2=80=99re =
setting ourselves an impossible target at which we are bound to fail.

BCP 9, governing the Internet Standards process, section 4.1.1 deals =
with the first level of maturity, termed Proposed Standard. To =
paraphrase, a Proposed Standard is supposed to be as correct as we can =
make it, but there is no requirement to have made an implementation. =
Since no engineer has ever written a fully correct specification before =
cutting metal, it may be expected that there are some areas which will =
need attention later on, at Draft Standard if we ever wanted to go that =
far. I=E2=80=99ll say now that one area in AODVv2 will need some work =
later, that of hop-by-hop security in an ad hoc network. This is because =
nobody has really cracked that problem yet; some real bright people are =
grappling with that right now over in DTN. The work in our own group on =
Identity Based Signatures will help but there is still ground to cover. =
However the actual level of security is not for AODVv2 to mandate, it is =
for the implementor and system integrator, based on an assessment of the =
likely risk and the thickness of their wallet.

It is clear to me that few will make an independent implementation =
without the RFC stamp. This much is obvious in modems fitted with DLEP; =
there are just four such implementations I know of, and two of those =
were written with the encouragement of author team members, but I know =
of many more who are just waiting for the dust to settle so they can =
make the business case to proceed. Allow AODVv2 to get to RFC and =
we=E2=80=99ll encourage others to use it and get some feedback.

Regards
John=


From nobody Thu Apr 21 11:46: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 D212312E415 for ; Thu, 21 Apr 2016 11:46:12 -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 H_voFWZQ-rkU for ; Thu, 21 Apr 2016 11:46:09 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id BC91112E510 for ; Thu, 21 Apr 2016 11:46:04 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=lh1pmLk/Scg4SWPOBNnA8E3l1DSOjMjoEVIDdUV8I9eLXt7kCXGm1DKN/Yb1ZOH0; 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-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1atJbt-0001Ck-CG; Thu, 21 Apr 2016 14:45:53 -0400
To: John Dowdell , "manet@ietf.org" 
References:    <927E6489-D927-4670-A24C-5A5D9B58C05D@gmail.com>
From: Charlie Perkins 
Message-ID: <57191FDD.5010707@earthlink.net>
Date: Thu, 21 Apr 2016 11:45:49 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <927E6489-D927-4670-A24C-5A5D9B58C05D@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac776b4d6a0f8c18ab495d0b29c3268ed8e350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: 
Subject: Re: [manet] New AODVv2 draft and status
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, 21 Apr 2016 18:46:13 -0000

Hello folks,

At least this author is ready to get on with revising the draft. There's =

not much currently left to do.

We don't have to take anyone's name away from previously published=20
documents.  All we have to do is accede to the request for the future=20
documents.

I have already offered to spend time on making the revision.

Regarding security: if AODVv2 were to solve all the possible security=20
exposures of ad hoc networks, it would be historic and worthy of=20
publication -- probably would win paper of the year. Needless to say,=20
that was never part of the charter.

Regards,
Charlie P.


On 4/21/2016 11:24 AM, John Dowdell wrote:
> All
>
> I believe we=E2=80=99re going about this the wrong way, and we=E2=80=99=
re setting ourselves an impossible target at which we are bound to fail.
>
> BCP 9, governing the Internet Standards process, section 4.1.1 deals wi=
th the first level of maturity, termed Proposed Standard. To paraphrase, =
a Proposed Standard is supposed to be as correct as we can make it, but t=
here is no requirement to have made an implementation. Since no engineer =
has ever written a fully correct specification before cutting metal, it m=
ay be expected that there are some areas which will need attention later =
on, at Draft Standard if we ever wanted to go that far. I=E2=80=99ll say =
now that one area in AODVv2 will need some work later, that of hop-by-hop=
 security in an ad hoc network. This is because nobody has really cracked=
 that problem yet; some real bright people are grappling with that right =
now over in DTN. The work in our own group on Identity Based Signatures w=
ill help but there is still ground to cover. However the actual level of =
security is not for AODVv2 to mandate, it is for the implementor and syst=
em integrator, based on an assessment of the likely risk and the thicknes=
s of their wallet.
>
> It is clear to me that few will make an independent implementation with=
out the RFC stamp. This much is obvious in modems fitted with DLEP; there=
 are just four such implementations I know of, and two of those were writ=
ten with the encouragement of author team members, but I know of many mor=
e who are just waiting for the dust to settle so they can make the busine=
ss case to proceed. Allow AODVv2 to get to RFC and we=E2=80=99ll encourag=
e others to use it and get some feedback.
>
> Regards
> John
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet



From nobody Thu Apr 21 12:27: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 7EFB712D0A4 for ; Thu, 21 Apr 2016 12:27:41 -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 1BXCaIO1R3oJ for ; Thu, 21 Apr 2016 12:27:39 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 7A71312B071 for ; Thu, 21 Apr 2016 12:27:39 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id 127so5600725wmz.0 for ; Thu, 21 Apr 2016 12:27:39 -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=+xJD8XxEDKBbhzZXyV0Sd7uJHqlnSb7zfnz3wK9EWq8=; b=t8Qh5kgZuRz9atykD4V+0PAe2rkHIXwCs+sKyl+jKYphDTFoSc5wJVOOYhCNQE+iYe Z0VWAXskx8l1h5MzKjwxf9Hot+gQ/O9rLkyTIwEYYZeQeBaSb7Mwjy/olX4+diUT8Lc7 fCZUgIcHifaWjGRaEgXAlxnCqCPp7Uq2d0W119JzeN2hx2OefAAJw0WRIqsCEcglJlrS CadSe1VCaHN79HaK6guOVpJi5jleUHoihnm/RCov1/q7ZeHE47DE/x1FJR5x5xl45/Kx bJKRgCQsOL0Hz5M7o1jGAfaytBbT8dscDTJ5hlp3QUp8cqAlzF4LskLLkrbnlAtpUY/U Pu9g==
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=+xJD8XxEDKBbhzZXyV0Sd7uJHqlnSb7zfnz3wK9EWq8=; b=LEMPpt8Y2XxUUHt9YIWhO08UrXFl9MgaVnEniRs7UK47jaNG7JEl+xpfLm83AWrt3F BnwkNFrdwus23FTg1FXlBVv3rhEzlBJ80bFj+2MlxjSMonOLEenWCTxaNS7ZYR9AWSN8 ZWbMsG8KOgIMktj37pKNmcd0O8k1qysKtBhayD/ixaHy5r0bnkyiYMF7GDVRNQpAvyYK ptlOPvX8j1Kh+cvzfTwbMHRO0Aal66z8hFxDohka50EixKWmkcxEjUXJa+/Ht+XEuxyT R5RPL+vlGRrfC62yaZavwXsZo7Em0RoWPx7IdXUyGtpWUIFksUa+cX1hhGnTl7i4ED01 DLIQ==
X-Gm-Message-State: AOPr4FW4mGyUztMFVmQZInAn8rDwi55W3PIUGYzWNpAD3oorpg80qqGstOPuhX0B/oQDvw==
X-Received: by 10.194.58.195 with SMTP id t3mr15659685wjq.97.1461266858026; Thu, 21 Apr 2016 12:27:38 -0700 (PDT)
Received: from [10.0.15.31] (82-132-230-227.dab.02.net. [82.132.230.227]) by smtp.gmail.com with ESMTPSA id t206sm4670063wmt.21.2016.04.21.12.27.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Apr 2016 12:27:37 -0700 (PDT)
References:    <927E6489-D927-4670-A24C-5A5D9B58C05D@gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <927E6489-D927-4670-A24C-5A5D9B58C05D@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BC99B1A-0AE6-46E9-9EBA-580D000FF9D4@gmail.com>
X-Mailer: iPhone Mail (13E238)
From: Christopher Dearlove 
Date: Thu, 21 Apr 2016 20:27:32 +0100
To: John Dowdell 
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 21 Apr 2016 19:27:41 -0000

This is missing the point, or not expressing clearly, that Experimental, whi=
ch may or may not be accepted, is an RFC. It's not a choice between Proposed=
 Standard and RFC. The WG can produced a Proposed Standard, Experimental or n=
ot (I'm ignoring obviously inappropriate things like Informational). Not is h=
owever not the final word on RFC status, there's approaches like AD sponsore=
d and Independent Submission.

But Proposed Standard is, by current practice, a high bar. It's not acceptab=
le to say "this is roughly right, let's do this and get it right in a future=
 advance". That's more like (I'm not saying exactly like) Experimental. Most=
 protocols never advance beyond Proposed Standard, even ones the Internet re=
lies on. In most organisations it would be called a standard.

In addition, the next stage after Proposed Standard isn't Draft Standard. Th=
at's been abolished (for new documents). The next stage after Proposed Stand=
ard is Internet Standard, and that's a very high bar indeed.

That's been in the abstract. In fact the chair has ruled out Proposed Standa=
rd. You'd have to invoke process to overturn that - and (switching to opinio=
n, up to now I may or may not have made errors, but it's meant to be objecti=
ve) I'm pretty sure you'd fail.

Do the labels Experimental and Proposed Standard (and others) matter? Outsid=
e the IETF quite a few people just say "RFC" and that's enough. Inside the I=
ETF people care, and many of those wished others did - and some do.

--=20
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)

> On 21 Apr 2016, at 19:24, John Dowdell  wrote=
:
>=20
>=20
> All
>=20
> I believe we=E2=80=99re going about this the wrong way, and we=E2=80=99re s=
etting ourselves an impossible target at which we are bound to fail.
>=20
> BCP 9, governing the Internet Standards process, section 4.1.1 deals with t=
he first level of maturity, termed Proposed Standard. To paraphrase, a Propo=
sed Standard is supposed to be as correct as we can make it, but there is no=
 requirement to have made an implementation. Since no engineer has ever writ=
ten a fully correct specification before cutting metal, it may be expected t=
hat there are some areas which will need attention later on, at Draft Standa=
rd if we ever wanted to go that far. I=E2=80=99ll say now that one area in A=
ODVv2 will need some work later, that of hop-by-hop security in an ad hoc ne=
twork. This is because nobody has really cracked that problem yet; some real=
 bright people are grappling with that right now over in DTN. The work in ou=
r own group on Identity Based Signatures will help but there is still ground=
 to cover. However the actual level of security is not for AODVv2 to mandate=
, it is for the implementor and system integrator, based on an assessment of=
 the likely risk and the thickness of their wallet.
>=20
> It is clear to me that few will make an independent implementation without=
 the RFC stamp. This much is obvious in modems fitted with DLEP; there are j=
ust four such implementations I know of, and two of those were written with t=
he encouragement of author team members, but I know of many more who are jus=
t waiting for the dust to settle so they can make the business case to proce=
ed. Allow AODVv2 to get to RFC and we=E2=80=99ll encourage others to use it a=
nd get some feedback.
>=20
> Regards
> John
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From nobody Thu Apr 21 13:38: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 3FAB812DD27 for ; Thu, 21 Apr 2016 13:38:10 -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 mg3MDlKr5jqB for ; Thu, 21 Apr 2016 13:38:08 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 89D8212B04E for ; Thu, 21 Apr 2016 13:38:07 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id v188so259335847wme.1 for ; Thu, 21 Apr 2016 13:38:07 -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=2+gBFA9FATWDwjCy/cQrlJawTDhrRZlEcUfhp90XsjE=; b=j3i4WGYJF+7A2R9w/IXW0t2Xg0a8TLUVYdy4MAF6qVZeA0xBT8LeQJ8yikBwuDTNC4 Qj55kxFiXhzeslYUXpnpEAQXLueU4cz7iX4FAKymepDcwIY1//CibmmUrkBpkfH8yywX fj8iE01GSMvQ8G7fy31vLXfvwq6wLGv45DLOmPapdPT0GTZGONYE37a4N3Vj/xKzS61M 1S5ixS4r+5CAT//vPtg/oCIDWjOkRGy8JzoKPPuJs2ZpLEvz9W5GA/PtWyPgNUYyuOUD /FXhsF87YDbohYpy0WTMJZsuPlcGn/WICQYVAnODXtZtiDtmWOQTUXh50cHNphXw84WJ gZbg==
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=2+gBFA9FATWDwjCy/cQrlJawTDhrRZlEcUfhp90XsjE=; b=IspPvODYWBqPRpyk58TnqfOLwfZyEx8r+Oz0BjLCxEzvgtoJ44FEQ2KrwlPRVx6iEP JTf+iHFxcADR4KNs4QfN+XoYS+Cj3Wwg2Eo/NQMUDqe1LxCpU/7IjfRA3DbrfcMQDodG o9+s8vnyo4rNg59kJ0Y6s39z1mz8lTt849xXKxgCsZpyXRLZ6Iu5YQlIwjOfKDLn5eUo 8zVuuIODFCPMmaaHI1YhkJbszrju9Pn9xNknWABtQTg5nTWIYOUQm3fIPkR+9WJ6W5OS HW1qMqBg/2k916tDG00mo1PA1ngozB7W6Jg27zEz8JHdyqaO6EzHigKyEE2S1Cvogfh6 9h1A==
X-Gm-Message-State: AOPr4FX6n/kuxnHteCVdebCL7PKuDjTFCCtUH3iKeUPzpilq7IiuDoDgz9tzhTdD7g72kiTCb5RVythA3GIO8g==
MIME-Version: 1.0
X-Received: by 10.28.54.208 with SMTP id y77mr36353699wmh.17.1461271086060; Thu, 21 Apr 2016 13:38:06 -0700 (PDT)
Sender: yi.jiazi@gmail.com
Received: by 10.194.153.166 with HTTP; Thu, 21 Apr 2016 13:38:05 -0700 (PDT)
In-Reply-To: <57191FDD.5010707@earthlink.net>
References:    <927E6489-D927-4670-A24C-5A5D9B58C05D@gmail.com> <57191FDD.5010707@earthlink.net>
Date: Thu, 21 Apr 2016 22:38:05 +0200
X-Google-Sender-Auth: 1I3ctYZzxIix5xgce6DMzCoxNes
Message-ID: 
From: Jiazi YI 
To: Charlie Perkins 
Content-Type: multipart/alternative; boundary=001a11435430015fc5053104b07c
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 21 Apr 2016 20:38:10 -0000

--001a11435430015fc5053104b07c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,


On Thu, Apr 21, 2016 at 8:45 PM, Charlie Perkins <
charles.perkins@earthlink.net> wrote:

> 
>
> Regarding security: if AODVv2 were to solve all the possible security
> exposures of ad hoc networks, it would be historic and worthy of
> publication -- probably would win paper of the year. Needless to say, tha=
t
> was never part of the charter.
>


But security and its consideration are part of every specification.

As one who co-authored several vulnerability analysis drafts/RFCs
(ndhp-sec-threats, smf-sec-threats, olsrv2-sec-threats), what we always do
for a protocol is:

  - assuming that we have a compromised router in the network, what can it
do to break the network? What's the consequences? What about if there are
several of them?

  - what about if there are mis-configured routers or wrong-implemented
routers?

  - what kind of threats can be mitigated by existed security measurements
(like RFC 7182/7183)?

  - what kind of future work can be done to make the protocol more secure?

With the current AODVv2 specification, if I was to produce a
aodvv2-sec-threats draft, it would be much simpler:

   - one single compromised router can easily jam the whole network (RREQ
flooding), or even bring down the whole network (remember the multicast
RERR?) because of the transit-trust model used.

  - with my limited knowledge, as future work, there is no easy way to
protect the message because of the reconstructed and length-varied message
regenerated in every hop.


Even *if* security was acceptable as future work (it is not, but as a
thought experiment, let's assume), there is no easy way to protect the
message because of the reconstructed and length-varied message regenerated
in every hop.

Securing a reactive protocol requires different considerations than does
securing a proactive protocol, but there has been work done in this area,
and other WG participants have raised both their concerns, and suggestions
to security architectures, and protocol architectures (better) able to
accommodate security, a long time ago. I don't see those works, nor the
suggestions and comments made, reflected or considered in revision -15 of
the draft. Especially, the current design based on message regeneration
makes the future extension to the security very hard, as has been
reiterated repeatedly.

Abdussalam doesn't agree with me on my observation on "Lack of response
from the author team on the comments. " -- this is an example.

regards

Jiazi

btw, I would like to confirm with the WG chair: the WGLC is from April 20th
to May 4th, right?



>
> Regards,
> Charlie P.
>
>
>
> On 4/21/2016 11:24 AM, John Dowdell wrote:
>
>> All
>>
>> I believe we=E2=80=99re going about this the wrong way, and we=E2=80=99r=
e setting
>> ourselves an impossible target at which we are bound to fail.
>>
>> BCP 9, governing the Internet Standards process, section 4.1.1 deals wit=
h
>> the first level of maturity, termed Proposed Standard. To paraphrase, a
>> Proposed Standard is supposed to be as correct as we can make it, but th=
ere
>> is no requirement to have made an implementation. Since no engineer has
>> ever written a fully correct specification before cutting metal, it may =
be
>> expected that there are some areas which will need attention later on, a=
t
>> Draft Standard if we ever wanted to go that far. I=E2=80=99ll say now th=
at one area
>> in AODVv2 will need some work later, that of hop-by-hop security in an a=
d
>> hoc network. This is because nobody has really cracked that problem yet;
>> some real bright people are grappling with that right now over in DTN. T=
he
>> work in our own group on Identity Based Signatures will help but there i=
s
>> still ground to cover. However the actual level of security is not for
>> AODVv2 to mandate, it is for the implementor and system integrator, base=
d
>> on an assessment of the likely risk and the thickness of their wallet.
>>
>> It is clear to me that few will make an independent implementation
>> without the RFC stamp. This much is obvious in modems fitted with DLEP;
>> there are just four such implementations I know of, and two of those wer=
e
>> written with the encouragement of author team members, but I know of man=
y
>> more who are just waiting for the dust to settle so they can make the
>> business case to proceed. Allow AODVv2 to get to RFC and we=E2=80=99ll e=
ncourage
>> others to use it and get some feedback.
>>
>> Regards
>> John
>> _______________________________________________
>> 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
>

--001a11435430015fc5053104b07c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,=C2=A0


On Thu, Apr 21, 2016 at 8:45 PM, Charlie Perkins <charles.perkins@earthlink.net> wrote:
<snip>



Regarding security: if AODVv2 were to solve all the possible security expos=
ures of ad hoc networks, it would be historic and worthy of publication -- =
probably would win paper of the year. Needless to say, that was never part =
of the charter.


But secu=
rity and its consideration are part of every specification.=C2=A0

As one who co-authored several vulnerability analysis draft=
s/RFCs (ndhp-sec-threats, smf-sec-threats, olsrv2-sec-threats), what we alw=
ays do for a protocol is:

=C2=A0 - assuming that w=
e have a compromised router in the network, what can it do to break the net=
work? What's the consequences? What about if there are several of them?=


=C2=A0 - what about if there are mis-configured r=
outers or wrong-implemented routers?

=C2=A0 - what=
 kind of threats can be mitigated by existed security measurements (like RF=
C 7182/7183)?=C2=A0

=C2=A0 - what kind of future w=
ork can be done to make the protocol more secure?

=
With the current AODVv2 specification, if I was to produce a aodvv2-sec-thr=
eats draft, it would be much simpler:=C2=A0

=C2=A0=
 =C2=A0- one single compromised router can easily jam the whole network (RR=
EQ flooding), or even bring down the whole network (remember the multicast =
RERR?) because of the transit-trust model used.=C2=A0

<=
div>=C2=A0 - with my limited knowledge, as future work, there is no easy wa=
y to protect the message because of the reconstructed and length-varied mes=
sage regenerated in every hop.=C2=A0


Even *if* security was acceptable as future work (it is not, but as =
a thought experiment, let's assume), there is no easy way to protect th=
e message because of the reconstructed and length-varied message regenerate=
d in every hop.=C2=A0

Securing a reactive protocol=
 requires different considerations than does securing a proactive protocol,=
 but there has been work done in this area, and other WG participants have =
raised both their concerns, and suggestions to security architectures, and =
protocol architectures (better) able to accommodate security, a long time a=
go. I don't see those works, nor the suggestions and comments made, ref=
lected or considered in revision -15 of the draft. Especially, the current =
design based on message regeneration makes the future extension to the secu=
rity very hard, as has been reiterated repeatedly.

Abdussalam doesn't agree with me on my observation on "Lack=
 of response from the author team on the comments. " -- this is an exa=
mple.=C2=A0

regards

J=
iazi

btw, I would like to confirm with the WG chai=
r: the WGLC is from April 20th to May 4th, right?
=C2=A0
=C2=A0



Regards,

Charlie P.






On 4/21/2016 11:24 AM, John Dowdell wrote:



All



I believe we=E2=80=99re going about this the wrong way, and we=E2=80=99re s=
etting ourselves an impossible target at which we are bound to fail.



BCP 9, governing the Internet Standards process, section 4.1.1 deals with t=
he first level of maturity, termed Proposed Standard. To paraphrase, a Prop=
osed Standard is supposed to be as correct as we can make it, but there is =
no requirement to have made an implementation. Since no engineer has ever w=
ritten a fully correct specification before cutting metal, it may be expect=
ed that there are some areas which will need attention later on, at Draft S=
tandard if we ever wanted to go that far. I=E2=80=99ll say now that one are=
a in AODVv2 will need some work later, that of hop-by-hop security in an ad=
 hoc network. This is because nobody has really cracked that problem yet; s=
ome real bright people are grappling with that right now over in DTN. The w=
ork in our own group on Identity Based Signatures will help but there is st=
ill ground to cover. However the actual level of security is not for AODVv2=
 to mandate, it is for the implementor and system integrator, based on an a=
ssessment of the likely risk and the thickness of their wallet.



It is clear to me that few will make an independent implementation without =
the RFC stamp. This much is obvious in modems fitted with DLEP; there are j=
ust four such implementations I know of, and two of those were written with=
 the encouragement of author team members, but I know of many more who are =
just waiting for the dust to settle so they can make the business case to p=
roceed. Allow AODVv2 to get to RFC and we=E2=80=99ll encourage others to us=
e it and get some feedback.



Regards

John

_______________________________________________

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





--001a11435430015fc5053104b07c--


From nobody Thu Apr 21 14:00: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 A66D212D6C7 for ; Thu, 21 Apr 2016 14:00:04 -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 nvcfAHtYoZMo for ; Thu, 21 Apr 2016 14:00:02 -0700 (PDT)
Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 4FB8612DDC2 for ; Thu, 21 Apr 2016 14:00:02 -0700 (PDT)
Received: by mail-wm0-x242.google.com with SMTP id n3so24642620wmn.1 for ; Thu, 21 Apr 2016 14:00:02 -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; bh=TzjAjI0ETjD6AWjcV8oPF8BqWvBY3Vx1ydsQj47+gBs=; b=AdG2CpMEVHash/axOxBr4s/Amz281Qiqb1VywcPG82mzIu+yo22QG6txzUHkCiW8oQ qhz04+NPwf/EyaU9zcQcy+M1gdGLSmNu541UaKn76ZODZSP8qBhVGR8/fI+sE2vFYiA2 jv3UyYhqZyzlrRo53CdYLqdAH0if1IdBKIAiJNc2HGTuD9BVidczaQsKCw7Ny5aZmyYD /T3NhpA7umC5sWTBcOuy4ntP/Woo8vzLmPH0vjh93wADy+bRzSd1ItEKkugBrtblolgV FtXJk1JRCBI9fLpiJ31zIO0TQgIwgXbTrAvjMYm0iOM44ws/wERmdtktGzTIFXIU3v9U A7Hg==
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; bh=TzjAjI0ETjD6AWjcV8oPF8BqWvBY3Vx1ydsQj47+gBs=; b=bu0DsobhyjpRRLP0Rt1W/RwEV/TiqN33Kzr0TdDuXDgTnuY+JuLUebMdwcwSVkjTth AlZxCEbNa+ivBBQ4PDjoOHxjlJvGX9WJ6yx0bI5sArbDrcM6zBLy38RT+0JcA2u7Si5r 8hw2WEhrP+Mz+jC13JDLyCKlXRAIiVGtBE7d5/7R/6N1Pw0sz7yIvvV3bC40VPTlXPgU ZraQPQkFeyBl7UurQ1+livCTUpDNZ9BkcXXKRlQ1OXpploNRoqvPRrJYRgHzj07IAPwQ 30rwLs9S1MNZuFehVCzGS1Cg9vU4oUo67LypYEc8JcSURwjgQpgmgoc67Mk+yE94smsJ 3buw==
X-Gm-Message-State: AOPr4FVVfuADwlhJUp1eZZFMMCI4x/2sNe3z2rXDYS5FF2BLeNaVh9jGLxmOrXCoye5IU0Yp9qodmPXqxxnkYQ==
MIME-Version: 1.0
X-Received: by 10.194.6.36 with SMTP id x4mr16640663wjx.122.1461272400728; Thu, 21 Apr 2016 14:00:00 -0700 (PDT)
Sender: yi.jiazi@gmail.com
Received: by 10.194.153.166 with HTTP; Thu, 21 Apr 2016 14:00:00 -0700 (PDT)
In-Reply-To: 
References:    <927E6489-D927-4670-A24C-5A5D9B58C05D@gmail.com> <57191FDD.5010707@earthlink.net> 
Date: Thu, 21 Apr 2016 23:00:00 +0200
X-Google-Sender-Auth: r3oKyA7SHaRJrfTniqHNb-fc9uM
Message-ID: 
From: Jiazi YI 
To: "manet@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b5d295c5d9abc053104fe79
Archived-At: 
Subject: Re: [manet] New AODVv2 draft and status
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, 21 Apr 2016 21:00:04 -0000

--047d7b5d295c5d9abc053104fe79
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

And by simply searching the archive, I would like to point out that those
comments are nothing new.

In the comments from Thomas in 2010 (6 years ago), the issue has been
brought out in
http://www.ietf.org/mail-archive/web/manet/current/msg11858.html , I quote:


   In situations where routing information or router identity are
   suspect, integrity and authentication techniques SHOULD be applied to
   DYMO messages.  In these situations, routing information that is
   distributed over multiple hops SHOULD also verify the integrity and
   identity of information based on originator of the routing
   information.

 This is really difficult to do, in case messages are mutable
in-transit, which appears to be the case for RERR and RM's; i.e. for all
DYMO messages. For that reason, using SHOULD is - imo - dangerous here.
Also, for that reason, I think that this issue of mutable messages deserves
being called out explicitly in this section, especially if there are known
or recommended ways of handling this (as is the case, for example, in the
security considerations section of RFC5444 regarding the mutable header
fields for hop-count/hop-limit of messages.

Then related comments were repeated again and again. Isn't enough to bring
the attention of the authors? In fact, the situation get even worse by
changing the strategy to regenerating messages.

best

Jiazi

On Thu, Apr 21, 2016 at 10:38 PM, Jiazi YI  wrote:

> Hi,
>
>
> On Thu, Apr 21, 2016 at 8:45 PM, Charlie Perkins <
> charles.perkins@earthlink.net> wrote:
>
>> 
>>
>> Regarding security: if AODVv2 were to solve all the possible security
>> exposures of ad hoc networks, it would be historic and worthy of
>> publication -- probably would win paper of the year. Needless to say, th=
at
>> was never part of the charter.
>>
>
>
> But security and its consideration are part of every specification.
>
> As one who co-authored several vulnerability analysis drafts/RFCs
> (ndhp-sec-threats, smf-sec-threats, olsrv2-sec-threats), what we always d=
o
> for a protocol is:
>
>   - assuming that we have a compromised router in the network, what can i=
t
> do to break the network? What's the consequences? What about if there are
> several of them?
>
>   - what about if there are mis-configured routers or wrong-implemented
> routers?
>
>   - what kind of threats can be mitigated by existed security measurement=
s
> (like RFC 7182/7183)?
>
>   - what kind of future work can be done to make the protocol more secure=
?
>
> With the current AODVv2 specification, if I was to produce a
> aodvv2-sec-threats draft, it would be much simpler:
>
>    - one single compromised router can easily jam the whole network (RREQ
> flooding), or even bring down the whole network (remember the multicast
> RERR?) because of the transit-trust model used.
>
>   - with my limited knowledge, as future work, there is no easy way to
> protect the message because of the reconstructed and length-varied messag=
e
> regenerated in every hop.
>
>
> Even *if* security was acceptable as future work (it is not, but as a
> thought experiment, let's assume), there is no easy way to protect the
> message because of the reconstructed and length-varied message regenerate=
d
> in every hop.
>
> Securing a reactive protocol requires different considerations than does
> securing a proactive protocol, but there has been work done in this area,
> and other WG participants have raised both their concerns, and suggestion=
s
> to security architectures, and protocol architectures (better) able to
> accommodate security, a long time ago. I don't see those works, nor the
> suggestions and comments made, reflected or considered in revision -15 of
> the draft. Especially, the current design based on message regeneration
> makes the future extension to the security very hard, as has been
> reiterated repeatedly.
>
> Abdussalam doesn't agree with me on my observation on "Lack of response
> from the author team on the comments. " -- this is an example.
>
> regards
>
> Jiazi
>
> btw, I would like to confirm with the WG chair: the WGLC is from April
> 20th to May 4th, right?
>
>
>
>>
>> Regards,
>> Charlie P.
>>
>>
>>
>> On 4/21/2016 11:24 AM, John Dowdell wrote:
>>
>>> All
>>>
>>> I believe we=E2=80=99re going about this the wrong way, and we=E2=80=99=
re setting
>>> ourselves an impossible target at which we are bound to fail.
>>>
>>> BCP 9, governing the Internet Standards process, section 4.1.1 deals
>>> with the first level of maturity, termed Proposed Standard. To paraphra=
se,
>>> a Proposed Standard is supposed to be as correct as we can make it, but
>>> there is no requirement to have made an implementation. Since no engine=
er
>>> has ever written a fully correct specification before cutting metal, it=
 may
>>> be expected that there are some areas which will need attention later o=
n,
>>> at Draft Standard if we ever wanted to go that far. I=E2=80=99ll say no=
w that one
>>> area in AODVv2 will need some work later, that of hop-by-hop security i=
n an
>>> ad hoc network. This is because nobody has really cracked that problem =
yet;
>>> some real bright people are grappling with that right now over in DTN. =
The
>>> work in our own group on Identity Based Signatures will help but there =
is
>>> still ground to cover. However the actual level of security is not for
>>> AODVv2 to mandate, it is for the implementor and system integrator, bas=
ed
>>> on an assessment of the likely risk and the thickness of their wallet.
>>>
>>> It is clear to me that few will make an independent implementation
>>> without the RFC stamp. This much is obvious in modems fitted with DLEP;
>>> there are just four such implementations I know of, and two of those we=
re
>>> written with the encouragement of author team members, but I know of ma=
ny
>>> more who are just waiting for the dust to settle so they can make the
>>> business case to proceed. Allow AODVv2 to get to RFC and we=E2=80=99ll =
encourage
>>> others to use it and get some feedback.
>>>
>>> Regards
>>> John
>>> _______________________________________________
>>> 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
>>
>
>

--047d7b5d295c5d9abc053104fe79
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


And by simply searching the archive, I would like to =
point out that those comments are nothing new.

In =
the comments from Thomas in 2010 (6 years ago), the issue has been brought =
out in http://www.ietf.org/mail-archive/web/manet/current/msg11858.html , I quote:=C2=A0


<DYMO&g=
t; =C2=A0 In situations where routing information or router identity are
=C2=A0 =C2=A0suspect, integrity and authentication techniques SHOUL=
D be applied to
=C2=A0 =C2=A0DYMO messages.=C2=A0 In these situat=
ions, routing information that is
=C2=A0 =C2=A0distributed over m=
ultiple hops SHOULD also verify the integrity and
=C2=A0 =C2=A0id=
entity of information based on originator of the routing
=C2=A0 =
=C2=A0information.

<TC> This is really diffi=
cult to do, in case messages are mutable in-transit, which appears to be th=
e case for RERR and RM's; i.e. for all DYMO messages. For that reason, =
using SHOULD is - imo - dangerous here. Also, for that reason, I think that=
 this issue of mutable messages deserves being called out explicitly in thi=
s section, especially if there are known or recommended ways of handling th=
is (as is the case, for example, in the security considerations section of =
RFC5444 regarding the mutable header fields for hop-count/hop-limit of mess=
ages.




On T=
hu, Apr 21, 2016 at 10:38 PM, Jiazi YI <ietf@jiaziyi.com> wro=
te:
Hi,=C2=A0
=


On Thu, Apr 2=
1, 2016 at 8:45 PM, Charlie Perkins <charles.perkins@earthlink=
.net> wrote:
<snip>



Regarding security: if AODVv2 were to solve all the possible security expos=
ures of ad hoc networks, it would be historic and worthy of publication -- =
probably would win paper of the year. Needless to say, that was never part =
of the charter.


B=
ut security and its consideration are part of every specification.=C2=A0

As one who co-authored several vulnerability analysi=
s drafts/RFCs (ndhp-sec-threats, smf-sec-threats, olsrv2-sec-threats), what=
 we always do for a protocol is:

=C2=A0 - assuming=
 that we have a compromised router in the network, what can it do to break =
the network? What's the consequences? What about if there are several o=
f them?

=C2=A0 - what about if there are mis-confi=
gured routers or wrong-implemented routers?

=C2=A0=
 - what kind of threats can be mitigated by existed security measurements (=
like RFC 7182/7183)?=C2=A0

=C2=A0 - what kind of f=
uture work can be done to make the protocol more secure?

With the current AODVv2 specification, if I was to produce a aodvv2-=
sec-threats draft, it would be much simpler:=C2=A0

=C2=A0 =C2=A0- one single compromised router can easily jam the whole netw=
ork (RREQ flooding), or even bring down the whole network (remember the mul=
ticast RERR?) because of the transit-trust model used.=C2=A0

=

=C2=A0 - with my limited knowledge, as future work, there is no =
easy way to protect the message because of the reconstructed and length-var=
ied message regenerated in every hop.=C2=A0


Even *if* security was acceptable as future work (it is not, =
but as a thought experiment, let's assume), there is no easy way to pro=
tect the message because of the reconstructed and length-varied message reg=
enerated in every hop.=C2=A0

Securing a reactive p=
rotocol requires different considerations than does securing a proactive pr=
otocol, but there has been work done in this area, and other WG participant=
s have raised both their concerns, and suggestions to security architecture=
s, and protocol architectures (better) able to accommodate security, a long=
 time ago. I don't see those works, nor the suggestions and comments ma=
de, reflected or considered in revision -15 of the draft. Especially, the c=
urrent design based on message regeneration makes the future extension to t=
he security very hard, as has been reiterated repeatedly.
<=
br>
Abdussalam doesn't agree with me on my observation on &qu=
ot;Lack of response from the author team on the comments. " -- this is=
 an example.=C2=A0

regards

Jiazi

btw, I would like to confirm with the =
WG chair: the WGLC is from April 20th to May 4th, right?
=C2=A0
=C2=A0



Regards,

Charlie P.






On 4/21/2016 11:24 AM, John Dowdell wrote:



All



I believe we=E2=80=99re going about this the wrong way, and we=E2=80=99re s=
etting ourselves an impossible target at which we are bound to fail.



BCP 9, governing the Internet Standards process, section 4.1.1 deals with t=
he first level of maturity, termed Proposed Standard. To paraphrase, a Prop=
osed Standard is supposed to be as correct as we can make it, but there is =
no requirement to have made an implementation. Since no engineer has ever w=
ritten a fully correct specification before cutting metal, it may be expect=
ed that there are some areas which will need attention later on, at Draft S=
tandard if we ever wanted to go that far. I=E2=80=99ll say now that one are=
a in AODVv2 will need some work later, that of hop-by-hop security in an ad=
 hoc network. This is because nobody has really cracked that problem yet; s=
ome real bright people are grappling with that right now over in DTN. The w=
ork in our own group on Identity Based Signatures will help but there is st=
ill ground to cover. However the actual level of security is not for AODVv2=
 to mandate, it is for the implementor and system integrator, based on an a=
ssessment of the likely risk and the thickness of their wallet.



It is clear to me that few will make an independent implementation without =
the RFC stamp. This much is obvious in modems fitted with DLEP; there are j=
ust four such implementations I know of, and two of those were written with=
 the encouragement of author team members, but I know of many more who are =
just waiting for the dust to settle so they can make the business case to p=
roceed. Allow AODVv2 to get to RFC and we=E2=80=99ll encourage others to us=
e it and get some feedback.



Regards

John

_______________________________________________

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








--047d7b5d295c5d9abc053104fe79--


From nobody Thu Apr 21 14:21: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 7DC1312DDC3 for ; Thu, 21 Apr 2016 14:21:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.715
X-Spam-Level: 
X-Spam-Status: No, score=-3.715 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, 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 r8gqwZKqgU0j for ; Thu, 21 Apr 2016 14:21:11 -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 3FBE412E85C for ; Thu, 21 Apr 2016 14:21:10 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=H02TqKBzbsEKi7S0C541F2RBVsUtN8wiWVBHF3YN7uxoNGKfaOr/YzaxXjpWj2r+; h=Received:Subject:To:References:Cc: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-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1atM25-0004GO-7z; Thu, 21 Apr 2016 17:21:05 -0400
To: Jiazi YI 
References:    <927E6489-D927-4670-A24C-5A5D9B58C05D@gmail.com> <57191FDD.5010707@earthlink.net> 
From: Charlie Perkins 
Message-ID: <5719443D.8020801@earthlink.net>
Date: Thu, 21 Apr 2016 14:21:01 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030202060209080201030905"
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7cf53b858d45e3ddf9b847df5f0e8686e350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 21 Apr 2016 21:21:14 -0000

This is a multi-part message in MIME format.
--------------030202060209080201030905
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello Jiazi,

Follow-up below...  notably I probably should not be doing email today 
since I am ill, but nevertheless you certainly deserve answers...

On 4/21/2016 1:38 PM, Jiazi YI wrote:
> Hi,
>
>
> On Thu, Apr 21, 2016 at 8:45 PM, Charlie Perkins 
> > 
> wrote:
>
>     
>
>     Regarding security: if AODVv2 were to solve all the possible
>     security exposures of ad hoc networks, it would be historic and
>     worthy of publication -- probably would win paper of the year.
>     Needless to say, that was never part of the charter.
>
>
>
> But security and its consideration are part of every specification.

And also part of AODVv2 specification.


>
> As one who co-authored several vulnerability analysis drafts/RFCs 
> (ndhp-sec-threats, smf-sec-threats, olsrv2-sec-threats), what we 
> always do for a protocol is:
>
>   - assuming that we have a compromised router in the network, what 
> can it do to break the network? What's the consequences? What about if 
> there are several of them?
>
>   - what about if there are mis-configured routers or 
> wrong-implemented routers?
>
>   - what kind of threats can be mitigated by existed security 
> measurements (like RFC 7182/7183)?
>
>   - what kind of future work can be done to make the protocol more secure?

We have tried to do exactly these things, except for the last one. I 
have read a lot of Security Considerations sections, and that last one 
is by no means universally included.

>
> With the current AODVv2 specification, if I was to produce a 
> aodvv2-sec-threats draft, it would be much simpler:
>
>    - one single compromised router can easily jam the whole network 
> (RREQ flooding), or even bring down the whole network (remember the 
> multicast RERR?) because of the transit-trust model used.
>
>   - with my limited knowledge, as future work, there is no easy way to 
> protect the message because of the reconstructed and length-varied 
> message regenerated in every hop.

Well, I am somewhat happy to see that you are agreeing with me.  I did 
produce an e2e draft that has some protections, and asked for comments, 
and offered it as an adjunct to the current draft.

>
>
> Even *if* security was acceptable as future work (it is not, but as a 
> thought experiment, let's assume), there is no easy way to protect the 
> message because of the reconstructed and length-varied message 
> regenerated in every hop.

This is not true.  As is usual in such cases, one has to identify the 
parts that may modified as the packet goes from source to destination, 
and provide some way to verify the authenticity of those fields.


>
> Securing a reactive protocol requires different considerations than 
> does securing a proactive protocol, but there has been work done in 
> this area, and other WG participants have raised both their concerns, 
> and suggestions to security architectures, and protocol architectures 
> (better) able to accommodate security, a long time ago. I don't see 
> those works, nor the suggestions and comments made, reflected or 
> considered in revision -15 of the draft. Especially, the current 
> design based on message regeneration makes the future extension to the 
> security very hard, as has been reiterated repeatedly.
>
> Abdussalam doesn't agree with me on my observation on "Lack of 
> response from the author team on the comments. " -- this is an example.
>

If we missed some things, please be more specific.  But it is factually 
incorrect to suggest that we have not been responsive to the comments.  
I have personally rewritten large parts of the Security Considerations 
twice in response, as well as offered a lot of text during the time when 
other co-authors have held the editorial pen.

Please excuse if I must delay further comment.

Regards,
Charlie P.


--------------030202060209080201030905
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hello Jiazi,

    

    Follow-up below...  notably I probably should not be doing email
    today since I am ill, but nevertheless you certainly deserve
    answers...

    

    
On 4/21/2016 1:38 PM, Jiazi YI wrote:

    

    

      
      

        
Hi, 

        

        


          
On Thu, Apr 21, 2016 at 8:45 PM,
            Charlie Perkins <charles.perkins@earthlink.net>
            wrote:

            
<snip>

              

              Regarding security: if AODVv2 were to solve all the
              possible security exposures of ad hoc networks, it would
              be historic and worthy of publication -- probably would
              win paper of the year. Needless to say, that was never
              part of the charter.

            

            


            

            


            

            
But security and its consideration are part of every
              specification. 

            

          

        

      

    

    

    And also part of AODVv2 specification.

    

    

    

      

        

          

            


            

            
As one who co-authored several vulnerability analysis
              drafts/RFCs (ndhp-sec-threats, smf-sec-threats,
              olsrv2-sec-threats), what we always do for a protocol is:

            


            

            
  - assuming that we have a compromised router in the
              network, what can it do to break the network? What's the
              consequences? What about if there are several of them?

            


            

            
  - what about if there are mis-configured routers or
              wrong-implemented routers?

            


            

            
  - what kind of threats can be mitigated by existed
              security measurements (like RFC 7182/7183)? 

            


            

            
  - what kind of future work can be done to make the
              protocol more secure?

          

        

      

    

    

    We have tried to do exactly these things, except for the last one. 
    I have read a lot of Security Considerations sections, and that last
    one is by no means universally included.

    

    

      

        

          

            


            

            
With the current AODVv2 specification, if I was to
              produce a aodvv2-sec-threats draft, it would be much
              simpler: 

            


            

            
   - one single compromised router can easily jam the
              whole network (RREQ flooding), or even bring down the
              whole network (remember the multicast RERR?) because of
              the transit-trust model used. 

            


            

            
  - with my limited knowledge, as future work, there is
              no easy way to protect the message because of the
              reconstructed and length-varied message regenerated in
              every hop.

          

        

      

    

    

    Well, I am somewhat happy to see that you are agreeing with me.  I
    did produce an e2e draft that has some protections, and asked for
    comments, and offered it as an adjunct to the current draft.

    

    

      

        

          

            


            

            


            

            

              
Even *if* security was acceptable as future work (it
                is not, but as a thought experiment, let's assume),
                there is no easy way to protect the message because of
                the reconstructed and length-varied message regenerated
                in every hop.

            

          

        

      

    

    

    This is not true.  As is usual in such cases, one has to identify
    the parts that may modified as the packet goes from source to
    destination, and provide some way to verify the authenticity of
    those fields.

    

    

    

      

        

          

            

              


              

              
Securing a reactive protocol requires different
                considerations than does securing a proactive protocol,
                but there has been work done in this area, and other WG
                participants have raised both their concerns, and
                suggestions to security architectures, and protocol
                architectures (better) able to accommodate security, a
                long time ago. I don't see those works, nor the
                suggestions and comments made, reflected or considered
                in revision -15 of the draft. Especially, the current
                design based on message regeneration makes the future
                extension to the security very hard, as has been
                reiterated repeatedly.

            

            


            

            
Abdussalam doesn't agree with me on my observation on
              "Lack of response from the author team on the comments. "
              -- this is an example. 

            

            

          

        

      

    

    

    If we missed some things, please be more specific.  But it is
    factually incorrect to suggest that we have not been responsive to
    the comments.  I have personally rewritten large parts of the
    Security Considerations twice in response, as well as offered a lot
    of text during the time when other co-authors have held the
    editorial pen.

    

    Please excuse if I must delay further comment.

    

    Regards,

    Charlie P.

    

  


--------------030202060209080201030905--


From nobody Thu Apr 21 14:49: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 1AD5D12E115 for ; Thu, 21 Apr 2016 14:49:19 -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 3KoSP58AFvDJ for ; Thu, 21 Apr 2016 14:49:16 -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 9B4B812D50D for ; Thu, 21 Apr 2016 14:49:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id AF3A724E0BB; Thu, 21 Apr 2016 14:49:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461275355; bh=YciNdWNGgY850Qey/qf3BjhD8uvUIKDsU1YmK6rkinE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=C4RUZABcAEI++Lws1CVWjvNyWDrsFKZ5WAWEZPPSwBTpKtx+3E5gKbUDPH6LSG9f3 UGBTRk1J6CPRai0jSgDq6Nvf7024cb6OPEq9+jqQ/ufpnJ7pc6CYmU82KPwADLfSyQ A6pndC21pxSc9jTNbK5F7HUkRvfr89R6Osdr7nIc=
X-Virus-Scanned: Debian amavisd-new at maila2.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 maila2.tigertech.net (Postfix) with ESMTPSA id E78BC24B534; Thu, 21 Apr 2016 14:49:14 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-7C93B10E-E4F3-4017-858E-9072AAD0311A
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPad Mail (13F51a)
In-Reply-To: <5719443D.8020801@earthlink.net>
Date: Thu, 21 Apr 2016 23:49:12 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <6C9B7B54-B62C-463C-B851-0C951F9C159E@thomasclausen.org>
References:    <927E6489-D927-4670-A24C-5A5D9B58C05D@gmail.com> <57191FDD.5010707@earthlink.net>  <5719443D.8020801@earthlink.net>
To: Charlie Perkins 
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 21 Apr 2016 21:49:19 -0000

--Apple-Mail-7C93B10E-E4F3-4017-858E-9072AAD0311A
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable


> On 21 Apr 2016, at 23:21, Charlie Perkins  w=
rote:
>=20
> Hello Jiazi,
>=20
> Follow-up below...  notably I probably should not be doing email today sin=
ce I am ill,

First: take care of yourself, and do get well!

> but nevertheless you certainly deserve answers...
>=20
>> On 4/21/2016 1:38 PM, Jiazi YI wrote:
>> Hi,=20
>>=20
>>=20
>> On Thu, Apr 21, 2016 at 8:45 PM, Charlie Perkins  wrote:
>>> 
>>>=20
>>> Regarding security: if AODVv2 were to solve all the possible security ex=
posures of ad hoc networks, it would be historic and worthy of publication -=
- probably would win paper of the year. Needless to say, that was never part=
 of the charter.
>>=20
>>=20
>> But security and its consideration are part of every specification.
>=20
> And also part of AODVv2 specification.
>=20

For having relatively recently seen an I-D through to RFC, as I have stated m=
ultiple times, the requirements for the security considerations have evolved=
 considerably, since what you may be familiar with, or what you have been re=
ading in the past.

>=20
>>=20
>> As one who co-authored several vulnerability analysis drafts/RFCs (ndhp-s=
ec-threats, smf-sec-threats, olsrv2-sec-threats), what we always do for a pr=
otocol is:
>>=20
>>   - assuming that we have a compromised router in the network, what can i=
t do to break the network? What's the consequences? What about if there are s=
everal of them?
>>=20
>>   - what about if there are mis-configured routers or wrong-implemented r=
outers?
>>=20
>>   - what kind of threats can be mitigated by existed security measurement=
s (like RFC 7182/7183)?=20
>>=20
>>   - what kind of future work can be done to make the protocol more secure=
?
>=20
> We have tried to do exactly these things, except for the last one.  I have=
 read a lot of Security Considerations sections,

I repeat, for having relatively recently seen an I-D through to RFC, as I ha=
ve stated multiple times, the requirements for the security considerations h=
ave evolved considerably, since what you may be familiar with, or what you h=
ave been reading in the past.

> and that last one is by no means universally included.
>=20
>>=20
>> With the current AODVv2 specification, if I was to produce a aodvv2-sec-t=
hreats draft, it would be much simpler:=20
>>=20
>>    - one single compromised router can easily jam the whole network (RREQ=
 flooding), or even bring down the whole network (remember the multicast RER=
R?) because of the transit-trust model used.=20
>>=20
>>   - with my limited knowledge, as future work, there is no easy way to pr=
otect the message because of the reconstructed and length-varied message reg=
enerated in every hop.
>=20
> Well, I am somewhat happy to see that you are agreeing with me.  I did pro=
duce an e2e draft that has some protections, and asked for comments, and off=
ered it as an adjunct to the current draft.

As I have also pointed out repeatedly, the e2e draft that you propose inhibi=
ts extensibility-without-also-updating-the-e2e-draft - I.e., each possible f=
uture extension requires also respinning / updating / replacing that draft. A=
nd, as it would be, I am not actually sure that the e2e draft suffices, even=
 without considering extensions, given the things that can happen in a "rege=
neration of a message". Either way, even *if* the e2e draft was a solution, e=
xperience shows that it would have to advance in parallel with the protocol s=
pecification, and not as "a promised afterthought". The SEC-ADs won't have t=
he latter.

As I have also pointed out repeatedly, the solution to this problem is to do=
 away with "message regeneration". I have described *how* as well as the sec=
urity model that would go with that, in several  emails in the past -- email=
s which so far have not been considered by the authors..

>> Even *if* security was acceptable as future work (it is not, but as a tho=
ught experiment, let's assume), there is no easy way to protect the message b=
ecause of the reconstructed and length-varied message regenerated in every h=
op.
>=20
> This is not true.  As is usual in such cases, one has to identify the part=
s that may modified as the packet goes from source to destination, and provi=
de some way to verify the authenticity of those fields.
>=20

Which is greatly simplified if doing away with both the regeneration and the=
 e2e- Draft, as previously proposed, and repeatedly.

>> Securing a reactive protocol requires different considerations than does s=
ecuring a proactive protocol, but there has been work done in this area, and=
 other WG participants have raised both their concerns, and suggestions to s=
ecurity architectures, and protocol architectures (better) able to accommoda=
te security, a long time ago. I don't see those works, nor the suggestions a=
nd comments made, reflected or considered in revision -15 of the draft. Espe=
cially, the current design based on message regeneration makes the future ex=
tension to the security very hard, as has been reiterated repeatedly.
>>=20
>> Abdussalam doesn't agree with me on my observation on "Lack of response f=
rom the author team on the comments. " -- this is an example.=20
>=20
> If we missed some things, please be more specific.=20

Done, for this subject, above.=20

> But it is factually incorrect to suggest that we have not been responsive t=
o the comments.=20

No, that is factually accurate.

Several comments have been made, by myself and others, including proposals f=
or how to address security, as indicated in the above,  which (demonstrably,=
 least security would have been resolved) have not been addressed.

Thomas

> I have personally rewritten large parts of the Security Considerations twi=
ce in response, as well as offered a lot of text during the time when other c=
o-authors have held the editorial pen.
>=20
> Please excuse if I must delay further comment.
>=20
> Regards,
> Charlie P.
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

--Apple-Mail-7C93B10E-E4F3-4017-858E-9072AAD0311A
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 21 Apr 2016, at 23:2=
1, Charlie Perkins <char=
les.perkins@earthlink.net> wrote:


 =20
    
 =20
 =20
    Hello Jiazi,

    

    Follow-up below...  notably I probably should not be doing email
    today since I am ill,

First: take care o=
f yourself, and do get well!

 but nev=
ertheless you certainly deserve
    answers...

    

    
On 4/21/2016 1:38 PM, Jiazi YI wrote:
=

    

    

      
      

        
Hi, 

        

        


          
On Thu, Apr 21, 2016 at 8:45 PM,
            Charlie Perkins <charles.perkins@earthlink.net>
            wrote:

            
<snip>

              

              Regarding security: if AODVv2 were to solve all the
              possible security exposures of ad hoc networks, it would
              be historic and worthy of publication -- probably would
              win paper of the year. Needless to say, that was never
              part of the charter.

            

            


            

            


            

            
But security and its consideration are part of every
              specification. 

            

          

        

      

    

    

    And also part of AODVv2 specification.

    

For having relatively recently see=
n an I-D through to RFC, as I have stated multiple times, the requirements f=
or the security considerations have evolved considerably, since what y=
ou may be familiar with, or what you have been reading in the past.


    

    

      

        

          

            


            

            
As one who co-authored several vulnerability analysis
              drafts/RFCs (ndhp-sec-threats, smf-sec-threats,
              olsrv2-sec-threats), what we always do for a protocol is:
            


            

            
  - assuming that we have a compromised router in the
              network, what can it do to break the network? What's the
              consequences? What about if there are several of them?

            


            

            
  - what about if there are mis-configured routers or
              wrong-implemented routers?

            


            

            
  - what kind of threats can be mitigated by existed
              security measurements (like RFC 7182/7183)? 

            


            

            
  - what kind of future work can be done to make the
              protocol more secure?

          

        

      

    

    

    We have tried to do exactly these things, except for the last one. =

    I have read a lot of Security Considerations sections, 

I=
 repeat, for having relatively recently seen an I-D through to RFC, as I hav=
e stated multiple times, the requirements for the security considerations ha=
ve evolved considerably, since what you may be familiar with, or=
 what you have been reading in the past.

and that last
    one is by no means universally included.

    

    

      

        

          

            


            

            
With the current AODVv2 specification, if I was to
              produce a aodvv2-sec-threats draft, it would be much
              simpler: 

            


            

            
   - one single compromised router can easily jam=
 the
              whole network (RREQ flooding), or even bring down the
              whole network (remember the multicast RERR?) because of
              the transit-trust model used. 

            


            

            
  - with my limited knowledge, as future work, there i=
s
              no easy way to protect the message because of the
              reconstructed and length-varied message regenerated in
              every hop.

          

        

      

    

    

    Well, I am somewhat happy to see that you are agreeing with me.  I
    did produce an e2e draft that has some protections, and asked for
    comments, and offered it as an adjunct to the current draft.

As I have also pointed out repeatedly, the e2e draft that you p=
ropose inhibits extensibility-without-also-updating-the-e2e-draft - I.e., ea=
ch possible future extension requires also respinning / updating / replacing=
 that draft. And, as it would be, I am not actually sure that the e2e draft s=
uffices, even without considering extensions, given the things that can happ=
en in a "regeneration of a message". Either way, even *if* the e2e draft was=
 a solution, experience shows that it would have to advance in parallel with=
 the protocol specification, and not as "a promised afterthought". The SEC-A=
Ds won't have the latter.

As I have also poi=
nted out repeatedly, the solution to this problem is to do away with "messag=
e regeneration". I have described *how* as well as the security model that w=
ould go with that, in several  emails in the past -- emails which so fa=
r have not been considered by the authors..


    

      

        

          

           =20
           =20
            

              
Even *if* security was acceptable as future work (it
                is not, but as a thought experiment, let's assume),
                there is no easy way to protect the message because of
                the reconstructed and length-varied message regenerated
                in every hop.

            

          

        

      

    

    

    This is not true.  As is usual in such cases, one has to identify
    the parts that may modified as the packet goes from source to
    destination, and provide some way to verify the authenticity of
    those fields.

    

Which is greatly simplified if doi=
ng away with both the regeneration and the e2e- Draft, as previously propose=
d, and repeatedly.

<=
blockquote cite=3D"mid:CAN1bDFyLdnkRBe_qQLW4JFNJxGzOs8=3DkTTCbRwrnRh+0WprDyQ=
@mail.gmail.com" type=3D"cite">
<=
div class=3D"gmail_quote">

              
Securing a reactive protocol requires different
                considerations than does securing a proactive protocol,
                but there has been work done in this area, and other WG
                participants have raised both their concerns, and
                suggestions to security architectures, and protocol
                architectures (better) able to accommodate security, a
                long time ago. I don't see those works, nor the
                suggestions and comments made, reflected or considered
                in revision -15 of the draft. Especially, the current
                design based on message regeneration makes the future
                extension to the security very hard, as has been
                reiterated repeatedly.

            

            


            

            
Abdussalam doesn't agree with me on my observation on
              "Lack of response from the author team on the comments. "
              -- this is an example. 

            

            

          

        

      

    

    

    If we missed some things, please be more specific. 

Done, for this subject, above. 

 But it is
    factually incorrect to suggest that we have not been responsive to
    the comments. 

No, that is factual=
ly accurate.

Several comments have been made, by my=
self and others, including proposals for how to address security, as indicat=
ed in the above,  which (demonstrably, least security would have been r=
esolved) have not been addressed.

Thomas
=

 I have personally rewritten large parts o=
f the
    Security Considerations twice in response, as well as offered a lot
    of text during the time when other co-authors have held the
    editorial pen.

    

    Please excuse if I must delay further comment.

    

    Regards,

    Charlie P.

    

 =20


____________________=
___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai=
lman/listinfo/manet
=

--Apple-Mail-7C93B10E-E4F3-4017-858E-9072AAD0311A--


From nobody Fri Apr 22 01:38:39 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 4006412EA1F for ; Fri, 22 Apr 2016 01:38:37 -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 Jo9JXLhCTEHT for ; Fri, 22 Apr 2016 01:38:35 -0700 (PDT)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 0FAD812EA1C for ; Fri, 22 Apr 2016 01:38:35 -0700 (PDT)
Received: by mail-qg0-x236.google.com with SMTP id f74so51326326qge.2 for ; Fri, 22 Apr 2016 01:38:35 -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=rUXLviTMYkWfSmttgvxPEHz6vaarPG20YIjScRh6xeg=; b=y52t3euDOn8Yrh3R+kwZfNuFOIN+C2Ary43gJQ4aBrRhM3p/ShX/985wpGWh6JMIif 1HXuZNTNOqYSMnCRIflynQtMfXsSQbItn6gp9woT6U5hIFJjFGEoYuF3sFCLV1thTRzx d83ecx6i1xyVH1fkVwAUBJek5Sk5TV27T0Zxv2nhQ4dBO04UVgWEmdUx9Ib+jdA6/CJp x8IpNB9vGUHfssylVTSVBEMUsgWWKo9JKLMTdOVS3Ff61xE0/VqRdhHSAj62TPJ/t9L/ y3zHObviEj8gTT0b0yfRhddJl3flX7EuxVul3Byv9cBxY1TdjuZPgrjFtWQlxPI420z0 uvSg==
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=rUXLviTMYkWfSmttgvxPEHz6vaarPG20YIjScRh6xeg=; b=fzF1EQ58VYUPR+c+kNaVJ234QnAMzl8rGc3YMlsVK242iRG2QQt/zoUyJPa3ohXWDA rfnN/RXxVZROBRfiqhSy/UY0gE6Bj5pDZ22NNH4WK0o73unn8wabQ7Rg/xxbyjz1+hZc SyCikqhpsKSREcL6XJAbs/SiWsNe6tVenCl9CUkVRkKAZuW+jEjg+kgGW9r3bHLBJz2F u6fI1Y+xtqjdieEMOwP55PAGNw4EAXTki/KDBximykJyzFaJTW3iQ+KDvnIm4QAoUSmX hALe06pXER8nO6j3INhcaRVNBQOfqimgMAO3g6pFQ3GiyH2ln7gY/8tJ1MCdf5sClSFI J8qA==
X-Gm-Message-State: AOPr4FUlz6X92Sxlkv8dGJm544raqU/HDfnoGNRwVs9OIE6+JPaNx/coQcH213WhGqEDqycp3eB7iJz4+psyyQ==
MIME-Version: 1.0
X-Received: by 10.140.100.225 with SMTP id s88mr20060445qge.76.1461314314178;  Fri, 22 Apr 2016 01:38:34 -0700 (PDT)
Received: by 10.140.43.52 with HTTP; Fri, 22 Apr 2016 01:38:34 -0700 (PDT)
In-Reply-To: <927E6489-D927-4670-A24C-5A5D9B58C05D@gmail.com>
References:    <927E6489-D927-4670-A24C-5A5D9B58C05D@gmail.com>
Date: Fri, 22 Apr 2016 10:38:34 +0200
Message-ID: 
From: Abdussalam Baryun 
To: John Dowdell 
Content-Type: multipart/alternative; boundary=001a1134f5fc9a1d6c05310ec052
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New AODVv2 draft and status
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, 22 Apr 2016 08:38:37 -0000

--001a1134f5fc9a1d6c05310ec052
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi John,

I understand your email that you want standard proposed status which we
wanted before, but did the WG chair or AD change their decision, I read
that they made a decision that either experimental RFC or no RFC. I think
this WG problem is to convince management again. So they don't give me
space for discussion about standard any more. My only choice is discussing
experimental and two weeks for completing it. Am I wrong?

AB

On Thu, Apr 21, 2016 at 8:24 PM, John Dowdell 
wrote:

>
> All
>
> I believe we=E2=80=99re going about this the wrong way, and we=E2=80=99re=
 setting
> ourselves an impossible target at which we are bound to fail.
>
> BCP 9, governing the Internet Standards process, section 4.1.1 deals with
> the first level of maturity, termed Proposed Standard. To paraphrase, a
> Proposed Standard is supposed to be as correct as we can make it, but the=
re
> is no requirement to have made an implementation. Since no engineer has
> ever written a fully correct specification before cutting metal, it may b=
e
> expected that there are some areas which will need attention later on, at
> Draft Standard if we ever wanted to go that far. I=E2=80=99ll say now tha=
t one area
> in AODVv2 will need some work later, that of hop-by-hop security in an ad
> hoc network. This is because nobody has really cracked that problem yet;
> some real bright people are grappling with that right now over in DTN. Th=
e
> work in our own group on Identity Based Signatures will help but there is
> still ground to cover. However the actual level of security is not for
> AODVv2 to mandate, it is for the implementor and system integrator, based
> on an assessment of the likely risk and the thickness of their wallet.
>
> It is clear to me that few will make an independent implementation withou=
t
> the RFC stamp. This much is obvious in modems fitted with DLEP; there are
> just four such implementations I know of, and two of those were written
> with the encouragement of author team members, but I know of many more wh=
o
> are just waiting for the dust to settle so they can make the business cas=
e
> to proceed. Allow AODVv2 to get to RFC and we=E2=80=99ll encourage others=
 to use it
> and get some feedback.
>
> Regards
> John
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

--001a1134f5fc9a1d6c05310ec052
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi John,

I understand your email th=
at you want standard proposed status which we wanted before, but did the WG=
 chair or AD change their decision, I read that they made a decision that e=
ither experimental RFC or no RFC. I think this WG problem is to convince ma=
nagement again. So they don't give me space for discussion about standa=
rd any more. My only choice is discussing experimental and two weeks for co=
mpleting it. Am I wrong?

AB

On Thu, Apr 21, 2016 at 8:24 PM, John Dowd=
ell <john.dowdell.ietf@gmail.com> wrote:


All



I believe we=E2=80=99re going about this the wrong way, and we=E2=80=99re s=
etting ourselves an impossible target at which we are bound to fail.



BCP 9, governing the Internet Standards process, section 4.1.1 deals with t=
he first level of maturity, termed Proposed Standard. To paraphrase, a Prop=
osed Standard is supposed to be as correct as we can make it, but there is =
no requirement to have made an implementation. Since no engineer has ever w=
ritten a fully correct specification before cutting metal, it may be expect=
ed that there are some areas which will need attention later on, at Draft S=
tandard if we ever wanted to go that far. I=E2=80=99ll say now that one are=
a in AODVv2 will need some work later, that of hop-by-hop security in an ad=
 hoc network. This is because nobody has really cracked that problem yet; s=
ome real bright people are grappling with that right now over in DTN. The w=
ork in our own group on Identity Based Signatures will help but there is st=
ill ground to cover. However the actual level of security is not for AODVv2=
 to mandate, it is for the implementor and system integrator, based on an a=
ssessment of the likely risk and the thickness of their wallet.



It is clear to me that few will make an independent implementation without =
the RFC stamp. This much is obvious in modems fitted with DLEP; there are j=
ust four such implementations I know of, and two of those were written with=
 the encouragement of author team members, but I know of many more who are =
just waiting for the dust to settle so they can make the business case to p=
roceed. Allow AODVv2 to get to RFC and we=E2=80=99ll encourage others to us=
e it and get some feedback.



Regards

John


_____________________=
__________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet





--001a1134f5fc9a1d6c05310ec052--


From nobody Fri Apr 22 02:05: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 871CD12E924 for ; Fri, 22 Apr 2016 02:05:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.89
X-Spam-Level: 
X-Spam-Status: No, score=-3.89 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, TRACKER_ID=1.306] 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 7hxqBMZMZhQd for ; Fri, 22 Apr 2016 02:05:06 -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 8766E12EA13 for ; Fri, 22 Apr 2016 02:05:05 -0700 (PDT)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1atX1K-002VaO-RK>; Fri, 22 Apr 2016 11:05:02 +0200
Received: from p548d7b4d.dip0.t-ipconnect.de ([84.141.123.77] helo=[192.168.46.209]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id <1atX1K-0047ap-8U>; Fri, 22 Apr 2016 11:05:02 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_3A06A814-A2DB-4444-92C2-C95E18B06575"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Lotte Steenbrink 
In-Reply-To: <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org>
Date: Fri, 22 Apr 2016 11:05:01 +0200
Message-Id: <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org>
To: Mobile Ad Hoc Networks mailing list 
X-Mailer: Apple Mail (2.3112)
X-Originating-IP: 84.141.123.77
X-ZEDAT-Hint: A
Archived-At: 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 09:05:10 -0000

--Apple-Mail=_3A06A814-A2DB-4444-92C2-C95E18B06575
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Thomas,

> Am 20.04.2016 um 11:54 schrieb Thomas Clausen =
:
>=20
> Lotte, all,
>=20
> On 19 Mar 2016, at 12:34, Lotte Steenbrink =
> =
wrote:
>=20
>> Hi Thomas,
>> thank you for reviewing AODVv2 yet again :) Some answers below:
>>=20
>>> Am 17.03.2016 um 17:00 schrieb ietf@thomasclausen.org =
:
>>>=20
>>> Dear all,
>>>=20
>>> Apologies for not having gotten this done sooner - day-job leaving =
few spare cycles.
>>>=20
>>> I=E2=80=99ve previously offered reviews and comments, and some of =
those have been addressed in the latest I-D =E2=80=94 others have not, =
but should be. I recall that there was some mail attempting to rebut =
parts of the review, and I will dig it out and reply to that.
>>>=20
>>=20
>> That wold be great.
>=20
> I am finding a bit of time here and there when there are holes in the =
agenda, and am (as you likely have noticed) backtracking through emails =
when I get a chance. Apologies, I hope that I will get to these emails =
this, or next week, but day-job eats in to the available time ;(
>=20
>>> Forwarding-vs-regeneration
>>> Recent exchanges on the list made me understand that protocol =
control messages are *not* forwarded, but are consumed at each hop, then =
a new message with (almost-but-not-quite) the same content is generated =
and transmitted.
>>=20
>> That=E2=80=99s what we=E2=80=99ve been trying to say all along! I=E2=80=
=99m really glad we=E2=80=99re having this conversation.
>=20
> Then, let us have it -- it's a central point to get right.
>=20
>>> I have thought some more on this (& read some of the exchanges on =
the list on this topic by Chris, Ulrich, and others), and I am convinced =
that this is not the right way to go, at least for the following =
reasons:
>>>=20
>>>=20
>>> 	o	It renders the hop-limit/hop-count fields in the RFC5444 =
message header useless.
>>> 		This would not be bad if the functionality offered by =
those fields was not useful
>>> 		=E2=80=94 sadly, it is. For example, for scope limited =
flooding (expanding ring search, and=20
>>> 		such) which may be of interest, and which require =
hop-limit.=20
>>> 		A hop-count field may also provide a =E2=80=9Ccheap=E2=80=9D=
 (in terms of overhead) additional piece
>>> 		of information to use conjunctively with a =E2=80=9Creal=E2=
=80=9D metric.
>>>=20
>>=20
>> I agree on the usefulness, which is why we were puzzled when we were =
told we weren=E2=80=99t allowed to use those fields (or, rather, that we =
were using them wrong, but that the right way to use them doesn=E2=80=99t =
work for AODvv2). I believe Vicky has written about this in more detail =
in previous discussions, and we were/are looking forward to reading your =
answers...
>=20
> So, the source generates a message, the message is forwarded through =
the network, with each intermediate router decrementing the hop limit =
and incrementing the hop count.
>=20
> As stated in the 5444-Usage document, when forwarding a message, the =
hop-limit/hop-count are modified, the rest of the message SHOULD not be.=20=

>=20
> That is specifically, one thing where I kinda would like 5444-usage to =
go further is "the message structure MUST in all conditions preserved =
when forwarding" - but still say "and it is RECOMMENDED that the value =
field of TLVs are also not modified".
>=20
> What this buys is several things, in the context of this protocol:
>=20
> 	o	hop-limit/hop-count could be useful for the usual=20
> 		purposes (ensuring that messages do not live forever,=20
> 		scope-limited flooding, =E2=80=A6)

Exactly.

>=20
> 	o	if the accumulated path metric is stored in a TLV value =
field, that=20
> 		value field can (with suitable disclaimer to call out =
"we know it is
> 		RECOMMENDED to not do this, but here's why we are OK in =
doing
> 		it anyways") be modified when forwarding the message, =
and
>=20

Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=E2=80=9D=
 language in the first place is that we=E2=80=99ve been told that =
whenever one bit in the message (apart from its header) is changed, the =
entire thing has to be regenerated. I=E2=80=99m starting to get the =
feeling we=E2=80=99ve just been misunderstanding each other for more =
than a year. :( Anyway, it seems like we=E2=80=99re getting close now, =
so yay.

> 	o	as that path metric field is in a message whose =
structure does not
> 		change, it will be "at the same place in the =
byte-stream" at each hop,
> 		which
> =09
> 	o	allows useful things such as deriving from RFC7182 a =
form of
> 		"when calculating the ICV, zero out that field in the =
message ' when
> 		  validating an ICV, also zero out that field" -- which =
goes one step
> 		  further (when coupled with a time stamp) than simple =
transitive trust,=20
> 		  but also

Well if that=E2=80=99d be possible, that=E2=80=99d solve a *huge* lump =
of problems. I=E2=80=99m guessing the remaining caveat would be that an =
attacker (or a buggy router) might still tamper with the metric value =
without being detected, which could divert routes (i.e. routes being =
established when they shouldn=E2=80=99t and dropped when they =
shouldn=E2=80=99t). Obviously this needs to be pointed out in the =
security considerations, but it=E2=80=99d be a massive improvement.=20
Do the other 5444 experts agree that we can do this? If yes, I=E2=80=99ll =
come up with some suggestions for suitable text tonight and run it by =
the list to see if it makes sense.

>=20
> 	o	allows even more fancy and useful (albeit experimental) =
things such
> 		as aggregate signatures to work correctly.
>=20
> Furthermore.....
>=20
>>> 		The only practical solution would be to re-introduce =
these functions by way of inserting a
>>> 		MessageTLV =E2=80=94 which (i) is not specified in this =
document, and (ii) which would just
>>> 		serve to render messages bigger than strictly needed.
>>=20
>> Exactly; we=E2=80=99d really like to avoid this as well.
>>=20
>=20
> ... It avoids the above, and....
>=20
>>>=20
>>> 		Scope limited flooding  does seem to be a necessary =
requirement, if for no
>>> 		other reason than to prevent information from =
=E2=80=9Ccirculating forever in the network=E2=80=9D.
>>=20
>> AODVv2=E2=80=99s duplicated detection hopefully should take care of =
that. Iirc, We interpreted your earlier E-Mails to (implicitly) mean =
that you think we should rely on that, since you said we can=E2=80=99t =
use the hop-limit/hop-count fields.
>>=20
>=20
> ....if done (proper forwarding with preservation of the structure, =
rather than regeneration which opens up the "this is a new message with =
potentially new structure" can of worms) as I describe, also addresses =
the above.
>=20
> With respect to what I said earlier when I said "can't use =
hop-limit/hop-count fields"....when you regenerate, you absolutely, =
definitely, can't.
>=20
> When you "regenerate" a message, that means "you construct a brand new =
message" which may shuffle addresses inside address blocks, or between =
address blocks, shuffle TLVs differently than they were originally, even =
use TLVs of different structure (e.g., single-value TLVs instead of =
multi-value TLVs).=20
>=20
> This means that some assumptions (such as when producing an ICV for =
the message, which depends on the byte order) don't hold. Well, they may =
not hold, so that means we can't assume that they do. Which means that =
the originator of a message cannot generate an ICV that can be correctly =
interpreted (which is what my next section in my original mail was =
about).
>=20
> Which means, in conclusion,  that the information in the message =
profoundly change -- and therefore these hop-count/hop-limit values do =
not even apply to "the information=E2=80=9C.=20

Okay, that makes sense. I thought we might have some wiggle room, saying =
=E2=80=9Cyes, we're constructing a new message, but that just happens to =
have a hop count that=E2=80=99s lastMessage.hopcount -1=E2=80=9D. But if =
your above outline is legal (which, as I said, we just thought we =
couldn=E2=80=99t do what you=E2=80=99ve described, and I=E2=80=99m =
pretty sure I=E2=80=99ve asked this list and Henning all kinds of =
questions revolving around this topic last spring), we won=E2=80=99t =
need hacks like those anyway, so I won=E2=80=99t entertain them any =
further. ;)

>=20
> However if proper forwarding with preservation of the structure, =
rather than regeneration which opens up the "this is a new message with =
potentially new structure" can of worms, as I (& Ulrich & others) have =
suggested, is taken to heart, it also addresses the issue below =
regarding end-to-end authentication (which, while still hard, is =
possible).
>=20
> A couple of more comments below
>=20
>>>=20
>>> 	o	It makes end-to-end authentication unnecessarily hard.
>>> 		I think Chris called this out already, but it bears =
repeating: S generates a message=20
>>> 		(say, a RREQ), and includes an ICV calculated over the =
content of the message.
>>> 		For any recipient to be able to validate the ICV, the =
message has to be exactly
>>> 		the same =E2=80=94 not just in content, but in structure =
=E2=80=94 as what was generated.
>>>=20
>>> 		=E2=80=9CRegenerating=E2=80=9D rather than =
=E2=80=9Cforwarding=E2=80=9D messages means, that the intermediate
>>> 		router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose =
a different structure (e.g., include TLVs
>>> 		in a different order).
>>>=20
>>> 		The proposal from =
https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00 =

>>> 		is to add constraints on (i) the set of elements to =
include in a signature and (ii) the
>>> 		order of these elements.
>>>=20
>>> 		One problem with that approach is (i): if an extension =
adds a message TLV, or an=20
>>> 		Address TLV, to a message, then that will not be =
=E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>>> 		Rather for *each* extension developed, an =E2=80=9Cupdates=
 e2esec=E2=80=9D clause needs to be done.
>>>=20
>>> 		I=E2=80=99d say that this approach would be prone to =
errors =E2=80=94 and add entropy to the process
>>> 		of designing protocol extensions. The alternative, a =
message being generated by the
>>> 		source and *forwarded* (as we do in OLSRv2, for example) =
would allow ICV TLVs=20
>>> 		(even, allow reuse of those specified for OLSRv2) for =
covering a message and=20
>>> 		extensions.
>>>=20
>>> 		=E2=80=9CBut what about the metrics value which will =
change on each hop=E2=80=9D, you may say?
>>> 		Fortunately, that is relatively easy to handle: simply =
zero out the value of that TLV when
>>> 		generating or verifying the ICV MessageTLV. And use =
Packet-TLVs for hop-by-hop=20
>>> 		authentication, if needed (but, see below).
>>>=20
>>> 	o	It prevents the use of more clever/advanced signature =
schemes/ICVs
>>> 		Aggregate signature algorithms ( =
https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf =
)
>>> 		exist, and an interesting use-case can be found in also =
reactive protocols, allowing verifying
>>> 		not =E2=80=9Cjust=E2=80=9D the end points, but also the =
intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D
>>> 		discussed above, or something smarter).
>>> 		Regeneration of messages, rather than forwarding, =
renders that impossible (or, if used,
>>> 		updating to  =
https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00 =
)
>>>=20
>>> There are other reasons, but the above are those that jump at me as =
immediate show-stoppers.
>>>=20
>>> I do honestly not see what possible benefit there is from =
=E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear =
inconveniences, and security is not the least of these. Insisting on =
=E2=80=9Cregeneration=E2=80=9D requires development of =E2=80=9Cnon-genera=
l workarounds=E2=80=9D as pointed out above.
>>=20
>> The possible benefit is that we need to accumulate & transport metric =
values somehow, and we can=E2=80=99t do that without regenerating at =
least parts of the message.
>> If we=E2=80=99re missing a solution here, please share it with us.
>>=20
>=20
> Done in the above.
>=20
>>>=20
>>> Security Considerations
>>=20
>> Just for context=E2=80=99s sake, did you review the security =
considerations in draft-ietf-manet-aodvv2-13 or the ones proposed in the =
thread =E2=80=9EAODVv2: Security considerations update=E2=80=9C?
>=20
> I did. It still is a far cry from passing the bar. I've posted on why =
in the past, and some more in this mail (which also contains some =
suggestions).

Just as a comment, the new Security Considerations and their =
reorganization were actually based on BCP72 (as suggested by Chris, I =
think?)=E2=80=93 if you have any concrete pointers where I missed =
something, I=E2=80=99d be glad to hear about them.

>=20
> I would suggest that settling the rearchitecturing to do forwarding, =
as I describe in the above, should be done, which would ease the =
security considerations issue considerably (and which would be necessary =
even if ignoring the security considerations, IMO, for this doc to go =
anywhere).=20
>=20
> With a new version covering that, the authors (I wanted to write =
"you", but decided to be inclusive) could you go look at the different =
security emails and perhaps start a separate thread on that, towards a =
resolution?

Sounds like a good plan, I=E2=80=99ll do that tonight as well (unless =
somebody beats me to it :D).

Best regards,
Lotte

>=20
>=20
> Best,
>=20
> Thomas
>=20
>=20
>>=20
>>> This is an always thorny subject. When OLSRv2 was going through the =
process we got a thorough education in how little we knew about security =
from the SEC-ADs, and had to spend about a year or so developing =
RFC7183. The bottom line is, that this protocol needs its =E2=80=9CRFC7183=
  equivalent=E2=80=9D, either as part of the main document, or as an =
independent document. currently, that is not the case.
>>>=20
>>> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration =
from RFC7183 might be aw good idea, as that was the most recent that =
went through the SEC AD. Regardless of how, however, a =E2=80=9Cmandatory =
to implement=E2=80=9D security mechanism most be specified (I think the =
right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D), in =
sufficient detail to ensure interoperable implementations.
>>>=20
>>> As an example, both [RFC6130] and [RFC7181] set out that that:
>>>=20
>>>       On receiving a ... message, a router MUST first check if the
>>>       message is invalid for processing by this router
>>>=20
>>> and then proceed to give a number of conditions that, each, will =
lead to a rejection of the message as "badly formed and therefore =
invalid for processing=E2=80=9D =E2=80=94 a list which RFC7183 then =
amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting =
=E2=80=9Crejection=E2=80=9D. Idem for message generation.
>>>=20
>>> If I was to do RFC7181/RFC6130 today, I would include that directly =
into the protocol specifications. It turned out to be more overhead (and =
slow down publication anyways) to do it as separate documents.
>>>=20
>>> Secondly, we need to be a lot more rigid in terms of what ICVs, =
Timestamps, etc. are added/removed, and what that brings.
>>>=20
>>> For example (with the assumption that messages are *forwarded* and =
*not* regenerated), this could be one option:
>>>=20
>>> 		o	When a RREQ, RREP message is generated, add an =
ICV Message TLV, which is calculated 
>>> 			 =E2=80=A6(take inspiration from RFC7183 here)
>>>=20
>>> 		o	When a RREQ, RREP message is transmitted  (by =
the source, or forwarded by an intermediary)
>>> 			in an RFC5444 packet, an ICV Packet TLV is added =
to the packet, which is calculated  =E2=80=A6
>>>=20
>>> 		o	When an RFC5444 packet is received, validate the =
ICV Packet TLV  and if the ICV doesn=E2=80=99t validate,
>>> 			discard the contained messages.
>>>=20
>>> 		o	When receiving a RREQ/RREP (either as =
destination, or as an intermediary), validate the ICV Message TLV=20
>>> 			 and if the ICV doesn=E2=80=99t =
validate, discard the message, do not process, do not forward.
>>>=20
>>> This is a different (and more flexible?) model than =E2=80=9Cjust=E2=80=
=9D transitive trust and =E2=80=9Cjust=E2=80=9D end-to-end trust =
discussed previously, and is enabled by the =E2=80=9Cforwarding=E2=80=9D =
bit described previously.
>>>=20
>>> Metrics
>>> I have asked this numerous times, but have not gotten any answer so =
I am escalating this again. Why is this document having a normative =
reference to RFC6551?
>>>=20
>>>    [RFC6551 <>]  Vasseur, JP., Ed., Kim, M., Ed., Pister, K., =
Dejean, N.,
>>>               and D. Barthel, "Routing Metrics Used for Path =
Calculation
>>>               in Low-Power and Lossy Networks", RFC 6551 =
, DOI 10.17487/
>>>               RFC6551 , March =
2012,
>>>               >.
>>>=20
>>>=20
>>> Unless I am mistaken, this is not the ROLL WG. And the abstract to =
RFC6551 explicitly reads:
>>>=20
>>>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>>>    compared with traditional wired and ad hoc networks that require =
the
>>>    specification of new routing metrics and constraints. =20
>>> Which explicitly is disclaiming that these metrics are not =
applicable in ad hoc networks =E2=80=94 and, I am wondering, what has =
changed since the publication of RFC6551 to suddenly make these =
applicable?
>>>=20
>>>  I am also wondering if looking at (and, perhaps, using?) the same =
metric type TLV type as in OLSRv2 is not a possibility?
>>>=20
>>> Either way, referencing RFC6551 here is wrong.
>>>=20
>>> RFC6621 (SMF) usage
>>> As late as earlier this month, RFC6621 reared its head again on the =
mailing list. I understand that the authors are set on using flooding =
reduction as part of RREQ distribution. If that is the case, then this =
protocol MUST specify that flooding reduction.=20
>>>=20
>>> Saying =E2=80=9CUse RFC6621=E2=80=9D won=E2=80=99t work, for reasons =
Chris point out in an email earlier to the list:
>>>> The network does not and fundamentally cannot offer multicast =
suppression to AODVv2. This isn't a hard concept, but seems to keep =
having to be said. AODVv2 messages are carried in 5444 packets, and =
those only travel one hop. That doesn't allow for suppression. =
Furthermore AODVv2 is creating new messages each hop. That needs AODVv2 =
specific handling.
>>>=20
>>>=20
>>> And quoting an email from myself:
>>>> If protocol X relies on using a flooding operation, then it =
certainly is protocol X's responsibility to  specify the flooding =
operation (or, at least, the requirements to the flooding operation ) =
for correct functioning of protocol X.
>>>=20
>>> I=E2=80=99ve previously pointed out that RFC6621 requires some =
degree of configuration (can=E2=80=99t just, for example, pick two =
different relay set selection algorithms, as that may produce a =
disconnected flooding domain).
>>>=20
>>> In other words, what the authors propose in =
https://tools.ietf.org/html/draft-perkins-manet-using-rfc6621-00 =
 is =
insufficient.
>>>=20
>>> Multiple interfaces configured with the same address(es) - & RFC6621
>>> I think that it has been established that the ability to use the =
same address on multiple interfaces is a requirement. It=E2=80=99s not =
clear to me that a single way of doing so has been proposed, nor that =
the =E2=80=9Coperating conditions=E2=80=9D are called out (for example, =
will it work  if router A and router B both have two interfaces, and =
that all 4 interfaces use the same IP address?)
>>>=20
>>> This is not entirely unrelated to flooding reduction and RFC6621. =
One of the complexities is to get that just right: OLSRv2 - for example =
- calculates Flooding-MPRs per interface, and RFC6130 is careful in how =
it detects bidirectionality of links.=20
>>>=20
>>> I have not worked out all the details of how this impacts this =
protocol =E2=80=94 but, it requires attention. Especially when wanting =
to be able to say =E2=80=9C=E2=80=A6use RFC6621=E2=80=9D, then the =
interface configuration constraints when faced with multiple interfaces =
must be worked out.
>>>=20
>>> Prefixes & Gateways
>>> A question to my mind, and I am not sure I know how to answer that =
from reading the draft since it is not discussed in section 9 (at =
least), is: =E2=80=9CWhat happens if I send a RREQ to a prefix=E2=80=9D =
(i.e., a /<128 in IPv6)?
>>>=20
>>> 	o	If the whole prefix is part of the attached network set =
of a single router,=20
>>> 		then I expect to get a single RREP back, is that the =
case?
>>>=20
>>> 	o	If "half the prefix"  is part of the attached network =
set of a single router,=20
>>> 		and the other half is part of the attached network set =
of another  single router,=20
>>> 		then I expect two RREPs, is that the case?
>>>=20
>>> 	o	More generally, will I get a tree build through the =
network here?
>>=20
>> AODVv2 currently doesn=E2=80=99t support RREQs for prefixes. I=E2=80=99=
ve already added =E2=80=9EIf RteMsg is a RREQ, RteMsg.TargPrefixLen =
SHOULD equal address length.=E2=80=9C to RteMsg.TargPrefixLen in section =
4.6 =
. =
Multicast Route Message Table in response to Justin=E2=80=99s comments, =
but I=E2=80=99ll go through the draft again and see where we need to =
state this more clearly.
>>=20
>> Best regards,
>> Lotte Steenbrink
>>=20
>>>=20
>>> Section 9 (or, the whole spec) is also not explicit enough about =
multiple  "default gateways" =E2=80=94 i.e., the external network being =
=E2=80=9Cthe rest of the Internet=E2=80=9D, and there being multiple =
gateways to the Internet. I understand how the RREQ gets to the gateway, =
and how the gateway determines if it should respond (the destination is =
not part of =E2=80=9Cthe MANET prefix, with which it is configured=E2=80=9D=
).
>>>=20
>>> But, if A is close to GW1, and B is close to GW2, but A and B being =
far far apart (according to the metric used) within the MANET, then it =
would be preferential for the route from A to B to go via =
GW1-=E2=80=9Cthe-Internet=E2=80=9D-GW2?=20
>>>=20
>>> Is this a supported configuration?=20
>>> 	o	If yes, how is it (seq# wise, I would expect some =
complications) handled?=20
>>> 	o	If not, where is it stated that this configuration is =
not possible with this protocol?
>>>=20
>>>=20
>>> The applicability statement says:
>>>=20
>>>    AODVv2 is designed for stub or disconnected mobile ad hoc =
networks,
>>>    i.e., non-transit networks or those not connected to the =
internet.
>>>    AODVv2 can, however, be configured to perform gateway functions =
when
>>>    attached to external networks, as discussed in Section 9 =
.
>>>=20
>>> I believe that the scenario I describe is indeed a stub network (and =
not a transit network)?
>>>=20
>>> =E2=80=94 =E2=80=94 =E2=80=94=20
>>>=20
>>> As I indicated, these are the big-picture issues that I have gotten =
around to thinking about enough to write up. I=E2=80=99m not through =
working through the document, but those were the ones that came to mind, =
and which seem imperative to resolve.
>>>=20
>>> Best,
>>>=20
>>> Thomas
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/manet =

>>=20


--Apple-Mail=_3A06A814-A2DB-4444-92C2-C95E18B06575
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi Thomas,

Am 20.04.2016 um 11:54 schrieb =
Thomas Clausen <ietf@thomasclausen.org>:

Lotte, =
all,

On 19 Mar =
2016, at 12:34, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:

Hi Thomas,
thank you for =
reviewing AODVv2 yet again :) Some answers below:
Am 17.03.2016 um 17:00 schrieb ietf@thomasclausen.org:

Dear all,

Apologies for not having =
gotten this done sooner - day-job leaving few spare cycles.

I=E2=80=99ve previously =
offered reviews and comments, and some of those have been addressed in =
the latest I-D =E2=80=94 others have not, but should be. I recall that =
there was some mail attempting to rebut parts of the review, and I will =
dig it out and reply to that.


That wold be =
great.

I am finding a bit of time here and there when there =
are holes in the agenda, and am (as you likely have noticed) =
backtracking through emails when I get a chance. Apologies, I hope that =
I will get to these emails this, or next week, but day-job eats in to =
the available time ;(

Forwarding-vs-regeneration
Recent exchanges on the list made me understand that protocol =
control messages are *not* forwarded, but are consumed at each hop, then =
a new message with (almost-but-not-quite) the same content is generated =
and transmitted.

That=E2=80=99s what we=E2=80=99ve been =
trying to say all along! I=E2=80=99m really glad we=E2=80=99re having =
this conversation.
Then, let us have it -- it's a central point to get =
right.

I have thought some more =
on this (& read some of the exchanges on the list on this topic by =
Chris, Ulrich, and others), and I am convinced that this is not the =
right way to go, at least for the following =
reasons:


	o	It renders the =
hop-limit/hop-count fields in the RFC5444 message header =
useless.
		This would not be bad if =
the functionality offered by those fields was not useful
		=
=E2=80=94 sadly, it is. For example, for scope limited flooding =
(expanding ring search, and 
		=
such) which may be of interest, and which require =
hop-limit. 
		A hop-count field may =
also provide a =E2=80=9Ccheap=E2=80=9D (in terms of overhead) additional =
piece
		of information to use =
conjunctively with a =E2=80=9Creal=E2=80=9D metric.


I agree on the =
usefulness, which is why we were puzzled when we were told we weren=E2=80=99=
t allowed to use those fields (or, rather, that we were using them =
wrong, but that the right way to use them doesn=E2=80=99t work for =
AODvv2). I believe Vicky has written about this in more detail in =
previous discussions, and we were/are looking forward to reading your =
answers...

So, the source generates a message, the message is =
forwarded through the network, with each intermediate router =
decrementing the hop limit and incrementing the hop count.

As stated in the =
5444-Usage document, when forwarding a message, the hop-limit/hop-count =
are modified, the rest of the message SHOULD not be. 

That is specifically, =
one thing where I kinda would like 5444-usage to go further is "the =
message structure MUST in all conditions preserved when forwarding" - =
but still say "and it is RECOMMENDED that the value field of TLVs are =
also not modified".

What this buys is several things, in the context of this =
protocol:

	o	=
hop-limit/hop-count could be useful for the usual 
		=
purposes (ensuring that messages do not live =
forever, 
		scope-limited flooding, =
=E2=80=A6)

Exactly.


	o	if the =
accumulated path metric is stored in a TLV value field, =
that 
		value field can (with =
suitable disclaimer to call out "we know it is
		=
RECOMMENDED to not do this, but here's why we are OK in =
doing
		it anyways") be modified =
when forwarding the message, and


Can it?! Iirc, the reason why we adopted the =
=E2=80=9Cregeneration=E2=80=9D language in the first place is that =
we=E2=80=99ve been told that whenever one bit in the message (apart from =
its header) is changed, the entire thing has to be regenerated. I=E2=80=99=
m starting to get the feeling we=E2=80=99ve just been misunderstanding =
each other for more than a year. :( Anyway, it seems like we=E2=80=99re =
getting close now, so yay.

	=
o	=
as that path metric field is in a message whose structure does =
not
		change, it will be "at =
the same place in the byte-stream" at each hop,
		=
which
	
	o	allows =
useful things such as deriving from RFC7182 a form of
		=
"when calculating the ICV, zero out that field in the message ' =
when
		  validating an ICV, =
also zero out that field" -- which goes one step
		=
  further (when coupled with a time stamp) than simple =
transitive trust, 
		=
  but also

Well if that=E2=80=99d be possible, that=E2=80=99d =
solve a *huge* lump of problems. I=E2=80=99m guessing the remaining =
caveat would be that an attacker (or a buggy router) might still tamper =
with the metric value without being detected, which could divert routes =
(i.e. routes being established when they shouldn=E2=80=99t and dropped =
when they shouldn=E2=80=99t). Obviously this needs to be pointed out in =
the security considerations, but it=E2=80=99d be a massive =
improvement. 
Do the other 5444 experts agree that we can =
do this? If yes, I=E2=80=99ll come up with some suggestions for suitable =
text tonight and run it by the list to see if it makes sense.


	=
o	=
allows even more fancy and useful (albeit experimental) things =
such
		as aggregate signatures =
to work correctly.

Furthermore.....

		=
The only practical solution would be to re-introduce these =
functions by way of inserting a
		=
MessageTLV =E2=80=94 which (i) is not specified in this document, =
and (ii) which would just
		=
serve to render messages bigger than strictly =
needed.

Exactly; we=E2=80=99d really like to =
avoid this as well.


... It avoids the above, and....

		=
Scope limited flooding  does seem to be a necessary =
requirement, if for no
		other reason than to =
prevent information from =E2=80=9Ccirculating forever in the =
network=E2=80=9D.

AODVv2=E2=80=99s duplicated detection =
hopefully should take care of that. Iirc, We interpreted your earlier =
E-Mails to (implicitly) mean that you think we should rely on that, =
since you said we can=E2=80=99t use the hop-limit/hop-count =
fields.


....if done (proper forwarding with =
preservation of the structure, rather than regeneration which opens up =
the "this is a new message with potentially new structure" can of worms) =
as I describe, also addresses the above.

With respect to what I said earlier =
when I said "can't use hop-limit/hop-count fields"....when you =
regenerate, you absolutely, definitely, can't.

When you =
"regenerate" a message, that means "you construct a brand new message" =
which may shuffle addresses inside address blocks, or between address =
blocks, shuffle TLVs differently than they were originally, even use =
TLVs of different structure (e.g., single-value TLVs instead of =
multi-value TLVs). 

This means that some assumptions =
(such as when producing an ICV for the message, which depends on the =
byte order) don't hold. Well, they may not hold, so that means we can't =
assume that they do. Which means that the originator of a message cannot =
generate an ICV that can be correctly interpreted (which is what my next =
section in my original mail was about).

Which means, in conclusion, =
 that the information in the message profoundly change -- and =
therefore these hop-count/hop-limit values do not even apply to "the =
information=E2=80=9C. 

Okay, that makes sense. I thought we might have =
some wiggle room, saying =E2=80=9Cyes, we're constructing a new message, =
but that just happens to have a hop count that=E2=80=99s =
lastMessage.hopcount -1=E2=80=9D. But if your above outline is legal =
(which, as I said, we just thought we couldn=E2=80=99t do what you=E2=80=99=
ve described, and I=E2=80=99m pretty sure I=E2=80=99ve asked this list =
and Henning all kinds of questions revolving around this topic last =
spring), we won=E2=80=99t need hacks like those anyway, so I won=E2=80=99t=
 entertain them any further. ;)


However if proper forwarding with preservation of the =
structure, rather than regeneration which opens up the "this is a new =
message with potentially new structure" can of worms, as I (& Ulrich =
& others) have suggested, is taken to heart, it also addresses the =
issue below regarding end-to-end authentication (which, while still =
hard, is possible).

A couple of more comments below

	o	It makes end-to-end authentication =
unnecessarily hard.
		I =
think Chris called this out already, but it bears repeating: S generates =
a message 
		(say, a RREQ), and =
includes an ICV calculated over the content of the message.
		=
For any recipient to be able to validate the ICV, the message has =
to be exactly
		the same =E2=80=94 not =
just in content, but in structure =E2=80=94 as what was =
generated.

		=
=E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforwarding=E2=80=
=9D messages means, that the intermediate
		=
router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose a =
different structure (e.g., include TLVs
		=
in a different order).

		The proposal from https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00<=
/a>
		is to add constraints on =
(i) the set of elements to include in a signature and (ii) the
		=
order of these elements.

		One problem with =
that approach is (i): if an extension adds a message TLV, or =
an 
		Address TLV, to a =
message, then that will not be =E2=80=9Ccovered=E2=80=9D by the proposed =
e2esec TLV.
		Rather for *each* =
extension developed, an =E2=80=9Cupdates e2esec=E2=80=9D clause needs to =
be done.

		=
I=E2=80=99d say that this approach would be prone to errors =E2=80=94=
 and add entropy to the process
		=
of designing protocol extensions. The alternative, a message =
being generated by the
		source and *forwarded* =
(as we do in OLSRv2, for example) would allow ICV TLVs 
		=
(even, allow reuse of those specified for OLSRv2) for covering a =
message and 
		extensions.

		=
=E2=80=9CBut what about the metrics value which will change on =
each hop=E2=80=9D, you may say?
		=
Fortunately, that is relatively easy to handle: simply zero out =
the value of that TLV when
		=
generating or verifying the ICV MessageTLV. And use Packet-TLVs =
for hop-by-hop 
		authentication, if needed =
(but, see below).

	=
o	=
It prevents the use of more =
clever/advanced signature schemes/ICVs
		=
Aggregate signature algorithms ( https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
		exist, and an interesting =
use-case can be found in also reactive protocols, allowing =
verifying
		not =E2=80=9Cjust=E2=80=9D =
the end points, but also the intermediaries (again, with the appropriate =
=E2=80=9Czero out=E2=80=9D
		=
discussed above, or something smarter).
		=
Regeneration of messages, rather than forwarding, renders that =
impossible (or, if used,
		=
updating to  https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00<=
/a>)

There are =
other reasons, but the above are those that jump at me as immediate =
show-stoppers.

I=
 do honestly not see what possible benefit there is from =
=E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear =
inconveniences, and security is not the least of these. Insisting on =
=E2=80=9Cregeneration=E2=80=9D requires development of =E2=80=9Cnon-genera=
l workarounds=E2=80=9D as pointed out =
above.

The possible benefit is that we need to =
accumulate & transport metric values somehow, and we can=E2=80=99t =
do that without regenerating at least parts of the message.
If we=E2=80=99re missing a solution here, please share it =
with us.


Done in the above.


Security =
Considerations

Just for context=E2=80=99s sake, did =
you review the security considerations =
in draft-ietf-manet-aodvv2-13 or the ones proposed in the thread =
=E2=80=9EAODVv2: Security considerations =
update=E2=80=9C?

I did. It still is a far cry from passing the bar. I've =
posted on why in the past, and some more in this mail (which also =
contains some suggestions).



I would suggest that settling the rearchitecturing to do forwarding, as I describe in the =
above, should be done, which would ease the security considerations =
issue considerably (and which would be necessary even if ignoring the =
security considerations, IMO, for this doc to go =
anywhere). 

With a new version covering that, =
the authors (I wanted to write "you", but decided to be inclusive) =
could you go look at the different security emails and =
perhaps start a separate thread on that, towards a =
resolution?

Sounds like a good plan, I=E2=80=99ll do that =
tonight as well (unless somebody beats me to it :D).

Best regards,
Lotte



Best,

Thomas



This is an always thorny subject. When OLSRv2 was going =
through the process we got a thorough education in how little we knew =
about security from the SEC-ADs, and had to spend about a year or so =
developing RFC7183. The bottom line is, that this protocol needs its =
=E2=80=9CRFC7183  equivalent=E2=80=9D, either as part of the main =
document, or as an independent document. currently, that is not the =
case.

A =
minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration from =
RFC7183 might be aw good idea, as that was the most recent that went =
through the SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to =
implement=E2=80=9D security mechanism most be specified (I think the =
right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D), in =
sufficient detail to ensure interoperable =
implementations.

As an =
example, both [RFC6130] and [RFC7181] set out that that:

  =
    On receiving a ... message, a router MUST first check if =
the
      message is invalid for =
processing by this router

and then proceed to give a number of conditions that, each, =
will lead to a rejection of the message as "badly formed and therefore =
invalid for processing=E2=80=9D =E2=80=94 a list which RFC7183 then =
amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting =
=E2=80=9Crejection=E2=80=9D. Idem for message generation.

If I was to do =
RFC7181/RFC6130 today, I would include that directly into the protocol =
specifications. It turned out to be more overhead (and slow down =
publication anyways) to do it as separate documents.

Secondly, we need to be =
a lot more rigid in terms of what ICVs, Timestamps, etc. are =
added/removed, and what that brings.

For example (with the assumption that =
messages are *forwarded* and *not* regenerated), this could be one =
option:

		=
o	=
When a RREQ, RREP message is generated, add an ICV Message TLV, =
which is calculated <this way>
			=
 =E2=80=A6(take inspiration from RFC7183 here)

		=
o	=
When a RREQ, RREP message is transmitted  (by the source, or =
forwarded by an intermediary)
			=
in an RFC5444 packet, an ICV Packet TLV is added to the packet, =
which is calculated <this way> =E2=80=A6

		o	When an =
RFC5444 packet is received, validate the ICV Packet TLV <this way> =
and if the ICV doesn=E2=80=99t validate,
			=
discard the contained messages.

		o	When =
receiving a RREQ/RREP (either as destination, or as an intermediary), =
validate the ICV Message TLV 
			=
<this way> and if the ICV doesn=E2=80=99t validate, discard =
the message, do not process, do not forward.

This is a different (and more =
flexible?) model than =E2=80=9Cjust=E2=80=9D transitive trust and =
=E2=80=9Cjust=E2=80=9D end-to-end trust discussed previously, and is =
enabled by the =E2=80=9Cforwarding=E2=80=9D bit described =
previously.

Metrics
I have =
asked this numerous times, but have not gotten any answer so I am =
escalating this again. Why is this document having a normative reference =
to RFC6551?

   [RFC6551]  =
Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
              and D. Barthel, "Routing Metrics Used for Path Calculation
              in Low-Power and Lossy Networks", RFC 6551, =
DOI 10.17487/
              RFC6551, March 2012,
              <http://www.rfc-editor.org/info/rfc6551>.


Unless I am mistaken, this is not the =
ROLL WG. And the abstract to RFC6551 explicitly reads:

   Low-Power and Lossy =
Networks (LLNs) have unique characteristics
   compared with traditional wired and ad hoc networks that require the
   specification of new routing metrics and constraints.  
Which explicitly is disclaiming that these metrics are not applicable in ad hoc networks =E2=80=
=94 and, I am wondering, what has changed since the publication of =
RFC6551 to suddenly make these applicable?

 I am also wondering if looking at =
(and, perhaps, using?) the same metric type TLV type as in OLSRv2 is not =
a possibility?

Either way, referencing RFC6551 here is wrong.

RFC6621 (SMF) usage
As late as =
earlier this month, RFC6621 reared its head again on the mailing list. I =
understand that the authors are set on using flooding reduction as part =
of RREQ distribution. If that is the case, then this protocol MUST =
specify that flooding reduction. 

Saying =E2=80=9CUse RFC6621=E2=80=9D =
won=E2=80=99t work, for reasons Chris point out in an email earlier to =
the list:
The =
network does not and fundamentally cannot offer multicast suppression to =
AODVv2. This isn't a hard concept, but seems to keep having to be =
said. AODVv2 messages are carried in 5444 packets, and those only travel =
one hop. That doesn't allow for suppression. Furthermore AODVv2 is =
creating new messages each hop. That needs AODVv2 specific =
handling.

And quoting an email from myself:
If protocol X relies on =
using a flooding operation, then it certainly is protocol X's =
responsibility to  specify the flooding operation (or, at =
least, the requirements to the flooding operation ) for correct =
functioning of protocol X.

I=E2=80=99ve previously pointed out =
that RFC6621 requires some degree of configuration (can=E2=80=99t just, =
for example, pick two different relay set selection algorithms, as that =
may produce a disconnected flooding domain).

In other words, what the authors =
propose in https://tools.ietf.org/html/draft-perkins-manet-using-rfc6621-0=
0 is insufficient.

Multiple interfaces configured =
with the same address(es) - & RFC6621
I =
think that it has been established that the ability to use the same =
address on multiple interfaces is a requirement. It=E2=80=99s not clear =
to me that a single way of doing so has been proposed, nor that the =
=E2=80=9Coperating conditions=E2=80=9D are called out (for example, will =
it work  if router A and router B both have two interfaces, and =
that all 4 interfaces use the same IP address?)

This is not entirely unrelated to =
flooding reduction and RFC6621. One of the complexities is to get that =
just right: OLSRv2 - for example - calculates Flooding-MPRs per =
interface, and RFC6130 is careful in how it detects bidirectionality of =
links. 

I =
have not worked out all the details of how this impacts this protocol =
=E2=80=94 but, it requires attention. Especially when wanting to be able =
to say =E2=80=9C=E2=80=A6use RFC6621=E2=80=9D, then the interface =
configuration constraints when faced with multiple interfaces must be =
worked out.

Prefixes & Gateways
A question to my mind, and I am not sure I know how to answer =
that from reading the draft since it is not discussed in section 9 (at =
least), is: =E2=80=9CWhat happens if I send a RREQ to a prefix=E2=80=9D =
(i.e., a /<128 in IPv6)?

	=
o	=
If the whole prefix is part of the attached network set of a =
single router, 
		then I expect to get a =
single RREP back, is that the case?

	o	If "half the prefix"  is =
part of the attached network set of a single router, 
		=
and the other half is part of the attached network set of another =
 single router, 
		=
then I expect two RREPs, is that the case?
	o	More generally, will I get a tree =
build through the network here?

AODVv2 currently =
doesn=E2=80=99t support RREQs for prefixes. I=E2=80=99ve already added =
=E2=80=9EIf RteMsg is a RREQ, =
RteMsg.TargPrefixLen SHOULD equal address length.=E2=80=9C to =
RteMsg.TargPrefixLen in section 4.6.  Multicast Route Message Table in response to =
Justin=E2=80=99s comments, but I=E2=80=99ll go through the draft again =
and see where we need to state this more clearly.
Best regards,
Lotte=
 Steenbrink


Section 9 (or, the whole =
spec) is also not explicit enough about multiple  "default =
gateways" =E2=80=94 i.e., the external network being =E2=80=9Cthe rest =
of the Internet=E2=80=9D, and there being multiple gateways to the =
Internet. I understand how the RREQ gets to the gateway, and how the =
gateway determines if it should respond (the destination is not part of =
=E2=80=9Cthe MANET prefix, with which it is configured=E2=80=9D).

But, if A is close to =
GW1, and B is close to GW2, but A and B being far far apart (according =
to the metric used) within the MANET, then it would be preferential for =
the route from A to B to go via =
GW1-=E2=80=9Cthe-Internet=E2=80=9D-GW2? 

Is this a supported =
configuration? 
	o	If yes, how is it (seq# wise, I =
would expect some complications) handled? 
	o	If not, =
where is it stated that this configuration is not possible with this =
protocol?


The applicability statement =
says:

   AODVv2 is designed =
for stub or disconnected mobile ad hoc networks,
   i.e., non-transit networks or those not connected to the internet.
   AODVv2 can, however, be configured to perform gateway functions when
   attached to external networks, as discussed in Section 9.


I =
believe that the scenario I describe is indeed a stub network (and not a =
transit network)?

=E2=80=94 =E2=80=94 =E2=80=94 

As I indicated, these are the =
big-picture issues that I have gotten around to thinking about enough to =
write up. I=E2=80=99m not through working through the document, but =
those were the ones that came to mind, and which seem imperative to =
resolve.

Best,

Thomas



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

<=
br class=3D"">=

--Apple-Mail=_3A06A814-A2DB-4444-92C2-C95E18B06575--


From nobody Fri Apr 22 02:09: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 1993712DDF6 for ; Fri, 22 Apr 2016 02:09: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, 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 Ja8H-YyJmrTW for ; Fri, 22 Apr 2016 02:08:59 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 A7CFF12DAEE for ; Fri, 22 Apr 2016 02:08:58 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id g184so75604086lfb.3 for ; Fri, 22 Apr 2016 02:08:58 -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:content-transfer-encoding; bh=L3b3f8fSE1U0CsmEft795iqWmNqmTTmB3x5+/qI4iPY=; b=FWPgrapyC5vP3VfIYGD1UXKYvZxLaXhw3d+cFuNFoYx90xBQ69K2ET36acuvzn8PyB 1sPZIjEmTAdWfMqCj/ANUXQntzkDQiJlZpywYerhIIDZgXlzbQGVylcTJ1kc6GfZrZE6 YH7kqxGyEMJqFKwmtc8Of0zwbFd7zY633a1i3BeFTVmNhQcdDLzbv5WciScNwVOPDSMU xwMJTWwlB7rTISTu0TMG7ZDmp7KmcrNJ6MKbPfw485SYNhF7wOaOJtwmxUJySQM+7OQl DkOwKaZb1N1d6p00lFLzXqn+75rvVSknMn3pd2lyxTbL1HLBAsBkk09UFwJtGpewZB9x rtEg==
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:content-transfer-encoding; bh=L3b3f8fSE1U0CsmEft795iqWmNqmTTmB3x5+/qI4iPY=; b=S85cnoUCNKW2ZBALTatgPxBNP4ppUUHhg4svjgFCg1SH0EMFK8TRFrWSoBToxTgF/X HiaxAYAo554ZPqdwm331w3j88pFGDcYj/jFqAH+CjvX9rzKVlLXZt1kbHxcik3Zdua2f ec0y4jA3IiN8JJHCZNlqvUEhw1gdanC0uMpp2oBE5VFC0EMKb3lxxKOcQr9LN3N18yp/ l7sujz9MlDVWGgR7SoSZVsTkorjrfPoyluOeEdwg7WFoLAs5q/sFs3hoX0hculRBiL+T 8yHKxysijl/aFNpKFaRT4tS6m/OBTR2vL4z2zUSp6gp08dLvVvk6Y+k5A7BGWvzR8vWb Cutg==
X-Gm-Message-State: AOPr4FXDLul4xNF47CzS+VhoYVaFWyrWy0y3U9snPkLJI3YnEvTVlMrvCtbfS551URGqlcSrjRzqHeKRxp0HEg==
X-Received: by 10.25.18.217 with SMTP id 86mr6213964lfs.107.1461316136869; Fri, 22 Apr 2016 02:08:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.24.42 with HTTP; Fri, 22 Apr 2016 02:08:27 -0700 (PDT)
In-Reply-To: <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>
From: Henning Rogge 
Date: Fri, 22 Apr 2016 11:08:27 +0200
Message-ID: 
To: Lotte Steenbrink 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 09:09:00 -0000

On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
 wrote:
> Hi Thomas,
> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=E2=80=
=9D language in the
> first place is that we=E2=80=99ve been told that whenever one bit in the =
message
> (apart from its header) is changed, the entire thing has to be regenerate=
d.
> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been misunders=
tanding each other
> for more than a year. :( Anyway, it seems like we=E2=80=99re getting clos=
e now, so
> yay.

"Modifying" the binary message instead of parsing and generating a new
one will be difficult as soon someone writes an extension to AODVv2
that adds more TLVs to the message.

Henning Rogge


From nobody Fri Apr 22 02:22: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 5FC7212DAEE for ; Fri, 22 Apr 2016 02:22:17 -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 URhzjvQxFDDj for ; Fri, 22 Apr 2016 02:22:14 -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 3C51012D7DD for ; Fri, 22 Apr 2016 02:22:14 -0700 (PDT)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1atXHw-002e1Z-G3>; Fri, 22 Apr 2016 11:22:12 +0200
Received: from p548d7b4d.dip0.t-ipconnect.de ([84.141.123.77] helo=[192.168.46.209]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id <1atXHw-0049Sp-1c>; Fri, 22 Apr 2016 11:22:12 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_F30901CB-B4BF-470C-B5B7-49F65AFAC1F1"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Lotte Steenbrink 
In-Reply-To: 
Date: Fri, 22 Apr 2016 11:22:11 +0200
Message-Id: 
References:    <927E6489-D927-4670-A24C-5A5D9B58C05D@gmail.com> <57191FDD.5010707@earthlink.net>  
To: Mobile Ad Hoc Networks mailing list 
X-Mailer: Apple Mail (2.3112)
X-Originating-IP: 84.141.123.77
X-ZEDAT-Hint: A
Archived-At: 
Subject: Re: [manet] New AODVv2 draft and status
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, 22 Apr 2016 09:22:17 -0000

--Apple-Mail=_F30901CB-B4BF-470C-B5B7-49F65AFAC1F1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Jiazi, hi everyone,

> Am 21.04.2016 um 23:00 schrieb Jiazi YI :
>=20
> And by simply searching the archive, I would like to point out that =
those comments are nothing new.
>=20
> In the comments from Thomas in 2010 (6 years ago), the issue has been =
brought out in =
http://www.ietf.org/mail-archive/web/manet/current/msg11858.html =
 , I =
quote:=20
>=20
>=20
>    In situations where routing information or router identity =
are
>    suspect, integrity and authentication techniques SHOULD be applied =
to
>    DYMO messages.  In these situations, routing information that is
>    distributed over multiple hops SHOULD also verify the integrity and
>    identity of information based on originator of the routing
>    information.
>=20
>  This is really difficult to do, in case messages are mutable =
in-transit, which appears to be the case for RERR and RM's; i.e. for all =
DYMO messages. For that reason, using SHOULD is - imo - dangerous here. =
Also, for that reason, I think that this issue of mutable messages =
deserves being called out explicitly in this section, especially if =
there are known or recommended ways of handling this (as is the case, =
for example, in the security considerations section of RFC5444 regarding =
the mutable header fields for hop-count/hop-limit of messages.
>=20
> Then related comments were repeated again and again. Isn't enough to =
bring the attention of the authors? In fact, the situation get even =
worse by changing the strategy to regenerating messages.=20
>=20

The strategy has never been changed, at least not in the past 2-3 years =
I=E2=80=99ve been watching AODVv2. We=E2=80=99ve just been talking past =
each other for a really long time. The discussion has just now finally =
taken a direction where all parties are on the same page, which is =
really unfortunate timing. For the sake of completeness, I=E2=80=99d =
also like to point out that we=E2=80=99ve brought up the topic of =
regeneration issues in September [1] and November [2] 2015, where =
we=E2=80=99ve explained why we use the word =E2=80=9Cregeneration=E2=80=9D=
. That would=E2=80=99ve been a great place to resolve the =
miscommunication that=E2=80=99s apparently been happening.=20
I get that we all have day jobs and lives and that E-Mails get lost, but =
to be pinned as the sole source of delay in this case when we were =
waiting for (and really curious about) the WG=E2=80=99s input is =
starting to get insulting.

Anyway, the regeneration discussion is now *finally* on the right path, =
so let=E2=80=99s get to it.

Best,
Lotte

[1] https://www.ietf.org/mail-archive/web/manet/current/msg18055.html =

[2] https://www.ietf.org/mail-archive/web/manet/current/msg18167.html =

> best
>=20
> Jiazi
>=20
> On Thu, Apr 21, 2016 at 10:38 PM, Jiazi YI > wrote:
> Hi,=20
>=20
>=20
> On Thu, Apr 21, 2016 at 8:45 PM, Charlie Perkins =
> =
wrote:
> 
>=20
> Regarding security: if AODVv2 were to solve all the possible security =
exposures of ad hoc networks, it would be historic and worthy of =
publication -- probably would win paper of the year. Needless to say, =
that was never part of the charter.
>=20
>=20
> But security and its consideration are part of every specification.=20
>=20
> As one who co-authored several vulnerability analysis drafts/RFCs =
(ndhp-sec-threats, smf-sec-threats, olsrv2-sec-threats), what we always =
do for a protocol is:
>=20
>   - assuming that we have a compromised router in the network, what =
can it do to break the network? What's the consequences? What about if =
there are several of them?
>=20
>   - what about if there are mis-configured routers or =
wrong-implemented routers?
>=20
>   - what kind of threats can be mitigated by existed security =
measurements (like RFC 7182/7183)?=20
>=20
>   - what kind of future work can be done to make the protocol more =
secure?
>=20
> With the current AODVv2 specification, if I was to produce a =
aodvv2-sec-threats draft, it would be much simpler:=20
>=20
>    - one single compromised router can easily jam the whole network =
(RREQ flooding), or even bring down the whole network (remember the =
multicast RERR?) because of the transit-trust model used.=20
>=20
>   - with my limited knowledge, as future work, there is no easy way to =
protect the message because of the reconstructed and length-varied =
message regenerated in every hop.=20
>=20
>=20
> Even *if* security was acceptable as future work (it is not, but as a =
thought experiment, let's assume), there is no easy way to protect the =
message because of the reconstructed and length-varied message =
regenerated in every hop.=20
>=20
> Securing a reactive protocol requires different considerations than =
does securing a proactive protocol, but there has been work done in this =
area, and other WG participants have raised both their concerns, and =
suggestions to security architectures, and protocol architectures =
(better) able to accommodate security, a long time ago. I don't see =
those works, nor the suggestions and comments made, reflected or =
considered in revision -15 of the draft. Especially, the current design =
based on message regeneration makes the future extension to the security =
very hard, as has been reiterated repeatedly.
>=20
> Abdussalam doesn't agree with me on my observation on "Lack of =
response from the author team on the comments. " -- this is an example.=20=

>=20
> regards
>=20
> Jiazi
>=20
> btw, I would like to confirm with the WG chair: the WGLC is from April =
20th to May 4th, right?
> =20
> =20
>=20
> Regards,
> Charlie P.
>=20
>=20
>=20
> On 4/21/2016 11:24 AM, John Dowdell wrote:
> All
>=20
> I believe we=E2=80=99re going about this the wrong way, and we=E2=80=99r=
e setting ourselves an impossible target at which we are bound to fail.
>=20
> BCP 9, governing the Internet Standards process, section 4.1.1 deals =
with the first level of maturity, termed Proposed Standard. To =
paraphrase, a Proposed Standard is supposed to be as correct as we can =
make it, but there is no requirement to have made an implementation. =
Since no engineer has ever written a fully correct specification before =
cutting metal, it may be expected that there are some areas which will =
need attention later on, at Draft Standard if we ever wanted to go that =
far. I=E2=80=99ll say now that one area in AODVv2 will need some work =
later, that of hop-by-hop security in an ad hoc network. This is because =
nobody has really cracked that problem yet; some real bright people are =
grappling with that right now over in DTN. The work in our own group on =
Identity Based Signatures will help but there is still ground to cover. =
However the actual level of security is not for AODVv2 to mandate, it is =
for the implementor and system integrator, based on an assessment of the =
likely risk and the thickness of their wallet.
>=20
> It is clear to me that few will make an independent implementation =
without the RFC stamp. This much is obvious in modems fitted with DLEP; =
there are just four such implementations I know of, and two of those =
were written with the encouragement of author team members, but I know =
of many more who are just waiting for the dust to settle so they can =
make the business case to proceed. Allow AODVv2 to get to RFC and =
we=E2=80=99ll encourage others to use it and get some feedback.
>=20
> Regards
> John
> _______________________________________________
> 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
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


--Apple-Mail=_F30901CB-B4BF-470C-B5B7-49F65AFAC1F1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi Jiazi, hi everyone,

Am =
21.04.2016 um 23:00 schrieb Jiazi YI <ietf@jiaziyi.com>:

And by simply searching the archive, I would =
like to point out that those comments are nothing new.

In the comments from =
Thomas in 2010 (6 years ago), the issue has been brought out in http://www.ietf.org/mail-archive/web/manet/current/msg11858.htm=
l , I quote: 


<DYMO>   In situations where routing information =
or router identity are
   suspect, =
integrity and authentication techniques SHOULD be applied to
   DYMO messages.  In these situations, =
routing information that is
  =
 distributed over multiple hops SHOULD also verify the integrity =
and
   identity of information based on =
originator of the routing
  =
 information.

<TC> This is really difficult to do, in case messages =
are mutable in-transit, which appears to be the case for RERR and RM's; =
i.e. for all DYMO messages. For that reason, using SHOULD is - imo - =
dangerous here. Also, for that reason, I think that this issue of =
mutable messages deserves being called out explicitly in this section, =
especially if there are known or recommended ways of handling this (as =
is the case, for example, in the security considerations section of =
RFC5444 regarding the mutable header fields for hop-count/hop-limit of =
messages.

Then related comments were repeated again and again. Isn't =
enough to bring the attention of the authors? In fact, the situation get =
even worse by changing the strategy to regenerating =
messages. 


The strategy has never been changed, at least not =
in the past 2-3 years I=E2=80=99ve been watching AODVv2. We=E2=80=99ve =
just been talking past each other for a really long time. The discussion =
has just now finally taken a direction where all parties are on the same =
page, which is really unfortunate timing. For the sake of completeness, =
I=E2=80=99d also like to point out that we=E2=80=99ve brought up the =
topic of regeneration issues in September [1] and November [2] 2015, =
where we=E2=80=99ve explained why we use the word =E2=80=9Cregeneration=E2=
=80=9D. That would=E2=80=99ve been a great place to resolve the =
miscommunication that=E2=80=99s apparently been =
happening. 
I get that we all have day jobs and lives and =
that E-Mails get lost, but to be pinned as the sole source of delay in =
this case when we were waiting for (and really curious about) the WG=E2=80=
=99s input is starting to get insulting.

Anyway, the regeneration discussion is now =
*finally* on the right path, so let=E2=80=99s get to it.

Best,
Lotte


best

Jiazi

On Thu, =
Apr 21, 2016 at 10:38 PM, Jiazi YI <ietf@jiaziyi.com> wrote:
Hi, 


On Thu, =
Apr 21, 2016 at 8:45 PM, Charlie Perkins <charles.perkins@earthlink.net> =
wrote:
<snip>



Regarding security: if AODVv2 were to solve all the possible security =
exposures of ad hoc networks, it would be historic and worthy of =
publication -- probably would win paper of the year. Needless to say, =
that was never part of the charter.


But security and its consideration are part of every =
specification. 

As one who co-authored several vulnerability analysis =
drafts/RFCs (ndhp-sec-threats, smf-sec-threats, olsrv2-sec-threats), =
what we always do for a protocol is:

  - assuming that we have a =
compromised router in the network, what can it do to break the network? =
What's the consequences? What about if there are several of =
them?

  - =
what about if there are mis-configured routers or wrong-implemented =
routers?

  =
- what kind of threats can be mitigated by existed security measurements =
(like RFC 7182/7183)? 

  - what kind of future work can be done to make the =
protocol more secure?

With the current AODVv2 specification, if I was to produce a =
aodvv2-sec-threats draft, it would be much simpler: 

   - one =
single compromised router can easily jam the whole network (RREQ =
flooding), or even bring down the whole network (remember the multicast =
RERR?) because of the transit-trust model used. 

  - with my limited =
knowledge, as future work, there is no easy way to protect the message =
because of the reconstructed and length-varied message regenerated in =
every hop. 


Even =
*if* security was acceptable as future work (it is not, but as a thought =
experiment, let's assume), there is no easy way to protect the message =
because of the reconstructed and length-varied message regenerated in =
every hop. 

Securing a reactive protocol requires different =
considerations than does securing a proactive protocol, but there has =
been work done in this area, and other WG participants have raised both =
their concerns, and suggestions to security architectures, and protocol =
architectures (better) able to accommodate security, a long time ago. I =
don't see those works, nor the suggestions and comments made, reflected =
or considered in revision -15 of the draft. Especially, the current =
design based on message regeneration makes the future extension to the =
security very hard, as has been reiterated repeatedly.

Abdussalam doesn't agree =
with me on my observation on "Lack of response from the author team on =
the comments. " -- this is an example. 

regards

Jiazi

btw, I would like to =
confirm with the WG chair: the WGLC is from April 20th to May 4th, =
right?
 
 



Regards,

Charlie P.






On 4/21/2016 11:24 AM, John Dowdell wrote:



All



I believe we=E2=80=99re going about this the wrong way, and we=E2=80=99re =
setting ourselves an impossible target at which we are bound to fail.



BCP 9, governing the Internet Standards process, section 4.1.1 deals =
with the first level of maturity, termed Proposed Standard. To =
paraphrase, a Proposed Standard is supposed to be as correct as we can =
make it, but there is no requirement to have made an implementation. =
Since no engineer has ever written a fully correct specification before =
cutting metal, it may be expected that there are some areas which will =
need attention later on, at Draft Standard if we ever wanted to go that =
far. I=E2=80=99ll say now that one area in AODVv2 will need some work =
later, that of hop-by-hop security in an ad hoc network. This is because =
nobody has really cracked that problem yet; some real bright people are =
grappling with that right now over in DTN. The work in our own group on =
Identity Based Signatures will help but there is still ground to cover. =
However the actual level of security is not for AODVv2 to mandate, it is =
for the implementor and system integrator, based on an assessment of the =
likely risk and the thickness of their wallet.



It is clear to me that few will make an independent implementation =
without the RFC stamp. This much is obvious in modems fitted with DLEP; =
there are just four such implementations I know of, and two of those =
were written with the encouragement of author team members, but I know =
of many more who are just waiting for the dust to settle so they can =
make the business case to proceed. Allow AODVv2 to get to RFC and =
we=E2=80=99ll encourage others to use it and get some feedback.



Regards

John

_______________________________________________

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

=

--Apple-Mail=_F30901CB-B4BF-470C-B5B7-49F65AFAC1F1--


From nobody Fri Apr 22 02:28: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 B3DAB12EA94 for ; Fri, 22 Apr 2016 02:28:21 -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 YSzlGVkLAwri for ; Fri, 22 Apr 2016 02:28:20 -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 4EA7C12D9B0 for ; Fri, 22 Apr 2016 02:28:20 -0700 (PDT)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1atXNq-002hJH-TB>; Fri, 22 Apr 2016 11:28:18 +0200
Received: from p548d7b4d.dip0.t-ipconnect.de ([84.141.123.77] helo=[192.168.46.209]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id <1atXNq-004A6k-Hu>; Fri, 22 Apr 2016 11:28:18 +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: 
Date: Fri, 22 Apr 2016 11:28:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de> 
To: Henning Rogge 
X-Mailer: Apple Mail (2.3112)
X-Originating-IP: 84.141.123.77
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 09:28:21 -0000

Hi Henning,

> Am 22.04.2016 um 11:08 schrieb Henning Rogge :
>=20
> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>  wrote:
>> Hi Thomas,
>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=E2=80=
=9D language in the
>> first place is that we=E2=80=99ve been told that whenever one bit in =
the message
>> (apart from its header) is changed, the entire thing has to be =
regenerated.
>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been =
misunderstanding each other
>> for more than a year. :( Anyway, it seems like we=E2=80=99re getting =
close now, so
>> yay.
>=20
> "Modifying" the binary message instead of parsing and generating a new
> one will be difficult as soon someone writes an extension to AODVv2
> that adds more TLVs to the message.
>=20

D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s =
what you explained to me when I got confused about the topic last =
spring=E2=80=A6 But=E2=80=93 even if a message contains TLVs that the =
AODVv2 implementation handling it doesn=E2=80=99t understand, it will =
still be able to recognize the Metric TLV, right? Isn=E2=80=99t that the =
nifty thing about RFC5444? So, while we really shouldn=E2=80=99t write =
=E2=80=9Cbefore calculating the ICV, set the n-th 4 octets to 0=E2=80=9D, =
we might say =E2=80=9Cidentify the octets that make up the metric value =
and set those to 0=E2=80=9D?

Best regards,
Lotte

> Henning Rogge


From nobody Fri Apr 22 02:31:53 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 F388C12EB2A for ; Fri, 22 Apr 2016 02:31:50 -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 YnPaH5p5ybBs for ; Fri, 22 Apr 2016 02:31:49 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 992D012EAD6 for ; Fri, 22 Apr 2016 02:31:48 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id j11so75870330lfb.1 for ; Fri, 22 Apr 2016 02:31:48 -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:content-transfer-encoding; bh=58typhwhX3bUu6w847j/Q4whkq+acPQeb/I3Q4mwEgg=; b=Biukat5FBhoJ4jed2ZW2FU5r3SLPwpCRYbNavhttRH2X0SpxFvTi6v3xpxYfntntbE F0HR3fAFbuWKRoJq/8OYLHhV8ELSFQbBRggGZbUI13pbdzssbDdi6FURHykwKwiAXsbm iusDsBfTQRnBT3QTPInlhj3Xzl42cRtvV/16zYapH1rcvuuO+DN1pG/SWmUmPAmOnf3T 65Ti4bG1V3/cavNomCe+v4/X4VuJpPZYlcEQpcGdBXSjTlT6tGE21dbBiPc+9AV69itN 4JoaNc7nH8IwaZM4pcWV+BhsxUxgtnjALqLF0WhovKx1IpUxOQQhJ/OayfX60Yas+Z75 F0zA==
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:content-transfer-encoding; bh=58typhwhX3bUu6w847j/Q4whkq+acPQeb/I3Q4mwEgg=; b=dYy4N6qB5Pb2x5imDReYhMQE0ZD6NUgaIV4DxGwh1sZNaLpbNBSNgd3Q2N32n3bPkN WTM9BgeMsHBiImaXlyXyupO+GNzXmmiZ2F4oP23GOX9cod21ZGB1O8AsitOTorl4i3u8 J0MLf+lJh9KZaiIJ9ln2Tec+YgTMp+ymQKotsEPYEmnIW7e7zKv0S+NzQCHBQ+tLNe35 yjRG8O53Ae7cA4aE5/azySZZNcpinoe+rdbxEXaF+De2lODIm2ozGkCKExKiEBhQcY1Y Su9TXyhrQMf2EajKKnx0/C9quxqc9ydpxYkEQ23DQvTTforYYCoxGSc5IWtEB/WW6jn3 h0rQ==
X-Gm-Message-State: AOPr4FU/P7HsNyrSrAdx5rwSdB2MrysPGyrSKEfOSlqGz4a266mtHeps19Gf3t8z7weqL02iHKFC/PSaBVX9mQ==
X-Received: by 10.25.131.147 with SMTP id f141mr8465969lfd.12.1461317506727; Fri, 22 Apr 2016 02:31:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.24.42 with HTTP; Fri, 22 Apr 2016 02:31:17 -0700 (PDT)
In-Reply-To: <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>
From: Henning Rogge 
Date: Fri, 22 Apr 2016 11:31:17 +0200
Message-ID: 
To: Lotte Steenbrink 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 09:31:51 -0000

On Fri, Apr 22, 2016 at 11:28 AM, Lotte Steenbrink
 wrote:
> Hi Henning,
>
> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s wha=
t you explained to me when I got confused about the topic last spring=E2=80=
=A6 But=E2=80=93 even if a message contains TLVs that the AODVv2 implementa=
tion handling it doesn=E2=80=99t understand, it will still be able to recog=
nize the Metric TLV, right? Isn=E2=80=99t that the nifty thing about RFC544=
4? So, while we really shouldn=E2=80=99t write =E2=80=9Cbefore calculating =
the ICV, set the n-th 4 octets to 0=E2=80=9D, we might say =E2=80=9Cidentif=
y the octets that make up the metric value and set those to 0=E2=80=9D?

Of course... you can build a "binary modifier" for RFC5444...

in fact I have done something like this on the way to implement
signatures (RFC7182) because you need the message layout before you
can calculate the hash.

And I can tell you it can be a pain in the *** for a generic
parser/generator system. It is worse for signatures (you need to
add/remove TLVs), but it is still not trivial for your usecase.

Henning Rogge


From nobody Fri Apr 22 02: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 52E7712DF29 for ; Fri, 22 Apr 2016 02:57:07 -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 1F82Oo1gZK5O for ; Fri, 22 Apr 2016 02:57:05 -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 2957012DDDF for ; Fri, 22 Apr 2016 02:57:05 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,516,1454976000"; d="scan'208";a="34055142"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 22 Apr 2016 10:57:03 +0100
X-IronPort-AV: E=Sophos;i="5.24,516,1454976000"; d="scan'208";a="115096031"
Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 22 Apr 2016 10:57:04 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Fri, 22 Apr 2016 10:57:03 +0100
From: "Dearlove, Christopher (UK)" 
To: Lotte Steenbrink , Henning Rogge 
Thread-Topic: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
Thread-Index: AQHRmuq4sr6y+au39kGswdQyX9PrDp+VpYGAgAAA9YCAAAWLgIAAETzQ
Date: Fri, 22 Apr 2016 09:57:02 +0000
Message-ID: 
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>
In-Reply-To: <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>
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="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 09:57:07 -0000

SnVzdCBiZSBjYXJlZnVsIHRvIG5vdGUgdGhhdCB0aGlzIGNvbmNlcHQgaXMgYXMgY3VycmVudGx5
IGJlaW5nIGRpc2N1c3NlZCAoYSkgc3BlY2lmaWMgdG8gQU9EVnYyLCBhbmQgKGIpIG5vdCBhbiBh
cHBsaWNhdGlvbiBvZiA3MTgyLCB3aGljaCBoYXMgbm8ga25vd2xlZGdlIG9mIHNwZWNpYWwgVExW
cy4NCg0KVGhpcyBpcyBzb21ldGhpbmcgd2UnZCB3YW50IHRvIGdldCByaWdodCwgYW5kIG5lZWQg
dG8gZ2V0IHJpZ2h0IGlmIGluIGFueSBzcGFjZSBub3Qgc3BlY2lmaWMgdG8gQURPRFZ2MiwgYmVj
YXVzZSBnZXR0aW5nIGl0IHdyb25nIHByb2R1Y2VzIGZ1dHVyZSBwcm9ibGVtcy4NCg0KSSBjYW4g
c2VlIHNvbWUgcG9zc2libGUgYXBwcm9hY2hlcywgbm9uZSBpcyBpZGVhbCBhbmQgd2UncmUgcmF0
aGVyIG91dCBvZiB0aW1lIHRvIHNwZWNpZnkuIEJ1dCB0aGlzIGlzIGV4cGVyaW1lbnRhbCwgc28g
SSB0aGluayB3ZSBtaWdodCBiZSBhYmxlIHRvIGluZGljYXRlIHRoZSBzaGFwZSBvZiB0aGUgc29s
dXRpb24gd2l0aG91dCBzcGVjaWZ5aW5nIGl0LCB3aGljaCB3b3VsZCBiZSBhIGRpZmZlcmVudCBS
RkMsIHVuZGVyIGEgYml0IGxlc3MgdGltZSBwcmVzc3VyZS4gKEV4dGVuc2lvbnMgdG8gZXhpc3Rp
bmcgcHJvdG9jb2xzIGxpa2UgNzE4MiB3b3VsZCBuYXR1cmFsbHkgYmUgaW4gc2NvcGUgcmVjaGFy
dGVyZWQgSSB0aGluay4pDQoNClRvIGluZGljYXRlIHRoZSByYW5nZSB0aGF0J3Mgb3BlbiwgaGVy
ZSBhcmUgdHdvIHBvc3NpYmxlIGlkZWFzLCBvbmUgb2Ygd2hpY2ggaGFzIGFuIGltcGFjdCBub3cs
IHNvIG5lZWRzIHRvIGJlIGFncmVlZC4gTm90ZSB0aGF0IEknbSBub3Qgc3VnZ2VzdGluZyAoaW4g
ZmFjdCBxdWl0ZSB0aGUgb3Bwb3NpdGUpIGRlZmluaW5nIGFuIGV4dGVuc2lvbiB0byA3MTgyIGhl
cmUsIHJhdGhlciBlbmFibGluZyBzdWNoIGFuIGV4dGVuc2lvbiwgaWYgd3JpdHRlbiwgdG8gImRv
IHRoZSByaWdodCB0aGluZyIuDQotIFdlIGhhdmUgYW4gZXh0ZW5zaW9uIHRvIDcxODIgdGhhdCBz
YXlzICJ6ZXJvIG91dCBhbGwgdmFsdWUgb2N0ZXRzIGluIHByb3RvY29sIHNwZWNpZmljIFRMVnMu
IFRoYXQgcmVxdWlyZXMgbm93IHB1dHRpbmcgdGhlIEFPRFZ2MiBtZXRyaWMgVExWIGluIHRoYXQg
c3BhY2UuDQotIFdlIGhhdmUgYW4gZXh0ZW5zaW9uIHRvIDcxODIgdGhhdCBhZGRzIGV4dHJhIG1h
dGVyaWFsIHRvIHRoZSB2YWx1ZSBmaWVsZCB0aGF0IGluZGljYXRlcyAoVEJEIGhvdywgYnkgcG9z
aXRpb24gd2l0aCBzYW5pdHkgY2hlY2sgdGhhdCB0aGlzIGlzIFRMViB2YWx1ZSBwZXJoYXBzPykg
d2hpY2ggb2N0ZXRzIGFyZSB0byBiZSB6ZXJvZWQgb3V0IGJlZm9yZSB0aGUgSUNWIGlzIGNhbGN1
bGF0ZWQuDQoNCldlIGRvIG5vdCBoYXZlIHRoZSB0aW1lIHRvIHNwZWNpZnkgdGhpcyBpbiBhbiBh
Y2NlcHRhYmxlIG1hbm5lciB3aXRoaW4gdHdvIHdlZWtzIHRob3VnaC4gQnV0IHRoZSBzZWN1cml0
eSBjb25zaWRlcmF0aW9uIHNlY3Rpb24gY291bGQgc2F5IHNvbWV0aGluZyBhbG9uZyB0aGUgbGlu
ZXMgb2YgInRoaXMgZW5hYmxlcyB0aGUgdXNlIG9mIGFuIElDViBkZWZpbmVkIHRvIHplcm8gb3V0
IHRoZXNlIG9jdGV0cyIuDQoNCi0tIA0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmlu
Y2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRv
cmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogwqArNDQgKDApMTI0NSAyNDIxOTQgwqB8IMKg
RTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJ
bnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENo
ZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWkNCkJBRSBTeXN0
ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAm
IFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQ
YXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh
bGYgT2YgTG90dGUgU3RlZW5icmluaw0KU2VudDogMjIgQXByaWwgMjAxNiAxMDoyOA0KVG86IEhl
bm5pbmcgUm9nZ2UNCkNjOiBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdA0KU3Vi
amVjdDogUmU6IFttYW5ldF0gT24gRm9yd2FyZGluZy1hbmQtcmVnZW5lcmF0aW9uICh3YXM6IFJl
OiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlj
a2V0IEl0ZW1zKQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9y
Z2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBp
bnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24g
YW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvbGxvdyB0aGUgJ1Jl
cG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlv
bnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQotLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoqKiogV0FSTklO
RyAqKioNCkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0
c2lkZSBvdXIgb3JnYW5pemF0aW9uLg0KDQoNCkhpIEhlbm5pbmcsDQoNCj4gQW0gMjIuMDQuMjAx
NiB1bSAxMTowOCBzY2hyaWViIEhlbm5pbmcgUm9nZ2UgPGhyb2dnZUBnbWFpbC5jb20+Og0KPiAN
Cj4gT24gRnJpLCBBcHIgMjIsIDIwMTYgYXQgMTE6MDUgQU0sIExvdHRlIFN0ZWVuYnJpbmsgDQo+
IDxsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZT4gd3JvdGU6DQo+PiBIaSBUaG9tYXMsDQo+
PiBDYW4gaXQ/ISBJaXJjLCB0aGUgcmVhc29uIHdoeSB3ZSBhZG9wdGVkIHRoZSDigJxyZWdlbmVy
YXRpb27igJ0gbGFuZ3VhZ2UgDQo+PiBpbiB0aGUgZmlyc3QgcGxhY2UgaXMgdGhhdCB3ZeKAmXZl
IGJlZW4gdG9sZCB0aGF0IHdoZW5ldmVyIG9uZSBiaXQgaW4gDQo+PiB0aGUgbWVzc2FnZSAoYXBh
cnQgZnJvbSBpdHMgaGVhZGVyKSBpcyBjaGFuZ2VkLCB0aGUgZW50aXJlIHRoaW5nIGhhcyB0byBi
ZSByZWdlbmVyYXRlZC4NCj4+IEnigJltIHN0YXJ0aW5nIHRvIGdldCB0aGUgZmVlbGluZyB3ZeKA
mXZlIGp1c3QgYmVlbiBtaXN1bmRlcnN0YW5kaW5nIGVhY2ggDQo+PiBvdGhlciBmb3IgbW9yZSB0
aGFuIGEgeWVhci4gOiggQW55d2F5LCBpdCBzZWVtcyBsaWtlIHdl4oCZcmUgZ2V0dGluZyANCj4+
IGNsb3NlIG5vdywgc28geWF5Lg0KPiANCj4gIk1vZGlmeWluZyIgdGhlIGJpbmFyeSBtZXNzYWdl
IGluc3RlYWQgb2YgcGFyc2luZyBhbmQgZ2VuZXJhdGluZyBhIG5ldyANCj4gb25lIHdpbGwgYmUg
ZGlmZmljdWx0IGFzIHNvb24gc29tZW9uZSB3cml0ZXMgYW4gZXh0ZW5zaW9uIHRvIEFPRFZ2MiAN
Cj4gdGhhdCBhZGRzIG1vcmUgVExWcyB0byB0aGUgbWVzc2FnZS4NCj4gDQoNCkTigJlvaCwgcmln
aHQuIFllYWgsIGlmIEkgcmVtZW1iZXIgaXQgY29ycmVjdGx5LCB0aGF04oCZcyB3aGF0IHlvdSBl
eHBsYWluZWQgdG8gbWUgd2hlbiBJIGdvdCBjb25mdXNlZCBhYm91dCB0aGUgdG9waWMgbGFzdCBz
cHJpbmfigKYgQnV04oCTIGV2ZW4gaWYgYSBtZXNzYWdlIGNvbnRhaW5zIFRMVnMgdGhhdCB0aGUg
QU9EVnYyIGltcGxlbWVudGF0aW9uIGhhbmRsaW5nIGl0IGRvZXNu4oCZdCB1bmRlcnN0YW5kLCBp
dCB3aWxsIHN0aWxsIGJlIGFibGUgdG8gcmVjb2duaXplIHRoZSBNZXRyaWMgVExWLCByaWdodD8g
SXNu4oCZdCB0aGF0IHRoZSBuaWZ0eSB0aGluZyBhYm91dCBSRkM1NDQ0PyBTbywgd2hpbGUgd2Ug
cmVhbGx5IHNob3VsZG7igJl0IHdyaXRlIOKAnGJlZm9yZSBjYWxjdWxhdGluZyB0aGUgSUNWLCBz
ZXQgdGhlIG4tdGggNCBvY3RldHMgdG8gMOKAnSwgd2UgbWlnaHQgc2F5IOKAnGlkZW50aWZ5IHRo
ZSBvY3RldHMgdGhhdCBtYWtlIHVwIHRoZSBtZXRyaWMgdmFsdWUgYW5kIHNldCB0aG9zZSB0byAw
4oCdPw0KDQpCZXN0IHJlZ2FyZHMsDQpMb3R0ZQ0KDQo+IEhlbm5pbmcgUm9nZ2UNCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcg
bGlzdA0KbWFuZXRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbWFuZXQNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUg
Y29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHBy
aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRl
bGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3Vs
ZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpk
aXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo=


From nobody Fri Apr 22 05:49: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 01B0912D9B7 for ; Fri, 22 Apr 2016 05:49:36 -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 OWFWLW2iajoA for ; Fri, 22 Apr 2016 05:49:34 -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 49C2A12D786 for ; Fri, 22 Apr 2016 05:49:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D98A13401A4; Fri, 22 Apr 2016 05:49:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461329373; bh=77ZRE0RcNIVGCyF1S3YmMSLi3gjhDT3DkeayWXwSATg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=VT2SlQhQVOjzpATbKGjaS27qwqxQCYHjkD5Ofwyact60mQ09oyLqv4oKjmbN4TSJA bIK6bN9z8u9Hca01xM3i+vwFwXDjDA4hKALvHplC7SWjTg9uoJh+aVp6GVFv4wxVM6 BsvcUjHzo9SXpdocgVAhwvaqiO1ZRyB5nG0YNXbg=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [100.113.155.142] (unknown [37.161.39.36]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id C75AE1C028F; Fri, 22 Apr 2016 05:49:30 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPhone Mail (13E238)
In-Reply-To: 
Date: Fri, 22 Apr 2016 14:49:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <61AE3F0A-E9D5-4936-8962-4D66A07E95C0@thomasclausen.org>
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de> 
To: "Dearlove, Christopher (UK)" 
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 12:49:36 -0000

> On 22 avr. 2016, at 11:57, Dearlove, Christopher (UK)  wrote:
>=20
> Just be careful to note that this concept is as currently being discussed (=
a) specific to AODVv2, and (b) not an application of 7182, which has no know=
ledge of special TLVs.
>=20
> This is something we'd want to get right, and need to get right if in any s=
pace not specific to ADODVv2, because getting it wrong produces future probl=
ems.
>=20

It would seem obvious that this "special TLV" would be specified without a r=
eserved TLV type from the IANA registries - and that in the experiment enabl=
ed by an experimental RFC, we would want to use (TLV, message) types from th=
e Experimental type space from these registries. This precisely because this=
 is something which, as Chris suggests, "getting wrong produces future probl=
ems".=20

Thomas
(Running between meetings)

> I can see some possible approaches, none is ideal and we're rather out of t=
ime to specify. But this is experimental, so I think we might be able to ind=
icate the shape of the solution without specifying it, which would be a diff=
erent RFC, under a bit less time pressure. (Extensions to existing protocols=
 like 7182 would naturally be in scope rechartered I think.)
>=20
> To indicate the range that's open, here are two possible ideas, one of whi=
ch has an impact now, so needs to be agreed. Note that I'm not suggesting (i=
n fact quite the opposite) defining an extension to 7182 here, rather enabli=
ng such an extension, if written, to "do the right thing".
> - We have an extension to 7182 that says "zero out all value octets in pro=
tocol specific TLVs. That requires now putting the AODVv2 metric TLV in that=
 space.
> - We have an extension to 7182 that adds extra material to the value field=
 that indicates (TBD how, by position with sanity check that this is TLV val=
ue perhaps?) which octets are to be zeroed out before the ICV is calculated.=

>=20
> We do not have the time to specify this in an acceptable manner within two=
 weeks though. But the security consideration section could say something al=
ong the lines of "this enables the use of an ICV defined to zero out these o=
ctets".
>=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
> -----Original Message-----
> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte Steenbrink
> Sent: 22 April 2016 10:28
> To: Henning Rogge
> Cc: Mobile Ad Hoc Networks mailing list
> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-m=
anet-aodvv2-13 review - a couple of big ticket Items)
>=20
> ----------------------! WARNING ! ---------------------- This message orig=
inates 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 attachm=
ents or reply.
> Follow the 'Report Suspicious Emails' link on IT matters for instructions o=
n reporting suspicious email messages.
> --------------------------------------------------------
>=20
> *** WARNING ***
> EXTERNAL EMAIL -- This message originates from outside our organization.
>=20
>=20
> Hi Henning,
>=20
>> Am 22.04.2016 um 11:08 schrieb Henning Rogge :
>>=20
>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink=20
>>  wrote:
>>> Hi Thomas,
>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=E2=80=
=9D language=20
>>> in the first place is that we=E2=80=99ve been told that whenever one bit=
 in=20
>>> the message (apart from its header) is changed, the entire thing has to b=
e regenerated.
>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been misunder=
standing each=20
>>> other for more than a year. :( Anyway, it seems like we=E2=80=99re getti=
ng=20
>>> close now, so yay.
>>=20
>> "Modifying" the binary message instead of parsing and generating a new=20=

>> one will be difficult as soon someone writes an extension to AODVv2=20
>> that adds more TLVs to the message.
>=20
> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s what=
 you explained to me when I got confused about the topic last spring=E2=80=A6=
 But=E2=80=93 even if a message contains TLVs that the AODVv2 implementation=
 handling it doesn=E2=80=99t understand, it will still be able to recognize t=
he Metric TLV, right? Isn=E2=80=99t that the nifty thing about RFC5444? So, w=
hile we really shouldn=E2=80=99t write =E2=80=9Cbefore calculating the ICV, s=
et the n-th 4 octets to 0=E2=80=9D, we might say =E2=80=9Cidentify the octet=
s that make up the metric value and set those to 0=E2=80=9D?
>=20
> Best regards,
> Lotte
>=20
>> Henning Rogge
>=20
> _______________________________________________
> 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


From nobody Fri Apr 22 05:58: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 5BA2912E4E0 for ; Fri, 22 Apr 2016 05:58:53 -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 WoDp2bH_Qkel for ; Fri, 22 Apr 2016 05:58:51 -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 8539D12E4A9 for ; Fri, 22 Apr 2016 05:58:51 -0700 (PDT)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1atafZ-0047X5-Hs>; Fri, 22 Apr 2016 14:58:49 +0200
Received: from ext176.non-member.tu-haburg.de ([195.37.187.176] helo=[172.16.19.135]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id <1atafZ-000Iww-9g>; Fri, 22 Apr 2016 14:58:49 +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: 
Date: Fri, 22 Apr 2016 14:58:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de> 
To: Mobile Ad Hoc Networks mailing list 
X-Mailer: Apple Mail (2.3112)
X-Originating-IP: 195.37.187.176
Archived-At: 
Cc: "Dearlove, Christopher \(UK\)" 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 12:58:53 -0000

Hello Christopher,

> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) =
:
>=20
> Just be careful to note that this concept is as currently being =
discussed (a) specific to AODVv2, and (b) not an application of 7182, =
which has no knowledge of special TLVs.
>=20
> This is something we'd want to get right, and need to get right if in =
any space not specific to ADODVv2, because getting it wrong produces =
future problems.
>=20

Makes sense.

> I can see some possible approaches, none is ideal and we're rather out =
of time to specify. But this is experimental, so I think we might be =
able to indicate the shape of the solution without specifying it, which =
would be a different RFC, under a bit less time pressure. (Extensions to =
existing protocols like 7182 would naturally be in scope rechartered I =
think.)
>=20
> To indicate the range that's open, here are two possible ideas, one of =
which has an impact now, so needs to be agreed. Note that I'm not =
suggesting (in fact quite the opposite) defining an extension to 7182 =
here, rather enabling such an extension, if written, to "do the right =
thing".
> - We have an extension to 7182 that says "zero out all value octets in =
protocol specific TLVs. That requires now putting the AODVv2 metric TLV =
in that space.

Just to make sure that I understood you correctly=E2=80=93 =E2=80=9Cthat =
space=E2=80=9D meaning making the AODVv2 metric TLV protocol specific? =
(By =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m referring to the =
generic TLV we=E2=80=99ve been talking about on this list earlier this =
week).

> - We have an extension to 7182 that adds extra material to the value =
field that indicates (TBD how, by position with sanity check that this =
is TLV value perhaps?) which octets are to be zeroed out before the ICV =
is calculated.

The way I understand that approach, it wouldn=E2=80=99t warrant any =
action from AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set =
the Metric value to zero=E2=80=9D (leaving the nitty gritty of how this =
would be done in detail to future work)=E2=80=A6 Is that correct?

>=20
> We do not have the time to specify this in an acceptable manner within =
two weeks though. But the security consideration section could say =
something along the lines of "this enables the use of an ICV defined to =
zero out these octets=E2=80=9C.

Okay. :)

Best regards,
Lotte

>=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
> -----Original Message-----
> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte =
Steenbrink
> Sent: 22 April 2016 10:28
> To: Henning Rogge
> Cc: Mobile Ad Hoc Networks mailing list
> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>=20
> ----------------------! WARNING ! ---------------------- This message =
originates from outside our organisation, either from an external =
partner or from the internet.
> Consider carefully whether you should click on any links, open any =
attachments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters for =
instructions on reporting suspicious email messages.
> --------------------------------------------------------
>=20
> *** WARNING ***
> EXTERNAL EMAIL -- This message originates from outside our =
organization.
>=20
>=20
> Hi Henning,
>=20
>> Am 22.04.2016 um 11:08 schrieb Henning Rogge :
>>=20
>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink=20
>>  wrote:
>>> Hi Thomas,
>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=E2=80=
=9D language=20
>>> in the first place is that we=E2=80=99ve been told that whenever one =
bit in=20
>>> the message (apart from its header) is changed, the entire thing has =
to be regenerated.
>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been =
misunderstanding each=20
>>> other for more than a year. :( Anyway, it seems like we=E2=80=99re =
getting=20
>>> close now, so yay.
>>=20
>> "Modifying" the binary message instead of parsing and generating a =
new=20
>> one will be difficult as soon someone writes an extension to AODVv2=20=

>> that adds more TLVs to the message.
>>=20
>=20
> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s =
what you explained to me when I got confused about the topic last =
spring=E2=80=A6 But=E2=80=93 even if a message contains TLVs that the =
AODVv2 implementation handling it doesn=E2=80=99t understand, it will =
still be able to recognize the Metric TLV, right? Isn=E2=80=99t that the =
nifty thing about RFC5444? So, while we really shouldn=E2=80=99t write =
=E2=80=9Cbefore calculating the ICV, set the n-th 4 octets to 0=E2=80=9D, =
we might say =E2=80=9Cidentify the octets that make up the metric value =
and set those to 0=E2=80=9D?
>=20
> Best regards,
> Lotte
>=20
>> Henning Rogge
>=20
> _______________________________________________
> 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 Fri Apr 22 06:05: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 0CC7312EBA7 for ; Fri, 22 Apr 2016 06:05:39 -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 NAyfAHH_AFZU for ; Fri, 22 Apr 2016 06:05:37 -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 6270312EB92 for ; Fri, 22 Apr 2016 06:05:36 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,517,1454976000"; d="scan'208";a="63377761"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 22 Apr 2016 14:05:34 +0100
X-IronPort-AV: E=Sophos;i="5.24,517,1454976000"; d="scan'208";a="115132699"
Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 22 Apr 2016 14:05:34 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0248.002; Fri, 22 Apr 2016 14:05:34 +0100
From: "Dearlove, Christopher (UK)" 
To: Lotte Steenbrink , "Mobile Ad Hoc Networks mailing list" 
Thread-Topic: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
Thread-Index: AQHRmuq4sr6y+au39kGswdQyX9PrDp+VpYGAgAAA9YCAAAWLgIAAETzQgAAplICAABFWYA==
Date: Fri, 22 Apr 2016 13:05:33 +0000
Message-ID: 
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 13:05:39 -0000

T25jZSB5b3UncmUgZW50aXJlbHkgaW4gQU9EVjIncyBvd24gc3BhY2UsIGFuZCBBT0RWdjIgaXMg
ZXhwZXJpbWVudGFsICh3b3JraW5nIGFzc3VtcHRpb24gZm9yIHRoaXMgZGlzY3Vzc2lvbikgeW91
IGhhdmUgbW9yZSBsaWJlcnR5Lg0KDQpUaGVuIHlvdSBjb3VsZCB0cnkgc3BlY2lmeWluZyBpdC4g
QnV0IHdpdGggYSB2ZXJ5IGdvb2QgY2hhbmNlIG9mIHByb2R1Y2luZyBzb21ldGhpbmcgeW91IGxh
dGVyIGRlY2lkZSB5b3Ugc2hvdWxkIGhhdmUgZG9uZSBkaWZmZXJlbnRseS4NCg0KSSBob25lc3Rs
eSBkb24ndCBrbm93IHdoaWNoIHdvdWxkIGdvIGRvd24gYmV0dGVyIChvciBsZXNzIGJhZGx5KSAt
ICJoZXJlJ3MgYSBtZWNoYW5pc20gd2UgaGF2ZW4ndCByZWFsbHkgdGhvdWdodCB0aHJvdWdoIGlu
IGRldGFpbCwgYnV0IGF0IGxlYXN0IHdlJ3ZlIGRlZmluZWQgb25lIiwgb3IgIndlIGtub3cgdGhl
IHNvcnQgb2YgdGhpbmcgd2Ugd2FudCwgYW5kIHdlJ2xsIGRlc2NyaWJlIGl0LCBidXQgcmF0aGVy
IHRoYW4gcHJvZHVjZSBzb21ldGhpbmcgbm90IHF1aXRlIHJpZ2h0LCB3ZSdsbCBub3QgZ28gZnVy
dGhlciIuDQoNCi0tIA0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5n
aW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCg0KVDogwqArNDQgKDApMTI0NSAyNDIxOTQgwqB8IMKgRTogY2hyaXMu
ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu
Y2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQs
IEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWkNCkJBRSBTeXN0ZW1zIEFwcGxp
ZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5v
OiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWls
ZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG
cm9tOiBMb3R0ZSBTdGVlbmJyaW5rIFttYWlsdG86bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4u
ZGVdIA0KU2VudDogMjIgQXByaWwgMjAxNiAxMzo1OQ0KVG86IE1vYmlsZSBBZCBIb2MgTmV0d29y
a3MgbWFpbGluZyBsaXN0DQpDYzogSGVubmluZyBSb2dnZTsgRGVhcmxvdmUsIENocmlzdG9waGVy
IChVSykNClN1YmplY3Q6IFJlOiBbbWFuZXRdIE9uIEZvcndhcmRpbmctYW5kLXJlZ2VuZXJhdGlv
biAod2FzOiBSZTogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUg
b2YgYmlnIHRpY2tldCBJdGVtcykNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAh
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRz
aWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3Ig
ZnJvbSB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxk
IGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb2xs
b3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3Ig
aW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K
SGVsbG8gQ2hyaXN0b3BoZXIsDQoNCj4gQW0gMjIuMDQuMjAxNiB1bSAxMTo1NyBzY2hyaWViIERl
YXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT46
DQo+IA0KPiBKdXN0IGJlIGNhcmVmdWwgdG8gbm90ZSB0aGF0IHRoaXMgY29uY2VwdCBpcyBhcyBj
dXJyZW50bHkgYmVpbmcgZGlzY3Vzc2VkIChhKSBzcGVjaWZpYyB0byBBT0RWdjIsIGFuZCAoYikg
bm90IGFuIGFwcGxpY2F0aW9uIG9mIDcxODIsIHdoaWNoIGhhcyBubyBrbm93bGVkZ2Ugb2Ygc3Bl
Y2lhbCBUTFZzLg0KPiANCj4gVGhpcyBpcyBzb21ldGhpbmcgd2UnZCB3YW50IHRvIGdldCByaWdo
dCwgYW5kIG5lZWQgdG8gZ2V0IHJpZ2h0IGlmIGluIGFueSBzcGFjZSBub3Qgc3BlY2lmaWMgdG8g
QURPRFZ2MiwgYmVjYXVzZSBnZXR0aW5nIGl0IHdyb25nIHByb2R1Y2VzIGZ1dHVyZSBwcm9ibGVt
cy4NCj4gDQoNCk1ha2VzIHNlbnNlLg0KDQo+IEkgY2FuIHNlZSBzb21lIHBvc3NpYmxlIGFwcHJv
YWNoZXMsIG5vbmUgaXMgaWRlYWwgYW5kIHdlJ3JlIHJhdGhlciBvdXQgDQo+IG9mIHRpbWUgdG8g
c3BlY2lmeS4gQnV0IHRoaXMgaXMgZXhwZXJpbWVudGFsLCBzbyBJIHRoaW5rIHdlIG1pZ2h0IGJl
IA0KPiBhYmxlIHRvIGluZGljYXRlIHRoZSBzaGFwZSBvZiB0aGUgc29sdXRpb24gd2l0aG91dCBz
cGVjaWZ5aW5nIGl0LCANCj4gd2hpY2ggd291bGQgYmUgYSBkaWZmZXJlbnQgUkZDLCB1bmRlciBh
IGJpdCBsZXNzIHRpbWUgcHJlc3N1cmUuIA0KPiAoRXh0ZW5zaW9ucyB0byBleGlzdGluZyBwcm90
b2NvbHMgbGlrZSA3MTgyIHdvdWxkIG5hdHVyYWxseSBiZSBpbiANCj4gc2NvcGUgcmVjaGFydGVy
ZWQgSSB0aGluay4pDQo+IA0KPiBUbyBpbmRpY2F0ZSB0aGUgcmFuZ2UgdGhhdCdzIG9wZW4sIGhl
cmUgYXJlIHR3byBwb3NzaWJsZSBpZGVhcywgb25lIG9mIHdoaWNoIGhhcyBhbiBpbXBhY3Qgbm93
LCBzbyBuZWVkcyB0byBiZSBhZ3JlZWQuIE5vdGUgdGhhdCBJJ20gbm90IHN1Z2dlc3RpbmcgKGlu
IGZhY3QgcXVpdGUgdGhlIG9wcG9zaXRlKSBkZWZpbmluZyBhbiBleHRlbnNpb24gdG8gNzE4MiBo
ZXJlLCByYXRoZXIgZW5hYmxpbmcgc3VjaCBhbiBleHRlbnNpb24sIGlmIHdyaXR0ZW4sIHRvICJk
byB0aGUgcmlnaHQgdGhpbmciLg0KPiAtIFdlIGhhdmUgYW4gZXh0ZW5zaW9uIHRvIDcxODIgdGhh
dCBzYXlzICJ6ZXJvIG91dCBhbGwgdmFsdWUgb2N0ZXRzIGluIHByb3RvY29sIHNwZWNpZmljIFRM
VnMuIFRoYXQgcmVxdWlyZXMgbm93IHB1dHRpbmcgdGhlIEFPRFZ2MiBtZXRyaWMgVExWIGluIHRo
YXQgc3BhY2UuDQoNCkp1c3QgdG8gbWFrZSBzdXJlIHRoYXQgSSB1bmRlcnN0b29kIHlvdSBjb3Jy
ZWN0bHnigJMg4oCcdGhhdCBzcGFjZeKAnSBtZWFuaW5nIG1ha2luZyB0aGUgQU9EVnYyIG1ldHJp
YyBUTFYgcHJvdG9jb2wgc3BlY2lmaWM/IChCeSDigJx0aGUgYW9kdnYyIG1ldHJpYyB0bHbigJ0g
SeKAmW0gcmVmZXJyaW5nIHRvIHRoZSBnZW5lcmljIFRMViB3ZeKAmXZlIGJlZW4gdGFsa2luZyBh
Ym91dCBvbiB0aGlzIGxpc3QgZWFybGllciB0aGlzIHdlZWspLg0KDQo+IC0gV2UgaGF2ZSBhbiBl
eHRlbnNpb24gdG8gNzE4MiB0aGF0IGFkZHMgZXh0cmEgbWF0ZXJpYWwgdG8gdGhlIHZhbHVlIGZp
ZWxkIHRoYXQgaW5kaWNhdGVzIChUQkQgaG93LCBieSBwb3NpdGlvbiB3aXRoIHNhbml0eSBjaGVj
ayB0aGF0IHRoaXMgaXMgVExWIHZhbHVlIHBlcmhhcHM/KSB3aGljaCBvY3RldHMgYXJlIHRvIGJl
IHplcm9lZCBvdXQgYmVmb3JlIHRoZSBJQ1YgaXMgY2FsY3VsYXRlZC4NCg0KVGhlIHdheSBJIHVu
ZGVyc3RhbmQgdGhhdCBhcHByb2FjaCwgaXQgd291bGRu4oCZdCB3YXJyYW50IGFueSBhY3Rpb24g
ZnJvbSBBT0RWdjIgYmVzaWRlcyBzYXlpbmcg4oCcaWYgeW91IGNhbGN1bGF0ZSB0aGUgSUNWLCBz
ZXQgdGhlIE1ldHJpYyB2YWx1ZSB0byB6ZXJv4oCdIChsZWF2aW5nIHRoZSBuaXR0eSBncml0dHkg
b2YgaG93IHRoaXMgd291bGQgYmUgZG9uZSBpbiBkZXRhaWwgdG8gZnV0dXJlIHdvcmsp4oCmIElz
IHRoYXQgY29ycmVjdD8NCg0KPiANCj4gV2UgZG8gbm90IGhhdmUgdGhlIHRpbWUgdG8gc3BlY2lm
eSB0aGlzIGluIGFuIGFjY2VwdGFibGUgbWFubmVyIHdpdGhpbiB0d28gd2Vla3MgdGhvdWdoLiBC
dXQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBjb3VsZCBzYXkgc29tZXRoaW5n
IGFsb25nIHRoZSBsaW5lcyBvZiAidGhpcyBlbmFibGVzIHRoZSB1c2Ugb2YgYW4gSUNWIGRlZmlu
ZWQgdG8gemVybyBvdXQgdGhlc2Ugb2N0ZXRz4oCcLg0KDQpPa2F5LiA6KQ0KDQpCZXN0IHJlZ2Fy
ZHMsDQpMb3R0ZQ0KDQo+IA0KPiAtLQ0KPiBDaHJpc3RvcGhlciBEZWFybG92ZQ0KPiBTZW5pb3Ig
UHJpbmNpcGFsIEVuZ2luZWVyDQo+IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExh
Ym9yYXRvcmllcyANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fDQo+IA0KPiBUOiAgKzQ0ICgwKTEy
NDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbQ0KPiANCj4gQkFF
IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJr
LCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQo+IHd3dy5iYWVzeXN0
ZW1zLmNvbS9haQ0KPiBCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkIFJl
Z2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIA0KPiBObzogMDEzMzc0NTEgUmVnaXN0ZXJlZCBP
ZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIA0KPiBTdXJyZXksIEdVMiA3
WVANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1hbmV0IFttYWls
dG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvdHRlIA0KPiBTdGVlbmJy
aW5rDQo+IFNlbnQ6IDIyIEFwcmlsIDIwMTYgMTA6MjgNCj4gVG86IEhlbm5pbmcgUm9nZ2UNCj4g
Q2M6IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0DQo+IFN1YmplY3Q6IFJlOiBb
bWFuZXRdIE9uIEZvcndhcmRpbmctYW5kLXJlZ2VuZXJhdGlvbiAod2FzOiBSZTogDQo+IGRyYWZ0
LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEgY291cGxlIG9mIGJpZyB0aWNrZXQgSXRl
bXMpDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2Fu
aXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRl
cm5ldC4NCj4gQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBh
bnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KPiBGb2xsb3cgdGhlICdS
ZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rp
b25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KPiAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gKioq
IFdBUk5JTkcgKioqDQo+IEVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVz
IGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uLg0KPiANCj4gDQo+IEhpIEhlbm5pbmcsDQo+
IA0KPj4gQW0gMjIuMDQuMjAxNiB1bSAxMTowOCBzY2hyaWViIEhlbm5pbmcgUm9nZ2UgPGhyb2dn
ZUBnbWFpbC5jb20+Og0KPj4gDQo+PiBPbiBGcmksIEFwciAyMiwgMjAxNiBhdCAxMTowNSBBTSwg
TG90dGUgU3RlZW5icmluayANCj4+IDxsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZT4gd3Jv
dGU6DQo+Pj4gSGkgVGhvbWFzLA0KPj4+IENhbiBpdD8hIElpcmMsIHRoZSByZWFzb24gd2h5IHdl
IGFkb3B0ZWQgdGhlIOKAnHJlZ2VuZXJhdGlvbuKAnSBsYW5ndWFnZSANCj4+PiBpbiB0aGUgZmly
c3QgcGxhY2UgaXMgdGhhdCB3ZeKAmXZlIGJlZW4gdG9sZCB0aGF0IHdoZW5ldmVyIG9uZSBiaXQg
aW4gDQo+Pj4gdGhlIG1lc3NhZ2UgKGFwYXJ0IGZyb20gaXRzIGhlYWRlcikgaXMgY2hhbmdlZCwg
dGhlIGVudGlyZSB0aGluZyBoYXMgdG8gYmUgcmVnZW5lcmF0ZWQuDQo+Pj4gSeKAmW0gc3RhcnRp
bmcgdG8gZ2V0IHRoZSBmZWVsaW5nIHdl4oCZdmUganVzdCBiZWVuIG1pc3VuZGVyc3RhbmRpbmcg
DQo+Pj4gZWFjaCBvdGhlciBmb3IgbW9yZSB0aGFuIGEgeWVhci4gOiggQW55d2F5LCBpdCBzZWVt
cyBsaWtlIHdl4oCZcmUgDQo+Pj4gZ2V0dGluZyBjbG9zZSBub3csIHNvIHlheS4NCj4+IA0KPj4g
Ik1vZGlmeWluZyIgdGhlIGJpbmFyeSBtZXNzYWdlIGluc3RlYWQgb2YgcGFyc2luZyBhbmQgZ2Vu
ZXJhdGluZyBhIA0KPj4gbmV3IG9uZSB3aWxsIGJlIGRpZmZpY3VsdCBhcyBzb29uIHNvbWVvbmUg
d3JpdGVzIGFuIGV4dGVuc2lvbiB0byANCj4+IEFPRFZ2MiB0aGF0IGFkZHMgbW9yZSBUTFZzIHRv
IHRoZSBtZXNzYWdlLg0KPj4gDQo+IA0KPiBE4oCZb2gsIHJpZ2h0LiBZZWFoLCBpZiBJIHJlbWVt
YmVyIGl0IGNvcnJlY3RseSwgdGhhdOKAmXMgd2hhdCB5b3UgZXhwbGFpbmVkIHRvIG1lIHdoZW4g
SSBnb3QgY29uZnVzZWQgYWJvdXQgdGhlIHRvcGljIGxhc3Qgc3ByaW5n4oCmIEJ1dOKAkyBldmVu
IGlmIGEgbWVzc2FnZSBjb250YWlucyBUTFZzIHRoYXQgdGhlIEFPRFZ2MiBpbXBsZW1lbnRhdGlv
biBoYW5kbGluZyBpdCBkb2VzbuKAmXQgdW5kZXJzdGFuZCwgaXQgd2lsbCBzdGlsbCBiZSBhYmxl
IHRvIHJlY29nbml6ZSB0aGUgTWV0cmljIFRMViwgcmlnaHQ/IElzbuKAmXQgdGhhdCB0aGUgbmlm
dHkgdGhpbmcgYWJvdXQgUkZDNTQ0ND8gU28sIHdoaWxlIHdlIHJlYWxseSBzaG91bGRu4oCZdCB3
cml0ZSDigJxiZWZvcmUgY2FsY3VsYXRpbmcgdGhlIElDViwgc2V0IHRoZSBuLXRoIDQgb2N0ZXRz
IHRvIDDigJ0sIHdlIG1pZ2h0IHNheSDigJxpZGVudGlmeSB0aGUgb2N0ZXRzIHRoYXQgbWFrZSB1
cCB0aGUgbWV0cmljIHZhbHVlIGFuZCBzZXQgdGhvc2UgdG8gMOKAnT8NCj4gDQo+IEJlc3QgcmVn
YXJkcywNCj4gTG90dGUNCj4gDQo+PiBIZW5uaW5nIFJvZ2dlDQo+IA0KPiBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtYW5ldCBtYWlsaW5nIGxpc3QN
Cj4gbWFuZXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9tYW5ldA0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKg0KPiBUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg
YXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQgDQo+IHJlY2lwaWVudCBhbmQgbWF5IGFs
c28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIA0KPiByZWNpcGll
bnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRl
ci4NCj4gWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5v
ciBkaXNjbG9zZSBvciANCj4gZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBl
cnNvbi4NCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioNCg0K


From nobody Fri Apr 22 06:21: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 A87A812ECEB for ; Fri, 22 Apr 2016 06:21:33 -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, 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 va3uTHlerw7V for ; Fri, 22 Apr 2016 06:21:31 -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 AE37812ECF0 for ; Fri, 22 Apr 2016 06:21:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6AAE624E0B4; Fri, 22 Apr 2016 06:21:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461331291; bh=jk5WfXJCtLkAqdsKIgvn3PFiSg9EMx+YcrRuYkYnAdQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=gQweFuIe0E+Se8Dla8TgzBQtVC4bhN9u+6BK4C1/W+i5vm1LruqaYlWj3Wq26X5z1 lFX1u6X5/F2WRzxok7tpQ43Ok5ulKFUXg/3aCqnTjz5nNj2Lqxotn8XcRepLbMXE1E 2vn1PSQDVVFpwrGIQRACdS0llq5UWDnVE6oor12Y=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [129.104.72.127] (unknown [129.104.72.127]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id B890924B534; Fri, 22 Apr 2016 06:21:30 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPhone Mail (13E238)
In-Reply-To: 
Date: Fri, 22 Apr 2016 15:21:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org>
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>   
To: "Dearlove, Christopher (UK)" 
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 13:21:33 -0000

> On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK)  wrote:
>=20
> Once you're entirely in AODV2's own space, and AODVv2 is experimental (wor=
king assumption for this discussion) you have more liberty.
>=20

Yep.=20

Taken somewhat by surprise both by the sudden "rush" and the experimental ma=
turity level, I am wondering (and haven't thought through) about experimenta=
l space vs non-experimental (for message types, and consequently for message=
 type specific TLV types).=20

I think that if the AODVv2 experiment specifies the use of Message types fro=
m the Experimental message type space without making actual registrations in=
 the IANA registry, AND the use of type specific TLV types, this becomes a n=
on-issue entirely (by design, this is precisely what that experimental space=
 is for)

Whereas, as you point out, the alternative is a "can open - worms everywhere=
" situation that I think time is too short to solve?

Thomas


> Then you could try specifying it. But with a very good chance of producing=
 something you later decide you should have done differently.
>=20
> I honestly don't know which would go down better (or less badly) - "here's=
 a mechanism we haven't really thought through in detail, but at least we've=
 defined one", or "we know the sort of thing we want, and we'll describe it,=
 but rather than produce something not quite right, we'll not go further".
>=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
> -----Original Message-----
> From: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]=20
> Sent: 22 April 2016 13:59
> To: Mobile Ad Hoc Networks mailing list
> Cc: Henning Rogge; Dearlove, Christopher (UK)
> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-m=
anet-aodvv2-13 review - a couple of big ticket Items)
>=20
> ----------------------! WARNING ! ---------------------- This message orig=
inates 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 attachm=
ents or reply.
> Follow the 'Report Suspicious Emails' link on IT matters for instructions o=
n reporting suspicious email messages.
> --------------------------------------------------------
>=20
> Hello Christopher,
>=20
>> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) :
>>=20
>> Just be careful to note that this concept is as currently being discussed=
 (a) specific to AODVv2, and (b) not an application of 7182, which has no kn=
owledge of special TLVs.
>>=20
>> This is something we'd want to get right, and need to get right if in any=
 space not specific to ADODVv2, because getting it wrong produces future pro=
blems.
>=20
> Makes sense.
>=20
>> I can see some possible approaches, none is ideal and we're rather out=20=

>> of time to specify. But this is experimental, so I think we might be=20
>> able to indicate the shape of the solution without specifying it,=20
>> which would be a different RFC, under a bit less time pressure.=20
>> (Extensions to existing protocols like 7182 would naturally be in=20
>> scope rechartered I think.)
>>=20
>> To indicate the range that's open, here are two possible ideas, one of wh=
ich has an impact now, so needs to be agreed. Note that I'm not suggesting (=
in fact quite the opposite) defining an extension to 7182 here, rather enabl=
ing such an extension, if written, to "do the right thing".
>> - We have an extension to 7182 that says "zero out all value octets in pr=
otocol specific TLVs. That requires now putting the AODVv2 metric TLV in tha=
t space.
>=20
> Just to make sure that I understood you correctly=E2=80=93 =E2=80=9Cthat s=
pace=E2=80=9D meaning making the AODVv2 metric TLV protocol specific? (By =E2=
=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m referring to the generic TL=
V we=E2=80=99ve been talking about on this list earlier this week).
>=20
>> - We have an extension to 7182 that adds extra material to the value fiel=
d that indicates (TBD how, by position with sanity check that this is TLV va=
lue perhaps?) which octets are to be zeroed out before the ICV is calculated=
.
>=20
> The way I understand that approach, it wouldn=E2=80=99t warrant any action=
 from AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set the Metri=
c value to zero=E2=80=9D (leaving the nitty gritty of how this would be done=
 in detail to future work)=E2=80=A6 Is that correct?
>=20
>>=20
>> We do not have the time to specify this in an acceptable manner within tw=
o weeks though. But the security consideration section could say something a=
long the lines of "this enables the use of an ICV defined to zero out these o=
ctets=E2=80=9C.
>=20
> Okay. :)
>=20
> Best regards,
> Lotte
>=20
>>=20
>> --
>> Christopher Dearlove
>> Senior Principal Engineer
>> BAE Systems Applied Intelligence Laboratories=20
>> ______________________________________________________________________
>> ____
>>=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=20=

>> No: 01337451 Registered Office: Surrey Research Park, Guildford,=20
>> Surrey, GU2 7YP
>>=20
>> -----Original Message-----
>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte=20
>> Steenbrink
>> Sent: 22 April 2016 10:28
>> To: Henning Rogge
>> Cc: Mobile Ad Hoc Networks mailing list
>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:=20
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>=20
>> ----------------------! WARNING ! ---------------------- This message ori=
ginates from outside our organisation, either from an external partner or fr=
om the internet.
>> Consider carefully whether you should click on any links, open any attach=
ments or reply.
>> Follow the 'Report Suspicious Emails' link on IT matters for instructions=
 on reporting suspicious email messages.
>> --------------------------------------------------------
>>=20
>> *** WARNING ***
>> EXTERNAL EMAIL -- This message originates from outside our organization.
>>=20
>>=20
>> Hi Henning,
>>=20
>>> Am 22.04.2016 um 11:08 schrieb Henning Rogge :
>>>=20
>>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink=20
>>>  wrote:
>>>> Hi Thomas,
>>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=E2=80=
=9D language=20
>>>> in the first place is that we=E2=80=99ve been told that whenever one bi=
t in=20
>>>> the message (apart from its header) is changed, the entire thing has to=
 be regenerated.
>>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been misunde=
rstanding=20
>>>> each other for more than a year. :( Anyway, it seems like we=E2=80=99re=
=20
>>>> getting close now, so yay.
>>>=20
>>> "Modifying" the binary message instead of parsing and generating a=20
>>> new one will be difficult as soon someone writes an extension to=20
>>> AODVv2 that adds more TLVs to the message.
>>=20
>> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s wha=
t you explained to me when I got confused about the topic last spring=E2=80=A6=
 But=E2=80=93 even if a message contains TLVs that the AODVv2 implementation=
 handling it doesn=E2=80=99t understand, it will still be able to recognize t=
he Metric TLV, right? Isn=E2=80=99t that the nifty thing about RFC5444? So, w=
hile we really shouldn=E2=80=99t write =E2=80=9Cbefore calculating the ICV, s=
et the n-th 4 octets to 0=E2=80=9D, we might say =E2=80=9Cidentify the octet=
s that make up the metric value and set those to 0=E2=80=9D?
>>=20
>> Best regards,
>> Lotte
>>=20
>>> Henning Rogge
>>=20
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>> ********************************************************************
>> This email and any attachments are confidential to the intended=20
>> recipient and may also be privileged. If you are not the intended=20
>> 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=20
>> distribute its contents to any other person.
>> ********************************************************************
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From nobody Fri Apr 22 06:35: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 2D43B12D19C for ; Fri, 22 Apr 2016 06:35:16 -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 OghI3TtOZfVH for ; Fri, 22 Apr 2016 06:35:14 -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 761B512D6B6 for ; Fri, 22 Apr 2016 06:35:13 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,517,1454976000"; d="scan'208";a="63391085"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 22 Apr 2016 14:35:11 +0100
X-IronPort-AV: E=Sophos;i="5.24,517,1454976000"; d="scan'208";a="115136121"
Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 22 Apr 2016 14:35:12 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Fri, 22 Apr 2016 14:35:12 +0100
From: "Dearlove, Christopher (UK)" 
To: Thomas Heide Clausen 
Thread-Topic: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
Thread-Index: AQHRmuq4sr6y+au39kGswdQyX9PrDp+VpYGAgAAA9YCAAAWLgIAAETzQgAAplICAABFWYP//9QAAgAARAXA=
Date: Fri, 22 Apr 2016 13:35:10 +0000
Message-ID: 
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org>
In-Reply-To: <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 13:35:16 -0000

VGhlcmUncyByYXRoZXIgYSBjb250cmFkaWN0aW9uIGJldHdlZW4gdGhlIGNvbmNlcHRzIG9mIGEg
ZGVmaW5pdGlvbiBvZiBhIHByb3RvY29sLCBldmVuIEV4cGVyaW1lbnRhbCwgYW5kIGV4cGVyaW1l
bnRhbCBzcGFjZSwgd2hpY2ggdXN1YWxseSBhc3N1bWVzIHRoYXQgdGhlIHVzZXIgY2FuIGRvIHdo
YXQgaGUgb3Igc2hlIGxpa2VzIGluIGl0Lg0KDQpCdXQgY2hld2luZyB1cCBtZXNzYWdlcyB0eXBl
cyAoaG93IG1hbnksIDM/KSBvZiB3aGljaCB0aGVyZSBhcmUgcmVsYXRpdmVseSBmZXcgZm9yIGV4
cGVyaW1lbnRhbCBpcyBsb25nIHRlcm0gYSBwcm9ibGVtLCBhbHRob3VnaCBzaG9ydCB0ZXJtIG5v
dC4NCg0KVExWIHNwYWNlIGlzIGVhc2llciBpbiB0d28gcmVnYXJkcy4gSXQncyBiaWdnZXIgKHRo
b3VnaCB0aGUgcHJpbWUgcmVhbCBlc3RhdGUgb2YgdHlwZSBleHRlbnNpb24gemVybyBpc24ndCkg
YW5kIGNhbiBoYXZlIG1lc3NhZ2UgdHlwZSBzcGVjaWZpYyBUTFZzLg0KDQpTbyBUTFZTIGNhbiBh
Y3R1YWxseSBiZSBpbnZpc2libGUsIGlmIHRoYXQgb3B0aW9uIGlzIGNob3Nlbi4gRm9yIG1lc3Nh
Z2VzIHNvbWV0aGluZyBoYXMgdG8gZ2l2ZS4gTGVhc3QgYmFkIG9wdGlvbiBpcyBhZ2FpbiBvbmUg
b2YgdGhvc2Ugd2Ugc2hvdWxkIGRpc2N1c3MsIGJ1dCB0aW1lIC4uLg0KDQooVG8gYmUgcHJlY2lz
ZSwgbWVzc2FnZXMgdHlwZXMgZnJvbSAyMjQgYXJlIGRlZmluZWQgaW4gUkZDIDU0NDQgYXMgIiBF
eHBlcmltZW50YWwgVXNlIiwgb2Ygd2hpY2ggQkNQIDI2IHNheXMgIlNpbWlsYXIgdG8gcHJpdmF0
ZSBvciBsb2NhbCB1c2Ugb25seSwgd2l0aCB0aGUgIHB1cnBvc2UgYmVpbmcgdG8gZmFjaWxpdGF0
ZSBleHBlcmltZW50YXRpb24uIiBUaGUgYWx0ZXJuYXRpdmUgMC0yMjMgc3BhY2UgaXMgRXhwZXJ0
IFJldmlldy4gSUFOQSBzdGlsbCB0aGlua3MgdGhlIGV4cGVydHMgYXJlIEpvZSBNYWNrZXIgYW5k
IHRoZSByZWN1c2VkIFN0YW4gUmF0bGlmZi4gQnV0IHRoYXQncyBhIHNvbHVibGUgbml0LikNCg0K
LS0gDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFF
IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KDQpUOiDCoCs0NCAoMCkxMjQ1IDI0MjE5NCDCoHwgwqBFOiBjaHJpcy5kZWFybG92ZUBi
YWVzeXN0ZW1zLmNvbQ0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1z
Zm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00y
IDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haQ0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxp
Z2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUx
DQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3Vy
cmV5LCBHVTIgN1lQDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRob21h
cyBIZWlkZSBDbGF1c2VuIFttYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZ10gDQpTZW50OiAy
MiBBcHJpbCAyMDE2IDE0OjIxDQpUbzogRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNCkNjOiBM
b3R0ZSBTdGVlbmJyaW5rOyBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdA0KU3Vi
amVjdDogUmU6IFttYW5ldF0gT24gRm9yd2FyZGluZy1hbmQtcmVnZW5lcmF0aW9uICh3YXM6IFJl
OiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlj
a2V0IEl0ZW1zKQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9y
Z2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBp
bnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24g
YW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvbGxvdyB0aGUgJ1Jl
cG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlv
bnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQotLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCj4gT24gMjIg
YXZyLiAyMDE2LCBhdCAxNTowNSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgPGNocmlzLmRl
YXJsb3ZlQGJhZXN5c3RlbXMuY29tPiB3cm90ZToNCj4gDQo+IE9uY2UgeW91J3JlIGVudGlyZWx5
IGluIEFPRFYyJ3Mgb3duIHNwYWNlLCBhbmQgQU9EVnYyIGlzIGV4cGVyaW1lbnRhbCAod29ya2lu
ZyBhc3N1bXB0aW9uIGZvciB0aGlzIGRpc2N1c3Npb24pIHlvdSBoYXZlIG1vcmUgbGliZXJ0eS4N
Cj4gDQoNClllcC4gDQoNClRha2VuIHNvbWV3aGF0IGJ5IHN1cnByaXNlIGJvdGggYnkgdGhlIHN1
ZGRlbiAicnVzaCIgYW5kIHRoZSBleHBlcmltZW50YWwgbWF0dXJpdHkgbGV2ZWwsIEkgYW0gd29u
ZGVyaW5nIChhbmQgaGF2ZW4ndCB0aG91Z2h0IHRocm91Z2gpIGFib3V0IGV4cGVyaW1lbnRhbCBz
cGFjZSB2cyBub24tZXhwZXJpbWVudGFsIChmb3IgbWVzc2FnZSB0eXBlcywgYW5kIGNvbnNlcXVl
bnRseSBmb3IgbWVzc2FnZSB0eXBlIHNwZWNpZmljIFRMViB0eXBlcykuIA0KDQpJIHRoaW5rIHRo
YXQgaWYgdGhlIEFPRFZ2MiBleHBlcmltZW50IHNwZWNpZmllcyB0aGUgdXNlIG9mIE1lc3NhZ2Ug
dHlwZXMgZnJvbSB0aGUgRXhwZXJpbWVudGFsIG1lc3NhZ2UgdHlwZSBzcGFjZSB3aXRob3V0IG1h
a2luZyBhY3R1YWwgcmVnaXN0cmF0aW9ucyBpbiB0aGUgSUFOQSByZWdpc3RyeSwgQU5EIHRoZSB1
c2Ugb2YgdHlwZSBzcGVjaWZpYyBUTFYgdHlwZXMsIHRoaXMgYmVjb21lcyBhIG5vbi1pc3N1ZSBl
bnRpcmVseSAoYnkgZGVzaWduLCB0aGlzIGlzIHByZWNpc2VseSB3aGF0IHRoYXQgZXhwZXJpbWVu
dGFsIHNwYWNlIGlzIGZvcikNCg0KV2hlcmVhcywgYXMgeW91IHBvaW50IG91dCwgdGhlIGFsdGVy
bmF0aXZlIGlzIGEgImNhbiBvcGVuIC0gd29ybXMgZXZlcnl3aGVyZSIgc2l0dWF0aW9uIHRoYXQg
SSB0aGluayB0aW1lIGlzIHRvbyBzaG9ydCB0byBzb2x2ZT8NCg0KVGhvbWFzDQoNCg0KPiBUaGVu
IHlvdSBjb3VsZCB0cnkgc3BlY2lmeWluZyBpdC4gQnV0IHdpdGggYSB2ZXJ5IGdvb2QgY2hhbmNl
IG9mIHByb2R1Y2luZyBzb21ldGhpbmcgeW91IGxhdGVyIGRlY2lkZSB5b3Ugc2hvdWxkIGhhdmUg
ZG9uZSBkaWZmZXJlbnRseS4NCj4gDQo+IEkgaG9uZXN0bHkgZG9uJ3Qga25vdyB3aGljaCB3b3Vs
ZCBnbyBkb3duIGJldHRlciAob3IgbGVzcyBiYWRseSkgLSAiaGVyZSdzIGEgbWVjaGFuaXNtIHdl
IGhhdmVuJ3QgcmVhbGx5IHRob3VnaHQgdGhyb3VnaCBpbiBkZXRhaWwsIGJ1dCBhdCBsZWFzdCB3
ZSd2ZSBkZWZpbmVkIG9uZSIsIG9yICJ3ZSBrbm93IHRoZSBzb3J0IG9mIHRoaW5nIHdlIHdhbnQs
IGFuZCB3ZSdsbCBkZXNjcmliZSBpdCwgYnV0IHJhdGhlciB0aGFuIHByb2R1Y2Ugc29tZXRoaW5n
IG5vdCBxdWl0ZSByaWdodCwgd2UnbGwgbm90IGdvIGZ1cnRoZXIiLg0KPiANCj4gLS0gDQo+IENo
cmlzdG9waGVyIERlYXJsb3ZlDQo+IFNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCj4gQkFFIFN5
c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQo+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+IA0KPiBUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBi
YWVzeXN0ZW1zLmNvbQ0KPiANCj4gQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENo
ZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4
IENNMiA4SE4uDQo+IHd3dy5iYWVzeXN0ZW1zLmNvbS9haQ0KPiBCQUUgU3lzdGVtcyBBcHBsaWVk
IEludGVsbGlnZW5jZSBMaW1pdGVkDQo+IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5v
OiAwMTMzNzQ1MQ0KPiBSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1
aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCj4gRnJvbTogTG90dGUgU3RlZW5icmluayBbbWFpbHRvOmxvdHRlLnN0ZWVuYnJpbmtA
ZnUtYmVybGluLmRlXSANCj4gU2VudDogMjIgQXByaWwgMjAxNiAxMzo1OQ0KPiBUbzogTW9iaWxl
IEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3QNCj4gQ2M6IEhlbm5pbmcgUm9nZ2U7IERlYXJs
b3ZlLCBDaHJpc3RvcGhlciAoVUspDQo+IFN1YmplY3Q6IFJlOiBbbWFuZXRdIE9uIEZvcndhcmRp
bmctYW5kLXJlZ2VuZXJhdGlvbiAod2FzOiBSZTogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMg
cmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcykNCj4gDQo+IC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2Fn
ZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBh
biBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVybmV0Lg0KPiBDb25zaWRlciBjYXJl
ZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0
YWNobWVudHMgb3IgcmVwbHkuDQo+IEZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWls
cycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3Bp
Y2lvdXMgZW1haWwgbWVzc2FnZXMuDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBIZWxsbyBDaHJpc3RvcGhlciwNCj4gDQo+
PiBBbSAyMi4wNC4yMDE2IHVtIDExOjU3IHNjaHJpZWIgRGVhcmxvdmUsIENocmlzdG9waGVyIChV
SykgPGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPjoNCj4+IA0KPj4gSnVzdCBiZSBjYXJl
ZnVsIHRvIG5vdGUgdGhhdCB0aGlzIGNvbmNlcHQgaXMgYXMgY3VycmVudGx5IGJlaW5nIGRpc2N1
c3NlZCAoYSkgc3BlY2lmaWMgdG8gQU9EVnYyLCBhbmQgKGIpIG5vdCBhbiBhcHBsaWNhdGlvbiBv
ZiA3MTgyLCB3aGljaCBoYXMgbm8ga25vd2xlZGdlIG9mIHNwZWNpYWwgVExWcy4NCj4+IA0KPj4g
VGhpcyBpcyBzb21ldGhpbmcgd2UnZCB3YW50IHRvIGdldCByaWdodCwgYW5kIG5lZWQgdG8gZ2V0
IHJpZ2h0IGlmIGluIGFueSBzcGFjZSBub3Qgc3BlY2lmaWMgdG8gQURPRFZ2MiwgYmVjYXVzZSBn
ZXR0aW5nIGl0IHdyb25nIHByb2R1Y2VzIGZ1dHVyZSBwcm9ibGVtcy4NCj4gDQo+IE1ha2VzIHNl
bnNlLg0KPiANCj4+IEkgY2FuIHNlZSBzb21lIHBvc3NpYmxlIGFwcHJvYWNoZXMsIG5vbmUgaXMg
aWRlYWwgYW5kIHdlJ3JlIHJhdGhlciBvdXQgDQo+PiBvZiB0aW1lIHRvIHNwZWNpZnkuIEJ1dCB0
aGlzIGlzIGV4cGVyaW1lbnRhbCwgc28gSSB0aGluayB3ZSBtaWdodCBiZSANCj4+IGFibGUgdG8g
aW5kaWNhdGUgdGhlIHNoYXBlIG9mIHRoZSBzb2x1dGlvbiB3aXRob3V0IHNwZWNpZnlpbmcgaXQs
IA0KPj4gd2hpY2ggd291bGQgYmUgYSBkaWZmZXJlbnQgUkZDLCB1bmRlciBhIGJpdCBsZXNzIHRp
bWUgcHJlc3N1cmUuIA0KPj4gKEV4dGVuc2lvbnMgdG8gZXhpc3RpbmcgcHJvdG9jb2xzIGxpa2Ug
NzE4MiB3b3VsZCBuYXR1cmFsbHkgYmUgaW4gDQo+PiBzY29wZSByZWNoYXJ0ZXJlZCBJIHRoaW5r
LikNCj4+IA0KPj4gVG8gaW5kaWNhdGUgdGhlIHJhbmdlIHRoYXQncyBvcGVuLCBoZXJlIGFyZSB0
d28gcG9zc2libGUgaWRlYXMsIG9uZSBvZiB3aGljaCBoYXMgYW4gaW1wYWN0IG5vdywgc28gbmVl
ZHMgdG8gYmUgYWdyZWVkLiBOb3RlIHRoYXQgSSdtIG5vdCBzdWdnZXN0aW5nIChpbiBmYWN0IHF1
aXRlIHRoZSBvcHBvc2l0ZSkgZGVmaW5pbmcgYW4gZXh0ZW5zaW9uIHRvIDcxODIgaGVyZSwgcmF0
aGVyIGVuYWJsaW5nIHN1Y2ggYW4gZXh0ZW5zaW9uLCBpZiB3cml0dGVuLCB0byAiZG8gdGhlIHJp
Z2h0IHRoaW5nIi4NCj4+IC0gV2UgaGF2ZSBhbiBleHRlbnNpb24gdG8gNzE4MiB0aGF0IHNheXMg
Inplcm8gb3V0IGFsbCB2YWx1ZSBvY3RldHMgaW4gcHJvdG9jb2wgc3BlY2lmaWMgVExWcy4gVGhh
dCByZXF1aXJlcyBub3cgcHV0dGluZyB0aGUgQU9EVnYyIG1ldHJpYyBUTFYgaW4gdGhhdCBzcGFj
ZS4NCj4gDQo+IEp1c3QgdG8gbWFrZSBzdXJlIHRoYXQgSSB1bmRlcnN0b29kIHlvdSBjb3JyZWN0
bHnigJMg4oCcdGhhdCBzcGFjZeKAnSBtZWFuaW5nIG1ha2luZyB0aGUgQU9EVnYyIG1ldHJpYyBU
TFYgcHJvdG9jb2wgc3BlY2lmaWM/IChCeSDigJx0aGUgYW9kdnYyIG1ldHJpYyB0bHbigJ0gSeKA
mW0gcmVmZXJyaW5nIHRvIHRoZSBnZW5lcmljIFRMViB3ZeKAmXZlIGJlZW4gdGFsa2luZyBhYm91
dCBvbiB0aGlzIGxpc3QgZWFybGllciB0aGlzIHdlZWspLg0KPiANCj4+IC0gV2UgaGF2ZSBhbiBl
eHRlbnNpb24gdG8gNzE4MiB0aGF0IGFkZHMgZXh0cmEgbWF0ZXJpYWwgdG8gdGhlIHZhbHVlIGZp
ZWxkIHRoYXQgaW5kaWNhdGVzIChUQkQgaG93LCBieSBwb3NpdGlvbiB3aXRoIHNhbml0eSBjaGVj
ayB0aGF0IHRoaXMgaXMgVExWIHZhbHVlIHBlcmhhcHM/KSB3aGljaCBvY3RldHMgYXJlIHRvIGJl
IHplcm9lZCBvdXQgYmVmb3JlIHRoZSBJQ1YgaXMgY2FsY3VsYXRlZC4NCj4gDQo+IFRoZSB3YXkg
SSB1bmRlcnN0YW5kIHRoYXQgYXBwcm9hY2gsIGl0IHdvdWxkbuKAmXQgd2FycmFudCBhbnkgYWN0
aW9uIGZyb20gQU9EVnYyIGJlc2lkZXMgc2F5aW5nIOKAnGlmIHlvdSBjYWxjdWxhdGUgdGhlIElD
Viwgc2V0IHRoZSBNZXRyaWMgdmFsdWUgdG8gemVyb+KAnSAobGVhdmluZyB0aGUgbml0dHkgZ3Jp
dHR5IG9mIGhvdyB0aGlzIHdvdWxkIGJlIGRvbmUgaW4gZGV0YWlsIHRvIGZ1dHVyZSB3b3JrKeKA
piBJcyB0aGF0IGNvcnJlY3Q/DQo+IA0KPj4gDQo+PiBXZSBkbyBub3QgaGF2ZSB0aGUgdGltZSB0
byBzcGVjaWZ5IHRoaXMgaW4gYW4gYWNjZXB0YWJsZSBtYW5uZXIgd2l0aGluIHR3byB3ZWVrcyB0
aG91Z2guIEJ1dCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGNvdWxkIHNheSBz
b21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mICJ0aGlzIGVuYWJsZXMgdGhlIHVzZSBvZiBhbiBJ
Q1YgZGVmaW5lZCB0byB6ZXJvIG91dCB0aGVzZSBvY3RldHPigJwuDQo+IA0KPiBPa2F5LiA6KQ0K
PiANCj4gQmVzdCByZWdhcmRzLA0KPiBMb3R0ZQ0KPiANCj4+IA0KPj4gLS0NCj4+IENocmlzdG9w
aGVyIERlYXJsb3ZlDQo+PiBTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQo+PiBCQUUgU3lzdGVt
cyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMgDQo+PiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
PiBfX19fDQo+PiANCj4+IFQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJs
b3ZlQGJhZXN5c3RlbXMuY29tDQo+PiANCj4+IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdl
bmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3Jk
LCBFc3NleCBDTTIgOEhOLg0KPj4gd3d3LmJhZXN5c3RlbXMuY29tL2FpDQo+PiBCQUUgU3lzdGVt
cyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkIFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdh
bGVzIA0KPj4gTm86IDAxMzM3NDUxIFJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2gg
UGFyaywgR3VpbGRmb3JkLCANCj4+IFN1cnJleSwgR1UyIDdZUA0KPj4gDQo+PiAtLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGll
dGYub3JnXSBPbiBCZWhhbGYgT2YgTG90dGUgDQo+PiBTdGVlbmJyaW5rDQo+PiBTZW50OiAyMiBB
cHJpbCAyMDE2IDEwOjI4DQo+PiBUbzogSGVubmluZyBSb2dnZQ0KPj4gQ2M6IE1vYmlsZSBBZCBI
b2MgTmV0d29ya3MgbWFpbGluZyBsaXN0DQo+PiBTdWJqZWN0OiBSZTogW21hbmV0XSBPbiBGb3J3
YXJkaW5nLWFuZC1yZWdlbmVyYXRpb24gKHdhczogUmU6IA0KPj4gZHJhZnQtaWV0Zi1tYW5ldC1h
b2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcykNCj4+IA0KPj4g
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g
VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVp
dGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuDQo+PiBD
b25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywg
b3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQo+PiBGb2xsb3cgdGhlICdSZXBvcnQgU3Vz
cGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJl
cG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IA0KPj4gKioqIFdBUk5J
TkcgKioqDQo+PiBFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9t
IG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbi4NCj4+IA0KPj4gDQo+PiBIaSBIZW5uaW5nLA0KPj4g
DQo+Pj4gQW0gMjIuMDQuMjAxNiB1bSAxMTowOCBzY2hyaWViIEhlbm5pbmcgUm9nZ2UgPGhyb2dn
ZUBnbWFpbC5jb20+Og0KPj4+IA0KPj4+IE9uIEZyaSwgQXByIDIyLCAyMDE2IGF0IDExOjA1IEFN
LCBMb3R0ZSBTdGVlbmJyaW5rIA0KPj4+IDxsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZT4g
d3JvdGU6DQo+Pj4+IEhpIFRob21hcywNCj4+Pj4gQ2FuIGl0PyEgSWlyYywgdGhlIHJlYXNvbiB3
aHkgd2UgYWRvcHRlZCB0aGUg4oCccmVnZW5lcmF0aW9u4oCdIGxhbmd1YWdlIA0KPj4+PiBpbiB0
aGUgZmlyc3QgcGxhY2UgaXMgdGhhdCB3ZeKAmXZlIGJlZW4gdG9sZCB0aGF0IHdoZW5ldmVyIG9u
ZSBiaXQgaW4gDQo+Pj4+IHRoZSBtZXNzYWdlIChhcGFydCBmcm9tIGl0cyBoZWFkZXIpIGlzIGNo
YW5nZWQsIHRoZSBlbnRpcmUgdGhpbmcgaGFzIHRvIGJlIHJlZ2VuZXJhdGVkLg0KPj4+PiBJ4oCZ
bSBzdGFydGluZyB0byBnZXQgdGhlIGZlZWxpbmcgd2XigJl2ZSBqdXN0IGJlZW4gbWlzdW5kZXJz
dGFuZGluZyANCj4+Pj4gZWFjaCBvdGhlciBmb3IgbW9yZSB0aGFuIGEgeWVhci4gOiggQW55d2F5
LCBpdCBzZWVtcyBsaWtlIHdl4oCZcmUgDQo+Pj4+IGdldHRpbmcgY2xvc2Ugbm93LCBzbyB5YXku
DQo+Pj4gDQo+Pj4gIk1vZGlmeWluZyIgdGhlIGJpbmFyeSBtZXNzYWdlIGluc3RlYWQgb2YgcGFy
c2luZyBhbmQgZ2VuZXJhdGluZyBhIA0KPj4+IG5ldyBvbmUgd2lsbCBiZSBkaWZmaWN1bHQgYXMg
c29vbiBzb21lb25lIHdyaXRlcyBhbiBleHRlbnNpb24gdG8gDQo+Pj4gQU9EVnYyIHRoYXQgYWRk
cyBtb3JlIFRMVnMgdG8gdGhlIG1lc3NhZ2UuDQo+PiANCj4+IETigJlvaCwgcmlnaHQuIFllYWgs
IGlmIEkgcmVtZW1iZXIgaXQgY29ycmVjdGx5LCB0aGF04oCZcyB3aGF0IHlvdSBleHBsYWluZWQg
dG8gbWUgd2hlbiBJIGdvdCBjb25mdXNlZCBhYm91dCB0aGUgdG9waWMgbGFzdCBzcHJpbmfigKYg
QnV04oCTIGV2ZW4gaWYgYSBtZXNzYWdlIGNvbnRhaW5zIFRMVnMgdGhhdCB0aGUgQU9EVnYyIGlt
cGxlbWVudGF0aW9uIGhhbmRsaW5nIGl0IGRvZXNu4oCZdCB1bmRlcnN0YW5kLCBpdCB3aWxsIHN0
aWxsIGJlIGFibGUgdG8gcmVjb2duaXplIHRoZSBNZXRyaWMgVExWLCByaWdodD8gSXNu4oCZdCB0
aGF0IHRoZSBuaWZ0eSB0aGluZyBhYm91dCBSRkM1NDQ0PyBTbywgd2hpbGUgd2UgcmVhbGx5IHNo
b3VsZG7igJl0IHdyaXRlIOKAnGJlZm9yZSBjYWxjdWxhdGluZyB0aGUgSUNWLCBzZXQgdGhlIG4t
dGggNCBvY3RldHMgdG8gMOKAnSwgd2UgbWlnaHQgc2F5IOKAnGlkZW50aWZ5IHRoZSBvY3RldHMg
dGhhdCBtYWtlIHVwIHRoZSBtZXRyaWMgdmFsdWUgYW5kIHNldCB0aG9zZSB0byAw4oCdPw0KPj4g
DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBMb3R0ZQ0KPj4gDQo+Pj4gSGVubmluZyBSb2dnZQ0KPj4g
DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g
bWFuZXQgbWFpbGluZyBsaXN0DQo+PiBtYW5ldEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KPj4gKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+IFRoaXMgZW1h
aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZCAN
Cj4+IHJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3Qg
dGhlIGludGVuZGVkIA0KPj4gcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5
c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuDQo+PiBZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9y
IHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yIA0KPj4gZGlzdHJpYnV0ZSBp
dHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4NCj4+ICoqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IA0KPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtYW5ldCBt
YWlsaW5nIGxpc3QNCj4gbWFuZXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9tYW5ldA0KDQo=


From nobody Fri Apr 22 07:35: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 5AB2412DBCD for ; Fri, 22 Apr 2016 07:35:13 -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 OqASxSbEzgDW for ; Fri, 22 Apr 2016 07:35:10 -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 6A04A12D8DB for ; Fri, 22 Apr 2016 07:35:10 -0700 (PDT)
Received: by mail-vk0-x22d.google.com with SMTP id n62so138465093vkb.0 for ; Fri, 22 Apr 2016 07:35: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=a+OMe1MAx0ljOx6aT77/rM1hN9dIk/o8bTHq21YuhDI=; b=vVOZxBhYTAX/1dP/+6BAqoCchv/1JLhNsQZvpCMclI/apk50jLLt4tjkqVa+Znf9bq D15rHiA7WsYoFAvy4clqB4opFLSKLVO+eu7lWUpAkxmjYl4yUqBE6Y8ztT4KSVEY1Gxv Cey6YvIadbZqfU8ad0dlWIt+BlTEwEDtIV1iqjoaqk6tKIrQQHlLEyVnyKmPn6ba46H+ St7Xad9R5qbgFydwOxeacicBgmOBtARlqMwCLcsaTFQAnagREiBhjy39GMyDxwU1hKZw p4sreKCoHBzp8TG0Fn63eoFIJmNixkmqw1EjUFBECqCLJ4QdoLsN/ghMWMe35VotY/lF JiAw==
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=a+OMe1MAx0ljOx6aT77/rM1hN9dIk/o8bTHq21YuhDI=; b=X8EP5upDBO0VrcyzG1bxozNKa3kGsxDujOxppfVi5XCcM4qRLX22WpWrCZmLUlP4+U yiuNDoatIJS60Cv9KLiI727UGep/xKuBJ88pTK/W/iWRcnw2dVrxQXrLqz34591OdVwe WKjlhg/E4qKuQucaed/UvOaskQPVjI2UwdxZZ1+A0u2E8123uwGCF+WT5nrrLjgfPYYQ Zr3cIs019/v4Es5df78pN3uwNAiXaYin322OQzqqko8U6yEK/Q0TiVpXXs18frv2gzG/ h/O/ycD7Rt6cLAoSAEZgDYADbnnDk3Arn/V1iY5w2b+KDC03SZiUQnVsFUxIpNi2Ir6+ HYAw==
X-Gm-Message-State: AOPr4FXj7bz4HHXSH7ajZKwG92qZK6Ro0IyQ6EiNUkUPORvRqjKLj/KHvR4schFbiWH4nWllsOG4/TBA4hrWKQ==
MIME-Version: 1.0
X-Received: by 10.176.1.108 with SMTP id 99mr3627056uak.54.1461335709346; Fri, 22 Apr 2016 07:35:09 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Fri, 22 Apr 2016 07:35:09 -0700 (PDT)
In-Reply-To: 
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org> 
Date: Fri, 22 Apr 2016 10:35:09 -0400
Message-ID: 
From: Justin Dean 
To: "Dearlove, Christopher (UK)" 
Content-Type: multipart/alternative; boundary=001a113d0cd4da7286053113bb97
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 14:35:13 -0000

--001a113d0cd4da7286053113bb97
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Speaking as participant.

I kind of like the idea of using the experimental message type space.  We
only have a limited amount of these message types.  The TLV assignments
could just use the message type specific space and there isn't an issue
there.  IANA wouldn't assign a number but I don't see why the document
couldn't specify the experimental numbers it was going to use so other
future near term experiential protocols could do the same and generally
avoid conflict.  If the experiment is successful IANA assignments could be
made.  Functionally no real difference with protections vs long term usage
of limited space.

Justin

On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) <
chris.dearlove@baesystems.com> wrote:

> There's rather a contradiction between the concepts of a definition of a
> protocol, even Experimental, and experimental space, which usually assume=
s
> that the user can do what he or she likes in it.
>
> But chewing up messages types (how many, 3?) of which there are relativel=
y
> few for experimental is long term a problem, although short term not.
>
> TLV space is easier in two regards. It's bigger (though the prime real
> estate of type extension zero isn't) and can have message type specific
> TLVs.
>
> So TLVS can actually be invisible, if that option is chosen. For messages
> something has to give. Least bad option is again one of those we should
> discuss, but time ...
>
> (To be precise, messages types from 224 are defined in RFC 5444 as "
> Experimental Use", of which BCP 26 says "Similar to private or local use
> only, with the  purpose being to facilitate experimentation." The
> alternative 0-223 space is Expert Review. IANA still thinks the experts a=
re
> Joe Macker and the recused Stan Ratliff. But that's a soluble nit.)
>
> --
> 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
>
>
> -----Original Message-----
> From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org]
> Sent: 22 April 2016 14:21
> To: Dearlove, Christopher (UK)
> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
> ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner
> or from the internet.
> Consider carefully whether you should click on any links, open any
> attachments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters for instructions
> on reporting suspicious email messages.
> --------------------------------------------------------
>
>
> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
> >
> > Once you're entirely in AODV2's own space, and AODVv2 is experimental
> (working assumption for this discussion) you have more liberty.
> >
>
> Yep.
>
> Taken somewhat by surprise both by the sudden "rush" and the experimental
> maturity level, I am wondering (and haven't thought through) about
> experimental space vs non-experimental (for message types, and consequent=
ly
> for message type specific TLV types).
>
> I think that if the AODVv2 experiment specifies the use of Message types
> from the Experimental message type space without making actual
> registrations in the IANA registry, AND the use of type specific TLV type=
s,
> this becomes a non-issue entirely (by design, this is precisely what that
> experimental space is for)
>
> Whereas, as you point out, the alternative is a "can open - worms
> everywhere" situation that I think time is too short to solve?
>
> Thomas
>
>
> > Then you could try specifying it. But with a very good chance of
> producing something you later decide you should have done differently.
> >
> > I honestly don't know which would go down better (or less badly) -
> "here's a mechanism we haven't really thought through in detail, but at
> least we've defined one", or "we know the sort of thing we want, and we'l=
l
> describe it, but rather than produce something not quite right, we'll not
> go further".
> >
> > --
> > 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
> >
> >
> > -----Original Message-----
> > From: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]
> > Sent: 22 April 2016 13:59
> > To: Mobile Ad Hoc Networks mailing list
> > Cc: Henning Rogge; Dearlove, Christopher (UK)
> > Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
> >
> > ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner
> or from the internet.
> > Consider carefully whether you should click on any links, open any
> attachments or reply.
> > Follow the 'Report Suspicious Emails' link on IT matters for
> instructions on reporting suspicious email messages.
> > --------------------------------------------------------
> >
> > Hello Christopher,
> >
> >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com>:
> >>
> >> Just be careful to note that this concept is as currently being
> discussed (a) specific to AODVv2, and (b) not an application of 7182, whi=
ch
> has no knowledge of special TLVs.
> >>
> >> This is something we'd want to get right, and need to get right if in
> any space not specific to ADODVv2, because getting it wrong produces futu=
re
> problems.
> >
> > Makes sense.
> >
> >> I can see some possible approaches, none is ideal and we're rather out
> >> of time to specify. But this is experimental, so I think we might be
> >> able to indicate the shape of the solution without specifying it,
> >> which would be a different RFC, under a bit less time pressure.
> >> (Extensions to existing protocols like 7182 would naturally be in
> >> scope rechartered I think.)
> >>
> >> To indicate the range that's open, here are two possible ideas, one of
> which has an impact now, so needs to be agreed. Note that I'm not
> suggesting (in fact quite the opposite) defining an extension to 7182 her=
e,
> rather enabling such an extension, if written, to "do the right thing".
> >> - We have an extension to 7182 that says "zero out all value octets in
> protocol specific TLVs. That requires now putting the AODVv2 metric TLV i=
n
> that space.
> >
> > Just to make sure that I understood you correctly=E2=80=93 =E2=80=9Ctha=
t space=E2=80=9D meaning
> making the AODVv2 metric TLV protocol specific? (By =E2=80=9Cthe aodvv2 m=
etric tlv=E2=80=9D
> I=E2=80=99m referring to the generic TLV we=E2=80=99ve been talking about=
 on this list
> earlier this week).
> >
> >> - We have an extension to 7182 that adds extra material to the value
> field that indicates (TBD how, by position with sanity check that this is
> TLV value perhaps?) which octets are to be zeroed out before the ICV is
> calculated.
> >
> > The way I understand that approach, it wouldn=E2=80=99t warrant any act=
ion from
> AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set the Metric v=
alue to
> zero=E2=80=9D (leaving the nitty gritty of how this would be done in deta=
il to
> future work)=E2=80=A6 Is that correct?
> >
> >>
> >> We do not have the time to specify this in an acceptable manner within
> two weeks though. But the security consideration section could say
> something along the lines of "this enables the use of an ICV defined to
> zero out these octets=E2=80=9C.
> >
> > Okay. :)
> >
> > Best regards,
> > Lotte
> >
> >>
> >> --
> >> 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
> >>
> >> -----Original Message-----
> >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte
> >> Steenbrink
> >> Sent: 22 April 2016 10:28
> >> To: Henning Rogge
> >> Cc: Mobile Ad Hoc Networks mailing list
> >> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
> >> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
> >>
> >> ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner
> or from the internet.
> >> Consider carefully whether you should click on any links, open any
> attachments or reply.
> >> Follow the 'Report Suspicious Emails' link on IT matters for
> instructions on reporting suspicious email messages.
> >> --------------------------------------------------------
> >>
> >> *** WARNING ***
> >> EXTERNAL EMAIL -- This message originates from outside our organizatio=
n.
> >>
> >>
> >> Hi Henning,
> >>
> >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge :
> >>>
> >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
> >>>  wrote:
> >>>> Hi Thomas,
> >>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=
=E2=80=9D language
> >>>> in the first place is that we=E2=80=99ve been told that whenever one=
 bit in
> >>>> the message (apart from its header) is changed, the entire thing has
> to be regenerated.
> >>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been misu=
nderstanding
> >>>> each other for more than a year. :( Anyway, it seems like we=E2=80=
=99re
> >>>> getting close now, so yay.
> >>>
> >>> "Modifying" the binary message instead of parsing and generating a
> >>> new one will be difficult as soon someone writes an extension to
> >>> AODVv2 that adds more TLVs to the message.
> >>
> >> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s =
what you
> explained to me when I got confused about the topic last spring=E2=80=A6 =
But=E2=80=93 even
> if a message contains TLVs that the AODVv2 implementation handling it
> doesn=E2=80=99t understand, it will still be able to recognize the Metric=
 TLV,
> right? Isn=E2=80=99t that the nifty thing about RFC5444? So, while we rea=
lly
> shouldn=E2=80=99t write =E2=80=9Cbefore calculating the ICV, set the n-th=
 4 octets to 0=E2=80=9D,
> we might say =E2=80=9Cidentify the octets that make up the metric value a=
nd set
> those to 0=E2=80=9D?
> >>
> >> Best regards,
> >> Lotte
> >>
> >>> Henning Rogge
> >>
> >> _______________________________________________
> >> 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
>

--001a113d0cd4da7286053113bb97
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Speaking as participant.

I kind of like the idea of=
 using the experimental message type space.=C2=A0 We only have a limited am=
ount of these message types.=C2=A0 The TLV assignments could just use the m=
essage type specific space and there isn't an issue there.=C2=A0 IANA w=
ouldn't assign a number but I don't see why the document couldn'=
;t specify the experimental numbers it was going to use so other future nea=
r term experiential protocols could do the same and generally avoid conflic=
t.=C2=A0 If the experiment is successful IANA assignments could be made.=C2=
=A0 Functionally no real difference with protections vs long term usage of =
limited space.

Justin

=

On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Chris=
topher (UK) <chris.dearlove@baesystems.com> wrot=
e:
There's rather a contradiction bet=
ween the concepts of a definition of a protocol, even Experimental, and exp=
erimental space, which usually assumes that the user can do what he or she =
likes in it.



But chewing up messages types (how many, 3?) of which there are relatively =
few for experimental is long term a problem, although short term not.



TLV space is easier in two regards. It's bigger (though the prime real =
estate of type extension zero isn't) and can have message type specific=
 TLVs.



So TLVS can actually be invisible, if that option is chosen. For messages s=
omething has to give. Least bad option is again one of those we should disc=
uss, but time ...



(To be precise, messages types from 224 are defined in RFC 5444 as " E=
xperimental Use", of which BCP 26 says "Similar to private or loc=
al use only, with the=C2=A0 purpose being to facilitate experimentation.&qu=
ot; The alternative 0-223 space is Expert Review. IANA still thinks the exp=
erts are Joe Macker and the recused Stan Ratliff. But that's a soluble =
nit.)



--

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





-----Original Message-----

From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org]

Sent: 22 April 2016 14:21

To: Dearlove, Christopher (UK)


Cc: Lotte Steenbrink; Mobile=
 Ad Hoc Networks mailing list

Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-ma=
net-aodvv2-13 review - a couple of big ticket Items)



----------------------! 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 instru=
ctions on reporting suspicious email messages.

--------------------------------------------------------





> On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> =
wrote:

>

> Once you're entirely in AODV2's own space, and AODVv2 is exper=
imental (working assumption for this discussion) you have more liberty.

>



Yep.



Taken somewhat by surprise both by the sudden "rush" and the expe=
rimental maturity level, I am wondering (and haven't thought through) a=
bout experimental space vs non-experimental (for message types, and consequ=
ently for message type specific TLV types).



I think that if the AODVv2 experiment specifies the use of Message types fr=
om the Experimental message type space without making actual registrations =
in the IANA registry, AND the use of type specific TLV types, this becomes =
a non-issue entirely (by design, this is precisely what that experimental s=
pace is for)



Whereas, as you point out, the alternative is a "can open - worms ever=
ywhere" situation that I think time is too short to solve?



Thomas





> Then you could try specifying it. But with a very good chance of produ=
cing something you later decide you should have done differently.

>

> I honestly don't know which would go down better (or less badly) -=
 "here's a mechanism we haven't really thought through in deta=
il, but at least we've defined one", or "we know the sort of =
thing we want, and we'll describe it, but rather than produce something=
 not quite right, we'll not go further".

>

> --

> Christopher Dearlove

> Senior Principal Engineer

> BAE Systems Applied Intelligence Laboratories

> ______________________________________________________________________=
____

>

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

>

> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Ba=
ddow, 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: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]

> Sent: 22 April 2016 13:59

> To: Mobile Ad Hoc Networks mailing list

> Cc: Henning Rogge; Dearlove, Christopher (UK)

> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ie=
tf-manet-aodvv2-13 review - a couple of big ticket Items)

>

> ----------------------! WARNING ! ---------------------- This message =
originates from outside our organisation, either from an external partner o=
r from the internet.

> Consider carefully whether you should click on any links, open any att=
achments or reply.

> Follow the 'Report Suspicious Emails' link on IT matters for i=
nstructions on reporting suspicious email messages.

> --------------------------------------------------------

>

> Hello Christopher,

>

>> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <chris.dearlove@baesystems.com<=
/a>>:

>>

>> Just be careful to note that this concept is as currently being di=
scussed (a) specific to AODVv2, and (b) not an application of 7182, which h=
as no knowledge of special TLVs.

>>

>> This is something we'd want to get right, and need to get righ=
t if in any space not specific to ADODVv2, because getting it wrong produce=
s future problems.

>

> Makes sense.

>

>> I can see some possible approaches, none is ideal and we're ra=
ther out

>> of time to specify. But this is experimental, so I think we might =
be

>> able to indicate the shape of the solution without specifying it,<=
br>
>> which would be a different RFC, under a bit less time pressure.
>> (Extensions to existing protocols like 7182 would naturally be in<=
br>
>> scope rechartered I think.)

>>

>> To indicate the range that's open, here are two possible ideas=
, one of which has an impact now, so needs to be agreed. Note that I'm =
not suggesting (in fact quite the opposite) defining an extension to 7182 h=
ere, rather enabling such an extension, if written, to "do the right t=
hing".

>> - We have an extension to 7182 that says "zero out all value =
octets in protocol specific TLVs. That requires now putting the AODVv2 metr=
ic TLV in that space.

>

> Just to make sure that I understood you correctly=E2=80=93 =E2=80=9Cth=
at space=E2=80=9D meaning making the AODVv2 metric TLV protocol specific? (=
By =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m referring to the gen=
eric TLV we=E2=80=99ve been talking about on this list earlier this week).<=
br>
>

>> - We have an extension to 7182 that adds extra material to the val=
ue field that indicates (TBD how, by position with sanity check that this i=
s TLV value perhaps?) which octets are to be zeroed out before the ICV is c=
alculated.

>

> The way I understand that approach, it wouldn=E2=80=99t warrant any ac=
tion from AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set the =
Metric value to zero=E2=80=9D (leaving the nitty gritty of how this would b=
e done in detail to future work)=E2=80=A6 Is that correct?

>

>>

>> We do not have the time to specify this in an acceptable manner wi=
thin two weeks though. But the security consideration section could say som=
ething along the lines of "this enables the use of an ICV defined to z=
ero out these octets=E2=80=9C.

>

> Okay. :)

>

> Best regards,

> Lotte

>

>>

>> --

>> Christopher Dearlove

>> Senior Principal Engineer

>> BAE Systems Applied Intelligence Laboratories

>> __________________________________________________________________=
____

>> ____

>>

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

>>

>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Grea=
t Baddow, Chelmsford, Essex CM2 8HN.

>> www.baesystems.com/ai

>> BAE Systems Applied Intelligence Limited Registered in England &am=
p; Wales

>> No: 01337451 Registered Office: Surrey Research Park, Guildford,
>> Surrey, GU2 7YP

>>

>> -----Original Message-----

>> From: manet [mailto:mane=
t-bounces@ietf.org] On Behalf Of Lotte

>> Steenbrink

>> Sent: 22 April 2016 10:28

>> To: Henning Rogge

>> Cc: Mobile Ad Hoc Networks mailing list

>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:

>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)<=
br>
>>

>> ----------------------! WARNING ! ---------------------- This mess=
age originates from outside our organisation, either from an external partn=
er or from the internet.

>> Consider carefully whether you should click on any links, open any=
 attachments or reply.

>> Follow the 'Report Suspicious Emails' link on IT matters f=
or instructions on reporting suspicious email messages.

>> --------------------------------------------------------

>>

>> *** WARNING ***

>> EXTERNAL EMAIL -- This message originates from outside our organiz=
ation.

>>

>>

>> Hi Henning,

>>

>>> Am 22.04.2016 um 11:08 schrieb Henning Rogge <hrogge@gmail.com>:

>>>

>>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink

>>> <lotte.ste=
enbrink@fu-berlin.de> wrote:

>>>> Hi Thomas,

>>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Crege=
neration=E2=80=9D language

>>>> in the first place is that we=E2=80=99ve been told that wh=
enever one bit in

>>>> the message (apart from its header) is changed, the entire=
 thing has to be regenerated.

>>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just=
 been misunderstanding

>>>> each other for more than a year. :( Anyway, it seems like =
we=E2=80=99re

>>>> getting close now, so yay.

>>>

>>> "Modifying" the binary message instead of parsing an=
d generating a

>>> new one will be difficult as soon someone writes an extension =
to

>>> AODVv2 that adds more TLVs to the message.

>>

>> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=
=99s what you explained to me when I got confused about the topic last spri=
ng=E2=80=A6 But=E2=80=93 even if a message contains TLVs that the AODVv2 im=
plementation handling it doesn=E2=80=99t understand, it will still be able =
to recognize the Metric TLV, right? Isn=E2=80=99t that the nifty thing abou=
t RFC5444? So, while we really shouldn=E2=80=99t write =E2=80=9Cbefore calc=
ulating the ICV, set the n-th 4 octets to 0=E2=80=9D, we might say =E2=80=
=9Cidentify the octets that make up the metric value and set those to 0=E2=
=80=9D?

>>

>> Best regards,

>> Lotte

>>

>>> Henning Rogge

>>

>> _______________________________________________

>> manet mailing list

>> manet@ietf.org

>> https://www.ietf.org/mailman/listinfo/manet<=
br>
>> ******************************************************************=
**

>> This email and any attachments are confidential to the intended
>> recipient and may also be privileged. If you are not the intended<=
br>
>> 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





--001a113d0cd4da7286053113bb97--


From nobody Fri Apr 22 07:40: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 84B6B12E56F for ; Fri, 22 Apr 2016 07:40:12 -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 2dKjkiD_BUw6 for ; Fri, 22 Apr 2016 07:40:09 -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 2478912DAB1 for ; Fri, 22 Apr 2016 07:40:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D71673402D5; Fri, 22 Apr 2016 07:40:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461336008; bh=TC5uSdoIMFsswqsMrol8UvJIcJzjarq4BR83dyPMfhY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=DDU0wcBnFW8FQ2mbjsX3ZyhYMqZnmVC+qVtUtEs5XIqGmfGfvhutImH4QG/fkBgyt qmhPaQmRmDnc3/EtDT3nmjacoyQS6ki7Y2sq2e4aSGAPpjUQDDPatOQzKt9PLeqHYx FL9xMf92XHq3jGr9QKecA/UPQbVcQS+kSL41Lq8g=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [129.104.72.127] (unknown [129.104.72.127]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id DBA7C340254; Fri, 22 Apr 2016 07:40:07 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-6DC4ACD0-186A-4ABD-BD3B-2911F1ADC64D
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPhone Mail (13E238)
In-Reply-To: 
Date: Fri, 22 Apr 2016 16:40:06 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <2D795651-3B12-4956-AFE8-AE2FB7B403BD@thomasclausen.org>
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org>  
To: Justin Dean 
Archived-At: 
Cc: "Dearlove, Christopher \(UK\)" , Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 14:40:12 -0000

--Apple-Mail-6DC4ACD0-186A-4ABD-BD3B-2911F1ADC64D
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

That was my line of thinking, too, as it would allow enormous flexibility in=
 the experiments possible - which definitely is required.=20

Thomas



> On 22 avr. 2016, at 16:35, Justin Dean  wrote:
>=20
> Speaking as participant.
>=20
> I kind of like the idea of using the experimental message type space.  We o=
nly have a limited amount of these message types.  The TLV assignments could=
 just use the message type specific space and there isn't an issue there.  I=
ANA wouldn't assign a number but I don't see why the document couldn't speci=
fy the experimental numbers it was going to use so other future near term ex=
periential protocols could do the same and generally avoid conflict.  If the=
 experiment is successful IANA assignments could be made.  Functionally no r=
eal difference with protections vs long term usage of limited space.
>=20
> Justin
>=20
>> On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK)  wrote:
>> There's rather a contradiction between the concepts of a definition of a p=
rotocol, even Experimental, and experimental space, which usually assumes th=
at the user can do what he or she likes in it.
>>=20
>> But chewing up messages types (how many, 3?) of which there are relativel=
y few for experimental is long term a problem, although short term not.
>>=20
>> TLV space is easier in two regards. It's bigger (though the prime real es=
tate of type extension zero isn't) and can have message type specific TLVs.
>>=20
>> So TLVS can actually be invisible, if that option is chosen. For messages=
 something has to give. Least bad option is again one of those we should dis=
cuss, but time ...
>>=20
>> (To be precise, messages types from 224 are defined in RFC 5444 as " Expe=
rimental Use", of which BCP 26 says "Similar to private or local use only, w=
ith the  purpose being to facilitate experimentation." The alternative 0-223=
 space is Expert Review. IANA still thinks the experts are Joe Macker and th=
e recused Stan Ratliff. But that's a soluble nit.)
>>=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
>>=20
>> -----Original Message-----
>> From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org]
>> Sent: 22 April 2016 14:21
>> To: Dearlove, Christopher (UK)
>> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-=
manet-aodvv2-13 review - a couple of big ticket Items)
>>=20
>> ----------------------! WARNING ! ---------------------- This message ori=
ginates from outside our organisation, either from an external partner or fr=
om the internet.
>> Consider carefully whether you should click on any links, open any attach=
ments or reply.
>> Follow the 'Report Suspicious Emails' link on IT matters for instructions=
 on reporting suspicious email messages.
>> --------------------------------------------------------
>>=20
>>=20
>> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK)  wrote:
>> >
>> > Once you're entirely in AODV2's own space, and AODVv2 is experimental (=
working assumption for this discussion) you have more liberty.
>> >
>>=20
>> Yep.
>>=20
>> Taken somewhat by surprise both by the sudden "rush" and the experimental=
 maturity level, I am wondering (and haven't thought through) about experime=
ntal space vs non-experimental (for message types, and consequently for mess=
age type specific TLV types).
>>=20
>> I think that if the AODVv2 experiment specifies the use of Message types f=
rom the Experimental message type space without making actual registrations i=
n the IANA registry, AND the use of type specific TLV types, this becomes a n=
on-issue entirely (by design, this is precisely what that experimental space=
 is for)
>>=20
>> Whereas, as you point out, the alternative is a "can open - worms everywh=
ere" situation that I think time is too short to solve?
>>=20
>> Thomas
>>=20
>>=20
>> > Then you could try specifying it. But with a very good chance of produc=
ing something you later decide you should have done differently.
>> >
>> > I honestly don't know which would go down better (or less badly) - "her=
e's a mechanism we haven't really thought through in detail, but at least we=
've defined one", or "we know the sort of thing we want, and we'll describe i=
t, but rather than produce something not quite right, we'll not go further".=

>> >
>> > --
>> > 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 Bad=
dow, 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: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]
>> > Sent: 22 April 2016 13:59
>> > To: Mobile Ad Hoc Networks mailing list
>> > Cc: Henning Rogge; Dearlove, Christopher (UK)
>> > Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-iet=
f-manet-aodvv2-13 review - a couple of big ticket Items)
>> >
>> > ----------------------! WARNING ! ---------------------- This message o=
riginates from outside our organisation, either from an external partner or f=
rom the internet.
>> > Consider carefully whether you should click on any links, open any atta=
chments or reply.
>> > Follow the 'Report Suspicious Emails' link on IT matters for instructio=
ns on reporting suspicious email messages.
>> > --------------------------------------------------------
>> >
>> > Hello Christopher,
>> >
>> >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) :
>> >>
>> >> Just be careful to note that this concept is as currently being discus=
sed (a) specific to AODVv2, and (b) not an application of 7182, which has no=
 knowledge of special TLVs.
>> >>
>> >> This is something we'd want to get right, and need to get right if in a=
ny space not specific to ADODVv2, because getting it wrong produces future p=
roblems.
>> >
>> > Makes sense.
>> >
>> >> I can see some possible approaches, none is ideal and we're rather out=

>> >> of time to specify. But this is experimental, so I think we might be
>> >> able to indicate the shape of the solution without specifying it,
>> >> which would be a different RFC, under a bit less time pressure.
>> >> (Extensions to existing protocols like 7182 would naturally be in
>> >> scope rechartered I think.)
>> >>
>> >> To indicate the range that's open, here are two possible ideas, one of=
 which has an impact now, so needs to be agreed. Note that I'm not suggestin=
g (in fact quite the opposite) defining an extension to 7182 here, rather en=
abling such an extension, if written, to "do the right thing".
>> >> - We have an extension to 7182 that says "zero out all value octets in=
 protocol specific TLVs. That requires now putting the AODVv2 metric TLV in t=
hat space.
>> >
>> > Just to make sure that I understood you correctly=E2=80=93 =E2=80=9Ctha=
t space=E2=80=9D meaning making the AODVv2 metric TLV protocol specific? (By=
 =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m referring to the generi=
c TLV we=E2=80=99ve been talking about on this list earlier this week).
>> >
>> >> - We have an extension to 7182 that adds extra material to the value f=
ield that indicates (TBD how, by position with sanity check that this is TLV=
 value perhaps?) which octets are to be zeroed out before the ICV is calcula=
ted.
>> >
>> > The way I understand that approach, it wouldn=E2=80=99t warrant any act=
ion from AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set the Me=
tric value to zero=E2=80=9D (leaving the nitty gritty of how this would be d=
one in detail to future work)=E2=80=A6 Is that correct?
>> >
>> >>
>> >> We do not have the time to specify this in an acceptable manner within=
 two weeks though. But the security consideration section could say somethin=
g along the lines of "this enables the use of an ICV defined to zero out the=
se octets=E2=80=9C.
>> >
>> > Okay. :)
>> >
>> > Best regards,
>> > Lotte
>> >
>> >>
>> >> --
>> >> 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 Ba=
ddow, 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 Lotte
>> >> Steenbrink
>> >> Sent: 22 April 2016 10:28
>> >> To: Henning Rogge
>> >> Cc: Mobile Ad Hoc Networks mailing list
>> >> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>> >> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>> >>
>> >> ----------------------! WARNING ! ---------------------- This message o=
riginates from outside our organisation, either from an external partner or f=
rom the internet.
>> >> Consider carefully whether you should click on any links, open any att=
achments or reply.
>> >> Follow the 'Report Suspicious Emails' link on IT matters for instructi=
ons on reporting suspicious email messages.
>> >> --------------------------------------------------------
>> >>
>> >> *** WARNING ***
>> >> EXTERNAL EMAIL -- This message originates from outside our organizatio=
n.
>> >>
>> >>
>> >> Hi Henning,
>> >>
>> >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge :
>> >>>
>> >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>> >>>  wrote:
>> >>>> Hi Thomas,
>> >>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=E2=
=80=9D language
>> >>>> in the first place is that we=E2=80=99ve been told that whenever one=
 bit in
>> >>>> the message (apart from its header) is changed, the entire thing has=
 to be regenerated.
>> >>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been misu=
nderstanding
>> >>>> each other for more than a year. :( Anyway, it seems like we=E2=80=99=
re
>> >>>> getting close now, so yay.
>> >>>
>> >>> "Modifying" the binary message instead of parsing and generating a
>> >>> new one will be difficult as soon someone writes an extension to
>> >>> AODVv2 that adds more TLVs to the message.
>> >>
>> >> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s w=
hat you explained to me when I got confused about the topic last spring=E2=80=
=A6 But=E2=80=93 even if a message contains TLVs that the AODVv2 implementat=
ion handling it doesn=E2=80=99t understand, it will still be able to recogni=
ze the Metric TLV, right? Isn=E2=80=99t that the nifty thing about RFC5444? S=
o, while we really shouldn=E2=80=99t write =E2=80=9Cbefore calculating the I=
CV, set the n-th 4 octets to 0=E2=80=9D, we might say =E2=80=9Cidentify the o=
ctets that make up the metric value and set those to 0=E2=80=9D?
>> >>
>> >> Best regards,
>> >> Lotte
>> >>
>> >>> Henning Rogge
>> >>
>> >> _______________________________________________
>> >> 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
>>=20
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>=20

--Apple-Mail-6DC4ACD0-186A-4ABD-BD3B-2911F1ADC64D
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


That was my line of thinking, too, as i=
t would allow enormous flexibility in the experiments possible - which defin=
itely is required. 

Thomas



On 22 a=
vr. 2016, at 16:35, Justin Dean <=
bebemaster@gmail.com> wrote:

<=
div>
Speaking as participant.

I kind of like the idea=
 of using the experimental message type space.  We only have a limited a=
mount of these message types.  The TLV assignments could just use the m=
essage type specific space and there isn't an issue there.  IANA wouldn=
't assign a number but I don't see why the document couldn't specify the exp=
erimental numbers it was going to use so other future near term experiential=
 protocols could do the same and generally avoid conflict.  If the expe=
riment is successful IANA assignments could be made.  Functionally no r=
eal difference with protections vs long term usage of limited space.
Justin

On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
There's rather a contradiction between the concepts of a definitio=
n of a protocol, even Experimental, and experimental space, which usually as=
sumes that the user can do what he or she likes in it.



But chewing up messages types (how many, 3?) of which there are relatively f=
ew for experimental is long term a problem, although short term not.



TLV space is easier in two regards. It's bigger (though the prime real estat=
e of type extension zero isn't) and can have message type specific TLVs.
=



So TLVS can actually be invisible, if that option is chosen. For messages so=
mething has to give. Least bad option is again one of those we should discus=
s, but time ...



(To be precise, messages types from 224 are defined in RFC 5444 as " Experim=
ental Use", of which BCP 26 says "Similar to private or local use only, with=
 the  purpose being to facilitate experimentation." The alternative 0-2=
23 space is Expert Review. IANA still thinks the experts are Joe Macker and t=
he recused Stan Ratliff. But that's a soluble nit.)



--

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





-----Original Message-----

From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org]

Sent: 22 April 2016 14:21

To: Dearlove, Christopher (UK)


Cc: Lotte Steenbrink; Mobile A=
d Hoc Networks mailing list

Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-man=
et-aodvv2-13 review - a couple of big ticket Items)



----------------------! WARNING ! ---------------------- This message origin=
ates from outside our organisation, either from an external partner or from t=
he internet.

Consider carefully whether you should click on any links, open any attachmen=
ts or reply.

Follow the 'Report Suspicious Emails' link on IT matters for instructions on=
 reporting suspicious email messages.

--------------------------------------------------------





> On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wr=
ote:

>

> Once you're entirely in AODV2's own space, and AODVv2 is experimental (=
working assumption for this discussion) you have more liberty.

>



Yep.



Taken somewhat by surprise both by the sudden "rush" and the experimental ma=
turity level, I am wondering (and haven't thought through) about experimenta=
l space vs non-experimental (for message types, and consequently for message=
 type specific TLV types).



I think that if the AODVv2 experiment specifies the use of Message types fro=
m the Experimental message type space without making actual registrations in=
 the IANA registry, AND the use of type specific TLV types, this becomes a n=
on-issue entirely (by design, this is precisely what that experimental space=
 is for)



Whereas, as you point out, the alternative is a "can open - worms everywhere=
" situation that I think time is too short to solve?



Thomas





> Then you could try specifying it. But with a very good chance of produc=
ing something you later decide you should have done differently.

>

> I honestly don't know which would go down better (or less badly) - "her=
e's a mechanism we haven't really thought through in detail, but at least we=
've defined one", or "we know the sort of thing we want, and we'll describe i=
t, but rather than produce something not quite right, we'll not go further".=


>

> --

> 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 Bad=
dow, 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: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]

> Sent: 22 April 2016 13:59

> To: Mobile Ad Hoc Networks mailing list

> Cc: Henning Rogge; Dearlove, Christopher (UK)

> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-iet=
f-manet-aodvv2-13 review - a couple of big ticket Items)

>

> ----------------------! WARNING ! ---------------------- This message o=
riginates from outside our organisation, either from an external partner or f=
rom the internet.

> Consider carefully whether you should click on any links, open any atta=
chments or reply.

> Follow the 'Report Suspicious Emails' link on IT matters for instructio=
ns on reporting suspicious email messages.

> --------------------------------------------------------

>

> Hello Christopher,

>

>> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>:

>>

>> Just be careful to note that this concept is as currently being dis=
cussed (a) specific to AODVv2, and (b) not an application of 7182, which has=
 no knowledge of special TLVs.

>>

>> This is something we'd want to get right, and need to get right if i=
n any space not specific to ADODVv2, because getting it wrong produces futur=
e problems.

>

> Makes sense.

>

>> I can see some possible approaches, none is ideal and we're rather o=
ut

>> of time to specify. But this is experimental, so I think we might b=
e

>> able to indicate the shape of the solution without specifying it,
>> which would be a different RFC, under a bit less time pressure.
=

>> (Extensions to existing protocols like 7182 would naturally be in
>> scope rechartered I think.)

>>

>> To indicate the range that's open, here are two possible ideas, one=
 of which has an impact now, so needs to be agreed. Note that I'm not sugges=
ting (in fact quite the opposite) defining an extension to 7182 here, rather=
 enabling such an extension, if written, to "do the right thing".

>> - We have an extension to 7182 that says "zero out all value octets=
 in protocol specific TLVs. That requires now putting the AODVv2 metric TLV i=
n that space.

>

> Just to make sure that I understood you correctly=E2=80=93 =E2=80=9Ctha=
t space=E2=80=9D meaning making the AODVv2 metric TLV protocol specific? (By=
 =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m referring to the generi=
c TLV we=E2=80=99ve been talking about on this list earlier this week).

>

>> - We have an extension to 7182 that adds extra material to the valu=
e field that indicates (TBD how, by position with sanity check that this is T=
LV value perhaps?) which octets are to be zeroed out before the ICV is calcu=
lated.

>

> The way I understand that approach, it wouldn=E2=80=99t warrant any act=
ion from AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set the Me=
tric value to zero=E2=80=9D (leaving the nitty gritty of how this would be d=
one in detail to future work)=E2=80=A6 Is that correct?

>

>>

>> We do not have the time to specify this in an acceptable manner wit=
hin two weeks though. But the security consideration section could say somet=
hing along the lines of "this enables the use of an ICV defined to zero out t=
hese octets=E2=80=9C.

>

> Okay. :)

>

> Best regards,

> Lotte

>

>>

>> --

>> 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

>>

>> -----Original Message-----

>> From: manet [mailto:manet=
-bounces@ietf.org] On Behalf Of Lotte

>> Steenbrink

>> Sent: 22 April 2016 10:28

>> To: Henning Rogge

>> Cc: Mobile Ad Hoc Networks mailing list

>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:

>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>

>> ----------------------! WARNING ! ---------------------- This messa=
ge originates from outside our organisation, either from an external partner=
 or from the internet.

>> Consider carefully whether you should click on any links, open any a=
ttachments or reply.

>> Follow the 'Report Suspicious Emails' link on IT matters for instru=
ctions on reporting suspicious email messages.

>> --------------------------------------------------------

>>

>> *** WARNING ***

>> EXTERNAL EMAIL -- This message originates from outside our organiza=
tion.

>>

>>

>> Hi Henning,

>>

>>> Am 22.04.2016 um 11:08 schrieb Henning Rogge <hrogge@gmail.com>:

>>>

>>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink

>>> <lotte.stee=
nbrink@fu-berlin.de> wrote:

>>>> Hi Thomas,

>>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregen=
eration=E2=80=9D language

>>>> in the first place is that we=E2=80=99ve been told that whe=
never one bit in

>>>> the message (apart from its header) is changed, the entire t=
hing has to be regenerated.

>>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just b=
een misunderstanding

>>>> each other for more than a year. :( Anyway, it seems like w=
e=E2=80=99re

>>>> getting close now, so yay.

>>>

>>> "Modifying" the binary message instead of parsing and generatin=
g a

>>> new one will be difficult as soon someone writes an extension t=
o

>>> AODVv2 that adds more TLVs to the message.

>>

>> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99=
s what you explained to me when I got confused about the topic last spring=E2=
=80=A6 But=E2=80=93 even if a message contains TLVs that the AODVv2 implemen=
tation handling it doesn=E2=80=99t understand, it will still be able to reco=
gnize the Metric TLV, right? Isn=E2=80=99t that the nifty thing about RFC544=
4? So, while we really shouldn=E2=80=99t write =E2=80=9Cbefore calculating t=
he ICV, set the n-th 4 octets to 0=E2=80=9D, we might say =E2=80=9Cidentify t=
he octets that make up the metric value and set those to 0=E2=80=9D?

>>

>> Best regards,

>> Lotte

>>

>>> Henning Rogge

>>

>> _______________________________________________

>> 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.<=
br>
>> 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





=

--Apple-Mail-6DC4ACD0-186A-4ABD-BD3B-2911F1ADC64D--


From nobody Fri Apr 22 07:40: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 DD83112DC91 for ; Fri, 22 Apr 2016 07:40:19 -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 oQd-yyaCUXZR for ; Fri, 22 Apr 2016 07:40:10 -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 E2F7312DFB9 for ; Fri, 22 Apr 2016 07:40:09 -0700 (PDT)
Received: by mail-ig0-x22e.google.com with SMTP id bi2so15449167igb.0 for ; Fri, 22 Apr 2016 07:40:09 -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=Q0arVU8ZfKrTmHHu82/8ocwq0HNnRTik+GZgsJ04a/s=; b=D+0ZDh6dYfYeDUJPdM59Oj0Pjlrh0VgE+2wKvz1MnsWU6zd1RYT8GAISgpAv/Jk/rz QB/oV24V/Msw7BKug4Gf10wI8sz5sqWl3K+9WVv8tJ9sxTT4ivkBUZG6Ae2F3Ruzcuaf Bsn0C2EKdvX6ukKcg14naVfvuX+zkOME1Gkj4l9jvbd6LvxChH3PTJwE4y5esRol5NYO Wr9KjEWP5nbANqh8TJ/4GEtmE+GxRlQS6ePdBMge7YxL3Vvybk8IH2AEpcdrpp9Oz2bX gJ0DT4GCkkfQEmiUmjQVBurCkcrfJENFwrmOIqBGq51F8GtUG+Id8w8hZffiBxRQi60C 9lpA==
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=Q0arVU8ZfKrTmHHu82/8ocwq0HNnRTik+GZgsJ04a/s=; b=WRqgan8eqdgMKYBjWmWmNBFMGKigvKlIqUDExOee3fE86gXtHTE/EmA2NaOOt2t8XW HlkEJe8v48TUIBAQE7rx1k09lqCDJKNNcE8yF7z/D/NKcI/bVPcke1Dquh6/namPCDHz sDqa9rYRXbhhMJ2SJtoCoqqsgooV1U1HJ1qZCSJq5CChbAdi0PqW2PhJp9tNmDAii8La mx8sEifs0WZuAWeboP0mmbGRnmlbVv51Ouazq/IdjC2sNHuCp9BFUQaFV5eBSym9ObKW SS0UYtmmNEmoXPzIRmS2J1ixn6bCawolGLLIJnZtcSyCATr4sXwjIoYB8DoJ41ZJFa+J t+BA==
X-Gm-Message-State: AOPr4FUAA8fbOTcuC8N4OPS3g9JLgUo1mxtAHtkB4nK1IX4G+HQXEDHPVld6EY8fc5Nbt3K6oGtSKKjxqWwhbQ==
MIME-Version: 1.0
X-Received: by 10.50.72.107 with SMTP id c11mr4924954igv.85.1461336009274; Fri, 22 Apr 2016 07:40:09 -0700 (PDT)
Received: by 10.79.72.68 with HTTP; Fri, 22 Apr 2016 07:40:09 -0700 (PDT)
In-Reply-To: 
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org>  
Date: Fri, 22 Apr 2016 10:40:09 -0400
Message-ID: 
From: Stan Ratliff 
To: Justin Dean 
Content-Type: multipart/alternative; boundary=047d7bdc15babb005c053113cd8a
Archived-At: 
Cc: "Dearlove, Christopher \(UK\)" , Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 14:40:20 -0000

--047d7bdc15babb005c053113cd8a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 22, 2016 at 10:35 AM, Justin Dean  wrote:

> Speaking as participant.
>
> I kind of like the idea of using the experimental message type space.  We
> only have a limited amount of these message types.  The TLV assignments
> could just use the message type specific space and there isn't an issue
> there.  IANA wouldn't assign a number but I don't see why the document
> couldn't specify the experimental numbers it was going to use so other
> future near term experiential protocols could do the same and generally
> avoid conflict.  If the experiment is successful IANA assignments could b=
e
> made.  Functionally no real difference with protections vs long term usag=
e
> of limited space.
>

+1 here.

Regards,
Stan




>
> Justin
>
> On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>> There's rather a contradiction between the concepts of a definition of a
>> protocol, even Experimental, and experimental space, which usually assum=
es
>> that the user can do what he or she likes in it.
>>
>> But chewing up messages types (how many, 3?) of which there are
>> relatively few for experimental is long term a problem, although short t=
erm
>> not.
>>
>> TLV space is easier in two regards. It's bigger (though the prime real
>> estate of type extension zero isn't) and can have message type specific
>> TLVs.
>>
>> So TLVS can actually be invisible, if that option is chosen. For message=
s
>> something has to give. Least bad option is again one of those we should
>> discuss, but time ...
>>
>> (To be precise, messages types from 224 are defined in RFC 5444 as "
>> Experimental Use", of which BCP 26 says "Similar to private or local use
>> only, with the  purpose being to facilitate experimentation." The
>> alternative 0-223 space is Expert Review. IANA still thinks the experts =
are
>> Joe Macker and the recused Stan Ratliff. But that's a soluble nit.)
>>
>> --
>> 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
>>
>>
>> -----Original Message-----
>> From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org]
>> Sent: 22 April 2016 14:21
>> To: Dearlove, Christopher (UK)
>> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>> ----------------------! WARNING ! ---------------------- This message
>> originates from outside our organisation, either from an external partne=
r
>> or from the internet.
>> Consider carefully whether you should click on any links, open any
>> attachments or reply.
>> Follow the 'Report Suspicious Emails' link on IT matters for instruction=
s
>> on reporting suspicious email messages.
>> --------------------------------------------------------
>>
>>
>> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>> >
>> > Once you're entirely in AODV2's own space, and AODVv2 is experimental
>> (working assumption for this discussion) you have more liberty.
>> >
>>
>> Yep.
>>
>> Taken somewhat by surprise both by the sudden "rush" and the experimenta=
l
>> maturity level, I am wondering (and haven't thought through) about
>> experimental space vs non-experimental (for message types, and consequen=
tly
>> for message type specific TLV types).
>>
>> I think that if the AODVv2 experiment specifies the use of Message types
>> from the Experimental message type space without making actual
>> registrations in the IANA registry, AND the use of type specific TLV typ=
es,
>> this becomes a non-issue entirely (by design, this is precisely what tha=
t
>> experimental space is for)
>>
>> Whereas, as you point out, the alternative is a "can open - worms
>> everywhere" situation that I think time is too short to solve?
>>
>> Thomas
>>
>>
>> > Then you could try specifying it. But with a very good chance of
>> producing something you later decide you should have done differently.
>> >
>> > I honestly don't know which would go down better (or less badly) -
>> "here's a mechanism we haven't really thought through in detail, but at
>> least we've defined one", or "we know the sort of thing we want, and we'=
ll
>> describe it, but rather than produce something not quite right, we'll no=
t
>> go further".
>> >
>> > --
>> > 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
>> >
>> >
>> > -----Original Message-----
>> > From: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]
>> > Sent: 22 April 2016 13:59
>> > To: Mobile Ad Hoc Networks mailing list
>> > Cc: Henning Rogge; Dearlove, Christopher (UK)
>> > Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>> >
>> > ----------------------! WARNING ! ---------------------- This message
>> originates from outside our organisation, either from an external partne=
r
>> or from the internet.
>> > Consider carefully whether you should click on any links, open any
>> attachments or reply.
>> > Follow the 'Report Suspicious Emails' link on IT matters for
>> instructions on reporting suspicious email messages.
>> > --------------------------------------------------------
>> >
>> > Hello Christopher,
>> >
>> >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com>:
>> >>
>> >> Just be careful to note that this concept is as currently being
>> discussed (a) specific to AODVv2, and (b) not an application of 7182, wh=
ich
>> has no knowledge of special TLVs.
>> >>
>> >> This is something we'd want to get right, and need to get right if in
>> any space not specific to ADODVv2, because getting it wrong produces fut=
ure
>> problems.
>> >
>> > Makes sense.
>> >
>> >> I can see some possible approaches, none is ideal and we're rather ou=
t
>> >> of time to specify. But this is experimental, so I think we might be
>> >> able to indicate the shape of the solution without specifying it,
>> >> which would be a different RFC, under a bit less time pressure.
>> >> (Extensions to existing protocols like 7182 would naturally be in
>> >> scope rechartered I think.)
>> >>
>> >> To indicate the range that's open, here are two possible ideas, one o=
f
>> which has an impact now, so needs to be agreed. Note that I'm not
>> suggesting (in fact quite the opposite) defining an extension to 7182 he=
re,
>> rather enabling such an extension, if written, to "do the right thing".
>> >> - We have an extension to 7182 that says "zero out all value octets i=
n
>> protocol specific TLVs. That requires now putting the AODVv2 metric TLV =
in
>> that space.
>> >
>> > Just to make sure that I understood you correctly=E2=80=93 =E2=80=9Cth=
at space=E2=80=9D meaning
>> making the AODVv2 metric TLV protocol specific? (By =E2=80=9Cthe aodvv2 =
metric tlv=E2=80=9D
>> I=E2=80=99m referring to the generic TLV we=E2=80=99ve been talking abou=
t on this list
>> earlier this week).
>> >
>> >> - We have an extension to 7182 that adds extra material to the value
>> field that indicates (TBD how, by position with sanity check that this i=
s
>> TLV value perhaps?) which octets are to be zeroed out before the ICV is
>> calculated.
>> >
>> > The way I understand that approach, it wouldn=E2=80=99t warrant any ac=
tion from
>> AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set the Metric =
value to
>> zero=E2=80=9D (leaving the nitty gritty of how this would be done in det=
ail to
>> future work)=E2=80=A6 Is that correct?
>> >
>> >>
>> >> We do not have the time to specify this in an acceptable manner withi=
n
>> two weeks though. But the security consideration section could say
>> something along the lines of "this enables the use of an ICV defined to
>> zero out these octets=E2=80=9C.
>> >
>> > Okay. :)
>> >
>> > Best regards,
>> > Lotte
>> >
>> >>
>> >> --
>> >> 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 & Wale=
s
>> >> No: 01337451 Registered Office: Surrey Research Park, Guildford,
>> >> Surrey, GU2 7YP
>> >>
>> >> -----Original Message-----
>> >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte
>> >> Steenbrink
>> >> Sent: 22 April 2016 10:28
>> >> To: Henning Rogge
>> >> Cc: Mobile Ad Hoc Networks mailing list
>> >> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>> >> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>> >>
>> >> ----------------------! WARNING ! ---------------------- This message
>> originates from outside our organisation, either from an external partne=
r
>> or from the internet.
>> >> Consider carefully whether you should click on any links, open any
>> attachments or reply.
>> >> Follow the 'Report Suspicious Emails' link on IT matters for
>> instructions on reporting suspicious email messages.
>> >> --------------------------------------------------------
>> >>
>> >> *** WARNING ***
>> >> EXTERNAL EMAIL -- This message originates from outside our
>> organization.
>> >>
>> >>
>> >> Hi Henning,
>> >>
>> >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge :
>> >>>
>> >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>> >>>  wrote:
>> >>>> Hi Thomas,
>> >>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=
=E2=80=9D language
>> >>>> in the first place is that we=E2=80=99ve been told that whenever on=
e bit in
>> >>>> the message (apart from its header) is changed, the entire thing ha=
s
>> to be regenerated.
>> >>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been mis=
understanding
>> >>>> each other for more than a year. :( Anyway, it seems like we=E2=80=
=99re
>> >>>> getting close now, so yay.
>> >>>
>> >>> "Modifying" the binary message instead of parsing and generating a
>> >>> new one will be difficult as soon someone writes an extension to
>> >>> AODVv2 that adds more TLVs to the message.
>> >>
>> >> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s=
 what you
>> explained to me when I got confused about the topic last spring=E2=80=A6=
 But=E2=80=93 even
>> if a message contains TLVs that the AODVv2 implementation handling it
>> doesn=E2=80=99t understand, it will still be able to recognize the Metri=
c TLV,
>> right? Isn=E2=80=99t that the nifty thing about RFC5444? So, while we re=
ally
>> shouldn=E2=80=99t write =E2=80=9Cbefore calculating the ICV, set the n-t=
h 4 octets to 0=E2=80=9D,
>> we might say =E2=80=9Cidentify the octets that make up the metric value =
and set
>> those to 0=E2=80=9D?
>> >>
>> >> Best regards,
>> >> Lotte
>> >>
>> >>> Henning Rogge
>> >>
>> >> _______________________________________________
>> >> 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
>>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>

--047d7bdc15babb005c053113cd8a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Apr 22, 2016 at 10:35 AM, Justin Dean <bebemaster@gmail.com=
> wrote:
S=
peaking as participant.

I kind of like the idea of using the experim=
ental message type space.=C2=A0 We only have a limited amount of these mess=
age types.=C2=A0 The TLV assignments could just use the message type specif=
ic space and there isn't an issue there.=C2=A0 IANA wouldn't assign=
 a number but I don't see why the document couldn't specify the exp=
erimental numbers it was going to use so other future near term experientia=
l protocols could do the same and generally avoid conflict.=C2=A0 If the ex=
periment is successful IANA assignments could be made.=C2=A0 Functionally n=
o real difference with protections vs long term usage of limited space.

+1 here.

Regard=
s,
Stan


=C2=A0

Justin

On Fri, Apr 22, 2016 at 9:=
35 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.c=
om> wrote:
There's rath=
er a contradiction between the concepts of a definition of a protocol, even=
 Experimental, and experimental space, which usually assumes that the user =
can do what he or she likes in it.



But chewing up messages types (how many, 3?) of which there are relatively =
few for experimental is long term a problem, although short term not.



TLV space is easier in two regards. It's bigger (though the prime real =
estate of type extension zero isn't) and can have message type specific=
 TLVs.



So TLVS can actually be invisible, if that option is chosen. For messages s=
omething has to give. Least bad option is again one of those we should disc=
uss, but time ...



(To be precise, messages types from 224 are defined in RFC 5444 as " E=
xperimental Use", of which BCP 26 says "Similar to private or loc=
al use only, with the=C2=A0 purpose being to facilitate experimentation.&qu=
ot; The alternative 0-223 space is Expert Review. IANA still thinks the exp=
erts are Joe Macker and the recused Stan Ratliff. But that's a soluble =
nit.)



--

Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

__________________________________________________________________________<=
br>


T: =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chris.dearlove@baesyst=
ems.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: Thomas Heide Clausen [mailto:ietf@thomasclausen.org]

Sent: 22 April 2016 14:21

To: Dearlove, Christopher (UK)


Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list<=
br>
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-ma=
net-aodvv2-13 review - a couple of big ticket Items)



----------------------! 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 instru=
ctions on reporting suspicious email messages.

--------------------------------------------------------





> On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <chris.dearlove@baesy=
stems.com> wrote:

>

> Once you're entirely in AODV2's own space, and AODVv2 is exper=
imental (working assumption for this discussion) you have more liberty.

>



Yep.



Taken somewhat by surprise both by the sudden "rush" and the expe=
rimental maturity level, I am wondering (and haven't thought through) a=
bout experimental space vs non-experimental (for message types, and consequ=
ently for message type specific TLV types).



I think that if the AODVv2 experiment specifies the use of Message types fr=
om the Experimental message type space without making actual registrations =
in the IANA registry, AND the use of type specific TLV types, this becomes =
a non-issue entirely (by design, this is precisely what that experimental s=
pace is for)



Whereas, as you point out, the alternative is a "can open - worms ever=
ywhere" situation that I think time is too short to solve?



Thomas





> Then you could try specifying it. But with a very good chance of produ=
cing something you later decide you should have done differently.

>

> I honestly don't know which would go down better (or less badly) -=
 "here's a mechanism we haven't really thought through in deta=
il, but at least we've defined one", or "we know the sort of =
thing we want, and we'll describe it, but rather than produce something=
 not quite right, we'll not go further".

>

> --

> Christopher Dearlove

> Senior Principal Engineer

> BAE Systems Applied Intelligence Laboratories

> ______________________________________________________________________=
____

>

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

>

> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Ba=
ddow, 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: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]

> Sent: 22 April 2016 13:59

> To: Mobile Ad Hoc Networks mailing list

> Cc: Henning Rogge; Dearlove, Christopher (UK)

> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ie=
tf-manet-aodvv2-13 review - a couple of big ticket Items)

>

> ----------------------! WARNING ! ---------------------- This message =
originates from outside our organisation, either from an external partner o=
r from the internet.

> Consider carefully whether you should click on any links, open any att=
achments or reply.

> Follow the 'Report Suspicious Emails' link on IT matters for i=
nstructions on reporting suspicious email messages.

> --------------------------------------------------------

>

> Hello Christopher,

>

>> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <chris.dearlo=
ve@baesystems.com>:

>>

>> Just be careful to note that this concept is as currently being di=
scussed (a) specific to AODVv2, and (b) not an application of 7182, which h=
as no knowledge of special TLVs.

>>

>> This is something we'd want to get right, and need to get righ=
t if in any space not specific to ADODVv2, because getting it wrong produce=
s future problems.

>

> Makes sense.

>

>> I can see some possible approaches, none is ideal and we're ra=
ther out

>> of time to specify. But this is experimental, so I think we might =
be

>> able to indicate the shape of the solution without specifying it,<=
br>
>> which would be a different RFC, under a bit less time pressure.
>> (Extensions to existing protocols like 7182 would naturally be in<=
br>
>> scope rechartered I think.)

>>

>> To indicate the range that's open, here are two possible ideas=
, one of which has an impact now, so needs to be agreed. Note that I'm =
not suggesting (in fact quite the opposite) defining an extension to 7182 h=
ere, rather enabling such an extension, if written, to "do the right t=
hing".

>> - We have an extension to 7182 that says "zero out all value =
octets in protocol specific TLVs. That requires now putting the AODVv2 metr=
ic TLV in that space.

>

> Just to make sure that I understood you correctly=E2=80=93 =E2=80=9Cth=
at space=E2=80=9D meaning making the AODVv2 metric TLV protocol specific? (=
By =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m referring to the gen=
eric TLV we=E2=80=99ve been talking about on this list earlier this week).<=
br>
>

>> - We have an extension to 7182 that adds extra material to the val=
ue field that indicates (TBD how, by position with sanity check that this i=
s TLV value perhaps?) which octets are to be zeroed out before the ICV is c=
alculated.

>

> The way I understand that approach, it wouldn=E2=80=99t warrant any ac=
tion from AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set the =
Metric value to zero=E2=80=9D (leaving the nitty gritty of how this would b=
e done in detail to future work)=E2=80=A6 Is that correct?

>

>>

>> We do not have the time to specify this in an acceptable manner wi=
thin two weeks though. But the security consideration section could say som=
ething along the lines of "this enables the use of an ICV defined to z=
ero out these octets=E2=80=9C.

>

> Okay. :)

>

> Best regards,

> Lotte

>

>>

>> --

>> Christopher Dearlove

>> Senior Principal Engineer

>> BAE Systems Applied Intelligence Laboratories

>> __________________________________________________________________=
____

>> ____

>>

>> T:=C2=A0 +44 (0)1245 242194=C2=A0 |=C2=A0 E: chris.dearlov=
e@baesystems.com

>>

>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Grea=
t Baddow, Chelmsford, Essex CM2 8HN.

>> www.baesystems.com/ai

>> BAE Systems Applied Intelligence Limited Registered in England &am=
p; Wales

>> No: 01337451 Registered Office: Surrey Research Park, Guildford,
>> Surrey, GU2 7YP

>>

>> -----Original Message-----

>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte

>> Steenbrink

>> Sent: 22 April 2016 10:28

>> To: Henning Rogge

>> Cc: Mobile Ad Hoc Networks mailing list

>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:

>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)<=
br>
>>

>> ----------------------! WARNING ! ---------------------- This mess=
age originates from outside our organisation, either from an external partn=
er or from the internet.

>> Consider carefully whether you should click on any links, open any=
 attachments or reply.

>> Follow the 'Report Suspicious Emails' link on IT matters f=
or instructions on reporting suspicious email messages.

>> --------------------------------------------------------

>>

>> *** WARNING ***

>> EXTERNAL EMAIL -- This message originates from outside our organiz=
ation.

>>

>>

>> Hi Henning,

>>

>>> Am 22.04.2016 um 11:08 schrieb Henning Rogge <hrogge@gmail.com>:

>>>

>>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink

>>> <lotte.steenbrink@fu-berlin.de> wrote:

>>>> Hi Thomas,

>>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Crege=
neration=E2=80=9D language

>>>> in the first place is that we=E2=80=99ve been told that wh=
enever one bit in

>>>> the message (apart from its header) is changed, the entire=
 thing has to be regenerated.

>>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just=
 been misunderstanding

>>>> each other for more than a year. :( Anyway, it seems like =
we=E2=80=99re

>>>> getting close now, so yay.

>>>

>>> "Modifying" the binary message instead of parsing an=
d generating a

>>> new one will be difficult as soon someone writes an extension =
to

>>> AODVv2 that adds more TLVs to the message.

>>

>> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=
=99s what you explained to me when I got confused about the topic last spri=
ng=E2=80=A6 But=E2=80=93 even if a message contains TLVs that the AODVv2 im=
plementation handling it doesn=E2=80=99t understand, it will still be able =
to recognize the Metric TLV, right? Isn=E2=80=99t that the nifty thing abou=
t RFC5444? So, while we really shouldn=E2=80=99t write =E2=80=9Cbefore calc=
ulating the ICV, set the n-th 4 octets to 0=E2=80=9D, we might say =E2=80=
=9Cidentify the octets that make up the metric value and set those to 0=E2=
=80=9D?

>>

>> Best regards,

>> Lotte

>>

>>> Henning Rogge

>>

>> _______________________________________________

>> manet mailing list

>> manet@ietf.org=


>> https://www.ietf.org/mailman/listinfo/manet<=
br>
>> ******************************************************************=
**

>> This email and any attachments are confidential to the intended
>> recipient and may also be privileged. If you are not the intended<=
br>
>> 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





--047d7bdc15babb005c053113cd8a--


From nobody Fri Apr 22 07:42: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 DB23A12E0D2 for ; Fri, 22 Apr 2016 07:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.915
X-Spam-Level: 
X-Spam-Status: No, score=-7.915 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] 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 d8YEafOzfaSR for ; Fri, 22 Apr 2016 07:42:02 -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 AE53B12DD10 for ; Fri, 22 Apr 2016 07:42:01 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,517,1454976000"; d="scan'208,217"; a="34085504"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 22 Apr 2016 15:42:01 +0100
X-IronPort-AV: E=Sophos;i="5.24,517,1454976000";  d="scan'208,217";a="115144209"
Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 22 Apr 2016 15:42:00 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0248.002; Fri, 22 Apr 2016 15:41:59 +0100
From: "Dearlove, Christopher (UK)" 
To: Justin Dean 
Thread-Topic: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
Thread-Index: AQHRmuq4sr6y+au39kGswdQyX9PrDp+VpYGAgAAA9YCAAAWLgIAAETzQgAAplICAABFWYP//9QAAgAARAXCAAAOWgIAAEl/w
Date: Fri, 22 Apr 2016 14:41:59 +0000
Message-ID: 
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org>  
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B0E81GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 14:42:05 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B0E81GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBoYXZlIG5vIHByb2JsZW0gd2l0aCB0aGF0LiBJIHdhcyB0cnlpbmcgdG8gbGF5IG91dCB0aGUg
aXNzdWVzIHdpdGhvdXQgbXVkZHlpbmcgdGhlIHdhdGVyIHdpdGggbXkgcHJlZmVyZW5jZS4NCg0K
LS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUg
U3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5
c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5
c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBH
cmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5j
b20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQg
SW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAw
MTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZv
cmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBKdXN0aW4gRGVhbiBbbWFpbHRvOmJlYmVtYXN0
ZXJAZ21haWwuY29tXQ0KU2VudDogMjIgQXByaWwgMjAxNiAxNTozNQ0KVG86IERlYXJsb3ZlLCBD
aHJpc3RvcGhlciAoVUspDQpDYzogVGhvbWFzIEhlaWRlIENsYXVzZW47IE1vYmlsZSBBZCBIb2Mg
TmV0d29ya3MgbWFpbGluZyBsaXN0DQpTdWJqZWN0OiBSZTogW21hbmV0XSBPbiBGb3J3YXJkaW5n
LWFuZC1yZWdlbmVyYXRpb24gKHdhczogUmU6IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJl
dmlldyAtIGEgY291cGxlIG9mIGJpZyB0aWNrZXQgSXRlbXMpDQoNCg0KKioqIFdBUk5JTkcgKioq
DQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwg
ZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRl
ciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBh
bnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBG
bGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xp
Y2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1
cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwg
dGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6
Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdo
dHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0K
U3BlYWtpbmcgYXMgcGFydGljaXBhbnQuDQoNCkkga2luZCBvZiBsaWtlIHRoZSBpZGVhIG9mIHVz
aW5nIHRoZSBleHBlcmltZW50YWwgbWVzc2FnZSB0eXBlIHNwYWNlLiAgV2Ugb25seSBoYXZlIGEg
bGltaXRlZCBhbW91bnQgb2YgdGhlc2UgbWVzc2FnZSB0eXBlcy4gIFRoZSBUTFYgYXNzaWdubWVu
dHMgY291bGQganVzdCB1c2UgdGhlIG1lc3NhZ2UgdHlwZSBzcGVjaWZpYyBzcGFjZSBhbmQgdGhl
cmUgaXNuJ3QgYW4gaXNzdWUgdGhlcmUuICBJQU5BIHdvdWxkbid0IGFzc2lnbiBhIG51bWJlciBi
dXQgSSBkb24ndCBzZWUgd2h5IHRoZSBkb2N1bWVudCBjb3VsZG4ndCBzcGVjaWZ5IHRoZSBleHBl
cmltZW50YWwgbnVtYmVycyBpdCB3YXMgZ29pbmcgdG8gdXNlIHNvIG90aGVyIGZ1dHVyZSBuZWFy
IHRlcm0gZXhwZXJpZW50aWFsIHByb3RvY29scyBjb3VsZCBkbyB0aGUgc2FtZSBhbmQgZ2VuZXJh
bGx5IGF2b2lkIGNvbmZsaWN0LiAgSWYgdGhlIGV4cGVyaW1lbnQgaXMgc3VjY2Vzc2Z1bCBJQU5B
IGFzc2lnbm1lbnRzIGNvdWxkIGJlIG1hZGUuICBGdW5jdGlvbmFsbHkgbm8gcmVhbCBkaWZmZXJl
bmNlIHdpdGggcHJvdGVjdGlvbnMgdnMgbG9uZyB0ZXJtIHVzYWdlIG9mIGxpbWl0ZWQgc3BhY2Uu
DQoNCkp1c3Rpbg0KDQpPbiBGcmksIEFwciAyMiwgMjAxNiBhdCA5OjM1IEFNLCBEZWFybG92ZSwg
Q2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNo
cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQpUaGVyZSdzIHJhdGhlciBhIGNv
bnRyYWRpY3Rpb24gYmV0d2VlbiB0aGUgY29uY2VwdHMgb2YgYSBkZWZpbml0aW9uIG9mIGEgcHJv
dG9jb2wsIGV2ZW4gRXhwZXJpbWVudGFsLCBhbmQgZXhwZXJpbWVudGFsIHNwYWNlLCB3aGljaCB1
c3VhbGx5IGFzc3VtZXMgdGhhdCB0aGUgdXNlciBjYW4gZG8gd2hhdCBoZSBvciBzaGUgbGlrZXMg
aW4gaXQuDQoNCkJ1dCBjaGV3aW5nIHVwIG1lc3NhZ2VzIHR5cGVzIChob3cgbWFueSwgMz8pIG9m
IHdoaWNoIHRoZXJlIGFyZSByZWxhdGl2ZWx5IGZldyBmb3IgZXhwZXJpbWVudGFsIGlzIGxvbmcg
dGVybSBhIHByb2JsZW0sIGFsdGhvdWdoIHNob3J0IHRlcm0gbm90Lg0KDQpUTFYgc3BhY2UgaXMg
ZWFzaWVyIGluIHR3byByZWdhcmRzLiBJdCdzIGJpZ2dlciAodGhvdWdoIHRoZSBwcmltZSByZWFs
IGVzdGF0ZSBvZiB0eXBlIGV4dGVuc2lvbiB6ZXJvIGlzbid0KSBhbmQgY2FuIGhhdmUgbWVzc2Fn
ZSB0eXBlIHNwZWNpZmljIFRMVnMuDQoNClNvIFRMVlMgY2FuIGFjdHVhbGx5IGJlIGludmlzaWJs
ZSwgaWYgdGhhdCBvcHRpb24gaXMgY2hvc2VuLiBGb3IgbWVzc2FnZXMgc29tZXRoaW5nIGhhcyB0
byBnaXZlLiBMZWFzdCBiYWQgb3B0aW9uIGlzIGFnYWluIG9uZSBvZiB0aG9zZSB3ZSBzaG91bGQg
ZGlzY3VzcywgYnV0IHRpbWUgLi4uDQoNCihUbyBiZSBwcmVjaXNlLCBtZXNzYWdlcyB0eXBlcyBm
cm9tIDIyNCBhcmUgZGVmaW5lZCBpbiBSRkMgNTQ0NCBhcyAiIEV4cGVyaW1lbnRhbCBVc2UiLCBv
ZiB3aGljaCBCQ1AgMjYgc2F5cyAiU2ltaWxhciB0byBwcml2YXRlIG9yIGxvY2FsIHVzZSBvbmx5
LCB3aXRoIHRoZSAgcHVycG9zZSBiZWluZyB0byBmYWNpbGl0YXRlIGV4cGVyaW1lbnRhdGlvbi4i
IFRoZSBhbHRlcm5hdGl2ZSAwLTIyMyBzcGFjZSBpcyBFeHBlcnQgUmV2aWV3LiBJQU5BIHN0aWxs
IHRoaW5rcyB0aGUgZXhwZXJ0cyBhcmUgSm9lIE1hY2tlciBhbmQgdGhlIHJlY3VzZWQgU3RhbiBS
YXRsaWZmLiBCdXQgdGhhdCdzIGEgc29sdWJsZSBuaXQuKQ0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVh
cmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50
ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkx
MjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4gIHwgIEU6IGNocmlz
LmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z
LmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVj
aG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3
d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBT
eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFu
ZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJj
aCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQpGcm9tOiBUaG9tYXMgSGVpZGUgQ2xhdXNlbiBbbWFpbHRvOmlldGZAdGhvbWFz
Y2xhdXNlbi5vcmc8bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmc+XQ0KU2VudDogMjIgQXBy
aWwgMjAxNiAxNDoyMQ0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpDYzogTG90dGUg
U3RlZW5icmluazsgTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3QNClN1YmplY3Q6
IFJlOiBbbWFuZXRdIE9uIEZvcndhcmRpbmctYW5kLXJlZ2VuZXJhdGlvbiAod2FzOiBSZTogZHJh
ZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJ
dGVtcykNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlz
YXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJu
ZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBs
aW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb2xsb3cgdGhlICdSZXBvcnQg
U3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9u
IHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo+IE9uIDIyIGF2ci4g
MjAxNiwgYXQgMTU6MDUsIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92
ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PiB3
cm90ZToNCj4NCj4gT25jZSB5b3UncmUgZW50aXJlbHkgaW4gQU9EVjIncyBvd24gc3BhY2UsIGFu
ZCBBT0RWdjIgaXMgZXhwZXJpbWVudGFsICh3b3JraW5nIGFzc3VtcHRpb24gZm9yIHRoaXMgZGlz
Y3Vzc2lvbikgeW91IGhhdmUgbW9yZSBsaWJlcnR5Lg0KPg0KDQpZZXAuDQoNClRha2VuIHNvbWV3
aGF0IGJ5IHN1cnByaXNlIGJvdGggYnkgdGhlIHN1ZGRlbiAicnVzaCIgYW5kIHRoZSBleHBlcmlt
ZW50YWwgbWF0dXJpdHkgbGV2ZWwsIEkgYW0gd29uZGVyaW5nIChhbmQgaGF2ZW4ndCB0aG91Z2h0
IHRocm91Z2gpIGFib3V0IGV4cGVyaW1lbnRhbCBzcGFjZSB2cyBub24tZXhwZXJpbWVudGFsIChm
b3IgbWVzc2FnZSB0eXBlcywgYW5kIGNvbnNlcXVlbnRseSBmb3IgbWVzc2FnZSB0eXBlIHNwZWNp
ZmljIFRMViB0eXBlcykuDQoNCkkgdGhpbmsgdGhhdCBpZiB0aGUgQU9EVnYyIGV4cGVyaW1lbnQg
c3BlY2lmaWVzIHRoZSB1c2Ugb2YgTWVzc2FnZSB0eXBlcyBmcm9tIHRoZSBFeHBlcmltZW50YWwg
bWVzc2FnZSB0eXBlIHNwYWNlIHdpdGhvdXQgbWFraW5nIGFjdHVhbCByZWdpc3RyYXRpb25zIGlu
IHRoZSBJQU5BIHJlZ2lzdHJ5LCBBTkQgdGhlIHVzZSBvZiB0eXBlIHNwZWNpZmljIFRMViB0eXBl
cywgdGhpcyBiZWNvbWVzIGEgbm9uLWlzc3VlIGVudGlyZWx5IChieSBkZXNpZ24sIHRoaXMgaXMg
cHJlY2lzZWx5IHdoYXQgdGhhdCBleHBlcmltZW50YWwgc3BhY2UgaXMgZm9yKQ0KDQpXaGVyZWFz
LCBhcyB5b3UgcG9pbnQgb3V0LCB0aGUgYWx0ZXJuYXRpdmUgaXMgYSAiY2FuIG9wZW4gLSB3b3Jt
cyBldmVyeXdoZXJlIiBzaXR1YXRpb24gdGhhdCBJIHRoaW5rIHRpbWUgaXMgdG9vIHNob3J0IHRv
IHNvbHZlPw0KDQpUaG9tYXMNCg0KDQo+IFRoZW4geW91IGNvdWxkIHRyeSBzcGVjaWZ5aW5nIGl0
LiBCdXQgd2l0aCBhIHZlcnkgZ29vZCBjaGFuY2Ugb2YgcHJvZHVjaW5nIHNvbWV0aGluZyB5b3Ug
bGF0ZXIgZGVjaWRlIHlvdSBzaG91bGQgaGF2ZSBkb25lIGRpZmZlcmVudGx5Lg0KPg0KPiBJIGhv
bmVzdGx5IGRvbid0IGtub3cgd2hpY2ggd291bGQgZ28gZG93biBiZXR0ZXIgKG9yIGxlc3MgYmFk
bHkpIC0gImhlcmUncyBhIG1lY2hhbmlzbSB3ZSBoYXZlbid0IHJlYWxseSB0aG91Z2h0IHRocm91
Z2ggaW4gZGV0YWlsLCBidXQgYXQgbGVhc3Qgd2UndmUgZGVmaW5lZCBvbmUiLCBvciAid2Uga25v
dyB0aGUgc29ydCBvZiB0aGluZyB3ZSB3YW50LCBhbmQgd2UnbGwgZGVzY3JpYmUgaXQsIGJ1dCBy
YXRoZXIgdGhhbiBwcm9kdWNlIHNvbWV0aGluZyBub3QgcXVpdGUgcmlnaHQsIHdlJ2xsIG5vdCBn
byBmdXJ0aGVyIi4NCj4NCj4gLS0NCj4gQ2hyaXN0b3BoZXIgRGVhcmxvdmUNCj4gU2VuaW9yIFBy
aW5jaXBhbCBFbmdpbmVlcg0KPiBCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJv
cmF0b3JpZXMNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4gVDogICs0NCAoMCkxMjQ1IDI0MjE5
NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4gIHwgIEU6IGNocmlzLmRlYXJsb3Zl
QGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCj4N
Cj4gQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9n
eSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQo+IHd3dy5i
YWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KPiBCQUUgU3lz
dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQo+IFJlZ2lzdGVyZWQgaW4gRW5nbGFu
ZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KPiBSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2Vh
cmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQo+DQo+DQo+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExvdHRlIFN0ZWVuYnJpbmsgW21haWx0bzpsb3R0ZS5z
dGVlbmJyaW5rQGZ1LWJlcmxpbi5kZTxtYWlsdG86bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4u
ZGU+XQ0KPiBTZW50OiAyMiBBcHJpbCAyMDE2IDEzOjU5DQo+IFRvOiBNb2JpbGUgQWQgSG9jIE5l
dHdvcmtzIG1haWxpbmcgbGlzdA0KPiBDYzogSGVubmluZyBSb2dnZTsgRGVhcmxvdmUsIENocmlz
dG9waGVyIChVSykNCj4gU3ViamVjdDogUmU6IFttYW5ldF0gT24gRm9yd2FyZGluZy1hbmQtcmVn
ZW5lcmF0aW9uICh3YXM6IFJlOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBh
IGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKQ0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
ISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRl
cyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwg
cGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4NCj4gQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRo
ZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9y
IHJlcGx5Lg0KPiBGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24g
SVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWls
IG1lc3NhZ2VzLg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KPg0KPiBIZWxsbyBDaHJpc3RvcGhlciwNCj4NCj4+IEFtIDIyLjA0LjIw
MTYgdW0gMTE6NTcgc2NocmllYiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVh
cmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t
Pj46DQo+Pg0KPj4gSnVzdCBiZSBjYXJlZnVsIHRvIG5vdGUgdGhhdCB0aGlzIGNvbmNlcHQgaXMg
YXMgY3VycmVudGx5IGJlaW5nIGRpc2N1c3NlZCAoYSkgc3BlY2lmaWMgdG8gQU9EVnYyLCBhbmQg
KGIpIG5vdCBhbiBhcHBsaWNhdGlvbiBvZiA3MTgyLCB3aGljaCBoYXMgbm8ga25vd2xlZGdlIG9m
IHNwZWNpYWwgVExWcy4NCj4+DQo+PiBUaGlzIGlzIHNvbWV0aGluZyB3ZSdkIHdhbnQgdG8gZ2V0
IHJpZ2h0LCBhbmQgbmVlZCB0byBnZXQgcmlnaHQgaWYgaW4gYW55IHNwYWNlIG5vdCBzcGVjaWZp
YyB0byBBRE9EVnYyLCBiZWNhdXNlIGdldHRpbmcgaXQgd3JvbmcgcHJvZHVjZXMgZnV0dXJlIHBy
b2JsZW1zLg0KPg0KPiBNYWtlcyBzZW5zZS4NCj4NCj4+IEkgY2FuIHNlZSBzb21lIHBvc3NpYmxl
IGFwcHJvYWNoZXMsIG5vbmUgaXMgaWRlYWwgYW5kIHdlJ3JlIHJhdGhlciBvdXQNCj4+IG9mIHRp
bWUgdG8gc3BlY2lmeS4gQnV0IHRoaXMgaXMgZXhwZXJpbWVudGFsLCBzbyBJIHRoaW5rIHdlIG1p
Z2h0IGJlDQo+PiBhYmxlIHRvIGluZGljYXRlIHRoZSBzaGFwZSBvZiB0aGUgc29sdXRpb24gd2l0
aG91dCBzcGVjaWZ5aW5nIGl0LA0KPj4gd2hpY2ggd291bGQgYmUgYSBkaWZmZXJlbnQgUkZDLCB1
bmRlciBhIGJpdCBsZXNzIHRpbWUgcHJlc3N1cmUuDQo+PiAoRXh0ZW5zaW9ucyB0byBleGlzdGlu
ZyBwcm90b2NvbHMgbGlrZSA3MTgyIHdvdWxkIG5hdHVyYWxseSBiZSBpbg0KPj4gc2NvcGUgcmVj
aGFydGVyZWQgSSB0aGluay4pDQo+Pg0KPj4gVG8gaW5kaWNhdGUgdGhlIHJhbmdlIHRoYXQncyBv
cGVuLCBoZXJlIGFyZSB0d28gcG9zc2libGUgaWRlYXMsIG9uZSBvZiB3aGljaCBoYXMgYW4gaW1w
YWN0IG5vdywgc28gbmVlZHMgdG8gYmUgYWdyZWVkLiBOb3RlIHRoYXQgSSdtIG5vdCBzdWdnZXN0
aW5nIChpbiBmYWN0IHF1aXRlIHRoZSBvcHBvc2l0ZSkgZGVmaW5pbmcgYW4gZXh0ZW5zaW9uIHRv
IDcxODIgaGVyZSwgcmF0aGVyIGVuYWJsaW5nIHN1Y2ggYW4gZXh0ZW5zaW9uLCBpZiB3cml0dGVu
LCB0byAiZG8gdGhlIHJpZ2h0IHRoaW5nIi4NCj4+IC0gV2UgaGF2ZSBhbiBleHRlbnNpb24gdG8g
NzE4MiB0aGF0IHNheXMgInplcm8gb3V0IGFsbCB2YWx1ZSBvY3RldHMgaW4gcHJvdG9jb2wgc3Bl
Y2lmaWMgVExWcy4gVGhhdCByZXF1aXJlcyBub3cgcHV0dGluZyB0aGUgQU9EVnYyIG1ldHJpYyBU
TFYgaW4gdGhhdCBzcGFjZS4NCj4NCj4gSnVzdCB0byBtYWtlIHN1cmUgdGhhdCBJIHVuZGVyc3Rv
b2QgeW91IGNvcnJlY3RseeKAkyDigJx0aGF0IHNwYWNl4oCdIG1lYW5pbmcgbWFraW5nIHRoZSBB
T0RWdjIgbWV0cmljIFRMViBwcm90b2NvbCBzcGVjaWZpYz8gKEJ5IOKAnHRoZSBhb2R2djIgbWV0
cmljIHRsduKAnSBJ4oCZbSByZWZlcnJpbmcgdG8gdGhlIGdlbmVyaWMgVExWIHdl4oCZdmUgYmVl
biB0YWxraW5nIGFib3V0IG9uIHRoaXMgbGlzdCBlYXJsaWVyIHRoaXMgd2VlaykuDQo+DQo+PiAt
IFdlIGhhdmUgYW4gZXh0ZW5zaW9uIHRvIDcxODIgdGhhdCBhZGRzIGV4dHJhIG1hdGVyaWFsIHRv
IHRoZSB2YWx1ZSBmaWVsZCB0aGF0IGluZGljYXRlcyAoVEJEIGhvdywgYnkgcG9zaXRpb24gd2l0
aCBzYW5pdHkgY2hlY2sgdGhhdCB0aGlzIGlzIFRMViB2YWx1ZSBwZXJoYXBzPykgd2hpY2ggb2N0
ZXRzIGFyZSB0byBiZSB6ZXJvZWQgb3V0IGJlZm9yZSB0aGUgSUNWIGlzIGNhbGN1bGF0ZWQuDQo+
DQo+IFRoZSB3YXkgSSB1bmRlcnN0YW5kIHRoYXQgYXBwcm9hY2gsIGl0IHdvdWxkbuKAmXQgd2Fy
cmFudCBhbnkgYWN0aW9uIGZyb20gQU9EVnYyIGJlc2lkZXMgc2F5aW5nIOKAnGlmIHlvdSBjYWxj
dWxhdGUgdGhlIElDViwgc2V0IHRoZSBNZXRyaWMgdmFsdWUgdG8gemVyb+KAnSAobGVhdmluZyB0
aGUgbml0dHkgZ3JpdHR5IG9mIGhvdyB0aGlzIHdvdWxkIGJlIGRvbmUgaW4gZGV0YWlsIHRvIGZ1
dHVyZSB3b3JrKeKApiBJcyB0aGF0IGNvcnJlY3Q/DQo+DQo+Pg0KPj4gV2UgZG8gbm90IGhhdmUg
dGhlIHRpbWUgdG8gc3BlY2lmeSB0aGlzIGluIGFuIGFjY2VwdGFibGUgbWFubmVyIHdpdGhpbiB0
d28gd2Vla3MgdGhvdWdoLiBCdXQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBj
b3VsZCBzYXkgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiAidGhpcyBlbmFibGVzIHRoZSB1
c2Ugb2YgYW4gSUNWIGRlZmluZWQgdG8gemVybyBvdXQgdGhlc2Ugb2N0ZXRz4oCcLg0KPg0KPiBP
a2F5LiA6KQ0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+IExvdHRlDQo+DQo+Pg0KPj4gLS0NCj4+IENo
cmlzdG9waGVyIERlYXJsb3ZlDQo+PiBTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQo+PiBCQUUg
U3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCj4+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4+IF9fX18NCj4+DQo+PiBUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5k
ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j
b20+DQo+Pg0KPj4gQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQg
VGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4u
DQo+PiB3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4N
Cj4+IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQgUmVnaXN0ZXJlZCBp
biBFbmdsYW5kICYgV2FsZXMNCj4+IE5vOiAwMTMzNzQ1MSBSZWdpc3RlcmVkIE9mZmljZTogU3Vy
cmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwNCj4+IFN1cnJleSwgR1UyIDdZUA0KPj4NCj4+
IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0
LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhh
bGYgT2YgTG90dGUNCj4+IFN0ZWVuYnJpbmsNCj4+IFNlbnQ6IDIyIEFwcmlsIDIwMTYgMTA6MjgN
Cj4+IFRvOiBIZW5uaW5nIFJvZ2dlDQo+PiBDYzogTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWls
aW5nIGxpc3QNCj4+IFN1YmplY3Q6IFJlOiBbbWFuZXRdIE9uIEZvcndhcmRpbmctYW5kLXJlZ2Vu
ZXJhdGlvbiAod2FzOiBSZToNCj4+IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAt
IGEgY291cGxlIG9mIGJpZyB0aWNrZXQgSXRlbXMpDQo+Pg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdp
bmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVy
bmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuDQo+PiBDb25zaWRlciBjYXJlZnVsbHkg
d2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVu
dHMgb3IgcmVwbHkuDQo+PiBGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxp
bmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3Vz
IGVtYWlsIG1lc3NhZ2VzLg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+PiAqKiogV0FSTklORyAqKioNCj4+IEVYVEVSTkFM
IEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5p
emF0aW9uLg0KPj4NCj4+DQo+PiBIaSBIZW5uaW5nLA0KPj4NCj4+PiBBbSAyMi4wNC4yMDE2IHVt
IDExOjA4IHNjaHJpZWIgSGVubmluZyBSb2dnZSA8aHJvZ2dlQGdtYWlsLmNvbTxtYWlsdG86aHJv
Z2dlQGdtYWlsLmNvbT4+Og0KPj4+DQo+Pj4gT24gRnJpLCBBcHIgMjIsIDIwMTYgYXQgMTE6MDUg
QU0sIExvdHRlIFN0ZWVuYnJpbmsNCj4+PiA8bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4uZGU8
bWFpbHRvOmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRlPj4gd3JvdGU6DQo+Pj4+IEhpIFRo
b21hcywNCj4+Pj4gQ2FuIGl0PyEgSWlyYywgdGhlIHJlYXNvbiB3aHkgd2UgYWRvcHRlZCB0aGUg
4oCccmVnZW5lcmF0aW9u4oCdIGxhbmd1YWdlDQo+Pj4+IGluIHRoZSBmaXJzdCBwbGFjZSBpcyB0
aGF0IHdl4oCZdmUgYmVlbiB0b2xkIHRoYXQgd2hlbmV2ZXIgb25lIGJpdCBpbg0KPj4+PiB0aGUg
bWVzc2FnZSAoYXBhcnQgZnJvbSBpdHMgaGVhZGVyKSBpcyBjaGFuZ2VkLCB0aGUgZW50aXJlIHRo
aW5nIGhhcyB0byBiZSByZWdlbmVyYXRlZC4NCj4+Pj4gSeKAmW0gc3RhcnRpbmcgdG8gZ2V0IHRo
ZSBmZWVsaW5nIHdl4oCZdmUganVzdCBiZWVuIG1pc3VuZGVyc3RhbmRpbmcNCj4+Pj4gZWFjaCBv
dGhlciBmb3IgbW9yZSB0aGFuIGEgeWVhci4gOiggQW55d2F5LCBpdCBzZWVtcyBsaWtlIHdl4oCZ
cmUNCj4+Pj4gZ2V0dGluZyBjbG9zZSBub3csIHNvIHlheS4NCj4+Pg0KPj4+ICJNb2RpZnlpbmci
IHRoZSBiaW5hcnkgbWVzc2FnZSBpbnN0ZWFkIG9mIHBhcnNpbmcgYW5kIGdlbmVyYXRpbmcgYQ0K
Pj4+IG5ldyBvbmUgd2lsbCBiZSBkaWZmaWN1bHQgYXMgc29vbiBzb21lb25lIHdyaXRlcyBhbiBl
eHRlbnNpb24gdG8NCj4+PiBBT0RWdjIgdGhhdCBhZGRzIG1vcmUgVExWcyB0byB0aGUgbWVzc2Fn
ZS4NCj4+DQo+PiBE4oCZb2gsIHJpZ2h0LiBZZWFoLCBpZiBJIHJlbWVtYmVyIGl0IGNvcnJlY3Rs
eSwgdGhhdOKAmXMgd2hhdCB5b3UgZXhwbGFpbmVkIHRvIG1lIHdoZW4gSSBnb3QgY29uZnVzZWQg
YWJvdXQgdGhlIHRvcGljIGxhc3Qgc3ByaW5n4oCmIEJ1dOKAkyBldmVuIGlmIGEgbWVzc2FnZSBj
b250YWlucyBUTFZzIHRoYXQgdGhlIEFPRFZ2MiBpbXBsZW1lbnRhdGlvbiBoYW5kbGluZyBpdCBk
b2VzbuKAmXQgdW5kZXJzdGFuZCwgaXQgd2lsbCBzdGlsbCBiZSBhYmxlIHRvIHJlY29nbml6ZSB0
aGUgTWV0cmljIFRMViwgcmlnaHQ/IElzbuKAmXQgdGhhdCB0aGUgbmlmdHkgdGhpbmcgYWJvdXQg
UkZDNTQ0ND8gU28sIHdoaWxlIHdlIHJlYWxseSBzaG91bGRu4oCZdCB3cml0ZSDigJxiZWZvcmUg
Y2FsY3VsYXRpbmcgdGhlIElDViwgc2V0IHRoZSBuLXRoIDQgb2N0ZXRzIHRvIDDigJ0sIHdlIG1p
Z2h0IHNheSDigJxpZGVudGlmeSB0aGUgb2N0ZXRzIHRoYXQgbWFrZSB1cCB0aGUgbWV0cmljIHZh
bHVlIGFuZCBzZXQgdGhvc2UgdG8gMOKAnT8NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBMb3R0
ZQ0KPj4NCj4+PiBIZW5uaW5nIFJvZ2dlDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4+IG1hbmV0IG1haWxpbmcgbGlzdA0KPj4gbWFuZXRA
aWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9tYW5ldA0KPj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+IFRoaXMgZW1haWwgYW5k
IGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZA0KPj4gcmVj
aXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50
ZW5kZWQNCj4+IHJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5k
IG5vdGlmeSB0aGUgc2VuZGVyLg0KPj4gWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQg
Zm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcg0KPj4gZGlzdHJpYnV0ZSBpdHMgY29udGVu
dHMgdG8gYW55IG90aGVyIHBlcnNvbi4NCj4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+DQo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1hbmV0IG1haWxpbmcgbGlz
dA0KPiBtYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0
Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9tYW5ldA0KDQo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B0E81GLKXM0002VGREEN_
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
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0
YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt
c2VyaWYiO30NCnNwYW4uaW0NCgl7bXNvLXN0eWxlLW5hbWU6aW07fQ0Kc3Bhbi5CYWxsb29uVGV4
dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1p
bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30N
CnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv
Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBw
YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0
IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj
dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm
YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv
OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh
W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5r
PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhhdmUgbm8g
cHJvYmxlbSB3aXRoIHRoYXQuIEkgd2FzIHRyeWluZyB0byBsYXkgb3V0IHRoZSBpc3N1ZXMgd2l0
aG91dCBtdWRkeWluZyB0aGUgd2F0ZXIgd2l0aCBteSBwcmVmZXJlbmNlLjxvOnA+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+IEp1c3RpbiBEZWFuIFttYWlsdG86YmViZW1hc3RlckBnbWFpbC5jb21dDQo8YnI+DQo8
Yj5TZW50OjwvYj4gMjIgQXByaWwgMjAxNiAxNTozNTxicj4NCjxiPlRvOjwvYj4gRGVhcmxvdmUs
IENocmlzdG9waGVyIChVSyk8YnI+DQo8Yj5DYzo8L2I+IFRob21hcyBIZWlkZSBDbGF1c2VuOyBN
b2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBS
ZTogW21hbmV0XSBPbiBGb3J3YXJkaW5nLWFuZC1yZWdlbmVyYXRpb24gKHdhczogUmU6IGRyYWZ0
LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEgY291cGxlIG9mIGJpZyB0aWNrZXQgSXRl
bXMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGlu
ZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i
Y2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7
YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMz
OTcyIj4qKiogV0FSTklORyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdp
bmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVy
bmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBj
YXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkg
YXR0YWNobWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3Ig
aW5mb3JtYXRpb24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxp
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9p
Pjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0
aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8
YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1
cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwvYT4uPC9z
cGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+
DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVh
c2UgZm9sbG93DQo8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hv
d3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1
c3BpY2lvdXMlMjBFbWFpbHMucGRmIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9z
cGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+U3BlYWtpbmcgYXMgcGFydGljaXBhbnQuPGJyPg0KPGJyPg0KSSBraW5kIG9mIGxpa2UgdGhl
IGlkZWEgb2YgdXNpbmcgdGhlIGV4cGVyaW1lbnRhbCBtZXNzYWdlIHR5cGUgc3BhY2UuJm5ic3A7
IFdlIG9ubHkgaGF2ZSBhIGxpbWl0ZWQgYW1vdW50IG9mIHRoZXNlIG1lc3NhZ2UgdHlwZXMuJm5i
c3A7IFRoZSBUTFYgYXNzaWdubWVudHMgY291bGQganVzdCB1c2UgdGhlIG1lc3NhZ2UgdHlwZSBz
cGVjaWZpYyBzcGFjZSBhbmQgdGhlcmUgaXNuJ3QgYW4gaXNzdWUgdGhlcmUuJm5ic3A7IElBTkEg
d291bGRuJ3QgYXNzaWduIGEgbnVtYmVyIGJ1dA0KIEkgZG9uJ3Qgc2VlIHdoeSB0aGUgZG9jdW1l
bnQgY291bGRuJ3Qgc3BlY2lmeSB0aGUgZXhwZXJpbWVudGFsIG51bWJlcnMgaXQgd2FzIGdvaW5n
IHRvIHVzZSBzbyBvdGhlciBmdXR1cmUgbmVhciB0ZXJtIGV4cGVyaWVudGlhbCBwcm90b2NvbHMg
Y291bGQgZG8gdGhlIHNhbWUgYW5kIGdlbmVyYWxseSBhdm9pZCBjb25mbGljdC4mbmJzcDsgSWYg
dGhlIGV4cGVyaW1lbnQgaXMgc3VjY2Vzc2Z1bCBJQU5BIGFzc2lnbm1lbnRzIGNvdWxkIGJlIG1h
ZGUuJm5ic3A7IEZ1bmN0aW9uYWxseQ0KIG5vIHJlYWwgZGlmZmVyZW5jZSB3aXRoIHByb3RlY3Rp
b25zIHZzIGxvbmcgdGVybSB1c2FnZSBvZiBsaW1pdGVkIHNwYWNlLjxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdGluPG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBcHIgMjIsIDIwMTYgYXQgOTozNSBBTSwgRGVhcmxv
dmUsIENocmlzdG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBi
YWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu
Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U
aGVyZSdzIHJhdGhlciBhIGNvbnRyYWRpY3Rpb24gYmV0d2VlbiB0aGUgY29uY2VwdHMgb2YgYSBk
ZWZpbml0aW9uIG9mIGEgcHJvdG9jb2wsIGV2ZW4gRXhwZXJpbWVudGFsLCBhbmQgZXhwZXJpbWVu
dGFsIHNwYWNlLCB3aGljaCB1c3VhbGx5IGFzc3VtZXMgdGhhdCB0aGUgdXNlciBjYW4gZG8gd2hh
dCBoZSBvciBzaGUgbGlrZXMgaW4gaXQuPGJyPg0KPGJyPg0KQnV0IGNoZXdpbmcgdXAgbWVzc2Fn
ZXMgdHlwZXMgKGhvdyBtYW55LCAzPykgb2Ygd2hpY2ggdGhlcmUgYXJlIHJlbGF0aXZlbHkgZmV3
IGZvciBleHBlcmltZW50YWwgaXMgbG9uZyB0ZXJtIGEgcHJvYmxlbSwgYWx0aG91Z2ggc2hvcnQg
dGVybSBub3QuPGJyPg0KPGJyPg0KVExWIHNwYWNlIGlzIGVhc2llciBpbiB0d28gcmVnYXJkcy4g
SXQncyBiaWdnZXIgKHRob3VnaCB0aGUgcHJpbWUgcmVhbCBlc3RhdGUgb2YgdHlwZSBleHRlbnNp
b24gemVybyBpc24ndCkgYW5kIGNhbiBoYXZlIG1lc3NhZ2UgdHlwZSBzcGVjaWZpYyBUTFZzLjxi
cj4NCjxicj4NClNvIFRMVlMgY2FuIGFjdHVhbGx5IGJlIGludmlzaWJsZSwgaWYgdGhhdCBvcHRp
b24gaXMgY2hvc2VuLiBGb3IgbWVzc2FnZXMgc29tZXRoaW5nIGhhcyB0byBnaXZlLiBMZWFzdCBi
YWQgb3B0aW9uIGlzIGFnYWluIG9uZSBvZiB0aG9zZSB3ZSBzaG91bGQgZGlzY3VzcywgYnV0IHRp
bWUgLi4uPGJyPg0KPGJyPg0KKFRvIGJlIHByZWNpc2UsIG1lc3NhZ2VzIHR5cGVzIGZyb20gMjI0
IGFyZSBkZWZpbmVkIGluIFJGQyA1NDQ0IGFzICZxdW90OyBFeHBlcmltZW50YWwgVXNlJnF1b3Q7
LCBvZiB3aGljaCBCQ1AgMjYgc2F5cyAmcXVvdDtTaW1pbGFyIHRvIHByaXZhdGUgb3IgbG9jYWwg
dXNlIG9ubHksIHdpdGggdGhlJm5ic3A7IHB1cnBvc2UgYmVpbmcgdG8gZmFjaWxpdGF0ZSBleHBl
cmltZW50YXRpb24uJnF1b3Q7IFRoZSBhbHRlcm5hdGl2ZSAwLTIyMyBzcGFjZSBpcyBFeHBlcnQg
UmV2aWV3LiBJQU5BIHN0aWxsDQogdGhpbmtzIHRoZSBleHBlcnRzIGFyZSBKb2UgTWFja2VyIGFu
ZCB0aGUgcmVjdXNlZCBTdGFuIFJhdGxpZmYuIEJ1dCB0aGF0J3MgYSBzb2x1YmxlIG5pdC4pPGJy
Pg0KPGJyPg0KPHNwYW4gY2xhc3M9ImltIj4tLTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0i
PkNocmlzdG9waGVyIERlYXJsb3ZlPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+U2VuaW9y
IFByaW5jaXBhbCBFbmdpbmVlcjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPkJBRSBTeXN0
ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczwvc3Bhbj48YnI+DQo8c3BhbiBj
bGFzcz0iaW0iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIGNsYXNz
PSJpbSI+VDogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQi
PiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8L2E+ICZuYnNwO3wgJm5ic3A7RToNCjxhIGhyZWY9Im1h
aWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lz
dGVtcy5jb208L2E+PC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+QkFFIFN5c3Rl
bXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVh
dCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPC9zcGFuPjxicj4NCjxzcGFuIGNs
YXNzPSJpbSI+PGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJf
YmxhbmsiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvYT48L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9
ImltIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPC9zcGFuPjxicj4N
CjxzcGFuIGNsYXNzPSJpbSI+UmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAw
MTMzNzQ1MTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPlJlZ2lzdGVyZWQgT2ZmaWNlOiBT
dXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8L3NwYW4+PGJy
Pg0KPGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImltIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPkZyb206IFRob21hcyBIZWlkZSBDbGF1c2Vu
IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmciPmlldGZAdGhv
bWFzY2xhdXNlbi5vcmc8L2E+XTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPlNlbnQ6IDIy
IEFwcmlsIDIwMTYgMTQ6MjE8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj5UbzogRGVhcmxv
dmUsIENocmlzdG9waGVyIChVSyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNjOiBMb3R0ZSBTdGVlbmJyaW5rOyBNb2JpbGUgQWQgSG9j
IE5ldHdvcmtzIG1haWxpbmcgbGlzdDxicj4NClN1YmplY3Q6IFJlOiBbbWFuZXRdIE9uIEZvcndh
cmRpbmctYW5kLXJlZ2VuZXJhdGlvbiAod2FzOiBSZTogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djIt
MTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcyk8YnI+DQo8YnI+DQotLS0t
LS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlz
IG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVy
IGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC48YnI+DQpDb25z
aWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3Bl
biBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPGJyPg0KRm9sbG93IHRoZSAnUmVwb3J0IFN1c3Bp
Y2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBvbiByZXBv
cnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCjxicj4NCiZn
dDsgT24gMjIgYXZyLiAyMDE2LCBhdCAxNTowNSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykg
Jmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMu
ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0
OyBPbmNlIHlvdSdyZSBlbnRpcmVseSBpbiBBT0RWMidzIG93biBzcGFjZSwgYW5kIEFPRFZ2MiBp
cyBleHBlcmltZW50YWwgKHdvcmtpbmcgYXNzdW1wdGlvbiBmb3IgdGhpcyBkaXNjdXNzaW9uKSB5
b3UgaGF2ZSBtb3JlIGxpYmVydHkuPGJyPg0KJmd0Ozxicj4NCjxicj4NClllcC48YnI+DQo8YnI+
DQpUYWtlbiBzb21ld2hhdCBieSBzdXJwcmlzZSBib3RoIGJ5IHRoZSBzdWRkZW4gJnF1b3Q7cnVz
aCZxdW90OyBhbmQgdGhlIGV4cGVyaW1lbnRhbCBtYXR1cml0eSBsZXZlbCwgSSBhbSB3b25kZXJp
bmcgKGFuZCBoYXZlbid0IHRob3VnaHQgdGhyb3VnaCkgYWJvdXQgZXhwZXJpbWVudGFsIHNwYWNl
IHZzIG5vbi1leHBlcmltZW50YWwgKGZvciBtZXNzYWdlIHR5cGVzLCBhbmQgY29uc2VxdWVudGx5
IGZvciBtZXNzYWdlIHR5cGUgc3BlY2lmaWMgVExWIHR5cGVzKS48YnI+DQo8YnI+DQpJIHRoaW5r
IHRoYXQgaWYgdGhlIEFPRFZ2MiBleHBlcmltZW50IHNwZWNpZmllcyB0aGUgdXNlIG9mIE1lc3Nh
Z2UgdHlwZXMgZnJvbSB0aGUgRXhwZXJpbWVudGFsIG1lc3NhZ2UgdHlwZSBzcGFjZSB3aXRob3V0
IG1ha2luZyBhY3R1YWwgcmVnaXN0cmF0aW9ucyBpbiB0aGUgSUFOQSByZWdpc3RyeSwgQU5EIHRo
ZSB1c2Ugb2YgdHlwZSBzcGVjaWZpYyBUTFYgdHlwZXMsIHRoaXMgYmVjb21lcyBhIG5vbi1pc3N1
ZSBlbnRpcmVseSAoYnkgZGVzaWduLA0KIHRoaXMgaXMgcHJlY2lzZWx5IHdoYXQgdGhhdCBleHBl
cmltZW50YWwgc3BhY2UgaXMgZm9yKTxicj4NCjxicj4NCldoZXJlYXMsIGFzIHlvdSBwb2ludCBv
dXQsIHRoZSBhbHRlcm5hdGl2ZSBpcyBhICZxdW90O2NhbiBvcGVuIC0gd29ybXMgZXZlcnl3aGVy
ZSZxdW90OyBzaXR1YXRpb24gdGhhdCBJIHRoaW5rIHRpbWUgaXMgdG9vIHNob3J0IHRvIHNvbHZl
Pzxicj4NCjxicj4NClRob21hczxicj4NCjxicj4NCjxicj4NCiZndDsgVGhlbiB5b3UgY291bGQg
dHJ5IHNwZWNpZnlpbmcgaXQuIEJ1dCB3aXRoIGEgdmVyeSBnb29kIGNoYW5jZSBvZiBwcm9kdWNp
bmcgc29tZXRoaW5nIHlvdSBsYXRlciBkZWNpZGUgeW91IHNob3VsZCBoYXZlIGRvbmUgZGlmZmVy
ZW50bHkuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBob25lc3RseSBkb24ndCBrbm93IHdoaWNoIHdv
dWxkIGdvIGRvd24gYmV0dGVyIChvciBsZXNzIGJhZGx5KSAtICZxdW90O2hlcmUncyBhIG1lY2hh
bmlzbSB3ZSBoYXZlbid0IHJlYWxseSB0aG91Z2h0IHRocm91Z2ggaW4gZGV0YWlsLCBidXQgYXQg
bGVhc3Qgd2UndmUgZGVmaW5lZCBvbmUmcXVvdDssIG9yICZxdW90O3dlIGtub3cgdGhlIHNvcnQg
b2YgdGhpbmcgd2Ugd2FudCwgYW5kIHdlJ2xsIGRlc2NyaWJlIGl0LCBidXQgcmF0aGVyIHRoYW4g
cHJvZHVjZSBzb21ldGhpbmcNCiBub3QgcXVpdGUgcmlnaHQsIHdlJ2xsIG5vdCBnbyBmdXJ0aGVy
JnF1b3Q7Ljxicj4NCiZndDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBDaHJpc3RvcGhlciBEZWFy
bG92ZTxicj4NCiZndDsgU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCiZndDsgQkFFIFN5
c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KJmd0OyBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCiZndDs8YnI+DQomZ3Q7IFQ6Jm5ic3A7IDxhIGhyZWY9InRlbDolMkI0
NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0Ij4mIzQzOzQ0ICgwKTEyNDUgMjQyMTk0PC9hPiZuYnNw
OyB8Jm5ic3A7IEU6IDxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNv
bSI+DQpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0
OyBCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5
IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQomZ3Q7
IDxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj53
d3cuYmFlc3lzdGVtcy5jb20vYWk8L2E+PGJyPg0KJmd0OyBCQUUgU3lzdGVtcyBBcHBsaWVkIElu
dGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KJmd0OyBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsg
V2FsZXMgTm86IDAxMzM3NDUxPGJyPg0KJmd0OyBSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJl
c2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPGJyPg0KJmd0Ozxicj4NCiZn
dDs8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBM
b3R0ZSBTdGVlbmJyaW5rIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmxvdHRlLnN0ZWVuYnJpbmtA
ZnUtYmVybGluLmRlIj5sb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZTwvYT5dPGJyPg0KJmd0
OyBTZW50OiAyMiBBcHJpbCAyMDE2IDEzOjU5PGJyPg0KJmd0OyBUbzogTW9iaWxlIEFkIEhvYyBO
ZXR3b3JrcyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IENjOiBIZW5uaW5nIFJvZ2dlOyBEZWFybG92
ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4NCiZndDsgU3ViamVjdDogUmU6IFttYW5ldF0gT24gRm9y
d2FyZGluZy1hbmQtcmVnZW5lcmF0aW9uICh3YXM6IFJlOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2
Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKTxicj4NCiZndDs8YnI+
DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0
aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVybmV0
Ljxicj4NCiZndDsgQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBv
biBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljxicj4NCiZndDsgRm9s
bG93IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9y
IGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy48YnI+
DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tPGJyPg0KJmd0Ozxicj4NCiZndDsgSGVsbG8gQ2hyaXN0b3BoZXIsPGJyPg0KJmd0Ozxi
cj4NCiZndDsmZ3Q7IEFtIDIyLjA0LjIwMTYgdW0gMTE6NTcgc2NocmllYiBEZWFybG92ZSwgQ2hy
aXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl
bXMuY29tIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsm
Z3Q7PGJyPg0KJmd0OyZndDsgSnVzdCBiZSBjYXJlZnVsIHRvIG5vdGUgdGhhdCB0aGlzIGNvbmNl
cHQgaXMgYXMgY3VycmVudGx5IGJlaW5nIGRpc2N1c3NlZCAoYSkgc3BlY2lmaWMgdG8gQU9EVnYy
LCBhbmQgKGIpIG5vdCBhbiBhcHBsaWNhdGlvbiBvZiA3MTgyLCB3aGljaCBoYXMgbm8ga25vd2xl
ZGdlIG9mIHNwZWNpYWwgVExWcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoaXMgaXMg
c29tZXRoaW5nIHdlJ2Qgd2FudCB0byBnZXQgcmlnaHQsIGFuZCBuZWVkIHRvIGdldCByaWdodCBp
ZiBpbiBhbnkgc3BhY2Ugbm90IHNwZWNpZmljIHRvIEFET0RWdjIsIGJlY2F1c2UgZ2V0dGluZyBp
dCB3cm9uZyBwcm9kdWNlcyBmdXR1cmUgcHJvYmxlbXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgTWFr
ZXMgc2Vuc2UuPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IEkgY2FuIHNlZSBzb21lIHBvc3NpYmxl
IGFwcHJvYWNoZXMsIG5vbmUgaXMgaWRlYWwgYW5kIHdlJ3JlIHJhdGhlciBvdXQ8YnI+DQomZ3Q7
Jmd0OyBvZiB0aW1lIHRvIHNwZWNpZnkuIEJ1dCB0aGlzIGlzIGV4cGVyaW1lbnRhbCwgc28gSSB0
aGluayB3ZSBtaWdodCBiZTxicj4NCiZndDsmZ3Q7IGFibGUgdG8gaW5kaWNhdGUgdGhlIHNoYXBl
IG9mIHRoZSBzb2x1dGlvbiB3aXRob3V0IHNwZWNpZnlpbmcgaXQsPGJyPg0KJmd0OyZndDsgd2hp
Y2ggd291bGQgYmUgYSBkaWZmZXJlbnQgUkZDLCB1bmRlciBhIGJpdCBsZXNzIHRpbWUgcHJlc3N1
cmUuPGJyPg0KJmd0OyZndDsgKEV4dGVuc2lvbnMgdG8gZXhpc3RpbmcgcHJvdG9jb2xzIGxpa2Ug
NzE4MiB3b3VsZCBuYXR1cmFsbHkgYmUgaW48YnI+DQomZ3Q7Jmd0OyBzY29wZSByZWNoYXJ0ZXJl
ZCBJIHRoaW5rLik8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRvIGluZGljYXRlIHRoZSBy
YW5nZSB0aGF0J3Mgb3BlbiwgaGVyZSBhcmUgdHdvIHBvc3NpYmxlIGlkZWFzLCBvbmUgb2Ygd2hp
Y2ggaGFzIGFuIGltcGFjdCBub3csIHNvIG5lZWRzIHRvIGJlIGFncmVlZC4gTm90ZSB0aGF0IEkn
bSBub3Qgc3VnZ2VzdGluZyAoaW4gZmFjdCBxdWl0ZSB0aGUgb3Bwb3NpdGUpIGRlZmluaW5nIGFu
IGV4dGVuc2lvbiB0byA3MTgyIGhlcmUsIHJhdGhlciBlbmFibGluZyBzdWNoIGFuIGV4dGVuc2lv
biwgaWYgd3JpdHRlbiwNCiB0byAmcXVvdDtkbyB0aGUgcmlnaHQgdGhpbmcmcXVvdDsuPGJyPg0K
Jmd0OyZndDsgLSBXZSBoYXZlIGFuIGV4dGVuc2lvbiB0byA3MTgyIHRoYXQgc2F5cyAmcXVvdDt6
ZXJvIG91dCBhbGwgdmFsdWUgb2N0ZXRzIGluIHByb3RvY29sIHNwZWNpZmljIFRMVnMuIFRoYXQg
cmVxdWlyZXMgbm93IHB1dHRpbmcgdGhlIEFPRFZ2MiBtZXRyaWMgVExWIGluIHRoYXQgc3BhY2Uu
PGJyPg0KJmd0Ozxicj4NCiZndDsgSnVzdCB0byBtYWtlIHN1cmUgdGhhdCBJIHVuZGVyc3Rvb2Qg
eW91IGNvcnJlY3RseeKAkyDigJx0aGF0IHNwYWNl4oCdIG1lYW5pbmcgbWFraW5nIHRoZSBBT0RW
djIgbWV0cmljIFRMViBwcm90b2NvbCBzcGVjaWZpYz8gKEJ5IOKAnHRoZSBhb2R2djIgbWV0cmlj
IHRsduKAnSBJ4oCZbSByZWZlcnJpbmcgdG8gdGhlIGdlbmVyaWMgVExWIHdl4oCZdmUgYmVlbiB0
YWxraW5nIGFib3V0IG9uIHRoaXMgbGlzdCBlYXJsaWVyIHRoaXMgd2VlaykuPGJyPg0KJmd0Ozxi
cj4NCiZndDsmZ3Q7IC0gV2UgaGF2ZSBhbiBleHRlbnNpb24gdG8gNzE4MiB0aGF0IGFkZHMgZXh0
cmEgbWF0ZXJpYWwgdG8gdGhlIHZhbHVlIGZpZWxkIHRoYXQgaW5kaWNhdGVzIChUQkQgaG93LCBi
eSBwb3NpdGlvbiB3aXRoIHNhbml0eSBjaGVjayB0aGF0IHRoaXMgaXMgVExWIHZhbHVlIHBlcmhh
cHM/KSB3aGljaCBvY3RldHMgYXJlIHRvIGJlIHplcm9lZCBvdXQgYmVmb3JlIHRoZSBJQ1YgaXMg
Y2FsY3VsYXRlZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgd2F5IEkgdW5kZXJzdGFuZCB0aGF0
IGFwcHJvYWNoLCBpdCB3b3VsZG7igJl0IHdhcnJhbnQgYW55IGFjdGlvbiBmcm9tIEFPRFZ2MiBi
ZXNpZGVzIHNheWluZyDigJxpZiB5b3UgY2FsY3VsYXRlIHRoZSBJQ1YsIHNldCB0aGUgTWV0cmlj
IHZhbHVlIHRvIHplcm/igJ0gKGxlYXZpbmcgdGhlIG5pdHR5IGdyaXR0eSBvZiBob3cgdGhpcyB3
b3VsZCBiZSBkb25lIGluIGRldGFpbCB0byBmdXR1cmUgd29yaynigKYgSXMgdGhhdCBjb3JyZWN0
Pzxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFdlIGRvIG5vdCBoYXZlIHRo
ZSB0aW1lIHRvIHNwZWNpZnkgdGhpcyBpbiBhbiBhY2NlcHRhYmxlIG1hbm5lciB3aXRoaW4gdHdv
IHdlZWtzIHRob3VnaC4gQnV0IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHNlY3Rpb24gY291
bGQgc2F5IHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YgJnF1b3Q7dGhpcyBlbmFibGVzIHRo
ZSB1c2Ugb2YgYW4gSUNWIGRlZmluZWQgdG8gemVybyBvdXQgdGhlc2Ugb2N0ZXRz4oCcLjxicj4N
CiZndDs8YnI+DQomZ3Q7IE9rYXkuIDopPGJyPg0KJmd0Ozxicj4NCiZndDsgQmVzdCByZWdhcmRz
LDxicj4NCiZndDsgTG90dGU8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAt
LTxicj4NCiZndDsmZ3Q7IENocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KJmd0OyZndDsgU2VuaW9y
IFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCiZndDsmZ3Q7IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50
ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom
Z3Q7Jmd0OyBfX19fPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUOiZuYnNwOyAmIzQzOzQ0
ICgwKTEyNDUgMjQyMTk0Jm5ic3A7IHwmbmJzcDsgRTogPGEgaHJlZj0ibWFpbHRvOmNocmlzLmRl
YXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48
YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdl
bmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3Jk
LCBFc3NleCBDTTIgOEhOLjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lz
dGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L2E+PGJy
Pg0KJmd0OyZndDsgQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZCBSZWdp
c3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXM8YnI+DQomZ3Q7Jmd0OyBObzogMDEzMzc0NTEg
UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsPGJyPg0K
Jmd0OyZndDsgU3VycmV5LCBHVTIgN1lQPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7IEZyb206IG1hbmV0IFttYWlsdG86
PGEgaHJlZj0ibWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmciPm1hbmV0LWJvdW5jZXNAaWV0
Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTG90dGU8YnI+DQomZ3Q7Jmd0OyBTdGVlbmJyaW5rPGJy
Pg0KJmd0OyZndDsgU2VudDogMjIgQXByaWwgMjAxNiAxMDoyODxicj4NCiZndDsmZ3Q7IFRvOiBI
ZW5uaW5nIFJvZ2dlPGJyPg0KJmd0OyZndDsgQ2M6IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFp
bGluZyBsaXN0PGJyPg0KJmd0OyZndDsgU3ViamVjdDogUmU6IFttYW5ldF0gT24gRm9yd2FyZGlu
Zy1hbmQtcmVnZW5lcmF0aW9uICh3YXM6IFJlOjxicj4NCiZndDsmZ3Q7IGRyYWZ0LWlldGYtbWFu
ZXQtYW9kdnYyLTEzIHJldmlldyAtIGEgY291cGxlIG9mIGJpZyB0aWNrZXQgSXRlbXMpPGJyPg0K
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEg
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNp
ZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBm
cm9tIHRoZSBpbnRlcm5ldC48YnI+DQomZ3Q7Jmd0OyBDb25zaWRlciBjYXJlZnVsbHkgd2hldGhl
ciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3Ig
cmVwbHkuPGJyPg0KJmd0OyZndDsgRm9sbG93IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxz
JyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGlj
aW91cyBlbWFpbCBtZXNzYWdlcy48YnI+DQomZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0
OyZndDsgKioqIFdBUk5JTkcgKioqPGJyPg0KJmd0OyZndDsgRVhURVJOQUwgRU1BSUwgLS0gVGhp
cyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb24uPGJyPg0K
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEhpIEhlbm5pbmcsPGJyPg0KJmd0
OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQW0gMjIuMDQuMjAxNiB1bSAxMTowOCBzY2hyaWViIEhl
bm5pbmcgUm9nZ2UgJmx0OzxhIGhyZWY9Im1haWx0bzpocm9nZ2VAZ21haWwuY29tIj5ocm9nZ2VA
Z21haWwuY29tPC9hPiZndDs6PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE9u
IEZyaSwgQXByIDIyLCAyMDE2IGF0IDExOjA1IEFNLCBMb3R0ZSBTdGVlbmJyaW5rPGJyPg0KJmd0
OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4u
ZGUiPmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRlPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyBIaSBUaG9tYXMsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBDYW4gaXQ/ISBJ
aXJjLCB0aGUgcmVhc29uIHdoeSB3ZSBhZG9wdGVkIHRoZSDigJxyZWdlbmVyYXRpb27igJ0gbGFu
Z3VhZ2U8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGluIHRoZSBmaXJzdCBwbGFjZSBpcyB0aGF0IHdl
4oCZdmUgYmVlbiB0b2xkIHRoYXQgd2hlbmV2ZXIgb25lIGJpdCBpbjxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsgdGhlIG1lc3NhZ2UgKGFwYXJ0IGZyb20gaXRzIGhlYWRlcikgaXMgY2hhbmdlZCwgdGhl
IGVudGlyZSB0aGluZyBoYXMgdG8gYmUgcmVnZW5lcmF0ZWQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyBJ4oCZbSBzdGFydGluZyB0byBnZXQgdGhlIGZlZWxpbmcgd2XigJl2ZSBqdXN0IGJlZW4gbWlz
dW5kZXJzdGFuZGluZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgZWFjaCBvdGhlciBmb3IgbW9yZSB0
aGFuIGEgeWVhci4gOiggQW55d2F5LCBpdCBzZWVtcyBsaWtlIHdl4oCZcmU8YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7IGdldHRpbmcgY2xvc2Ugbm93LCBzbyB5YXkuPGJyPg0KJmd0OyZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsmZ3Q7ICZxdW90O01vZGlmeWluZyZxdW90OyB0aGUgYmluYXJ5IG1lc3NhZ2Ug
aW5zdGVhZCBvZiBwYXJzaW5nIGFuZCBnZW5lcmF0aW5nIGE8YnI+DQomZ3Q7Jmd0OyZndDsgbmV3
IG9uZSB3aWxsIGJlIGRpZmZpY3VsdCBhcyBzb29uIHNvbWVvbmUgd3JpdGVzIGFuIGV4dGVuc2lv
biB0bzxicj4NCiZndDsmZ3Q7Jmd0OyBBT0RWdjIgdGhhdCBhZGRzIG1vcmUgVExWcyB0byB0aGUg
bWVzc2FnZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IETigJlvaCwgcmlnaHQuIFllYWgs
IGlmIEkgcmVtZW1iZXIgaXQgY29ycmVjdGx5LCB0aGF04oCZcyB3aGF0IHlvdSBleHBsYWluZWQg
dG8gbWUgd2hlbiBJIGdvdCBjb25mdXNlZCBhYm91dCB0aGUgdG9waWMgbGFzdCBzcHJpbmfigKYg
QnV04oCTIGV2ZW4gaWYgYSBtZXNzYWdlIGNvbnRhaW5zIFRMVnMgdGhhdCB0aGUgQU9EVnYyIGlt
cGxlbWVudGF0aW9uIGhhbmRsaW5nIGl0IGRvZXNu4oCZdCB1bmRlcnN0YW5kLCBpdCB3aWxsIHN0
aWxsIGJlIGFibGUgdG8gcmVjb2duaXplDQogdGhlIE1ldHJpYyBUTFYsIHJpZ2h0PyBJc27igJl0
IHRoYXQgdGhlIG5pZnR5IHRoaW5nIGFib3V0IFJGQzU0NDQ/IFNvLCB3aGlsZSB3ZSByZWFsbHkg
c2hvdWxkbuKAmXQgd3JpdGUg4oCcYmVmb3JlIGNhbGN1bGF0aW5nIHRoZSBJQ1YsIHNldCB0aGUg
bi10aCA0IG9jdGV0cyB0byAw4oCdLCB3ZSBtaWdodCBzYXkg4oCcaWRlbnRpZnkgdGhlIG9jdGV0
cyB0aGF0IG1ha2UgdXAgdGhlIG1ldHJpYyB2YWx1ZSBhbmQgc2V0IHRob3NlIHRvIDDigJ0/PGJy
Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyZndDsgTG90
dGU8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBIZW5uaW5nIFJvZ2dlPGJyPg0KJmd0
OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCiZndDsmZ3Q7IG1hbmV0IG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7
IDxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0K
Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t
YW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbWFuZXQ8L2E+PGJyPg0KJmd0OyZndDsgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQomZ3Q7Jmd0OyBUaGlz
IGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5k
ZWQ8YnI+DQomZ3Q7Jmd0OyByZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm
IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4NCiZndDsmZ3Q7IHJlY2lwaWVudCBwbGVhc2Ug
ZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj4NCiZn
dDsmZ3Q7IFlvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBu
b3IgZGlzY2xvc2Ugb3I8YnI+DQomZ3Q7Jmd0OyBkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBh
bnkgb3RoZXIgcGVyc29uLjxicj4NCiZndDsmZ3Q7ICoqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KJmd0Ozxicj4N
CiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+
DQomZ3Q7IG1hbmV0IG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm1hbmV0
QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxicj4NCjxicj4NCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQg
bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBp
ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B0E81GLKXM0002VGREEN_--


From nobody Fri Apr 22 08:07: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 E0ACB12EB09 for ; Fri, 22 Apr 2016 08:07: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 mIT4J6hXzNY3 for ; Fri, 22 Apr 2016 08:07:01 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::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 4E05E12EB23 for ; Fri, 22 Apr 2016 08:07:01 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id n62so139753664vkb.0 for ; Fri, 22 Apr 2016 08:07:01 -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=zsWd+atugkNadXEn6jWy/Z7MeOMN4/JO5VyotZkbNgY=; b=sKcpVbEksqiu03nut8fvYbqOCv8GDvYo2gi+FnhnQ35z6RgDyJXnJG9ZPHIgjyXbzL tz4GNCX4U5ErcbrUBLE3MRaVEpkAfSgRYaGP82kGCFY1DHb/JNlp2bs/lg76DYRavnAp yu3N2TmwcUptQ5kH1WnKTC7TVvPE1aDq1NHUiuJIXiHZkzMy/BLUToReC9VimS4kQ2ct YP/HR3A0t4o2qyQgy2MxjxaT4XD4LjYcbog1BO75uyGCMfJcM2YoViYAe7o5bshz3OoK IPHJEDiFj2JN5IifWKqtslugaY8QH8/6JlDvTnUqCJX04W5TaY1IWZ/9RaH9H9xlOzlH dqzg==
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=zsWd+atugkNadXEn6jWy/Z7MeOMN4/JO5VyotZkbNgY=; b=HECfDOasWf5McRwtBdeWp6Vn5EmN1hX53c2Qf5rTTMBwEV9/C15w0uxF3L2yskXEiZ WYHotNsj5YVIHaC7a2nvGlcSJysDaNtZGzUB4VyqfZdRUKdB4H3W9mJIjUBVD8Licz6b TmjE6yVjOwSCyiXrAseD3CaNfjMY/FZv2TtehaokZ40HPN//7yaVljBxK+BImTJeLYOe pb9/oTwpgnurbn/2YC4lz2aZqwTfnN3NhwSPsDU7rAnEqhMqUblbi9Ton7BWP6j48xi2 rxSm0K+sLdoVh+BdqGRN1BDzQnZoKZCM5HfVPiUZTDa7F+lxtBSLw5MXiIu1kAWw0S/G TFeQ==
X-Gm-Message-State: AOPr4FUpx2b6b/FqTbkR1u6eYk68fBNhz+VMWziPiHYuJSzsi8XaPAaxXAv7GFW2LPTtZVsZy2m/FIBtEV8/YQ==
MIME-Version: 1.0
X-Received: by 10.31.134.133 with SMTP id i127mr11014784vkd.153.1461337620362;  Fri, 22 Apr 2016 08:07:00 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Fri, 22 Apr 2016 08:07:00 -0700 (PDT)
Date: Fri, 22 Apr 2016 11:07:00 -0400
Message-ID: 
From: Justin Dean 
To: "manet@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11440cb6c240510531142d81
Archived-At: 
Subject: [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: Fri, 22 Apr 2016 15:07:03 -0000

--001a11440cb6c240510531142d81
Content-Type: text/plain; charset=UTF-8

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
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.

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:

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

--001a11440cb6c240510531142d81
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


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

The purpose of the MANET worki=
ng group is to standardize IP routing protocol functionality suitable for w=
ireless 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

The MANET WG will standardize a multicast MANET protocol framework based on=
 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 mu=
lticast forwarding information base.

The WG will produce an informational draft outlining challenges and best pr=
actices 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)
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


--001a11440cb6c240510531142d81--


From nobody Fri Apr 22 08:45: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 09CBC12D8FB for ; Fri, 22 Apr 2016 08:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.915
X-Spam-Level: 
X-Spam-Status: No, score=-7.915 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] 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 jMLHkVEbZeu1 for ; Fri, 22 Apr 2016 08:45:34 -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 526DB12D658 for ; Fri, 22 Apr 2016 08:45:33 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,517,1454976000"; d="scan'208,217"; a="63437051"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 22 Apr 2016 16:45:32 +0100
X-IronPort-AV: E=Sophos;i="5.24,517,1454976000";  d="scan'208,217";a="115150241"
Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 22 Apr 2016 16:45:31 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.6]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Fri, 22 Apr 2016 16:45:32 +0100
From: "Dearlove, Christopher (UK)" 
To: Justin Dean , "manet@ietf.org" 
Thread-Topic: [manet] Recharter Discussion
Thread-Index: AQHRnKi1tIqGPmFeIkW1v/uroMSbLJ+WICEg
Date: Fri, 22 Apr 2016 15:45:30 +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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B0ED4GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: 
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: Fri, 22 Apr 2016 15:45:36 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B0ED4GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

TXVsdGljYXN0IGlzIHRoZSBvYnZpb3VzIHRvcCBpdGVtLiBMb3RzIG9mIHBvc3NpYmxlIGFwcHJv
YWNoZXMsIHRpbWUgdG8gZGlzY3Vzcy4NCg0KR2F0ZXdheXMgZm9yIEFPRFZ2MiBhdCBTdGFuZGFy
ZCBpcyBvYnZpb3VzbHkgbm90IHBvc3NpYmxlIHNpbmNlIEFPRFZ2MiBpcyBnb2luZyB0byBiZSBF
eHBlcmltZW50YWwgYXQgbW9zdC4NCg0KTWFuYWdlbWVudCB3ZSBkaWQgb2YgY291cnNlIGhhdmUg
YW4gTkhEUC9PTFNSdjIgZHJhZnQga2lsbGVkIGJ5IEFELiBXaGljaCBzaW5jZSBOSERQL09MU1J2
MiB1cyBhbGwgd2UgaGF2ZSAoU01GIGV4Y2VwdGVkKSB0aGF0IHdhcyBhIGJpdCB0cmlja3kuDQoN
Ckkgd291bGQgaGF2ZSB0byBtYWtlIGFuIElQUiBkZWNsYXJhdGlvbiB0byBzYXkgc29tZSBvZiB3
aGF0IEkgbWlnaHQgaGF2ZSB0byBzYXkgYWJvdXQgZW5jcnlwdGlvbi4gTm90IHRvZGF5Lg0KDQpN
aXNzaW5nIGZyb20gdGhlIGxpc3QgaXMgYW55IHdvcmsgb24gT0xTUnYyIChvciBOSERQKS4gTVQt
T0xTUnYyIGlzIGV4cGVyaW1lbnRhbC4gVGhhdCB3b3VsZCBuZWVkIGltcGxlbWVudGF0aW9uIHRl
c3RzIHRvIGFkdmFuY2UgdG8gUFMuIEFueW9uZSBpbnRlcmVzdGVkIGluIHRoYXQgKEnigJltIG5v
dCBzYXlpbmcgSSBjYW4pPw0KDQpNb3JlIGJyb2FkbHkgb24gT0xTUnYyIHRoZXJlIGFyZSB2YXJp
b3VzIHRoaW5ncyB0aGF0IGNvdWxkIGJlIGRvbmUsIGJ1dCB3aGF0IGlzIHJlYWxseSBuZWVkZWQg
aXMgcGVvcGxlIHdpdGggYSByZWFsIGFwcGxpY2F0aW9uLiBBbnkgdGhhdCBleGlzdCB3ZXJlIGZy
aWdodGVuZWQgYXdheSBmcm9tIHRoaXMgZ3JvdXAuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92
ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxp
Z2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUg
MjQyMTk0ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMu
ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdl
bmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3Jk
LCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lz
dGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpS
ZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2Zm
aWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0K
RnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg
SnVzdGluIERlYW4NClNlbnQ6IDIyIEFwcmlsIDIwMTYgMTY6MDcNClRvOiBtYW5ldEBpZXRmLm9y
Zw0KU3ViamVjdDogW21hbmV0XSBSZWNoYXJ0ZXIgRGlzY3Vzc2lvbg0KDQoNCioqKiBXQVJOSU5H
ICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRp
b24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29u
c2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9w
ZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBS
ZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUs
IGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsv
c2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBm
ZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2Vzczxo
dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90
bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRm
Pi4NCioqKiBXQVJOSU5HICoqKg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdp
bmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb24uDQoNCkknbGwgc3RhcnQgdGhpbmdz
IG9mZiBieSBmbG9hdGluZyB0aGUgZHJhZnQgcmUtY2hhcnRlciB3aGljaCB3YXMgcHJlc2VudGVk
IGluIFByYWd1ZS4NCg0KDQoNClRoZSBwdXJwb3NlIG9mIHRoZSBNQU5FVCB3b3JraW5nIGdyb3Vw
IGlzIHRvIHN0YW5kYXJkaXplIElQIHJvdXRpbmcgcHJvdG9jb2wgZnVuY3Rpb25hbGl0eSBzdWl0
YWJsZSBmb3Igd2lyZWxlc3Mgcm91dGluZyBhcHBsaWNhdGlvbiB3aXRoaW4gYm90aCBzdGF0aWMg
YW5kIGR5bmFtaWMgdG9wb2xvZ2llcyB3aXRoIGluY3JlYXNlZCBkeW5hbWljcyBkdWUgdG8gbm9k
ZSBtb3Rpb24gb3Igb3RoZXIgZmFjdG9ycy4NCg0KDQoNCkFwcHJvYWNoZXMgYXJlIGludGVuZGVk
IHRvIGJlIHJlbGF0aXZlbHkgbGlnaHR3ZWlnaHQgaW4gbmF0dXJlLCBzdWl0YWJsZSBmb3IgbXVs
dGlwbGUgaGFyZHdhcmUgYW5kIHdpcmVsZXNzIGVudmlyb25tZW50cywgYW5kIGFkZHJlc3Mgc2Nl
bmFyaW9zIHdoZXJlIE1BTkVUcyBhcmUgZGVwbG95ZWQgYXQgdGhlIGVkZ2VzIG9mIGFuIElQIGlu
ZnJhc3RydWN0dXJlLiBIeWJyaWQgbWVzaCBpbmZyYXN0cnVjdHVyZXMgKGUuZy4sIGEgbWl4dHVy
ZSBvZiBmaXhlZCBhbmQgbW9iaWxlIHJvdXRlcnMpIHNob3VsZCBhbHNvIGJlIHN1cHBvcnRlZCBi
eSBNQU5FVCBzcGVjaWZpY2F0aW9ucyBhbmQgbWFuYWdlbWVudCBmZWF0dXJlcy4NCg0KDQoNClRo
ZSBNQU5FVCBXRyBpcyByZXNwb25zaWJsZSBmb3IgdGhlIG1haW50ZW5hbmNlIG9mIE9MU1J2Miwg
QU9EVnYyLCBETEVQIGFuZCBOSFBELiBPZiBwYXJ0aWN1bGFyIGludGVyZXN0OiBib3JkZXIgYmVo
YXZpb3IgYmV0d2VlbiBNQU5FVCBuZXR3b3JrcyBhbmQgZml4ZWQgSVAgbmV0d29yayBpbmZyYXN0
cnVjdHVyZXMsIGVuaGFuY2UgQU9EVnYyIGdhdGV3YXkgZnVuY3Rpb25hbGl0eTsgc2VjdXJpdHkg
ZW5oYW5jZW1lbnRzLCBlbmNyeXB0aW9uIHNlY3VyaXR5IGV4dGVuc2lvbnMgZm9yIFJGQzU0NDQu
DQoNCg0KDQpUaGUgTUFORVQgV0cgd2lsbCBzdGFuZGFyZGl6ZSBhIG11bHRpY2FzdCBNQU5FVCBw
cm90b2NvbCBmcmFtZXdvcmsgYmFzZWQgb24gcHJldmlvdXMgd29yayBhbmQgbGVzc29ucyBsZWFy
bmVkIGZvciBzY29wZWQgZm9yd2FyZGluZyB3aXRoaW4gTUFORVQgbmV0d29ya3MuICBBcyBwYXJ0
IG9mIHRoaXMgZnJhbWV3b3JrIHRoZSBXRyB3aWxsIHByb2R1Y2UgYSB3ZWxsIGRlZmluZWQgTUFO
RVQgbXVsdGljYXN0IGZvcndhcmRpbmcgaW5mb3JtYXRpb24gYmFzZS4NCg0KDQoNClRoZSBXRyB3
aWxsIHByb2R1Y2UgYW4gaW5mb3JtYXRpb25hbCBkcmFmdCBvdXRsaW5pbmcgY2hhbGxlbmdlcyBh
bmQgYmVzdCBwcmFjdGljZXMgZm9yIGRlcGxveWluZyBhbmQgbWFuYWdpbmcgTUFORVQgbmV0d29y
a3MuDQoNCg0KDQpUaGUgTUFORVQgV0cgd2lsbCBpbnRlcmFjdCB3aXRoIHRoZSBQSU0gd29ya2lu
ZyBncm91cCBvbiBpc3N1ZXMgcmVsYXRpbmcgdG8gdGhlIG11bHRpY2FzdCB3b3JrLiAgVGhlIFdH
IHdpbGwgYWxzbyBwYXkgYXR0ZW50aW9uIHRvIG90aGVyIElFVEYgYW5kIElSVEYgd29yayB0aGF0
IGlzIGFkZHJlc3NpbmcgdG9waWNzIHJlbGF0ZWQgdG8gTUFORVQgZW52aXJvbm1lbnRzLg0KDQoN
Cg0KSW4gc3VtbWFyeSwgdGhlIFdHIHdpbGwgZGV2ZWxvcCB0aGUgZm9sbG93aW5nIGRyYWZ0czoN
Cg0KDQoNCk1BTkVUIE1hbmFnZW1lbnQgRG9jdW1lbnQgKEluZm9ybWF0aW9uYWwpDQoNCk1BTkVU
IE1haW50ZW5hbmNlDQoNCiAtIFJGQzU0NDQgU2VjdXJpdHkgZXh0ZW5zaW9uIChTdGFuZGFyZHMp
DQoNCiAtIEVuaGFuY2VkIEFPRFZ2MiBnYXRld2F5IGV4dGVuc2lvbiAoU3RhbmRhcmRzKQ0KDQpN
QU5FVCBNdWx0aWNhc3QNCg0KIC0gTXVsdGljYXN0IEZJQiAoU3RhbmRhcmRzKQ0KDQoNCg0KDQoN
ClRoaXMgd2lsbCBsaWtlbHkgYmUgY29uc2lkZXJlZCB0b28gYnJvYWQgdG8gcGFzcy4gIFdlIHdp
bGwgbGlrZWx5IG5lZWQgdG8gY3V0IHNvbWUgYW5kIGZvY3VzIHRoZSB3b3JrLiAgRm9yIG1lIHBl
cnNvbmFsbHkgSSBrbm93IEkgaGF2ZSB0aGUgdGltZSBhbmQgYmFja2luZyB0byB3b3JrIG9uIHRo
ZSBNdWx0aWNhc3QgcGllY2UuDQoNCg0KDQpKdXN0aW4NCioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqClRoaXMgZW1haWwg
YW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZApyZWNp
cGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl
bmRlZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3Rp
ZnkgdGhlIHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBw
dXJwb3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3Ro
ZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKgo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B0ED4GLKXM0002VGREEN_
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
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk11bHRpY2FzdCBp
cyB0aGUgb2J2aW91cyB0b3AgaXRlbS4gTG90cyBvZiBwb3NzaWJsZSBhcHByb2FjaGVzLCB0aW1l
IHRvIGRpc2N1c3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HYXRld2F5cyBmb3IgQU9EVnYyIGF0IFN0YW5kYXJkIGlz
IG9idmlvdXNseSBub3QgcG9zc2libGUgc2luY2UgQU9EVnYyIGlzIGdvaW5nIHRvIGJlIEV4cGVy
aW1lbnRhbCBhdCBtb3N0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWFuYWdlbWVudCB3ZSBkaWQgb2YgY291cnNlIGhh
dmUgYW4gTkhEUC9PTFNSdjIgZHJhZnQga2lsbGVkIGJ5IEFELiBXaGljaCBzaW5jZSBOSERQL09M
U1J2MiB1cyBhbGwgd2UgaGF2ZSAoU01GIGV4Y2VwdGVkKSB0aGF0IHdhcyBhIGJpdCB0cmlja3ku
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5JIHdvdWxkIGhhdmUgdG8gbWFrZSBhbiBJUFIgZGVjbGFyYXRpb24gdG8gc2F5
IHNvbWUgb2Ygd2hhdCBJIG1pZ2h0IGhhdmUgdG8gc2F5IGFib3V0IGVuY3J5cHRpb24uIE5vdCB0
b2RheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPk1pc3NpbmcgZnJvbSB0aGUgbGlzdCBpcyBhbnkgd29yayBvbiBPTFNS
djIgKG9yIE5IRFApLiBNVC1PTFNSdjIgaXMgZXhwZXJpbWVudGFsLiBUaGF0IHdvdWxkIG5lZWQg
aW1wbGVtZW50YXRpb24gdGVzdHMgdG8gYWR2YW5jZSB0byBQUy4gQW55b25lIGludGVyZXN0ZWQg
aW4NCiB0aGF0IChJ4oCZbSBub3Qgc2F5aW5nIEkgY2FuKT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1vcmUgYnJvYWRs
eSBvbiBPTFNSdjIgdGhlcmUgYXJlIHZhcmlvdXMgdGhpbmdzIHRoYXQgY291bGQgYmUgZG9uZSwg
YnV0IHdoYXQgaXMgcmVhbGx5IG5lZWRlZCBpcyBwZW9wbGUgd2l0aCBhIHJlYWwgYXBwbGljYXRp
b24uIEFueSB0aGF0IGV4aXN0IHdlcmUgZnJpZ2h0ZW5lZA0KIGF3YXkgZnJvbSB0aGlzIGdyb3Vw
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9vOnA+
PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv
bToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hy
aXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFF
IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwv
Yj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAw
MDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3
RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+
OiAmbmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wgJm5ic3A7PGI+RToNCjwvYj48
YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJs
b3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9y
ZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhI
Ti48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHls
ZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGlt
aXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5S
ZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5
LCBHVTIgN1lQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9y
Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIERlYW48YnI+DQo8Yj5TZW50OjwvYj4gMjIg
QXByaWwgMjAxNiAxNjowNzxicj4NCjxiPlRvOjwvYj4gbWFuZXRAaWV0Zi5vcmc8YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gW21hbmV0XSBSZWNoYXJ0ZXIgRGlzY3Vzc2lvbjxvOnA+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
cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ2xsIHN0YXJ0IHRoaW5ncyBvZmYgYnkgZmxvYXRpbmcgdGhl
IGRyYWZ0IHJlLWNoYXJ0ZXIgd2hpY2ggd2FzIHByZXNlbnRlZCBpbiBQcmFndWUuICZuYnNwOzxi
cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPlRoZSBwdXJwb3NlIG9mIHRoZSBNQU5FVCB3b3JraW5nIGdyb3VwIGlzIHRvIHN0YW5k
YXJkaXplIElQIHJvdXRpbmcgcHJvdG9jb2wgZnVuY3Rpb25hbGl0eSBzdWl0YWJsZSBmb3Igd2ly
ZWxlc3Mgcm91dGluZyBhcHBsaWNhdGlvbiB3aXRoaW4gYm90aCBzdGF0aWMgYW5kIGR5bmFtaWMg
dG9wb2xvZ2llcyB3aXRoIGluY3JlYXNlZCBkeW5hbWljcyBkdWUgdG8gbm9kZSBtb3Rpb24gb3Ig
b3RoZXIgZmFjdG9ycy4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QXBwcm9hY2hlcyBhcmUgaW50ZW5kZWQgdG8gYmUg
cmVsYXRpdmVseSBsaWdodHdlaWdodCBpbiBuYXR1cmUsIHN1aXRhYmxlIGZvciBtdWx0aXBsZSBo
YXJkd2FyZSBhbmQgd2lyZWxlc3MgZW52aXJvbm1lbnRzLCBhbmQgYWRkcmVzcyBzY2VuYXJpb3Mg
d2hlcmUgTUFORVRzIGFyZSBkZXBsb3llZCBhdCB0aGUgZWRnZXMgb2YgYW4gSVAgaW5mcmFzdHJ1
Y3R1cmUuIEh5YnJpZCBtZXNoIGluZnJhc3RydWN0dXJlcyAoZS5nLiwgYSBtaXh0dXJlIG9mIGZp
eGVkIGFuZCBtb2JpbGUgcm91dGVycykgc2hvdWxkIGFsc28gYmUgc3VwcG9ydGVkIGJ5IE1BTkVU
IHNwZWNpZmljYXRpb25zIGFuZCBtYW5hZ2VtZW50IGZlYXR1cmVzLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBNQU5FVCBX
RyBpcyByZXNwb25zaWJsZSBmb3IgdGhlIG1haW50ZW5hbmNlIG9mIE9MU1J2MiwgQU9EVnYyLCBE
TEVQIGFuZCBOSFBELiBPZiBwYXJ0aWN1bGFyIGludGVyZXN0OiBib3JkZXIgYmVoYXZpb3IgYmV0
d2VlbiBNQU5FVCBuZXR3b3JrcyBhbmQgZml4ZWQgSVAgbmV0d29yayBpbmZyYXN0cnVjdHVyZXMs
IGVuaGFuY2UgQU9EVnYyIGdhdGV3YXkgZnVuY3Rpb25hbGl0eTsgc2VjdXJpdHkgZW5oYW5jZW1l
bnRzLCBlbmNyeXB0aW9uIHNlY3VyaXR5IGV4dGVuc2lvbnMgZm9yIFJGQzU0NDQuIDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRo
ZSBNQU5FVCBXRyB3aWxsIHN0YW5kYXJkaXplIGEgbXVsdGljYXN0IE1BTkVUIHByb3RvY29sIGZy
YW1ld29yayBiYXNlZCBvbiBwcmV2aW91cyB3b3JrIGFuZCBsZXNzb25zIGxlYXJuZWQgZm9yIHNj
b3BlZCBmb3J3YXJkaW5nIHdpdGhpbiBNQU5FVCBuZXR3b3Jrcy4mbmJzcDsgQXMgcGFydCBvZiB0
aGlzIGZyYW1ld29yayB0aGUgV0cgd2lsbCBwcm9kdWNlIGEgd2VsbCBkZWZpbmVkIE1BTkVUIG11
bHRpY2FzdCBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIGJhc2UuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIFdHIHdpbGwgcHJv
ZHVjZSBhbiBpbmZvcm1hdGlvbmFsIGRyYWZ0IG91dGxpbmluZyBjaGFsbGVuZ2VzIGFuZCBiZXN0
IHByYWN0aWNlcyBmb3IgZGVwbG95aW5nIGFuZCBtYW5hZ2luZyBNQU5FVCBuZXR3b3Jrcy48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
Ij5UaGUgTUFORVQgV0cgd2lsbCBpbnRlcmFjdCB3aXRoIHRoZSBQSU0gd29ya2luZyBncm91cCBv
biBpc3N1ZXMgcmVsYXRpbmcgdG8gdGhlIG11bHRpY2FzdCB3b3JrLiZuYnNwOyBUaGUgV0cgd2ls
bCBhbHNvIHBheSBhdHRlbnRpb24gdG8gb3RoZXIgSUVURiBhbmQgSVJURiB3b3JrIHRoYXQgaXMg
YWRkcmVzc2luZyB0b3BpY3MgcmVsYXRlZCB0byBNQU5FVCBlbnZpcm9ubWVudHMuPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SW4g
c3VtbWFyeSwgdGhlIFdHIHdpbGwgZGV2ZWxvcCB0aGUgZm9sbG93aW5nIGRyYWZ0czo8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5N
QU5FVCBNYW5hZ2VtZW50IERvY3VtZW50IChJbmZvcm1hdGlvbmFsKTxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1BTkVUIE1haW50ZW5hbmNl
IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si
PiZuYnNwOy0gUkZDNTQ0NCBTZWN1cml0eSBleHRlbnNpb24gKFN0YW5kYXJkcyk8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gLSBFbmhhbmNl
ZCBBT0RWdjIgZ2F0ZXdheSBleHRlbnNpb24gKFN0YW5kYXJkcyk8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5NQU5FVCBNdWx0aWNhc3Q8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gLSBN
dWx0aWNhc3QgRklCIChTdGFuZGFyZHMpPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhpcyB3aWxsIGxpa2VseSBiZSBj
b25zaWRlcmVkIHRvbyBicm9hZCB0byBwYXNzLiZuYnNwOyBXZSB3aWxsIGxpa2VseSBuZWVkIHRv
IGN1dCBzb21lIGFuZCBmb2N1cyB0aGUgd29yay4mbmJzcDsgRm9yIG1lIHBlcnNvbmFsbHkgSSBr
bm93IEkgaGF2ZSB0aGUgdGltZSBhbmQgYmFja2luZyB0byB3b3JrIG9uIHRoZSBNdWx0aWNhc3Qg
cGllY2UuJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0iY29sb3I6YmxhY2siPkp1c3RpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqPGJyPgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVu
dHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBhbmQgbWF5
IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPgpyZWNp
cGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNl
bmRlci48YnI+CllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9z
ZSBub3IgZGlzY2xvc2Ugb3I8YnI+CmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhl
ciBwZXJzb24uPGJyPgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKjwvcD48L2JvZHk+DQo8L2h0bWw+DQo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B0ED4GLKXM0002VGREEN_--


From nobody Fri Apr 22 08:50:46 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 A32D912D642 for ; Fri, 22 Apr 2016 08:50:44 -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 JqV2tb7oUr9C for ; Fri, 22 Apr 2016 08:50:41 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001: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 AAEDF12D590 for ; Fri, 22 Apr 2016 08:50:41 -0700 (PDT)
Received: by mail-ig0-x22c.google.com with SMTP id bi2so17217868igb.0 for ; Fri, 22 Apr 2016 08:50:41 -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=86D/XH6cfeLX/gV+eO5raFo7vwPSAs1TLGwWsG1WX6I=; b=p4cEeB9FGprE5dLmV+B59sG0K473GRE6YWGN5wPm+P28lbpebIlPq31gHk/BlMBa18 7MWEjJBuBtjrddNWuGZbGMAqHfJl9ucEj2iBMPz7oXCuSrrbbREsT9sRw1r/F3NFT4/O wulB9JevtO1Q7wbs29B5b2YZqvj0q5bd5j6nFQNKKoB3DxT5oFCMCtekHa89fWNhsaK5 py3azfBRcMAVlgO6gokAGGhVURDQnXa5g9FKQyypmhf/e5BtOP/opC5RsNP+xLv4nV0t 0Vw7fvdib6XBh0XaQR2QMCC9TBgwqxvOSFFVP2wWnZTCRGetvzdoXuCau1JURg3vbZpL muww==
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=86D/XH6cfeLX/gV+eO5raFo7vwPSAs1TLGwWsG1WX6I=; b=VqozcgasgpKsc4V1Ge74U9hK7ky10RkWn5yiAXttu2lnN4Btw3Acrt13XI0dD0mzaK ks+RJPPcgUx6JmHQGZtYz8VzSxCTC54GfBn2NsiWvnwpEGP5HANYhXsHJ1OcXoIWJkvA 771S9kNEOu02v+ndrkVCRHLU7kfuWH3ru1lz0UD7enLH4+ugRmKKdrHnXspaKhIvSljq 6eOJE+0zpAOuB4ZLJOOgPf9KlvDcj8qcIlZ05AIONSBGE6gKEyPx6+jkd/02gY2pWsIl ipdyIpXKNhlVBxBDt0dzTRL3qRR6j6wToel1xN7zOuIWhj0VFp3Ih4R2MqK6E2fzyyl4 7yFQ==
X-Gm-Message-State: AOPr4FUyHyOGmmiP86/XbaOdVuGMPC9MX5GqVxelC/cKXSlg0fBLAHab93ZZuOqgsv7KJ+sH3V4boIcGXFmctQ==
MIME-Version: 1.0
X-Received: by 10.50.33.225 with SMTP id u1mr5120238igi.36.1461340240937; Fri, 22 Apr 2016 08:50:40 -0700 (PDT)
Received: by 10.79.72.68 with HTTP; Fri, 22 Apr 2016 08:50:40 -0700 (PDT)
In-Reply-To: 
References:  
Date: Fri, 22 Apr 2016 11:50:40 -0400
Message-ID: 
From: Stan Ratliff 
To: "Dearlove, Christopher (UK)" 
Content-Type: multipart/alternative; boundary=f46d044469c9f50e3e053114c925
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: Fri, 22 Apr 2016 15:50:44 -0000

--f46d044469c9f50e3e053114c925
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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
>
>

--f46d044469c9f50e3e053114c925
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hello WG,=C2=A0

Do we need to hold an i=
nterim 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 d=
o that.=C2=A0

One other point inline:=C2=A0

On Fri, Apr 22, 2016=
 at 11:45 AM, Dearlove, Christopher (UK) <chris.dearlove@baesy=
stems.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 a=
t most.


=C2=A0


Management we did of cour=
se have an NHDP/OLSRv2 draft killed by AD. Which since NHDP/OLSRv2 us all w=
e 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. No=
t today.

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

Regards,
Stan

=C2=A0


=C2=A0


Missing from the list is =
any work on OLSRv2 (or NHDP). MT-OLSRv2 is experimental. That would need im=
plementation 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 peo=
ple with a real application. Any that exist were frightened
 away from this group.


=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: 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 ***<=
/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.=










***
WARNING
***

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




=C2=A0






I'll start things off by floating the draft re-c=
harter 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.<=
u>


=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)<=
u>


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

https://www.ietf.org/mailman/listinfo/manet





--f46d044469c9f50e3e053114c925--


From nobody Fri Apr 22 09:27:09 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 962BA12E8CE for ; Fri, 22 Apr 2016 09:27:07 -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 A9rJ7_3L5rMc for ; Fri, 22 Apr 2016 09:27:04 -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 2DE1712E8C6 for ; Fri, 22 Apr 2016 09:27:04 -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 <1atdv3-0018Da-DT>; Fri, 22 Apr 2016 18:27:01 +0200
Received: from x4dbabaf0.dyn.telefonica.de ([77.186.186.240] helo=[192.168.1.130]) by inpost2.zedat.fu-berlin.de (Exim 4.85) for manet@ietf.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id <1atdv2-000bIX-Gc>; Fri, 22 Apr 2016 18:27:01 +0200
From: Lotte Steenbrink 
Content-Type: multipart/alternative; boundary="Apple-Mail=_4D01F7C8-AE05-4134-977E-67AC3CDB49EF"
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Date: Fri, 22 Apr 2016 18:26:56 +0200
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org>   
To: Mobile Ad Hoc Networks mailing list 
In-Reply-To: 
X-Mailer: Apple Mail (2.3112)
X-Originating-IP: 77.186.186.240
X-ZEDAT-Hint: A
Archived-At: 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 16:27:07 -0000

--Apple-Mail=_4D01F7C8-AE05-4134-977E-67AC3CDB49EF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,
to summarize:

* AODVv2 message Type numbers should be in the Experimental type space =
and the AODVv2 TLV Types should be message type-specific. This also =
means changing the text regarding IANA actions and changing the text =
regarding what the experiment is to something along the lines of =E2=80=9C=
we want to gather experience on how to make generic metric TLVs and ICVs =
that work with changing metric TV values happen with reactive =
protocols=E2=80=9D
* we=E2=80=99re undecided on (to quote Christopher) the "here's a =
mechanism we haven't really thought through in detail, but at least =
we've defined one", or "we know the sort of thing we want, and we'll =
describe it, but rather than produce something not quite right, we'll =
not go further=E2=80=9C decision on temporarily setting the metric value =
to 0 (i.e. the who and how). (personally, I think I=E2=80=99d prefer the =
latter approach, but that=E2=80=99s an entirely gut feeling-based =
preference)

Did I catch that correctly? If so, I=E2=80=99ll put together and suggest =
some text for the first point as soon as I get home and in case there =
has been a decision on the second by then, I=E2=80=99ll try to tackle =
that one too. :)

Best regards, Lotte

> Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) =
:
>=20
> I have no problem with that. I was trying to lay out the issues =
without muddying the water with my preference.
> =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: Justin Dean [mailto:bebemaster@gmail.com =
]=20
> Sent: 22 April 2016 15:35
> To: Dearlove, Christopher (UK)
> Cc: Thomas Heide Clausen; Mobile Ad Hoc Networks mailing list
> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
> =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
> Speaking as participant.
>=20
> I kind of like the idea of using the experimental message type space.  =
We only have a limited amount of these message types.  The TLV =
assignments could just use the message type specific space and there =
isn't an issue there.  IANA wouldn't assign a number but I don't see why =
the document couldn't specify the experimental numbers it was going to =
use so other future near term experiential protocols could do the same =
and generally avoid conflict.  If the experiment is successful IANA =
assignments could be made.  Functionally no real difference with =
protections vs long term usage of limited space.
> =20
> Justin
> =20
> On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) =
> =
wrote:
> There's rather a contradiction between the concepts of a definition of =
a protocol, even Experimental, and experimental space, which usually =
assumes that the user can do what he or she likes in it.
>=20
> But chewing up messages types (how many, 3?) of which there are =
relatively few for experimental is long term a problem, although short =
term not.
>=20
> TLV space is easier in two regards. It's bigger (though the prime real =
estate of type extension zero isn't) and can have message type specific =
TLVs.
>=20
> So TLVS can actually be invisible, if that option is chosen. For =
messages something has to give. Least bad option is again one of those =
we should discuss, but time ...
>=20
> (To be precise, messages types from 224 are defined in RFC 5444 as " =
Experimental Use", of which BCP 26 says "Similar to private or local use =
only, with the  purpose being to facilitate experimentation." The =
alternative 0-223 space is Expert Review. IANA still thinks the experts =
are Joe Macker and the recused Stan Ratliff. But that's a soluble nit.)
>=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
> -----Original Message-----
> From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org =
]
> Sent: 22 April 2016 14:21
> To: Dearlove, Christopher (UK)
> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>=20
> ----------------------! WARNING ! ---------------------- This message =
originates from outside our organisation, either from an external =
partner or from the internet.
> Consider carefully whether you should click on any links, open any =
attachments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters for =
instructions on reporting suspicious email messages.
> --------------------------------------------------------
>=20
>=20
> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) =
> =
wrote:
> >
> > Once you're entirely in AODV2's own space, and AODVv2 is =
experimental (working assumption for this discussion) you have more =
liberty.
> >
>=20
> Yep.
>=20
> Taken somewhat by surprise both by the sudden "rush" and the =
experimental maturity level, I am wondering (and haven't thought =
through) about experimental space vs non-experimental (for message =
types, and consequently for message type specific TLV types).
>=20
> I think that if the AODVv2 experiment specifies the use of Message =
types from the Experimental message type space without making actual =
registrations in the IANA registry, AND the use of type specific TLV =
types, this becomes a non-issue entirely (by design, this is precisely =
what that experimental space is for)
>=20
> Whereas, as you point out, the alternative is a "can open - worms =
everywhere" situation that I think time is too short to solve?
>=20
> Thomas
>=20
>=20
> > Then you could try specifying it. But with a very good chance of =
producing something you later decide you should have done differently.
> >
> > I honestly don't know which would go down better (or less badly) - =
"here's a mechanism we haven't really thought through in detail, but at =
least we've defined one", or "we know the sort of thing we want, and =
we'll describe it, but rather than produce something not quite right, =
we'll not go further".
> >
> > --
> > 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
> >
> >
> > -----Original Message-----
> > From: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de =
]
> > Sent: 22 April 2016 13:59
> > To: Mobile Ad Hoc Networks mailing list
> > Cc: Henning Rogge; Dearlove, Christopher (UK)
> > Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
> >
> > ----------------------! WARNING ! ---------------------- This =
message originates from outside our organisation, either from an =
external partner or from the internet.
> > Consider carefully whether you should click on any links, open any =
attachments or reply.
> > Follow the 'Report Suspicious Emails' link on IT matters for =
instructions on reporting suspicious email messages.
> > --------------------------------------------------------
> >
> > Hello Christopher,
> >
> >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) =
>:
> >>
> >> Just be careful to note that this concept is as currently being =
discussed (a) specific to AODVv2, and (b) not an application of 7182, =
which has no knowledge of special TLVs.
> >>
> >> This is something we'd want to get right, and need to get right if =
in any space not specific to ADODVv2, because getting it wrong produces =
future problems.
> >
> > Makes sense.
> >
> >> I can see some possible approaches, none is ideal and we're rather =
out
> >> of time to specify. But this is experimental, so I think we might =
be
> >> able to indicate the shape of the solution without specifying it,
> >> which would be a different RFC, under a bit less time pressure.
> >> (Extensions to existing protocols like 7182 would naturally be in
> >> scope rechartered I think.)
> >>
> >> To indicate the range that's open, here are two possible ideas, one =
of which has an impact now, so needs to be agreed. Note that I'm not =
suggesting (in fact quite the opposite) defining an extension to 7182 =
here, rather enabling such an extension, if written, to "do the right =
thing".
> >> - We have an extension to 7182 that says "zero out all value octets =
in protocol specific TLVs. That requires now putting the AODVv2 metric =
TLV in that space.
> >
> > Just to make sure that I understood you correctly=E2=80=93 =E2=80=9Cth=
at space=E2=80=9D meaning making the AODVv2 metric TLV protocol =
specific? (By =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m =
referring to the generic TLV we=E2=80=99ve been talking about on this =
list earlier this week).
> >
> >> - We have an extension to 7182 that adds extra material to the =
value field that indicates (TBD how, by position with sanity check that =
this is TLV value perhaps?) which octets are to be zeroed out before the =
ICV is calculated.
> >
> > The way I understand that approach, it wouldn=E2=80=99t warrant any =
action from AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set =
the Metric value to zero=E2=80=9D (leaving the nitty gritty of how this =
would be done in detail to future work)=E2=80=A6 Is that correct?
> >
> >>
> >> We do not have the time to specify this in an acceptable manner =
within two weeks though. But the security consideration section could =
say something along the lines of "this enables the use of an ICV defined =
to zero out these octets=E2=80=9C.
> >
> > Okay. :)
> >
> > Best regards,
> > Lotte
> >
> >>
> >> --
> >> 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
> >>
> >> -----Original Message-----
> >> From: manet [mailto:manet-bounces@ietf.org =
] On Behalf Of Lotte
> >> Steenbrink
> >> Sent: 22 April 2016 10:28
> >> To: Henning Rogge
> >> Cc: Mobile Ad Hoc Networks mailing list
> >> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
> >> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
> >>
> >> ----------------------! WARNING ! ---------------------- This =
message originates from outside our organisation, either from an =
external partner or from the internet.
> >> Consider carefully whether you should click on any links, open any =
attachments or reply.
> >> Follow the 'Report Suspicious Emails' link on IT matters for =
instructions on reporting suspicious email messages.
> >> --------------------------------------------------------
> >>
> >> *** WARNING ***
> >> EXTERNAL EMAIL -- This message originates from outside our =
organization.
> >>
> >>
> >> Hi Henning,
> >>
> >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge >:
> >>>
> >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
> >>> > wrote:
> >>>> Hi Thomas,
> >>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=E2=
=80=9D language
> >>>> in the first place is that we=E2=80=99ve been told that whenever =
one bit in
> >>>> the message (apart from its header) is changed, the entire thing =
has to be regenerated.
> >>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been =
misunderstanding
> >>>> each other for more than a year. :( Anyway, it seems like we=E2=80=99=
re
> >>>> getting close now, so yay.
> >>>
> >>> "Modifying" the binary message instead of parsing and generating a
> >>> new one will be difficult as soon someone writes an extension to
> >>> AODVv2 that adds more TLVs to the message.
> >>
> >> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s=
 what you explained to me when I got confused about the topic last =
spring=E2=80=A6 But=E2=80=93 even if a message contains TLVs that the =
AODVv2 implementation handling it doesn=E2=80=99t understand, it will =
still be able to recognize the Metric TLV, right? Isn=E2=80=99t that the =
nifty thing about RFC5444? So, while we really shouldn=E2=80=99t write =
=E2=80=9Cbefore calculating the ICV, set the n-th 4 octets to 0=E2=80=9D, =
we might say =E2=80=9Cidentify the octets that make up the metric value =
and set those to 0=E2=80=9D?
> >>
> >> Best regards,
> >> Lotte
> >>
> >>> Henning Rogge
> >>
> >> _______________________________________________
> >> 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 =

>=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=_4D01F7C8-AE05-4134-977E-67AC3CDB49EF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi all,
to summarize:

* AODVv2 message Type numbers should be =
in the Experimental type space and the AODVv2 TLV Types should be =
message type-specific. This also means changing the text regarding IANA =
actions and changing the text regarding what the experiment is to =
something along the lines of =E2=80=9Cwe want to gather experience on =
how to make generic metric TLVs and ICVs that work with changing metric =
TV values happen with reactive protocols=E2=80=9D
* =
we=E2=80=99re undecided on (to quote Christopher) the "here's a =
mechanism we haven't really thought through in detail, but at least =
we've defined one", or "we know the sort of thing we want, and we'll =
describe it, but rather than produce something not quite right, we'll =
not go further=E2=80=9C decision on temporarily setting the metric value =
to 0 (i.e. the who and how). (personally, I think I=E2=80=99d prefer the =
latter approach, but that=E2=80=99s an entirely gut feeling-based =
preference)

Did =
I catch that correctly? If so, I=E2=80=99ll put together and suggest =
some text for the first point as soon as I get home and in case there =
has been a decision on the second by then, I=E2=80=99ll try to tackle =
that one too. :)

Best regards, Lotte


=

--Apple-Mail=_4D01F7C8-AE05-4134-977E-67AC3CDB49EF--


From nobody Fri Apr 22 14:31: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 9965812E3D5 for ; Fri, 22 Apr 2016 14:31:05 -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 LAn9F-CrG-oI for ; Fri, 22 Apr 2016 14:31:04 -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 2BA2112E396 for ; Fri, 22 Apr 2016 14:31:04 -0700 (PDT)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1atifG-002DYu-E8>; Fri, 22 Apr 2016 23:31:02 +0200
Received: from x4dbabaf0.dyn.telefonica.de ([77.186.186.240] helo=[192.168.1.2]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id <1atifG-000xeZ-5n>; Fri, 22 Apr 2016 23:31:02 +0200
From: Lotte Steenbrink 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Fri, 22 Apr 2016 23:31:01 +0200
To: Mobile Ad Hoc Networks mailing list 
Message-Id: <6E2BB485-BF11-4050-9F75-0E2605ABBC96@fu-berlin.de>
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
X-Originating-IP: 77.186.186.240
Archived-At: 
Subject: [manet] AODVv2 Security Considerations discussion thread
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, 22 Apr 2016 21:31:05 -0000

Hi all,
in [1], Thomas has suggested starting a new thread to discuss AODVv2s =
security considerations. I think that=E2=80=99s a good idea, so here it =
goes.

In case it=E2=80=99s helpful, previous security consideration =
discussions can be found here:=20

https://mailarchive.ietf.org/arch/msg/manet/WxpVkfPSTERUquFi8uAMu7UqWC8 =
(and consecutive e-mails)

Also in [1],Thomas mentioned he=E2=80=99s missing the influence of BCP72 =
and BCP107. BCP72 was used as a basis when we reordered the security =
considerations, but that doesn=E2=80=99t mean we didn=E2=80=99t oversee =
anything. If anyone wants to provide pointers as to what we=E2=80=99ve =
missed, by all means, please share it with us.
Regarding BCP107, I think that=E2=80=99s a good point. However, I =
don=E2=80=99t think I=E2=80=99m qualified to do it justice, so I=E2=80=99m=
 just mentioning it again for completeness and in the hope that someone =
else who knows what they=E2=80=99re doing might pick it up :)

Any other comments regarding the security considerations are also very =
welcome, obviously.

With kind regards,
Lotte

[1] =
https://mailarchive.ietf.org/arch/msg/manet/Oc_fMxVIzD_9Y0R2SvQ_S4DeDZU=


From nobody Fri Apr 22 16:27: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 50F1C12E61A for ; Fri, 22 Apr 2016 16:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.143
X-Spam-Level: 
X-Spam-Status: No, score=-1.143 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, TRACKER_ID=1.306] 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 xymn4a1uLt74 for ; Fri, 22 Apr 2016 16:27:00 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::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 24D6712E57F for ; Fri, 22 Apr 2016 16:26:59 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id n62so155434175vkb.0 for ; Fri, 22 Apr 2016 16:26: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=lGN5mbVGIni1+t+VXMuoEgn0FSDrO88EPdhiBxY8HiM=; b=EYIsPVm4+xKJ14QsumPqJj9EkbVQeZ3LOSBcOJyEIAYQTxIqRsjb8WOpMQJ6olGy63 3HQXYPbHMZMBMEEe51N4Bw171TTfGKq2zc34SAEODEHnw6i88ENy63axufz/qYOWj5zj lCjCoN5MBWY4C76O5DcHqc0R2XVY+Mp2r0t33I7/9JVgMMau8USxx/vl1EWv/Pc8w6OA FOTts+oUJTwb3Q79tAQEvTBL1Gf2nj4lfXXOEk5sK7NE7b+BoB8bVt+cmICGp6ZLQxsY S5cg7AoI4DxfUBEJ/0dIqVeAYlgVVEAiC1/EtKA1RWgMBohZrllce/yMJSWAWs2ZxTH+ Z7Gw==
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=lGN5mbVGIni1+t+VXMuoEgn0FSDrO88EPdhiBxY8HiM=; b=OJgsaFCgBeRkmOBA7XYW8su01Gwcux6zaoStDyVV4ynesVH7EiDF2BZA0OdsXhzEXT ziHYR94LwS5GhBIMKtE2dPZzmpMhZrFDQlAzKrfTUX5zyVD4CjeB0PfTgMVyrLo3azfb KquE2VaJtsbFKg9EL0pvZJWD+1j3foDkRKF8mNCji2qNQ4T3cxRYRFqbotlU9CQOHc5V sPUCHo+U/W8u3v1GRFIFZb3zd/+iq/ROW2QMO1vHLJPP8GJWfQUrbLDpBS4N7Vq7tPWz Au5WcpmA2FkNze4bQjJlFzL1rXGKN67UHNniyRN5x+1HP8U01kXZHPGKVoplaolftpk4 fICQ==
X-Gm-Message-State: AOPr4FViGx+ns4LP5eYwW5Z2pLF69jAVea3S2kCm73/nPiN5DN4Sn73C6ut0VMkPHHeefiPxbZlW8IhBXPW3sQ==
MIME-Version: 1.0
X-Received: by 10.159.37.68 with SMTP id 62mr12714663uaz.73.1461367618135; Fri, 22 Apr 2016 16:26:58 -0700 (PDT)
Received: by 10.176.65.40 with HTTP; Fri, 22 Apr 2016 16:26:58 -0700 (PDT)
In-Reply-To: <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>
Date: Sat, 23 Apr 2016 00:26:58 +0100
Message-ID: 
From: Victoria Mercieca 
To: ietf@thomasclausen.org
Content-Type: multipart/alternative; boundary=94eb2c122e52c3edcb05311b2934
Archived-At: 
Cc: Christopher Dearlove , Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 22 Apr 2016 23:27:03 -0000

--94eb2c122e52c3edcb05311b2934
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all,

Continued in this thread because the other one seems to be more about TLV
types and metric type numbers, whereas this is about
regeneration/forwarding.

To recap, in the current draft, there are 3 things that might change at
each hop:
- the metric value (happens in RREQ and RREP),
- adding/changing Validity Time using the Validity Time TLV (can happen in
RREQ and RREP),
- adding an address (and corresponding value in the AddressType TLV to
indicate how to interpret the address) to indicate the address from which
an RREP_Ack is expected, to accomplish the bidirectionality check (can
happen in RREP).

If we define a certain portion of the message as immutable and include the
ICV to verify that part, end to end:
- The metric value would be excluded from the ICV since it needs changing
at each hop.
- Would adding a Validity Time TLV at an intermediate hop be acceptable?
The whole TLV could be removed in order to calculate the ICV?
- Would adding an address cause issues for the ICV, because it's in the
address block? Could the rule be "if it contains an AckReq address, remove
it (and the corresponding value in the AddressType TLV), before checking
the ICV", is that OK? Or would we need to avoid touching the ICV'ed part of
the message altogether, maybe put the AckReq address in a separate Address
Block, with an extra AddressType TLV following that address block? Is there
a way to accomplish this?

Also, to be thorough, do we need to consider RERR messages while we discuss
regeneration vs forwarding?
- RERR (sent when a link breaks) is a way of saying "I've lost my route so
I'm telling others" and "you were my next hop, so now I've also lost my
route, I'll tell others", etc. It's going to be tailored at each step to
include the relevant routes that got deleted, it's not one message being
sent end-to-end like RREQ and RREP are.
- However, RERR (sent when a source of traffic is sending data on a route
which comes through you, and you want to tell the Packet Source's router to
delete the route) could be seen as an end-to-end message which all
intermediate routers learn from, similar to RREQ and RREP. It reports one
route, and doesn't need changing at intermediate hops, so could be
protected with ICV.
- Would it be OK to only require a message ICV if a PktSource address was
included, i.e. when the message needs to go via a number of intermediate
hops to PktSource's router? All other RERRs are intended to be one-hop
messages, which may in turn prompt other one-hop messages, etc..., and a
packet ICV might be more appropriate?

Kind regards,
Victoria.

On Thu, Mar 17, 2016 at 5:26 PM,  wrote:

>
> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
> Yes, I meant AODVv2, thanks for the catch.
>
> So is your (Thomas) proposed base specification a hop count only metric?
>
>
> No, the would be silly as base specification, given that hop count mostly
> is useless.
>
> As base specification I would simply say =E2=80=9CInclude a Metric Type M=
essage
> TLV with a value field, and a 7182 Message TLV & Timestamp=E2=80=9D as we=
 do in
> OLSRv2 (with the appropriate verbiage as to generation and processing).
>
> With the message generated by the originator of the RREQ/RREP and *not*
> deconstructed/reconstructed/reordered (as is the risk with =E2=80=9Cregen=
eration)
> allows knowing that it would be *only* that metric field being modified
> (other than hop count/limit) for when eventually writing up the extension=
.
>
>
> (Actually doesn=E2=80=99t the current specification only define hop count=
, or has
> that changed in latest draft?)
>
>
> No. That is one of the issues I raise in my original. For some reason, it
> cites RFC6551, which is a ROLL document and which has in its abstract tha=
t:
>
>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>    compared with traditional wired and ad hoc networks that require the
>    specification of new routing metrics and constraints.
>
>
> I.e. this document cites a metric document which clearly claims to be
> inapplicable in ad hoc networks. I note that this is another thing I=E2=
=80=99ve
> raised for years without seeing it attempted resolved.
>
> Best,
>
> Thomas
>
>
>
>
> *--*
>
>
>
>
> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
> ]
> *Sent:* 17 March 2016 17:10
> *To:* Dearlove, Christopher (UK)
> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
> **** 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 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
> OK, so we have a message that mutates by:
> - Modifying hop count/limit.
> - Modifying a metric value.
> Anything else?
>
> As mutating (other than hop count/limit) messages aren=E2=80=99t covered =
by 5444
> or any derivative document (but only recommended against, not banned) tha=
t
> you may need to make the message otherwise immutable (no deconstruction a=
nd
> rebuilding, other than guaranteed unchanging) that would have to be
> specified by AODVv2. (Easy to say, but needs saying.)
>
>
> With you so far.
>
>
> Then that information is not in a guaranteed fixed location given by a
> simple offset. So any signature algorithm that finds it and ignores it or
> aggregates on it is specific to OLSRv2.
>
> Surely you mean AODVv2
>
>
> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AODVv2
> specialised variant. Which is the sort of thing that the message specific
> TLV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cbut ig=
nore the value of
> this specific TLV should it occur=E2=80=9D being in the general space. Ho=
wever it
> can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like tha=
t TLV,
> except if an X TLV is present, set its value field to zero=E2=80=9D).
>
> Messy, but could work.
>
> Not that messy, actually, although clearly not as nice as =E2=80=9Cfixed =
offset=E2=80=9D.
>
> That said, I am arguing for the base spec being:
>
>             =E2=80=9Cmake the message otherwise immutable (no deconstruct=
ion and
> rebuilding, other
>              than guaranteed unchanging)=E2=80=9D which is afforded by fo=
rwarding
>
>                                     +
>
>             RFC7182 Timestamps and ICVs.
>
>                                     +
>
>             RFC7183 style text bringing it all together.
>
> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would ve=
ry be an
> experimental extension.
>
> What I object to is, if the base spec specifically renders such extension=
s
> impossible
>
>
>
>
>
> *--*
>
>
>
>
> *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:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
> ]
> *Sent:* 17 March 2016 16:48
> *To:* Dearlove, Christopher (UK)
> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
> **** 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
> .*
> Hi all,
>
>
> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com>:
>
> Good point about whether you just pass on one cost or a set of costs. As =
I
> said, not looked at details - I will, when time permits. One cost is much
> easier, and yes, it reduces the fixed size aggregated signatures problem =
to
> =E2=80=9Cjust=E2=80=9D one of computational load.
>
>
> For the record, Thomas=E2=80=99 understanding is correct; the cost is one
> aggregated value.
>
> Best regards,
> Lotte Steenrbink
>
>
>
>
>
> *--*
>
>
>
>
> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
> ]
> *Sent:* 17 March 2016 16:38
> *To:* Dearlove, Christopher (UK)
> *Cc:* Mobile Ad Hoc Networks mailing list
> *Subject:* Re: Message integrity and message mutability (was RE: [manet]
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
> **** 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 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
> I appreciate Thomas=E2=80=99s comments about the limitations of message
> regeneration, but I would be a bit less absolute.
>
> The issues over end to end authentication and more advanced signatures ar=
e
> valid. I need to read the given reference on aggregate signatures to
> increase my knowledge (thanks for it), but my understanding of the
> possibilities in this field may offer a solution to the problem, but with
> some other issues (possibly including a new type of TLV).
>
> But the hop count/limit point I don=E2=80=99t fully agree with, you can r=
egenerate
> with an incremented/decremented count/limit, which leaves the ability to
> prevent messages propagating indefinitely, including expanding ring
> searches, and retains the ability to use RFC 5497 interval and validity
> times that might be useful with an expanding ring search (or might not).
>
> But the key issue is that AODVv2 wants to accumulate metrics. I still
> haven=E2=80=99t got to the bottom of many details here, but let=E2=80=99s=
 for the moment
> just consider that conceptually.
>
> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft attempts =
to do an end to
> end of some information, not this information. I=E2=80=99m not sure if th=
at=E2=80=99s
> useful (and the specialised format is better avoided if possible). Other
> approaches are hop by hop (might as well use packet signatures) and share=
d
> key (might as well go hop by hop). Pairwise signatures for each pair of
> routers I=E2=80=99m discounting as scaling terribly. In the interests of
> completeness let=E2=80=99s mention not accumulating metrics, which puts u=
s back to
> hop count and that=E2=80=99s not ideal either.
>
> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=80=
=99ve seen about
> aggregating, but that has some issues of its own, even apart from
> computational load.) I=E2=80=99d love to be proved wrong - someone with t=
he perfect
> solution to come along.
>
> Which means that either we make an arbitrary choice - which will be
> disagreed with, but needs discussing first - or create something flexible=
.
> Unfortunately flexible in that regard constrains in others, e.g. some
> (many? most?) aggregating signatures need fixed data sizes (which we can =
do
> by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but tha=
t has a cost too).
>
>
> I have been told by people much more well versed in this than I in
> cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>
> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does th=
at mean that the
> message grows as it is being forwarded, and that the recipient of a
> RREQ/RREP will know the individual costs of each path segment? My
> understanding is, that the recipient will get =E2=80=9Cthe sum the costs =
of each
> path segment=E2=80=9D which should be fitting within a fixed size?
>
> Thomas
>
>
>
>
>
>
> Sorry, no answers, just comments. And I=E2=80=99m not addressing Thomas=
=E2=80=99s later
> points here.
>
>
> *--*
>
>
>
>
> *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 *ietf@thomasclausen.org
> *Sent:* 17 March 2016 16:00
> *To:* Mobile Ad Hoc Networks mailing list
> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of big
> ticket Items
>
>
> **** 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.
>
> Dear all,
>
> Apologies for not having gotten this done sooner - day-job leaving few
> spare cycles.
>
> I=E2=80=99ve previously offered reviews and comments, and some of those h=
ave been
> addressed in the latest I-D =E2=80=94 others have not, but should be. I r=
ecall that
> there was some mail attempting to rebut parts of the review, and I will d=
ig
> it out and reply to that.
>
> With that being said, I have reviewed the latest version of the document,
> and full details will be forthcoming. There=E2=80=99re a couple of
> big-ticket/architectural items that I want to address up front, as I
> believe that before we have those hammered out, it will be useless to go
> into details. Note, I do not claim that this is an exhaustive list of =E2=
=80=9Cbig
> ticket items=E2=80=9D, but that=E2=80=99s as far as I have gotten in thin=
king this through.
>
> I also bring these up as they are items that have been brought up
> repeatedly over the past years, but not resolved nor discussed.
>
> *Loops*
> Just to bring this out: I share Chris=E2=80=99 worry about conflicting an=
d
> concurrent statements from the authors on =E2=80=9CThere are no loops pos=
sible=E2=80=9D and
> =E2=80=9CWe need to fix two situations where loops can occur=E2=80=9D and=
 =E2=80=9Cwe are still
> investigating some loop conditions=E2=80=9D
>
> I particularly worry that this is not a discussion had in public, but
> apparently in some other forum=E2=80=A6
>
>
> *Intermediate Route Replies, and all of section 10*
> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=80=
=9D, which is
> incoherent with the intended status indicated for this document.
>
> Specifically, and this is not unrelated to the point about loops above,
> intermediate RREPs (section 10.3) are a potential source for loops.
>
> Expanding Ring Multicast (section 10.1) is not documented in a way that
> can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=E2=
=80=9D below, it is
> in the present form of this protocol impossible), etc.
>
>
> *Forwarding-vs-regeneration*
> Recent exchanges on the list made me understand that protocol control
> messages are *not* forwarded, but are consumed at each hop, then a new
> message with (almost-but-not-quite) the same content is generated and
> transmitted.
>
> I have thought some more on this (& read some of the exchanges on the lis=
t
> on this topic by Chris, Ulrich, and others), and I am convinced that this
> is not the right way to go, *at least* for the following reasons:
>
>
>             o          *It renders the hop-limit/hop-count fields in the
> RFC5444 message header useless.*
>                         This would not be bad if the functionality
> offered by those fields was not useful
>                         =E2=80=94 sadly, it is. For example, for scope li=
mited
> flooding (expanding ring search, and
>                         such) which may be of interest, and which require
> hop-limit.
>                         A hop-count field may also provide a =E2=80=9Cche=
ap=E2=80=9D (in
> terms of overhead) additional piece
>                         of information to use conjunctively with a =E2=80=
=9Creal=E2=80=9D
> metric.
>
>                         The only practical solution would be to
> re-introduce these functions by way of inserting a
>                         MessageTLV =E2=80=94 which (i) is not specified i=
n this
> document, and (ii) which would just
>                         serve to render messages bigger than strictly
> needed.
>
>                         Scope limited flooding  does seem to be a
> necessary requirement, if for no
>                         other reason than to prevent information from
> =E2=80=9Ccirculating forever in the network=E2=80=9D.
>
>             o          *It makes end-to-end authentication unnecessarily
> hard.*
>                         I think Chris called this out already, but it
> bears repeating: S generates a message
>                         (say, a RREQ), and includes an ICV calculated
> over the content of the message.
>                         For any recipient to be able to validate the ICV,
> the message has to be exactly
>                         the same =E2=80=94 not just in content, but in st=
ructure
> =E2=80=94 as what was generated.
>
>                         =E2=80=9CRegenerating=E2=80=9D rather than =E2=80=
=9Cforwarding=E2=80=9D messages
> means, that the intermediate
>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ ma=
y chose a
> different structure (e.g., include TLVs
>                         in a different order).
>
>                         The proposal from
> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>                         is to add constraints on (i) the set of elements
> to include in a signature and (ii) the
>                         order of these elements.
>
>                         One problem with that approach is (i): if an
> extension adds a message TLV, or an
>                         Address TLV, to a message, then that will not be
> =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>                         Rather for *each* extension developed, an
> =E2=80=9Cupdates e2esec=E2=80=9D clause needs to be done.
>
>                         I=E2=80=99d say that this approach would be prone=
 to
> errors =E2=80=94 and add entropy to the process
>                         of designing protocol extensions. The
> alternative, a message being generated by the
>                         source and *forwarded* (as we do in OLSRv2, for
> example) would allow ICV TLVs
>                         (even, allow reuse of those specified for OLSRv2)
> for covering a message and
>                         extensions.
>
>                         =E2=80=9CBut what about the metrics value which w=
ill
> change on each hop=E2=80=9D, you may say?
>                         Fortunately, that is relatively easy to handle:
> simply zero out the value of that TLV when
>                         generating or verifying the ICV MessageTLV. And
> use Packet-TLVs for hop-by-hop
>                         authentication, if needed (but, see below).
>
>             o          *It prevents the use of more clever/advanced
> signature schemes/ICVs*
>                         Aggregate signature algorithms (
> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>                         exist, and an interesting use-case can be found
> in also reactive protocols, allowing verifying
>                         not =E2=80=9Cjust=E2=80=9D the end points, but al=
so the
> intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D
>                         discussed above, or something smarter).
>                         Regeneration of messages, rather than forwarding,
> renders that impossible (or, if used,
>                         updating to
> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>
> There are other reasons, but the above are those that jump at me as
> immediate show-stoppers.
>
> I do honestly not see what possible benefit there is from =E2=80=9Cregene=
ration=E2=80=9D =E2=80=94
> but I see very clear inconveniences, and security is not the least of
> these. Insisting on =E2=80=9Cregeneration=E2=80=9D requires development o=
f =E2=80=9Cnon-general
> workarounds=E2=80=9D as pointed out above.
>
> *Security Considerations*
> This is an always thorny subject. When OLSRv2 was going through the
> process we got a thorough education in how little we knew about security
> from the SEC-ADs, and had to spend about a year or so developing RFC7183.
> The bottom line is, that this protocol needs its =E2=80=9CRFC7183  equiva=
lent=E2=80=9D,
> either as part of the main document, or as an independent document.
> currently, that is not the case.
>
> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration from R=
FC7183
> might be aw good idea, as that was the most recent that went through the
> SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to implement=E2=
=80=9D security
> mechanism most be specified (I think the right term was =E2=80=9CMUST imp=
lement,
> SHOULD use=E2=80=9D), in sufficient detail to ensure interoperable implem=
entations.
>
> As an example, both [RFC6130] and [RFC7181] set out that that:
>
>       On receiving a ... message, a router MUST first check if the
>       message is invalid for processing by this router
>
> and then proceed to give a number of conditions that, each, will lead to =
a
> rejection of the message as "badly formed and therefore invalid for
> processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That gav=
e a =E2=80=9Chook=E2=80=9D for
> RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message gener=
ation.
>
> If I was to do RFC7181/RFC6130 today, I would include that directly into
> the protocol specifications. It turned out to be more overhead (and slow
> down publication anyways) to do it as separate documents.
>
> Secondly, we need to be a lot more rigid in terms of what ICVs,
> Timestamps, etc. are added/removed, and what that brings.
>
> For example (with the assumption that messages are *forwarded* and *not*
> regenerated), this could be one option:
>
>                         o          When a RREQ, RREP message is
> generated, add an ICV Message TLV, which is calculated 
>                                      =E2=80=A6(take inspiration from RFC7=
183 here)
>
>
> ...
>
> [Message clipped]
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>

--94eb2c122e52c3edcb05311b2934
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi all,

Continued =
in this thread because the other one seems to be more about TLV types and m=
etric type numbers, whereas this is about regeneration/forwarding.

To recap, in the current draft, there are 3 things that mi=
ght change at each hop: 
- the metric value (happens in RREQ and RREP), =

- adding/changing Validity Time using the Validity Time TLV (can happen=
 in RREQ and RREP), 
-
 adding an address (and corresponding value in the AddressType TLV to indic=
ate how to interpret the address) to=20
indicate the address from which an RREP_Ack is expected, to accomplish=20
the bidirectionality check (can happen in RREP).

If we define=C2=A0a=
 certain portion of the message as immutable and include the ICV to verify =
that part, end to end: 
- The metric value would be excluded from the IC=
V since it needs changing at each hop.=C2=A0
- Would adding a Validity T=
ime TLV at an intermediate hop be acceptable? The whole TLV could be remove=
d in order to calculate the ICV?
- Would adding an address cause i=
ssues for the ICV, because it's in the address block? Could the rule be=
 "if it contains an AckReq address, remove it (and the corresponding v=
alue in the AddressType TLV), before checking the ICV", is that OK? Or=
 would we need to avoid touching the ICV'ed part of the message altoget=
her, maybe put the AckReq address in a separate Address Block, with an extr=
a AddressType TLV following that address block? Is there a way to accomplis=
h this?

Also, to be thorough, do we need to consid=
er RERR messages while we discuss regeneration vs forwarding?=C2=A0
- RERR (sent when a link breaks) is a way of saying "I've lost =
my route so I'm telling others" and "you were my next hop, so=
=C2=A0now=C2=A0I've also lost my route, I'll tell others", etc=
. It's going to be tailored at each step to include the relevant routes=
 that got deleted, it's not one message being sent end-to-end like RREQ=
 and RREP are.=C2=A0
- However, RERR (sent when a source of t=
raffic is sending data on a route which comes through you, and you want to =
tell the Packet Source's router to delete the route) could be seen as a=
n end-to-end message which all intermediate routers learn from, similar to =
RREQ and RREP. It reports one route, and doesn't need changing at inter=
mediate hops, so could be protected with ICV.
- Would it be OK to=
 only require a message ICV if a PktSource address was included, i.e. when =
the message needs to go via a number of intermediate hops to PktSource'=
s router? All other RERRs are intended to be one-hop messages, which may in=
 turn prompt other one-hop messages, etc..., and a packet ICV might be more=
 appropriate?

Kind regards,
Victoria.

On Apr 20, 2016, at 12:30, =
Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

Can I just say it=E2=80=99s quite hard to =
work out who is saying what in these exchanges. I=E2=80=99m having to =
guess some on the basis of =E2=80=9Cthat sounds like Thomas=E2=80=9D or =
=E2=80=9Cthat sounds like Lotte=E2=80=9D.

I think that your MUA is slightly broken, then, but =
when I have doubts I hit the archives, which correctly shows who says =
what =E2=80=94 here=E2=80=99s the archive for the message in =
question:



 
What I=E2=80=99m not =
clear on is what conclusion, if any, you=E2=80=99ve drawn on hop =
count/limit.
 
As I see it, if the =
protocol receives a message then sends a message similar but not =
identical to that out, that can be reviewed as creating a new message. =
It is a new message as far as 7182 is =
concerned.

Hence why I wrote (or, I think I wrote) 7182-derived =
TLV.

 
But the protocol could =
impose some restrictions. For example =E2=80=9Cthe only thing allowed to =
be changed is this field in this TLV=E2=80=9D. Which it would therefore =
be a good idea for the creator of the message to include, even if it =
thus needed to include a link metric of zero. (Which is a design point - =
you might need to allow that in metric specification.) But you would =
need to state that. That enables some future designs - not 7182, =
possibly an extension to 7182, possibly something new. =


YES, =
that=E2=80=99s my point.

There is a problem that =
this idea would be putting in a need to understand specific TLVs, which =
is undesirable. I have some ideas there, such as using the =
protocol-specific space, but this isn=E2=80=99t a five minute job, and =
needs to be got right. While now is not the time to define this, some =
decisions could really impact on future designs. For example putting =
anything wanting to be mutable stuck in the middle of all the other TLVs =
would be constraining. Making all intended to be mutable by this =
protocol TLVs in the protocol specific space is probably the least bad =
idea, as that could be generalised (either making that space not covered =
by this hypothetical 7182 variant, or splitting =
it).

My =
position on that would be =E2=80=9Cnever change the structure of the =
message in transit=E2=80=9D and =E2=80=9Cnever change the length on a =
TLV in transit=E2=80=9D, and you=E2=80=99d have done a fairly good job =
of making it possible to do *something* clever for ICVs: the mutating =
field, which would be in a fixed position in the byte stream, you could =
zero that out, or do something else. 7182 does not do that. But =
something else might.

Not having =
that constraint means that =E2=80=9Csomething else=E2=80=9D would be =
impossible, would impede on extensibility.

 
That leaves hop =
count/limit. Technically you wouldn=E2=80=99t increment/decrement, as =
it=E2=80=99s a new message. But you can send any hop limit on any new =
message, so that could be one less than the one you received. Hop count =
is a bit more arguable. I=E2=80=99m not sure how clearly its meaning is =
indicated, whether it is a =E2=80=9Creal=E2=80=9D hop count of this =
message. But if you needed to I wouldn=E2=80=99t be too strongly against =
doing what looks like incrementing that, as long as carefully =
explained.

Yes, I agree that that can be arguable.

Again, here my position is: if you change the =
slightest in the *structure* of the message, then a hop-count increment =
would be invalid (illegal? ;) ) 

Which is to say: regeneration =3D> don=E2=80=99t =
use hop-count/hop-limit (in my opinion).

 (A key question is if you use 5497 TLVs. =
In that case I think - combined with the =E2=80=9Conly change one thing =
above=E2=80=9D that you need to appear to increment hop limit, i.e. =
create a new message with a non-zero hop =
count.

Indeed, good catch. This document does, indeed, cite =
RFC5497 normatively. I=E2=80=99d not seen that interaction, but you are =
right it has to be matched up. I=E2=80=99ve not checked that/if it =
is.

Best,

Thomas

 
--
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 =
Clausen
Sent: 20 April 2016 10:55
To: Lotte Steenbrink
Cc: Mobile Ad Hoc Networks =
mailing list
Subject: [manet] On =
Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review =
- a couple of big ticket Items)
 
 
*** 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.
 
Lotte, all,
 
On 19 Mar 2016, at 12:34, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:
Hi Thomas,
thank you for =
reviewing AODVv2 yet again :) Some answers below:
 
Am 17.03.2016 um =
17:00 schrieb ietf@thomasclausen.org:
 
Dear all,
 
Apologies for not having gotten this done sooner - =
day-job leaving few spare cycles.
 
I=E2=80=99ve previously offered reviews and comments, =
and some of those have been addressed in the latest I-D =E2=80=94 others =
have not, but should be. I recall that there was some mail attempting to =
rebut parts of the review, and I will dig it out and reply to that.
 
 
That wold be great.
 
I am finding a bit of time here and there when there are =
holes in the agenda, and am (as you likely have noticed) backtracking =
through emails when I get a chance. Apologies, I hope that I will get to =
these emails this, or next week, but day-job eats in to the available =
time ;(


Forwarding-vs-regeneration
Recent exchanges on the list made me understand that protocol =
control messages are *not* forwarded, but are consumed at each hop, then =
a new message with (almost-but-not-quite) the same content is generated =
and transmitted.
 
That=E2=80=99s what we=E2=80=99ve been trying to say =
all along! I=E2=80=99m really glad we=E2=80=99re having this =
conversation.
 
Then, let us have it -- it's a central point to get =
right.


I have thought some more on this (& =
read some of the exchanges on the list on this topic by Chris, Ulrich, =
and others), and I am convinced that this is not the right way to =
go, at least for the following reasons:
 
 
        &=
nbsp;   o        &=
nbsp; It renders the hop-limit/hop-count fields in the RFC5444 =
message header useless.
        &=
nbsp;           &nb=
sp;   This would not be =
bad if the functionality offered by those fields was not useful
        &=
nbsp;           &nb=
sp;   =E2=80=94 sadly, it =
is. For example, for scope limited flooding (expanding ring search, =
and 
        &=
nbsp;           &nb=
sp;   such) which may be =
of interest, and which require hop-limit. 
        &=
nbsp;           &nb=
sp;   A=
 hop-count field may also provide a =E2=80=9Ccheap=E2=80=9D (in terms of =
overhead) additional piece
        &=
nbsp;           &nb=
sp;   of information to =
use conjunctively with a =E2=80=9Creal=E2=80=9D metric.
 
 
I agree on the usefulness, which is why we were =
puzzled when we were told we weren=E2=80=99t allowed to use those fields =
(or, rather, that we were using them wrong, but that the right way to =
use them doesn=E2=80=99t work for AODvv2). I believe Vicky has written =
about this in more detail in previous discussions, and we were/are =
looking forward to reading your answers...
 
So, the source generates a message, the message is forwarded =
through the network, with each intermediate router decrementing the hop =
limit and incrementing the hop count.
 
As stated in the 5444-Usage document, =
when forwarding a message, the hop-limit/hop-count are modified, the =
rest of the message SHOULD not be. 
 
That is specifically, one thing where I =
kinda would like 5444-usage to go further is "the message structure MUST =
in all conditions preserved when forwarding" - but still say "and it is =
RECOMMENDED that the value field of TLVs are also not modified".
 
What this buys is several things, in the =
context of this protocol:
 
        &=
nbsp;   o        &=
nbsp; hop-limit/hop-count =
could be useful for the usual 
        &=
nbsp;           &nb=
sp;   purposes (ensuring =
that messages do not live forever, 
        &=
nbsp;           &nb=
sp;   scope-limited =
flooding, ...)
 
        &=
nbsp;   o        &=
nbsp; if the =
accumulated path metric is stored in a TLV value field, that 
        &=
nbsp;           &nb=
sp;   value field can =
(with suitable disclaimer to call out "we know it is
        &=
nbsp;           &nb=
sp;   RECOMMENDED to not =
do this, but here's why we are OK in doing
        &=
nbsp;           &nb=
sp;   it anyways") be =
modified when forwarding the message, and
 
        &=
nbsp;   o        &=
nbsp; as that =
path metric field is in a message whose structure does not
        &=
nbsp;           &nb=
sp;   change, it will be =
"at the same place in the byte-stream" at each hop,
        &=
nbsp;           &nb=
sp;   which
        &=
nbsp;   
        &=
nbsp;   o        &=
nbsp; allows =
useful things such as deriving from RFC7182 a form of
        &=
nbsp;           &nb=
sp;   "when calculating =
the ICV, zero out that field in the message ' when
        &=
nbsp;           &nb=
sp;     validating an =
ICV, also zero out that field" -- which goes one step
        &=
nbsp;           &nb=
sp;     further (when =
coupled with a time stamp) than simple transitive trust, 
        &=
nbsp;           &nb=
sp;     but also
 
        &=
nbsp;   o        &=
nbsp; allows =
even more fancy and useful (albeit experimental) things such
        &=
nbsp;           &nb=
sp;   as aggregate =
signatures to work correctly.
 
Furthermore.....


        &=
nbsp;           &nb=
sp;   The only practical =
solution would be to re-introduce these functions by way of inserting =
a
        &=
nbsp;           &nb=
sp;   MessageTLV =E2=80=94 =
which (i) is not specified in this document, and (ii) which would =
just
        &=
nbsp;           &nb=
sp;   serve to render =
messages bigger than strictly needed.
 
Exactly; we=E2=80=99d really like to avoid this as =
well.
 
 
... It avoids the above, and....


 
        &=
nbsp;           &nb=
sp;   Scope limited =
flooding  does seem to be a necessary requirement, if for no
        &=
nbsp;           &nb=
sp;   other reason than to =
prevent information from =E2=80=9Ccirculating forever in the =
network=E2=80=9D.
 
AODVv2=E2=80=99s duplicated detection hopefully =
should take care of that. Iirc, We interpreted your earlier E-Mails to =
(implicitly) mean that you think we should rely on that, since you said =
we can=E2=80=99t use the hop-limit/hop-count fields.
 
 
....if done (proper forwarding with preservation of the =
structure, rather than regeneration which opens up the "this is a new =
message with potentially new structure" can of worms) as I describe, =
also addresses the above.
 
With respect to what I said earlier when I said =
"can't use hop-limit/hop-count fields"....when you regenerate, you =
absolutely, definitely, can't.


When you "regenerate" a message, that =
means "you construct a brand new message" which may shuffle addresses =
inside address blocks, or between address blocks, shuffle TLVs =
differently than they were originally, even use TLVs of different =
structure (e.g., single-value TLVs instead of multi-value =
TLVs). 


This means that some assumptions (such as when producing an =
ICV for the message, which depends on the byte order) don't hold. Well, =
they may not hold, so that means we can't assume that they do. Which =
means that the originator of a message cannot generate an ICV that can =
be correctly interpreted (which is what my next section in my original =
mail was about).


Which means, in conclusion,  that the information in the =
message profoundly change -- and therefore these hop-count/hop-limit =
values do not even apply to "the information". 


However if proper forwarding with preservation of the =
structure, rather than regeneration which opens up the "this is a new =
message with potentially new structure" can of worms, as I (& Ulrich =
& others) have suggested, is taken to heart, it also addresses the =
issue below regarding end-to-end authentication (which, while still =
hard, is possible).


A couple of more comments below


 
        &=
nbsp;   o        &=
nbsp; It makes end-to-end authentication =
unnecessarily hard.
        &=
nbsp;           &nb=
sp;   I=
 think Chris called this out already, but it bears repeating: S =
generates a message 
        &=
nbsp;           &nb=
sp;   (say, a RREQ), and =
includes an ICV calculated over the content of the message.
        &=
nbsp;           &nb=
sp;   For any recipient to =
be able to validate the ICV, the message has to be exactly
        &=
nbsp;           &nb=
sp;   the same =E2=80=94 =
not just in content, but in structure =E2=80=94 as what was =
generated.
 
        &=
nbsp;           &nb=
sp;   =E2=80=9CRegenerating=E2=
=80=9D rather than =E2=80=9Cforwarding=E2=80=9D messages means, that the =
intermediate
        &=
nbsp;           &nb=
sp;   router =
=E2=80=9Cregenerating=E2=80=9D the RREQ may chose a different structure =
(e.g., include TLVs
        &=
nbsp;           &nb=
sp;   in a different =
order).
 
        &=
nbsp;           &nb=
sp;   The proposal =
from https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00<=
/a>
        &=
nbsp;           &nb=
sp;   is to add =
constraints on (i) the set of elements to include in a signature and =
(ii) the
        &=
nbsp;           &nb=
sp;   order of these =
elements.
 
        &=
nbsp;           &nb=
sp;   One problem =
with that approach is (i): if an extension adds a message TLV, or =
an 
        &=
nbsp;           &nb=
sp;   Address TLV, to a =
message, then that will not be =E2=80=9Ccovered=E2=80=9D by the proposed =
e2esec TLV.
        &=
nbsp;           &nb=
sp;   Rather for *each* =
extension developed, an =E2=80=9Cupdates e2esec=E2=80=9D clause needs to =
be done.
 
        &=
nbsp;           &nb=
sp;   I=E2=80=99d say that =
this approach would be prone to errors =E2=80=94 and add entropy to the =
process
        &=
nbsp;           &nb=
sp;   of designing =
protocol extensions. The alternative, a message being generated by =
the
        &=
nbsp;           &nb=
sp;   source and =
*forwarded* (as we do in OLSRv2, for example) would allow ICV =
TLVs 
        &=
nbsp;           &nb=
sp;   (even, allow reuse =
of those specified for OLSRv2) for covering a message and 
        &=
nbsp;           &nb=
sp;   =E2=80=9CBut what =
about the metrics value which will change on each hop=E2=80=9D, you may =
say?
        &=
nbsp;           &nb=
sp;   Fortunately, that is =
relatively easy to handle: simply zero out the value of that TLV =
when
        &=
nbsp;           &nb=
sp;   generating or =
verifying the ICV MessageTLV. And use Packet-TLVs for =
hop-by-hop 
        &=
nbsp;           &nb=
sp;   authentication, if =
needed (but, see below).
 
        &=
nbsp;   o        &=
nbsp; It prevents the use of more clever/advanced =
signature schemes/ICVs
        &=
nbsp;           &nb=
sp;   Aggregate signature =
algorithms ( https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
        &=
nbsp;           &nb=
sp;   exist, and an =
interesting use-case can be found in also reactive protocols, allowing =
verifying
        &=
nbsp;           &nb=
sp;   not =E2=80=9Cjust=E2=80=
=9D the end points, but also the intermediaries (again, with the =
appropriate =E2=80=9Czero out=E2=80=9D
        &=
nbsp;           &nb=
sp;   discussed above, or =
something smarter).
        &=
nbsp;           &nb=
sp;   Regeneration of =
messages, rather than forwarding, renders that impossible (or, if =
used,
        &=
nbsp;           &nb=
sp;   updating to  https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00<=
/a>)
 
There are other reasons, but the above are those that =
jump at me as immediate show-stoppers.
I do honestly not see what possible =
benefit there is from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see =
very clear inconveniences, and security is not the least of these. =
Insisting on =E2=80=9Cregeneration=E2=80=9D requires development of =
=E2=80=9Cnon-general workarounds=E2=80=9D as pointed out above.
 
The possible benefit is that we need to accumulate =
& transport metric values somehow, and we can=E2=80=99t do that =
without regenerating at least parts of the message.
 
Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) =
<chris.dearlove@baesystems.com>:

I =
have no problem with that. I was trying to lay out the issues without =
muddying the water with my preference.
 
--
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: 22 =
April 2016 15:35
To: Dearlove, Christopher =
(UK)
Cc: Thomas Heide Clausen; =
Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] On =
Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review =
- a couple of big ticket Items)
 
 
*** 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.
Speaking as participant.

I kind of like the idea of using the experimental message =
type space.  We only have a limited amount of these message =
types.  The TLV assignments could just use the message type =
specific space and there isn't an issue there.  IANA wouldn't =
assign a number but I don't see why the document couldn't specify the =
experimental numbers it was going to use so other future near term =
experiential protocols could do the same and generally avoid =
conflict.  If the experiment is successful IANA assignments could =
be made.  Functionally no real difference with protections vs long =
term usage of limited space.
 
Justin
 
On Fri, Apr 22, 2016 =
at 9:35 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
There's rather a contradiction between the concepts of a =
definition of a protocol, even Experimental, and experimental space, =
which usually assumes that the user can do what he or she likes in =
it.

But chewing up messages types (how =
many, 3?) of which there are relatively few for experimental is long =
term a problem, although short term not.

TLV =
space is easier in two regards. It's bigger (though the prime real =
estate of type extension zero isn't) and can have message type specific =
TLVs.

So TLVS can actually be invisible, if =
that option is chosen. For messages something has to give. Least bad =
option is again one of those we should discuss, but time ...

(To be precise, messages types from 224 are =
defined in RFC 5444 as " Experimental Use", of which BCP 26 says =
"Similar to private or local use only, with the  purpose being to =
facilitate experimentation." The alternative 0-223 space is Expert =
Review. IANA still thinks the experts are Joe Macker and the recused =
Stan Ratliff. But that's a soluble nit.)

--
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


-----Original =
Message-----
From: Thomas Heide =
Clausen [mailto:ietf@thomasclausen.org]
Sent: 22 April 2016 14:21
To: Dearlove, Christopher (UK)
Cc: Lotte Steenbrink; Mobile Ad Hoc =
Networks mailing list
Subject: Re: [manet] On =
Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review =
- a couple of big ticket Items)

----------------------! WARNING ! ---------------------- This =
message originates from outside our organisation, either from an =
external partner or from the internet.
Consider carefully =
whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for =
instructions on reporting suspicious email messages.
--------------------------------------------------------


> On 22 avr. 2016, at 15:05, =
Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
>
> Once you're entirely in AODV2's own =
space, and AODVv2 is experimental (working assumption for this =
discussion) you have more liberty.
>

Yep.

Taken somewhat by surprise =
both by the sudden "rush" and the experimental maturity level, I am =
wondering (and haven't thought through) about experimental space vs =
non-experimental (for message types, and consequently for message type =
specific TLV types).

I think that if the =
AODVv2 experiment specifies the use of Message types from the =
Experimental message type space without making actual registrations in =
the IANA registry, AND the use of type specific TLV types, this becomes =
a non-issue entirely (by design, this is precisely what that =
experimental space is for)

Whereas, as you =
point out, the alternative is a "can open - worms everywhere" situation =
that I think time is too short to solve?

Thomas


> Then =
you could try specifying it. But with a very good chance of producing =
something you later decide you should have done differently.
>
> I honestly don't know which would go =
down better (or less badly) - "here's a mechanism we haven't really =
thought through in detail, but at least we've defined one", or "we know =
the sort of thing we want, and we'll describe it, but rather than =
produce something not quite right, we'll not go further".
>
> --
> 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
>
>
> -----Original Message-----
> From: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]
> Sent: =
22 April 2016 13:59
> To: Mobile Ad Hoc Networks =
mailing list
> Cc: Henning Rogge; Dearlove, Christopher =
(UK)
> Subject: Re: [manet] On =
Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review =
- a couple of big ticket Items)
>
> =
----------------------! WARNING ! ---------------------- This message =
originates from outside our organisation, either from an external =
partner or from the internet.
> Consider carefully =
whether you should click on any links, open any attachments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters =
for instructions on reporting suspicious email messages.
> =
--------------------------------------------------------
>
> Hello Christopher,
>
>> Am 22.04.2016 um 11:57 schrieb =
Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>:
>>
>> Just be careful to note that =
this concept is as currently being discussed (a) specific to AODVv2, and =
(b) not an application of 7182, which has no knowledge of special =
TLVs.
>>
>> This is something =
we'd want to get right, and need to get right if in any space not =
specific to ADODVv2, because getting it wrong produces future =
problems.
>
> Makes sense.
>
>> I can see some possible =
approaches, none is ideal and we're rather out
>> of =
time to specify. But this is experimental, so I think we might be
>> able to indicate the shape of the solution without =
specifying it,
>> which would be a different RFC, =
under a bit less time pressure.
>> (Extensions to =
existing protocols like 7182 would naturally be in
>> =
scope rechartered I think.)
>>
>> =
To indicate the range that's open, here are two possible ideas, one of =
which has an impact now, so needs to be agreed. Note that I'm not =
suggesting (in fact quite the opposite) defining an extension to 7182 =
here, rather enabling such an extension, if written, to "do the right =
thing".
>> - We have an extension to 7182 that says =
"zero out all value octets in protocol specific TLVs. That requires now =
putting the AODVv2 metric TLV in that space.
>
> Just to make sure that I understood you correctly=E2=80=93=
 =E2=80=9Cthat space=E2=80=9D meaning making the AODVv2 metric TLV =
protocol specific? (By =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m=
 referring to the generic TLV we=E2=80=99ve been talking about on this =
list earlier this week).
>
>> - We =
have an extension to 7182 that adds extra material to the value field =
that indicates (TBD how, by position with sanity check that this is TLV =
value perhaps?) which octets are to be zeroed out before the ICV is =
calculated.
>
> The way I understand =
that approach, it wouldn=E2=80=99t warrant any action from AODVv2 =
besides saying =E2=80=9Cif you calculate the ICV, set the Metric value =
to zero=E2=80=9D (leaving the nitty gritty of how this would be done in =
detail to future work)=E2=80=A6 Is that correct?
>
>>
>> We do not have the time to =
specify this in an acceptable manner within two weeks though. But the =
security consideration section could say something along the lines of =
"this enables the use of an ICV defined to zero out these octets=E2=80=9C.=

>
> Okay. :)
>
> Best regards,
> Lotte
>
>>
>> --
>> 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
>>
>> -----Original Message-----
>> From: manet [mailto:manet-bounces@ietf.org] On =
Behalf Of Lotte
>> Steenbrink
>> =
Sent: 22 April 2016 10:28
>> To: Henning Rogge
>> Cc: Mobile Ad Hoc Networks mailing list
>> Subject: Re: [manet] On Forwarding-and-regeneration =
(was: Re:
>> draft-ietf-manet-aodvv2-13 review - a =
couple of big ticket Items)
>>
>> =
----------------------! WARNING ! ---------------------- This message =
originates from outside our organisation, either from an external =
partner or from the internet.
>> Consider carefully =
whether you should click on any links, open any attachments or reply.
>> Follow the 'Report Suspicious Emails' link on IT =
matters for instructions on reporting suspicious email messages.
>> =
--------------------------------------------------------
>>
>> *** WARNING ***
>> EXTERNAL EMAIL -- This message originates from =
outside our organization.
>>
>>>> Hi Henning,
>>
>>> Am 22.04.2016 um 11:08 schrieb Henning Rogge =
<hrogge@gmail.com>:
>>>
>>> On Fri, Apr 22, 2016 =
at 11:05 AM, Lotte Steenbrink
>>> <lotte.steenbrink@fu-berlin.de> wrote:
>>>> Hi Thomas,
>>>> =
Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=E2=80=9D=
 language
>>>> in the first place is that =
we=E2=80=99ve been told that whenever one bit in
>>>> the message (apart from its header) is =
changed, the entire thing has to be regenerated.
>>>> I=E2=80=99m starting to get the feeling =
we=E2=80=99ve just been misunderstanding
>>>> =
each other for more than a year. :( Anyway, it seems like we=E2=80=99re>>>> getting close now, so yay.
>>>
>>> "Modifying" the =
binary message instead of parsing and generating a
>>> new one will be difficult as soon someone writes =
an extension to
>>> AODVv2 that adds more TLVs to =
the message.
>>
>> D=E2=80=99oh, =
right. Yeah, if I remember it correctly, that=E2=80=99s what you =
explained to me when I got confused about the topic last spring=E2=80=A6 =
But=E2=80=93 even if a message contains TLVs that the AODVv2 =
implementation handling it doesn=E2=80=99t understand, it will still be =
able to recognize the Metric TLV, right? Isn=E2=80=99t that the nifty =
thing about RFC5444? So, while we really shouldn=E2=80=99t write =
=E2=80=9Cbefore calculating the ICV, set the n-th 4 octets to 0=E2=80=9D, =
we might say =E2=80=9Cidentify the octets that make up the metric value =
and set those to 0=E2=80=9D?
>>
>>=
 Best regards,
>> Lotte
>>
>>> Henning Rogge
>>
>> _______________________________________________
>> 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
 
_______________________________________________
manet mailing =
list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

On Thu, Mar 17, =
2016 at 5:26 PM,  <ietf@thomasclausen.org> wrote:

<=
blockquote type=3D"cite">
On 17 Mar 2016, at 18:17, Dearlove, Christoph=
er (UK) <chris.dearlove@baesystems.com> wrote:

Yes, I meant AODVv2, thanks for the catch.
=C2=A0
<=
div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">So is your (Thomas) proposed base specificati=
on a hop count only metric?

No, the woul=
d be silly as base specification, given that hop count mostly is useless.

As base specification I would simply say =E2=80=9CI=
nclude a Metric Type Message TLV with a value field, and a 7182 Message TLV=
 & Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage=
 as to generation and processing).=C2=A0

With the =
message generated by the originator of the RREQ/RREP and *not* deconstructe=
d/reconstructed/reordered (as is the risk with =E2=80=9Cregeneration) allow=
s knowing that it would be *only* that metric field being modified (other t=
han hop count/limit) for when eventually writing up the extension.
=C2=A0
(Actually doesn=E2=80=99t the current specification only define =
hop count, or has that changed in latest draft?)
=


No. That is one of the issues I raise in my original. For some reason, i=
t cites RFC6551, which is a ROLL document and which has in its abstract tha=
t:

   Low-Power and Lossy Networks (LLNs) have unique characte=
ristics
   compared with traditional wired and ad hoc networks that require the
   specification of new routing metrics and constraints. 

I.e. this document cites a metric document which clearly claims to =
be inapplicable in ad hoc networks. I note that this is another thing I=E2=
=80=99ve raised for years without seeing it attempted resolved.
<=
br>
Best,

Thomas


=C2=
=A0
-=
-
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied I=
ntelligence Laboratories
_________________________=
_________________________________________________

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

BAE=
 Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Ch=
elmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limi=
ted
Registered in England & Wales No: 01337451<=
/div>
Registered Office: Surrey R=
esearch Park, Guildford, Surrey, GU2 7YP
=C2=A0
From:=C2=A0ietf@thomasclausen.=
org=C2=A0[mailto:ietf@t=
homasclausen.org]=C2=A0
Sent:=C2=A0=
17 March 2016 17:10
To:=C2=A0Dearlove, Christopher (=
UK)
Cc:=C2=A0Lotte Steenbrink; Mobile Ad Hoc Network=
s mailing list
Subject:=C2=A0Re: [manet] Message int=
egrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - =
a couple of big ticket Items)
=C2=A0
=C2=A0
*** WARNING ***
This message originates from outside our organisation,=
 either from an external partner or the internet.Consider carefully whethe=
r you should click on any links, open any attachments or reply.=

For information regard=
ing=C2=A0Red Flags=C2=A0that you can look out for in emails y=
ou receive, click=C2=A0here.
If you fe=
el the email is suspicious, please follow=C2=A0this process.
=C2=
=A0
On 17 Mar 2016, at 18:04, Dearlove, Christophe=
r (UK) <chris.dearlove@baesyste=
ms.com> wrote:
=C2=A0
OK, so we hav=
e a message that mutates by:
- Modifying hop count/limit.
- Modifying a metric value.
Anything e=
lse?
=
=C2=A0
=
As mutating (other than hop count/limit) messages aren=E2=80=99t covered by=
 5444 or any derivative document (but only recommended against, not banned)=
 that you may need to make the message otherwise immutable (no deconstructi=
on and rebuilding, other than guaranteed unchanging) that would have to be =
specified by AODVv2. (Easy to say, but needs saying.)<=
/div>
=C2=A0<=
/u>
With you so far.
<=
/div>


Then that information is not in a guaranteed fixed lo=
cation given by a simple offset. So any signature algorithm that finds it a=
nd ignores it or aggregates on it is specific to OLSRv2.
=C2=A0
<=
div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">Surely you mean AODVv2
=



So standard 7182 ICVs don=E2=80=99t do the job, you would need =
an AODVv2 specialised variant. Which is the sort of thing that the message =
specific TLV space is there for, I=E2=80=99d be strongly against a =E2=80=
=9Cbut ignore the value of this specific TLV should it occur=E2=80=9D being=
 in the general space. However it can easily be defined by reference to 718=
2 (=E2=80=9Cthis TLV is like that TLV, except if an X TLV is present, set i=
ts value field to zero=E2=80=9D).
=C2=A0
Messy, but could work.
=C2=A0
Not that messy, actually, although clearly not as nice as =
=E2=80=9Cfixed offset=E2=80=9D.
=C2=A0
That =
said, I am arguing for the base spec being:
<=
div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">=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=E2=80=9Cmake the message otherwise immutab=
le (no deconstruction and rebuilding, other=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=A0than guaranteed =
unchanging)=E2=80=9D which is afforded by forwarding
=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0RFC7182 Timestamps and ICVs.
=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0RFC7183 style text bringing it all together.=

=C2=A0
The =E2=80=9Caggregated signatures around muta=
ble field=E2=80=9D would very be an experimental extension.
=C2=A0
=

What I object to is, if the base spec specifically r=
enders such extensions impossible
=C2=A0

=C2=A0=

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applie=
d Intelligence Laboratories
______________________=
____________________________________________________

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

BAE Systems Applied Intelligence, Chel=
msford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesyst=
ems.com/ai
<=
span style=3D"font-size:8pt;font-family:Arial,sans-serif;color:rgb(58,139,1=
46)">BAE Systems Applied Intelligence Limited
Registered in England &=
; Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Su=
rrey, GU2 7YP
=C2=A0
From:=
=C2=A0Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]=C2=A0
Sent:=C2=A017 March 2016 =
16:48
To:=C2=A0Dearlove, Christopher (UK)
Cc:<=
/b>=C2=A0ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing=
 list
Subject:=C2=A0Re: [manet] Message integrity an=
d message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple =
of big ticket Items)
=C2=A0
=C2=A0=

*** WARNING ***
This message originates from outside our organ=
isation, either from an external partner or the internet.
Consider carefull=
y whether you should click on any links, open any attachments or reply.
For informatio=
n regarding=C2=A0Red Flags=C2=A0that yo=
u can look out for in emails you receive, click=C2=A0here.
If you feel the email is suspicious, please fol=
low=C2=A0this process.
Hi all,
=

=C2=A0
Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <chris.dearlove@=
baesystems.com>:
=C2=A0
Good point about whether you just pass on one cost or a s=
et of costs. As I said, not looked at details - I will, when time permits. =
One cost is much easier, and yes, it reduces the fixed size aggregated sign=
atures problem to =E2=80=9Cjust=E2=80=9D one of computational load.<=
u>
=C2=A0
For the record, Thomas=E2=80=99 understanding is correct; the cost is o=
ne aggregated value.=C2=A0
=C2=A0
Best regards,=C2=A0
<=
div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">Lotte Steenrbink
=




=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.dearlove@baesystems.com
BAE Systems Applied Intelligence, Chelmsford Technology Park,=
 Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems A=
pplied Intelligence Limited
Registered in England & Wales No: 013374=
51
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7Y=
P
=
=C2=A0
From:=C2=A0ietf@thomasclausen.org=C2=A0[mailto:ietf@thomasc=
lausen.org]=C2=A0
Sent:=C2=A017 March 2016 16:38
To:=C2=A0Dearlove, Christopher =
(UK)
Cc:=C2=A0Mobile Ad Hoc Networks mailing listSubject:=C2=A0Re: Message integrity and message mutabi=
lity (was RE: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big t=
icket Items)
=C2=A0
=C2=A0<=
/span>
*** 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 r=
eply.
For i=
nformation regarding=C2=A0Red F=
lags=C2=A0that you can look out for in emails you receive, click<=
i>=C2=A0here.
If you feel the email is suspicious, p=
lease follow=C2=A0this process.=

=C2=A0
On 17 Mar 2016, at 17:30, Dearlove, =
Christopher (UK) <chris.dearlove@baesystems.com> wrote:
=C2=A0<=
/u>
I appreciate Thomas=E2=80=99s comments about the limitations of message=
 regeneration, but I would be a bit less absolute.
=C2=A0
The issues over end to end authentication and more advanced si=
gnatures are valid. I need to read the given reference on aggregate signatu=
res to increase my knowledge (thanks for it), but my understanding of the p=
ossibilities in this field may offer a solution to the problem, but with so=
me other issues (possibly including a new type of TLV).
=C2=
=A0
But the hop count/limit point I don=E2=80=99t fully ag=
ree with, you can regenerate with an incremented/decremented count/limit, w=
hich leaves the ability to prevent messages propagating indefinitely, inclu=
ding expanding ring searches, and retains the ability to use RFC 5497 inter=
val and validity times that might be useful with an expanding ring search (=
or might not).
<=
div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">=C2=A0
=

But the key issue is th=
at AODVv2 wants to accumulate metrics. I still haven=E2=80=99t got to the b=
ottom of many details here, but let=E2=80=99s for the moment just consider =
that conceptually.
=C2=A0
It=E2=80=99s hard t=
o handle end to end. Charlie=E2=80=99s draft attempts to do an end to end o=
f some information, not this information. I=E2=80=99m not sure if that=E2=
=80=99s useful (and the specialised format is better avoided if possible). =
Other approaches are hop by hop (might as well use packet signatures) and s=
hared key (might as well go hop by hop). Pairwise signatures for each pair =
of routers I=E2=80=99m discounting as scaling terribly. In the interests of=
 completeness let=E2=80=99s mention not accumulating metrics, which puts us=
 back to hop count and that=E2=80=99s not ideal either.
=C2=
=A0
I don=E2=80=99t think there is an ideal solution. (I l=
ike ideas I=E2=80=99ve seen about aggregating, but that has some issues of =
its own, even apart from computational load.) I=E2=80=99d love to be proved=
 wrong - someone with the perfect solution to come along.<=
/u>
=
=C2=A0
Which means that either we make an arbitrary choice -=
 which will be disagreed with, but needs discussing first - or create somet=
hing flexible. Unfortunately flexible in that regard constrains in others, =
e.g. some (many? most?) aggregating signatures need fixed data sizes (which=
 we can do by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count=
, but that has a cost too).
=C2=A0<=
/div>
I have been told by=
 people much more well versed in this than I in cryptology, that the correc=
t answer is =E2=80=9Csome=E2=80=9D.
=C2=A0
<=
/div>
That said, "AODVv2 wants to=
 accumulate metrics=E2=80=9D =E2=80=94 does that mean that the message grow=
s as it is being forwarded, and that the recipient of a RREQ/RREP will know=
 the individual costs of each path segment? My understanding is, that the r=
ecipient will get =E2=80=9Cthe sum the costs of each path segment=E2=80=9D =
which should be fitting within a fixed size?
=C2=A0
Thomas
=C2=A0=



<=
br>
=C2=A0
Sorry, no answers, just comments. And =
I=E2=80=99m not addressing Thomas=E2=80=99s later points here.
=C2=A0
--
Christopher Dearlove
Senior Principal En=
gineer
BAE Systems Applied Intelligence Laboratories
_____________________________________________________________________=
_____

T: =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E:=C2=A0chris.d=
earlove@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<=
/u>
Regis=
tered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
=C2=A0
From:=C2=A0manet [mailto:manet-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0ietf@thomasclausen.org
Sent=
:=C2=A017 March 2016 16:00
To:=C2=A0Mobile Ad Hoc Networks mailing list
Subject:=C2=A0[=
manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items
=C2=A0
=C2=A0=

*** WARNING ***
This message originates from outside=
 our organisation, either from an external partner or the internet.<=
/em>
Conside=
r carefully whether you should click on any links, open any attachments or =
reply.
For =
information regarding=C2=A0<=
span style=3D"font-size:10.5pt;font-family:Arial,sans-serif;color:red">Red =
Flags=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***
EXTERNAL EMA=
IL -- This message originates from outside our organization.<=
/div>
=C2=A0
=

Dear all,<=
/u>
Apologies for not having gotten this done sooner - day-=
job leaving few spare cycles.
=C2=A0
I=E2=80=99ve pre=
viously offered reviews and comments, and some of those have been addressed=
 in the latest I-D =E2=80=94 others have not, but should be. I recall that =
there was some mail attempting to rebut parts of the review, and I will dig=
 it out and reply to that.
=

=C2=A0
With that being sai=
d, I have reviewed the latest version of the document, and full details wil=
l be forthcoming. There=E2=80=99re a couple of big-ticket/architectural ite=
ms that I want to address up front, as I believe that before we have those =
hammered out, it will be useless to go into details. Note, I do not claim t=
hat this is an exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D, but t=
hat=E2=80=99s as far as I have gotten in thinking this through.
=
=C2=A0
I also bring these up as they are items that have been br=
ought up repeatedly over the past years, but not resolved nor discussed.=

=C2=A0
<=
div>
Loops
Just to bring thi=
s out: I share Chris=E2=80=99 worry about conflicting and concurrent statem=
ents from the authors on =E2=80=9CThere are no loops possible=E2=80=9D and =
=E2=80=9CWe need to fix two situations where loops can occur=E2=80=9D and =
=E2=80=9Cwe are still investigating some loop conditions=E2=80=9D=

I particularly worry that this is not a discussion had =
in public, but apparently in some other forum=E2=80=A6
<=
/div>
=C2=A0=

=C2=A0
<=
div>
Intermediate Route Replies, and all o=
f section 10
<=
div>
Section 10 contains a set of =E2=80=9Cvague=
ly specified extensions=E2=80=9D, which is incoherent with the intended sta=
tus indicated for this document.=C2=A0
=C2=A0
Specifi=
cally, and this is not unrelated to the point about loops above, intermedia=
te RREPs (section 10.3) are a potential source for loops.
=C2=A0=

Expanding Ring Multicast (section 10.1) is not documented in a=
 way that can be implemented (and also, see =E2=80=9CForwarding-vs-regenera=
tion=E2=80=9D below, it is in the present form of this protocol impossible)=
, etc.
=C2=A0
<=
div>
=C2=A0
<=
/div>
Forwardin=
g-vs-regeneration
<=
div>
Recent exchanges on the list made me u=
nderstand that protocol control messages are *not* forwarded, but are consu=
med at each hop, then a new message with (almost-but-not-quite) the same co=
ntent is generated and transmitted.
=C2=A0
I have tho=
ught some more on this (& read some of the exchanges on the list on thi=
s topic by Chris, Ulrich, and others), and I am convinced that this is not =
the right way to go,=C2=A0at least=C2=A0for the following reasons:
=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0It renders the hop-limit/hop-count fields in the RFC5444 messa=
ge header useless.
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0This would not be b=
ad if the functionality offered by those fields was not useful
<=
span>=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=94 sadly, it is. For example, for scope limited =
flooding (expanding ring search, and=C2=A0
<=
/div>
=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=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0s=
uch) which may be of interest, and which require hop-limit.=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=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0of information to use conjunctively with a =E2=80=9Creal=E2=80=9D=
 metric.
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The only practic=
al solution would be to re-introduce these functions by way of inserting a<=
u>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0MessageTLV =E2=80=94 which (i) is not sp=
ecified in this document, and (ii) which would just
=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=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0serve to render messages bigger than strictly needed.
=
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Scope limited flooding =C2=A0does see=
m to be a necessary requirement, if for no
<=
/div>
=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=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0o=
ther reason than to prevent information from =E2=80=9Ccirculating forever i=
n the network=E2=80=9D.
=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0It makes end-to-end authentication unnecessarily hard.<=
/u>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0I think Chris called this out alre=
ady, but it bears repeating: S generates a message=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=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(say, a RREQ), and includes an ICV calculated over the conten=
t of the message.
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0For any recipient to be a=
ble to validate the ICV, the message has to be exactly
<=
/div>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0the same =E2=80=94 not just in content, but in structure =E2=
=80=94 as what was generated.
=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=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforwarding=E2=80=
=9D messages means, that the intermediate
=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=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0r=
outer =E2=80=9Cregenerating=E2=80=9D the RREQ may chose a different structu=
re (e.g., include TLVs
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0in a different orde=
r).
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The proposal from=C2=
=A0https://tools.ietf.org/html/draft-perkins-manet-aod=
v-e2esec-00
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0is to add constrain=
ts on (i) the set of elements to include in a signature and (ii) the=

=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0order of these elements.
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0One=C2=A0problem with that approach is (i): if an=
 extension adds a message TLV, or an=C2=A0
<=
/div>
=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=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0A=
ddress TLV, to a message, then that will not be =E2=80=9Ccovered=E2=80=9D b=
y the proposed e2esec TLV.
=

=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=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Rather for *each=
* extension developed, an =E2=80=9Cupdates e2esec=E2=80=9D clause needs to =
be done.
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I=E2=80=99d say =
that this approach would be prone to errors =E2=80=94 and add entropy to th=
e process
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0of designing protocol extensions. =
The alternative, a message being generated by the
=

=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=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0source and *forwarded* (as we do in OLSRv2, for example) would al=
low ICV TLVs=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(even, allow reuse of tho=
se specified for OLSRv2) for covering a message and=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=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0extensions.
<=
div>
=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=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9CBut what about the metrics value which will change on each hop=
=E2=80=9D, you may say?
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Fortunately, that i=
s relatively easy to handle: simply zero out the value of that TLV when<=
/u>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0generating or verifying the ICV MessageTLV. An=
d use Packet-TLVs for hop-by-hop=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=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0auth=
entication, if needed (but, see below).
=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It prevents the use of more clever/advan=
ced signature schemes/ICVs
=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=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Aggrega=
te signature algorithms (=C2=A0https://crypto.stanford.edu/~da=
bo/papers/aggsurvey.pdf)
=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=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0exist, =
and an interesting use-case can be found in also reactive protocols, allowi=
ng verifying
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0not =E2=80=9Cjust=E2=80=9D the =
end points, but also the intermediaries (again, with the appropriate =E2=80=
=9Czero out=E2=80=9D
<=
div>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0discussed above, or so=
mething smarter).
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Regeneration of messages,=
 rather than forwarding, renders that impossible (or, if used,
<=
span>=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0updating to =C2=A0https://tools.ie=
tf.org/html/draft-perkins-manet-aodv-e2esec-00)
=C2=
=A0
There are other reasons, but the above are those that jump a=
t me as immediate show-stoppers.
=C2=A0
I do honestly=
 not see what possible benefit there is from =E2=80=9Cregeneration=E2=80=9D=
 =E2=80=94 but I see very clear inconveniences, and security is not the lea=
st of these. Insisting on =E2=80=9Cregeneration=E2=80=9D requires developme=
nt of =E2=80=9Cnon-general workarounds=E2=80=9D as pointed out above.
=C2=A0
Security Considerations=

Th=
is is an always thorny subject. When OLSRv2 was going through the process w=
e got a thorough education in how little we knew about security from the SE=
C-ADs, and had to spend about a year or so developing RFC7183. The bottom l=
ine is, that this protocol needs its =E2=80=9CRFC7183 =C2=A0equivalent=E2=
=80=9D, either as part of the main document, or as an independent document.=
 currently, that is not the case.
=C2=A0
A minima, lo=
oking at BCP72 and BCP107 =E2=80=94 taking inspiration from RFC7183 might b=
e aw good idea, as that was the most recent that went through the SEC AD. R=
egardless of how, however, a =E2=80=9Cmandatory to implement=E2=80=9D secur=
ity mechanism most be specified (I think the right term was =E2=80=9CMUST i=
mplement, SHOULD use=E2=80=9D), in sufficient detail to ensure interoperabl=
e implementations.
=C2=A0
<=
/div>
As an example, both [RFC613=
0] and [RFC7181] set out that that:
=C2=A0
=C2=
=A0 =C2=A0 =C2=A0 On receiving a ... message, a router MUST first check if =
the
=C2=A0 =C2=A0 =C2=A0 message is invalid for processing by th=
is router
=C2=A0
and then proceed to give a number of=
 conditions that, each, will lead to a rejection of the message as "ba=
dly formed and therefore invalid for processing=E2=80=9D =E2=80=94 a list w=
hich RFC7183 then amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 f=
or inserting =E2=80=9Crejection=E2=80=9D. Idem for message generation.
=C2=A0
If I was to do RFC7181/RFC6130 today, I would incl=
ude that directly into the protocol specifications. It turned out to be mor=
e overhead (and slow down publication anyways) to do it as separate documen=
ts.
=C2=A0
Secondly, we need to be a lot more r=
igid in terms of what ICVs, Timestamps, etc. are added/removed, and what th=
at brings.
<=
div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">=C2=A0
For example (with the assumption th=
at messages are *forwarded* and *not* regenerated), this could be one optio=
n:
=C2=A0
<=
div>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0When a RRE=
Q, RREP message is generated, add an ICV Message TLV, which is calculated &=
lt;this way>
<=
div>
=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=A6(take inspiratio=
n from RFC7183 here)
<=
div>
=C2=A0
<=
/div>
...=


[Message clipped]=C2=A0=C2=A0
__________________________________=
_____________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet





--94eb2c122e52c3edcb05311b2934--


From nobody Sat Apr 23 02:55: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 DDC8612DA2F for ; Sat, 23 Apr 2016 02:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.143
X-Spam-Level: 
X-Spam-Status: No, score=-1.143 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, TRACKER_ID=1.306] 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 j8bXiGsG0RBG for ; Sat, 23 Apr 2016 02:55:05 -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 6ECB412D811 for ; Sat, 23 Apr 2016 02:55:05 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id n67so143470651vkf.3 for ; Sat, 23 Apr 2016 02:55:05 -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=nvx1TqWu/oF3Dwokj2RIcDq3Dek/NXY1ZEGqpVdLPpg=; b=MHIjygEmjxtOjJx/lWmT18CDL55Ddx9Hesnt1HT9lQ7IrQo/2KY1QzOv3wGmzYq6NS xwSA1hM9LA3ESLM0tBsQvlGsZrMetEKcunhBlFP3gzojrNpQG3k1oThVdkXew5eia6nQ jTlKa1PBAWxmUdU7BodgNcxXoGM4nOOTxsoihZAvxHYedsx2xhsgprB0zr9IbUBYhy+4 o44pmSj30Dwd4JTg/YQdtuThdFn/26AmyPCk7RRIOxw5OYjL7wpYPNV+x2r8qp/2ZMUa wm+AmURC8SF+c9haV+Or4UgvCu7v4IbQtc108q2M4sm3PBVK/cbgariwdqHFcHVmzBwk SBLw==
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=nvx1TqWu/oF3Dwokj2RIcDq3Dek/NXY1ZEGqpVdLPpg=; b=eRz7nPgDKYa1H9aRLrvUIVWXI+JDH5s4u1sfi70ezfyG0uoO6cTWABNaI3+Oqls4y6 ytp7hmJ25lzFvcGPoa0QbKK8oYl7HKjKKBEw+BHfI2H36IRgYcIpFF6bjiiBpx+FR3ZH ddxv/C/OqcYuurJE5gfqjBjE1Qp60SZN7M/E/fOwQgCx6Z7HLuhe2LLn+pO1J68bLfKF x9jqgY3y5RL2omzg8Gsm6PD5ClXLr46CHixF+HnBvSQzolJ+3Bu5NOiAYImNdRIoguic 4zQAct0sS5P4odzRe/BIF4nE1nn+Fqci+46Z6fx/MR+fJ22qP1N2xp56N/gF1z9e3HbW mi6Q==
X-Gm-Message-State: AOPr4FVnkGCVpYpfVSBEcIIZRmBuv70rdWqBxQj3cyQr/NINF1PMwSukNynhgVr48JYe0wNdOREbzL69C2YZZA==
MIME-Version: 1.0
X-Received: by 10.159.37.208 with SMTP id 74mr14049836uaf.148.1461405304228; Sat, 23 Apr 2016 02:55:04 -0700 (PDT)
Received: by 10.176.65.40 with HTTP; Sat, 23 Apr 2016 02:55:04 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>  
Date: Sat, 23 Apr 2016 10:55:04 +0100
Message-ID: 
From: Victoria Mercieca 
To: Christopher Dearlove 
Content-Type: multipart/alternative; boundary=001a1139558c081042053123f06c
Archived-At: 
Cc: Christopher Dearlove , Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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: Sat, 23 Apr 2016 09:55:10 -0000

--001a1139558c081042053123f06c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Chris,

These have both been in the draft in some form since before I got
involved... but I'll do my best to explain.

- For Validity Time, its a way to advertise that you would only support the
route contained in the message for a certain period of time. The originator
might use this, but the draft was written to allow any intermediate node to
be able to add it or update it too. The route created in the Local Route
Set has an expiration time associated with it, based on the received
validity time.
- For the AckReq address, its so that you can add into a RREP a request for
an acknowledgement, so that you don't have to have a different message type
altogether for working out whether links to neighbors are bidirectional,
and also, since you only care about bidirectionality on routes that are
being set up, you dont need to constantly monitor all neighbors.


In order to avoid the potential AckReq-related changes to each message,
maybe we do need to introduce a different message specifically for this. We
could maybe use RREP_Ack to both request and acknowledge? It means an extra
message of control traffic that needs to be sent, maybe one extra message
per hop on the path of a RREP, but it could still be limited to neighbors
which have participated in the route discovery rather than monitoring all
neighbors at all times.

This message could maybe also include "I'm happy to route anywhere for a
certain amount of time", sort of like willingness in OLSR/OLSRv2. So
instead of having a validity time per route, its a validity time per
neighbor. Then, for RREQ and RREP, only the metric value would change in
transit, as discussed. However, that leads to some issues with deciding
what a route's expiration time is. You might know how long the next hop
router is valid for, but what if a router beyond that, which was also part
of the route, had a lower validity time? You couldn't determine the real
validity time. Do we remove the route expiration time altogether to avoid
this issue? In which case, we would have to rely on RERR messages being
sent for routes which become invalid when the neighbor's validity time has
expired? So neighbor validity time expiration is treated the same as a link
break.

What do you think?

Kind regards,
Victoria.






On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
chris@mnemosyne.demon.co.uk> wrote:

> Pretty much all of the discussion has been assuming only a metric value
> change. With multiple things changing many of the ideas go out of the
> window. That reinforces the point about not making specifications now tha=
t
> might turn out to be wrong for ICVs.
>
> Ignoring how this misunderstanding happened, I'll start by asking why.
> Metric changing I understand. Why the other two? (there's a partial
> explanation of one). What alternatives have people implemented in
> comparable protocols?
>
> --
> Christopher Dearlove
> christopher.dearlove@gmail.com (iPhone)
> chris@mnemosyne.demon.co.uk (home)
>
> On 23 Apr 2016, at 00:26, Victoria Mercieca  wrote:
>
> Hi all,
>
> Continued in this thread because the other one seems to be more about TLV
> types and metric type numbers, whereas this is about
> regeneration/forwarding.
>
> To recap, in the current draft, there are 3 things that might change at
> each hop:
> - the metric value (happens in RREQ and RREP),
> - adding/changing Validity Time using the Validity Time TLV (can happen i=
n
> RREQ and RREP),
> - adding an address (and corresponding value in the AddressType TLV to
> indicate how to interpret the address) to indicate the address from which
> an RREP_Ack is expected, to accomplish the bidirectionality check (can
> happen in RREP).
>
> If we define a certain portion of the message as immutable and include th=
e
> ICV to verify that part, end to end:
> - The metric value would be excluded from the ICV since it needs changing
> at each hop.
> - Would adding a Validity Time TLV at an intermediate hop be acceptable?
> The whole TLV could be removed in order to calculate the ICV?
> - Would adding an address cause issues for the ICV, because it's in the
> address block? Could the rule be "if it contains an AckReq address, remov=
e
> it (and the corresponding value in the AddressType TLV), before checking
> the ICV", is that OK? Or would we need to avoid touching the ICV'ed part =
of
> the message altogether, maybe put the AckReq address in a separate Addres=
s
> Block, with an extra AddressType TLV following that address block? Is the=
re
> a way to accomplish this?
>
> Also, to be thorough, do we need to consider RERR messages while we
> discuss regeneration vs forwarding?
> - RERR (sent when a link breaks) is a way of saying "I've lost my route s=
o
> I'm telling others" and "you were my next hop, so now I've also lost my
> route, I'll tell others", etc. It's going to be tailored at each step to
> include the relevant routes that got deleted, it's not one message being
> sent end-to-end like RREQ and RREP are.
> - However, RERR (sent when a source of traffic is sending data on a route
> which comes through you, and you want to tell the Packet Source's router =
to
> delete the route) could be seen as an end-to-end message which all
> intermediate routers learn from, similar to RREQ and RREP. It reports one
> route, and doesn't need changing at intermediate hops, so could be
> protected with ICV.
> - Would it be OK to only require a message ICV if a PktSource address was
> included, i.e. when the message needs to go via a number of intermediate
> hops to PktSource's router? All other RERRs are intended to be one-hop
> messages, which may in turn prompt other one-hop messages, etc..., and a
> packet ICV might be more appropriate?
>
> Kind regards,
> Victoria.
>
> On Thu, Mar 17, 2016 at 5:26 PM,  wrote:
>
>>
>> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>> Yes, I meant AODVv2, thanks for the catch.
>>
>> So is your (Thomas) proposed base specification a hop count only metric?
>>
>>
>> No, the would be silly as base specification, given that hop count mostl=
y
>> is useless.
>>
>> As base specification I would simply say =E2=80=9CInclude a Metric Type =
Message
>> TLV with a value field, and a 7182 Message TLV & Timestamp=E2=80=9D as w=
e do in
>> OLSRv2 (with the appropriate verbiage as to generation and processing).
>>
>> With the message generated by the originator of the RREQ/RREP and *not*
>> deconstructed/reconstructed/reordered (as is the risk with =E2=80=9Crege=
neration)
>> allows knowing that it would be *only* that metric field being modified
>> (other than hop count/limit) for when eventually writing up the extensio=
n.
>>
>>
>> (Actually doesn=E2=80=99t the current specification only define hop coun=
t, or has
>> that changed in latest draft?)
>>
>>
>> No. That is one of the issues I raise in my original. For some reason, i=
t
>> cites RFC6551, which is a ROLL document and which has in its abstract th=
at:
>>
>>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>>    compared with traditional wired and ad hoc networks that require the
>>    specification of new routing metrics and constraints.
>>
>>
>> I.e. this document cites a metric document which clearly claims to be
>> inapplicable in ad hoc networks. I note that this is another thing I=E2=
=80=99ve
>> raised for years without seeing it attempted resolved.
>>
>> Best,
>>
>> Thomas
>>
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>> ]
>> *Sent:* 17 March 2016 17:10
>> *To:* Dearlove, Christopher (UK)
>> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>> **** 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 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>> OK, so we have a message that mutates by:
>> - Modifying hop count/limit.
>> - Modifying a metric value.
>> Anything else?
>>
>> As mutating (other than hop count/limit) messages aren=E2=80=99t covered=
 by 5444
>> or any derivative document (but only recommended against, not banned) th=
at
>> you may need to make the message otherwise immutable (no deconstruction =
and
>> rebuilding, other than guaranteed unchanging) that would have to be
>> specified by AODVv2. (Easy to say, but needs saying.)
>>
>>
>> With you so far.
>>
>>
>> Then that information is not in a guaranteed fixed location given by a
>> simple offset. So any signature algorithm that finds it and ignores it o=
r
>> aggregates on it is specific to OLSRv2.
>>
>> Surely you mean AODVv2
>>
>>
>> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AODVv2
>> specialised variant. Which is the sort of thing that the message specifi=
c
>> TLV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cbut i=
gnore the value of
>> this specific TLV should it occur=E2=80=9D being in the general space. H=
owever it
>> can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like th=
at TLV,
>> except if an X TLV is present, set its value field to zero=E2=80=9D).
>>
>> Messy, but could work.
>>
>> Not that messy, actually, although clearly not as nice as =E2=80=9Cfixed=
 offset=E2=80=9D.
>>
>> That said, I am arguing for the base spec being:
>>
>>             =E2=80=9Cmake the message otherwise immutable (no deconstruc=
tion and
>> rebuilding, other
>>              than guaranteed unchanging)=E2=80=9D which is afforded by f=
orwarding
>>
>>                                     +
>>
>>             RFC7182 Timestamps and ICVs.
>>
>>                                     +
>>
>>             RFC7183 style text bringing it all together.
>>
>> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would v=
ery be an
>> experimental extension.
>>
>> What I object to is, if the base spec specifically renders such
>> extensions impossible
>>
>>
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *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:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
>> ]
>> *Sent:* 17 March 2016 16:48
>> *To:* Dearlove, Christopher (UK)
>> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
>> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>> **** 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
>> .*
>> Hi all,
>>
>>
>> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com>:
>>
>> Good point about whether you just pass on one cost or a set of costs. As
>> I said, not looked at details - I will, when time permits. One cost is m=
uch
>> easier, and yes, it reduces the fixed size aggregated signatures problem=
 to
>> =E2=80=9Cjust=E2=80=9D one of computational load.
>>
>>
>> For the record, Thomas=E2=80=99 understanding is correct; the cost is on=
e
>> aggregated value.
>>
>> Best regards,
>> Lotte Steenrbink
>>
>>
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>> ]
>> *Sent:* 17 March 2016 16:38
>> *To:* Dearlove, Christopher (UK)
>> *Cc:* Mobile Ad Hoc Networks mailing list
>> *Subject:* Re: Message integrity and message mutability (was RE: [manet]
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>> **** 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 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>> I appreciate Thomas=E2=80=99s comments about the limitations of message
>> regeneration, but I would be a bit less absolute.
>>
>> The issues over end to end authentication and more advanced signatures
>> are valid. I need to read the given reference on aggregate signatures to
>> increase my knowledge (thanks for it), but my understanding of the
>> possibilities in this field may offer a solution to the problem, but wit=
h
>> some other issues (possibly including a new type of TLV).
>>
>> But the hop count/limit point I don=E2=80=99t fully agree with, you can
>> regenerate with an incremented/decremented count/limit, which leaves the
>> ability to prevent messages propagating indefinitely, including expandin=
g
>> ring searches, and retains the ability to use RFC 5497 interval and
>> validity times that might be useful with an expanding ring search (or mi=
ght
>> not).
>>
>> But the key issue is that AODVv2 wants to accumulate metrics. I still
>> haven=E2=80=99t got to the bottom of many details here, but let=E2=80=99=
s for the moment
>> just consider that conceptually.
>>
>> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft attempts=
 to do an end to
>> end of some information, not this information. I=E2=80=99m not sure if t=
hat=E2=80=99s
>> useful (and the specialised format is better avoided if possible). Other
>> approaches are hop by hop (might as well use packet signatures) and shar=
ed
>> key (might as well go hop by hop). Pairwise signatures for each pair of
>> routers I=E2=80=99m discounting as scaling terribly. In the interests of
>> completeness let=E2=80=99s mention not accumulating metrics, which puts =
us back to
>> hop count and that=E2=80=99s not ideal either.
>>
>> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=80=
=99ve seen about
>> aggregating, but that has some issues of its own, even apart from
>> computational load.) I=E2=80=99d love to be proved wrong - someone with =
the perfect
>> solution to come along.
>>
>> Which means that either we make an arbitrary choice - which will be
>> disagreed with, but needs discussing first - or create something flexibl=
e.
>> Unfortunately flexible in that regard constrains in others, e.g. some
>> (many? most?) aggregating signatures need fixed data sizes (which we can=
 do
>> by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but th=
at has a cost too).
>>
>>
>> I have been told by people much more well versed in this than I in
>> cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>>
>> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does t=
hat mean that the
>> message grows as it is being forwarded, and that the recipient of a
>> RREQ/RREP will know the individual costs of each path segment? My
>> understanding is, that the recipient will get =E2=80=9Cthe sum the costs=
 of each
>> path segment=E2=80=9D which should be fitting within a fixed size?
>>
>> Thomas
>>
>>
>>
>>
>>
>>
>> Sorry, no answers, just comments. And I=E2=80=99m not addressing Thomas=
=E2=80=99s later
>> points here.
>>
>>
>> *--*
>>
>>
>>
>>
>> *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 *ietf@thomasclausen.org
>> *Sent:* 17 March 2016 16:00
>> *To:* Mobile Ad Hoc Networks mailing list
>> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of big
>> ticket Items
>>
>>
>> **** 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.
>>
>> Dear all,
>>
>> Apologies for not having gotten this done sooner - day-job leaving few
>> spare cycles.
>>
>> I=E2=80=99ve previously offered reviews and comments, and some of those =
have been
>> addressed in the latest I-D =E2=80=94 others have not, but should be. I =
recall that
>> there was some mail attempting to rebut parts of the review, and I will =
dig
>> it out and reply to that.
>>
>> With that being said, I have reviewed the latest version of the document=
,
>> and full details will be forthcoming. There=E2=80=99re a couple of
>> big-ticket/architectural items that I want to address up front, as I
>> believe that before we have those hammered out, it will be useless to go
>> into details. Note, I do not claim that this is an exhaustive list of =
=E2=80=9Cbig
>> ticket items=E2=80=9D, but that=E2=80=99s as far as I have gotten in thi=
nking this through.
>>
>> I also bring these up as they are items that have been brought up
>> repeatedly over the past years, but not resolved nor discussed.
>>
>> *Loops*
>> Just to bring this out: I share Chris=E2=80=99 worry about conflicting a=
nd
>> concurrent statements from the authors on =E2=80=9CThere are no loops po=
ssible=E2=80=9D and
>> =E2=80=9CWe need to fix two situations where loops can occur=E2=80=9D an=
d =E2=80=9Cwe are still
>> investigating some loop conditions=E2=80=9D
>>
>> I particularly worry that this is not a discussion had in public, but
>> apparently in some other forum=E2=80=A6
>>
>>
>> *Intermediate Route Replies, and all of section 10*
>> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=80=
=9D, which is
>> incoherent with the intended status indicated for this document.
>>
>> Specifically, and this is not unrelated to the point about loops above,
>> intermediate RREPs (section 10.3) are a potential source for loops.
>>
>> Expanding Ring Multicast (section 10.1) is not documented in a way that
>> can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=E2=
=80=9D below, it is
>> in the present form of this protocol impossible), etc.
>>
>>
>> *Forwarding-vs-regeneration*
>> Recent exchanges on the list made me understand that protocol control
>> messages are *not* forwarded, but are consumed at each hop, then a new
>> message with (almost-but-not-quite) the same content is generated and
>> transmitted.
>>
>> I have thought some more on this (& read some of the exchanges on the
>> list on this topic by Chris, Ulrich, and others), and I am convinced tha=
t
>> this is not the right way to go, *at least* for the following reasons:
>>
>>
>>             o          *It renders the hop-limit/hop-count fields in the
>> RFC5444 message header useless.*
>>                         This would not be bad if the functionality
>> offered by those fields was not useful
>>                         =E2=80=94 sadly, it is. For example, for scope l=
imited
>> flooding (expanding ring search, and
>>                         such) which may be of interest, and which
>> require hop-limit.
>>                         A hop-count field may also provide a =E2=80=9Cch=
eap=E2=80=9D (in
>> terms of overhead) additional piece
>>                         of information to use conjunctively with a
>> =E2=80=9Creal=E2=80=9D metric.
>>
>>                         The only practical solution would be to
>> re-introduce these functions by way of inserting a
>>                         MessageTLV =E2=80=94 which (i) is not specified =
in this
>> document, and (ii) which would just
>>                         serve to render messages bigger than strictly
>> needed.
>>
>>                         Scope limited flooding  does seem to be a
>> necessary requirement, if for no
>>                         other reason than to prevent information from
>> =E2=80=9Ccirculating forever in the network=E2=80=9D.
>>
>>             o          *It makes end-to-end authentication unnecessarily
>> hard.*
>>                         I think Chris called this out already, but it
>> bears repeating: S generates a message
>>                         (say, a RREQ), and includes an ICV calculated
>> over the content of the message.
>>                         For any recipient to be able to validate the
>> ICV, the message has to be exactly
>>                         the same =E2=80=94 not just in content, but in s=
tructure
>> =E2=80=94 as what was generated.
>>
>>                         =E2=80=9CRegenerating=E2=80=9D rather than =E2=
=80=9Cforwarding=E2=80=9D messages
>> means, that the intermediate
>>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ m=
ay chose a
>> different structure (e.g., include TLVs
>>                         in a different order).
>>
>>                         The proposal from
>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>>                         is to add constraints on (i) the set of elements
>> to include in a signature and (ii) the
>>                         order of these elements.
>>
>>                         One problem with that approach is (i): if an
>> extension adds a message TLV, or an
>>                         Address TLV, to a message, then that will not be
>> =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>>                         Rather for *each* extension developed, an
>> =E2=80=9Cupdates e2esec=E2=80=9D clause needs to be done.
>>
>>                         I=E2=80=99d say that this approach would be pron=
e to
>> errors =E2=80=94 and add entropy to the process
>>                         of designing protocol extensions. The
>> alternative, a message being generated by the
>>                         source and *forwarded* (as we do in OLSRv2, for
>> example) would allow ICV TLVs
>>                         (even, allow reuse of those specified for
>> OLSRv2) for covering a message and
>>                         extensions.
>>
>>                         =E2=80=9CBut what about the metrics value which =
will
>> change on each hop=E2=80=9D, you may say?
>>                         Fortunately, that is relatively easy to handle:
>> simply zero out the value of that TLV when
>>                         generating or verifying the ICV MessageTLV. And
>> use Packet-TLVs for hop-by-hop
>>                         authentication, if needed (but, see below).
>>
>>             o          *It prevents the use of more clever/advanced
>> signature schemes/ICVs*
>>                         Aggregate signature algorithms (
>> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>>                         exist, and an interesting use-case can be found
>> in also reactive protocols, allowing verifying
>>                         not =E2=80=9Cjust=E2=80=9D the end points, but a=
lso the
>> intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D
>>                         discussed above, or something smarter).
>>                         Regeneration of messages, rather than
>> forwarding, renders that impossible (or, if used,
>>                         updating to
>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>>
>> There are other reasons, but the above are those that jump at me as
>> immediate show-stoppers.
>>
>> I do honestly not see what possible benefit there is from =E2=80=9Cregen=
eration=E2=80=9D
>> =E2=80=94 but I see very clear inconveniences, and security is not the l=
east of
>> these. Insisting on =E2=80=9Cregeneration=E2=80=9D requires development =
of =E2=80=9Cnon-general
>> workarounds=E2=80=9D as pointed out above.
>>
>> *Security Considerations*
>> This is an always thorny subject. When OLSRv2 was going through the
>> process we got a thorough education in how little we knew about security
>> from the SEC-ADs, and had to spend about a year or so developing RFC7183=
.
>> The bottom line is, that this protocol needs its =E2=80=9CRFC7183  equiv=
alent=E2=80=9D,
>> either as part of the main document, or as an independent document.
>> currently, that is not the case.
>>
>> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration from =
RFC7183
>> might be aw good idea, as that was the most recent that went through the
>> SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to implement=E2=
=80=9D security
>> mechanism most be specified (I think the right term was =E2=80=9CMUST im=
plement,
>> SHOULD use=E2=80=9D), in sufficient detail to ensure interoperable imple=
mentations.
>>
>> As an example, both [RFC6130] and [RFC7181] set out that that:
>>
>>       On receiving a ... message, a router MUST first check if the
>>       message is invalid for processing by this router
>>
>> and then proceed to give a number of conditions that, each, will lead to
>> a rejection of the message as "badly formed and therefore invalid for
>> processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That ga=
ve a =E2=80=9Chook=E2=80=9D for
>> RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message gene=
ration.
>>
>> If I was to do RFC7181/RFC6130 today, I would include that directly into
>> the protocol specifications. It turned out to be more overhead (and slow
>> down publication anyways) to do it as separate documents.
>>
>> Secondly, we need to be a lot more rigid in terms of what ICVs,
>> Timestamps, etc. are added/removed, and what that brings.
>>
>> For example (with the assumption that messages are *forwarded* and *not*
>> regenerated), this could be one option:
>>
>>                         o          When a RREQ, RREP message is
>> generated, add an ICV Message TLV, which is calculated 
>>                                      =E2=80=A6(take inspiration from RFC=
7183
>> here)
>>
>>
>> ...
>>
>> [Message clipped]
>> _______________________________________________
>> 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
>
>

--001a1139558c081042053123f06c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Chris,

These have both been in the d=
raft in some form since before I got involved... but I'll do my best to=
 explain.

- For Validity Time, its a way to advertise th=
at you would only support the route contained in the message for a certain =
period of time. The originator might use this, but the draft was written to=
 allow any intermediate node to be able to add it or update it too. The rou=
te created in the Local Route Set has an expiration time associated with it=
, based on the received validity time.
- For the AckReq address, =
its so that you can add into a RREP a request for an acknowledgement, so th=
at you don't have to have a different message type altogether for worki=
ng out whether links to neighbors are bidirectional, and also, since you on=
ly care about bidirectionality on routes that are being set up, you dont ne=
ed to constantly monitor all neighbors.


=

In order to avoid the potential AckReq-related changes to each message=
, maybe we do need to introduce a different message specifically for this. =
We could maybe use RREP_Ack to both request and acknowledge? It means an ex=
tra message of control traffic that needs to be sent, maybe one extra messa=
ge per hop on the path of a RREP, but it could still be limited to neighbor=
s which have participated in the route discovery rather than monitoring all=
 neighbors at all times.=C2=A0

This message could =
maybe also include "I'm happy to route anywhere for a certain amou=
nt of time", sort of like willingness in OLSR/OLSRv2. So instead of ha=
ving a validity time per route, its a validity time per neighbor. Then, for=
 RREQ and RREP, only the metric value would change in transit, as discussed=
. However, that leads to some issues with deciding what a route's expir=
ation time is. You might know how long the next hop router is valid for, bu=
t what if a router beyond that, which was also part of the route, had a low=
er validity time? You couldn't determine the real validity time. Do we =
remove the route expiration time altogether to avoid this issue? In which c=
ase, we would have to rely on RERR messages being sent for routes which bec=
ome invalid when the neighbor's validity time has expired? So neighbor =
validity time expiration is treated the same as a link break.
What do you think?

Kind regards,
=

Victoria.




<=
/div>


On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <c=
hris@mnemosyne.demon.co.uk> wrote:
Pretty much all of the discussion has been assuming only a=
 metric value change. With multiple things changing many of the ideas go ou=
t of the window. That reinforces the point about not making specifications =
now that might turn out to be wrong for ICVs.

Igno=
ring how this misunderstanding happened, I'll start by asking why. Metr=
ic changing I understand. Why the other two? (there's a partial explana=
tion of one). What alternatives have people implemented in comparable proto=
cols?

-- =C2=A0
Christopher Dearlove
=

On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmail.com> wrote:
<=
br>
Hi =
all,

Continued in this thread because the other on=
e seems to be more about TLV types and metric type numbers, whereas this is=
 about regeneration/forwarding.

To recap, in the c=
urrent draft, there are 3 things that might change at each hop: 
- the m=
etric value (happens in RREQ and RREP), 
- adding/changing Validity Time=
 using the Validity Time TLV (can happen in RREQ and RREP), 
-
 adding an address (and corresponding value in the AddressType TLV to indic=
ate how to interpret the address) to=20
indicate the address from which an RREP_Ack is expected, to accomplish=20
the bidirectionality check (can happen in RREP).

If we define=C2=A0a=
 certain portion of the message as immutable and include the ICV to verify =
that part, end to end: 
- The metric value would be excluded from the IC=
V since it needs changing at each hop.=C2=A0
- Would adding a Validity T=
ime TLV at an intermediate hop be acceptable? The whole TLV could be remove=
d in order to calculate the ICV?
- Would adding an address cause i=
ssues for the ICV, because it's in the address block? Could the rule be=
 "if it contains an AckReq address, remove it (and the corresponding v=
alue in the AddressType TLV), before checking the ICV", is that OK? Or=
 would we need to avoid touching the ICV'ed part of the message altoget=
her, maybe put the AckReq address in a separate Address Block, with an extr=
a AddressType TLV following that address block? Is there a way to accomplis=
h this?

Also, to be thorough, do we need to consid=
er RERR messages while we discuss regeneration vs forwarding?=C2=A0
- RERR (sent when a link breaks) is a way of saying "I've lost =
my route so I'm telling others" and "you were my next hop, so=
=C2=A0now=C2=A0I've also lost my route, I'll tell others", etc=
. It's going to be tailored at each step to include the relevant routes=
 that got deleted, it's not one message being sent end-to-end like RREQ=
 and RREP are.=C2=A0
- However, RERR (sent when a source of t=
raffic is sending data on a route which comes through you, and you want to =
tell the Packet Source's router to delete the route) could be seen as a=
n end-to-end message which all intermediate routers learn from, similar to =
RREQ and RREP. It reports one route, and doesn't need changing at inter=
mediate hops, so could be protected with ICV.
- Would it be OK to=
 only require a message ICV if a PktSource address was included, i.e. when =
the message needs to go via a number of intermediate hops to PktSource'=
s router? All other RERRs are intended to be one-hop messages, which may in=
 turn prompt other one-hop messages, etc..., and a packet ICV might be more=
 appropriate?

Kind regards,
Victoria.

On Thu, Mar 17, =
2016 at 5:26 PM,  <ietf@thomasclausen.org> wrote:

On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <chris.dear=
love@baesystems.com> wrote:

=
Yes, I meant AODVv2, thanks for the catch.
=C2=A0
So is your (Thomas) proposed base specification a hop count o=
nly metric?

No, the would be silly as ba=
se specification, given that hop count mostly is useless.

As base specification I would simply say =E2=80=9CInclude a Metric =
Type Message TLV with a value field, and a 7182 Message TLV & Timestamp=
=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage as to generatio=
n and processing).=C2=A0

With the message generate=
d by the originator of the RREQ/RREP and *not* deconstructed/reconstructed/=
reordered (as is the risk with =E2=80=9Cregeneration) allows knowing that i=
t would be *only* that metric field being modified (other than hop count/li=
mit) for when eventually writing up the extension.
=C2=A0=

(Ac=
tually doesn=E2=80=99t the current specification only define hop count, or =
has that changed in latest draft?)

No. That is=
 one of the issues I raise in my original. For some reason, it cites RFC655=
1, which is a ROLL document and which has in its abstract that:
<=
br>
   Low-Power and Lossy Networks (LLNs) have unique characteristics
   compared with traditional wired and ad hoc networks that require the
   specification of new routing metrics and constraints. 

I.e. this document cites a metric document which clearly claims to =
be inapplicable in ad hoc networks. I note that this is another thing I=E2=
=80=99ve raised for years without seeing it attempted resolved.
<=
br>
Best,

Thomas


=C2=
=A0
-=
-
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied I=
ntelligence Laboratories
_________________________=
_________________________________________________

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

BAE=
 Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Ch=
elmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limi=
ted
Registered in England & Wales No: 01337451<=
/div>
Registered Office: Surrey R=
esearch Park, Guildford, Surrey, GU2 7YP
=C2=A0
From:=C2=A0ietf@thomasclausen.=
org=C2=A0[mailto:ietf@t=
homasclausen.org]=C2=A0
Sent:=C2=A0=
17 March 2016 17:10
To:=C2=A0Dearlove, Christopher (=
UK)
Cc:=C2=A0Lotte Steenbrink; Mobile Ad Hoc Network=
s mailing list
Subject:=C2=A0Re: [manet] Message int=
egrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - =
a couple of big ticket Items)
=C2=A0
=C2=A0
*** WARNING ***
This message originates from outside our organisa=
tion, either from an external partner or the internet.
Consider carefully w=
hether you should click on any links, open any attachments or reply.=

For information r=
egarding=C2=A0Red Flags<=
/i>=C2=A0that you can look out for in ema=
ils you receive, click=C2=A0here.
If =
you feel the email is suspicious, please follow=C2=A0this process.<=
/i>
<=
/u>=C2=A0
On 17 Mar 2016, at 18:04, Dearlove, Chri=
stopher (UK) <chris.dearlove@ba=
esystems.com> wrote:
=C2=A0
OK, so =
we have a message that mutates by:
- Modifying hop count/limit.
- Modifying a metric valu=
e.
Any=
thing else?
=C2=A0
As mutating (other than hop count/limit) messages aren=E2=80=99t cover=
ed by 5444 or any derivative document (but only recommended against, not ba=
nned) that you may need to make the message otherwise immutable (no deconst=
ruction and rebuilding, other than guaranteed unchanging) that would have t=
o be specified by AODVv2. (Easy to say, but needs saying.)=

=C2=
=A0
With you so far.=



Then that information is not in a guaranteed f=
ixed location given by a simple offset. So any signature algorithm that fin=
ds it and ignores it or aggregates on it is specific to OLSRv2.
=C2=A0
=

Surely you mean AODVv2


So standard 7182 ICVs don=E2=80=99t do the job, you wo=
uld need an AODVv2 specialised variant. Which is the sort of thing that the=
 message specific TLV space is there for, I=E2=80=99d be strongly against a=
 =E2=80=9Cbut ignore the value of this specific TLV should it occur=E2=80=
=9D being in the general space. However it can easily be defined by referen=
ce to 7182 (=E2=80=9Cthis TLV is like that TLV, except if an X TLV is prese=
nt, set its value field to zero=E2=80=9D).
=

=C2=A0
=

Messy, but could work.=

=C2=A0
Not that messy, actually, although clearly not as n=
ice as =E2=80=9Cfixed offset=E2=80=9D.
=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=A0=E2=80=9Cmake the message otherwise i=
mmutable (no deconstruction and rebuilding, other=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=A0than guara=
nteed unchanging)=E2=80=9D which is afforded by forwarding
=C2=A0
<=
div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0RFC7182 Timestamps and ICVs.
=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0RFC7183 style text bringing it all together.
=C2=A0
=

The =E2=80=9Caggregated signatures around=
 mutable field=E2=80=9D would very be an experimental extension.<=
/u>
=C2=A0
=

What I object to is, if the base spec specifica=
lly renders such extensions impossible
=C2=A0
=C2=A0
=
--
<=
b>Christopher Dearlove
Senior Principal Engineer
BAE Systems Ap=
plied Intelligence Laboratories
__________________=
________________________________________________________
<=
br>T: =C2=A0+44 (0)1245 2421=
94 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, C=
helmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baes=
ystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England &=
amp; Wales No: 01337451
Registered Office: Surrey Research Park, Guildford,=
 Surrey, GU2 7YP
=
=C2=A0
From:=
=C2=A0Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]=C2=A0
Sent:=C2=A017 March 2016=
 16:48
To:=C2=A0Dearlove, Christopher (UK)
Cc:=
=C2=A0ietf@thomasclausen.org; Mobile Ad Hoc Networks mailin=
g list
Subject:=C2=A0Re: [manet] Message integrity a=
nd message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple=
 of big ticket Items)
=C2=A0
=C2=A0
*** WARNING ***
This message originates from outside our=
 organisation, either from an external partner or the internet.=

Consider ca=
refully whether you should click on any links, open any attachments or repl=
y.
For info=
rmation regarding=C2=A0Red Flag=
s=C2=A0t=
hat you can look out for in emails you receive, click<=
span style=3D"font-size:10.5pt;font-family:Arial,sans-serif;color:rgb(51,57=
,114)">=C2=A0here.
If you feel the email is suspicious, ple=
ase follow=C2=A0this process.=

Hi all,
=

=C2=A0
Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <=
;chri=
s.dearlove@baesystems.com>:
=C2=A0
Good point about whether you just pass on one =
cost or a set of costs. As I said, not looked at details - I will, when tim=
e permits. One cost is much easier, and yes, it reduces the fixed size aggr=
egated signatures problem to =E2=80=9Cjust=E2=80=9D one of computational lo=
ad.
=C2=A0
For the record, Thomas=E2=80=99 understanding is correct; th=
e cost is one aggregated value.=C2=A0
<=
div>
=C2=A0
=

Best regards,=C2=A0
<=
div>
Lotte Steenrbink
<=
/div>



=C2=A0
=

--
Christophe=
r Dearlove
Senior Principal Engineer
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 Technolo=
gy Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE =
Systems Applied Intelligence Limited
Registered in England & Wales N=
o: 01337451
Registered Office: Surrey Research Park, Guildford, Surre=
y, GU2 7YP
<=
span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73=
,125)">=C2=A0
From:=
=C2=A0ietf@thomasclausen.org=C2=A0[mailto:ietf@th=
omasclausen.org]=C2=A0
Sent:=C2=A0<=
/span>17 March 2016 16:38
To:=C2=A0Dearlove, Christo=
pher (UK)
Cc:=C2=A0Mobile Ad Hoc Networks mailing li=
st
Subject:=C2=A0Re: Message integrity and message m=
utability (was RE: [manet] draft-ietf-manet-aodvv2-13 review - a couple of =
big ticket Items)
=C2=A0
=
=C2=A0
*** WARNING ***
This message originates f=
rom outside our organisation, either from an external partner or the intern=
et.
Consider carefully whether you should click on any links, open any atta=
chments or reply.
For information regarding=C2=A0<=
strong>Red Flags=C2=A0that you can look out for in emails you receive, click=
=C2=A0here.If you feel the email is =
suspicious, please follow=C2=A0=
this process.
=C2=A0
On 17 Mar 2016, at 17:30,=
 Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wro=
te:
=
=C2=A0
I appreciate Thomas=E2=80=99s comments about the limitations =
of message regeneration, but I would be a bit less absolute.<=
u>
=C2=A0
The issues over end to end authentication and more a=
dvanced signatures are valid. I need to read the given reference on aggrega=
te signatures to increase my knowledge (thanks for it), but my understandin=
g of the possibilities in this field may offer a solution to the problem, b=
ut with some other issues (possibly including a new type of TLV).=

=C2=A0
But the hop count/limit point I don=E2=80=99t f=
ully agree with, you can regenerate with an incremented/decremented count/l=
imit, which leaves the ability to prevent messages propagating indefinitely=
, including expanding ring searches, and retains the ability to use RFC 549=
7 interval and validity times that might be useful with an expanding ring s=
earch (or might not).
=C2=A0
But the key issu=
e is that AODVv2 wants to accumulate metrics. I still haven=E2=80=99t got t=
o the bottom of many details here, but let=E2=80=99s for the moment just co=
nsider that conceptually.
=

=C2=A0
<=
/div>
It=E2=80=99s=
 hard to handle end to end. Charlie=E2=80=99s draft attempts to do an end t=
o end of some information, not this information. I=E2=80=99m not sure if th=
at=E2=80=99s useful (and the specialised format is better avoided if possib=
le). Other approaches are hop by hop (might as well use packet signatures) =
and shared key (might as well go hop by hop). Pairwise signatures for each =
pair of routers I=E2=80=99m discounting as scaling terribly. In the interes=
ts of completeness let=E2=80=99s mention not accumulating metrics, which pu=
ts us back to hop count and that=E2=80=99s not ideal either.<=
u>
=C2=A0
I don=E2=80=99t think there is an ideal solution. (I=
 like ideas I=E2=80=99ve seen about aggregating, but that has some issues o=
f its own, even apart from computational load.) I=E2=80=99d love to be prov=
ed wrong - someone with the perfect solution to come along.
=
=C2=A0
Which means that either we make an arbitrary choice -=
 which will be disagreed with, but needs discussing first - or create somet=
hing flexible. Unfortunately flexible in that regard constrains in others, =
e.g. some (many? most?) aggregating signatures need fixed data sizes (which=
 we can do by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count=
, but that has a cost too).
=C2=A0<=
/div>
I have been told by=
 people much more well versed in this than I in cryptology, that the correc=
t answer is =E2=80=9Csome=E2=80=9D.
=C2=A0
<=
/div>
That said, "AODVv2 wants to=
 accumulate metrics=E2=80=9D =E2=80=94 does that mean that the message grow=
s as it is being forwarded, and that the recipient of a RREQ/RREP will know=
 the individual costs of each path segment? My understanding is, that the r=
ecipient will get =E2=80=9Cthe sum the costs of each path segment=E2=80=9D =
which should be fitting within a fixed size?
=C2=A0
Thomas
=C2=A0=



<=
br>
=C2=A0
Sorry, no answers, just comments. And =
I=E2=80=99m not addressing Thomas=E2=80=99s later points here.
=C2=A0
--
Christopher Dearlove
Senior Principal En=
gineer
BAE Systems Applied Intelligence Laboratories
_____________________________________________________________________=
_____

T: =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E:=C2=A0chris.d=
earlove@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<=
/u>
Regis=
tered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
=C2=A0
From:=C2=A0manet [mailto:manet-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0ietf@thomasclausen.org
Sent=
:=C2=A017 March 2016 16:00
To:=C2=A0Mobile Ad Hoc Networks mailing list
Subject:=C2=A0[=
manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items
=C2=A0
=C2=A0=

*** WARNING ***
This message originates from ou=
tside our organisation, either from an external partner or the internet.
Co=
nsider carefully whether you should click on any links, open any attachment=
s or reply.
For information regarding=C2=A0Red Flags=C2=A0=
that you can look out for in emails you receive, click<=
span>=C2=A0here.
If you feel the email is suspici=
ous, please follow=C2=A0this process.
***=C2=A0WARNING=C2=A0***EXTERN=
AL EMAIL -- This message originates from outside our organization.
=C2=A0=

Dear al=
l,
=C2=A0
Apologies for not having gotten this done sooner =
- day-job leaving few spare cycles.
=C2=A0
I=E2=80=99=
ve previously offered reviews and comments, and some of those have been add=
ressed in the latest I-D =E2=80=94 others have not, but should be. I recall=
 that there was some mail attempting to rebut parts of the review, and I wi=
ll dig it out and reply to that.
=C2=A0
With that bei=
ng said, I have reviewed the latest version of the document, and full detai=
ls will be forthcoming. There=E2=80=99re a couple of big-ticket/architectur=
al items that I want to address up front, as I believe that before we have =
those hammered out, it will be useless to go into details. Note, I do not c=
laim that this is an exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D,=
 but that=E2=80=99s as far as I have gotten in thinking this through.
=C2=A0
I also bring these up as they are items that have b=
een brought up repeatedly over the past years, but not resolved nor discuss=
ed.
=C2=A0
=

Loops
Just to bri=
ng this out: I share Chris=E2=80=99 worry about conflicting and concurrent =
statements from the authors on =E2=80=9CThere are no loops possible=E2=80=
=9D and =E2=80=9CWe need to fix two situations where loops can occur=E2=80=
=9D and =E2=80=9Cwe are still investigating some loop conditions=E2=80=9D
=C2=A0
=

I particularly worry that this is not a discuss=
ion had in public, but apparently in some other forum=E2=80=A6
=
=C2=A0
=C2=A0
Intermediate Route Replies, =
and all of section 10
Section 10 contains a set of =E2=
=80=9Cvaguely specified extensions=E2=80=9D, which is incoherent with the i=
ntended status indicated for this document.=C2=A0
=

=C2=A0<=
u>
Specifically, and this is not unrelated to the point about loops above,=
 intermediate RREPs (section 10.3) are a potential source for loops.=

=C2=A0
=

Expanding Ring Multicast (section 10.1) is not docum=
ented in a way that can be implemented (and also, see =E2=80=9CForwarding-v=
s-regeneration=E2=80=9D below, it is in the present form of this protocol i=
mpossible), etc.
=C2=A0
=C2=A0
Forwarding-vs-regeneration
Recent exchanges on the list=
 made me understand that protocol control messages are *not* forwarded, but=
 are consumed at each hop, then a new message with (almost-but-not-quite) t=
he same content is generated and transmitted.
=C2=A0
=
I have thought some more on this (& read some of the exchanges on the l=
ist on this topic by Chris, Ulrich, and others), and I am convinced that th=
is is not the right way to go,=C2=A0at least=C2=A0for the following =
reasons:
=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0It renders the hop-limit/hop-count fields in the RFC544=
4 message header useless.
=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=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0This would no=
t be bad if the functionality offered by those fields was not useful=

=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=E2=80=94 sadly, it is. For example, for scope li=
mited flooding (expanding ring search, and=C2=A0
<=
/div>
=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=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0such) which may be of interest, and which require hop-limit.=C2=A0<=
/u>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0A hop-count field may also provide a =E2=80=9C=
cheap=E2=80=9D (in terms of overhead) additional piece
<=
/div>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0of information to use conjunctively with a =E2=80=9Creal=E2=80=
=9D metric.
=

=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The only prac=
tical solution would be to re-introduce these functions by way of inserting=
 a
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0MessageTLV =E2=80=94 which (i) is not sp=
ecified in this document, and (ii) which would just
=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=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0serve to render messages bigger than strictly needed.
=
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Scope limited flooding =C2=A0does see=
m to be a necessary requirement, if for no
<=
/div>
=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=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0o=
ther reason than to prevent information from =E2=80=9Ccirculating forever i=
n the network=E2=80=9D.
=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0It makes end-to-end authentication unnecessarily hard.<=
/u>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0I think Chris called this out alre=
ady, but it bears repeating: S generates a message=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=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(say, a RREQ), and includes an ICV calculated over the conten=
t of the message.
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0For any recipient to be a=
ble to validate the ICV, the message has to be exactly
<=
/div>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0the same =E2=80=94 not just in content, but in structure =E2=
=80=94 as what was generated.
=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=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforwarding=E2=80=
=9D messages means, that the intermediate
=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=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0r=
outer =E2=80=9Cregenerating=E2=80=9D the RREQ may chose a different structu=
re (e.g., include TLVs
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0in a different orde=
r).
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The proposal from=C2=
=A0https://tools.ietf.org/html/draft-perkins-manet-aod=
v-e2esec-00
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0is to add constrain=
ts on (i) the set of elements to include in a signature and (ii) the=

=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0order of these elements.
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0One=C2=A0problem with that approach is (i): if an=
 extension adds a message TLV, or an=C2=A0
<=
/div>
=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=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0A=
ddress TLV, to a message, then that will not be =E2=80=9Ccovered=E2=80=9D b=
y the proposed e2esec TLV.
=

=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=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Rather for *each=
* extension developed, an =E2=80=9Cupdates e2esec=E2=80=9D clause needs to =
be done.
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I=E2=80=99d say =
that this approach would be prone to errors =E2=80=94 and add entropy to th=
e process
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0of designing protocol extensions. =
The alternative, a message being generated by the
=

=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=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0source and *forwarded* (as we do in OLSRv2, for example) would al=
low ICV TLVs=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(even, allow reuse of tho=
se specified for OLSRv2) for covering a message and=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=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0extensions.
<=
div>
=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=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9CBut what about the metrics value which will change on each hop=
=E2=80=9D, you may say?
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Fortunately, that i=
s relatively easy to handle: simply zero out the value of that TLV when<=
/u>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0generating or verifying the ICV MessageTLV. An=
d use Packet-TLVs for hop-by-hop=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=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0auth=
entication, if needed (but, see below).
=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It prevents the use of more clever/advan=
ced signature schemes/ICVs
=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=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Aggrega=
te signature algorithms (=C2=A0https://crypto.stanford.edu/~da=
bo/papers/aggsurvey.pdf)
=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=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0exist, =
and an interesting use-case can be found in also reactive protocols, allowi=
ng verifying
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0not =E2=80=9Cjust=E2=80=9D the =
end points, but also the intermediaries (again, with the appropriate =E2=80=
=9Czero out=E2=80=9D
<=
div>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0discussed above, or so=
mething smarter).
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Regeneration of messages,=
 rather than forwarding, renders that impossible (or, if used,
<=
span>=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0updating to =C2=A0https://tools.ie=
tf.org/html/draft-perkins-manet-aodv-e2esec-00)
=C2=
=A0
There are other reasons, but the above are those that jump a=
t me as immediate show-stoppers.
=C2=A0
I do honestly=
 not see what possible benefit there is from =E2=80=9Cregeneration=E2=80=9D=
 =E2=80=94 but I see very clear inconveniences, and security is not the lea=
st of these. Insisting on =E2=80=9Cregeneration=E2=80=9D requires developme=
nt of =E2=80=9Cnon-general workarounds=E2=80=9D as pointed out above.
=C2=A0
Security Considerations=

Th=
is is an always thorny subject. When OLSRv2 was going through the process w=
e got a thorough education in how little we knew about security from the SE=
C-ADs, and had to spend about a year or so developing RFC7183. The bottom l=
ine is, that this protocol needs its =E2=80=9CRFC7183 =C2=A0equivalent=E2=
=80=9D, either as part of the main document, or as an independent document.=
 currently, that is not the case.
=C2=A0
A minima, lo=
oking at BCP72 and BCP107 =E2=80=94 taking inspiration from RFC7183 might b=
e aw good idea, as that was the most recent that went through the SEC AD. R=
egardless of how, however, a =E2=80=9Cmandatory to implement=E2=80=9D secur=
ity mechanism most be specified (I think the right term was =E2=80=9CMUST i=
mplement, SHOULD use=E2=80=9D), in sufficient detail to ensure interoperabl=
e implementations.
=C2=A0
<=
/div>
As an example, both [RFC613=
0] and [RFC7181] set out that that:
=C2=A0
=C2=
=A0 =C2=A0 =C2=A0 On receiving a ... message, a router MUST first check if =
the
=C2=A0 =C2=A0 =C2=A0 message is invalid for processing by th=
is router
=C2=A0
and then proceed to give a number of=
 conditions that, each, will lead to a rejection of the message as "ba=
dly formed and therefore invalid for processing=E2=80=9D =E2=80=94 a list w=
hich RFC7183 then amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 f=
or inserting =E2=80=9Crejection=E2=80=9D. Idem for message generation.
=C2=A0
If I was to do RFC7181/RFC6130 today, I would incl=
ude that directly into the protocol specifications. It turned out to be mor=
e overhead (and slow down publication anyways) to do it as separate documen=
ts.
=C2=A0
Secondly, we need to be a lot more r=
igid in terms of what ICVs, Timestamps, etc. are added/removed, and what th=
at brings.
<=
div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">=C2=A0
For example (with the assumption th=
at messages are *forwarded* and *not* regenerated), this could be one optio=
n:
=C2=A0
<=
div>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0When a RRE=
Q, RREP message is generated, add an ICV Message TLV, which is calculated &=
lt;this way>
<=
div>
=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=A6(take inspiratio=
n from RFC7183 here)
<=
div>
=C2=A0
<=
/div>
...=


[Message clipped]=C2=A0=C2=A0
__________________________________=
_____________

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>



--001a1139558c081042053123f06c--


From nobody Sun Apr 24 09:10:53 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 4B01C12D1E9 for ; Sun, 24 Apr 2016 09:10:52 -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 qslF91FfVb3s for ; Sun, 24 Apr 2016 09:10:49 -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 8856112D1A0 for ; Sun, 24 Apr 2016 09:10:48 -0700 (PDT)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1auMcQ-000n6W-6N>; Sun, 24 Apr 2016 18:10:46 +0200
Received: from x4dbae210.dyn.telefonica.de ([77.186.226.16] helo=[192.168.1.130]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id <1auMcP-003odT-9a>; Sun, 24 Apr 2016 18:10:46 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_4E81EA54-1C3B-4593-A5FB-56670FFCB2E5"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Lotte Steenbrink 
In-Reply-To: 
Date: Sun, 24 Apr 2016 18:10:44 +0200
Message-Id: <759A0E8C-8224-453F-8128-254398DFEFC3@fu-berlin.de>
References:     
To: Mobile Ad Hoc Networks mailing list 
X-Mailer: Apple Mail (2.3112)
X-Originating-IP: 77.186.226.16
X-ZEDAT-Hint: A
Archived-At: 
Cc: Christopher Dearlove 
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03
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, 24 Apr 2016 16:10:52 -0000

--Apple-Mail=_4E81EA54-1C3B-4593-A5FB-56670FFCB2E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Christopher,

> Am 15.04.2016 um 19:49 schrieb Christopher Dearlove =
:
>=20
> A few immediate comments inline below.
>=20
> -- =20
> Christopher Dearlove
> christopher.dearlove@gmail.com  =
(iPhone)
> chris@mnemosyne.demon.co.uk  =
(home)
>=20
> On 15 Apr 2016, at 15:18, Lotte Steenbrink =
> =
wrote:
>=20
>> Hi all,
>>=20
>> sparked by the recently started WGLC, I=E2=80=99ve reviewed the =
current revision of the draft. I=E2=80=99d like to offer the working =
group my perspective as someone who doesn=E2=80=99t have decades of =
protocol and/or packet format design under their belt (i.e. some things =
might not be obvious to me that are obvious to others), but also as =
someone who has worked with RFC 5444 when implementing a routing =
protocol (AODVv2), updating the packet format of a routing protocol =
(AODVv2 again) and (partially) implementing my own RFC5444 =
builder/parser.
>>=20
>> Overall, I think the document is easy to read and follow. To me, it =
contains valuable information and guidance and in some cases prevents =
people from shooting themselves in the foot.
>> I=E2=80=99m really happy this document exists and I=E2=80=99d like it =
to move forward soon, but I do feel that it is still lacking in some =
areas, which is why I was a bit surprised to see it go to Last Call all =
of a sudden.
>=20
> Not really. The authors had said what they intended to say, no one was =
commenting, time for WGLC.

I was kind of still waiting for an answer to my E-Mail from October (see =
below)...

>=20
>> First, some nitpicks and comments:
>>=20
>> * from 1.2.1 =
. Packet/Message Format:
>>=20
>>       [=E2=80=A6] a packet
>>       transmission following a successful packet reception is by =
design
>>       of a new packet that may include all, some, or none of the
>>       received messages [...]
>>=20
>> I=E2=80=99m not a native speaker, but that =E2=80=9Eof=E2=80=9C seems =
out of place...
>=20
> I am a native speaker, and no, it's not. Some would repeat it after =
each of all, some and none, and I might sometimes. But it really doesn't =
matter which of the two styles we pick, the RFC Editor may well change =
to the other.

OK cool, then I learned something new. :) Sorry about the fuss, and =
thanks for the explanation.

>=20
>> * Regarding 4.2 =
. Packets and Messages:
>> this section talks a lot about how the multiplexer operates, so I =
think it=E2=80=99d be helpful if its title reflected that.=20
>=20
> I'm of two opinions on that. On the one hand it is, as its title =
suggests, about the packet and message level, as opposed to lower =
levels, and its title contrasts with that if 4.3 for that reason. On the =
other hand you are right, it does have much about the multiplexer. A =
title covering all three woukd start getting cumbersome. Will take this =
one away to think about.
>=20
>> * from 4.4 =
. Addresses Require Attributes:
>>=20
>>    An unmodified extension to NHDP would ignore such addresses,
>>    as required, as it does not support that specialized purpose.
>>=20
>> At first glance, (to me) this reads as =E2=80=9EAll addresses that =
are associated with an unknown TLV are ignored=E2=80=9C, which is =
obviously nonsense (but quite panic-inducing :D). I=E2=80=99d propose to =
reword it to something along the lines of=20
>>    An unmodified extension to NHDP would not consider this
>>    address to be of a neighbor, as it is lacking a LINK_STATUS
>>    or OTHER_NEIGHB TLV.
>=20
> I take your point, but I think that if the address ends up with no =
relevant associated TLVs then it is ignored is also a point. I dare say =
we can wordsmith something.
>=20
>> Also, I don=E2=80=99t quite get where you=E2=80=99re going with the =
last paragraph of that section (=E2=80=9CThese restrictions do not, =
however, mean that added information is
>>    completely ignored for purposes of the base protocol.=E2=80=9D)...
>=20
> Read on, the rest of the paragraph describes the case where not. But =
we might telegraph that better in the opening sentence.

I know it does, but I don=E2=80=99t quite see how the paragraph fits =
into the rest of the section and what exactly it wants to warn users =
about.

>=20
>> * regarding the maps in 4.5 =
. Information Representation:
>> I=E2=80=99m afraid I just don=E2=80=99t really understand the purpose =
of this section and the mapping notation. I=E2=80=99m assuming that the =
maps are supposed to offer a way of describing how a TLV relates to a =
message or an address?=20
>> If so, why does it only mention extension types, but not the basis =
types?
>=20
> It says extended types, meaning the combination of the two. But full =
type would be better, as almost defined in 5444. In fact I think we =
should add a comment to the notation section. (5444 uses a symbolic name =
rather than the phrase.)
>=20
>> Or is it supposed to be used something like this:
>>=20
>> BASE_TLV
>>=20
>> Message:=20
>> (base_tlv_extension_type_1) -> (2 octets, "value a when condition x =
is met")
>> (base_tlv_extension_type_2) -> (2 octets, "value b when condition y =
is met")
>>=20
>> ? Also, I don=E2=80=99t quite get how this would be used in future =
protocol specifications? Or aid in implementing RFC5444 parsers?
>> An example or a clarification would be very helpful.
>=20
> It's a way of looking at things. But not the only one, it goes on to =
discuss variants. I think it mostly comes under heading of if useful use =
it, if not skip it.

I get that, I just wanted to point out that at least to me, it isn=E2=80=99=
t quite obvious if this section would be useful for me, because I =
don=E2=80=99t get what it=E2=80=99s trying to say. If I=E2=80=99m not =
the target audience that=E2=80=99s finde, but I thought it may be =
something to consider otherwise.

> We'll take another look, but I don't think this will ever be =
elementary.
>=20
>> * regarding 4.6 =
. TLVs:
>> In general, it=E2=80=99s not clear everywhere in the section whether =
you=E2=80=99re talking to RFC5444 parser/builder implementors or =
protocol designers.=20
>>=20
>>    A protocol SHOULD use an efficient
>>    representation, but this is a quality of implementation issue.
>>=20
>> I=E2=80=99m not sure where you=E2=80=99re going with the last part of =
that sentence? I=E2=80=99d reword it to something like =E2=80=9EA =
protocol SHOULD use an efficient representation, avoiding unnecessarily =
verbose use of TLVs and extension types. However, the final arrangement =
in a message- or addressTLV block is  a quality of implementation =
issue=E2=80=9C (in case that=E2=80=99s what you meant).
>=20
> No, you're considering the protocol design. This is considering the =
protocol object that implements the protocol. There isn't a one to one =
mapping from information to representation, it's up to the =
implementation to do it efficiently. Different implementations of the =
same protocol specification may do better or worse here. (Trivial case, =
an implementation could choose to never compress addresses. Bad idea, =
but legal.)

In that case, I find the current wording very misleading.

>=20
>> And then:
>>=20
>>    A
>>    protocol MUST recognize any permitted representation of the
>>    information; even if it chooses to (for example) only use =
multivalue
>>    TLVs, it MUST recognize single value TLVs (and vice versa).
>>=20
>> =E2=80=A6 I thought protocols weren=E2=80=99t supposed to specify =
whether a TLV is arranged (for example) as a multivalue TLV?!
>=20
> Implementation again, not design.

Misleading wording then, again.

>=20
>> And so, since a protocol shouldn't be concerned with multivalue TLVs =
and the like, wouldn=E2=80=99t it be the *RFC5444 implementation* that =
MUST recognize any permitted representation?
>=20
> You're assuming that there is an RFC 5444 implementation. That's the =
same way to work if you plan to implement more than one protocol. But =
nothing says you have to do it that way. The architecture defined by =
5498 admits of the multiplexer and protocols, and thus these are rules =
on the protocol. If protocols delegate all their common work to =
something (parser/creator) then it inherits those restrictions, but =
that's not defined, and we can't assume it.

Hmm. But even if a protocol implementation has its own RFC5444 message =
building code which is not generic and deeply entangled in the rest of =
the code, the parser checking a message still does this based on RFC5444 =
specifications, not on the protocol specifications (since the protocol =
must not know or care about stuff like multivalue TLVs)? So to me, =
that=E2=80=99d put it into 5444 territory.

I guess what I=E2=80=99d expected from the document is to say =E2=80=9Cthe=
se are the entities involved*, and they have tasks x, y and z, and they =
talk to each other like so, and while they may not be present as =
autonomous entities in specific implementations we=E2=80=99ll use them =
in this draft to describe what should (not) be going on where=E2=80=9D. =
It=E2=80=99s not trivial to figure out the distribution of tasks here =
(I=E2=80=99m still struggling with it 2 years in and I=E2=80=99m not =
sure if my intellect is the sole cause of this), and I think it =
would=E2=80=99ve been helpful if 5444-usage cleared it up a bit.

* probably something like Protocol, RFC5444 message building/parsing =
component, multiplexer?

>=20
>> Or is this paragraph really just a complicated way of saying =E2=80=9Ea=
s a protocol designer, make sure to not specify/rely on things like (for =
example) multivalue TLVs, since your messages have to work with *any* =
representation=E2=80=9C? If so, I think that should be done in a less =
complicated fashion (see below).
>>=20
>> * regarding 5 =
.=
 Structure:
>> Since this section talks a lot about flags, it=E2=80=99d be nice if =
its title represented that. Maybe consider renaming it to =E2=80=9EStructu=
re and Flags=E2=80=9C or so?
>=20
> I mostly don't agree. Structure is the subject, flags are a detail.
>=20
>> * from 6.1 =
. Address Block Compression:
>>=20
>>    Compression of addresses in an Address Block considers addresses =
to
>>    consist of a Head, a Mid, and a Tail, where all addresses in an
>>    Address Block have the same Head and Tail, but different Mids.
>>=20
>>=20
>> I=E2=80=99d find this sentence easier to read if it started with =
=E2=80=9CCompression of addresses in an Address Block is possible when =
addresses consist of a Head, a Mid [=E2=80=A6]=E2=80=9D.
>=20
> No. That's missing the point and misleading. Addresses are always =
considered to have the head/mid/tail format. Compression is possible if =
either the head or tail (or both) is non-empty.

Mh, true.

>=20
>> * from 6.1 =
. Address Block Compression:
>>=20
>>    Putting addresses into a message efficiently also has to include:
>>=20
>> Why =E2=80=9Ehas to=E2=80=9C? I=E2=80=99d think that would be a =
=E2=80=9Emay=E2=80=9C. Multiple Adress Blocks and/or reordering don=E2=80=99=
t increase efficiency in all possible cases...
>=20
> I think that's the wrong change. Rather "include" should be =
"consider=E2=80=9C.

Sounds good.

>=20
>> * from 6.2 =
. TLVs:
>>       [...] This is even possible if the MPR TLV specified in
>>       OLSRv2 [RFC7181 ] is =
added; but it is not possible, in general, if
>>       the LINK_METRIC TLV is also added.
>>=20
>> Why is it not possible for the latter? If that could be =
explained/hinted at in a half sentence, I think it=E2=80=99d be helpful =
information to have in the draft.
>=20
> That's very hard, and not just because it's a negative. It's really an =
observation that motivates the duscussion. A half sentence would I think =
confuse more than it enlightens (it's because you have too many =
constraints to satisfy at once - I doubt that helped).

I think it actually did :)

>=20
>>       In a typical case where a
>>       LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with
>>       enough addresses, sorted appropriately, two single value TLVs =
can
>>       be more efficient than one multivalue TLV.
>>=20
>> Same thing: why?
>=20
> Here I think this should be obvious to anyone who has looked at 5444.

Well, yeah, I get why using multivalue TLVs can be more efficient, what =
I was getting at was that you=E2=80=99d have to be familiar with  =
LINK_STATUS TLVs in order for this specific example to be clear. But now =
that I=E2=80=99m thinking about it that was rubbish. TL;DR: nevermind.

>=20
>> * regarding the second paragraph from 6.3 =
. TLV Values, i.e.
>>   =20
>>    This approach was specified in [RFC7188 =
], and required for protocols
>>    that extend [RFC6130 ] and =
[RFC7181 ].  It is here RECOMMENDED =
that
>>    this approach is followed when defining any Address Block TLV that
>>    may be used by a protocol using [RFC5444 =
].
>>=20
>> The term =E2=80=9Ethis approach=E2=80=9C confused me, since I =
initially  thought it meant =E2=80=9Ethe approach is to use UNSPECIFIED =
in a way that makes sense=E2=80=9C rather than =E2=80=9Ethe approach is =
to use UNSPECIFIED=E2=80=9C. Maybe that could be reworded to something =
along the lines of=20
>> The UNSPECIFIED TLV and its usage was specified in [RFC7188]=E2=80=A6=20=

>> ?
>=20
> No. There is no UNSPECIFIED TLV. There is a recommendation to include =
an UNSPECIFIED value in a TLV. But really, we've described this once in =
7188, it's there to read.
>=20
>> * regarding 6.3 =
. TLV Values:
>> The second paragraph is a bit confusing and seems to explaing roghly =
the same things as the fourth paragraphs. I=E2=80=99d propose to merge =
the second into the fourth.
>=20
> I'm not sure I exactly agree, but the ordering in that section could =
be improved.

That=E2=80=99d be great.

>=20
>> * from 6.4 =
. Automation:
>>=20
>>    The possible gain depends on the efficiency
>>    of the original message creation,
>>=20
>> the term =E2=80=9Ethe original message creation=E2=80=9C seems a bit =
ambiguous=E2=80=93 does this refer to the message as created by an =
RFC5444 message builder implementation?
>=20
> Yes.

Okay, thanks :)

>=20
>> Additionally, I'm concerned about two things that *aren=E2=80=99t* in =
the draft:
>>=20
>> *  Some of the AODVv2 co-authors and me have asked for a list of =
=E2=80=9Eas a protocol, you can set all of these fields of a message, =
but please leave the rest alone=E2=80=9C, which would=E2=80=99ve saved =
us many hours of discussions (and Henning a lot of time spent explaining =
these things=E2=80=A6). These requests have been met with a refusal to =
specify a concrete API, as such an effort is dependent on outside =
factors such as programming language or software architecture. I agree =
with this notion, but a programming-language dependent API is not what =
we=E2=80=99ve asked for. I=E2=80=99ve tried to supply a sketch of what I =
did ask for in [1], but unfortunately I didn=E2=80=99t get an answer =
(and as far as I can see it, the draft wasn=E2=80=99t changed either). I =
still think that such a list, in whatever form, would be very helpful =
for future Internet-Draft authors and I also think this request is in =
accordance with the intentions stated in 1.1 History and Purpose, and I =
think it should be included in the document.
>=20
> No. There are many reasons why we're just not touching this one.
>=20
> One is that language independence is a mirage. How you go about things =
is completely different in, for example an object oriented language than =
one that isn't. Section 4.5 shows that there are quite different ways of =
doing things even given a decision to use a map approach, and there are =
other approaches than that. It would be wrong and beyond our competence =
to suggest one of these as "best". There's reasons the IETF doesn't do =
this, and that's one.

What does this have to do with object orientation? I=E2=80=99m not =
asking for the draft to contain a recommendation on how to implement  =
RFC 5444 message building/parsing code.

Kind regards,
Lotte

>=20
> Plus, frankly, the work it would take is beyond what we choose to =
spend.
>=20
>> * As the exact rules for using/setting the hop count & hop-limit =
fields are currently being discussed w/ regard to AODVv2 in another =
thread [2]=E2=80=93 should a definitive answer to that question be part =
of 5444-usage?
>=20
> You don't want that. Because if we did specify that you'd find =
yourself more constrained than you want to be. There is a design intent =
described in 5444, but it assumes immutable messages. Which you don't =
want. Really, we're doing you a favour by not imposing on you.
>=20
>> Best regards,
>> Lotte
>>=20
>> [1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.html =

>> [2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.html =
=20
>>=20
>>=20
>>> Am 06.04.2016 um 19:14 schrieb Justin Dean >:
>>>=20
>>> The chairs agree that a 3 week WGLC is appropriate.  Everyone please =
read the draft early and get comments in early so that they can be =
addressed within the last call period.
>>>=20
>>> Justin
>>>=20
>>> On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) =
> =
wrote:
>>> Obviously +1 to the request for WGLC.
>>>=20
>>> With regard to what's changed, technically the only significant =
thing is to make it clear that if a protocol delivers a message to the =
multiplexer, the multiplexer must pass it on unchanged to the protocol =
(another instance of, at another router) unchanged. Without that nothing =
that the protocol itself chooses to do with regard to security makes =
sense. Though the protocol can alternatively let the multiplexer do the =
security, 7182 can be implemented in either way. This isn't really new, =
but it wasn't formally spelled out. It's presented as part of spelling =
out multiplexer rules more carefully.
>>>=20
>>> But what about message optimisation? That's a function of =
constructing a 5444 message, not the multiplexer, and is down to that =
5444 includes two things - packet/message structure (and implicitly, and =
in pretty much any implementation I would expect to see, a parser and =
builder for that structure) and the multiplexer. So we took the =
opportunity to separate out more clearly a discussion of the two, which =
we think will be helpful.
>>>=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
>>> -----Original Message-----
>>> From: manet [mailto:manet-bounces@ietf.org =
] On Behalf Of Ulrich Herberg
>>> Sent: 05 April 2016 20:08
>>> To: manet@ietf.org 
>>> Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03
>>>=20
>>> ----------------------! WARNING ! ---------------------- This =
message originates from outside our organisation, either from an =
external partner or from the internet.
>>> Consider carefully whether you should click on any links, open any =
attachments or reply.
>>> Follow the 'Report Suspicious Emails' link on IT matters for =
instructions on reporting suspicious email messages.
>>> --------------------------------------------------------
>>>=20
>>> *** WARNING ***
>>> EXTERNAL EMAIL -- This message originates from outside our =
organization.
>>>=20
>>>=20
>>> Hi,
>>>=20
>>> As you have seen, we have submitted a new revision of 5444-usage. =
The authors feel comfortable that we have addressed all issues by this =
version, and would like to ask the WG chairs to issue a WGLC on this =
document. While it is a fairly short document, given that it is IETF =
week for some, we'd suggest that a 3-4 week WGLC would be appropriate.
>>>=20
>>> Best regards
>>> Ulrich
>>>=20
>>> _______________________________________________
>>> manet mailing list
>>> manet@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/manet =

>>>=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 =

>>>=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=_4E81EA54-1C3B-4593-A5FB-56670FFCB2E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi Christopher,

Am 15.04.2016 um 19:49 schrieb =
Christopher Dearlove <christopher.dearlove@gmail.com>:

A few immediate =
comments inline below.

--  
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)

On 15 Apr 2016, at 15:18, Lotte Steenbrink =
<lotte.steenbrink@fu-berlin.de> wrote:

Hi all,

sparked by the recently started WGLC, I=E2=80=99ve reviewed =
the current revision of the draft. I=E2=80=99d like to offer the working =
group my perspective as someone who doesn=E2=80=99t have decades of =
protocol and/or packet format design under their belt (i.e. some things =
might not be obvious to me that are obvious to others), but also as =
someone who has worked with RFC 5444 when implementing a routing =
protocol (AODVv2), updating the packet format of a routing protocol =
(AODVv2 again) and (partially) implementing my own RFC5444 =
builder/parser.

Overall, I think the document is easy to read and follow. To =
me, it contains valuable information and guidance and in some cases =
prevents people from shooting themselves in the foot.
I=E2=80=99m really happy this document exists and I=E2=80=99d =
like it to move forward soon, but I do feel that it is still lacking in =
some areas, which is why I was a bit surprised to see it go to Last Call =
all of a sudden.

Not really. The authors had said what =
they intended to say, no one was commenting, time for =
WGLC.

I was =
kind of still waiting for an answer to my E-Mail from October (see =
below)...


First, some nitpicks and =
comments:

* =
from 1.2.1. Packet/Message Format:

      [=E2=80=A6] a packet
      transmission =
following a successful packet reception is by design
      of a new packet that may include all, some, or none of the
      received messages [...]

I=E2=80=99m not a native =
speaker, but that =E2=80=9Eof=E2=80=9C seems out of =
place...

I am a native speaker, and no, it's not. Some would =
repeat it after each of all, some and none, and I might sometimes. But =
it really doesn't matter which of the two styles we pick, the RFC Editor =
may well change to the =
other.

OK cool, then I learned something new. :) Sorry =
about the fuss, and thanks for the explanation.


* Regarding 4.2. Packets and Messages:
this =
section talks a lot about how the multiplexer operates, so I think =
it=E2=80=99d be helpful if its title reflected =
that. 

I'm of two opinions on that. On the one hand it is, as =
its title suggests, about the packet and message level, as opposed to =
lower levels, and its title contrasts with that if 4.3 for that reason. =
On the other hand you are right, it does have much about the =
multiplexer. A title covering all three woukd start getting cumbersome. =
Will take this one away to think about.

* from 4.4. Addresses Require Attributes:

   An unmodified =
extension to NHDP would ignore such addresses,
   as required, as it does not support that specialized =
purpose.

At first glance, (to me) this reads as =E2=80=9EAll addresses =
that are associated with an unknown TLV are ignored=E2=80=9C, which is =
obviously nonsense (but quite panic-inducing :D). I=E2=80=99d propose to =
reword it to something along the lines of 
   An unmodified =
extension to NHDP would not consider this
   address to be of a neighbor, as it is =
lacking a LINK_STATUS
  =
 or OTHER_NEIGHB TLV.

I take your point, but I think that if =
the address ends up with no relevant associated TLVs then it is ignored =
is also a point. I dare say we can wordsmith something.

Also, I don=E2=80=99t quite get where you=E2=80=99re going with the last paragraph of that section =
(=E2=80=9CThese =
restrictions do not, however, mean that added information =
is
   =
completely ignored for purposes of the base protocol.=E2=80=9D)...

Read on, the rest of the paragraph =
describes the case where not. But we might telegraph that better in the =
opening sentence.

I know it does, but I don=E2=80=99t quite see how =
the paragraph fits into the rest of the section and what exactly it =
wants to warn users about.


* regarding the maps =
in 4.5. Information Representation:
I=E2=80=
=99m afraid I just don=E2=80=99t really understand the purpose of this =
section and the mapping notation. I=E2=80=99m assuming that the maps are =
supposed to offer a way of describing how a TLV relates to a message or =
an address? 
If so, why does it only mention =
extension types, but not the basis types?

It says extended types, meaning the =
combination of the two. But full type would be better, as almost defined =
in 5444. In fact I think we should add a comment to the notation =
section. (5444 uses a symbolic name rather than the phrase.)

Or is it supposed to be used something like =
this:

BASE_TLV

Message: 
(base_tlv_extension_type_1) -> (2 octets, =
"value a when condition x is met")
(base_tlv_extension_type_2) -> (2 octets, =
"value b when condition y is met")

? Also, I don=E2=80=99t quite get how =
this would be used in future protocol specifications? Or aid in =
implementing RFC5444 parsers?
An example or a =
clarification would be very helpful.

It's a way of looking at things. But not =
the only one, it goes on to discuss variants. I think it mostly comes =
under heading of if useful use it, if not skip it. =


I =
get that, I just wanted to point out that at least to me, it isn=E2=80=99t=
 quite obvious if this section would be useful for me, because I don=E2=80=
=99t get what it=E2=80=99s trying to say. If I=E2=80=99m not the target =
audience that=E2=80=99s finde, but I thought it may be something to =
consider otherwise.

We'll take another look, but I don't think =
this will ever be elementary.

* regarding 4.6. TLVs:
In general, it=E2=80=99s not clear everywhere in the section whether =
you=E2=80=99re talking =
to RFC5444 parser/builder implementors or protocol =
designers. 

   A protocol =
SHOULD use an efficient
   representation, but this is a quality of implementation =
issue.

I=E2=80=99=
m not sure where you=E2=80=99re going with the last part of that =
sentence? I=E2=80=99d reword it to something like =E2=80=9EA protocol =
SHOULD use an efficient representation, avoiding unnecessarily verbose =
use of TLVs and extension types. However, the final arrangement in a =
message- or addressTLV block is  a quality of implementation =
issue=E2=80=9C (in case that=E2=80=99s what you =
meant).

No, you're considering the protocol design. This is =
considering the protocol object that implements the protocol. There =
isn't a one to one mapping from information to representation, it's up =
to the implementation to do it efficiently. Different implementations of =
the same protocol specification may do better or worse here. (Trivial =
case, an implementation could choose to never compress addresses. Bad =
idea, but legal.)

In that case, I find the current wording very =
misleading.


And then:

   A
   protocol MUST recognize any permitted representation of the
   information; even if it chooses to (for example) only use multivalue
   TLVs, it MUST recognize single value TLVs (and vice versa).

=E2=80=A6 I thought =
protocols weren=E2=80=99t supposed to specify whether a TLV is arranged =
(for example) as a multivalue TLV?!

Implementation again, not =
design.

Misleading wording then, again.


And so, since a protocol shouldn't be =
concerned with multivalue TLVs and the like, wouldn=E2=80=99t it be the =
*RFC5444 implementation* that MUST recognize any permitted =
representation?

You're assuming that there is an RFC =
5444 implementation. That's the same way to work if you plan to =
implement more than one protocol. But nothing says you have to do it =
that way. The architecture defined by 5498 admits of the multiplexer and =
protocols, and thus these are rules on the protocol. If protocols =
delegate all their common work to something (parser/creator) then it =
inherits those restrictions, but that's not defined, and we can't assume =
it.

Hmm. But even if a protocol implementation has its =
own RFC5444 message building code which is not generic and deeply =
entangled in the rest of the code, the parser checking a message still =
does this based on RFC5444 specifications, not on the protocol =
specifications (since the protocol must not know or care about stuff =
like multivalue TLVs)? So to me, that=E2=80=99d put it into 5444 =
territory.

I guess what I=E2=80=99d =
expected from the document is to say =E2=80=9Cthese are the entities =
involved*, and they have tasks x, y and z, and they talk to each other =
like so, and while they may not be present as autonomous entities in =
specific implementations we=E2=80=99ll use them in this draft to =
describe what should (not) be going on where=E2=80=9D. It=E2=80=99s not =
trivial to figure out the distribution of tasks here (I=E2=80=99m still =
struggling with it 2 years in and I=E2=80=99m not sure if my intellect =
is the sole cause of this), and I think it would=E2=80=99ve been helpful =
if 5444-usage cleared it up a bit.

* =
probably something like Protocol, RFC5444 message building/parsing =
component, multiplexer?


Or is this =
paragraph really just a complicated way of saying =E2=80=9Eas a protocol =
designer, make sure to not specify/rely on things like (for example) =
multivalue TLVs, since your messages have to work with *any* =
representation=E2=80=9C? If so, I think that should be done in a less =
complicated fashion (see below).

* regarding 5. Structure:
Since this section talks a lot =
about flags, it=E2=80=99d be nice if its title represented that. Maybe consider =
renaming it to =E2=80=9EStructure and Flags=E2=80=9C or =
so?

I =
mostly don't agree. Structure is the subject, flags are a =
detail.

* from 6.1. Address Block Compression:

   Compression of addresses in an Address =
Block considers addresses to
   consist of a Head, a Mid, and a Tail, where all addresses in an
   Address Block have the same Head and Tail, but different =
Mids.


I=E2=80=99d find this sentence easier =
to read if it started with =E2=80=9CCompression of addresses in an =
Address Block is possible when addresses consist of a Head, a Mid =
[=E2=80=A6]=E2=80=9D.

No. That's missing the point and misleading. Addresses =
are always considered to have the head/mid/tail format. Compression is =
possible if either the head or tail (or both) is =
non-empty.

Mh, true.


* from 6.1. Address Block Compression:

   Putting addresses =
into a message efficiently also has to include:

Why =E2=80=9Ehas to=E2=80=9C? =
I=E2=80=99d think that would be a =E2=80=9Emay=E2=80=9C. Multiple Adress =
Blocks and/or reordering don=E2=80=99t increase efficiency in all =
possible cases...

I think that's the wrong change. Rather "include" =
should be "consider=E2=80=9C.
Sounds good.


* from 6.2. TLVs:
      [...] This is even possible if the MPR =
TLV specified in
      OLSRv2 [RFC7181] is added; but it is not possible, in =
general, if

      the LINK_METRIC =
TLV is also added.

Why is it not possible for the latter? If that could be =
explained/hinted at in a half sentence, I think it=E2=80=99d be helpful =
information to have in the draft.

That's very hard, and not just because =
it's a negative. It's really an observation that motivates the =
duscussion. A half sentence would I think confuse more than it =
enlightens (it's because you have too many constraints to satisfy at =
once - I doubt that =
helped).

I think it actually did :)


      In a typical =
case where a
      LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with
      enough addresses, sorted appropriately, two single value TLVs can
      be more efficient than one multivalue TLV.

Same thing: =
why?

Here I =
think this should be obvious to anyone who has looked at =
5444.

Well, yeah, I get why using multivalue TLVs can be =
more efficient, what I was getting at was that you=E2=80=99d have to be =
familiar with  LINK_STATUS TLVs in order for this specific example =
to be clear. But now that I=E2=80=99m thinking about it that was =
rubbish. TL;DR: nevermind.


* regarding the second =
paragraph from 6.3. TLV Values, i.e.
   
   This approach was =
specified in [RFC7188], and required for protocols
   that extend [RFC6130] and [RFC7181].  It is here RECOMMENDED that
   this approach is followed when defining any Address Block TLV that
   may be used by a protocol using [RFC5444].

The term =E2=80=9Ethis approach=E2=80=9C =
confused me, since I initially  thought it meant =E2=80=9Ethe =
approach is to use UNSPECIFIED in a way that makes sense=E2=80=9C rather =
than =E2=80=9Ethe approach is to use UNSPECIFIED=E2=80=9C. Maybe that =
could be reworded to something along the lines of 
The UNSPECIFIED TLV and its =
usage was specified in [RFC7188]=E2=80=A6 
?

No. There is no UNSPECIFIED TLV. There is a =
recommendation to include an UNSPECIFIED value in a TLV. But really, =
we've described this once in 7188, it's there to read.

* regarding 6.3. TLV Values:
The second paragraph is a bit =
confusing and seems to explaing roghly the same things as the fourth =
paragraphs. I=E2=80=99d =
propose to merge the second into the =
fourth.

I'm not sure I exactly agree, but the ordering in that =
section could be improved.

That=E2=80=99d be great.


* from 6.4. Automation:

   The possible gain depends on the =
efficiency
   of the original message creation,

the term =E2=80=9Ethe original =
message creation=E2=80=9C seems a bit ambiguous=E2=80=93 does this refer =
to the message as created by an RFC5444 message builder =
implementation?

Yes.

Okay, thanks :)


Additionally, I'm concerned =
about two things that *aren=E2=80=99t* in the draft:

*  Some of the =
AODVv2 co-authors and me have asked for a list of =E2=80=9Eas a =
protocol, you can set all of these fields of a message, but please leave =
the rest alone=E2=80=9C, which would=E2=80=99ve saved us many hours of =
discussions (and Henning a lot of time spent explaining these =
things=E2=80=A6). These requests have been met with a refusal to specify =
a concrete API, as such an effort is dependent on outside factors such =
as programming language or software architecture. I agree with this =
notion, but a programming-language dependent API is not what we=E2=80=99ve=
 asked for. I=E2=80=99ve tried to supply a sketch of what I did ask for =
in [1], but unfortunately I didn=E2=80=99t get an answer (and as far as =
I can see it, the draft wasn=E2=80=99t changed either). I still think =
that such a list, in whatever form, would be very helpful for future =
Internet-Draft authors and I also think this request is in accordance =
with the intentions stated in 1.1 =
History and Purpose, and I think it should be included in =
the document.

No. There are many reasons why we're just not touching =
this one.

One =
is that language independence is a mirage. How you go about things is =
completely different in, for example an object oriented language than =
one that isn't. Section 4.5 shows that there are quite different ways of =
doing things even given a decision to use a map approach, and there are =
other approaches than that. It would be wrong and beyond our competence =
to suggest one of these as "best". There's reasons the IETF doesn't do =
this, and that's one.

What does this have to do with object orientation? =
I=E2=80=99m not asking for the draft to contain a recommendation on how =
to implement  RFC 5444 message building/parsing =
code.

Kind =
regards,
Lotte


Plus, =
frankly, the work it would take is beyond what we choose to =
spend.

* As the exact rules for =
using/setting the hop count & hop-limit fields are currently being =
discussed w/ regard to AODVv2 in another thread [2]=E2=80=93 should a =
definitive answer to that question be part of =
5444-usage?

You don't want that. Because if we did specify that =
you'd find yourself more constrained than you want to be. There is a =
design intent described in 5444, but it assumes immutable messages. =
Which you don't want. Really, we're doing you a favour by not imposing =
on you.

Best regards,
Lotte

[1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.ht=
ml
[2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.ht=
ml 


Am 06.04.2016 um 19:14 schrieb Justin Dean =
<bebemaster@gmail.com>:

The chairs agree that a 3 week WGLC is appropriate.  =
Everyone please read the draft early and get comments in early so that =
they can be addressed within the last call period.

Justin

On Wed, =
Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> =
wrote:
Obviously +1 to =
the request for WGLC.



With regard to what's changed, technically the only significant thing is =
to make it clear that if a protocol delivers a message to the =
multiplexer, the multiplexer must pass it on unchanged to the protocol =
(another instance of, at another router) unchanged. Without that nothing =
that the protocol itself chooses to do with regard to security makes =
sense. Though the protocol can alternatively let the multiplexer do the =
security, 7182 can be implemented in either way. This isn't really new, =
but it wasn't formally spelled out. It's presented as part of spelling =
out multiplexer rules more carefully.



But what about message optimisation? That's a function of constructing a =
5444 message, not the multiplexer, and is down to that 5444 includes two =
things - packet/message structure (and implicitly, and in pretty much =
any implementation I would expect to see, a parser and builder for that =
structure) and the multiplexer. So we took the opportunity to separate =
out more clearly a discussion of the two, which we think will be =
helpful.



--

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



-----Original Message-----

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg

Sent: 05 April 2016 20:08

To: manet@ietf.org

Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03



----------------------! WARNING ! ---------------------- This message =
originates from outside our organisation, either from an external =
partner or from the internet.

Consider carefully whether you should click on any links, open any =
attachments or reply.

Follow the 'Report Suspicious Emails' link on IT matters for =
instructions on reporting suspicious email messages.

--------------------------------------------------------



*** WARNING ***

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






Hi,



As you have seen, we have submitted a new revision of 5444-usage. The =
authors feel comfortable that we have addressed all issues by this =
version, and would like to ask the WG chairs to issue a WGLC on this =
document. While it is a fairly short document, given that it is IETF =
week for some, we'd suggest that a 3-4 week WGLC would be =
appropriate.



Best regards

Ulrich



_______________________________________________

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

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
<=
br class=3D"">=

--Apple-Mail=_4E81EA54-1C3B-4593-A5FB-56670FFCB2E5--


From nobody Mon Apr 25 01:00: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 1281B12D0ED for ; Mon, 25 Apr 2016 01:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.596
X-Spam-Level: 
X-Spam-Status: No, score=-3.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 muDEdjdd32LE for ; Mon, 25 Apr 2016 01:00:03 -0700 (PDT)
Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 965A812B069 for ; Mon, 25 Apr 2016 01:00:03 -0700 (PDT)
Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by outbox.sics.se (Postfix) with ESMTPS id 1AD0D17F2 for ; Mon, 25 Apr 2016 10:00:02 +0200 (CEST)
Received: from [193.10.66.141] (marco-desktop.sics.se [193.10.66.141]) by norm.sics.se (Postfix) with ESMTPSA id 0FB292A0 for ; Mon, 25 Apr 2016 10:00:02 +0200 (CEST)
Message-ID: <571DCE81.8070101@sics.se>
Date: Mon, 25 Apr 2016 10:00:01 +0200
From: Marco Tiloca 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: manet@ietf.org
Content-Type: multipart/alternative; boundary="------------030202000900070906050307"
Archived-At: 
Subject: [manet] IEEE SMARTCOMP 2016 - Call for Participation
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, 25 Apr 2016 08:00:06 -0000

This is a multi-part message in MIME format.
--------------030202000900070906050307
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

** Our sincere apologies if you receive multiple copies of this call for
participation **

=========================================================================
CALL FOR PARTICIPATION
=========================================================================
IEEE SMARTCOMP 2016
2nd IEEE International Conference on Smart Computing
http://smart-comp.org
St. Louis, Missouri, United States
May 18 - 20, 2016

Sponsored by: IEEE Computer Society, National Science Foundation,
Missouri University of Science and Technology, IEEE St. Louis Section

======================================================================
Registration:  http://www.smart-comp.org/registration.html
======================================================================

======================================================================
Main Features:
======================================================================
*** Two keynote speeches - see
http://www.smart-comp.org/keynote-speakers.html
*** 24 Full Papers and 6 Concise Contributions
*** Panel on Smart Communities: Challenges and Opportunities
*** Best Papers Session
*** Work-in-Progress Session
*** Demonstration/Poster Session
*** PhD Forum
*** Two Cutting-edge Workshops - see
http://www.smart-comp.org/list-of-workshops.html
*** NSF Special Session on Funding Opportunities in Smart Service Systems"
     - see
http://www.smart-comp.org/nsf-session-on-smart-service-systems.html

=====================================================================
Preliminary Program Outline
=====================================================================
May 18: Workshops and NSF Special Session
May 19-20: Main Conference

May 19-20: Keynotes
May 19: Demo and WiP sessions, PhD Forum
May 19: Social Dinner
May 19: Panel
May 20: Best Papers Session

=====================================================================
Keynote Speakers
=====================================================================
Prof. Raj Rajkumar (Carnegie Mellon University)
Self-Driving Vehicles: The Road Ahead

=====================================================================
Panel Discussions
=====================================================================
Panel topic:  Smart Communities: Challenges and Opportunities
Panel Moderator:
    Klara Nahrstedt, University of Illinois at Urbana Champaign
Panelists:
    Glen Ricart, Founder and CTO of US Ignite
    Gurdip Singh, Program Director in Cyber-Physical Systems, NSF
    Prem Kumar, IOT Engineering Lead, Google Fiber
    Alex Rojas, Director of Distributed Technologies, Ameren Services
Company
    Pradeep Natarajan, Engineering Manager, IBM Informix IoT Solutions

=====================================================================
Technical Program
=====================================================================
 http://www.smart-comp.org/conference-program.html

May 19:
Keynote 1
Session 1A: Smart Mobility
Session 1B: Smart Healthcare
Session 2A: on Smart  Systems
Session 2B: Smart Data Analytics
Poster Session and PhD Forum

May 20:
Keynote 2
Session 3: Best Paper Candidates
Session 4A: Smart Cities
Session 4B: Smart Sensing
Session 5A: Smart Social Interactions

=====================================================================
Workshops - See http://www.smart-comp.org/list-of-workshops.html
=====================================================================
First International Workshop on Smart Service Systems (SmartSys)
http://mpsc.umbc.edu/smartsys/

Second International Workshop on Sensors and Smart Cities (SSC)
http://ssc2016.unime.it

=======================================================================


--------------030202000900070906050307
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    

      
** Our sincere apologies if you receive multiple copies of this call for
participation **

=========================================================================
CALL FOR PARTICIPATION
=========================================================================
IEEE SMARTCOMP 2016
2nd IEEE International Conference on Smart Computing
http://smart-comp.org
St. Louis, Missouri, United States
May 18 - 20, 2016

Sponsored by: IEEE Computer Society, National Science Foundation,
Missouri University of Science and Technology, IEEE St. Louis Section

======================================================================
Registration:  http://www.smart-comp.org/registration.html
======================================================================

======================================================================
Main Features:
======================================================================
*** Two keynote speeches - see
http://www.smart-comp.org/keynote-speakers.html
*** 24 Full Papers and 6 Concise Contributions
*** Panel on Smart Communities: Challenges and Opportunities
*** Best Papers Session
*** Work-in-Progress Session
*** Demonstration/Poster Session
*** PhD Forum
*** Two Cutting-edge Workshops - see
http://www.smart-comp.org/list-of-workshops.html
*** NSF Special Session on Funding Opportunities in Smart Service Systems"
     - see
http://www.smart-comp.org/nsf-session-on-smart-service-systems.html

=====================================================================
Preliminary Program Outline
=====================================================================
May 18: Workshops and NSF Special Session
May 19-20: Main Conference

May 19-20: Keynotes
May 19: Demo and WiP sessions, PhD Forum
May 19: Social Dinner
May 19: Panel
May 20: Best Papers Session

=====================================================================
Keynote Speakers
=====================================================================
Prof. Raj Rajkumar (Carnegie Mellon University)
Self-Driving Vehicles: The Road Ahead

=====================================================================
Panel Discussions
=====================================================================
Panel topic:  Smart Communities: Challenges and Opportunities
Panel Moderator:
    Klara Nahrstedt, University of Illinois at Urbana Champaign
Panelists:
    Glen Ricart, Founder and CTO of US Ignite
    Gurdip Singh, Program Director in Cyber-Physical Systems, NSF
    Prem Kumar, IOT Engineering Lead, Google Fiber
    Alex Rojas, Director of Distributed Technologies, Ameren Services
Company
    Pradeep Natarajan, Engineering Manager, IBM Informix IoT Solutions

=====================================================================
Technical Program
=====================================================================
 http://www.smart-comp.org/conference-program.html

May 19:
Keynote 1
Session 1A: Smart Mobility
Session 1B: Smart Healthcare
Session 2A: on Smart  Systems
Session 2B: Smart Data Analytics
Poster Session and PhD Forum

May 20:
Keynote 2
Session 3: Best Paper Candidates
Session 4A: Smart Cities
Session 4B: Smart Sensing
Session 5A: Smart Social Interactions

=====================================================================
Workshops - See http://www.smart-comp.org/list-of-workshops.html
=====================================================================
First International Workshop on Smart Service Systems (SmartSys)
http://mpsc.umbc.edu/smartsys/

Second International Workshop on Sensors and Smart Cities (SSC)
http://ssc2016.unime.it

=======================================================================



    

  


--------------030202000900070906050307--


From nobody Mon Apr 25 02:21:32 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 0F8B312D56D for ; Mon, 25 Apr 2016 02:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.82
X-Spam-Level: 
X-Spam-Status: No, score=-4.82 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, TRACKER_ID=1.306] 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 CM5OtzwpOrlV for ; Mon, 25 Apr 2016 02:21:26 -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 6B55D12D56C for ; Mon, 25 Apr 2016 02:21:25 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,532,1454976000"; d="scan'208,217"; a="34146541"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 25 Apr 2016 10:21:22 +0100
X-IronPort-AV: E=Sophos;i="5.24,532,1454976000";  d="scan'208,217";a="115304106"
Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 25 Apr 2016 10:20:31 +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; Mon, 25 Apr 2016 10:20:30 +0100
From: "Dearlove, Christopher (UK)" 
To: Victoria Mercieca , Christopher Dearlove 
Thread-Topic: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
Thread-Index: AQHRgGzYnQ0jbgFSiUepI05etGsIBJ9d2vAQgAAD6gCAAAGt4IAAAs+AgDjn+gCAAAvpAIAAo5QAgAMoSiA=
Date: Mon, 25 Apr 2016 09:20:30 +0000
Message-ID: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>   
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B12C9GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 09:21:31 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B12C9GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

V2l0aCByZWdhcmQgdG8geW91ciB2YWxpZGl0eSB0aW1lIHBvaW50LCB3ZSBoZXJlIGhhdmUgYSB0
cmFkZW9mZi4gSWYgeW91IGFsbG93IHRoYXQgZmVhdHVyZSwgaXQgc2lnbmlmaWNhbnRseSBpbXBh
Y3RzIG9uIHRoZSBhcHByb2FjaCB0aGF0IHdhcyBjb21pbmcgdG9nZXRoZXIgb24gYXMgYmVzdCB5
b3UgY2FuIGVuZCB0byBlbmQgZW5jcnlwdGlvbi4NCg0KU28gdGhlIHF1ZXN0aW9uIGlzLCBpcyB0
aGlzIGEgZmVhdHVyZSB0aGF04oCZcyByZWFsbHkgd2FudGVkPyBVbmZvcnR1bmF0ZWx5IEkgdGhp
bmsgd2Uga25vdyB0aGF0IHRoZSBhbnN3ZXIgdG8gdGhhdCBpcywgd2UgZG9u4oCZdCBrbm93IGJl
Y2F1c2Ugd2UgZG9u4oCZdCBoYXZlIGFueSBleHBlcmllbmNlLiBNeSB2aWV3IHdvdWxkIGJlIHRo
YXQgaW4gdGhlIHRyYWRlb2ZmIG9mIGFuIHVudGVzdGVkIGZlYXR1cmUgKHVubGVzcyBJ4oCZbSB3
cm9uZyBhYm91dCB0aGF0KSBhbmQgdGhlIHNlY3VyaXR5IGNvbXBsaWNhdGlvbiwgc2VjdXJpdHkg
d2lucyBhbmQgZHJvcCB0aGUgZmVhdHVyZS4gSWYgdGhlcmUgaXMgc29tZSByZWFsIHJlcXVpcmVt
ZW50LCB0aGVuIHRoZXJl4oCZcyBhIGRpc2N1c3Npb24uIChRdWVzdGlvbnMgbGlrZSBob3cgb2Z0
ZW4gdGhlIGludGVybWVkaWF0ZSByb3V0ZXJzIGFjdHVhbGx5IGhhdmUgYW55IGtub3dsZWRnZSAt
IHR5cGljYWxseSBsaW5rcyBicmVhayBmb3IgdW5leHBlY3RlZCByYXRoZXIgdGhhbiBleHBlY3Rl
ZCByZWFzb25zLiBBbmRhbiBpbnRlcm1lZGlhdGUgcm91dGVyIGNvdWxkIHBvc3NpYmx5IHVzZSBh
IHZhbGlkaXR5IHRpbWUgdG8gaW5mbHVlbmNlIGl0cyBiZWhhdmlvdXIuKSBOb3RlIHRoYXQgZHJv
cHBpbmcgdGhlIGFiaWxpdHkgb2YgaW50ZXJtZWRpYXRlIHJvdXRlcnMgdG8gbW9kaWZ5L3NldCBz
dGlsbCBhbGxvd3MgdmFsaWRpdHkgdGltZXMgcGVyIHJvdXRlIHRvIGJlIHNldCBhdCBlbmRwb2lu
dHMuDQoNCldpdGggcmVnYXJkIHRvIHRoZSBhY2tub3dsZWRnZW1lbnRzLCB0aGUgcHJvYmxlbSAo
d2l0aCByZWdhcmQgdG8gc2VjdXJpdHkpIGNvbWVzIGZyb20gdHJ5aW5nIHRvIGRvIHR3byBqb2Jz
IHdpdGggdGhlIHNhbWUgbWVzc2FnZSAtIGVuZCB0byBlbmQgcm91dGUgYWR2ZXJ0aXNlbWVudCBh
bmQgaG9wIGJ5IGhvcCBhY2tub3dsZWRnZW1lbnQuIEkgdW5kZXJzdGFuZCB0aGUgcmVhc29ucyAt
IHNhdmluZyBieXRlcyBhbmQgbWVzc2FnZSB0eXBlcy4gKEkgd291bGQgaGF2ZSB0byBzdHVkeSB0
aGUgcHJvdG9jb2wgcmVhbGx5IGhhcmQgdG8gaWRlbnRpZnkgaWYgYW55IG1lc3NhZ2UgdHlwZXMg
Y2FuIGJlIGZvbGRlZCB0b2dldGhlciBhbmQgcmVjb2duaXNlZCBieSBjb250ZW50IHJhdGhlciB0
aGFuIHR5cGUgZWZmaWNpZW50bHkuIFRoaXMgSSBkbyBub3QgZXhwZWN0IHRvIGRvLikgQWdhaW4g
YSB0cmFkZW9mZi4gVGhpcyBvbmUgaXMgaW4gZGlzY3Vzc2lvbiBzcGFjZSwgdGhvdWdoIHRoYXQg
bmVlZHMgcGVvcGxlIHdobyB1bmRlcnN0YW5kIGJvdGggc2lkZXMgb2YgdGhlIGlzc3VlLCBpbmNs
dWRpbmcgdGhlIGRldGFpbHMgb2YgdGhlIGJpZGlyZWN0aW9uYWxpdHkgbWVjaGFuaXNtLiBPZiBj
b3Vyc2UsIGFzIGhhcyBiZWVuIHNhaWQsIHdlIG5lZWQgb25lIG9mIHRob3NlLg0KDQotLQ0KQ2hy
aXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1z
IEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K
VDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j
b208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBB
cHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJh
ZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxo
dHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxp
Z2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUx
DQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3Vy
cmV5LCBHVTIgN1lQDQoNCkZyb206IFZpY3RvcmlhIE1lcmNpZWNhIFttYWlsdG86dm1lcmNpZWNh
MEBnbWFpbC5jb21dDQpTZW50OiAyMyBBcHJpbCAyMDE2IDEwOjU1DQpUbzogQ2hyaXN0b3BoZXIg
RGVhcmxvdmUNCkNjOiBpZXRmQHRob21hc2NsYXVzZW4ub3JnOyBEZWFybG92ZSwgQ2hyaXN0b3Bo
ZXIgKFVLKTsgTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3QNClN1YmplY3Q6IFJl
OiBbbWFuZXRdIE1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBtZXNzYWdlIG11dGFiaWxpdHkgKHdhcyBS
RTogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRp
Y2tldCBJdGVtcykNCg0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVz
IGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBw
YXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBz
aG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4N
CkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91
dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5l
bnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRz
L1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywg
cGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1z
LmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdp
dGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQpIaSBDaHJpcywNCg0KVGhlc2UgaGF2ZSBi
b3RoIGJlZW4gaW4gdGhlIGRyYWZ0IGluIHNvbWUgZm9ybSBzaW5jZSBiZWZvcmUgSSBnb3QgaW52
b2x2ZWQuLi4gYnV0IEknbGwgZG8gbXkgYmVzdCB0byBleHBsYWluLg0KDQotIEZvciBWYWxpZGl0
eSBUaW1lLCBpdHMgYSB3YXkgdG8gYWR2ZXJ0aXNlIHRoYXQgeW91IHdvdWxkIG9ubHkgc3VwcG9y
dCB0aGUgcm91dGUgY29udGFpbmVkIGluIHRoZSBtZXNzYWdlIGZvciBhIGNlcnRhaW4gcGVyaW9k
IG9mIHRpbWUuIFRoZSBvcmlnaW5hdG9yIG1pZ2h0IHVzZSB0aGlzLCBidXQgdGhlIGRyYWZ0IHdh
cyB3cml0dGVuIHRvIGFsbG93IGFueSBpbnRlcm1lZGlhdGUgbm9kZSB0byBiZSBhYmxlIHRvIGFk
ZCBpdCBvciB1cGRhdGUgaXQgdG9vLiBUaGUgcm91dGUgY3JlYXRlZCBpbiB0aGUgTG9jYWwgUm91
dGUgU2V0IGhhcyBhbiBleHBpcmF0aW9uIHRpbWUgYXNzb2NpYXRlZCB3aXRoIGl0LCBiYXNlZCBv
biB0aGUgcmVjZWl2ZWQgdmFsaWRpdHkgdGltZS4NCi0gRm9yIHRoZSBBY2tSZXEgYWRkcmVzcywg
aXRzIHNvIHRoYXQgeW91IGNhbiBhZGQgaW50byBhIFJSRVAgYSByZXF1ZXN0IGZvciBhbiBhY2tu
b3dsZWRnZW1lbnQsIHNvIHRoYXQgeW91IGRvbid0IGhhdmUgdG8gaGF2ZSBhIGRpZmZlcmVudCBt
ZXNzYWdlIHR5cGUgYWx0b2dldGhlciBmb3Igd29ya2luZyBvdXQgd2hldGhlciBsaW5rcyB0byBu
ZWlnaGJvcnMgYXJlIGJpZGlyZWN0aW9uYWwsIGFuZCBhbHNvLCBzaW5jZSB5b3Ugb25seSBjYXJl
IGFib3V0IGJpZGlyZWN0aW9uYWxpdHkgb24gcm91dGVzIHRoYXQgYXJlIGJlaW5nIHNldCB1cCwg
eW91IGRvbnQgbmVlZCB0byBjb25zdGFudGx5IG1vbml0b3IgYWxsIG5laWdoYm9ycy4NCg0KDQpJ
biBvcmRlciB0byBhdm9pZCB0aGUgcG90ZW50aWFsIEFja1JlcS1yZWxhdGVkIGNoYW5nZXMgdG8g
ZWFjaCBtZXNzYWdlLCBtYXliZSB3ZSBkbyBuZWVkIHRvIGludHJvZHVjZSBhIGRpZmZlcmVudCBt
ZXNzYWdlIHNwZWNpZmljYWxseSBmb3IgdGhpcy4gV2UgY291bGQgbWF5YmUgdXNlIFJSRVBfQWNr
IHRvIGJvdGggcmVxdWVzdCBhbmQgYWNrbm93bGVkZ2U/IEl0IG1lYW5zIGFuIGV4dHJhIG1lc3Nh
Z2Ugb2YgY29udHJvbCB0cmFmZmljIHRoYXQgbmVlZHMgdG8gYmUgc2VudCwgbWF5YmUgb25lIGV4
dHJhIG1lc3NhZ2UgcGVyIGhvcCBvbiB0aGUgcGF0aCBvZiBhIFJSRVAsIGJ1dCBpdCBjb3VsZCBz
dGlsbCBiZSBsaW1pdGVkIHRvIG5laWdoYm9ycyB3aGljaCBoYXZlIHBhcnRpY2lwYXRlZCBpbiB0
aGUgcm91dGUgZGlzY292ZXJ5IHJhdGhlciB0aGFuIG1vbml0b3JpbmcgYWxsIG5laWdoYm9ycyBh
dCBhbGwgdGltZXMuDQoNClRoaXMgbWVzc2FnZSBjb3VsZCBtYXliZSBhbHNvIGluY2x1ZGUgIkkn
bSBoYXBweSB0byByb3V0ZSBhbnl3aGVyZSBmb3IgYSBjZXJ0YWluIGFtb3VudCBvZiB0aW1lIiwg
c29ydCBvZiBsaWtlIHdpbGxpbmduZXNzIGluIE9MU1IvT0xTUnYyLiBTbyBpbnN0ZWFkIG9mIGhh
dmluZyBhIHZhbGlkaXR5IHRpbWUgcGVyIHJvdXRlLCBpdHMgYSB2YWxpZGl0eSB0aW1lIHBlciBu
ZWlnaGJvci4gVGhlbiwgZm9yIFJSRVEgYW5kIFJSRVAsIG9ubHkgdGhlIG1ldHJpYyB2YWx1ZSB3
b3VsZCBjaGFuZ2UgaW4gdHJhbnNpdCwgYXMgZGlzY3Vzc2VkLiBIb3dldmVyLCB0aGF0IGxlYWRz
IHRvIHNvbWUgaXNzdWVzIHdpdGggZGVjaWRpbmcgd2hhdCBhIHJvdXRlJ3MgZXhwaXJhdGlvbiB0
aW1lIGlzLiBZb3UgbWlnaHQga25vdyBob3cgbG9uZyB0aGUgbmV4dCBob3Agcm91dGVyIGlzIHZh
bGlkIGZvciwgYnV0IHdoYXQgaWYgYSByb3V0ZXIgYmV5b25kIHRoYXQsIHdoaWNoIHdhcyBhbHNv
IHBhcnQgb2YgdGhlIHJvdXRlLCBoYWQgYSBsb3dlciB2YWxpZGl0eSB0aW1lPyBZb3UgY291bGRu
J3QgZGV0ZXJtaW5lIHRoZSByZWFsIHZhbGlkaXR5IHRpbWUuIERvIHdlIHJlbW92ZSB0aGUgcm91
dGUgZXhwaXJhdGlvbiB0aW1lIGFsdG9nZXRoZXIgdG8gYXZvaWQgdGhpcyBpc3N1ZT8gSW4gd2hp
Y2ggY2FzZSwgd2Ugd291bGQgaGF2ZSB0byByZWx5IG9uIFJFUlIgbWVzc2FnZXMgYmVpbmcgc2Vu
dCBmb3Igcm91dGVzIHdoaWNoIGJlY29tZSBpbnZhbGlkIHdoZW4gdGhlIG5laWdoYm9yJ3MgdmFs
aWRpdHkgdGltZSBoYXMgZXhwaXJlZD8gU28gbmVpZ2hib3IgdmFsaWRpdHkgdGltZSBleHBpcmF0
aW9uIGlzIHRyZWF0ZWQgdGhlIHNhbWUgYXMgYSBsaW5rIGJyZWFrLg0KDQpXaGF0IGRvIHlvdSB0
aGluaz8NCg0KS2luZCByZWdhcmRzLA0KVmljdG9yaWEuDQoNCg0KDQoNCg0KDQpPbiBTYXQsIEFw
ciAyMywgMjAxNiBhdCAxOjA5IEFNLCBDaHJpc3RvcGhlciBEZWFybG92ZSA8Y2hyaXNAbW5lbW9z
eW5lLmRlbW9uLmNvLnVrPG1haWx0bzpjaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWs+PiB3cm90
ZToNClByZXR0eSBtdWNoIGFsbCBvZiB0aGUgZGlzY3Vzc2lvbiBoYXMgYmVlbiBhc3N1bWluZyBv
bmx5IGEgbWV0cmljIHZhbHVlIGNoYW5nZS4gV2l0aCBtdWx0aXBsZSB0aGluZ3MgY2hhbmdpbmcg
bWFueSBvZiB0aGUgaWRlYXMgZ28gb3V0IG9mIHRoZSB3aW5kb3cuIFRoYXQgcmVpbmZvcmNlcyB0
aGUgcG9pbnQgYWJvdXQgbm90IG1ha2luZyBzcGVjaWZpY2F0aW9ucyBub3cgdGhhdCBtaWdodCB0
dXJuIG91dCB0byBiZSB3cm9uZyBmb3IgSUNWcy4NCg0KSWdub3JpbmcgaG93IHRoaXMgbWlzdW5k
ZXJzdGFuZGluZyBoYXBwZW5lZCwgSSdsbCBzdGFydCBieSBhc2tpbmcgd2h5LiBNZXRyaWMgY2hh
bmdpbmcgSSB1bmRlcnN0YW5kLiBXaHkgdGhlIG90aGVyIHR3bz8gKHRoZXJlJ3MgYSBwYXJ0aWFs
IGV4cGxhbmF0aW9uIG9mIG9uZSkuIFdoYXQgYWx0ZXJuYXRpdmVzIGhhdmUgcGVvcGxlIGltcGxl
bWVudGVkIGluIGNvbXBhcmFibGUgcHJvdG9jb2xzPw0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxv
dmUNCmNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNvbTxtYWlsdG86Y2hyaXN0b3BoZXIuZGVh
cmxvdmVAZ21haWwuY29tPiAoaVBob25lKQ0KY2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrPG1h
aWx0bzpjaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWs+IChob21lKQ0KDQpPbiAyMyBBcHIgMjAx
NiwgYXQgMDA6MjYsIFZpY3RvcmlhIE1lcmNpZWNhIDx2bWVyY2llY2EwQGdtYWlsLmNvbTxtYWls
dG86dm1lcmNpZWNhMEBnbWFpbC5jb20+PiB3cm90ZToNCkhpIGFsbCwNCg0KQ29udGludWVkIGlu
IHRoaXMgdGhyZWFkIGJlY2F1c2UgdGhlIG90aGVyIG9uZSBzZWVtcyB0byBiZSBtb3JlIGFib3V0
IFRMViB0eXBlcyBhbmQgbWV0cmljIHR5cGUgbnVtYmVycywgd2hlcmVhcyB0aGlzIGlzIGFib3V0
IHJlZ2VuZXJhdGlvbi9mb3J3YXJkaW5nLg0KDQpUbyByZWNhcCwgaW4gdGhlIGN1cnJlbnQgZHJh
ZnQsIHRoZXJlIGFyZSAzIHRoaW5ncyB0aGF0IG1pZ2h0IGNoYW5nZSBhdCBlYWNoIGhvcDoNCi0g
dGhlIG1ldHJpYyB2YWx1ZSAoaGFwcGVucyBpbiBSUkVRIGFuZCBSUkVQKSwNCi0gYWRkaW5nL2No
YW5naW5nIFZhbGlkaXR5IFRpbWUgdXNpbmcgdGhlIFZhbGlkaXR5IFRpbWUgVExWIChjYW4gaGFw
cGVuIGluIFJSRVEgYW5kIFJSRVApLA0KLSBhZGRpbmcgYW4gYWRkcmVzcyAoYW5kIGNvcnJlc3Bv
bmRpbmcgdmFsdWUgaW4gdGhlIEFkZHJlc3NUeXBlIFRMViB0byBpbmRpY2F0ZSBob3cgdG8gaW50
ZXJwcmV0IHRoZSBhZGRyZXNzKSB0byBpbmRpY2F0ZSB0aGUgYWRkcmVzcyBmcm9tIHdoaWNoIGFu
IFJSRVBfQWNrIGlzIGV4cGVjdGVkLCB0byBhY2NvbXBsaXNoIHRoZSBiaWRpcmVjdGlvbmFsaXR5
IGNoZWNrIChjYW4gaGFwcGVuIGluIFJSRVApLg0KDQpJZiB3ZSBkZWZpbmUgYSBjZXJ0YWluIHBv
cnRpb24gb2YgdGhlIG1lc3NhZ2UgYXMgaW1tdXRhYmxlIGFuZCBpbmNsdWRlIHRoZSBJQ1YgdG8g
dmVyaWZ5IHRoYXQgcGFydCwgZW5kIHRvIGVuZDoNCi0gVGhlIG1ldHJpYyB2YWx1ZSB3b3VsZCBi
ZSBleGNsdWRlZCBmcm9tIHRoZSBJQ1Ygc2luY2UgaXQgbmVlZHMgY2hhbmdpbmcgYXQgZWFjaCBo
b3AuDQotIFdvdWxkIGFkZGluZyBhIFZhbGlkaXR5IFRpbWUgVExWIGF0IGFuIGludGVybWVkaWF0
ZSBob3AgYmUgYWNjZXB0YWJsZT8gVGhlIHdob2xlIFRMViBjb3VsZCBiZSByZW1vdmVkIGluIG9y
ZGVyIHRvIGNhbGN1bGF0ZSB0aGUgSUNWPw0KLSBXb3VsZCBhZGRpbmcgYW4gYWRkcmVzcyBjYXVz
ZSBpc3N1ZXMgZm9yIHRoZSBJQ1YsIGJlY2F1c2UgaXQncyBpbiB0aGUgYWRkcmVzcyBibG9jaz8g
Q291bGQgdGhlIHJ1bGUgYmUgImlmIGl0IGNvbnRhaW5zIGFuIEFja1JlcSBhZGRyZXNzLCByZW1v
dmUgaXQgKGFuZCB0aGUgY29ycmVzcG9uZGluZyB2YWx1ZSBpbiB0aGUgQWRkcmVzc1R5cGUgVExW
KSwgYmVmb3JlIGNoZWNraW5nIHRoZSBJQ1YiLCBpcyB0aGF0IE9LPyBPciB3b3VsZCB3ZSBuZWVk
IHRvIGF2b2lkIHRvdWNoaW5nIHRoZSBJQ1YnZWQgcGFydCBvZiB0aGUgbWVzc2FnZSBhbHRvZ2V0
aGVyLCBtYXliZSBwdXQgdGhlIEFja1JlcSBhZGRyZXNzIGluIGEgc2VwYXJhdGUgQWRkcmVzcyBC
bG9jaywgd2l0aCBhbiBleHRyYSBBZGRyZXNzVHlwZSBUTFYgZm9sbG93aW5nIHRoYXQgYWRkcmVz
cyBibG9jaz8gSXMgdGhlcmUgYSB3YXkgdG8gYWNjb21wbGlzaCB0aGlzPw0KDQpBbHNvLCB0byBi
ZSB0aG9yb3VnaCwgZG8gd2UgbmVlZCB0byBjb25zaWRlciBSRVJSIG1lc3NhZ2VzIHdoaWxlIHdl
IGRpc2N1c3MgcmVnZW5lcmF0aW9uIHZzIGZvcndhcmRpbmc/DQotIFJFUlIgKHNlbnQgd2hlbiBh
IGxpbmsgYnJlYWtzKSBpcyBhIHdheSBvZiBzYXlpbmcgIkkndmUgbG9zdCBteSByb3V0ZSBzbyBJ
J20gdGVsbGluZyBvdGhlcnMiIGFuZCAieW91IHdlcmUgbXkgbmV4dCBob3AsIHNvIG5vdyBJJ3Zl
IGFsc28gbG9zdCBteSByb3V0ZSwgSSdsbCB0ZWxsIG90aGVycyIsIGV0Yy4gSXQncyBnb2luZyB0
byBiZSB0YWlsb3JlZCBhdCBlYWNoIHN0ZXAgdG8gaW5jbHVkZSB0aGUgcmVsZXZhbnQgcm91dGVz
IHRoYXQgZ290IGRlbGV0ZWQsIGl0J3Mgbm90IG9uZSBtZXNzYWdlIGJlaW5nIHNlbnQgZW5kLXRv
LWVuZCBsaWtlIFJSRVEgYW5kIFJSRVAgYXJlLg0KLSBIb3dldmVyLCBSRVJSIChzZW50IHdoZW4g
YSBzb3VyY2Ugb2YgdHJhZmZpYyBpcyBzZW5kaW5nIGRhdGEgb24gYSByb3V0ZSB3aGljaCBjb21l
cyB0aHJvdWdoIHlvdSwgYW5kIHlvdSB3YW50IHRvIHRlbGwgdGhlIFBhY2tldCBTb3VyY2UncyBy
b3V0ZXIgdG8gZGVsZXRlIHRoZSByb3V0ZSkgY291bGQgYmUgc2VlbiBhcyBhbiBlbmQtdG8tZW5k
IG1lc3NhZ2Ugd2hpY2ggYWxsIGludGVybWVkaWF0ZSByb3V0ZXJzIGxlYXJuIGZyb20sIHNpbWls
YXIgdG8gUlJFUSBhbmQgUlJFUC4gSXQgcmVwb3J0cyBvbmUgcm91dGUsIGFuZCBkb2Vzbid0IG5l
ZWQgY2hhbmdpbmcgYXQgaW50ZXJtZWRpYXRlIGhvcHMsIHNvIGNvdWxkIGJlIHByb3RlY3RlZCB3
aXRoIElDVi4NCi0gV291bGQgaXQgYmUgT0sgdG8gb25seSByZXF1aXJlIGEgbWVzc2FnZSBJQ1Yg
aWYgYSBQa3RTb3VyY2UgYWRkcmVzcyB3YXMgaW5jbHVkZWQsIGkuZS4gd2hlbiB0aGUgbWVzc2Fn
ZSBuZWVkcyB0byBnbyB2aWEgYSBudW1iZXIgb2YgaW50ZXJtZWRpYXRlIGhvcHMgdG8gUGt0U291
cmNlJ3Mgcm91dGVyPyBBbGwgb3RoZXIgUkVSUnMgYXJlIGludGVuZGVkIHRvIGJlIG9uZS1ob3Ag
bWVzc2FnZXMsIHdoaWNoIG1heSBpbiB0dXJuIHByb21wdCBvdGhlciBvbmUtaG9wIG1lc3NhZ2Vz
LCBldGMuLi4sIGFuZCBhIHBhY2tldCBJQ1YgbWlnaHQgYmUgbW9yZSBhcHByb3ByaWF0ZT8NCg0K
S2luZCByZWdhcmRzLA0KVmljdG9yaWEuDQoNCk9uIFRodSwgTWFyIDE3LCAyMDE2IGF0IDU6MjYg
UE0sIDxpZXRmQHRob21hc2NsYXVzZW4ub3JnPG1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3Jn
Pj4gd3JvdGU6DQoNCk9uIDE3IE1hciAyMDE2LCBhdCAxODoxNywgRGVhcmxvdmUsIENocmlzdG9w
aGVyIChVSykgPGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFy
bG92ZUBiYWVzeXN0ZW1zLmNvbT4+IHdyb3RlOg0KDQpZZXMsIEkgbWVhbnQgQU9EVnYyLCB0aGFu
a3MgZm9yIHRoZSBjYXRjaC4NCg0KU28gaXMgeW91ciAoVGhvbWFzKSBwcm9wb3NlZCBiYXNlIHNw
ZWNpZmljYXRpb24gYSBob3AgY291bnQgb25seSBtZXRyaWM/DQoNCk5vLCB0aGUgd291bGQgYmUg
c2lsbHkgYXMgYmFzZSBzcGVjaWZpY2F0aW9uLCBnaXZlbiB0aGF0IGhvcCBjb3VudCBtb3N0bHkg
aXMgdXNlbGVzcy4NCg0KQXMgYmFzZSBzcGVjaWZpY2F0aW9uIEkgd291bGQgc2ltcGx5IHNheSDi
gJxJbmNsdWRlIGEgTWV0cmljIFR5cGUgTWVzc2FnZSBUTFYgd2l0aCBhIHZhbHVlIGZpZWxkLCBh
bmQgYSA3MTgyIE1lc3NhZ2UgVExWICYgVGltZXN0YW1w4oCdIGFzIHdlIGRvIGluIE9MU1J2MiAo
d2l0aCB0aGUgYXBwcm9wcmlhdGUgdmVyYmlhZ2UgYXMgdG8gZ2VuZXJhdGlvbiBhbmQgcHJvY2Vz
c2luZykuDQoNCldpdGggdGhlIG1lc3NhZ2UgZ2VuZXJhdGVkIGJ5IHRoZSBvcmlnaW5hdG9yIG9m
IHRoZSBSUkVRL1JSRVAgYW5kICpub3QqIGRlY29uc3RydWN0ZWQvcmVjb25zdHJ1Y3RlZC9yZW9y
ZGVyZWQgKGFzIGlzIHRoZSByaXNrIHdpdGgg4oCccmVnZW5lcmF0aW9uKSBhbGxvd3Mga25vd2lu
ZyB0aGF0IGl0IHdvdWxkIGJlICpvbmx5KiB0aGF0IG1ldHJpYyBmaWVsZCBiZWluZyBtb2RpZmll
ZCAob3RoZXIgdGhhbiBob3AgY291bnQvbGltaXQpIGZvciB3aGVuIGV2ZW50dWFsbHkgd3JpdGlu
ZyB1cCB0aGUgZXh0ZW5zaW9uLg0KDQooQWN0dWFsbHkgZG9lc27igJl0IHRoZSBjdXJyZW50IHNw
ZWNpZmljYXRpb24gb25seSBkZWZpbmUgaG9wIGNvdW50LCBvciBoYXMgdGhhdCBjaGFuZ2VkIGlu
IGxhdGVzdCBkcmFmdD8pDQoNCk5vLiBUaGF0IGlzIG9uZSBvZiB0aGUgaXNzdWVzIEkgcmFpc2Ug
aW4gbXkgb3JpZ2luYWwuIEZvciBzb21lIHJlYXNvbiwgaXQgY2l0ZXMgUkZDNjU1MSwgd2hpY2gg
aXMgYSBST0xMIGRvY3VtZW50IGFuZCB3aGljaCBoYXMgaW4gaXRzIGFic3RyYWN0IHRoYXQ6DQoN
Cg0KICAgTG93LVBvd2VyIGFuZCBMb3NzeSBOZXR3b3JrcyAoTExOcykgaGF2ZSB1bmlxdWUgY2hh
cmFjdGVyaXN0aWNzDQoNCiAgIGNvbXBhcmVkIHdpdGggdHJhZGl0aW9uYWwgd2lyZWQgYW5kIGFk
IGhvYyBuZXR3b3JrcyB0aGF0IHJlcXVpcmUgdGhlDQoNCiAgIHNwZWNpZmljYXRpb24gb2YgbmV3
IHJvdXRpbmcgbWV0cmljcyBhbmQgY29uc3RyYWludHMuDQoNCkkuZS4gdGhpcyBkb2N1bWVudCBj
aXRlcyBhIG1ldHJpYyBkb2N1bWVudCB3aGljaCBjbGVhcmx5IGNsYWltcyB0byBiZSBpbmFwcGxp
Y2FibGUgaW4gYWQgaG9jIG5ldHdvcmtzLiBJIG5vdGUgdGhhdCB0aGlzIGlzIGFub3RoZXIgdGhp
bmcgSeKAmXZlIHJhaXNlZCBmb3IgeWVhcnMgd2l0aG91dCBzZWVpbmcgaXQgYXR0ZW1wdGVkIHJl
c29sdmVkLg0KDQpCZXN0LA0KDQpUaG9tYXMNCg0KDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92
ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxp
Z2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUg
MjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0PiAgfCAgRTogY2hyaXMuZGVh
cmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t
Pg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9s
b2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5i
YWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3Rl
bXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYg
V2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBh
cmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IGlldGZAdGhvbWFzY2xhdXNl
bi5vcmc8bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmc+IFttYWlsdG86aWV0ZkB0aG9tYXNj
bGF1c2VuLm9yZ10NClNlbnQ6IDE3IE1hcmNoIDIwMTYgMTc6MTANClRvOiBEZWFybG92ZSwgQ2hy
aXN0b3BoZXIgKFVLKQ0KQ2M6IExvdHRlIFN0ZWVuYnJpbms7IE1vYmlsZSBBZCBIb2MgTmV0d29y
a3MgbWFpbGluZyBsaXN0DQpTdWJqZWN0OiBSZTogW21hbmV0XSBNZXNzYWdlIGludGVncml0eSBh
bmQgbWVzc2FnZSBtdXRhYmlsaXR5ICh3YXMgUkU6IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEz
IHJldmlldyAtIGEgY291cGxlIG9mIGJpZyB0aWNrZXQgSXRlbXMpDQoNCg0KKioqIFdBUk5JTkcg
KioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlv
biwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25z
aWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3Bl
biBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJl
ZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwg
Y2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9z
ZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZl
ZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0
dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3Rs
aWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+
Lg0KDQpPbiAxNyBNYXIgMjAxNiwgYXQgMTg6MDQsIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp
IDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFl
c3lzdGVtcy5jb20+PiB3cm90ZToNCg0KT0ssIHNvIHdlIGhhdmUgYSBtZXNzYWdlIHRoYXQgbXV0
YXRlcyBieToNCi0gTW9kaWZ5aW5nIGhvcCBjb3VudC9saW1pdC4NCi0gTW9kaWZ5aW5nIGEgbWV0
cmljIHZhbHVlLg0KQW55dGhpbmcgZWxzZT8NCg0KQXMgbXV0YXRpbmcgKG90aGVyIHRoYW4gaG9w
IGNvdW50L2xpbWl0KSBtZXNzYWdlcyBhcmVu4oCZdCBjb3ZlcmVkIGJ5IDU0NDQgb3IgYW55IGRl
cml2YXRpdmUgZG9jdW1lbnQgKGJ1dCBvbmx5IHJlY29tbWVuZGVkIGFnYWluc3QsIG5vdCBiYW5u
ZWQpIHRoYXQgeW91IG1heSBuZWVkIHRvIG1ha2UgdGhlIG1lc3NhZ2Ugb3RoZXJ3aXNlIGltbXV0
YWJsZSAobm8gZGVjb25zdHJ1Y3Rpb24gYW5kIHJlYnVpbGRpbmcsIG90aGVyIHRoYW4gZ3VhcmFu
dGVlZCB1bmNoYW5naW5nKSB0aGF0IHdvdWxkIGhhdmUgdG8gYmUgc3BlY2lmaWVkIGJ5IEFPRFZ2
Mi4gKEVhc3kgdG8gc2F5LCBidXQgbmVlZHMgc2F5aW5nLikNCg0KV2l0aCB5b3Ugc28gZmFyLg0K
DQpUaGVuIHRoYXQgaW5mb3JtYXRpb24gaXMgbm90IGluIGEgZ3VhcmFudGVlZCBmaXhlZCBsb2Nh
dGlvbiBnaXZlbiBieSBhIHNpbXBsZSBvZmZzZXQuIFNvIGFueSBzaWduYXR1cmUgYWxnb3JpdGht
IHRoYXQgZmluZHMgaXQgYW5kIGlnbm9yZXMgaXQgb3IgYWdncmVnYXRlcyBvbiBpdCBpcyBzcGVj
aWZpYyB0byBPTFNSdjIuDQoNClN1cmVseSB5b3UgbWVhbiBBT0RWdjINCg0KU28gc3RhbmRhcmQg
NzE4MiBJQ1ZzIGRvbuKAmXQgZG8gdGhlIGpvYiwgeW91IHdvdWxkIG5lZWQgYW4gQU9EVnYyIHNw
ZWNpYWxpc2VkIHZhcmlhbnQuIFdoaWNoIGlzIHRoZSBzb3J0IG9mIHRoaW5nIHRoYXQgdGhlIG1l
c3NhZ2Ugc3BlY2lmaWMgVExWIHNwYWNlIGlzIHRoZXJlIGZvciwgSeKAmWQgYmUgc3Ryb25nbHkg
YWdhaW5zdCBhIOKAnGJ1dCBpZ25vcmUgdGhlIHZhbHVlIG9mIHRoaXMgc3BlY2lmaWMgVExWIHNo
b3VsZCBpdCBvY2N1cuKAnSBiZWluZyBpbiB0aGUgZ2VuZXJhbCBzcGFjZS4gSG93ZXZlciBpdCBj
YW4gZWFzaWx5IGJlIGRlZmluZWQgYnkgcmVmZXJlbmNlIHRvIDcxODIgKOKAnHRoaXMgVExWIGlz
IGxpa2UgdGhhdCBUTFYsIGV4Y2VwdCBpZiBhbiBYIFRMViBpcyBwcmVzZW50LCBzZXQgaXRzIHZh
bHVlIGZpZWxkIHRvIHplcm/igJ0pLg0KDQpNZXNzeSwgYnV0IGNvdWxkIHdvcmsuDQoNCk5vdCB0
aGF0IG1lc3N5LCBhY3R1YWxseSwgYWx0aG91Z2ggY2xlYXJseSBub3QgYXMgbmljZSBhcyDigJxm
aXhlZCBvZmZzZXTigJ0uDQoNClRoYXQgc2FpZCwgSSBhbSBhcmd1aW5nIGZvciB0aGUgYmFzZSBz
cGVjIGJlaW5nOg0KDQogICAgICAgICAgICDigJxtYWtlIHRoZSBtZXNzYWdlIG90aGVyd2lzZSBp
bW11dGFibGUgKG5vIGRlY29uc3RydWN0aW9uIGFuZCByZWJ1aWxkaW5nLCBvdGhlcg0KICAgICAg
ICAgICAgIHRoYW4gZ3VhcmFudGVlZCB1bmNoYW5naW5nKeKAnSB3aGljaCBpcyBhZmZvcmRlZCBi
eSBmb3J3YXJkaW5nDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsNCg0K
ICAgICAgICAgICAgUkZDNzE4MiBUaW1lc3RhbXBzIGFuZCBJQ1ZzLg0KDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICArDQoNCiAgICAgICAgICAgIFJGQzcxODMgc3R5bGUgdGV4
dCBicmluZ2luZyBpdCBhbGwgdG9nZXRoZXIuDQoNClRoZSDigJxhZ2dyZWdhdGVkIHNpZ25hdHVy
ZXMgYXJvdW5kIG11dGFibGUgZmllbGTigJ0gd291bGQgdmVyeSBiZSBhbiBleHBlcmltZW50YWwg
ZXh0ZW5zaW9uLg0KDQpXaGF0IEkgb2JqZWN0IHRvIGlzLCBpZiB0aGUgYmFzZSBzcGVjIHNwZWNp
ZmljYWxseSByZW5kZXJzIHN1Y2ggZXh0ZW5zaW9ucyBpbXBvc3NpYmxlDQoNCg0KDQotLQ0KQ2hy
aXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1z
IEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K
VDogICs0NCAoMCkxMjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4g
IHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92
ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENo
ZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4
IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNv
bS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVy
ZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1
cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBM
b3R0ZSBTdGVlbmJyaW5rIFttYWlsdG86bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4uZGVdDQpT
ZW50OiAxNyBNYXJjaCAyMDE2IDE2OjQ4DQpUbzogRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykN
CkNjOiBpZXRmQHRob21hc2NsYXVzZW4ub3JnPG1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3Jn
PjsgTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3QNClN1YmplY3Q6IFJlOiBbbWFu
ZXRdIE1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBtZXNzYWdlIG11dGFiaWxpdHkgKHdhcyBSRTogZHJh
ZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJ
dGVtcykNCg0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20g
b3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVy
IG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQg
Y2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBp
bmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3Ig
aW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFl
c3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUy
MEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNl
IGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9o
b3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBT
dXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQpIaSBhbGwsDQoNCkFtIDE3LjAzLjIwMTYgdW0gMTc6
NDQgc2NocmllYiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFl
c3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj46DQoNCkdv
b2QgcG9pbnQgYWJvdXQgd2hldGhlciB5b3UganVzdCBwYXNzIG9uIG9uZSBjb3N0IG9yIGEgc2V0
IG9mIGNvc3RzLiBBcyBJIHNhaWQsIG5vdCBsb29rZWQgYXQgZGV0YWlscyAtIEkgd2lsbCwgd2hl
biB0aW1lIHBlcm1pdHMuIE9uZSBjb3N0IGlzIG11Y2ggZWFzaWVyLCBhbmQgeWVzLCBpdCByZWR1
Y2VzIHRoZSBmaXhlZCBzaXplIGFnZ3JlZ2F0ZWQgc2lnbmF0dXJlcyBwcm9ibGVtIHRvIOKAnGp1
c3TigJ0gb25lIG9mIGNvbXB1dGF0aW9uYWwgbG9hZC4NCg0KRm9yIHRoZSByZWNvcmQsIFRob21h
c+KAmSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3Q7IHRoZSBjb3N0IGlzIG9uZSBhZ2dyZWdhdGVk
IHZhbHVlLg0KDQpCZXN0IHJlZ2FyZHMsDQpMb3R0ZSBTdGVlbnJiaW5rDQoNCg0KDQotLQ0KQ2hy
aXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1z
IEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K
VDogICs0NCAoMCkxMjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4g
IHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92
ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENo
ZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4
IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNv
bS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVy
ZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1
cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBp
ZXRmQHRob21hc2NsYXVzZW4ub3JnPG1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3JnPiBbbWFp
bHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmddDQpTZW50OiAxNyBNYXJjaCAyMDE2IDE2OjM4DQpU
bzogRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNCkNjOiBNb2JpbGUgQWQgSG9jIE5ldHdvcmtz
IG1haWxpbmcgbGlzdA0KU3ViamVjdDogUmU6IE1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBtZXNzYWdl
IG11dGFiaWxpdHkgKHdhcyBSRTogW21hbmV0XSBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyBy
ZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKQ0KDQoNCioqKiBXQVJOSU5HICoq
Kg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24s
IGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lk
ZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4g
YW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQg
RmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNs
aWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2Vj
dXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVs
IHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRw
Oi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGln
aHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4N
Cg0KT24gMTcgTWFyIDIwMTYsIGF0IDE3OjMwLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8
Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5
c3RlbXMuY29tPj4gd3JvdGU6DQoNCkkgYXBwcmVjaWF0ZSBUaG9tYXPigJlzIGNvbW1lbnRzIGFi
b3V0IHRoZSBsaW1pdGF0aW9ucyBvZiBtZXNzYWdlIHJlZ2VuZXJhdGlvbiwgYnV0IEkgd291bGQg
YmUgYSBiaXQgbGVzcyBhYnNvbHV0ZS4NCg0KVGhlIGlzc3VlcyBvdmVyIGVuZCB0byBlbmQgYXV0
aGVudGljYXRpb24gYW5kIG1vcmUgYWR2YW5jZWQgc2lnbmF0dXJlcyBhcmUgdmFsaWQuIEkgbmVl
ZCB0byByZWFkIHRoZSBnaXZlbiByZWZlcmVuY2Ugb24gYWdncmVnYXRlIHNpZ25hdHVyZXMgdG8g
aW5jcmVhc2UgbXkga25vd2xlZGdlICh0aGFua3MgZm9yIGl0KSwgYnV0IG15IHVuZGVyc3RhbmRp
bmcgb2YgdGhlIHBvc3NpYmlsaXRpZXMgaW4gdGhpcyBmaWVsZCBtYXkgb2ZmZXIgYSBzb2x1dGlv
biB0byB0aGUgcHJvYmxlbSwgYnV0IHdpdGggc29tZSBvdGhlciBpc3N1ZXMgKHBvc3NpYmx5IGlu
Y2x1ZGluZyBhIG5ldyB0eXBlIG9mIFRMVikuDQoNCkJ1dCB0aGUgaG9wIGNvdW50L2xpbWl0IHBv
aW50IEkgZG9u4oCZdCBmdWxseSBhZ3JlZSB3aXRoLCB5b3UgY2FuIHJlZ2VuZXJhdGUgd2l0aCBh
biBpbmNyZW1lbnRlZC9kZWNyZW1lbnRlZCBjb3VudC9saW1pdCwgd2hpY2ggbGVhdmVzIHRoZSBh
YmlsaXR5IHRvIHByZXZlbnQgbWVzc2FnZXMgcHJvcGFnYXRpbmcgaW5kZWZpbml0ZWx5LCBpbmNs
dWRpbmcgZXhwYW5kaW5nIHJpbmcgc2VhcmNoZXMsIGFuZCByZXRhaW5zIHRoZSBhYmlsaXR5IHRv
IHVzZSBSRkMgNTQ5NyBpbnRlcnZhbCBhbmQgdmFsaWRpdHkgdGltZXMgdGhhdCBtaWdodCBiZSB1
c2VmdWwgd2l0aCBhbiBleHBhbmRpbmcgcmluZyBzZWFyY2ggKG9yIG1pZ2h0IG5vdCkuDQoNCkJ1
dCB0aGUga2V5IGlzc3VlIGlzIHRoYXQgQU9EVnYyIHdhbnRzIHRvIGFjY3VtdWxhdGUgbWV0cmlj
cy4gSSBzdGlsbCBoYXZlbuKAmXQgZ290IHRvIHRoZSBib3R0b20gb2YgbWFueSBkZXRhaWxzIGhl
cmUsIGJ1dCBsZXTigJlzIGZvciB0aGUgbW9tZW50IGp1c3QgY29uc2lkZXIgdGhhdCBjb25jZXB0
dWFsbHkuDQoNCkl04oCZcyBoYXJkIHRvIGhhbmRsZSBlbmQgdG8gZW5kLiBDaGFybGll4oCZcyBk
cmFmdCBhdHRlbXB0cyB0byBkbyBhbiBlbmQgdG8gZW5kIG9mIHNvbWUgaW5mb3JtYXRpb24sIG5v
dCB0aGlzIGluZm9ybWF0aW9uLiBJ4oCZbSBub3Qgc3VyZSBpZiB0aGF04oCZcyB1c2VmdWwgKGFu
ZCB0aGUgc3BlY2lhbGlzZWQgZm9ybWF0IGlzIGJldHRlciBhdm9pZGVkIGlmIHBvc3NpYmxlKS4g
T3RoZXIgYXBwcm9hY2hlcyBhcmUgaG9wIGJ5IGhvcCAobWlnaHQgYXMgd2VsbCB1c2UgcGFja2V0
IHNpZ25hdHVyZXMpIGFuZCBzaGFyZWQga2V5IChtaWdodCBhcyB3ZWxsIGdvIGhvcCBieSBob3Ap
LiBQYWlyd2lzZSBzaWduYXR1cmVzIGZvciBlYWNoIHBhaXIgb2Ygcm91dGVycyBJ4oCZbSBkaXNj
b3VudGluZyBhcyBzY2FsaW5nIHRlcnJpYmx5LiBJbiB0aGUgaW50ZXJlc3RzIG9mIGNvbXBsZXRl
bmVzcyBsZXTigJlzIG1lbnRpb24gbm90IGFjY3VtdWxhdGluZyBtZXRyaWNzLCB3aGljaCBwdXRz
IHVzIGJhY2sgdG8gaG9wIGNvdW50IGFuZCB0aGF04oCZcyBub3QgaWRlYWwgZWl0aGVyLg0KDQpJ
IGRvbuKAmXQgdGhpbmsgdGhlcmUgaXMgYW4gaWRlYWwgc29sdXRpb24uIChJIGxpa2UgaWRlYXMg
SeKAmXZlIHNlZW4gYWJvdXQgYWdncmVnYXRpbmcsIGJ1dCB0aGF0IGhhcyBzb21lIGlzc3VlcyBv
ZiBpdHMgb3duLCBldmVuIGFwYXJ0IGZyb20gY29tcHV0YXRpb25hbCBsb2FkLikgSeKAmWQgbG92
ZSB0byBiZSBwcm92ZWQgd3JvbmcgLSBzb21lb25lIHdpdGggdGhlIHBlcmZlY3Qgc29sdXRpb24g
dG8gY29tZSBhbG9uZy4NCg0KV2hpY2ggbWVhbnMgdGhhdCBlaXRoZXIgd2UgbWFrZSBhbiBhcmJp
dHJhcnkgY2hvaWNlIC0gd2hpY2ggd2lsbCBiZSBkaXNhZ3JlZWQgd2l0aCwgYnV0IG5lZWRzIGRp
c2N1c3NpbmcgZmlyc3QgLSBvciBjcmVhdGUgc29tZXRoaW5nIGZsZXhpYmxlLiBVbmZvcnR1bmF0
ZWx5IGZsZXhpYmxlIGluIHRoYXQgcmVnYXJkIGNvbnN0cmFpbnMgaW4gb3RoZXJzLCBlLmcuIHNv
bWUgKG1hbnk/IG1vc3Q/KSBhZ2dyZWdhdGluZyBzaWduYXR1cmVzIG5lZWQgZml4ZWQgZGF0YSBz
aXplcyAod2hpY2ggd2UgY2FuIGRvIGJ5IGRlZmluaW5nIGEgVExWIHRoYXQg4oCcZmlsbHMgdXDi
gJ0gd2l0aCBob3AgY291bnQsIGJ1dCB0aGF0IGhhcyBhIGNvc3QgdG9vKS4NCg0KSSBoYXZlIGJl
ZW4gdG9sZCBieSBwZW9wbGUgbXVjaCBtb3JlIHdlbGwgdmVyc2VkIGluIHRoaXMgdGhhbiBJIGlu
IGNyeXB0b2xvZ3ksIHRoYXQgdGhlIGNvcnJlY3QgYW5zd2VyIGlzIOKAnHNvbWXigJ0uDQoNClRo
YXQgc2FpZCwgIkFPRFZ2MiB3YW50cyB0byBhY2N1bXVsYXRlIG1ldHJpY3PigJ0g4oCUIGRvZXMg
dGhhdCBtZWFuIHRoYXQgdGhlIG1lc3NhZ2UgZ3Jvd3MgYXMgaXQgaXMgYmVpbmcgZm9yd2FyZGVk
LCBhbmQgdGhhdCB0aGUgcmVjaXBpZW50IG9mIGEgUlJFUS9SUkVQIHdpbGwga25vdyB0aGUgaW5k
aXZpZHVhbCBjb3N0cyBvZiBlYWNoIHBhdGggc2VnbWVudD8gTXkgdW5kZXJzdGFuZGluZyBpcywg
dGhhdCB0aGUgcmVjaXBpZW50IHdpbGwgZ2V0IOKAnHRoZSBzdW0gdGhlIGNvc3RzIG9mIGVhY2gg
cGF0aCBzZWdtZW504oCdIHdoaWNoIHNob3VsZCBiZSBmaXR0aW5nIHdpdGhpbiBhIGZpeGVkIHNp
emU/DQoNClRob21hcw0KDQoNCg0KDQoNClNvcnJ5LCBubyBhbnN3ZXJzLCBqdXN0IGNvbW1lbnRz
LiBBbmQgSeKAmW0gbm90IGFkZHJlc3NpbmcgVGhvbWFz4oCZcyBsYXRlciBwb2ludHMgaGVyZS4N
Cg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpC
QUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUl
MjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hy
aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxs
aWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNm
b3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFl
c3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVk
DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQg
T2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVAN
Cg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgaWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzxtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZz4N
ClNlbnQ6IDE3IE1hcmNoIDIwMTYgMTY6MDANClRvOiBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1h
aWxpbmcgbGlzdA0KU3ViamVjdDogW21hbmV0XSBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyBy
ZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zDQoNCg0KKioqIFdBUk5JTkcgKioq
DQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwg
ZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRl
ciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBh
bnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBG
bGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xp
Y2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1
cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwg
dGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6
Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdo
dHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0K
KioqIFdBUk5JTkcgKioqDQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRl
cyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbi4NCg0KRGVhciBhbGwsDQoNCkFwb2xvZ2ll
cyBmb3Igbm90IGhhdmluZyBnb3R0ZW4gdGhpcyBkb25lIHNvb25lciAtIGRheS1qb2IgbGVhdmlu
ZyBmZXcgc3BhcmUgY3ljbGVzLg0KDQpJ4oCZdmUgcHJldmlvdXNseSBvZmZlcmVkIHJldmlld3Mg
YW5kIGNvbW1lbnRzLCBhbmQgc29tZSBvZiB0aG9zZSBoYXZlIGJlZW4gYWRkcmVzc2VkIGluIHRo
ZSBsYXRlc3QgSS1EIOKAlCBvdGhlcnMgaGF2ZSBub3QsIGJ1dCBzaG91bGQgYmUuIEkgcmVjYWxs
IHRoYXQgdGhlcmUgd2FzIHNvbWUgbWFpbCBhdHRlbXB0aW5nIHRvIHJlYnV0IHBhcnRzIG9mIHRo
ZSByZXZpZXcsIGFuZCBJIHdpbGwgZGlnIGl0IG91dCBhbmQgcmVwbHkgdG8gdGhhdC4NCg0KV2l0
aCB0aGF0IGJlaW5nIHNhaWQsIEkgaGF2ZSByZXZpZXdlZCB0aGUgbGF0ZXN0IHZlcnNpb24gb2Yg
dGhlIGRvY3VtZW50LCBhbmQgZnVsbCBkZXRhaWxzIHdpbGwgYmUgZm9ydGhjb21pbmcuIFRoZXJl
4oCZcmUgYSBjb3VwbGUgb2YgYmlnLXRpY2tldC9hcmNoaXRlY3R1cmFsIGl0ZW1zIHRoYXQgSSB3
YW50IHRvIGFkZHJlc3MgdXAgZnJvbnQsIGFzIEkgYmVsaWV2ZSB0aGF0IGJlZm9yZSB3ZSBoYXZl
IHRob3NlIGhhbW1lcmVkIG91dCwgaXQgd2lsbCBiZSB1c2VsZXNzIHRvIGdvIGludG8gZGV0YWls
cy4gTm90ZSwgSSBkbyBub3QgY2xhaW0gdGhhdCB0aGlzIGlzIGFuIGV4aGF1c3RpdmUgbGlzdCBv
ZiDigJxiaWcgdGlja2V0IGl0ZW1z4oCdLCBidXQgdGhhdOKAmXMgYXMgZmFyIGFzIEkgaGF2ZSBn
b3R0ZW4gaW4gdGhpbmtpbmcgdGhpcyB0aHJvdWdoLg0KDQpJIGFsc28gYnJpbmcgdGhlc2UgdXAg
YXMgdGhleSBhcmUgaXRlbXMgdGhhdCBoYXZlIGJlZW4gYnJvdWdodCB1cCByZXBlYXRlZGx5IG92
ZXIgdGhlIHBhc3QgeWVhcnMsIGJ1dCBub3QgcmVzb2x2ZWQgbm9yIGRpc2N1c3NlZC4NCg0KTG9v
cHMNCkp1c3QgdG8gYnJpbmcgdGhpcyBvdXQ6IEkgc2hhcmUgQ2hyaXPigJkgd29ycnkgYWJvdXQg
Y29uZmxpY3RpbmcgYW5kIGNvbmN1cnJlbnQgc3RhdGVtZW50cyBmcm9tIHRoZSBhdXRob3JzIG9u
IOKAnFRoZXJlIGFyZSBubyBsb29wcyBwb3NzaWJsZeKAnSBhbmQg4oCcV2UgbmVlZCB0byBmaXgg
dHdvIHNpdHVhdGlvbnMgd2hlcmUgbG9vcHMgY2FuIG9jY3Vy4oCdIGFuZCDigJx3ZSBhcmUgc3Rp
bGwgaW52ZXN0aWdhdGluZyBzb21lIGxvb3AgY29uZGl0aW9uc+KAnQ0KDQpJIHBhcnRpY3VsYXJs
eSB3b3JyeSB0aGF0IHRoaXMgaXMgbm90IGEgZGlzY3Vzc2lvbiBoYWQgaW4gcHVibGljLCBidXQg
YXBwYXJlbnRseSBpbiBzb21lIG90aGVyIGZvcnVt4oCmDQoNCg0KSW50ZXJtZWRpYXRlIFJvdXRl
IFJlcGxpZXMsIGFuZCBhbGwgb2Ygc2VjdGlvbiAxMA0KU2VjdGlvbiAxMCBjb250YWlucyBhIHNl
dCBvZiDigJx2YWd1ZWx5IHNwZWNpZmllZCBleHRlbnNpb25z4oCdLCB3aGljaCBpcyBpbmNvaGVy
ZW50IHdpdGggdGhlIGludGVuZGVkIHN0YXR1cyBpbmRpY2F0ZWQgZm9yIHRoaXMgZG9jdW1lbnQu
DQoNClNwZWNpZmljYWxseSwgYW5kIHRoaXMgaXMgbm90IHVucmVsYXRlZCB0byB0aGUgcG9pbnQg
YWJvdXQgbG9vcHMgYWJvdmUsIGludGVybWVkaWF0ZSBSUkVQcyAoc2VjdGlvbiAxMC4zKSBhcmUg
YSBwb3RlbnRpYWwgc291cmNlIGZvciBsb29wcy4NCg0KRXhwYW5kaW5nIFJpbmcgTXVsdGljYXN0
IChzZWN0aW9uIDEwLjEpIGlzIG5vdCBkb2N1bWVudGVkIGluIGEgd2F5IHRoYXQgY2FuIGJlIGlt
cGxlbWVudGVkIChhbmQgYWxzbywgc2VlIOKAnEZvcndhcmRpbmctdnMtcmVnZW5lcmF0aW9u4oCd
IGJlbG93LCBpdCBpcyBpbiB0aGUgcHJlc2VudCBmb3JtIG9mIHRoaXMgcHJvdG9jb2wgaW1wb3Nz
aWJsZSksIGV0Yy4NCg0KDQpGb3J3YXJkaW5nLXZzLXJlZ2VuZXJhdGlvbg0KUmVjZW50IGV4Y2hh
bmdlcyBvbiB0aGUgbGlzdCBtYWRlIG1lIHVuZGVyc3RhbmQgdGhhdCBwcm90b2NvbCBjb250cm9s
IG1lc3NhZ2VzIGFyZSAqbm90KiBmb3J3YXJkZWQsIGJ1dCBhcmUgY29uc3VtZWQgYXQgZWFjaCBo
b3AsIHRoZW4gYSBuZXcgbWVzc2FnZSB3aXRoIChhbG1vc3QtYnV0LW5vdC1xdWl0ZSkgdGhlIHNh
bWUgY29udGVudCBpcyBnZW5lcmF0ZWQgYW5kIHRyYW5zbWl0dGVkLg0KDQpJIGhhdmUgdGhvdWdo
dCBzb21lIG1vcmUgb24gdGhpcyAoJiByZWFkIHNvbWUgb2YgdGhlIGV4Y2hhbmdlcyBvbiB0aGUg
bGlzdCBvbiB0aGlzIHRvcGljIGJ5IENocmlzLCBVbHJpY2gsIGFuZCBvdGhlcnMpLCBhbmQgSSBh
bSBjb252aW5jZWQgdGhhdCB0aGlzIGlzIG5vdCB0aGUgcmlnaHQgd2F5IHRvIGdvLCBhdCBsZWFz
dCBmb3IgdGhlIGZvbGxvd2luZyByZWFzb25zOg0KDQoNCiAgICAgICAgICAgIG8gICAgICAgICAg
SXQgcmVuZGVycyB0aGUgaG9wLWxpbWl0L2hvcC1jb3VudCBmaWVsZHMgaW4gdGhlIFJGQzU0NDQg
bWVzc2FnZSBoZWFkZXIgdXNlbGVzcy4NCiAgICAgICAgICAgICAgICAgICAgICAgIFRoaXMgd291
bGQgbm90IGJlIGJhZCBpZiB0aGUgZnVuY3Rpb25hbGl0eSBvZmZlcmVkIGJ5IHRob3NlIGZpZWxk
cyB3YXMgbm90IHVzZWZ1bA0KICAgICAgICAgICAgICAgICAgICAgICAg4oCUIHNhZGx5LCBpdCBp
cy4gRm9yIGV4YW1wbGUsIGZvciBzY29wZSBsaW1pdGVkIGZsb29kaW5nIChleHBhbmRpbmcgcmlu
ZyBzZWFyY2gsIGFuZA0KICAgICAgICAgICAgICAgICAgICAgICAgc3VjaCkgd2hpY2ggbWF5IGJl
IG9mIGludGVyZXN0LCBhbmQgd2hpY2ggcmVxdWlyZSBob3AtbGltaXQuDQogICAgICAgICAgICAg
ICAgICAgICAgICBBIGhvcC1jb3VudCBmaWVsZCBtYXkgYWxzbyBwcm92aWRlIGEg4oCcY2hlYXDi
gJ0gKGluIHRlcm1zIG9mIG92ZXJoZWFkKSBhZGRpdGlvbmFsIHBpZWNlDQogICAgICAgICAgICAg
ICAgICAgICAgICBvZiBpbmZvcm1hdGlvbiB0byB1c2UgY29uanVuY3RpdmVseSB3aXRoIGEg4oCc
cmVhbOKAnSBtZXRyaWMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBvbmx5IHByYWN0
aWNhbCBzb2x1dGlvbiB3b3VsZCBiZSB0byByZS1pbnRyb2R1Y2UgdGhlc2UgZnVuY3Rpb25zIGJ5
IHdheSBvZiBpbnNlcnRpbmcgYQ0KICAgICAgICAgICAgICAgICAgICAgICAgTWVzc2FnZVRMViDi
gJQgd2hpY2ggKGkpIGlzIG5vdCBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCwgYW5kIChpaSkg
d2hpY2ggd291bGQganVzdA0KICAgICAgICAgICAgICAgICAgICAgICAgc2VydmUgdG8gcmVuZGVy
IG1lc3NhZ2VzIGJpZ2dlciB0aGFuIHN0cmljdGx5IG5lZWRlZC4NCg0KICAgICAgICAgICAgICAg
ICAgICAgICAgU2NvcGUgbGltaXRlZCBmbG9vZGluZyAgZG9lcyBzZWVtIHRvIGJlIGEgbmVjZXNz
YXJ5IHJlcXVpcmVtZW50LCBpZiBmb3Igbm8NCiAgICAgICAgICAgICAgICAgICAgICAgIG90aGVy
IHJlYXNvbiB0aGFuIHRvIHByZXZlbnQgaW5mb3JtYXRpb24gZnJvbSDigJxjaXJjdWxhdGluZyBm
b3JldmVyIGluIHRoZSBuZXR3b3Jr4oCdLg0KDQogICAgICAgICAgICBvICAgICAgICAgIEl0IG1h
a2VzIGVuZC10by1lbmQgYXV0aGVudGljYXRpb24gdW5uZWNlc3NhcmlseSBoYXJkLg0KICAgICAg
ICAgICAgICAgICAgICAgICAgSSB0aGluayBDaHJpcyBjYWxsZWQgdGhpcyBvdXQgYWxyZWFkeSwg
YnV0IGl0IGJlYXJzIHJlcGVhdGluZzogUyBnZW5lcmF0ZXMgYSBtZXNzYWdlDQogICAgICAgICAg
ICAgICAgICAgICAgICAoc2F5LCBhIFJSRVEpLCBhbmQgaW5jbHVkZXMgYW4gSUNWIGNhbGN1bGF0
ZWQgb3ZlciB0aGUgY29udGVudCBvZiB0aGUgbWVzc2FnZS4NCiAgICAgICAgICAgICAgICAgICAg
ICAgIEZvciBhbnkgcmVjaXBpZW50IHRvIGJlIGFibGUgdG8gdmFsaWRhdGUgdGhlIElDViwgdGhl
IG1lc3NhZ2UgaGFzIHRvIGJlIGV4YWN0bHkNCiAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBz
YW1lIOKAlCBub3QganVzdCBpbiBjb250ZW50LCBidXQgaW4gc3RydWN0dXJlIOKAlCBhcyB3aGF0
IHdhcyBnZW5lcmF0ZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIOKAnFJlZ2VuZXJhdGlu
Z+KAnSByYXRoZXIgdGhhbiDigJxmb3J3YXJkaW5n4oCdIG1lc3NhZ2VzIG1lYW5zLCB0aGF0IHRo
ZSBpbnRlcm1lZGlhdGUNCiAgICAgICAgICAgICAgICAgICAgICAgIHJvdXRlciDigJxyZWdlbmVy
YXRpbmfigJ0gdGhlIFJSRVEgbWF5IGNob3NlIGEgZGlmZmVyZW50IHN0cnVjdHVyZSAoZS5nLiwg
aW5jbHVkZSBUTFZzDQogICAgICAgICAgICAgICAgICAgICAgICBpbiBhIGRpZmZlcmVudCBvcmRl
cikuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBwcm9wb3NhbCBmcm9tIGh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wZXJraW5zLW1hbmV0LWFvZHYtZTJlc2VjLTAwDQog
ICAgICAgICAgICAgICAgICAgICAgICBpcyB0byBhZGQgY29uc3RyYWludHMgb24gKGkpIHRoZSBz
ZXQgb2YgZWxlbWVudHMgdG8gaW5jbHVkZSBpbiBhIHNpZ25hdHVyZSBhbmQgKGlpKSB0aGUNCiAg
ICAgICAgICAgICAgICAgICAgICAgIG9yZGVyIG9mIHRoZXNlIGVsZW1lbnRzLg0KDQogICAgICAg
ICAgICAgICAgICAgICAgICBPbmUgcHJvYmxlbSB3aXRoIHRoYXQgYXBwcm9hY2ggaXMgKGkpOiBp
ZiBhbiBleHRlbnNpb24gYWRkcyBhIG1lc3NhZ2UgVExWLCBvciBhbg0KICAgICAgICAgICAgICAg
ICAgICAgICAgQWRkcmVzcyBUTFYsIHRvIGEgbWVzc2FnZSwgdGhlbiB0aGF0IHdpbGwgbm90IGJl
IOKAnGNvdmVyZWTigJ0gYnkgdGhlIHByb3Bvc2VkIGUyZXNlYyBUTFYuDQogICAgICAgICAgICAg
ICAgICAgICAgICBSYXRoZXIgZm9yICplYWNoKiBleHRlbnNpb24gZGV2ZWxvcGVkLCBhbiDigJx1
cGRhdGVzIGUyZXNlY+KAnSBjbGF1c2UgbmVlZHMgdG8gYmUgZG9uZS4NCg0KICAgICAgICAgICAg
ICAgICAgICAgICAgSeKAmWQgc2F5IHRoYXQgdGhpcyBhcHByb2FjaCB3b3VsZCBiZSBwcm9uZSB0
byBlcnJvcnMg4oCUIGFuZCBhZGQgZW50cm9weSB0byB0aGUgcHJvY2Vzcw0KICAgICAgICAgICAg
ICAgICAgICAgICAgb2YgZGVzaWduaW5nIHByb3RvY29sIGV4dGVuc2lvbnMuIFRoZSBhbHRlcm5h
dGl2ZSwgYSBtZXNzYWdlIGJlaW5nIGdlbmVyYXRlZCBieSB0aGUNCiAgICAgICAgICAgICAgICAg
ICAgICAgIHNvdXJjZSBhbmQgKmZvcndhcmRlZCogKGFzIHdlIGRvIGluIE9MU1J2MiwgZm9yIGV4
YW1wbGUpIHdvdWxkIGFsbG93IElDViBUTFZzDQogICAgICAgICAgICAgICAgICAgICAgICAoZXZl
biwgYWxsb3cgcmV1c2Ugb2YgdGhvc2Ugc3BlY2lmaWVkIGZvciBPTFNSdjIpIGZvciBjb3Zlcmlu
ZyBhIG1lc3NhZ2UgYW5kDQogICAgICAgICAgICAgICAgICAgICAgICBleHRlbnNpb25zLg0KDQog
ICAgICAgICAgICAgICAgICAgICAgICDigJxCdXQgd2hhdCBhYm91dCB0aGUgbWV0cmljcyB2YWx1
ZSB3aGljaCB3aWxsIGNoYW5nZSBvbiBlYWNoIGhvcOKAnSwgeW91IG1heSBzYXk/DQogICAgICAg
ICAgICAgICAgICAgICAgICBGb3J0dW5hdGVseSwgdGhhdCBpcyByZWxhdGl2ZWx5IGVhc3kgdG8g
aGFuZGxlOiBzaW1wbHkgemVybyBvdXQgdGhlIHZhbHVlIG9mIHRoYXQgVExWIHdoZW4NCiAgICAg
ICAgICAgICAgICAgICAgICAgIGdlbmVyYXRpbmcgb3IgdmVyaWZ5aW5nIHRoZSBJQ1YgTWVzc2Fn
ZVRMVi4gQW5kIHVzZSBQYWNrZXQtVExWcyBmb3IgaG9wLWJ5LWhvcA0KICAgICAgICAgICAgICAg
ICAgICAgICAgYXV0aGVudGljYXRpb24sIGlmIG5lZWRlZCAoYnV0LCBzZWUgYmVsb3cpLg0KDQog
ICAgICAgICAgICBvICAgICAgICAgIEl0IHByZXZlbnRzIHRoZSB1c2Ugb2YgbW9yZSBjbGV2ZXIv
YWR2YW5jZWQgc2lnbmF0dXJlIHNjaGVtZXMvSUNWcw0KICAgICAgICAgICAgICAgICAgICAgICAg
QWdncmVnYXRlIHNpZ25hdHVyZSBhbGdvcml0aG1zICggaHR0cHM6Ly9jcnlwdG8uc3RhbmZvcmQu
ZWR1L35kYWJvL3BhcGVycy9hZ2dzdXJ2ZXkucGRmKQ0KICAgICAgICAgICAgICAgICAgICAgICAg
ZXhpc3QsIGFuZCBhbiBpbnRlcmVzdGluZyB1c2UtY2FzZSBjYW4gYmUgZm91bmQgaW4gYWxzbyBy
ZWFjdGl2ZSBwcm90b2NvbHMsIGFsbG93aW5nIHZlcmlmeWluZw0KICAgICAgICAgICAgICAgICAg
ICAgICAgbm90IOKAnGp1c3TigJ0gdGhlIGVuZCBwb2ludHMsIGJ1dCBhbHNvIHRoZSBpbnRlcm1l
ZGlhcmllcyAoYWdhaW4sIHdpdGggdGhlIGFwcHJvcHJpYXRlIOKAnHplcm8gb3V04oCdDQogICAg
ICAgICAgICAgICAgICAgICAgICBkaXNjdXNzZWQgYWJvdmUsIG9yIHNvbWV0aGluZyBzbWFydGVy
KS4NCiAgICAgICAgICAgICAgICAgICAgICAgIFJlZ2VuZXJhdGlvbiBvZiBtZXNzYWdlcywgcmF0
aGVyIHRoYW4gZm9yd2FyZGluZywgcmVuZGVycyB0aGF0IGltcG9zc2libGUgKG9yLCBpZiB1c2Vk
LA0KICAgICAgICAgICAgICAgICAgICAgICAgdXBkYXRpbmcgdG8gIGh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1wZXJraW5zLW1hbmV0LWFvZHYtZTJlc2VjLTAwKQ0KDQpUaGVyZSBh
cmUgb3RoZXIgcmVhc29ucywgYnV0IHRoZSBhYm92ZSBhcmUgdGhvc2UgdGhhdCBqdW1wIGF0IG1l
IGFzIGltbWVkaWF0ZSBzaG93LXN0b3BwZXJzLg0KDQpJIGRvIGhvbmVzdGx5IG5vdCBzZWUgd2hh
dCBwb3NzaWJsZSBiZW5lZml0IHRoZXJlIGlzIGZyb20g4oCccmVnZW5lcmF0aW9u4oCdIOKAlCBi
dXQgSSBzZWUgdmVyeSBjbGVhciBpbmNvbnZlbmllbmNlcywgYW5kIHNlY3VyaXR5IGlzIG5vdCB0
aGUgbGVhc3Qgb2YgdGhlc2UuIEluc2lzdGluZyBvbiDigJxyZWdlbmVyYXRpb27igJ0gcmVxdWly
ZXMgZGV2ZWxvcG1lbnQgb2Yg4oCcbm9uLWdlbmVyYWwgd29ya2Fyb3VuZHPigJ0gYXMgcG9pbnRl
ZCBvdXQgYWJvdmUuDQoNClNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQpUaGlzIGlzIGFuIGFsd2F5
cyB0aG9ybnkgc3ViamVjdC4gV2hlbiBPTFNSdjIgd2FzIGdvaW5nIHRocm91Z2ggdGhlIHByb2Nl
c3Mgd2UgZ290IGEgdGhvcm91Z2ggZWR1Y2F0aW9uIGluIGhvdyBsaXR0bGUgd2Uga25ldyBhYm91
dCBzZWN1cml0eSBmcm9tIHRoZSBTRUMtQURzLCBhbmQgaGFkIHRvIHNwZW5kIGFib3V0IGEgeWVh
ciBvciBzbyBkZXZlbG9waW5nIFJGQzcxODMuIFRoZSBib3R0b20gbGluZSBpcywgdGhhdCB0aGlz
IHByb3RvY29sIG5lZWRzIGl0cyDigJxSRkM3MTgzICBlcXVpdmFsZW504oCdLCBlaXRoZXIgYXMg
cGFydCBvZiB0aGUgbWFpbiBkb2N1bWVudCwgb3IgYXMgYW4gaW5kZXBlbmRlbnQgZG9jdW1lbnQu
IGN1cnJlbnRseSwgdGhhdCBpcyBub3QgdGhlIGNhc2UuDQoNCkEgbWluaW1hLCBsb29raW5nIGF0
IEJDUDcyIGFuZCBCQ1AxMDcg4oCUIHRha2luZyBpbnNwaXJhdGlvbiBmcm9tIFJGQzcxODMgbWln
aHQgYmUgYXcgZ29vZCBpZGVhLCBhcyB0aGF0IHdhcyB0aGUgbW9zdCByZWNlbnQgdGhhdCB3ZW50
IHRocm91Z2ggdGhlIFNFQyBBRC4gUmVnYXJkbGVzcyBvZiBob3csIGhvd2V2ZXIsIGEg4oCcbWFu
ZGF0b3J5IHRvIGltcGxlbWVudOKAnSBzZWN1cml0eSBtZWNoYW5pc20gbW9zdCBiZSBzcGVjaWZp
ZWQgKEkgdGhpbmsgdGhlIHJpZ2h0IHRlcm0gd2FzIOKAnE1VU1QgaW1wbGVtZW50LCBTSE9VTEQg
dXNl4oCdKSwgaW4gc3VmZmljaWVudCBkZXRhaWwgdG8gZW5zdXJlIGludGVyb3BlcmFibGUgaW1w
bGVtZW50YXRpb25zLg0KDQpBcyBhbiBleGFtcGxlLCBib3RoIFtSRkM2MTMwXSBhbmQgW1JGQzcx
ODFdIHNldCBvdXQgdGhhdCB0aGF0Og0KDQogICAgICBPbiByZWNlaXZpbmcgYSAuLi4gbWVzc2Fn
ZSwgYSByb3V0ZXIgTVVTVCBmaXJzdCBjaGVjayBpZiB0aGUNCiAgICAgIG1lc3NhZ2UgaXMgaW52
YWxpZCBmb3IgcHJvY2Vzc2luZyBieSB0aGlzIHJvdXRlcg0KDQphbmQgdGhlbiBwcm9jZWVkIHRv
IGdpdmUgYSBudW1iZXIgb2YgY29uZGl0aW9ucyB0aGF0LCBlYWNoLCB3aWxsIGxlYWQgdG8gYSBy
ZWplY3Rpb24gb2YgdGhlIG1lc3NhZ2UgYXMgImJhZGx5IGZvcm1lZCBhbmQgdGhlcmVmb3JlIGlu
dmFsaWQgZm9yIHByb2Nlc3NpbmfigJ0g4oCUIGEgbGlzdCB3aGljaCBSRkM3MTgzIHRoZW4gYW1l
bmRlZC4gVGhhdCBnYXZlIGEg4oCcaG9va+KAnSBmb3IgUkZDNzE4MyBmb3IgaW5zZXJ0aW5nIOKA
nHJlamVjdGlvbuKAnS4gSWRlbSBmb3IgbWVzc2FnZSBnZW5lcmF0aW9uLg0KDQpJZiBJIHdhcyB0
byBkbyBSRkM3MTgxL1JGQzYxMzAgdG9kYXksIEkgd291bGQgaW5jbHVkZSB0aGF0IGRpcmVjdGx5
IGludG8gdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb25zLiBJdCB0dXJuZWQgb3V0IHRvIGJlIG1v
cmUgb3ZlcmhlYWQgKGFuZCBzbG93IGRvd24gcHVibGljYXRpb24gYW55d2F5cykgdG8gZG8gaXQg
YXMgc2VwYXJhdGUgZG9jdW1lbnRzLg0KDQpTZWNvbmRseSwgd2UgbmVlZCB0byBiZSBhIGxvdCBt
b3JlIHJpZ2lkIGluIHRlcm1zIG9mIHdoYXQgSUNWcywgVGltZXN0YW1wcywgZXRjLiBhcmUgYWRk
ZWQvcmVtb3ZlZCwgYW5kIHdoYXQgdGhhdCBicmluZ3MuDQoNCkZvciBleGFtcGxlICh3aXRoIHRo
ZSBhc3N1bXB0aW9uIHRoYXQgbWVzc2FnZXMgYXJlICpmb3J3YXJkZWQqIGFuZCAqbm90KiByZWdl
bmVyYXRlZCksIHRoaXMgY291bGQgYmUgb25lIG9wdGlvbjoNCg0KICAgICAgICAgICAgICAgICAg
ICAgICAgbyAgICAgICAgICBXaGVuIGEgUlJFUSwgUlJFUCBtZXNzYWdlIGlzIGdlbmVyYXRlZCwg
YWRkIGFuIElDViBNZXNzYWdlIFRMViwgd2hpY2ggaXMgY2FsY3VsYXRlZCA8dGhpcyB3YXk+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg4oCmKHRha2UgaW5zcGlyYXRpb24g
ZnJvbSBSRkM3MTgzIGhlcmUpDQoNCi4uLg0KDQpbTWVzc2FnZSBjbGlwcGVkXQ0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlz
dA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9y
ZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL21hbmV0DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50
cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBhbHNv
IGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgcGxl
YXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KWW91
IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9z
ZSBvcgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKgo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B12C9GLKXM0002VGREEN_
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
MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N
c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs
InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h
bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz
Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJ
e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhv
bWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLkVt
YWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1
bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg
NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6
ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2
OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t
LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl
Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2l0aCByZWdhcmQgdG8geW91
ciB2YWxpZGl0eSB0aW1lIHBvaW50LCB3ZSBoZXJlIGhhdmUgYSB0cmFkZW9mZi4gSWYgeW91IGFs
bG93IHRoYXQgZmVhdHVyZSwgaXQgc2lnbmlmaWNhbnRseSBpbXBhY3RzIG9uIHRoZSBhcHByb2Fj
aCB0aGF0IHdhcyBjb21pbmcgdG9nZXRoZXINCiBvbiBhcyBiZXN0IHlvdSBjYW4gZW5kIHRvIGVu
ZCBlbmNyeXB0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28gdGhlIHF1ZXN0aW9uIGlzLCBpcyB0aGlzIGEgZmVh
dHVyZSB0aGF04oCZcyByZWFsbHkgd2FudGVkPyBVbmZvcnR1bmF0ZWx5IEkgdGhpbmsgd2Uga25v
dyB0aGF0IHRoZSBhbnN3ZXIgdG8gdGhhdCBpcywgd2UgZG9u4oCZdCBrbm93IGJlY2F1c2Ugd2Ug
ZG9u4oCZdCBoYXZlIGFueQ0KIGV4cGVyaWVuY2UuIE15IHZpZXcgd291bGQgYmUgdGhhdCBpbiB0
aGUgdHJhZGVvZmYgb2YgYW4gdW50ZXN0ZWQgZmVhdHVyZSAodW5sZXNzIEnigJltIHdyb25nIGFi
b3V0IHRoYXQpIGFuZCB0aGUgc2VjdXJpdHkgY29tcGxpY2F0aW9uLCBzZWN1cml0eSB3aW5zIGFu
ZCBkcm9wIHRoZSBmZWF0dXJlLiBJZiB0aGVyZSBpcyBzb21lIHJlYWwgcmVxdWlyZW1lbnQsIHRo
ZW4gdGhlcmXigJlzIGEgZGlzY3Vzc2lvbi4gKFF1ZXN0aW9ucyBsaWtlIGhvdyBvZnRlbg0KIHRo
ZSBpbnRlcm1lZGlhdGUgcm91dGVycyBhY3R1YWxseSBoYXZlIGFueSBrbm93bGVkZ2UgLSB0eXBp
Y2FsbHkgbGlua3MgYnJlYWsgZm9yIHVuZXhwZWN0ZWQgcmF0aGVyIHRoYW4gZXhwZWN0ZWQgcmVh
c29ucy4gQW5kYW4gaW50ZXJtZWRpYXRlIHJvdXRlciBjb3VsZCBwb3NzaWJseSB1c2UgYSB2YWxp
ZGl0eSB0aW1lIHRvIGluZmx1ZW5jZSBpdHMgYmVoYXZpb3VyLikgTm90ZSB0aGF0IGRyb3BwaW5n
IHRoZSBhYmlsaXR5IG9mIGludGVybWVkaWF0ZQ0KIHJvdXRlcnMgdG8gbW9kaWZ5L3NldCBzdGls
bCBhbGxvd3MgdmFsaWRpdHkgdGltZXMgcGVyIHJvdXRlIHRvIGJlIHNldCBhdCBlbmRwb2ludHMu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5XaXRoIHJlZ2FyZCB0byB0aGUgYWNrbm93bGVkZ2VtZW50cywgdGhlIHByb2Js
ZW0gKHdpdGggcmVnYXJkIHRvIHNlY3VyaXR5KSBjb21lcyBmcm9tIHRyeWluZyB0byBkbyB0d28g
am9icyB3aXRoIHRoZSBzYW1lIG1lc3NhZ2UgLSBlbmQgdG8gZW5kIHJvdXRlIGFkdmVydGlzZW1l
bnQNCiBhbmQgaG9wIGJ5IGhvcCBhY2tub3dsZWRnZW1lbnQuIEkgdW5kZXJzdGFuZCB0aGUgcmVh
c29ucyAtIHNhdmluZyBieXRlcyBhbmQgbWVzc2FnZSB0eXBlcy4gKEkgd291bGQgaGF2ZSB0byBz
dHVkeSB0aGUgcHJvdG9jb2wgcmVhbGx5IGhhcmQgdG8gaWRlbnRpZnkgaWYgYW55IG1lc3NhZ2Ug
dHlwZXMgY2FuIGJlIGZvbGRlZCB0b2dldGhlciBhbmQgcmVjb2duaXNlZCBieSBjb250ZW50IHJh
dGhlciB0aGFuIHR5cGUgZWZmaWNpZW50bHkuIFRoaXMNCiBJIGRvIG5vdCBleHBlY3QgdG8gZG8u
KSBBZ2FpbiBhIHRyYWRlb2ZmLiBUaGlzIG9uZSBpcyBpbiBkaXNjdXNzaW9uIHNwYWNlLCB0aG91
Z2ggdGhhdCBuZWVkcyBwZW9wbGUgd2hvIHVuZGVyc3RhbmQgYm90aCBzaWRlcyBvZiB0aGUgaXNz
dWUsIGluY2x1ZGluZyB0aGUgZGV0YWlscyBvZiB0aGUgYmlkaXJlY3Rpb25hbGl0eSBtZWNoYW5p
c20uIE9mIGNvdXJzZSwgYXMgaGFzIGJlZW4gc2FpZCwgd2UgbmVlZCBvbmUgb2YgdGhvc2UuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPG86cD48L286cD48L3Nw
YW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3Rv
cGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lz
dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdF
Ij48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0Qi
PlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZu
YnNwOyYjNDM7NDQgKDApMTI0NSAyNDIxOTQgJm5ic3A7fCAmbmJzcDs8Yj5FOg0KPC9iPjxhIGhy
ZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVA
YmFlc3lzdGVtcy5jb208L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRl
Y2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxi
cj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiPjxzcGFuIHN0eWxlPSJj
b2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVk
PGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lz
dGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdV
MiA3WVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij4gVmljdG9yaWEgTWVyY2llY2EgW21haWx0bzp2bWVyY2llY2EwQGdt
YWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyMyBBcHJpbCAyMDE2IDEwOjU1PGJyPg0KPGI+
VG86PC9iPiBDaHJpc3RvcGhlciBEZWFybG92ZTxicj4NCjxiPkNjOjwvYj4gaWV0ZkB0aG9tYXNj
bGF1c2VuLm9yZzsgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk7IE1vYmlsZSBBZCBIb2MgTmV0
d29ya3MgbWFpbGluZyBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFuZXRdIE1lc3Nh
Z2UgaW50ZWdyaXR5IGFuZCBtZXNzYWdlIG11dGFiaWxpdHkgKHdhcyBSRTogZHJhZnQtaWV0Zi1t
YW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcyk8bzpw
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
aHJpcyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXNl
IGhhdmUgYm90aCBiZWVuIGluIHRoZSBkcmFmdCBpbiBzb21lIGZvcm0gc2luY2UgYmVmb3JlIEkg
Z290IGludm9sdmVkLi4uIGJ1dCBJJ2xsIGRvIG15IGJlc3QgdG8gZXhwbGFpbi48bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gRm9yIFZhbGlkaXR5IFRpbWUs
IGl0cyBhIHdheSB0byBhZHZlcnRpc2UgdGhhdCB5b3Ugd291bGQgb25seSBzdXBwb3J0IHRoZSBy
b3V0ZSBjb250YWluZWQgaW4gdGhlIG1lc3NhZ2UgZm9yIGEgY2VydGFpbiBwZXJpb2Qgb2YgdGlt
ZS4gVGhlIG9yaWdpbmF0b3IgbWlnaHQgdXNlIHRoaXMsIGJ1dCB0aGUgZHJhZnQgd2FzIHdyaXR0
ZW4gdG8gYWxsb3cgYW55IGludGVybWVkaWF0ZSBub2RlIHRvIGJlIGFibGUNCiB0byBhZGQgaXQg
b3IgdXBkYXRlIGl0IHRvby4gVGhlIHJvdXRlIGNyZWF0ZWQgaW4gdGhlIExvY2FsIFJvdXRlIFNl
dCBoYXMgYW4gZXhwaXJhdGlvbiB0aW1lIGFzc29jaWF0ZWQgd2l0aCBpdCwgYmFzZWQgb24gdGhl
IHJlY2VpdmVkIHZhbGlkaXR5IHRpbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEZvciB0aGUgQWNrUmVxIGFkZHJlc3MsIGl0cyBzbyB0aGF0
IHlvdSBjYW4gYWRkIGludG8gYSBSUkVQIGEgcmVxdWVzdCBmb3IgYW4gYWNrbm93bGVkZ2VtZW50
LCBzbyB0aGF0IHlvdSBkb24ndCBoYXZlIHRvIGhhdmUgYSBkaWZmZXJlbnQgbWVzc2FnZSB0eXBl
IGFsdG9nZXRoZXIgZm9yIHdvcmtpbmcgb3V0IHdoZXRoZXIgbGlua3MgdG8gbmVpZ2hib3JzIGFy
ZSBiaWRpcmVjdGlvbmFsLCBhbmQgYWxzbywgc2luY2UNCiB5b3Ugb25seSBjYXJlIGFib3V0IGJp
ZGlyZWN0aW9uYWxpdHkgb24gcm91dGVzIHRoYXQgYXJlIGJlaW5nIHNldCB1cCwgeW91IGRvbnQg
bmVlZCB0byBjb25zdGFudGx5IG1vbml0b3IgYWxsIG5laWdoYm9ycy48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBvcmRlciB0byBhdm9p
ZCB0aGUgcG90ZW50aWFsIEFja1JlcS1yZWxhdGVkIGNoYW5nZXMgdG8gZWFjaCBtZXNzYWdlLCBt
YXliZSB3ZSBkbyBuZWVkIHRvIGludHJvZHVjZSBhIGRpZmZlcmVudCBtZXNzYWdlIHNwZWNpZmlj
YWxseSBmb3IgdGhpcy4gV2UgY291bGQgbWF5YmUgdXNlIFJSRVBfQWNrIHRvIGJvdGggcmVxdWVz
dCBhbmQgYWNrbm93bGVkZ2U/IEl0IG1lYW5zIGFuIGV4dHJhIG1lc3NhZ2Ugb2YgY29udHJvbA0K
IHRyYWZmaWMgdGhhdCBuZWVkcyB0byBiZSBzZW50LCBtYXliZSBvbmUgZXh0cmEgbWVzc2FnZSBw
ZXIgaG9wIG9uIHRoZSBwYXRoIG9mIGEgUlJFUCwgYnV0IGl0IGNvdWxkIHN0aWxsIGJlIGxpbWl0
ZWQgdG8gbmVpZ2hib3JzIHdoaWNoIGhhdmUgcGFydGljaXBhdGVkIGluIHRoZSByb3V0ZSBkaXNj
b3ZlcnkgcmF0aGVyIHRoYW4gbW9uaXRvcmluZyBhbGwgbmVpZ2hib3JzIGF0IGFsbCB0aW1lcy4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+VGhpcyBtZXNzYWdlIGNvdWxkIG1heWJlIGFsc28gaW5jbHVkZSAmcXVvdDtJJ20gaGFwcHkg
dG8gcm91dGUgYW55d2hlcmUgZm9yIGEgY2VydGFpbiBhbW91bnQgb2YgdGltZSZxdW90Oywgc29y
dCBvZiBsaWtlIHdpbGxpbmduZXNzIGluIE9MU1IvT0xTUnYyLiBTbyBpbnN0ZWFkIG9mIGhhdmlu
ZyBhIHZhbGlkaXR5IHRpbWUgcGVyIHJvdXRlLCBpdHMgYSB2YWxpZGl0eSB0aW1lIHBlciBuZWln
aGJvci4gVGhlbiwgZm9yIFJSRVENCiBhbmQgUlJFUCwgb25seSB0aGUgbWV0cmljIHZhbHVlIHdv
dWxkIGNoYW5nZSBpbiB0cmFuc2l0LCBhcyBkaXNjdXNzZWQuIEhvd2V2ZXIsIHRoYXQgbGVhZHMg
dG8gc29tZSBpc3N1ZXMgd2l0aCBkZWNpZGluZyB3aGF0IGEgcm91dGUncyBleHBpcmF0aW9uIHRp
bWUgaXMuIFlvdSBtaWdodCBrbm93IGhvdyBsb25nIHRoZSBuZXh0IGhvcCByb3V0ZXIgaXMgdmFs
aWQgZm9yLCBidXQgd2hhdCBpZiBhIHJvdXRlciBiZXlvbmQgdGhhdCwgd2hpY2ggd2FzDQogYWxz
byBwYXJ0IG9mIHRoZSByb3V0ZSwgaGFkIGEgbG93ZXIgdmFsaWRpdHkgdGltZT8gWW91IGNvdWxk
bid0IGRldGVybWluZSB0aGUgcmVhbCB2YWxpZGl0eSB0aW1lLiBEbyB3ZSByZW1vdmUgdGhlIHJv
dXRlIGV4cGlyYXRpb24gdGltZSBhbHRvZ2V0aGVyIHRvIGF2b2lkIHRoaXMgaXNzdWU/IEluIHdo
aWNoIGNhc2UsIHdlIHdvdWxkIGhhdmUgdG8gcmVseSBvbiBSRVJSIG1lc3NhZ2VzIGJlaW5nIHNl
bnQgZm9yIHJvdXRlcyB3aGljaCBiZWNvbWUNCiBpbnZhbGlkIHdoZW4gdGhlIG5laWdoYm9yJ3Mg
dmFsaWRpdHkgdGltZSBoYXMgZXhwaXJlZD8gU28gbmVpZ2hib3IgdmFsaWRpdHkgdGltZSBleHBp
cmF0aW9uIGlzIHRyZWF0ZWQgdGhlIHNhbWUgYXMgYSBsaW5rIGJyZWFrLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGRvIHlvdSB0aGlu
az88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
S2luZCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+VmljdG9yaWEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgQXByIDIzLCAyMDE2IGF0IDE6MDkgQU0s
IENocmlzdG9waGVyIERlYXJsb3ZlICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXNAbW5lbW9zeW5l
LmRlbW9uLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVr
PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPlByZXR0eSBtdWNoIGFsbCBvZiB0aGUgZGlzY3Vzc2lvbiBoYXMgYmVlbiBhc3N1
bWluZyBvbmx5IGEgbWV0cmljIHZhbHVlIGNoYW5nZS4gV2l0aCBtdWx0aXBsZSB0aGluZ3MgY2hh
bmdpbmcgbWFueSBvZiB0aGUgaWRlYXMgZ28gb3V0IG9mIHRoZSB3aW5kb3cuIFRoYXQgcmVpbmZv
cmNlcyB0aGUgcG9pbnQgYWJvdXQgbm90IG1ha2luZyBzcGVjaWZpY2F0aW9ucyBub3cgdGhhdCBt
aWdodCB0dXJuIG91dCB0byBiZQ0KIHdyb25nIGZvciBJQ1ZzLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZ25vcmluZyBob3cgdGhpcyBtaXN1
bmRlcnN0YW5kaW5nIGhhcHBlbmVkLCBJJ2xsIHN0YXJ0IGJ5IGFza2luZyB3aHkuIE1ldHJpYyBj
aGFuZ2luZyBJIHVuZGVyc3RhbmQuIFdoeSB0aGUgb3RoZXIgdHdvPyAodGhlcmUncyBhIHBhcnRp
YWwgZXhwbGFuYXRpb24gb2Ygb25lKS4gV2hhdCBhbHRlcm5hdGl2ZXMgaGF2ZSBwZW9wbGUgaW1w
bGVtZW50ZWQgaW4gY29tcGFyYWJsZSBwcm90b2NvbHM/PGJyPg0KPGJyPg0KLS0gJm5ic3A7PG86
cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hyaXN0b3BoZXIgRGVh
cmxvdmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxhIGhyZWY9Im1haWx0bzpjaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb20iIHRhcmdldD0i
X2JsYW5rIj5jaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb208L2E+IChpUGhvbmUpPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJt
YWlsdG86Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXNA
bW5lbW9zeW5lLmRlbW9uLmNvLnVrPC9hPiAoaG9tZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206
MTIuMHB0Ij48YnI+DQpPbiAyMyBBcHIgMjAxNiwgYXQgMDA6MjYsIFZpY3RvcmlhIE1lcmNpZWNh
ICZsdDs8YSBocmVmPSJtYWlsdG86dm1lcmNpZWNhMEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r
Ij52bWVyY2llY2EwQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5Db250aW51ZWQgaW4gdGhpcyB0aHJlYWQgYmVjYXVzZSB0aGUgb3RoZXIgb25l
IHNlZW1zIHRvIGJlIG1vcmUgYWJvdXQgVExWIHR5cGVzIGFuZCBtZXRyaWMgdHlwZSBudW1iZXJz
LCB3aGVyZWFzIHRoaXMgaXMgYWJvdXQgcmVnZW5lcmF0aW9uL2ZvcndhcmRpbmcuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIHJlY2FwLCBp
biB0aGUgY3VycmVudCBkcmFmdCwgdGhlcmUgYXJlIDMgdGhpbmdzIHRoYXQgbWlnaHQgY2hhbmdl
IGF0IGVhY2ggaG9wOg0KPGJyPg0KLSB0aGUgbWV0cmljIHZhbHVlIChoYXBwZW5zIGluIFJSRVEg
YW5kIFJSRVApLCA8YnI+DQotIGFkZGluZy9jaGFuZ2luZyBWYWxpZGl0eSBUaW1lIHVzaW5nIHRo
ZSBWYWxpZGl0eSBUaW1lIFRMViAoY2FuIGhhcHBlbiBpbiBSUkVRIGFuZCBSUkVQKSwNCjxicj4N
Ci0gYWRkaW5nIGFuIGFkZHJlc3MgKGFuZCBjb3JyZXNwb25kaW5nIHZhbHVlIGluIHRoZSBBZGRy
ZXNzVHlwZSBUTFYgdG8gaW5kaWNhdGUgaG93IHRvIGludGVycHJldCB0aGUgYWRkcmVzcykgdG8g
aW5kaWNhdGUgdGhlIGFkZHJlc3MgZnJvbSB3aGljaCBhbiBSUkVQX0FjayBpcyBleHBlY3RlZCwg
dG8gYWNjb21wbGlzaCB0aGUgYmlkaXJlY3Rpb25hbGl0eSBjaGVjayAoY2FuIGhhcHBlbiBpbiBS
UkVQKS48YnI+DQo8YnI+DQpJZiB3ZSBkZWZpbmUmbmJzcDthIGNlcnRhaW4gcG9ydGlvbiBvZiB0
aGUgbWVzc2FnZSBhcyBpbW11dGFibGUgYW5kIGluY2x1ZGUgdGhlIElDViB0byB2ZXJpZnkgdGhh
dCBwYXJ0LCBlbmQgdG8gZW5kOg0KPGJyPg0KLSBUaGUgbWV0cmljIHZhbHVlIHdvdWxkIGJlIGV4
Y2x1ZGVkIGZyb20gdGhlIElDViBzaW5jZSBpdCBuZWVkcyBjaGFuZ2luZyBhdCBlYWNoIGhvcC4m
bmJzcDs8YnI+DQotIFdvdWxkIGFkZGluZyBhIFZhbGlkaXR5IFRpbWUgVExWIGF0IGFuIGludGVy
bWVkaWF0ZSBob3AgYmUgYWNjZXB0YWJsZT8gVGhlIHdob2xlIFRMViBjb3VsZCBiZSByZW1vdmVk
IGluIG9yZGVyIHRvIGNhbGN1bGF0ZSB0aGUgSUNWPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFdvdWxkIGFkZGluZyBhbiBhZGRyZXNzIGNhdXNlIGlzc3Vl
cyBmb3IgdGhlIElDViwgYmVjYXVzZSBpdCdzIGluIHRoZSBhZGRyZXNzIGJsb2NrPyBDb3VsZCB0
aGUgcnVsZSBiZSAmcXVvdDtpZiBpdCBjb250YWlucyBhbiBBY2tSZXEgYWRkcmVzcywgcmVtb3Zl
IGl0IChhbmQgdGhlIGNvcnJlc3BvbmRpbmcgdmFsdWUgaW4gdGhlIEFkZHJlc3NUeXBlIFRMViks
IGJlZm9yZSBjaGVja2luZyB0aGUgSUNWJnF1b3Q7LCBpcyB0aGF0DQogT0s/IE9yIHdvdWxkIHdl
IG5lZWQgdG8gYXZvaWQgdG91Y2hpbmcgdGhlIElDVidlZCBwYXJ0IG9mIHRoZSBtZXNzYWdlIGFs
dG9nZXRoZXIsIG1heWJlIHB1dCB0aGUgQWNrUmVxIGFkZHJlc3MgaW4gYSBzZXBhcmF0ZSBBZGRy
ZXNzIEJsb2NrLCB3aXRoIGFuIGV4dHJhIEFkZHJlc3NUeXBlIFRMViBmb2xsb3dpbmcgdGhhdCBh
ZGRyZXNzIGJsb2NrPyBJcyB0aGVyZSBhIHdheSB0byBhY2NvbXBsaXNoIHRoaXM/PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIHRvIGJl
IHRob3JvdWdoLCBkbyB3ZSBuZWVkIHRvIGNvbnNpZGVyIFJFUlIgbWVzc2FnZXMgd2hpbGUgd2Ug
ZGlzY3VzcyByZWdlbmVyYXRpb24gdnMgZm9yd2FyZGluZz8mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gUkVSUiAoc2VudCB3aGVuIGEg
bGluayBicmVha3MpIGlzIGEgd2F5IG9mIHNheWluZyAmcXVvdDtJJ3ZlIGxvc3QgbXkgcm91dGUg
c28gSSdtIHRlbGxpbmcgb3RoZXJzJnF1b3Q7IGFuZCAmcXVvdDt5b3Ugd2VyZSBteSBuZXh0IGhv
cCwgc28mbmJzcDtub3cmbmJzcDtJJ3ZlIGFsc28gbG9zdCBteSByb3V0ZSwgSSdsbCB0ZWxsIG90
aGVycyZxdW90OywgZXRjLiBJdCdzIGdvaW5nIHRvIGJlIHRhaWxvcmVkIGF0IGVhY2ggc3RlcCB0
byBpbmNsdWRlIHRoZSByZWxldmFudA0KIHJvdXRlcyB0aGF0IGdvdCBkZWxldGVkLCBpdCdzIG5v
dCBvbmUgbWVzc2FnZSBiZWluZyBzZW50IGVuZC10by1lbmQgbGlrZSBSUkVRIGFuZCBSUkVQIGFy
ZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPi0gSG93ZXZlciwgUkVSUiAoc2VudCB3aGVuIGEgc291cmNlIG9mIHRyYWZmaWMgaXMgc2Vu
ZGluZyBkYXRhIG9uIGEgcm91dGUgd2hpY2ggY29tZXMgdGhyb3VnaCB5b3UsIGFuZCB5b3Ugd2Fu
dCB0byB0ZWxsIHRoZSBQYWNrZXQgU291cmNlJ3Mgcm91dGVyIHRvIGRlbGV0ZSB0aGUgcm91dGUp
IGNvdWxkIGJlIHNlZW4gYXMgYW4gZW5kLXRvLWVuZCBtZXNzYWdlIHdoaWNoIGFsbCBpbnRlcm1l
ZGlhdGUgcm91dGVycw0KIGxlYXJuIGZyb20sIHNpbWlsYXIgdG8gUlJFUSBhbmQgUlJFUC4gSXQg
cmVwb3J0cyBvbmUgcm91dGUsIGFuZCBkb2Vzbid0IG5lZWQgY2hhbmdpbmcgYXQgaW50ZXJtZWRp
YXRlIGhvcHMsIHNvIGNvdWxkIGJlIHByb3RlY3RlZCB3aXRoIElDVi48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gV291bGQgaXQgYmUgT0sgdG8g
b25seSByZXF1aXJlIGEgbWVzc2FnZSBJQ1YgaWYgYSBQa3RTb3VyY2UgYWRkcmVzcyB3YXMgaW5j
bHVkZWQsIGkuZS4gd2hlbiB0aGUgbWVzc2FnZSBuZWVkcyB0byBnbyB2aWEgYSBudW1iZXIgb2Yg
aW50ZXJtZWRpYXRlIGhvcHMgdG8gUGt0U291cmNlJ3Mgcm91dGVyPyBBbGwgb3RoZXIgUkVSUnMg
YXJlIGludGVuZGVkIHRvIGJlIG9uZS1ob3AgbWVzc2FnZXMsIHdoaWNoIG1heQ0KIGluIHR1cm4g
cHJvbXB0IG90aGVyIG9uZS1ob3AgbWVzc2FnZXMsIGV0Yy4uLiwgYW5kIGEgcGFja2V0IElDViBt
aWdodCBiZSBtb3JlIGFwcHJvcHJpYXRlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPktpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VmljdG9yaWEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1hciAxNywgMjAxNiBhdCA1OjI2IFBNLCAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZXRm
QHRob21hc2NsYXVzZW4ub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTcgTWFyIDIwMTYsIGF0IDE4OjE3LCBEZWFybG92
ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh
ZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j
b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
WWVzLCBJIG1lYW50IEFPRFZ2MiwgdGhhbmtzIGZvciB0aGUgY2F0Y2guPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBpcyB5b3VyIChUaG9tYXMpIHByb3Bvc2VkIGJh
c2Ugc3BlY2lmaWNhdGlvbiBhIGhvcCBjb3VudCBvbmx5IG1ldHJpYz88L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk5vLCB0aGUgd291bGQgYmUgc2lsbHkgYXMgYmFzZSBzcGVjaWZpY2F0aW9u
LCBnaXZlbiB0aGF0IGhvcCBjb3VudCBtb3N0bHkgaXMgdXNlbGVzcy48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgYmFzZSBzcGVjaWZpY2F0
aW9uIEkgd291bGQgc2ltcGx5IHNheSDigJxJbmNsdWRlIGEgTWV0cmljIFR5cGUgTWVzc2FnZSBU
TFYgd2l0aCBhIHZhbHVlIGZpZWxkLCBhbmQgYSA3MTgyIE1lc3NhZ2UgVExWICZhbXA7IFRpbWVz
dGFtcOKAnSBhcyB3ZSBkbyBpbiBPTFNSdjIgKHdpdGggdGhlIGFwcHJvcHJpYXRlIHZlcmJpYWdl
IGFzIHRvIGdlbmVyYXRpb24gYW5kIHByb2Nlc3NpbmcpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIHRoZSBtZXNzYWdlIGdl
bmVyYXRlZCBieSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgUlJFUS9SUkVQIGFuZCAqbm90KiBkZWNv
bnN0cnVjdGVkL3JlY29uc3RydWN0ZWQvcmVvcmRlcmVkIChhcyBpcyB0aGUgcmlzayB3aXRoIOKA
nHJlZ2VuZXJhdGlvbikgYWxsb3dzIGtub3dpbmcgdGhhdCBpdCB3b3VsZCBiZSAqb25seSogdGhh
dCBtZXRyaWMgZmllbGQgYmVpbmcgbW9kaWZpZWQgKG90aGVyIHRoYW4gaG9wIGNvdW50L2xpbWl0
KQ0KIGZvciB3aGVuIGV2ZW50dWFsbHkgd3JpdGluZyB1cCB0aGUgZXh0ZW5zaW9uLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KEFjdHVhbGx5IGRvZXNu
4oCZdCB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uIG9ubHkgZGVmaW5lIGhvcCBjb3VudCwgb3Ig
aGFzIHRoYXQgY2hhbmdlZCBpbiBsYXRlc3QgZHJhZnQ/KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5v
LiBUaGF0IGlzIG9uZSBvZiB0aGUgaXNzdWVzIEkgcmFpc2UgaW4gbXkgb3JpZ2luYWwuIEZvciBz
b21lIHJlYXNvbiwgaXQgY2l0ZXMgUkZDNjU1MSwgd2hpY2ggaXMgYSBST0xMIGRvY3VtZW50IGFu
ZCB3aGljaCBoYXMgaW4gaXRzIGFic3RyYWN0IHRoYXQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IExvdy1Qb3dlciBhbmQgTG9zc3kgTmV0d29ya3Mg
KExMTnMpIGhhdmUgdW5pcXVlIGNoYXJhY3RlcmlzdGljczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZuYnNwOyZuYnNwOyBjb21wYXJlZCB3aXRoIHRyYWRpdGlvbmFsIHdpcmVkIGFuZCBhZCBob2Mg
bmV0d29ya3MgdGhhdCByZXF1aXJlIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu
YnNwOyBzcGVjaWZpY2F0aW9uIG9mIG5ldyByb3V0aW5nIG1ldHJpY3MgYW5kIGNvbnN0cmFpbnRz
LiA8bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SS5lLiB0
aGlzIGRvY3VtZW50IGNpdGVzIGEgbWV0cmljIGRvY3VtZW50IHdoaWNoIGNsZWFybHkgY2xhaW1z
IHRvIGJlIGluYXBwbGljYWJsZSBpbiBhZCBob2MgbmV0d29ya3MuIEkgbm90ZSB0aGF0IHRoaXMg
aXMgYW5vdGhlciB0aGluZyBJ4oCZdmUgcmFpc2VkIGZvciB5ZWFycyB3aXRob3V0IHNlZWluZyBp
dCBhdHRlbXB0ZWQgcmVzb2x2ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRob21hczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w
cHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS08L3NwYW4+
PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0Ui
PkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4N
CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bh
bj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdE
N0QiPjogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQiIHRh
cmdldD0iX2JsYW5rIj4mIzQzOzQ0ICgwKTEyNDUgMjQyMTk0PC9hPg0KICZuYnNwO3wgJm5ic3A7
PGI+RTombmJzcDs8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu
Y29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2hyaXMuZGVh
cmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwg
Q2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNz
ZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIiB0
YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1z
LmNvbS9haTwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUg
U3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBF
bmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6
IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij4mbmJzcDs8YSBocmVmPSJtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIg
dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlldGZAdGhvbWFzY2xh
dXNlbi5vcmc8L3NwYW4+PC9hPiZuYnNwO1s8YSBocmVmPSJtYWlsdG86aWV0ZkB0aG9tYXNjbGF1
c2VuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0
bzppZXRmQHRob21hc2NsYXVzZW4ub3JnPC9zcGFuPjwvYT5dJm5ic3A7PGJyPg0KPGI+U2VudDo8
L2I+Jm5ic3A7MTcgTWFyY2ggMjAxNiAxNzoxMDxicj4NCjxiPlRvOjwvYj4mbmJzcDtEZWFybG92
ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4NCjxiPkNjOjwvYj4mbmJzcDtMb3R0ZSBTdGVlbmJyaW5r
OyBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9i
PiZuYnNwO1JlOiBbbWFuZXRdIE1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBtZXNzYWdlIG11dGFiaWxp
dHkgKHdhcyBSRTogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUg
b2YgYmlnIHRpY2tldCBJdGVtcyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5n
OjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj
ZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndo
aXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJO
SU5HICoqKjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7
dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91
dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBv
ciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0
aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBv
ciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBpbmZvcm1hdGlvbiBy
ZWdhcmRpbmcmbmJzcDs8L3NwYW4+PC9lbT48L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9zdHJvbmc+
PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+Jm5ic3A7dGhhdA0K
IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2smbmJzcDs8
YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1
cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiIHRhcmdldD0iX2JsYW5r
Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5oZXJlPC9zcGFuPjwvYT4uPC9zcGFuPjwvZW0+
PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93
Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdv
cmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNp
b3VzJTIwRW1haWxzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw
bGUiPnRoaXMNCiBwcm9jZXNzPC9zcGFuPjwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+T24gMTcgTWFyIDIwMTYsIGF0IDE4OjA0LCBEZWFybG92ZSwgQ2hy
aXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl
bXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2hyaXMu
ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T0ssIHNv
IHdlIGhhdmUgYSBtZXNzYWdlIHRoYXQgbXV0YXRlcyBieTo8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LSBNb2RpZnlpbmcgaG9wIGNv
dW50L2xpbWl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj4tIE1vZGlmeWluZyBhIG1ldHJpYyB2YWx1ZS48L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW55dGhpbmcgZWxz
ZT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkFzIG11dGF0aW5nIChvdGhlciB0aGFuIGhvcCBjb3VudC9saW1pdCkg
bWVzc2FnZXMgYXJlbuKAmXQgY292ZXJlZCBieSA1NDQ0IG9yIGFueSBkZXJpdmF0aXZlIGRvY3Vt
ZW50IChidXQgb25seSByZWNvbW1lbmRlZCBhZ2FpbnN0LCBub3QgYmFubmVkKSB0aGF0IHlvdSBt
YXkNCiBuZWVkIHRvIG1ha2UgdGhlIG1lc3NhZ2Ugb3RoZXJ3aXNlIGltbXV0YWJsZSAobm8gZGVj
b25zdHJ1Y3Rpb24gYW5kIHJlYnVpbGRpbmcsIG90aGVyIHRoYW4gZ3VhcmFudGVlZCB1bmNoYW5n
aW5nKSB0aGF0IHdvdWxkIGhhdmUgdG8gYmUgc3BlY2lmaWVkIGJ5IEFPRFZ2Mi4gKEVhc3kgdG8g
c2F5LCBidXQgbmVlZHMgc2F5aW5nLik8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5XaXRoIHlvdSBzbyBmYXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5UaGVuIHRoYXQgaW5mb3JtYXRpb24gaXMgbm90IGluIGEgZ3VhcmFudGVlZCBm
aXhlZCBsb2NhdGlvbiBnaXZlbiBieSBhIHNpbXBsZSBvZmZzZXQuIFNvIGFueSBzaWduYXR1cmUg
YWxnb3JpdGhtIHRoYXQgZmluZHMgaXQgYW5kIGlnbm9yZXMgaXQgb3IgYWdncmVnYXRlcw0KIG9u
IGl0IGlzIHNwZWNpZmljIHRvIE9MU1J2Mi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3Vy
ZWx5IHlvdSBtZWFuIEFPRFZ2MjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28g
c3RhbmRhcmQgNzE4MiBJQ1ZzIGRvbuKAmXQgZG8gdGhlIGpvYiwgeW91IHdvdWxkIG5lZWQgYW4g
QU9EVnYyIHNwZWNpYWxpc2VkIHZhcmlhbnQuIFdoaWNoIGlzIHRoZSBzb3J0IG9mIHRoaW5nIHRo
YXQgdGhlIG1lc3NhZ2Ugc3BlY2lmaWMgVExWIHNwYWNlIGlzIHRoZXJlDQogZm9yLCBJ4oCZZCBi
ZSBzdHJvbmdseSBhZ2FpbnN0IGEg4oCcYnV0IGlnbm9yZSB0aGUgdmFsdWUgb2YgdGhpcyBzcGVj
aWZpYyBUTFYgc2hvdWxkIGl0IG9jY3Vy4oCdIGJlaW5nIGluIHRoZSBnZW5lcmFsIHNwYWNlLiBI
b3dldmVyIGl0IGNhbiBlYXNpbHkgYmUgZGVmaW5lZCBieSByZWZlcmVuY2UgdG8gNzE4MiAo4oCc
dGhpcyBUTFYgaXMgbGlrZSB0aGF0IFRMViwgZXhjZXB0IGlmIGFuIFggVExWIGlzIHByZXNlbnQs
IHNldCBpdHMgdmFsdWUgZmllbGQgdG8NCiB6ZXJv4oCdKS48L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1lc3N5LCBi
dXQgY291bGQgd29yay48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IHRoYXQgbWVzc3ks
IGFjdHVhbGx5LCBhbHRob3VnaCBjbGVhcmx5IG5vdCBhcyBuaWNlIGFzIOKAnGZpeGVkIG9mZnNl
dOKAnS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBzYWlkLCBJIGFtIGFyZ3Vpbmcg
Zm9yIHRoZSBiYXNlIHNwZWMgYmVpbmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwO+KAnG1ha2UgdGhlIG1lc3NhZ2Ugb3RoZXJ3aXNlIGltbXV0YWJsZSAobm8gZGVj
b25zdHJ1Y3Rpb24gYW5kIHJlYnVpbGRpbmcsIG90aGVyJm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDt0aGFuIGd1YXJhbnRlZWQgdW5jaGFuZ2luZynigJ0gd2hpY2ggaXMgYWZm
b3JkZWQgYnkgZm9yd2FyZGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtSRkM3MTgyIFRpbWVzdGFtcHMgYW5kIElDVnMuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyYjNDM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwO1JGQzcxODMgc3R5bGUgdGV4dCBicmluZ2luZyBpdCBhbGwgdG9nZXRoZXIuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSDigJxhZ2dyZWdhdGVkIHNpZ25hdHVyZXMgYXJvdW5kIG11
dGFibGUgZmllbGTigJ0gd291bGQgdmVyeSBiZSBhbiBleHBlcmltZW50YWwgZXh0ZW5zaW9uLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IEkgb2JqZWN0IHRvIGlzLCBpZiB0aGUgYmFz
ZSBzcGVjIHNwZWNpZmljYWxseSByZW5kZXJzIHN1Y2ggZXh0ZW5zaW9ucyBpbXBvc3NpYmxlPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxi
cj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIElu
dGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOzxhIGhyZWY9InRl
bDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0IiB0YXJnZXQ9Il9ibGFuayI+JiM0Mzs0NCAo
MCkxMjQ1IDI0MjE5NDwvYT4NCiAmbmJzcDt8ICZuYnNwOzxiPkU6Jm5ic3A7PC9iPjxhIGhyZWY9
Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxz
cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9z
cGFuPjwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAw
N0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+
QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQ
YXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJl
Zj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0
eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQg
SW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2Fs
ZXMgTm86IDAxMzM3NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkg
UmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwO0xvdHRlIFN0ZWVuYnJpbmsgWzxhIGhyZWY9
Im1haWx0bzpsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZSIgdGFyZ2V0PSJfYmxhbmsiPjxz
cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxp
bi5kZTwvc3Bhbj48L2E+XSZuYnNwOzxicj4NCjxiPlNlbnQ6PC9iPiZuYnNwOzE3IE1hcmNoIDIw
MTYgMTY6NDg8YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7RGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk8
YnI+DQo8Yj5DYzo8L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5v
cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZXRmQHRob21h
c2NsYXVzZW4ub3JnPC9zcGFuPjwvYT47IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBs
aXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+Jm5ic3A7UmU6IFttYW5ldF0gTWVzc2FnZSBpbnRlZ3Jp
dHkgYW5kIG1lc3NhZ2UgbXV0YWJpbGl0eSAod2FzIFJFOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2
Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKTwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBw
dCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls
ZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i
Y2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8L3Nw
YW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246
Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBv
cmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVy
bmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3
MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hv
dWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPC9z
cGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nPC9z
cGFuPjwvZW0+Jm5ic3A7PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxpPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+Jm5ic3A7PGVtPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50aGF0
DQogeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljazwvc3Bh
bj48L2VtPiZuYnNwOzxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5i
YWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVk
JTIwRmxhZ3MucGRmIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+
aGVyZTwvc3Bhbj48L2E+Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZl
ZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3c8L3NwYW4+PC9lbT4mbmJz
cDs8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5j
b20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRo
JTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i
Y29sb3I6cHVycGxlIj50aGlzDQogcHJvY2Vzczwvc3Bhbj48L2E+Ljwvc3Bhbj48L2VtPjwvc3Bh
bj48L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+QW0gMTcuMDMuMjAxNiB1bSAxNzo0NCBzY2hyaWViIERlYXJsb3Zl
LCBDaHJpc3RvcGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFl
c3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5j
aHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvc3Bhbj48L2E+Jmd0Ozo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Hb29kIHBvaW50IGFib3V0IHdoZXRoZXIgeW91IGp1c3Qg
cGFzcyBvbiBvbmUgY29zdCBvciBhIHNldCBvZiBjb3N0cy4gQXMgSSBzYWlkLCBub3QgbG9va2Vk
IGF0IGRldGFpbHMgLSBJIHdpbGwsIHdoZW4gdGltZSBwZXJtaXRzLiBPbmUgY29zdCBpcyBtdWNo
IGVhc2llciwNCiBhbmQgeWVzLCBpdCByZWR1Y2VzIHRoZSBmaXhlZCBzaXplIGFnZ3JlZ2F0ZWQg
c2lnbmF0dXJlcyBwcm9ibGVtIHRvIOKAnGp1c3TigJ0gb25lIG9mIGNvbXB1dGF0aW9uYWwgbG9h
ZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHRoZSByZWNvcmQsIFRob21hc+KA
mSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3Q7IHRoZSBjb3N0IGlzIG9uZSBhZ2dyZWdhdGVkIHZh
bHVlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5M
b3R0ZSBTdGVlbnJiaW5rPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMwMDdFN0UiPi0tPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQ
cmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBM
YWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOzxhIGhyZWY9InRlbDolMkI0NCUyMCUy
ODAlMjkxMjQ1JTIwMjQyMTk0IiB0YXJnZXQ9Il9ibGFuayI+JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5
NDwvYT4NCiAmbmJzcDt8ICZuYnNwOzxiPkU6Jm5ic3A7PC9iPjxhIGhyZWY9Im1haWx0bzpjaHJp
cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj
b2xvcjpwdXJwbGUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT48YnI+
DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMg
QXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBC
YWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3
dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjoj
M0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs
bGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5v
OiAwMTMzNzQ1MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJy
ZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv
c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8
YSBocmVmPSJtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxz
cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlldGZAdGhvbWFzY2xhdXNlbi5vcmc8L3NwYW4+PC9h
PiZuYnNwO1s8YSBocmVmPSJtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIgdGFyZ2V0PSJf
YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzppZXRmQHRob21hc2NsYXVz
ZW4ub3JnPC9zcGFuPjwvYT5dJm5ic3A7PGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7MTcgTWFyY2gg
MjAxNiAxNjozODxicj4NCjxiPlRvOjwvYj4mbmJzcDtEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVL
KTxicj4NCjxiPkNjOjwvYj4mbmJzcDtNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlz
dDxicj4NCjxiPlN1YmplY3Q6PC9iPiZuYnNwO1JlOiBNZXNzYWdlIGludGVncml0eSBhbmQgbWVz
c2FnZSBtdXRhYmlsaXR5ICh3YXMgUkU6IFttYW5ldF0gZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djIt
MTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcyk8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4w
cHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0
ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFj
a2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcy
Ij4qKiogV0FSTklORyAqKio8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0
b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0
ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFs
IHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJl
ZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0
YWNobWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5m
b3JtYXRpb24gcmVnYXJkaW5nPC9zcGFuPjwvZW0+Jm5ic3A7PC9zcGFuPjwvaT48c3Ryb25nPjxp
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9p
Pjwvc3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+Jm5i
c3A7PGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij50aGF0DQogeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlv
dSByZWNlaXZlLCBjbGljazwvc3Bhbj48L2VtPiZuYnNwOzxlbT48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0i
aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3Bv
dGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g
c3R5bGU9ImNvbG9yOnB1cnBsZSI+aGVyZTwvc3Bhbj48L2E+Ljwvc3Bhbj48L2VtPjxicj4NCjxl
bT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBm
b2xsb3c8L3NwYW4+PC9lbT4mbmJzcDs8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly9pbnRy
YW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9j
dW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiIHRhcmdldD0i
X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50aGlzDQogcHJvY2Vzczwvc3Bhbj48
L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTcgTWFyIDIwMTYsIGF0IDE3
OjMwLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlz
LmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv
bG9yOnB1cnBsZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+SSBhcHByZWNpYXRlIFRob21hc+KAmXMgY29tbWVudHMgYWJvdXQgdGhl
IGxpbWl0YXRpb25zIG9mIG1lc3NhZ2UgcmVnZW5lcmF0aW9uLCBidXQgSSB3b3VsZCBiZSBhIGJp
dCBsZXNzIGFic29sdXRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGlzc3VlcyBvdmVyIGVuZCB0byBl
bmQgYXV0aGVudGljYXRpb24gYW5kIG1vcmUgYWR2YW5jZWQgc2lnbmF0dXJlcyBhcmUgdmFsaWQu
IEkgbmVlZCB0byByZWFkIHRoZSBnaXZlbiByZWZlcmVuY2Ugb24gYWdncmVnYXRlIHNpZ25hdHVy
ZXMgdG8gaW5jcmVhc2UgbXkNCiBrbm93bGVkZ2UgKHRoYW5rcyBmb3IgaXQpLCBidXQgbXkgdW5k
ZXJzdGFuZGluZyBvZiB0aGUgcG9zc2liaWxpdGllcyBpbiB0aGlzIGZpZWxkIG1heSBvZmZlciBh
IHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtLCBidXQgd2l0aCBzb21lIG90aGVyIGlzc3VlcyAocG9z
c2libHkgaW5jbHVkaW5nIGEgbmV3IHR5cGUgb2YgVExWKS48L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCB0
aGUgaG9wIGNvdW50L2xpbWl0IHBvaW50IEkgZG9u4oCZdCBmdWxseSBhZ3JlZSB3aXRoLCB5b3Ug
Y2FuIHJlZ2VuZXJhdGUgd2l0aCBhbiBpbmNyZW1lbnRlZC9kZWNyZW1lbnRlZCBjb3VudC9saW1p
dCwgd2hpY2ggbGVhdmVzIHRoZSBhYmlsaXR5IHRvIHByZXZlbnQNCiBtZXNzYWdlcyBwcm9wYWdh
dGluZyBpbmRlZmluaXRlbHksIGluY2x1ZGluZyBleHBhbmRpbmcgcmluZyBzZWFyY2hlcywgYW5k
IHJldGFpbnMgdGhlIGFiaWxpdHkgdG8gdXNlIFJGQyA1NDk3IGludGVydmFsIGFuZCB2YWxpZGl0
eSB0aW1lcyB0aGF0IG1pZ2h0IGJlIHVzZWZ1bCB3aXRoIGFuIGV4cGFuZGluZyByaW5nIHNlYXJj
aCAob3IgbWlnaHQgbm90KS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCB0aGUga2V5IGlzc3VlIGlzIHRo
YXQgQU9EVnYyIHdhbnRzIHRvIGFjY3VtdWxhdGUgbWV0cmljcy4gSSBzdGlsbCBoYXZlbuKAmXQg
Z290IHRvIHRoZSBib3R0b20gb2YgbWFueSBkZXRhaWxzIGhlcmUsIGJ1dCBsZXTigJlzIGZvciB0
aGUgbW9tZW50IGp1c3QgY29uc2lkZXINCiB0aGF0IGNvbmNlcHR1YWxseS48L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkl04oCZcyBoYXJkIHRvIGhhbmRsZSBlbmQgdG8gZW5kLiBDaGFybGll4oCZcyBkcmFmdCBh
dHRlbXB0cyB0byBkbyBhbiBlbmQgdG8gZW5kIG9mIHNvbWUgaW5mb3JtYXRpb24sIG5vdCB0aGlz
IGluZm9ybWF0aW9uLiBJ4oCZbSBub3Qgc3VyZSBpZiB0aGF04oCZcyB1c2VmdWwgKGFuZCB0aGUN
CiBzcGVjaWFsaXNlZCBmb3JtYXQgaXMgYmV0dGVyIGF2b2lkZWQgaWYgcG9zc2libGUpLiBPdGhl
ciBhcHByb2FjaGVzIGFyZSBob3AgYnkgaG9wIChtaWdodCBhcyB3ZWxsIHVzZSBwYWNrZXQgc2ln
bmF0dXJlcykgYW5kIHNoYXJlZCBrZXkgKG1pZ2h0IGFzIHdlbGwgZ28gaG9wIGJ5IGhvcCkuIFBh
aXJ3aXNlIHNpZ25hdHVyZXMgZm9yIGVhY2ggcGFpciBvZiByb3V0ZXJzIEnigJltIGRpc2NvdW50
aW5nIGFzIHNjYWxpbmcgdGVycmlibHkuIEluIHRoZQ0KIGludGVyZXN0cyBvZiBjb21wbGV0ZW5l
c3MgbGV04oCZcyBtZW50aW9uIG5vdCBhY2N1bXVsYXRpbmcgbWV0cmljcywgd2hpY2ggcHV0cyB1
cyBiYWNrIHRvIGhvcCBjb3VudCBhbmQgdGhhdOKAmXMgbm90IGlkZWFsIGVpdGhlci48L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPkkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhbiBpZGVhbCBzb2x1dGlvbi4gKEkg
bGlrZSBpZGVhcyBJ4oCZdmUgc2VlbiBhYm91dCBhZ2dyZWdhdGluZywgYnV0IHRoYXQgaGFzIHNv
bWUgaXNzdWVzIG9mIGl0cyBvd24sIGV2ZW4gYXBhcnQgZnJvbSBjb21wdXRhdGlvbmFsIGxvYWQu
KQ0KIEnigJlkIGxvdmUgdG8gYmUgcHJvdmVkIHdyb25nIC0gc29tZW9uZSB3aXRoIHRoZSBwZXJm
ZWN0IHNvbHV0aW9uIHRvIGNvbWUgYWxvbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGljaCBtZWFucyB0
aGF0IGVpdGhlciB3ZSBtYWtlIGFuIGFyYml0cmFyeSBjaG9pY2UgLSB3aGljaCB3aWxsIGJlIGRp
c2FncmVlZCB3aXRoLCBidXQgbmVlZHMgZGlzY3Vzc2luZyBmaXJzdCAtIG9yIGNyZWF0ZSBzb21l
dGhpbmcgZmxleGlibGUuIFVuZm9ydHVuYXRlbHkNCiBmbGV4aWJsZSBpbiB0aGF0IHJlZ2FyZCBj
b25zdHJhaW5zIGluIG90aGVycywgZS5nLiBzb21lIChtYW55PyBtb3N0PykgYWdncmVnYXRpbmcg
c2lnbmF0dXJlcyBuZWVkIGZpeGVkIGRhdGEgc2l6ZXMgKHdoaWNoIHdlIGNhbiBkbyBieSBkZWZp
bmluZyBhIFRMViB0aGF0IOKAnGZpbGxzIHVw4oCdIHdpdGggaG9wIGNvdW50LCBidXQgdGhhdCBo
YXMgYSBjb3N0IHRvbykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SSBoYXZlIGJlZW4gdG9sZCBieSBwZW9wbGUgbXVjaCBtb3JlIHdlbGwgdmVy
c2VkIGluIHRoaXMgdGhhbiBJIGluIGNyeXB0b2xvZ3ksIHRoYXQgdGhlIGNvcnJlY3QgYW5zd2Vy
IGlzIOKAnHNvbWXigJ0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgc2FpZCwg
JnF1b3Q7QU9EVnYyIHdhbnRzIHRvIGFjY3VtdWxhdGUgbWV0cmljc+KAnSDigJQgZG9lcyB0aGF0
IG1lYW4gdGhhdCB0aGUgbWVzc2FnZSBncm93cyBhcyBpdCBpcyBiZWluZyBmb3J3YXJkZWQsIGFu
ZCB0aGF0IHRoZSByZWNpcGllbnQgb2YgYSBSUkVRL1JSRVAgd2lsbCBrbm93IHRoZSBpbmRpdmlk
dWFsIGNvc3RzIG9mIGVhY2ggcGF0aCBzZWdtZW50PyBNeSB1bmRlcnN0YW5kaW5nIGlzLCB0aGF0
IHRoZSByZWNpcGllbnQNCiB3aWxsIGdldCDigJx0aGUgc3VtIHRoZSBjb3N0cyBvZiBlYWNoIHBh
dGggc2VnbWVudOKAnSB3aGljaCBzaG91bGQgYmUgZml0dGluZyB3aXRoaW4gYSBmaXhlZCBzaXpl
PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaG9tYXM8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8YnI+
DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5Tb3JyeSwgbm8gYW5zd2VycywganVzdCBjb21tZW50cy4gQW5kIEnigJltIG5v
dCBhZGRyZXNzaW5nIFRob21hc+KAmXMgbGF0ZXIgcG9pbnRzIGhlcmUuPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMDA3RTdFIj4tLTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJp
bmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFi
b3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgw
JTI5MTI0NSUyMDI0MjE5NCIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8
L2E+DQogJm5ic3A7fCAmbmJzcDs8Yj5FOiZuYnNwOzwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMu
ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s
b3I6cHVycGxlIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvc3Bhbj48L2E+PGJyPg0K
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFw
cGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFk
ZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cu
YmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzNB
OEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQg
SW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2Fs
ZXMgTm86IDAxMzM3NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox
Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVk
IE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQ
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6
c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwO21hbmV0IFs8YSBocmVmPSJtYWlsdG86
bWFuZXQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPm1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dJm5ic3A7
PGI+T24NCiBCZWhhbGYgT2YmbmJzcDs8L2I+PGEgaHJlZj0ibWFpbHRvOmlldGZAdGhvbWFzY2xh
dXNlbi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZXRm
QHRob21hc2NsYXVzZW4ub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TZW50OjwvYj4mbmJzcDsxNyBN
YXJjaCAyMDE2IDE2OjAwPGJyPg0KPGI+VG86PC9iPiZuYnNwO01vYmlsZSBBZCBIb2MgTmV0d29y
a3MgbWFpbGluZyBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+Jm5ic3A7W21hbmV0XSBkcmFmdC1p
ZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1z
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAy
LjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz
dHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln
bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8
L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxp
Z246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91
ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGlu
dGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMz
Mzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ug
c2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHku
PC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5n
PC9zcGFuPjwvZW0+Jm5ic3A7PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxpPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+Jm5ic3A7PGVtPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50
aGF0DQogeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljazwv
c3Bhbj48L2VtPiZuYnNwOzxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVu
dC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMv
UmVkJTIwRmxhZ3MucGRmIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs
ZSI+aGVyZTwvc3Bhbj48L2E+Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91
IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3c8L3NwYW4+PC9lbT4m
bmJzcDs8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVt
cy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBX
aXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls
ZT0iY29sb3I6cHVycGxlIj50aGlzDQogcHJvY2Vzczwvc3Bhbj48L2E+Ljwvc3Bhbj48L2VtPjwv
c3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MS4wcHQgNC4wcHQgMS4w
cHQgNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRl
eHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPioqPC9zcGFuPjwv
c3Ryb25nPjxiPiZuYnNwOzwvYj48L3NwYW4+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij5XQVJOSU5HPC9zcGFuPjwvc3Ryb25nPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PiZuYnNwOzwvc3Bhbj48L2I+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KioqPC9zcGFuPjwvc3Ryb25nPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0
c2lkZSBvdXIgb3JnYW5pemF0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ljwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFwb2xvZ2llcyBmb3Igbm90IGhhdmluZyBnb3R0ZW4g
dGhpcyBkb25lIHNvb25lciAtIGRheS1qb2IgbGVhdmluZyBmZXcgc3BhcmUgY3ljbGVzLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
4oCZdmUgcHJldmlvdXNseSBvZmZlcmVkIHJldmlld3MgYW5kIGNvbW1lbnRzLCBhbmQgc29tZSBv
ZiB0aG9zZSBoYXZlIGJlZW4gYWRkcmVzc2VkIGluIHRoZSBsYXRlc3QgSS1EIOKAlCBvdGhlcnMg
aGF2ZSBub3QsIGJ1dCBzaG91bGQgYmUuIEkgcmVjYWxsIHRoYXQgdGhlcmUgd2FzIHNvbWUgbWFp
bCBhdHRlbXB0aW5nIHRvIHJlYnV0IHBhcnRzIG9mIHRoZSByZXZpZXcsIGFuZCBJIHdpbGwgZGln
IGl0IG91dCBhbmQNCiByZXBseSB0byB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIHRoYXQgYmVpbmcgc2FpZCwgSSBo
YXZlIHJldmlld2VkIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQsIGFuZCBmdWxs
IGRldGFpbHMgd2lsbCBiZSBmb3J0aGNvbWluZy4gVGhlcmXigJlyZSBhIGNvdXBsZSBvZiBiaWct
dGlja2V0L2FyY2hpdGVjdHVyYWwgaXRlbXMgdGhhdCBJIHdhbnQgdG8gYWRkcmVzcyB1cCBmcm9u
dCwgYXMgSSBiZWxpZXZlIHRoYXQgYmVmb3JlIHdlIGhhdmUgdGhvc2UNCiBoYW1tZXJlZCBvdXQs
IGl0IHdpbGwgYmUgdXNlbGVzcyB0byBnbyBpbnRvIGRldGFpbHMuIE5vdGUsIEkgZG8gbm90IGNs
YWltIHRoYXQgdGhpcyBpcyBhbiBleGhhdXN0aXZlIGxpc3Qgb2Yg4oCcYmlnIHRpY2tldCBpdGVt
c+KAnSwgYnV0IHRoYXTigJlzIGFzIGZhciBhcyBJIGhhdmUgZ290dGVuIGluIHRoaW5raW5nIHRo
aXMgdGhyb3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SSBhbHNvIGJyaW5nIHRoZXNlIHVwIGFzIHRoZXkgYXJlIGl0ZW1zIHRo
YXQgaGF2ZSBiZWVuIGJyb3VnaHQgdXAgcmVwZWF0ZWRseSBvdmVyIHRoZSBwYXN0IHllYXJzLCBi
dXQgbm90IHJlc29sdmVkIG5vciBkaXNjdXNzZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjx1Pkxvb3BzPC91PjwvYj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3Qg
dG8gYnJpbmcgdGhpcyBvdXQ6IEkgc2hhcmUgQ2hyaXPigJkgd29ycnkgYWJvdXQgY29uZmxpY3Rp
bmcgYW5kIGNvbmN1cnJlbnQgc3RhdGVtZW50cyBmcm9tIHRoZSBhdXRob3JzIG9uIOKAnFRoZXJl
IGFyZSBubyBsb29wcyBwb3NzaWJsZeKAnSBhbmQg4oCcV2UgbmVlZCB0byBmaXggdHdvIHNpdHVh
dGlvbnMgd2hlcmUgbG9vcHMgY2FuIG9jY3Vy4oCdIGFuZCDigJx3ZSBhcmUgc3RpbGwgaW52ZXN0
aWdhdGluZyBzb21lIGxvb3ANCiBjb25kaXRpb25z4oCdPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcGFydGljdWxhcmx5IHdvcnJ5
IHRoYXQgdGhpcyBpcyBub3QgYSBkaXNjdXNzaW9uIGhhZCBpbiBwdWJsaWMsIGJ1dCBhcHBhcmVu
dGx5IGluIHNvbWUgb3RoZXIgZm9ydW3igKY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHU+SW50ZXJtZWRp
YXRlIFJvdXRlIFJlcGxpZXMsIGFuZCBhbGwgb2Ygc2VjdGlvbiAxMDwvdT48L2I+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDEw
IGNvbnRhaW5zIGEgc2V0IG9mIOKAnHZhZ3VlbHkgc3BlY2lmaWVkIGV4dGVuc2lvbnPigJ0sIHdo
aWNoIGlzIGluY29oZXJlbnQgd2l0aCB0aGUgaW50ZW5kZWQgc3RhdHVzIGluZGljYXRlZCBmb3Ig
dGhpcyBkb2N1bWVudC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3BlY2lmaWNhbGx5LCBhbmQgdGhpcyBpcyBub3QgdW5y
ZWxhdGVkIHRvIHRoZSBwb2ludCBhYm91dCBsb29wcyBhYm92ZSwgaW50ZXJtZWRpYXRlIFJSRVBz
IChzZWN0aW9uIDEwLjMpIGFyZSBhIHBvdGVudGlhbCBzb3VyY2UgZm9yIGxvb3BzLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FeHBh
bmRpbmcgUmluZyBNdWx0aWNhc3QgKHNlY3Rpb24gMTAuMSkgaXMgbm90IGRvY3VtZW50ZWQgaW4g
YSB3YXkgdGhhdCBjYW4gYmUgaW1wbGVtZW50ZWQgKGFuZCBhbHNvLCBzZWUg4oCcRm9yd2FyZGlu
Zy12cy1yZWdlbmVyYXRpb27igJ0gYmVsb3csIGl0IGlzIGluIHRoZSBwcmVzZW50IGZvcm0gb2Yg
dGhpcyBwcm90b2NvbCBpbXBvc3NpYmxlKSwgZXRjLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHU+Rm9y
d2FyZGluZy12cy1yZWdlbmVyYXRpb248L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVjZW50IGV4Y2hhbmdlcyBvbiB0aGUgbGlz
dCBtYWRlIG1lIHVuZGVyc3RhbmQgdGhhdCBwcm90b2NvbCBjb250cm9sIG1lc3NhZ2VzIGFyZSAq
bm90KiBmb3J3YXJkZWQsIGJ1dCBhcmUgY29uc3VtZWQgYXQgZWFjaCBob3AsIHRoZW4gYSBuZXcg
bWVzc2FnZSB3aXRoIChhbG1vc3QtYnV0LW5vdC1xdWl0ZSkgdGhlIHNhbWUgY29udGVudCBpcyBn
ZW5lcmF0ZWQgYW5kIHRyYW5zbWl0dGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgdGhvdWdodCBzb21lIG1vcmUgb24g
dGhpcyAoJmFtcDsgcmVhZCBzb21lIG9mIHRoZSBleGNoYW5nZXMgb24gdGhlIGxpc3Qgb24gdGhp
cyB0b3BpYyBieSBDaHJpcywgVWxyaWNoLCBhbmQgb3RoZXJzKSwgYW5kIEkgYW0gY29udmluY2Vk
IHRoYXQgdGhpcyBpcyBub3QgdGhlIHJpZ2h0IHdheSB0byBnbywmbmJzcDs8Yj5hdCBsZWFzdDwv
Yj4mbmJzcDtmb3IgdGhlIGZvbGxvd2luZyByZWFzb25zOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
O28mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDs8Yj5JdCByZW5kZXJzIHRoZSBob3AtbGltaXQvaG9wLWNvdW50IGZpZWxkcyBpbiB0aGUg
UkZDNTQ0NCBtZXNzYWdlIGhlYWRlciB1c2VsZXNzLjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO1RoaXMgd291bGQgbm90IGJlIGJhZCBpZiB0aGUgZnVuY3Rpb25hbGl0eSBvZmZlcmVk
IGJ5IHRob3NlIGZpZWxkcyB3YXMgbm90IHVzZWZ1bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A74oCUIHNhZGx5LCBpdCBpcy4gRm9yIGV4YW1wbGUsIGZvciBzY29wZSBsaW1pdGVkIGZsb29k
aW5nIChleHBhbmRpbmcgcmluZyBzZWFyY2gsIGFuZCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7c3VjaCkgd2hpY2ggbWF5IGJlIG9mIGludGVyZXN0LCBhbmQgd2hpY2ggcmVxdWly
ZSBob3AtbGltaXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBIGhvcC1jb3Vu
dCBmaWVsZCBtYXkgYWxzbyBwcm92aWRlIGEg4oCcY2hlYXDigJ0gKGluIHRlcm1zIG9mIG92ZXJo
ZWFkKSBhZGRpdGlvbmFsIHBpZWNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvZiBpbmZv
cm1hdGlvbiB0byB1c2UgY29uanVuY3RpdmVseSB3aXRoIGEg4oCccmVhbOKAnSBtZXRyaWMuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSBvbmx5IHByYWN0aWNhbCBzb2x1dGlv
biB3b3VsZCBiZSB0byByZS1pbnRyb2R1Y2UgdGhlc2UgZnVuY3Rpb25zIGJ5IHdheSBvZiBpbnNl
cnRpbmcgYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TWVzc2FnZVRMViDigJQgd2hpY2gg
KGkpIGlzIG5vdCBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCwgYW5kIChpaSkgd2hpY2ggd291
bGQganVzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c2VydmUgdG8gcmVuZGVyIG1lc3Nh
Z2VzIGJpZ2dlciB0aGFuIHN0cmljdGx5IG5lZWRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7U2NvcGUgbGltaXRlZCBmbG9vZGluZyAmbmJzcDtkb2VzIHNlZW0gdG8gYmUgYSBu
ZWNlc3NhcnkgcmVxdWlyZW1lbnQsIGlmIGZvciBubzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7b3RoZXIgcmVhc29uIHRoYW4gdG8gcHJldmVudCBpbmZvcm1hdGlvbiBmcm9tIOKAnGNpcmN1
bGF0aW5nIGZvcmV2ZXIgaW4gdGhlIG5ldHdvcmvigJ0uPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO28mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8
Yj48dT5JdCBtYWtlcyBlbmQtdG8tZW5kIGF1dGhlbnRpY2F0aW9uIHVubmVjZXNzYXJpbHkgaGFy
ZC48L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SSB0aGluayBDaHJpcyBjYWxs
ZWQgdGhpcyBvdXQgYWxyZWFkeSwgYnV0IGl0IGJlYXJzIHJlcGVhdGluZzogUyBnZW5lcmF0ZXMg
YSBtZXNzYWdlJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsoc2F5LCBhIFJSRVEp
LCBhbmQgaW5jbHVkZXMgYW4gSUNWIGNhbGN1bGF0ZWQgb3ZlciB0aGUgY29udGVudCBvZiB0aGUg
bWVzc2FnZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0ZvciBhbnkgcmVjaXBpZW50IHRv
IGJlIGFibGUgdG8gdmFsaWRhdGUgdGhlIElDViwgdGhlIG1lc3NhZ2UgaGFzIHRvIGJlIGV4YWN0
bHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoZSBzYW1lIOKAlCBub3QganVzdCBpbiBj
b250ZW50LCBidXQgaW4gc3RydWN0dXJlIOKAlCBhcyB3aGF0IHdhcyBnZW5lcmF0ZWQuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO+KAnFJlZ2VuZXJhdGluZ+KAnSByYXRoZXIgdGhh
biDigJxmb3J3YXJkaW5n4oCdIG1lc3NhZ2VzIG1lYW5zLCB0aGF0IHRoZSBpbnRlcm1lZGlhdGU8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JvdXRlciDigJxyZWdlbmVyYXRpbmfigJ0gdGhl
IFJSRVEgbWF5IGNob3NlIGEgZGlmZmVyZW50IHN0cnVjdHVyZSAoZS5nLiwgaW5jbHVkZSBUTFZz
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpbiBhIGRpZmZlcmVudCBvcmRlcikuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSBwcm9wb3NhbCBmcm9tJm5ic3A7PGEgaHJl
Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlcmtpbnMtbWFuZXQtYW9kdi1l
MmVzZWMtMDAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0w
MDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpcyB0byBhZGQgY29uc3Ry
YWludHMgb24gKGkpIHRoZSBzZXQgb2YgZWxlbWVudHMgdG8gaW5jbHVkZSBpbiBhIHNpZ25hdHVy
ZSBhbmQgKGlpKSB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO29yZGVyIG9mIHRoZXNl
IGVsZW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtPbmUmbmJzcDtwcm9i
bGVtIHdpdGggdGhhdCBhcHByb2FjaCBpcyAoaSk6IGlmIGFuIGV4dGVuc2lvbiBhZGRzIGEgbWVz
c2FnZSBUTFYsIG9yIGFuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBZGRyZXNz
IFRMViwgdG8gYSBtZXNzYWdlLCB0aGVuIHRoYXQgd2lsbCBub3QgYmUg4oCcY292ZXJlZOKAnSBi
eSB0aGUgcHJvcG9zZWQgZTJlc2VjIFRMVi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1Jh
dGhlciBmb3IgKmVhY2gqIGV4dGVuc2lvbiBkZXZlbG9wZWQsIGFuIOKAnHVwZGF0ZXMgZTJlc2Vj
4oCdIGNsYXVzZSBuZWVkcyB0byBiZSBkb25lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDtJ4oCZZCBzYXkgdGhhdCB0aGlzIGFwcHJvYWNoIHdvdWxkIGJlIHByb25lIHRvIGVycm9y
cyDigJQgYW5kIGFkZCBlbnRyb3B5IHRvIHRoZSBwcm9jZXNzPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDtvZiBkZXNpZ25pbmcgcHJvdG9jb2wgZXh0ZW5zaW9ucy4gVGhlIGFsdGVybmF0aXZl
LCBhIG1lc3NhZ2UgYmVpbmcgZ2VuZXJhdGVkIGJ5IHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7c291cmNlIGFuZCAqZm9yd2FyZGVkKiAoYXMgd2UgZG8gaW4gT0xTUnYyLCBmb3IgZXhh
bXBsZSkgd291bGQgYWxsb3cgSUNWIFRMVnMmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyhldmVuLCBhbGxvdyByZXVzZSBvZiB0aG9zZSBzcGVjaWZpZWQgZm9yIE9MU1J2MikgZm9y
IGNvdmVyaW5nIGEgbWVzc2FnZSBhbmQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
O2V4dGVuc2lvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO+KAnEJ1dCB3aGF0
IGFib3V0IHRoZSBtZXRyaWNzIHZhbHVlIHdoaWNoIHdpbGwgY2hhbmdlIG9uIGVhY2ggaG9w4oCd
LCB5b3UgbWF5IHNheT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0ZvcnR1bmF0ZWx5LCB0
aGF0IGlzIHJlbGF0aXZlbHkgZWFzeSB0byBoYW5kbGU6IHNpbXBseSB6ZXJvIG91dCB0aGUgdmFs
dWUgb2YgdGhhdCBUTFYgd2hlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Z2VuZXJhdGlu
ZyBvciB2ZXJpZnlpbmcgdGhlIElDViBNZXNzYWdlVExWLiBBbmQgdXNlIFBhY2tldC1UTFZzIGZv
ciBob3AtYnktaG9wJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthdXRoZW50aWNh
dGlvbiwgaWYgbmVlZGVkIChidXQsIHNlZSBiZWxvdykuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO28mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8
Yj48dT5JdCBwcmV2ZW50cyB0aGUgdXNlIG9mIG1vcmUgY2xldmVyL2FkdmFuY2VkIHNpZ25hdHVy
ZSBzY2hlbWVzL0lDVnM8L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QWdncmVn
YXRlIHNpZ25hdHVyZSBhbGdvcml0aG1zICgmbmJzcDs8YSBocmVmPSJodHRwczovL2NyeXB0by5z
dGFuZm9yZC5lZHUvfmRhYm8vcGFwZXJzL2FnZ3N1cnZleS5wZGYiIHRhcmdldD0iX2JsYW5rIj48
c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2NyeXB0by5zdGFuZm9yZC5lZHUvfmRh
Ym8vcGFwZXJzL2FnZ3N1cnZleS5wZGY8L3NwYW4+PC9hPik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO2V4aXN0LCBhbmQgYW4gaW50ZXJlc3RpbmcgdXNlLWNhc2UgY2FuIGJlIGZvdW5kIGlu
IGFsc28gcmVhY3RpdmUgcHJvdG9jb2xzLCBhbGxvd2luZyB2ZXJpZnlpbmc8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO25vdCDigJxqdXN04oCdIHRoZSBlbmQgcG9pbnRzLCBidXQgYWxzbyB0
aGUgaW50ZXJtZWRpYXJpZXMgKGFnYWluLCB3aXRoIHRoZSBhcHByb3ByaWF0ZSDigJx6ZXJvIG91
dOKAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZGlzY3Vzc2VkIGFib3ZlLCBvciBzb21l
dGhpbmcgc21hcnRlcikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtSZWdlbmVyYXRpb24g
b2YgbWVzc2FnZXMsIHJhdGhlciB0aGFuIGZvcndhcmRpbmcsIHJlbmRlcnMgdGhhdCBpbXBvc3Np
YmxlIChvciwgaWYgdXNlZCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3VwZGF0aW5nIHRv
ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wZXJraW5z
LW1hbmV0LWFvZHYtZTJlc2VjLTAwIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y
OnB1cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlcmtpbnMtbWFuZXQt
YW9kdi1lMmVzZWMtMDA8L3NwYW4+PC9hPik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIG90aGVyIHJlYXNvbnMsIGJ1
dCB0aGUgYWJvdmUgYXJlIHRob3NlIHRoYXQganVtcCBhdCBtZSBhcyBpbW1lZGlhdGUgc2hvdy1z
dG9wcGVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SSBkbyBob25lc3RseSBub3Qgc2VlIHdoYXQgcG9zc2libGUgYmVuZWZpdCB0
aGVyZSBpcyBmcm9tIOKAnHJlZ2VuZXJhdGlvbuKAnSDigJQgYnV0IEkgc2VlIHZlcnkgY2xlYXIg
aW5jb252ZW5pZW5jZXMsIGFuZCBzZWN1cml0eSBpcyBub3QgdGhlIGxlYXN0IG9mIHRoZXNlLiBJ
bnNpc3Rpbmcgb24g4oCccmVnZW5lcmF0aW9u4oCdIHJlcXVpcmVzIGRldmVsb3BtZW50IG9mIOKA
nG5vbi1nZW5lcmFsIHdvcmthcm91bmRz4oCdIGFzIHBvaW50ZWQNCiBvdXQgYWJvdmUuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
Pjx1PlNlY3VyaXR5IENvbnNpZGVyYXRpb25zPC91PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgYW4gYWx3YXlzIHRob3Ju
eSBzdWJqZWN0LiBXaGVuIE9MU1J2MiB3YXMgZ29pbmcgdGhyb3VnaCB0aGUgcHJvY2VzcyB3ZSBn
b3QgYSB0aG9yb3VnaCBlZHVjYXRpb24gaW4gaG93IGxpdHRsZSB3ZSBrbmV3IGFib3V0IHNlY3Vy
aXR5IGZyb20gdGhlIFNFQy1BRHMsIGFuZCBoYWQgdG8gc3BlbmQgYWJvdXQgYSB5ZWFyIG9yIHNv
IGRldmVsb3BpbmcgUkZDNzE4My4gVGhlIGJvdHRvbSBsaW5lIGlzLCB0aGF0DQogdGhpcyBwcm90
b2NvbCBuZWVkcyBpdHMg4oCcUkZDNzE4MyAmbmJzcDtlcXVpdmFsZW504oCdLCBlaXRoZXIgYXMg
cGFydCBvZiB0aGUgbWFpbiBkb2N1bWVudCwgb3IgYXMgYW4gaW5kZXBlbmRlbnQgZG9jdW1lbnQu
IGN1cnJlbnRseSwgdGhhdCBpcyBub3QgdGhlIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgbWluaW1hLCBsb29raW5nIGF0
IEJDUDcyIGFuZCBCQ1AxMDcg4oCUIHRha2luZyBpbnNwaXJhdGlvbiBmcm9tIFJGQzcxODMgbWln
aHQgYmUgYXcgZ29vZCBpZGVhLCBhcyB0aGF0IHdhcyB0aGUgbW9zdCByZWNlbnQgdGhhdCB3ZW50
IHRocm91Z2ggdGhlIFNFQyBBRC4gUmVnYXJkbGVzcyBvZiBob3csIGhvd2V2ZXIsIGEg4oCcbWFu
ZGF0b3J5IHRvIGltcGxlbWVudOKAnSBzZWN1cml0eSBtZWNoYW5pc20gbW9zdCBiZSBzcGVjaWZp
ZWQNCiAoSSB0aGluayB0aGUgcmlnaHQgdGVybSB3YXMg4oCcTVVTVCBpbXBsZW1lbnQsIFNIT1VM
RCB1c2XigJ0pLCBpbiBzdWZmaWNpZW50IGRldGFpbCB0byBlbnN1cmUgaW50ZXJvcGVyYWJsZSBp
bXBsZW1lbnRhdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkFzIGFuIGV4YW1wbGUsIGJvdGggW1JGQzYxMzBdIGFuZCBbUkZD
NzE4MV0gc2V0IG91dCB0aGF0IHRoYXQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBP
biByZWNlaXZpbmcgYSAuLi4gbWVzc2FnZSwgYSByb3V0ZXIgTVVTVCBmaXJzdCBjaGVjayBpZiB0
aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOyAmbmJzcDsgJm5ic3A7IG1lc3NhZ2UgaXMgaW52YWxpZCBmb3IgcHJvY2Vzc2luZyBi
eSB0aGlzIHJvdXRlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5hbmQgdGhlbiBwcm9jZWVkIHRvIGdpdmUgYSBudW1iZXIgb2YgY29u
ZGl0aW9ucyB0aGF0LCBlYWNoLCB3aWxsIGxlYWQgdG8gYSByZWplY3Rpb24gb2YgdGhlIG1lc3Nh
Z2UgYXMgJnF1b3Q7YmFkbHkgZm9ybWVkIGFuZCB0aGVyZWZvcmUgaW52YWxpZCBmb3IgcHJvY2Vz
c2luZ+KAnSDigJQgYSBsaXN0IHdoaWNoIFJGQzcxODMgdGhlbiBhbWVuZGVkLiBUaGF0IGdhdmUg
YSDigJxob29r4oCdIGZvciBSRkM3MTgzIGZvciBpbnNlcnRpbmcNCiDigJxyZWplY3Rpb27igJ0u
IElkZW0gZm9yIG1lc3NhZ2UgZ2VuZXJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgSSB3YXMgdG8gZG8gUkZDNzE4MS9S
RkM2MTMwIHRvZGF5LCBJIHdvdWxkIGluY2x1ZGUgdGhhdCBkaXJlY3RseSBpbnRvIHRoZSBwcm90
b2NvbCBzcGVjaWZpY2F0aW9ucy4gSXQgdHVybmVkIG91dCB0byBiZSBtb3JlIG92ZXJoZWFkIChh
bmQgc2xvdyBkb3duIHB1YmxpY2F0aW9uIGFueXdheXMpIHRvIGRvIGl0IGFzIHNlcGFyYXRlIGRv
Y3VtZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWNvbmRseSwgd2UgbmVlZCB0byBiZSBhIGxvdCBtb3JlIHJp
Z2lkIGluIHRlcm1zIG9mIHdoYXQgSUNWcywgVGltZXN0YW1wcywgZXRjLiBhcmUgYWRkZWQvcmVt
b3ZlZCwgYW5kIHdoYXQgdGhhdCBicmluZ3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBleGFtcGxlICh3aXRoIHRoZSBhc3N1
bXB0aW9uIHRoYXQgbWVzc2FnZXMgYXJlICpmb3J3YXJkZWQqIGFuZCAqbm90KiByZWdlbmVyYXRl
ZCksIHRoaXMgY291bGQgYmUgb25lIG9wdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7byZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwO1doZW4gYSBSUkVRLCBSUkVQIG1lc3NhZ2UgaXMgZ2VuZXJhdGVkLCBhZGQgYW4g
SUNWIE1lc3NhZ2UgVExWLCB3aGljaCBpcyBjYWxjdWxhdGVkICZsdDt0aGlzIHdheSZndDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO+KApih0YWtlIGlu
c3BpcmF0aW9uIGZyb20gUkZDNzE4MyBoZXJlKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4u
Li48YnI+DQo8YnI+DQpbTWVzc2FnZSBjbGlwcGVkXSZuYnNwOyZuYnNwOzxicj4NCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGlu
ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu
ayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBs
aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cD4q
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKjxicj4KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRl
bnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZp
bGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IHBsZWFzZSBk
ZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPgpZb3Ug
c2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3Nl
IG9yPGJyPgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4K
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKio8L3A+PC9ib2R5Pg0KPC9odG1sPg0K

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B12C9GLKXM0002VGREEN_--


From nobody Mon Apr 25 05:04: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 5860412D1AB for ; Mon, 25 Apr 2016 05:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.093
X-Spam-Level: 
X-Spam-Status: No, score=-1.093 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, TRACKER_ID=1.306] 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 9lsLOUgvonqG for ; Mon, 25 Apr 2016 05:04:20 -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 88CA212D15B for ; Mon, 25 Apr 2016 05:04:19 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id v188so95174055wme.1 for ; Mon, 25 Apr 2016 05:04:19 -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=bV6ze0qsR/Q/jPaCSjgNos8ksNncozmFQaw45UCoep0=; b=lcH1fvj5x4dId1MnkK9VbL1JIwL6Js5+sZhRmIC0CUnI36XRVa6m2nzE9cQ/Qiwy9m 2eyE64UIsTyaka46b1Hvpl+N9ZtTlrZ4Hj7J2Vk/a5pkhTE7EkfR8GAuZhQngfOq6n9j BZsaWZoqYZZmh2S74g6lIe4/znmaxyOByoecwBpUWQ62WhiiNIXiE2Izfktq4h/zds10 EL9dc12ihibVS8IHsUBUqGwCyo4ZY018+dEdtVKnqk1a9hGp7FQMQ9oEEr5xNE+zYvnN EBq2vfkgpb7Hty/giUkjmSal6BpkHPAf8l0RUOAr15rY+eCgGH5fwEL51VZrN/uLfTMc Yq3A==
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=bV6ze0qsR/Q/jPaCSjgNos8ksNncozmFQaw45UCoep0=; b=ijg7vAhmN0zoY7ghap7nFApK8MJiNouibHlMWZNuJRTPJGjoDMmu8sCCcKX30UC1DV XHfgMuEJgCQnl1qzqjlROjuzaPXJgwjESTkRUl6qtxA6PLd2mKhzx8Y9bR8QJkSZ7ySF oG/w2NY6f3PM9rhVEzM2X25uapTz85WWLbEGrMLwTDrHqVRToT58nF5eig6FYK3ylIrt SVf0rK1FzP1h1kw8kzajzyYjGlKbT2RRRrnGBPgOXDRGfqhUsxUt2Ya4vSm9SolNX8lN l0g0Bhbhjqo0IBqbvGYp02/Zf9zmdqfmVXZnGyosFlJ9RCoo/PWjk2KoiK7F8nNq3ggC gxkA==
X-Gm-Message-State: AOPr4FWITxu3FyZ2cpcssjXgLFZeNK53xBu12I0u3cYlcL6eOeFOgMuaP9wD4VY75VIqgxG8GiQoJy7vQDUj8w==
MIME-Version: 1.0
X-Received: by 10.28.128.143 with SMTP id b137mr11380118wmd.57.1461585857967;  Mon, 25 Apr 2016 05:04:17 -0700 (PDT)
Sender: yi.jiazi@gmail.com
Received: by 10.194.153.166 with HTTP; Mon, 25 Apr 2016 05:04:17 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>    
Date: Mon, 25 Apr 2016 14:04:17 +0200
X-Google-Sender-Auth: yv4tGLCq9BsvrVffPkpl7OF2xsE
Message-ID: 
From: Jiazi YI 
To: Victoria Mercieca ,  "Dearlove, Christopher (UK)" 
Content-Type: multipart/alternative; boundary=001a1141e52cdf7f8105314df92e
Archived-At: 
Cc: Christopher Dearlove , Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 12:04:26 -0000

--001a1141e52cdf7f8105314df92e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
chris.dearlove@baesystems.com> wrote:

> With regard to your validity time point, we here have a tradeoff. If you
> allow that feature, it significantly impacts on the approach that was
> coming together on as best you can end to end encryption.
>
>
>
> So the question is, is this a feature that=E2=80=99s really wanted? Unfor=
tunately
> I think we know that the answer to that is, we don=E2=80=99t know because=
 we don=E2=80=99t
> have any experience. My view would be that in the tradeoff of an untested
> feature (unless I=E2=80=99m wrong about that) and the security complicati=
on,
> security wins and drop the feature. If there is some real requirement, th=
en
> there=E2=80=99s a discussion. (Questions like how often the intermediate =
routers
> actually have any knowledge - typically links break for unexpected rather
> than expected reasons. Andan intermediate router could possibly use a
> validity time to influence its behaviour.) Note that dropping the ability
> of intermediate routers to modify/set still allows validity times per rou=
te
> to be set at endpoints.
>

I agree with Chris' concern.
The ValidityTime is optional, which makes the integrity protection hard.
Furthermore, it gives a potential attack vector: as all the routers in a
path will take the shortest validityTime, a compromised router can set the
the validityTime to a very short value, which will make the route installed
along the path became invalid (very soon).

On the other hand, I'm not sure this option will give us much help. Chris
mentioned much knowledge intermediate router would have to decide this
value (and how much sense the value would make).
Another issue is, a route to a destination might be updated by different
sources. For example, in the network below:

A----B-----C

A first establish a route to B with long validity time. Then A initiates a
route discovery to C. C tends to set a short validity time, which will make
the route between B and A expire earlier than expected.
Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered or
not.


>
>
> With regard to the acknowledgements, the problem (with regard to security=
)
> comes from trying to do two jobs with the same message - end to end route
> advertisement and hop by hop acknowledgement. I understand the reasons -
> saving bytes and message types. (I would have to study the protocol reall=
y
> hard to identify if any message types can be folded together and recognis=
ed
> by content rather than type efficiently. This I do not expect to do.) Aga=
in
> a tradeoff. This one is in discussion space, though that needs people who
> understand both sides of the issue, including the details of the
> bidirectionality mechanism. Of course, as has been said, we need one of
> those.
>

I haven't finished my review of the latest draft, and I don't get the
necessity of AckReq and the corresponding multicast RREP yet.
If possible, this "optional" field should be avoided.

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
>
>
>
> *From:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
> *Sent:* 23 April 2016 10:55
> *To:* Christopher Dearlove
> *Cc:* ietf@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc
> Networks mailing list
>
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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
> .*
>
> Hi Chris,
>
>
>
> These have both been in the draft in some form since before I got
> involved... but I'll do my best to explain.
>
>
>
> - For Validity Time, its a way to advertise that you would only support
> the route contained in the message for a certain period of time. The
> originator might use this, but the draft was written to allow any
> intermediate node to be able to add it or update it too. The route create=
d
> in the Local Route Set has an expiration time associated with it, based o=
n
> the received validity time.
>
> - For the AckReq address, its so that you can add into a RREP a request
> for an acknowledgement, so that you don't have to have a different messag=
e
> type altogether for working out whether links to neighbors are
> bidirectional, and also, since you only care about bidirectionality on
> routes that are being set up, you dont need to constantly monitor all
> neighbors.
>
>
>
>
>
> In order to avoid the potential AckReq-related changes to each message,
> maybe we do need to introduce a different message specifically for this. =
We
> could maybe use RREP_Ack to both request and acknowledge? It means an ext=
ra
> message of control traffic that needs to be sent, maybe one extra message
> per hop on the path of a RREP, but it could still be limited to neighbors
> which have participated in the route discovery rather than monitoring all
> neighbors at all times.
>
>
>
> This message could maybe also include "I'm happy to route anywhere for a
> certain amount of time", sort of like willingness in OLSR/OLSRv2. So
> instead of having a validity time per route, its a validity time per
> neighbor. Then, for RREQ and RREP, only the metric value would change in
> transit, as discussed. However, that leads to some issues with deciding
> what a route's expiration time is. You might know how long the next hop
> router is valid for, but what if a router beyond that, which was also par=
t
> of the route, had a lower validity time? You couldn't determine the real
> validity time. Do we remove the route expiration time altogether to avoid
> this issue? In which case, we would have to rely on RERR messages being
> sent for routes which become invalid when the neighbor's validity time ha=
s
> expired? So neighbor validity time expiration is treated the same as a li=
nk
> break.
>
>
>
> What do you think?
>
>
>
> Kind regards,
>
> Victoria.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
> chris@mnemosyne.demon.co.uk> wrote:
>
> Pretty much all of the discussion has been assuming only a metric value
> change. With multiple things changing many of the ideas go out of the
> window. That reinforces the point about not making specifications now tha=
t
> might turn out to be wrong for ICVs.
>
>
>
> Ignoring how this misunderstanding happened, I'll start by asking why.
> Metric changing I understand. Why the other two? (there's a partial
> explanation of one). What alternatives have people implemented in
> comparable protocols?
>
> --
>
> Christopher Dearlove
>
> christopher.dearlove@gmail.com (iPhone)
>
> chris@mnemosyne.demon.co.uk (home)
>
>
> On 23 Apr 2016, at 00:26, Victoria Mercieca  wrote:
>
> Hi all,
>
>
>
> Continued in this thread because the other one seems to be more about TLV
> types and metric type numbers, whereas this is about
> regeneration/forwarding.
>
>
>
> To recap, in the current draft, there are 3 things that might change at
> each hop:
> - the metric value (happens in RREQ and RREP),
> - adding/changing Validity Time using the Validity Time TLV (can happen i=
n
> RREQ and RREP),
> - adding an address (and corresponding value in the AddressType TLV to
> indicate how to interpret the address) to indicate the address from which
> an RREP_Ack is expected, to accomplish the bidirectionality check (can
> happen in RREP).
>
> If we define a certain portion of the message as immutable and include th=
e
> ICV to verify that part, end to end:
> - The metric value would be excluded from the ICV since it needs changing
> at each hop.
> - Would adding a Validity Time TLV at an intermediate hop be acceptable?
> The whole TLV could be removed in order to calculate the ICV?
>
> - Would adding an address cause issues for the ICV, because it's in the
> address block? Could the rule be "if it contains an AckReq address, remov=
e
> it (and the corresponding value in the AddressType TLV), before checking
> the ICV", is that OK? Or would we need to avoid touching the ICV'ed part =
of
> the message altogether, maybe put the AckReq address in a separate Addres=
s
> Block, with an extra AddressType TLV following that address block? Is the=
re
> a way to accomplish this?
>
>
>
> Also, to be thorough, do we need to consider RERR messages while we
> discuss regeneration vs forwarding?
>
> - RERR (sent when a link breaks) is a way of saying "I've lost my route s=
o
> I'm telling others" and "you were my next hop, so now I've also lost my
> route, I'll tell others", etc. It's going to be tailored at each step to
> include the relevant routes that got deleted, it's not one message being
> sent end-to-end like RREQ and RREP are.
>
> - However, RERR (sent when a source of traffic is sending data on a route
> which comes through you, and you want to tell the Packet Source's router =
to
> delete the route) could be seen as an end-to-end message which all
> intermediate routers learn from, similar to RREQ and RREP. It reports one
> route, and doesn't need changing at intermediate hops, so could be
> protected with ICV.
>
> - Would it be OK to only require a message ICV if a PktSource address was
> included, i.e. when the message needs to go via a number of intermediate
> hops to PktSource's router? All other RERRs are intended to be one-hop
> messages, which may in turn prompt other one-hop messages, etc..., and a
> packet ICV might be more appropriate?
>
>
>
> Kind regards,
>
> Victoria.
>
>
>
> On Thu, Mar 17, 2016 at 5:26 PM,  wrote:
>
>
>
> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>
>
> Yes, I meant AODVv2, thanks for the catch.
>
>
>
> So is your (Thomas) proposed base specification a hop count only metric?
>
>
>
> No, the would be silly as base specification, given that hop count mostly
> is useless.
>
>
>
> As base specification I would simply say =E2=80=9CInclude a Metric Type M=
essage
> TLV with a value field, and a 7182 Message TLV & Timestamp=E2=80=9D as we=
 do in
> OLSRv2 (with the appropriate verbiage as to generation and processing).
>
>
>
> With the message generated by the originator of the RREQ/RREP and *not*
> deconstructed/reconstructed/reordered (as is the risk with =E2=80=9Cregen=
eration)
> allows knowing that it would be *only* that metric field being modified
> (other than hop count/limit) for when eventually writing up the extension=
.
>
>
>
> (Actually doesn=E2=80=99t the current specification only define hop count=
, or has
> that changed in latest draft?)
>
>
>
> No. That is one of the issues I raise in my original. For some reason, it
> cites RFC6551, which is a ROLL document and which has in its abstract tha=
t:
>
>
>
>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>
>    compared with traditional wired and ad hoc networks that require the
>
>    specification of new routing metrics and constraints.
>
>
>
> I.e. this document cites a metric document which clearly claims to be
> inapplicable in ad hoc networks. I note that this is another thing I=E2=
=80=99ve
> raised for years without seeing it attempted resolved.
>
>
>
> Best,
>
>
>
> Thomas
>
>
>
>
>
>
>
> *--*
>
>
>
>
> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
> ]
> *Sent:* 17 March 2016 17:10
> *To:* Dearlove, Christopher (UK)
> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>
>
> OK, so we have a message that mutates by:
>
> - Modifying hop count/limit.
>
> - Modifying a metric value.
>
> Anything else?
>
>
>
> As mutating (other than hop count/limit) messages aren=E2=80=99t covered =
by 5444
> or any derivative document (but only recommended against, not banned) tha=
t
> you may need to make the message otherwise immutable (no deconstruction a=
nd
> rebuilding, other than guaranteed unchanging) that would have to be
> specified by AODVv2. (Easy to say, but needs saying.)
>
>
>
> With you so far.
>
>
>
> Then that information is not in a guaranteed fixed location given by a
> simple offset. So any signature algorithm that finds it and ignores it or
> aggregates on it is specific to OLSRv2.
>
>
>
> Surely you mean AODVv2
>
>
>
> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AODVv2
> specialised variant. Which is the sort of thing that the message specific
> TLV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cbut ig=
nore the value of
> this specific TLV should it occur=E2=80=9D being in the general space. Ho=
wever it
> can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like tha=
t TLV,
> except if an X TLV is present, set its value field to zero=E2=80=9D).
>
>
>
> Messy, but could work.
>
>
>
> Not that messy, actually, although clearly not as nice as =E2=80=9Cfixed =
offset=E2=80=9D.
>
>
>
> That said, I am arguing for the base spec being:
>
>
>
>             =E2=80=9Cmake the message otherwise immutable (no deconstruct=
ion and
> rebuilding, other
>
>              than guaranteed unchanging)=E2=80=9D which is afforded by fo=
rwarding
>
>
>
>                                     +
>
>
>
>             RFC7182 Timestamps and ICVs.
>
>
>
>                                     +
>
>
>
>             RFC7183 style text bringing it all together.
>
>
>
> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would ve=
ry be an
> experimental extension.
>
>
>
> What I object to is, if the base spec specifically renders such extension=
s
> impossible
>
>
>
>
>
>
>
> *--*
>
>
>
>
> *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:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
> ]
> *Sent:* 17 March 2016 16:48
> *To:* Dearlove, Christopher (UK)
> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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
> .*
>
> Hi all,
>
>
>
> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com>:
>
>
>
> Good point about whether you just pass on one cost or a set of costs. As =
I
> said, not looked at details - I will, when time permits. One cost is much
> easier, and yes, it reduces the fixed size aggregated signatures problem =
to
> =E2=80=9Cjust=E2=80=9D one of computational load.
>
>
>
> For the record, Thomas=E2=80=99 understanding is correct; the cost is one
> aggregated value.
>
>
>
> Best regards,
>
> Lotte Steenrbink
>
>
>
>
>
> *--*
>
>
>
>
> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
> ]
> *Sent:* 17 March 2016 16:38
> *To:* Dearlove, Christopher (UK)
> *Cc:* Mobile Ad Hoc Networks mailing list
> *Subject:* Re: Message integrity and message mutability (was RE: [manet]
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>
>
> I appreciate Thomas=E2=80=99s comments about the limitations of message
> regeneration, but I would be a bit less absolute.
>
>
>
> The issues over end to end authentication and more advanced signatures ar=
e
> valid. I need to read the given reference on aggregate signatures to
> increase my knowledge (thanks for it), but my understanding of the
> possibilities in this field may offer a solution to the problem, but with
> some other issues (possibly including a new type of TLV).
>
>
>
> But the hop count/limit point I don=E2=80=99t fully agree with, you can r=
egenerate
> with an incremented/decremented count/limit, which leaves the ability to
> prevent messages propagating indefinitely, including expanding ring
> searches, and retains the ability to use RFC 5497 interval and validity
> times that might be useful with an expanding ring search (or might not).
>
>
>
> But the key issue is that AODVv2 wants to accumulate metrics. I still
> haven=E2=80=99t got to the bottom of many details here, but let=E2=80=99s=
 for the moment
> just consider that conceptually.
>
>
>
> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft attempts =
to do an end to
> end of some information, not this information. I=E2=80=99m not sure if th=
at=E2=80=99s
> useful (and the specialised format is better avoided if possible). Other
> approaches are hop by hop (might as well use packet signatures) and share=
d
> key (might as well go hop by hop). Pairwise signatures for each pair of
> routers I=E2=80=99m discounting as scaling terribly. In the interests of
> completeness let=E2=80=99s mention not accumulating metrics, which puts u=
s back to
> hop count and that=E2=80=99s not ideal either.
>
>
>
> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=80=
=99ve seen about
> aggregating, but that has some issues of its own, even apart from
> computational load.) I=E2=80=99d love to be proved wrong - someone with t=
he perfect
> solution to come along.
>
>
>
> Which means that either we make an arbitrary choice - which will be
> disagreed with, but needs discussing first - or create something flexible=
.
> Unfortunately flexible in that regard constrains in others, e.g. some
> (many? most?) aggregating signatures need fixed data sizes (which we can =
do
> by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but tha=
t has a cost too).
>
>
>
> I have been told by people much more well versed in this than I in
> cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>
>
>
> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does th=
at mean that the
> message grows as it is being forwarded, and that the recipient of a
> RREQ/RREP will know the individual costs of each path segment? My
> understanding is, that the recipient will get =E2=80=9Cthe sum the costs =
of each
> path segment=E2=80=9D which should be fitting within a fixed size?
>
>
>
> Thomas
>
>
>
>
>
>
>
>
> Sorry, no answers, just comments. And I=E2=80=99m not addressing Thomas=
=E2=80=99s later
> points here.
>
>
>
> *--*
>
>
>
>
> *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 ] *O=
n
> Behalf Of *ietf@thomasclausen.org
> *Sent:* 17 March 2016 16:00
> *To:* Mobile Ad Hoc Networks mailing list
> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of big
> ticket Items
>
>
>
>
>
> **** 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.
>
>
>
> Dear all,
>
>
>
> Apologies for not having gotten this done sooner - day-job leaving few
> spare cycles.
>
>
>
> I=E2=80=99ve previously offered reviews and comments, and some of those h=
ave been
> addressed in the latest I-D =E2=80=94 others have not, but should be. I r=
ecall that
> there was some mail attempting to rebut parts of the review, and I will d=
ig
> it out and reply to that.
>
>
>
> With that being said, I have reviewed the latest version of the document,
> and full details will be forthcoming. There=E2=80=99re a couple of
> big-ticket/architectural items that I want to address up front, as I
> believe that before we have those hammered out, it will be useless to go
> into details. Note, I do not claim that this is an exhaustive list of =E2=
=80=9Cbig
> ticket items=E2=80=9D, but that=E2=80=99s as far as I have gotten in thin=
king this through.
>
>
>
> I also bring these up as they are items that have been brought up
> repeatedly over the past years, but not resolved nor discussed.
>
>
>
> *Loops*
>
> Just to bring this out: I share Chris=E2=80=99 worry about conflicting an=
d
> concurrent statements from the authors on =E2=80=9CThere are no loops pos=
sible=E2=80=9D and
> =E2=80=9CWe need to fix two situations where loops can occur=E2=80=9D and=
 =E2=80=9Cwe are still
> investigating some loop conditions=E2=80=9D
>
>
>
> I particularly worry that this is not a discussion had in public, but
> apparently in some other forum=E2=80=A6
>
>
>
>
>
> *Intermediate Route Replies, and all of section 10*
>
> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=80=
=9D, which is
> incoherent with the intended status indicated for this document.
>
>
>
> Specifically, and this is not unrelated to the point about loops above,
> intermediate RREPs (section 10.3) are a potential source for loops.
>
>
>
> Expanding Ring Multicast (section 10.1) is not documented in a way that
> can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=E2=
=80=9D below, it is
> in the present form of this protocol impossible), etc.
>
>
>
>
>
> *Forwarding-vs-regeneration*
>
> Recent exchanges on the list made me understand that protocol control
> messages are *not* forwarded, but are consumed at each hop, then a new
> message with (almost-but-not-quite) the same content is generated and
> transmitted.
>
>
>
> I have thought some more on this (& read some of the exchanges on the lis=
t
> on this topic by Chris, Ulrich, and others), and I am convinced that this
> is not the right way to go, *at least* for the following reasons:
>
>
>
>
>
>             o          *It renders the hop-limit/hop-count fields in the
> RFC5444 message header useless.*
>
>                         This would not be bad if the functionality offere=
d
> by those fields was not useful
>
>                         =E2=80=94 sadly, it is. For example, for scope li=
mited
> flooding (expanding ring search, and
>
>                         such) which may be of interest, and which require
> hop-limit.
>
>                         A hop-count field may also provide a =E2=80=9Cche=
ap=E2=80=9D (in
> terms of overhead) additional piece
>
>                         of information to use conjunctively with a =E2=80=
=9Creal=E2=80=9D
> metric.
>
>
>
>                         The only practical solution would be to
> re-introduce these functions by way of inserting a
>
>                         MessageTLV =E2=80=94 which (i) is not specified i=
n this
> document, and (ii) which would just
>
>                         serve to render messages bigger than strictly
> needed.
>
>
>
>                         Scope limited flooding  does seem to be a
> necessary requirement, if for no
>
>                         other reason than to prevent information from
> =E2=80=9Ccirculating forever in the network=E2=80=9D.
>
>
>
>             o          *It makes end-to-end authentication unnecessarily
> hard.*
>
>                         I think Chris called this out already, but it
> bears repeating: S generates a message
>
>                         (say, a RREQ), and includes an ICV calculated ove=
r
> the content of the message.
>
>                         For any recipient to be able to validate the ICV,
> the message has to be exactly
>
>                         the same =E2=80=94 not just in content, but in st=
ructure =E2=80=94
> as what was generated.
>
>
>
>                         =E2=80=9CRegenerating=E2=80=9D rather than =E2=80=
=9Cforwarding=E2=80=9D messages
> means, that the intermediate
>
>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ ma=
y chose a
> different structure (e.g., include TLVs
>
>                         in a different order).
>
>
>
>                         The proposal from
> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>
>                         is to add constraints on (i) the set of elements
> to include in a signature and (ii) the
>
>                         order of these elements.
>
>
>
>                         One problem with that approach is (i): if an
> extension adds a message TLV, or an
>
>                         Address TLV, to a message, then that will not be
> =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>
>                         Rather for *each* extension developed, an =E2=80=
=9Cupdates
> e2esec=E2=80=9D clause needs to be done.
>
>
>
>                         I=E2=80=99d say that this approach would be prone=
 to
> errors =E2=80=94 and add entropy to the process
>
>                         of designing protocol extensions. The alternative=
,
> a message being generated by the
>
>                         source and *forwarded* (as we do in OLSRv2, for
> example) would allow ICV TLVs
>
>                         (even, allow reuse of those specified for OLSRv2)
> for covering a message and
>
>                         extensions.
>
>
>
>                         =E2=80=9CBut what about the metrics value which w=
ill
> change on each hop=E2=80=9D, you may say?
>
>                         Fortunately, that is relatively easy to handle:
> simply zero out the value of that TLV when
>
>                         generating or verifying the ICV MessageTLV. And
> use Packet-TLVs for hop-by-hop
>
>                         authentication, if needed (but, see below).
>
>
>
>             o          *It prevents the use of more clever/advanced
> signature schemes/ICVs*
>
>                         Aggregate signature algorithms (
> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>
>                         exist, and an interesting use-case can be found i=
n
> also reactive protocols, allowing verifying
>
>                         not =E2=80=9Cjust=E2=80=9D the end points, but al=
so the
> intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D
>
>                         discussed above, or something smarter).
>
>                         Regeneration of messages, rather than forwarding,
> renders that impossible (or, if used,
>
>                         updating to
> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>
>
>
> There are other reasons, but the above are those that jump at me as
> immediate show-stoppers.
>
>
>
> I do honestly not see what possible benefit there is from =E2=80=9Cregene=
ration=E2=80=9D =E2=80=94
> but I see very clear inconveniences, and security is not the least of
> these. Insisting on =E2=80=9Cregeneration=E2=80=9D requires development o=
f =E2=80=9Cnon-general
> workarounds=E2=80=9D as pointed out above.
>
>
>
> *Security Considerations*
>
> This is an always thorny subject. When OLSRv2 was going through the
> process we got a thorough education in how little we knew about security
> from the SEC-ADs, and had to spend about a year or so developing RFC7183.
> The bottom line is, that this protocol needs its =E2=80=9CRFC7183  equiva=
lent=E2=80=9D,
> either as part of the main document, or as an independent document.
> currently, that is not the case.
>
>
>
> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration from R=
FC7183
> might be aw good idea, as that was the most recent that went through the
> SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to implement=E2=
=80=9D security
> mechanism most be specified (I think the right term was =E2=80=9CMUST imp=
lement,
> SHOULD use=E2=80=9D), in sufficient detail to ensure interoperable implem=
entations.
>
>
>
> As an example, both [RFC6130] and [RFC7181] set out that that:
>
>
>
>       On receiving a ... message, a router MUST first check if the
>
>       message is invalid for processing by this router
>
>
>
> and then proceed to give a number of conditions that, each, will lead to =
a
> rejection of the message as "badly formed and therefore invalid for
> processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That gav=
e a =E2=80=9Chook=E2=80=9D for
> RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message gener=
ation.
>
>
>
> If I was to do RFC7181/RFC6130 today, I would include that directly into
> the protocol specifications. It turned out to be more overhead (and slow
> down publication anyways) to do it as separate documents.
>
>
>
> Secondly, we need to be a lot more rigid in terms of what ICVs,
> Timestamps, etc. are added/removed, and what that brings.
>
>
>
> For example (with the assumption that messages are *forwarded* and *not*
> regenerated), this could be one option:
>
>
>
>                         o          When a RREQ, RREP message is generated=
,
> add an ICV Message TLV, which is calculated 
>
>                                      =E2=80=A6(take inspiration from RFC7=
183 here)
>
>
>
> ...
>
> [Message clipped]
> _______________________________________________
> 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
>
>
>
> ********************************************************************
> 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
>
>

--001a1141e52cdf7f8105314df92e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,=C2=A0

On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <=
span dir=3D"ltr"><chris.dearlove@baesystems.com> wrote:











With regard to your valid=
ity time point, we here have a tradeoff. If you allow that feature, it sign=
ificantly impacts on the approach that was coming together
 on as best you can end to end encryption.


=C2=A0


So the question is, is th=
is a feature that=E2=80=99s really wanted? Unfortunately I think we know th=
at the answer to that is, we don=E2=80=99t know because we don=E2=80=99t ha=
ve any
 experience. My view would be that in the tradeoff of an untested feature (=
unless I=E2=80=99m wrong about that) and the security complication, securit=
y wins and drop the feature. If there is some real requirement, then there=
=E2=80=99s a discussion. (Questions like how often
 the intermediate routers actually have any knowledge - typically links bre=
ak for unexpected rather than expected reasons. Andan intermediate router c=
ould possibly use a validity time to influence its behaviour.) Note that dr=
opping the ability of intermediate
 routers to modify/set still allows validity times per route to be set at e=
ndpoints.

I agree wi=
th Chris' concern.
The ValidityTime is optional, which makes =
the integrity protection hard. Furthermore, it gives a potential attack vec=
tor: as all the routers in a path will take the shortest validityTime, a co=
mpromised router can set the the validityTime to a very short value, which =
will make the route installed along the path became invalid (very soon).=C2=
=A0

On the other hand, I'm not sure this optio=
n will give us much help. Chris mentioned much knowledge intermediate route=
r would have to decide this value (and how much sense the value would make)=
.=C2=A0
Another issue is, a route to a destination might be updat=
ed by different sources. For example, in the network below:

<=
/div>
A----B-----C

A first establish a route to B with long validity time. The=
n A initiates a route discovery to C. C tends to set a short validity time,=
 which will make the route between B and A expire earlier than expected.=C2=
=A0
Is this a problem? Maybe yes, maybe no -- I'm not sure it=
's considered or not.=C2=A0
=C2=A0


=C2=A0


With regard to the acknow=
ledgements, the problem (with regard to security) comes from trying to do t=
wo jobs with the same message - end to end route advertisement
 and hop by hop acknowledgement. I understand the reasons - saving bytes an=
d message types. (I would have to study the protocol really hard to identif=
y if any message types can be folded together and recognised by content rat=
her than type efficiently. This
 I do not expect to do.) Again a tradeoff. This one is in discussion space,=
 though that needs people who understand both sides of the issue, including=
 the details of the bidirectionality mechanism. Of course, as has been said=
, we need one of those.

<=
div>I haven't finished my review of the latest draft, and I don't g=
et the necessity of AckReq and the corresponding multicast RREP yet.=C2=A0<=
/div>
If possible, this "optional" field should be avoided.=
=C2=A0

regards

Jiazi
=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: Victoria Mercieca [mailto:vmercieca0@gmail.com]


Sent: 23 April 2016 10:55

To: Christopher Dearlove

Cc: ietf=
@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc Networks =
mailing list


Subject: Re: [manet] Message integrity and message mutability (was R=
E: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)=



=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.=









Hi Chris,




=C2=A0






These have both been in the draft in some form since=
 before I got involved... but I'll do my best to explain.=





=C2=A0






- For Validity Time, its a way to advertise that you=
 would only support the route contained in the message for a certain period=
 of time. The originator might use this, but the draft was written to allow=
 any intermediate node to be able
 to add it or update it too. The route created in the Local Route Set has a=
n expiration time associated with it, based on the received validity time.<=
u>






- For the AckReq address, its so that you can add in=
to a RREP a request for an acknowledgement, so that you don't have to h=
ave a different message type altogether for working out whether links to ne=
ighbors are bidirectional, and also, since
 you only care about bidirectionality on routes that are being set up, you =
dont need to constantly monitor all neighbors.






=C2=A0






=C2=A0






In order to avoid the potential AckReq-related chang=
es to each message, maybe we do need to introduce a different message speci=
fically for this. We could maybe use RREP_Ack to both request and acknowled=
ge? It means an extra message of control
 traffic that needs to be sent, maybe one extra message per hop on the path=
 of a RREP, but it could still be limited to neighbors which have participa=
ted in the route discovery rather than monitoring all neighbors at all time=
s.=C2=A0






=C2=A0






This message could maybe also include "I'm =
happy to route anywhere for a certain amount of time", sort of like wi=
llingness in OLSR/OLSRv2. So instead of having a validity time per route, i=
ts a validity time per neighbor. Then, for RREQ
 and RREP, only the metric value would change in transit, as discussed. How=
ever, that leads to some issues with deciding what a route's expiration=
 time is. You might know how long the next hop router is valid for, but wha=
t if a router beyond that, which was
 also part of the route, had a lower validity time? You couldn't determ=
ine the real validity time. Do we remove the route expiration time altogeth=
er to avoid this issue? In which case, we would have to rely on RERR messag=
es being sent for routes which become
 invalid when the neighbor's validity time has expired? So neighbor val=
idity time expiration is treated the same as a link break.





=C2=A0






What do you think?






=C2=A0






Kind regards,






Victoria.






=C2=A0






=C2=A0






=C2=A0






=C2=A0






=C2=A0








=C2=A0




On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlov=
e <chri=
s@mnemosyne.demon.co.uk> wrote:






Pretty much all of the discussion has been assuming =
only a metric value change. With multiple things changing many of the ideas=
 go out of the window. That reinforces the point about not making specifica=
tions now that might turn out to be
 wrong for ICVs.






=C2=A0






Ignoring how this misunderstanding happened, I'l=
l start by asking why. Metric changing I understand. Why the other two? (th=
ere's a partial explanation of one). What alternatives have people impl=
emented in comparable protocols?



-- =C2=A0




Christopher Dearlove












On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmail.com> wrote:
















Hi all,






=C2=A0






Continued in this thread because the other one seems=
 to be more about TLV types and metric type numbers, whereas this is about =
regeneration/forwarding.






=C2=A0






To recap, in the current draft, there are 3 things t=
hat might change at each hop:


- the metric value (happens in RREQ and RREP), 

- adding/changing Validity Time using the Validity Time TLV (can happen in =
RREQ and RREP),


- adding an address (and corresponding value in the AddressType TLV to indi=
cate how to interpret the address) to indicate the address from which an RR=
EP_Ack is expected, to accomplish the bidirectionality check (can happen in=
 RREP).



If we define=C2=A0a certain portion of the message as immutable and include=
 the ICV to verify that part, end to end:


- The metric value would be excluded from the ICV since it needs changing a=
t each hop.=C2=A0

- Would adding a Validity Time TLV at an intermediate hop be acceptable? Th=
e whole TLV could be removed in order to calculate the ICV?



- Would adding an address cause issues for the ICV, =
because it's in the address block? Could the rule be "if it contai=
ns an AckReq address, remove it (and the corresponding value in the Address=
Type TLV), before checking the ICV", is that
 OK? Or would we need to avoid touching the ICV'ed part of the message =
altogether, maybe put the AckReq address in a separate Address Block, with =
an extra AddressType TLV following that address block? Is there a way to ac=
complish this?






=C2=A0






Also, to be thorough, do we need to consider RERR me=
ssages while we discuss regeneration vs forwarding?=C2=A0






- RERR (sent when a link breaks) is a way of saying =
"I've lost my route so I'm telling others" and "you =
were my next hop, so=C2=A0now=C2=A0I've also lost my route, I'll te=
ll others", etc. It's going to be tailored at each step to include=
 the relevant
 routes that got deleted, it's not one message being sent end-to-end li=
ke RREQ and RREP are.=C2=A0






- However, RERR (sent when a source of traffic is se=
nding data on a route which comes through you, and you want to tell the Pac=
ket Source's router to delete the route) could be seen as an end-to-end=
 message which all intermediate routers
 learn from, similar to RREQ and RREP. It reports one route, and doesn'=
t need changing at intermediate hops, so could be protected with ICV.






- Would it be OK to only require a message ICV if a =
PktSource address was included, i.e. when the message needs to go via a num=
ber of intermediate hops to PktSource's router? All other RERRs are int=
ended to be one-hop messages, which may
 in turn prompt other one-hop messages, etc..., and a packet ICV might be m=
ore appropriate?






=C2=A0




Kind regards,




Victoria.






=C2=A0




On Thu, Mar 17, 2016 at 5:26 PM, <ietf@thomasclausen.org>=
 wrote:




=C2=A0








On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK)=
 <chr=
is.dearlove@baesystems.com> wrote:




=C2=A0








Yes, I meant AODVv2, than=
ks for the catch.






=C2=A0






So is your (Thomas) propo=
sed base specification a hop count only metric?












=C2=A0




No, the would be silly as base specification, given =
that hop count mostly is useless.






=C2=A0






As base specification I would simply say =E2=80=9CIn=
clude a Metric Type Message TLV with a value field, and a 7182 Message TLV =
& Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage =
as to generation and processing).=C2=A0






=C2=A0






With the message generated by the originator of the =
RREQ/RREP and *not* deconstructed/reconstructed/reordered (as is the risk w=
ith =E2=80=9Cregeneration) allows knowing that it would be *only* that metr=
ic field being modified (other than hop count/limit)
 for when eventually writing up the extension.






=C2=A0












(Actually doesn=E2=80=99t=
 the current specification only define hop count, or has that changed in la=
test draft?)










=C2=A0




No. That is one of the issues I raise in my original=
. For some reason, it cites RFC6551, which is a ROLL document and which has=
 in its abstract that:






=C2=A0






=C2=A0=C2=A0 Low-Power and Lossy Networks (LLNs) have unique character=
istics


=C2=A0=C2=A0 compared with traditional wired and ad hoc networks that =
require the


=C2=A0=C2=A0 specification of new routing metrics and constraints. =





=C2=A0






I.e. this document cites a metric document which cle=
arly claims to be inapplicable in ad hoc networks. I note that this is anot=
her thing I=E2=80=99ve raised for years without seeing it attempted resolve=
d.






=C2=A0






Best,






=C2=A0






Thomas






=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:=C2=A0chris.dearlove@baesystem=
s.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:=C2=A0ietf@thomasclausen.org=
=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 17:10

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Lotte Steenbrink; Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)










=C2=A0






=C2=A0




*** WARNING ***<=
/u>







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=C2=A0Red Flags=C2=A0t=
hat
 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=A0












On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:








=C2=A0










OK, so we have a message =
that mutates by:










- Modifying hop count/lim=
it.










- Modifying a metric valu=
e.










Anything else?<=
/u>










=C2=A0










As mutating (other than h=
op count/limit) messages aren=E2=80=99t covered by 5444 or any derivative d=
ocument (but only recommended against, not banned) that you may
 need to make the message otherwise immutable (no deconstruction and rebuil=
ding, other than guaranteed unchanging) that would have to be specified by =
AODVv2. (Easy to say, but needs saying.)














=C2=A0








With you so far.










=C2=A0<=
/p>







Then that information is =
not in a guaranteed fixed location given by a simple offset. So any signatu=
re algorithm that finds it and ignores it or aggregates
 on it is specific to OLSRv2.










=C2=A0








Surely you mean AODVv2










=C2=A0<=
/p>







So standard 7182 ICVs don=
=E2=80=99t do the job, you would need an AODVv2 specialised variant. Which =
is the sort of thing that the message specific TLV space is there
 for, I=E2=80=99d be strongly against a =E2=80=9Cbut ignore the value of th=
is specific TLV should it occur=E2=80=9D being in the general space. Howeve=
r it can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like =
that TLV, except if an X TLV is present, set its value field to
 zero=E2=80=9D).










=C2=A0










Messy, but could work.










=C2=A0








Not that messy, actually, although clearly not as ni=
ce as =E2=80=9Cfixed offset=E2=80=9D.










=C2=A0










That said, I am arguing for the base spec being:<=
/u>










=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=E2=80=9Cmake the message otherwise immutable (no deco=
nstruction and rebuilding, other=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=A0than guaranteed unchanging)=E2=80=9D which is af=
forded by forwarding










=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7182 Timestamps and ICVs.










=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7183 style text bringing it all together.=











=C2=A0










The =E2=80=9Caggregated signatures around mutable fi=
eld=E2=80=9D would very be an experimental extension.










=C2=A0










What I object to is, if the base spec specifically r=
enders such extensions impossible










=C2=A0










=C2=A0<=
/p>







=C2=A0








--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44 (0)12=
45 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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:=C2=A0Lotte Steenbrink [mailto:lo=
tte.steenbrink@fu-berlin.de]=C2=A0

Sent:=C2=A017 March 2016 16:48

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0ietf@thomasclausen.org; Mobile Ad =
Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=C2=A0








=C2=A0




*** WARNING ***<=
/u>







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=C2=A0Red Flags=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.










Hi all,












=C2=A0
















Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher=
 (UK) <chris.dearlove@baesystems.com>=
:












=C2=A0














Good point about whether =
you just pass on one cost or a set of costs. As I said, not looked at detai=
ls - I will, when time permits. One cost is much easier,
 and yes, it reduces the fixed size aggregated signatures problem to =E2=80=
=9Cjust=E2=80=9D one of computational load.


















=C2=A0














For the record, Thomas=E2=80=99 understanding is cor=
rect; the cost is one aggregated value.=C2=A0














=C2=A0














Best regards,=C2=A0














Lotte Steenrbink































=C2=A0










--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44 (0)12=
45 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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:=C2=A0ietf@thomasclausen.org=
=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 16:38

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: Message integrity and message mutability (was RE: =
[manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)


















=C2=A0










=C2=A0




*** WARNING ***<=
/u>







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=C2=A0Red Flags=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=A0




















On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:
















=C2=A0


















I appreciate Thomas=E2=80=
=99s comments about the limitations of message regeneration, but I would be=
 a bit less absolute.


















=C2=A0


















The issues over end to en=
d authentication and more advanced signatures are valid. I need to read the=
 given reference on aggregate signatures to increase my
 knowledge (thanks for it), but my understanding of the possibilities in th=
is field may offer a solution to the problem, but with some other issues (p=
ossibly including a new type of TLV).


















=C2=A0


















But the hop count/limit p=
oint I don=E2=80=99t fully agree with, you can regenerate with an increment=
ed/decremented count/limit, which leaves the ability to prevent
 messages propagating indefinitely, including expanding ring searches, and =
retains the ability to use RFC 5497 interval and validity times that might =
be useful with an expanding ring search (or might not).


















=C2=A0


















But the key issue is that=
 AODVv2 wants to accumulate metrics. I still haven=E2=80=99t got to the bot=
tom of many details here, but let=E2=80=99s for the moment just consider
 that conceptually.


















=C2=A0


















It=E2=80=99s hard to hand=
le end to end. Charlie=E2=80=99s draft attempts to do an end to end of some=
 information, not this information. I=E2=80=99m not sure if that=E2=80=99s =
useful (and the
 specialised format is better avoided if possible). Other approaches are ho=
p by hop (might as well use packet signatures) and shared key (might as wel=
l go hop by hop). Pairwise signatures for each pair of routers I=E2=80=99m =
discounting as scaling terribly. In the
 interests of completeness let=E2=80=99s mention not accumulating metrics, =
which puts us back to hop count and that=E2=80=99s not ideal either.=



















=C2=A0


















I don=E2=80=99t think the=
re is an ideal solution. (I like ideas I=E2=80=99ve seen about aggregating,=
 but that has some issues of its own, even apart from computational load.)
 I=E2=80=99d love to be proved wrong - someone with the perfect solution to=
 come along.


















=C2=A0


















Which means that either w=
e make an arbitrary choice - which will be disagreed with, but needs discus=
sing first - or create something flexible. Unfortunately
 flexible in that regard constrains in others, e.g. some (many? most?) aggr=
egating signatures need fixed data sizes (which we can do by defining a TLV=
 that =E2=80=9Cfills up=E2=80=9D with hop count, but that has a cost too).<=
/span>






















=C2=A0
















I have been told by people much more well versed in =
this than I in cryptology, that the correct answer is =E2=80=9Csome=E2=80=
=9D.


















=C2=A0


















That said, "AODVv2 wants to accumulate metrics=
=E2=80=9D =E2=80=94 does that mean that the message grows as it is being fo=
rwarded, and that the recipient of a RREQ/RREP will know the individual cos=
ts of each path segment? My understanding is, that the recipient
 will get =E2=80=9Cthe sum the costs of each path segment=E2=80=9D which sh=
ould be fitting within a fixed size?


















=C2=A0


















Thomas


















=C2=A0











































=C2=A0


















Sorry, no answers, just c=
omments. And I=E2=80=99m not addressing Thomas=E2=80=99s later points here.=



















=C2=A0












--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44 (0)12=
45 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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:=C2=A0manet [mailto:manet-bounces@ietf.o=
rg]=C2=A0On
 Behalf Of=C2=A0ietf@thomasclausen.org

Sent:=C2=A017 March 2016 16:00

To:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0[manet] draft-ietf-manet-aodvv2-13 review - a couple o=
f big ticket Items






















=C2=A0












=C2=A0




*** WARNING ***<=
/u>







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=C2=A0Red Flags=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.








***<=
/strong>=C2=A0WARNING=C2=A0***

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












=C2=A0




















Dear all,




















=C2=A0






















Apologies for not having gotten this done sooner - d=
ay-job leaving few spare cycles.






















=C2=A0






















I=E2=80=99ve previously offered reviews and comments=
, and some of those have been addressed in the latest I-D =E2=80=94 others =
have not, but should be. I recall that there was some mail attempting to re=
but parts of the review, and I will dig it out and
 reply to that.






















=C2=A0






















With that being said, I have reviewed the latest ver=
sion of the document, and full details will be forthcoming. There=E2=80=99r=
e a couple of big-ticket/architectural items that I want to address up fron=
t, as I believe that before we have those
 hammered out, it will be useless to go into details. Note, I do not claim =
that this is an exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D, but =
that=E2=80=99s as far as I have gotten in thinking this through.<=
/u>






















=C2=A0






















I also bring these up as they are items that have be=
en brought up repeatedly over the past years, but not resolved nor discusse=
d.






















=C2=A0






















Loops






















Just to bring this out: I share Chris=E2=80=99 worry=
 about conflicting and concurrent statements from the authors on =E2=80=9CT=
here are no loops possible=E2=80=9D and =E2=80=9CWe need to fix two situati=
ons where loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating =
some loop
 conditions=E2=80=9D






















=C2=A0






















I particularly worry that this is not a discussion h=
ad in public, but apparently in some other forum=E2=80=A6






















=C2=A0






















=C2=A0
























Intermediate Route Replies, and all of section=
 10






















Section 10 contains a set of =E2=80=9Cvaguely specif=
ied extensions=E2=80=9D, which is incoherent with the intended status indic=
ated for this document.=C2=A0






















=C2=A0






















Specifically, and this is not unrelated to the point=
 about loops above, intermediate RREPs (section 10.3) are a potential sourc=
e for loops.






















=C2=A0






















Expanding Ring Multicast (section 10.1) is not docum=
ented in a way that can be implemented (and also, see =E2=80=9CForwarding-v=
s-regeneration=E2=80=9D below, it is in the present form of this protocol i=
mpossible), etc.
























=C2=A0






















=C2=A0






















Forwarding-vs-regeneration






















Recent exchanges on the list made me understand that=
 protocol control messages are *not* forwarded, but are consumed at each ho=
p, then a new message with (almost-but-not-quite) the same content is gener=
ated and transmitted.






















=C2=A0






















I have thought some more on this (& read some of=
 the exchanges on the list on this topic by Chris, Ulrich, and others), and=
 I am convinced that this is not the right way to go,=C2=A0at least=
=C2=A0for the following reasons:






















=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It renders the hop-limit/hop-count fields in the RFC5444 messag=
e header useless.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0This would not be bad if the functionality offered by tho=
se fields was not useful






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=94 sadly, it is. For example, for scope limited fl=
ooding (expanding ring search, and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0such) which may be of interest, and which require hop-lim=
it.=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0A hop-count field may also provide a =E2=80=9Ccheap=E2=80=
=9D (in terms of overhead) additional piece






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of information to use conjunctively with a =E2=80=9Creal=
=E2=80=9D metric.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The only practical solution would be to re-introduce thes=
e functions by way of inserting a






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0MessageTLV =E2=80=94 which (i) is not specified in this d=
ocument, and (ii) which would just






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0serve to render messages bigger than strictly needed.<=
/u>






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Scope limited flooding =C2=A0does seem to be a necessary =
requirement, if for no






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0other reason than to prevent information from =E2=80=9Cci=
rculating forever in the network=E2=80=9D.






















=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It makes end-to-end authentication unnecessarily hard.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I think Chris called this out already, but it bears repea=
ting: S generates a message=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(say, a RREQ), and includes an ICV calculated over the co=
ntent of the message.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0For any recipient to be able to validate the ICV, the mes=
sage has to be exactly






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0the same =E2=80=94 not just in content, but in structure =
=E2=80=94 as what was generated.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforwa=
rding=E2=80=9D messages means, that the intermediate






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose =
a different structure (e.g., include TLVs






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0in a different order).






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The proposal from=C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00=























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0is to add constraints on (i) the set of elements to inclu=
de in a signature and (ii) the






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0order of these elements.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0One=C2=A0problem with that approach is (i): if an extensi=
on adds a message TLV, or an=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Address TLV, to a message, then that will not be =E2=80=
=9Ccovered=E2=80=9D by the proposed e2esec TLV.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Rather for *each* extension developed, an =E2=80=9Cupdate=
s e2esec=E2=80=9D clause needs to be done.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I=E2=80=99d say that this approach would be prone to erro=
rs =E2=80=94 and add entropy to the process






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of designing protocol extensions. The alternative, a mess=
age being generated by the






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0source and *forwarded* (as we do in OLSRv2, for example) =
would allow ICV TLVs=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(even, allow reuse of those specified for OLSRv2) for cov=
ering a message and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0extensions.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CBut what about the metrics value which will chan=
ge on each hop=E2=80=9D, you may say?






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Fortunately, that is relatively easy to handle: simply ze=
ro out the value of that TLV when






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0generating or verifying the ICV MessageTLV. And use Packe=
t-TLVs for hop-by-hop=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0authentication, if needed (but, see below).=























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It prevents the use of more clever/advanced signature scheme=
s/ICVs






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Aggregate signature algorithms (=C2=A0https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf<=
/span>)






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0exist, and an interesting use-case can be found in also r=
eactive protocols, allowing verifying






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0not =E2=80=9Cjust=E2=80=9D the end points, but also the i=
ntermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0discussed above, or something smarter).






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Regeneration of messages, rather than forwarding, renders=
 that impossible (or, if used,






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0updating to =C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)






















=C2=A0






















There are other reasons, but the above are those tha=
t jump at me as immediate show-stoppers.






















=C2=A0






















I do honestly not see what possible benefit there is=
 from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inconve=
niences, and security is not the least of these. Insisting on =E2=80=9Crege=
neration=E2=80=9D requires development of =E2=80=9Cnon-general workarounds=
=E2=80=9D as pointed
 out above.






















=C2=A0






















Security Considerations<=
/p>





















This is an always thorny subject. When OLSRv2 was go=
ing through the process we got a thorough education in how little we knew a=
bout security from the SEC-ADs, and had to spend about a year or so develop=
ing RFC7183. The bottom line is, that
 this protocol needs its =E2=80=9CRFC7183 =C2=A0equivalent=E2=80=9D, either=
 as part of the main document, or as an independent document. currently, th=
at is not the case.






















=C2=A0






















A minima, looking at BCP72 and BCP107 =E2=80=94 taki=
ng inspiration from RFC7183 might be aw good idea, as that was the most rec=
ent that went through the SEC AD. Regardless of how, however, a =E2=80=9Cma=
ndatory to implement=E2=80=9D security mechanism most be specified
 (I think the right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D),=
 in sufficient detail to ensure interoperable implementations.






















=C2=A0






















As an example, both [RFC6130] and [RFC7181] set out =
that that:
























=C2=A0






















=C2=A0 =C2=A0 =C2=A0 On receiving a ... message, a r=
outer MUST first check if the






















=C2=A0 =C2=A0 =C2=A0 message is invalid for processi=
ng by this router






















=C2=A0






















and then proceed to give a number of conditions that=
, each, will lead to a rejection of the message as "badly formed and t=
herefore invalid for processing=E2=80=9D =E2=80=94 a list which RFC7183 the=
n amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting
 =E2=80=9Crejection=E2=80=9D. Idem for message generation.





















=C2=A0






















If I was to do RFC7181/RFC6130 today, I would includ=
e that directly into the protocol specifications. It turned out to be more =
overhead (and slow down publication anyways) to do it as separate documents=
.
























=C2=A0






















Secondly, we need to be a lot more rigid in terms of=
 what ICVs, Timestamps, etc. are added/removed, and what that brings.






















=C2=A0






















For example (with the assumption that messages are *=
forwarded* and *not* regenerated), this could be one option:<=
/p>





















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0When a RREQ, RREP message is generated, add an ICV Message TLV, which=
 is calculated <this way>






















=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=E2=80=A6(take inspiration from RFC7183 here)






















=C2=A0
































...



[Message clipped]=C2=A0=C2=A0

_______________________________________________

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










=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





--001a1141e52cdf7f8105314df92e--


From nobody Mon Apr 25 05:53: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 140D312D0AD for ; Mon, 25 Apr 2016 05:52:59 -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 9obBnyysrx-j for ; Mon, 25 Apr 2016 05:52:56 -0700 (PDT)
Received: from ukmta1.baesystems.com (unknown [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 66CA912D094 for ; Mon, 25 Apr 2016 05:52:55 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,532,1454976000"; d="scan'208,217"; a="63914004"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 25 Apr 2016 13:52:52 +0100
X-IronPort-AV: E=Sophos;i="5.24,532,1454976000";  d="scan'208,217";a="115354395"
Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds016.greenlnk.net with ESMTP; 25 Apr 2016 13:51:43 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.34]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0248.002; Mon, 25 Apr 2016 13:51:43 +0100
From: "Dearlove, Christopher (UK)" 
To: Stan Ratliff 
Thread-Topic: [manet] Recharter Discussion
Thread-Index: AQHRnKi1tIqGPmFeIkW1v/uroMSbLJ+WICEg///zOgCABJAFIA==
Date: Mon, 25 Apr 2016 12:51:42 +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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1510GLKXM0002VGREEN_"
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: Mon, 25 Apr 2016 12:52:59 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1510GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Q2hhaXJzIGFuZCBXRw0KDQpJIGp1c3QgbmVlZGVkIHRvIHRvdWNoIGJhc2Ugd2l0aCB0aGUgYXBw
cm9wcmlhdGUgcGVyc29uIGhlcmUuDQoNCkkgY2FuIGNvbmZpcm0gdGhhdCBJ4oCZbSBhd2FyZSBv
ZiAoYW0gYW4gaW52ZW50b3Igb24pIGEgcGF0ZW50IGFwcGxpY2F0aW9uIHRoYXQgaXMgcmVsYXRl
ZCB0byB0aGUgYXJlYSBvZiBlbmNyeXB0aW9uIGluIGFuIGFkIGhvYyBuZXR3b3JrLiBBdCB0aGlz
IHBvaW50IHdl4oCZcmUgb25seSBkaXNjdXNzaW5nIHdoZXRoZXIgd2Ugc2hvdWxkIHdvcmsgaW4g
dGhpcyBhcmVhLCBzbyBpc3N1ZXMgb2YgaXRzIHVzZSBkbyBub3QgY29tZSB1cCBub3cuDQoNCihE
byB5b3UgbmVlZCB0aGUgbnVtYmVyPyBJIGRvbuKAmXQgaGF2ZSBpdCB0byBoYW5kIHRoaXMgc2Vj
b25kOyBob3dldmVyIGdpdmVuIHRoYXQgSeKAmW0gbm90IGNhbGxlZCBTbWl0aCBpdOKAmXMgcXVp
dGUgZWFzeSB0byBmaW5kIC0gYnV0IHNlZSBiZWxvdy4pDQoNCkhhdmluZyBzYWlkIHRoYXQsIEkg
Y2FuIG5vdyBzYXkgdGhhdCBhIHJlcXVpcmVtZW50IHRoYXQgc29tZSBwZW9wbGUgSSBrbm93IGhh
dmUgaXMgdGhhdCBvZiBjb25jZWFsaW5nIGlkZW50aXR5IGFuZCB0b3BvbG9neS9yb3V0aW5nIGlu
Zm9ybWF0aW9uLiBXaGljaCBhZCBob2Mgcm91dGluZyBwcm90b2NvbHMgdGVuZCB0byBmcmVlbHkg
ZGlzdHJpYnV0ZS4gVGhhdOKAmXMgZWFzeSBpZiB5b3UganVzdCB1c2UgYSBzaGFyZWQgc2VjcmV0
IGtleS4gVGhhdOKAmXMgYWxzbyBmYWlybHkgZWFzeSBpZiBldmVyeW9uZSBrbm93cyB3aG8gZXZl
cnlvbmUgZWxzZSBpcywgYW5kIGhhcyBzeW1tZXRyaWMgb3IgcHVibGljIGtleXMgZm9yIGV2ZXJ5
b25lIGVsc2UuIEJ1dCBuZWl0aGVyIGFyZSBpZGVhbCBzb2x1dGlvbnMgKGVzcGVjaWFsbHkgdGhl
IGxhdHRlciB0aGF0IGhhcyBzZXJpb3VzIG92ZXJoZWFkcykuDQoNClRoZSBjb21iaW5hdGlvbiBv
ZiByZXF1aXJlbWVudCBhbmQgZGlmZmljdWx0eSBtYWtlcyBpdCBhIHBvc3NpYmxlIHN1YmplY3Qg
Zm9yIHRoZSBXRywgaWYgdGhlcmXigJlzIGVub3VnaCBzdXBwb3J0LiBCdXQgSSBkbyBub3QgZXhw
ZWN0IGFueXRoaW5nIHNlY3VyaXR5IHJlbGF0ZWQsIGFuZCBlc3BlY2lhbGx5IGNyeXB0byByZWxh
dGVkLCB0byBiZSBwbGFpbiBzYWlsaW5nLiBXZSB3b3VsZCBiZSBzdHJvbmdseSBhZHZpc2VkIHRv
IGdldCBzcGVjaWFsaXNlZCBpbnB1dC4NCg0KQmV5b25kIHRoYXQgb2YgY291cnNlIHRoZXJlIGlz
IGVuY3J5cHRpb24gb2YgdHJhZmZpYy4gQW4gZWFzaWVyIHByb2JsZW0gKGF0IGxlYXN0IHVuaWNh
c3QpIGluIHRoYXQgaXTigJlzIGEgc3RhbmRhcmQgSVAgcHJvYmxlbS4gS2V5IG1hbmFnZW1lbnQg
aXMgdGhlIGlzc3VlLiBUaGVyZSBhcmUgdGhpbmdzIHJlbGF0ZWQgdG8gdGhlIElCUyBkcmFmdCB0
aGF0IGNhbiBoZWxwIHRoZXJlLCBidXQgbm8gZG91YnQgb3RoZXJzLiAoSW4gZmFjdCBJIGtub3cg
b2YgYW5vdGhlciB1c2luZyBhbiBhbHRlcm5hdGl2ZSB0byB0aGF0IGZvcm0gb2YgSUJTLikNCg0K
SW4gc2hvcnQsIHdlIGhhdmUgc29tZSBpbnRlcmVzdCBoZXJlLiBEbyBvdGhlcnM/DQoNCkFzIEkg
bm90ZWQgYWJvdmUsIEkgc2FpZCBwYXRlbnQgYXBwbGljYXRpb24gbm90IGhhcmQgdG8gZmluZC4g
QnV0IGl04oCZcyBub3QgdGhlIG9ubHkgb25lIEnigJltIGEgY28taW52ZW50b3IgaW4uIChUaG91
Z2ggdGhlcmUgYXJlbuKAmXQgbWFueSwgYWJvdXQgdGhyZWUpLiBBbm90aGVyIG9uZSBtaWdodCBh
bHNvIGJlIGFuIGFyZWEgb2YgV0cgaW50ZXJlc3QsIGJ1dCBvbmUgdG9waWMgcGVyIGVtYWlsLg0K
DQpDaHJpc3RvcGhlcg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lw
YWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmll
cw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hy
aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl
bXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBU
ZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4N
Cnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFF
IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmds
YW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2Vh
cmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IFN0YW4gUmF0bGlm
ZiBbbWFpbHRvOnJhdGxpZmZzdGFuQGdtYWlsLmNvbV0NClNlbnQ6IDIyIEFwcmlsIDIwMTYgMTY6
NTENClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IEp1c3RpbiBEZWFuOyBtYW5l
dEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttYW5ldF0gUmVjaGFydGVyIERpc2N1c3Npb24NCg0K
DQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBv
dXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBp
bnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24g
YW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlv
biByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxz
IHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5j
b20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBk
Zj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0
aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsv
c2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3Vz
JTIwRW1haWxzLnBkZj4uDQpIZWxsbyBXRywNCg0KRG8gd2UgbmVlZCB0byBob2xkIGFuIGludGVy
aW0gbWVldGluZyAodmlhIFdlYkVYKSB0byBkaXNjdXNzPyBJJ2QgbGlrZSB0byBnZXQgb3Bpbmlv
bnMgb24gdGhlIGxpc3QgYWJvdXQgdGhhdC4gV2UnbGwgbmVlZCBhIGNvdXBsZSBvZiB3ZWVrcyB0
byBzY2hlZHVsZSwgYnV0IHdlIGNhbiBkbyB0aGF0Lg0KDQpPbmUgb3RoZXIgcG9pbnQgaW5saW5l
Og0KDQpPbiBGcmksIEFwciAyMiwgMjAxNiBhdCAxMTo0NSBBTSwgRGVhcmxvdmUsIENocmlzdG9w
aGVyIChVSykgPGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFy
bG92ZUBiYWVzeXN0ZW1zLmNvbT4+IHdyb3RlOg0KTXVsdGljYXN0IGlzIHRoZSBvYnZpb3VzIHRv
cCBpdGVtLiBMb3RzIG9mIHBvc3NpYmxlIGFwcHJvYWNoZXMsIHRpbWUgdG8gZGlzY3Vzcy4NCg0K
R2F0ZXdheXMgZm9yIEFPRFZ2MiBhdCBTdGFuZGFyZCBpcyBvYnZpb3VzbHkgbm90IHBvc3NpYmxl
IHNpbmNlIEFPRFZ2MiBpcyBnb2luZyB0byBiZSBFeHBlcmltZW50YWwgYXQgbW9zdC4NCg0KTWFu
YWdlbWVudCB3ZSBkaWQgb2YgY291cnNlIGhhdmUgYW4gTkhEUC9PTFNSdjIgZHJhZnQga2lsbGVk
IGJ5IEFELiBXaGljaCBzaW5jZSBOSERQL09MU1J2MiB1cyBhbGwgd2UgaGF2ZSAoU01GIGV4Y2Vw
dGVkKSB0aGF0IHdhcyBhIGJpdCB0cmlja3kuDQoNCkkgd291bGQgaGF2ZSB0byBtYWtlIGFuIElQ
UiBkZWNsYXJhdGlvbiB0byBzYXkgc29tZSBvZiB3aGF0IEkgbWlnaHQgaGF2ZSB0byBzYXkgYWJv
dXQgZW5jcnlwdGlvbi4gTm90IHRvZGF5Lg0KDQpVbmRlcnN0b29kLiBCdXQgcGxlYXNlIHJlbWVt
YmVyIC0gdGhlcmUncyBvbmx5IGFib3V0IGEgNS13ZWVrIGdhcCBub3cgYmVmb3JlIHRoZSBjaGFy
dGVyIG5lZWRzIHRvIGJlIGNvbXBsZXRlIGluIG9yZGVyIGZvciB0aGUgV0cgdG8gbWVldCBpbiBC
ZXJsaW4uDQoNClJlZ2FyZHMsDQpTdGFuDQoNCg0KDQoNCk1pc3NpbmcgZnJvbSB0aGUgbGlzdCBp
cyBhbnkgd29yayBvbiBPTFNSdjIgKG9yIE5IRFApLiBNVC1PTFNSdjIgaXMgZXhwZXJpbWVudGFs
LiBUaGF0IHdvdWxkIG5lZWQgaW1wbGVtZW50YXRpb24gdGVzdHMgdG8gYWR2YW5jZSB0byBQUy4g
QW55b25lIGludGVyZXN0ZWQgaW4gdGhhdCAoSeKAmW0gbm90IHNheWluZyBJIGNhbik/DQoNCk1v
cmUgYnJvYWRseSBvbiBPTFNSdjIgdGhlcmUgYXJlIHZhcmlvdXMgdGhpbmdzIHRoYXQgY291bGQg
YmUgZG9uZSwgYnV0IHdoYXQgaXMgcmVhbGx5IG5lZWRlZCBpcyBwZW9wbGUgd2l0aCBhIHJlYWwg
YXBwbGljYXRpb24uIEFueSB0aGF0IGV4aXN0IHdlcmUgZnJpZ2h0ZW5lZCBhd2F5IGZyb20gdGhp
cyBncm91cC4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVu
Z2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVsOiUyQjQ0JTIwJTI4
MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxt
YWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxp
ZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93
LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6
Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j
ZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJl
Z2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXks
IEdVMiA3WVANCg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPG1h
aWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEp1c3RpbiBEZWFuDQpT
ZW50OiAyMiBBcHJpbCAyMDE2IDE2OjA3DQpUbzogbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0
QGlldGYub3JnPg0KU3ViamVjdDogW21hbmV0XSBSZWNoYXJ0ZXIgRGlzY3Vzc2lvbg0KDQoNCioq
KiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBv
cmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVy
bmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkg
bGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJl
Z2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91
IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9o
b3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4N
CklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMg
cHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1
cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBF
bWFpbHMucGRmPi4NCioqKiBXQVJOSU5HICoqKg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNz
YWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb24uDQoNCkknbGwgc3Rh
cnQgdGhpbmdzIG9mZiBieSBmbG9hdGluZyB0aGUgZHJhZnQgcmUtY2hhcnRlciB3aGljaCB3YXMg
cHJlc2VudGVkIGluIFByYWd1ZS4NCg0KDQpUaGUgcHVycG9zZSBvZiB0aGUgTUFORVQgd29ya2lu
ZyBncm91cCBpcyB0byBzdGFuZGFyZGl6ZSBJUCByb3V0aW5nIHByb3RvY29sIGZ1bmN0aW9uYWxp
dHkgc3VpdGFibGUgZm9yIHdpcmVsZXNzIHJvdXRpbmcgYXBwbGljYXRpb24gd2l0aGluIGJvdGgg
c3RhdGljIGFuZCBkeW5hbWljIHRvcG9sb2dpZXMgd2l0aCBpbmNyZWFzZWQgZHluYW1pY3MgZHVl
IHRvIG5vZGUgbW90aW9uIG9yIG90aGVyIGZhY3RvcnMuDQoNCg0KDQpBcHByb2FjaGVzIGFyZSBp
bnRlbmRlZCB0byBiZSByZWxhdGl2ZWx5IGxpZ2h0d2VpZ2h0IGluIG5hdHVyZSwgc3VpdGFibGUg
Zm9yIG11bHRpcGxlIGhhcmR3YXJlIGFuZCB3aXJlbGVzcyBlbnZpcm9ubWVudHMsIGFuZCBhZGRy
ZXNzIHNjZW5hcmlvcyB3aGVyZSBNQU5FVHMgYXJlIGRlcGxveWVkIGF0IHRoZSBlZGdlcyBvZiBh
biBJUCBpbmZyYXN0cnVjdHVyZS4gSHlicmlkIG1lc2ggaW5mcmFzdHJ1Y3R1cmVzIChlLmcuLCBh
IG1peHR1cmUgb2YgZml4ZWQgYW5kIG1vYmlsZSByb3V0ZXJzKSBzaG91bGQgYWxzbyBiZSBzdXBw
b3J0ZWQgYnkgTUFORVQgc3BlY2lmaWNhdGlvbnMgYW5kIG1hbmFnZW1lbnQgZmVhdHVyZXMuDQoN
Cg0KDQpUaGUgTUFORVQgV0cgaXMgcmVzcG9uc2libGUgZm9yIHRoZSBtYWludGVuYW5jZSBvZiBP
TFNSdjIsIEFPRFZ2MiwgRExFUCBhbmQgTkhQRC4gT2YgcGFydGljdWxhciBpbnRlcmVzdDogYm9y
ZGVyIGJlaGF2aW9yIGJldHdlZW4gTUFORVQgbmV0d29ya3MgYW5kIGZpeGVkIElQIG5ldHdvcmsg
aW5mcmFzdHJ1Y3R1cmVzLCBlbmhhbmNlIEFPRFZ2MiBnYXRld2F5IGZ1bmN0aW9uYWxpdHk7IHNl
Y3VyaXR5IGVuaGFuY2VtZW50cywgZW5jcnlwdGlvbiBzZWN1cml0eSBleHRlbnNpb25zIGZvciBS
RkM1NDQ0Lg0KDQoNCg0KVGhlIE1BTkVUIFdHIHdpbGwgc3RhbmRhcmRpemUgYSBtdWx0aWNhc3Qg
TUFORVQgcHJvdG9jb2wgZnJhbWV3b3JrIGJhc2VkIG9uIHByZXZpb3VzIHdvcmsgYW5kIGxlc3Nv
bnMgbGVhcm5lZCBmb3Igc2NvcGVkIGZvcndhcmRpbmcgd2l0aGluIE1BTkVUIG5ldHdvcmtzLiAg
QXMgcGFydCBvZiB0aGlzIGZyYW1ld29yayB0aGUgV0cgd2lsbCBwcm9kdWNlIGEgd2VsbCBkZWZp
bmVkIE1BTkVUIG11bHRpY2FzdCBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIGJhc2UuDQoNCg0KDQpU
aGUgV0cgd2lsbCBwcm9kdWNlIGFuIGluZm9ybWF0aW9uYWwgZHJhZnQgb3V0bGluaW5nIGNoYWxs
ZW5nZXMgYW5kIGJlc3QgcHJhY3RpY2VzIGZvciBkZXBsb3lpbmcgYW5kIG1hbmFnaW5nIE1BTkVU
IG5ldHdvcmtzLg0KDQoNCg0KVGhlIE1BTkVUIFdHIHdpbGwgaW50ZXJhY3Qgd2l0aCB0aGUgUElN
IHdvcmtpbmcgZ3JvdXAgb24gaXNzdWVzIHJlbGF0aW5nIHRvIHRoZSBtdWx0aWNhc3Qgd29yay4g
IFRoZSBXRyB3aWxsIGFsc28gcGF5IGF0dGVudGlvbiB0byBvdGhlciBJRVRGIGFuZCBJUlRGIHdv
cmsgdGhhdCBpcyBhZGRyZXNzaW5nIHRvcGljcyByZWxhdGVkIHRvIE1BTkVUIGVudmlyb25tZW50
cy4NCg0KDQoNCkluIHN1bW1hcnksIHRoZSBXRyB3aWxsIGRldmVsb3AgdGhlIGZvbGxvd2luZyBk
cmFmdHM6DQoNCg0KDQpNQU5FVCBNYW5hZ2VtZW50IERvY3VtZW50IChJbmZvcm1hdGlvbmFsKQ0K
DQpNQU5FVCBNYWludGVuYW5jZQ0KDQogLSBSRkM1NDQ0IFNlY3VyaXR5IGV4dGVuc2lvbiAoU3Rh
bmRhcmRzKQ0KDQogLSBFbmhhbmNlZCBBT0RWdjIgZ2F0ZXdheSBleHRlbnNpb24gKFN0YW5kYXJk
cykNCg0KTUFORVQgTXVsdGljYXN0DQoNCiAtIE11bHRpY2FzdCBGSUIgKFN0YW5kYXJkcykNCg0K
DQoNCg0KDQpUaGlzIHdpbGwgbGlrZWx5IGJlIGNvbnNpZGVyZWQgdG9vIGJyb2FkIHRvIHBhc3Mu
ICBXZSB3aWxsIGxpa2VseSBuZWVkIHRvIGN1dCBzb21lIGFuZCBmb2N1cyB0aGUgd29yay4gIEZv
ciBtZSBwZXJzb25hbGx5IEkga25vdyBJIGhhdmUgdGhlIHRpbWUgYW5kIGJhY2tpbmcgdG8gd29y
ayBvbiB0aGUgTXVsdGljYXN0IHBpZWNlLg0KDQoNCg0KSnVzdGluDQoNCioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpU
aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50
ZW5kZWQNCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBu
b3QgdGhlIGludGVuZGVkDQpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lz
dGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4NCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNl
IGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3INCmRpc3RyaWJ1dGUgaXRzIGNvbnRl
bnRzIHRvIGFueSBvdGhlciBwZXJzb24uDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5l
dEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCg==

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1510GLKXM0002VGREEN_
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
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNo
YWlycyBhbmQgV0c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkganVzdCBuZWVkZWQgdG8gdG91Y2ggYmFzZSB3aXRoIHRo
ZSBhcHByb3ByaWF0ZSBwZXJzb24gaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgY2FuIGNvbmZpcm0gdGhhdCBJ
4oCZbSBhd2FyZSBvZiAoYW0gYW4gaW52ZW50b3Igb24pIGEgcGF0ZW50IGFwcGxpY2F0aW9uIHRo
YXQgaXMgcmVsYXRlZCB0byB0aGUgYXJlYSBvZiBlbmNyeXB0aW9uIGluIGFuIGFkIGhvYyBuZXR3
b3JrLiBBdCB0aGlzIHBvaW50IHdl4oCZcmUNCiBvbmx5IGRpc2N1c3Npbmcgd2hldGhlciB3ZSBz
aG91bGQgd29yayBpbiB0aGlzIGFyZWEsIHNvIGlzc3VlcyBvZiBpdHMgdXNlIGRvIG5vdCBjb21l
IHVwIG5vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPihEbyB5b3UgbmVlZCB0aGUgbnVtYmVyPyBJIGRvbuKAmXQgaGF2
ZSBpdCB0byBoYW5kIHRoaXMgc2Vjb25kOyBob3dldmVyIGdpdmVuIHRoYXQgSeKAmW0gbm90IGNh
bGxlZCBTbWl0aCBpdOKAmXMgcXVpdGUgZWFzeSB0byBmaW5kIC0gYnV0IHNlZSBiZWxvdy4pPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj5IYXZpbmcgc2FpZCB0aGF0LCBJIGNhbiBub3cgc2F5IHRoYXQgYSByZXF1aXJlbWVu
dCB0aGF0IHNvbWUgcGVvcGxlIEkga25vdyBoYXZlIGlzIHRoYXQgb2YgY29uY2VhbGluZyBpZGVu
dGl0eSBhbmQgdG9wb2xvZ3kvcm91dGluZyBpbmZvcm1hdGlvbi4gV2hpY2ggYWQgaG9jDQogcm91
dGluZyBwcm90b2NvbHMgdGVuZCB0byBmcmVlbHkgZGlzdHJpYnV0ZS4gVGhhdOKAmXMgZWFzeSBp
ZiB5b3UganVzdCB1c2UgYSBzaGFyZWQgc2VjcmV0IGtleS4gVGhhdOKAmXMgYWxzbyBmYWlybHkg
ZWFzeSBpZiBldmVyeW9uZSBrbm93cyB3aG8gZXZlcnlvbmUgZWxzZSBpcywgYW5kIGhhcyBzeW1t
ZXRyaWMgb3IgcHVibGljIGtleXMgZm9yIGV2ZXJ5b25lIGVsc2UuIEJ1dCBuZWl0aGVyIGFyZSBp
ZGVhbCBzb2x1dGlvbnMgKGVzcGVjaWFsbHkgdGhlDQogbGF0dGVyIHRoYXQgaGFzIHNlcmlvdXMg
b3ZlcmhlYWRzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBjb21iaW5hdGlvbiBvZiByZXF1aXJlbWVudCBhbmQg
ZGlmZmljdWx0eSBtYWtlcyBpdCBhIHBvc3NpYmxlIHN1YmplY3QgZm9yIHRoZSBXRywgaWYgdGhl
cmXigJlzIGVub3VnaCBzdXBwb3J0LiBCdXQgSSBkbyBub3QgZXhwZWN0IGFueXRoaW5nIHNlY3Vy
aXR5IHJlbGF0ZWQsDQogYW5kIGVzcGVjaWFsbHkgY3J5cHRvIHJlbGF0ZWQsIHRvIGJlIHBsYWlu
IHNhaWxpbmcuIFdlIHdvdWxkIGJlIHN0cm9uZ2x5IGFkdmlzZWQgdG8gZ2V0IHNwZWNpYWxpc2Vk
IGlucHV0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+QmV5b25kIHRoYXQgb2YgY291cnNlIHRoZXJlIGlzIGVuY3J5cHRp
b24gb2YgdHJhZmZpYy4gQW4gZWFzaWVyIHByb2JsZW0gKGF0IGxlYXN0IHVuaWNhc3QpIGluIHRo
YXQgaXTigJlzIGEgc3RhbmRhcmQgSVAgcHJvYmxlbS4gS2V5IG1hbmFnZW1lbnQgaXMgdGhlIGlz
c3VlLg0KIFRoZXJlIGFyZSB0aGluZ3MgcmVsYXRlZCB0byB0aGUgSUJTIGRyYWZ0IHRoYXQgY2Fu
IGhlbHAgdGhlcmUsIGJ1dCBubyBkb3VidCBvdGhlcnMuIChJbiBmYWN0IEkga25vdyBvZiBhbm90
aGVyIHVzaW5nIGFuIGFsdGVybmF0aXZlIHRvIHRoYXQgZm9ybSBvZiBJQlMuKTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
SW4gc2hvcnQsIHdlIGhhdmUgc29tZSBpbnRlcmVzdCBoZXJlLiBEbyBvdGhlcnM/PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij5BcyBJIG5vdGVkIGFib3ZlLCBJIHNhaWQgcGF0ZW50IGFwcGxpY2F0aW9uIG5vdCBoYXJkIHRv
IGZpbmQuIEJ1dCBpdOKAmXMgbm90IHRoZSBvbmx5IG9uZSBJ4oCZbSBhIGNvLWludmVudG9yIGlu
LiAoVGhvdWdoIHRoZXJlIGFyZW7igJl0IG1hbnksIGFib3V0IHRocmVlKS4gQW5vdGhlcg0KIG9u
ZSBtaWdodCBhbHNvIGJlIGFuIGFyZWEgb2YgV0cgaW50ZXJlc3QsIGJ1dCBvbmUgdG9waWMgcGVy
IGVtYWlsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0b3BoZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMwMDdFN0UiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9y
IFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl
IExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5
NCAmbmJzcDt8ICZuYnNwOzxiPkU6DQo8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3Zl
QGJhZXN5c3RlbXMuY29tIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBw
bGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRk
b3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5i
YWVzeXN0ZW1zLmNvbS9haSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0
ZW1zLmNvbS9haTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0
ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xh
bmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNl
YXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z
cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTdGFuIFJh
dGxpZmYgW21haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g
MjIgQXByaWwgMjAxNiAxNjo1MTxicj4NCjxiPlRvOjwvYj4gRGVhcmxvdmUsIENocmlzdG9waGVy
IChVSyk8YnI+DQo8Yj5DYzo8L2I+IEp1c3RpbiBEZWFuOyBtYW5ldEBpZXRmLm9yZzxicj4NCjxi
PlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBSZWNoYXJ0ZXIgRGlzY3Vzc2lvbjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQg
Mi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9
InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr
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+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvIFdHLCZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8gd2Ug
bmVlZCB0byBob2xkIGFuIGludGVyaW0gbWVldGluZyAodmlhIFdlYkVYKSB0byBkaXNjdXNzPyBJ
J2QgbGlrZSB0byBnZXQgb3BpbmlvbnMgb24gdGhlIGxpc3QgYWJvdXQgdGhhdC4gV2UnbGwgbmVl
ZCBhIGNvdXBsZSBvZiB3ZWVrcyB0byBzY2hlZHVsZSwgYnV0IHdlIGNhbiBkbyB0aGF0LiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P
bmUgb3RoZXIgcG9pbnQgaW5saW5lOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPk9uIEZyaSwgQXByIDIyLCAyMDE2IGF0IDExOjQ1IEFNLCBEZWFybG92ZSwgQ2hy
aXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl
bXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+
Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXVsdGlj
YXN0IGlzIHRoZSBvYnZpb3VzIHRvcCBpdGVtLiBMb3RzIG9mIHBvc3NpYmxlIGFwcHJvYWNoZXMs
IHRpbWUgdG8gZGlzY3Vzcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HYXRld2F5cyBmb3IgQU9EVnYyIGF0IFN0
YW5kYXJkIGlzIG9idmlvdXNseSBub3QgcG9zc2libGUgc2luY2UgQU9EVnYyIGlzIGdvaW5nIHRv
IGJlIEV4cGVyaW1lbnRhbA0KIGF0IG1vc3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWFuYWdlbWVudCB3ZSBk
aWQgb2YgY291cnNlIGhhdmUgYW4gTkhEUC9PTFNSdjIgZHJhZnQga2lsbGVkIGJ5IEFELiBXaGlj
aCBzaW5jZSBOSERQL09MU1J2MiB1cyBhbGwNCiB3ZSBoYXZlIChTTUYgZXhjZXB0ZWQpIHRoYXQg
d2FzIGEgYml0IHRyaWNreS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxkIGhhdmUgdG8gbWFrZSBhbiBJ
UFIgZGVjbGFyYXRpb24gdG8gc2F5IHNvbWUgb2Ygd2hhdCBJIG1pZ2h0IGhhdmUgdG8gc2F5IGFi
b3V0IGVuY3J5cHRpb24uDQogTm90IHRvZGF5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VbmRlcnN0b29kLiBCdXQg
cGxlYXNlIHJlbWVtYmVyIC0gdGhlcmUncyBvbmx5IGFib3V0IGEgNS13ZWVrIGdhcCBub3cgYmVm
b3JlIHRoZSBjaGFydGVyIG5lZWRzIHRvIGJlIGNvbXBsZXRlIGluIG9yZGVyIGZvciB0aGUgV0cg
dG8gbWVldCBpbiBCZXJsaW4uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdGFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND
Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy
Z2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pc3NpbmcgZnJvbSB0aGUgbGlzdCBpcyBhbnkgd29yayBv
biBPTFNSdjIgKG9yIE5IRFApLiBNVC1PTFNSdjIgaXMgZXhwZXJpbWVudGFsLiBUaGF0IHdvdWxk
IG5lZWQNCiBpbXBsZW1lbnRhdGlvbiB0ZXN0cyB0byBhZHZhbmNlIHRvIFBTLiBBbnlvbmUgaW50
ZXJlc3RlZCBpbiB0aGF0IChJ4oCZbSBub3Qgc2F5aW5nIEkgY2FuKT88L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5N
b3JlIGJyb2FkbHkgb24gT0xTUnYyIHRoZXJlIGFyZSB2YXJpb3VzIHRoaW5ncyB0aGF0IGNvdWxk
IGJlIGRvbmUsIGJ1dCB3aGF0IGlzIHJlYWxseSBuZWVkZWQgaXMNCiBwZW9wbGUgd2l0aCBhIHJl
YWwgYXBwbGljYXRpb24uIEFueSB0aGF0IGV4aXN0IHdlcmUgZnJpZ2h0ZW5lZCBhd2F5IGZyb20g
dGhpcyBncm91cC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv
dHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+
Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0K
QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFu
PjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
N0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3
RCI+OiAmbmJzcDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5NCIgdGFy
Z2V0PSJfYmxhbmsiPiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8L2E+DQogJm5ic3A7fCAmbmJzcDs8
Yj5FOiA8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0
YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+PGJyPg0KPC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxp
ZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93
LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFl
c3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5
MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
M0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVn
aXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRm
b3JkLCBTdXJyZXksIEdVMiA3WVA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1hbmV0DQogW21haWx0bzo8YSBo
cmVmPSJtYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0
LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gRGVhbjxi
cj4NCjxiPlNlbnQ6PC9iPiAyMiBBcHJpbCAyMDE2IDE2OjA3PGJyPg0KPGI+VG86PC9iPiA8YSBo
cmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9y
ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW21hbmV0XSBSZWNoYXJ0ZXIgRGlzY3Vzc2lvbjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoy
LjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu
dGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG87dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndo
aXRlIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdB
Uk5JTkcgKioqPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndo
aXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMg
bWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIg
ZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlu
a3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48
L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZs
YWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2Vp
dmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9o
b3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIiB0
YXJnZXQ9Il9ibGFuayI+DQpoZXJlPC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwg
dGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9p
bnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMv
RG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiIHRhcmdl
dD0iX2JsYW5rIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNv
bGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzoxLjBwdCA0LjBwdCAxLjBwdCA0LjBwdCI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50ZXIiPg0K
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPio8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qKg0KPC9zcGFuPjwvc3Ryb25nPjwvc3Bhbj48
c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldBUk5JTkcNCjwvc3Bhbj48L3N0cm9u
Zz48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij4qKio8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RVhURVJOQUwg
RU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6
YXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4uPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5JJ2xsIHN0YXJ0IHRoaW5ncyBvZmYg
YnkgZmxvYXRpbmcgdGhlIGRyYWZ0IHJlLWNoYXJ0ZXIgd2hpY2ggd2FzIHByZXNlbnRlZCBpbiBQ
cmFndWUuICZuYnNwOzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siPlRoZSBwdXJwb3NlIG9mIHRoZSBNQU5FVCB3b3JraW5nIGdyb3VwIGlz
IHRvIHN0YW5kYXJkaXplIElQIHJvdXRpbmcgcHJvdG9jb2wgZnVuY3Rpb25hbGl0eSBzdWl0YWJs
ZSBmb3Igd2lyZWxlc3Mgcm91dGluZyBhcHBsaWNhdGlvbiB3aXRoaW4gYm90aCBzdGF0aWMgYW5k
IGR5bmFtaWMgdG9wb2xvZ2llcyB3aXRoIGluY3JlYXNlZCBkeW5hbWljcyBkdWUgdG8gbm9kZSBt
b3Rpb24gb3Igb3RoZXIgZmFjdG9ycy4mbmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QXBwcm9hY2hlcyBhcmUgaW50ZW5k
ZWQgdG8gYmUgcmVsYXRpdmVseSBsaWdodHdlaWdodCBpbiBuYXR1cmUsIHN1aXRhYmxlIGZvciBt
dWx0aXBsZSBoYXJkd2FyZSBhbmQgd2lyZWxlc3MgZW52aXJvbm1lbnRzLCBhbmQgYWRkcmVzcyBz
Y2VuYXJpb3Mgd2hlcmUgTUFORVRzIGFyZSBkZXBsb3llZCBhdCB0aGUgZWRnZXMgb2YgYW4gSVAg
aW5mcmFzdHJ1Y3R1cmUuIEh5YnJpZCBtZXNoIGluZnJhc3RydWN0dXJlcyAoZS5nLiwgYSBtaXh0
dXJlIG9mIGZpeGVkIGFuZCBtb2JpbGUgcm91dGVycykgc2hvdWxkIGFsc28gYmUgc3VwcG9ydGVk
IGJ5IE1BTkVUIHNwZWNpZmljYXRpb25zIGFuZCBtYW5hZ2VtZW50IGZlYXR1cmVzLjwvc3Bhbj48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRo
ZSBNQU5FVCBXRyBpcyByZXNwb25zaWJsZSBmb3IgdGhlIG1haW50ZW5hbmNlIG9mIE9MU1J2Miwg
QU9EVnYyLCBETEVQIGFuZCBOSFBELiBPZiBwYXJ0aWN1bGFyIGludGVyZXN0OiBib3JkZXIgYmVo
YXZpb3IgYmV0d2VlbiBNQU5FVCBuZXR3b3JrcyBhbmQgZml4ZWQgSVAgbmV0d29yayBpbmZyYXN0
cnVjdHVyZXMsIGVuaGFuY2UgQU9EVnYyIGdhdGV3YXkgZnVuY3Rpb25hbGl0eTsgc2VjdXJpdHkg
ZW5oYW5jZW1lbnRzLCBlbmNyeXB0aW9uIHNlY3VyaXR5IGV4dGVuc2lvbnMgZm9yIFJGQzU0NDQu
IDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPlRoZSBNQU5FVCBXRyB3aWxsIHN0YW5kYXJkaXplIGEgbXVsdGljYXN0IE1BTkVUIHBy
b3RvY29sIGZyYW1ld29yayBiYXNlZCBvbiBwcmV2aW91cyB3b3JrIGFuZCBsZXNzb25zIGxlYXJu
ZWQgZm9yIHNjb3BlZCBmb3J3YXJkaW5nIHdpdGhpbiBNQU5FVCBuZXR3b3Jrcy4mbmJzcDsgQXMg
cGFydCBvZiB0aGlzIGZyYW1ld29yayB0aGUgV0cgd2lsbCBwcm9kdWNlIGEgd2VsbCBkZWZpbmVk
IE1BTkVUIG11bHRpY2FzdCBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIGJhc2UuPC9zcGFuPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIFdH
IHdpbGwgcHJvZHVjZSBhbiBpbmZvcm1hdGlvbmFsIGRyYWZ0IG91dGxpbmluZyBjaGFsbGVuZ2Vz
IGFuZCBiZXN0IHByYWN0aWNlcyBmb3IgZGVwbG95aW5nIGFuZCBtYW5hZ2luZyBNQU5FVCBuZXR3
b3Jrcy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIj5UaGUgTUFORVQgV0cgd2lsbCBpbnRlcmFjdCB3aXRoIHRoZSBQSU0gd29ya2lu
ZyBncm91cCBvbiBpc3N1ZXMgcmVsYXRpbmcgdG8gdGhlIG11bHRpY2FzdCB3b3JrLiZuYnNwOyBU
aGUgV0cgd2lsbCBhbHNvIHBheSBhdHRlbnRpb24gdG8gb3RoZXIgSUVURiBhbmQgSVJURiB3b3Jr
IHRoYXQgaXMgYWRkcmVzc2luZyB0b3BpY3MgcmVsYXRlZCB0byBNQU5FVCBlbnZpcm9ubWVudHMu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+SW4gc3VtbWFyeSwgdGhlIFdHIHdpbGwgZGV2ZWxvcCB0aGUgZm9sbG93aW5nIGRyYWZ0
czo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsYWNrIj5NQU5FVCBNYW5hZ2VtZW50IERvY3VtZW50IChJbmZvcm1hdGlvbmFsKTwvc3Bhbj48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1BTkVUIE1h
aW50ZW5hbmNlIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPiZuYnNwOy0gUkZDNTQ0NCBTZWN1cml0eSBleHRlbnNpb24gKFN0YW5kYXJkcyk8
L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4g
LSBFbmhhbmNlZCBBT0RWdjIgZ2F0ZXdheSBleHRlbnNpb24gKFN0YW5kYXJkcyk8L3NwYW4+PG86
cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5NQU5FVCBNdWx0
aWNhc3Q8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIj4gLSBNdWx0aWNhc3QgRklCIChTdGFuZGFyZHMpPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhpcyB3aWxsIGxp
a2VseSBiZSBjb25zaWRlcmVkIHRvbyBicm9hZCB0byBwYXNzLiZuYnNwOyBXZSB3aWxsIGxpa2Vs
eSBuZWVkIHRvIGN1dCBzb21lIGFuZCBmb2N1cyB0aGUgd29yay4mbmJzcDsgRm9yIG1lIHBlcnNv
bmFsbHkgSSBrbm93IEkgaGF2ZSB0aGUgdGltZSBhbmQgYmFja2luZyB0byB3b3JrIG9uIHRoZSBN
dWx0aWNhc3QgcGllY2UuJm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkp1c3Rpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KVGhpcyBlbWFpbCBhbmQgYW55
IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPg0KcmVjaXBp
ZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k
ZWQ8YnI+DQpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBu
b3RpZnkgdGhlIHNlbmRlci48YnI+DQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBm
b3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPg0KZGlzdHJpYnV0ZSBpdHMgY29udGVu
dHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi
Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy
Pg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3Jn
Ij5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1510GLKXM0002VGREEN_--


From nobody Mon Apr 25 06:15: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 F2AFF12D5D2 for ; Mon, 25 Apr 2016 06:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.143
X-Spam-Level: 
X-Spam-Status: No, score=-1.143 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, TRACKER_ID=1.306] 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 Aj3bHrUAYpPN for ; Mon, 25 Apr 2016 06:14:54 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 EA7E212D5D0 for ; Mon, 25 Apr 2016 06:14:53 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id g133so182556542ywb.2 for ; Mon, 25 Apr 2016 06:14:53 -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=Nl/nySKk326Lx7AVRDcFwaGqvLak/zdjFCEq57NGvgs=; b=XAoECzY48DFsBbGsxkLrWNnSDkIsCi3GewAOfCNziLAhbxfXTvVybgt1k6hl1PJ+g7 M1m5mxcRldHbVVo6Ubc/Bp7EkgjJQjUqjrhK2AcAWecDFnzvSZahdsBzf4J+JcWaDbCo aWvGjnvnBHkhVxlRiDBD/8B+gQHgnjTnznWpxA1FXHZ5/b2xSnmh8W+D4L6qaRVV38d8 NtgKK0nrsEDR52yqt68dt+J/7HLrglYhOx0utbN5i+CEe0j14LediLaI6bleigVbeKP4 bNAVYYXbR+seYxJ3P+FcZQryETL/s+AEXVhB3eTx8tXJBAwD/RNL/XXjzIa/bpRQUlFb tg4g==
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=Nl/nySKk326Lx7AVRDcFwaGqvLak/zdjFCEq57NGvgs=; b=X0x/FyJhF9vGxbHxotL3zeVjoUC0cais8cXCJL09/hOqhd25t7ApiKhNId9qnLKo4+ kzYdirWaypbNI6s97K1op7zrcZOXKn31CVMhKW5tlVu71PY2CJuwXzx+a6rGbnutBFsQ CiMjYvpM+0GtwlqILq12bJsREbR4zQsqO0hZpIyxNuN4m3NP1HoQJZI81EYaEMui8eWs +bMH2yfPCvYiGyGnZ0WpxDmgHKdd7CY+p3DBb+hsHGj7y9/iKcsvvf7AklUBxpY0wA9G Ads0px2f/FhPIQssjPfwx4e+U9f/tK7t75IMu2ysZU1rh7jTHbw4J47I88pRI1uU99Fe BZEw==
X-Gm-Message-State: AOPr4FVGl8UiZpc1KQVcVq7rn+B72asPJ7LL4i0pEx/q84H8s4ER/ak7pD5x6V97sY61pMGaTt4oePY+4HsMww==
MIME-Version: 1.0
X-Received: by 10.176.4.20 with SMTP id 20mr19753627uav.125.1461590092934; Mon, 25 Apr 2016 06:14:52 -0700 (PDT)
Received: by 10.176.65.40 with HTTP; Mon, 25 Apr 2016 06:14:52 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>     
Date: Mon, 25 Apr 2016 14:14:52 +0100
Message-ID: 
From: Victoria Mercieca 
To: Jiazi YI 
Content-Type: multipart/alternative; boundary=001a114fd8864bf6c605314ef6ed
Archived-At: 
Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 13:14:59 -0000

--001a114fd8864bf6c605314ef6ed
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Jiazi,




On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI  wrote:

> Hi,
>
> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>> With regard to your validity time point, we here have a tradeoff. If you
>> allow that feature, it significantly impacts on the approach that was
>> coming together on as best you can end to end encryption.
>>
>>
>>
>> So the question is, is this a feature that=E2=80=99s really wanted? Unfo=
rtunately
>> I think we know that the answer to that is, we don=E2=80=99t know becaus=
e we don=E2=80=99t
>> have any experience. My view would be that in the tradeoff of an unteste=
d
>> feature (unless I=E2=80=99m wrong about that) and the security complicat=
ion,
>> security wins and drop the feature. If there is some real requirement, t=
hen
>> there=E2=80=99s a discussion. (Questions like how often the intermediate=
 routers
>> actually have any knowledge - typically links break for unexpected rathe=
r
>> than expected reasons. Andan intermediate router could possibly use a
>> validity time to influence its behaviour.) Note that dropping the abilit=
y
>> of intermediate routers to modify/set still allows validity times per ro=
ute
>> to be set at endpoints.
>>
>
> I agree with Chris' concern.
> The ValidityTime is optional, which makes the integrity protection hard.
> Furthermore, it gives a potential attack vector: as all the routers in a
> path will take the shortest validityTime, a compromised router can set th=
e
> the validityTime to a very short value, which will make the route install=
ed
> along the path became invalid (very soon).
>
> On the other hand, I'm not sure this option will give us much help. Chris
> mentioned much knowledge intermediate router would have to decide this
> value (and how much sense the value would make).
> Another issue is, a route to a destination might be updated by different
> sources. For example, in the network below:
>
> A----B-----C
>
> A first establish a route to B with long validity time. Then A initiates =
a
> route discovery to C. C tends to set a short validity time, which will ma=
ke
> the route between B and A expire earlier than expected.
> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered or
> not.
>
>

Not sure I follow here.

Currently, the validity time of the route between A and B would not
affected by a short validity time of a route between A and C. Validity
times are per-route, and the route A-B and the route A-C are separate.

If we switched to a validity time per neighbor (so that we can keep
validity time separate from route advertisements) as I mentioned in the
email below, then the validity of a route between A and C would be affected
if there was a short validity time between A and B. But, if B will only
route for a certain amount of time, then the route between A and C will of
course be affected. Is it best to know in advance that there's a time
limit, or just deal with RERRs when they happen?




>
>>
>> With regard to the acknowledgements, the problem (with regard to
>> security) comes from trying to do two jobs with the same message - end t=
o
>> end route advertisement and hop by hop acknowledgement. I understand the
>> reasons - saving bytes and message types. (I would have to study the
>> protocol really hard to identify if any message types can be folded
>> together and recognised by content rather than type efficiently. This I =
do
>> not expect to do.) Again a tradeoff. This one is in discussion space,
>> though that needs people who understand both sides of the issue, includi=
ng
>> the details of the bidirectionality mechanism. Of course, as has been sa=
id,
>> we need one of those.
>>
>
> I haven't finished my review of the latest draft, and I don't get the
> necessity of AckReq and the corresponding multicast RREP yet.
> If possible, this "optional" field should be avoided.
>
>
To give an overview of AckReq and RREP:

Since AODVv2 requires bidirectional links, this is the way to determine if
a link is bidirectional.

A----B----C

1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install a
route to OrigAddr but they dont yet know if it's valid because they dont
know if the link to their next hop is available in the reverse direction.
2) C creates the RREP. Since it doesnt know if the link to B is
bidirectional, it includes the AckReq (an address to indicate that it
expects to receive a RREP_Ack from B).
3) B receives the RREP, installs a route to TargAddr and marks it as valid,
since it knows the link to C is bidirectional, because the RREQ went in one
direction and the RREP came in the other. B also sends the RREP_Ack to C
and forwards the RREP to A (and might change the message to indicate its
own AckReq - ie that it requires an ack from A).
4) C receives the RREP_Ack from B, and therefore knows that B received the
RREP, therefore the link is bidirectional. C can then mark its route to
OrigAddr as valid.
5) Similarly, A receives the RREP, installs the route to TargAddr and sends
an RREP_Ack to B.
6) B receives the RREP_Ack and marks its route to OrigAddr as valid.

Alternatively, in step 2, if C knows the link to B is bidirectional
(perhaps from some earlier route discovery), it doesnt need to put the
AckReq in the RREP. Then in step 3, since B doesnt know if the link to A is
bidirectional, it changes the message to add the AckReq address, in order
to get an RREP_Ack from A.

If we want to avoid changing the message, we'll need to look at forwarding
the RREP as-is, and creating a second message to solicit an RREP_Ack, in
order to verify that the link is bidirectional before marking the route to
OrigAddr as valid.

Kind regards,
Victoria.




> 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
>>
>>
>>
>> *From:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
>> *Sent:* 23 April 2016 10:55
>> *To:* Christopher Dearlove
>> *Cc:* ietf@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc
>> Networks mailing list
>>
>> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>>
>>
>>
>> **** 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
>> .*
>>
>> Hi Chris,
>>
>>
>>
>> These have both been in the draft in some form since before I got
>> involved... but I'll do my best to explain.
>>
>>
>>
>> - For Validity Time, its a way to advertise that you would only support
>> the route contained in the message for a certain period of time. The
>> originator might use this, but the draft was written to allow any
>> intermediate node to be able to add it or update it too. The route creat=
ed
>> in the Local Route Set has an expiration time associated with it, based =
on
>> the received validity time.
>>
>> - For the AckReq address, its so that you can add into a RREP a request
>> for an acknowledgement, so that you don't have to have a different messa=
ge
>> type altogether for working out whether links to neighbors are
>> bidirectional, and also, since you only care about bidirectionality on
>> routes that are being set up, you dont need to constantly monitor all
>> neighbors.
>>
>>
>>
>>
>>
>> In order to avoid the potential AckReq-related changes to each message,
>> maybe we do need to introduce a different message specifically for this.=
 We
>> could maybe use RREP_Ack to both request and acknowledge? It means an ex=
tra
>> message of control traffic that needs to be sent, maybe one extra messag=
e
>> per hop on the path of a RREP, but it could still be limited to neighbor=
s
>> which have participated in the route discovery rather than monitoring al=
l
>> neighbors at all times.
>>
>>
>>
>> This message could maybe also include "I'm happy to route anywhere for a
>> certain amount of time", sort of like willingness in OLSR/OLSRv2. So
>> instead of having a validity time per route, its a validity time per
>> neighbor. Then, for RREQ and RREP, only the metric value would change in
>> transit, as discussed. However, that leads to some issues with deciding
>> what a route's expiration time is. You might know how long the next hop
>> router is valid for, but what if a router beyond that, which was also pa=
rt
>> of the route, had a lower validity time? You couldn't determine the real
>> validity time. Do we remove the route expiration time altogether to avoi=
d
>> this issue? In which case, we would have to rely on RERR messages being
>> sent for routes which become invalid when the neighbor's validity time h=
as
>> expired? So neighbor validity time expiration is treated the same as a l=
ink
>> break.
>>
>>
>>
>> What do you think?
>>
>>
>>
>> Kind regards,
>>
>> Victoria.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
>> chris@mnemosyne.demon.co.uk> wrote:
>>
>> Pretty much all of the discussion has been assuming only a metric value
>> change. With multiple things changing many of the ideas go out of the
>> window. That reinforces the point about not making specifications now th=
at
>> might turn out to be wrong for ICVs.
>>
>>
>>
>> Ignoring how this misunderstanding happened, I'll start by asking why.
>> Metric changing I understand. Why the other two? (there's a partial
>> explanation of one). What alternatives have people implemented in
>> comparable protocols?
>>
>> --
>>
>> Christopher Dearlove
>>
>> christopher.dearlove@gmail.com (iPhone)
>>
>> chris@mnemosyne.demon.co.uk (home)
>>
>>
>> On 23 Apr 2016, at 00:26, Victoria Mercieca  wrote=
:
>>
>> Hi all,
>>
>>
>>
>> Continued in this thread because the other one seems to be more about TL=
V
>> types and metric type numbers, whereas this is about
>> regeneration/forwarding.
>>
>>
>>
>> To recap, in the current draft, there are 3 things that might change at
>> each hop:
>> - the metric value (happens in RREQ and RREP),
>> - adding/changing Validity Time using the Validity Time TLV (can happen
>> in RREQ and RREP),
>> - adding an address (and corresponding value in the AddressType TLV to
>> indicate how to interpret the address) to indicate the address from whic=
h
>> an RREP_Ack is expected, to accomplish the bidirectionality check (can
>> happen in RREP).
>>
>> If we define a certain portion of the message as immutable and include
>> the ICV to verify that part, end to end:
>> - The metric value would be excluded from the ICV since it needs changin=
g
>> at each hop.
>> - Would adding a Validity Time TLV at an intermediate hop be acceptable?
>> The whole TLV could be removed in order to calculate the ICV?
>>
>> - Would adding an address cause issues for the ICV, because it's in the
>> address block? Could the rule be "if it contains an AckReq address, remo=
ve
>> it (and the corresponding value in the AddressType TLV), before checking
>> the ICV", is that OK? Or would we need to avoid touching the ICV'ed part=
 of
>> the message altogether, maybe put the AckReq address in a separate Addre=
ss
>> Block, with an extra AddressType TLV following that address block? Is th=
ere
>> a way to accomplish this?
>>
>>
>>
>> Also, to be thorough, do we need to consider RERR messages while we
>> discuss regeneration vs forwarding?
>>
>> - RERR (sent when a link breaks) is a way of saying "I've lost my route
>> so I'm telling others" and "you were my next hop, so now I've also lost =
my
>> route, I'll tell others", etc. It's going to be tailored at each step to
>> include the relevant routes that got deleted, it's not one message being
>> sent end-to-end like RREQ and RREP are.
>>
>> - However, RERR (sent when a source of traffic is sending data on a rout=
e
>> which comes through you, and you want to tell the Packet Source's router=
 to
>> delete the route) could be seen as an end-to-end message which all
>> intermediate routers learn from, similar to RREQ and RREP. It reports on=
e
>> route, and doesn't need changing at intermediate hops, so could be
>> protected with ICV.
>>
>> - Would it be OK to only require a message ICV if a PktSource address wa=
s
>> included, i.e. when the message needs to go via a number of intermediate
>> hops to PktSource's router? All other RERRs are intended to be one-hop
>> messages, which may in turn prompt other one-hop messages, etc..., and a
>> packet ICV might be more appropriate?
>>
>>
>>
>> Kind regards,
>>
>> Victoria.
>>
>>
>>
>> On Thu, Mar 17, 2016 at 5:26 PM,  wrote:
>>
>>
>>
>> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>>
>>
>> Yes, I meant AODVv2, thanks for the catch.
>>
>>
>>
>> So is your (Thomas) proposed base specification a hop count only metric?
>>
>>
>>
>> No, the would be silly as base specification, given that hop count mostl=
y
>> is useless.
>>
>>
>>
>> As base specification I would simply say =E2=80=9CInclude a Metric Type =
Message
>> TLV with a value field, and a 7182 Message TLV & Timestamp=E2=80=9D as w=
e do in
>> OLSRv2 (with the appropriate verbiage as to generation and processing).
>>
>>
>>
>> With the message generated by the originator of the RREQ/RREP and *not*
>> deconstructed/reconstructed/reordered (as is the risk with =E2=80=9Crege=
neration)
>> allows knowing that it would be *only* that metric field being modified
>> (other than hop count/limit) for when eventually writing up the extensio=
n.
>>
>>
>>
>> (Actually doesn=E2=80=99t the current specification only define hop coun=
t, or has
>> that changed in latest draft?)
>>
>>
>>
>> No. That is one of the issues I raise in my original. For some reason, i=
t
>> cites RFC6551, which is a ROLL document and which has in its abstract th=
at:
>>
>>
>>
>>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>>
>>    compared with traditional wired and ad hoc networks that require the
>>
>>    specification of new routing metrics and constraints.
>>
>>
>>
>> I.e. this document cites a metric document which clearly claims to be
>> inapplicable in ad hoc networks. I note that this is another thing I=E2=
=80=99ve
>> raised for years without seeing it attempted resolved.
>>
>>
>>
>> Best,
>>
>>
>>
>> Thomas
>>
>>
>>
>>
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>> ]
>> *Sent:* 17 March 2016 17:10
>> *To:* Dearlove, Christopher (UK)
>> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>>
>>
>>
>> **** 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 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>>
>>
>> OK, so we have a message that mutates by:
>>
>> - Modifying hop count/limit.
>>
>> - Modifying a metric value.
>>
>> Anything else?
>>
>>
>>
>> As mutating (other than hop count/limit) messages aren=E2=80=99t covered=
 by 5444
>> or any derivative document (but only recommended against, not banned) th=
at
>> you may need to make the message otherwise immutable (no deconstruction =
and
>> rebuilding, other than guaranteed unchanging) that would have to be
>> specified by AODVv2. (Easy to say, but needs saying.)
>>
>>
>>
>> With you so far.
>>
>>
>>
>> Then that information is not in a guaranteed fixed location given by a
>> simple offset. So any signature algorithm that finds it and ignores it o=
r
>> aggregates on it is specific to OLSRv2.
>>
>>
>>
>> Surely you mean AODVv2
>>
>>
>>
>> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AODVv2
>> specialised variant. Which is the sort of thing that the message specifi=
c
>> TLV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cbut i=
gnore the value of
>> this specific TLV should it occur=E2=80=9D being in the general space. H=
owever it
>> can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like th=
at TLV,
>> except if an X TLV is present, set its value field to zero=E2=80=9D).
>>
>>
>>
>> Messy, but could work.
>>
>>
>>
>> Not that messy, actually, although clearly not as nice as =E2=80=9Cfixed=
 offset=E2=80=9D.
>>
>>
>>
>> That said, I am arguing for the base spec being:
>>
>>
>>
>>             =E2=80=9Cmake the message otherwise immutable (no deconstruc=
tion and
>> rebuilding, other
>>
>>              than guaranteed unchanging)=E2=80=9D which is afforded by f=
orwarding
>>
>>
>>
>>                                     +
>>
>>
>>
>>             RFC7182 Timestamps and ICVs.
>>
>>
>>
>>                                     +
>>
>>
>>
>>             RFC7183 style text bringing it all together.
>>
>>
>>
>> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would v=
ery be an
>> experimental extension.
>>
>>
>>
>> What I object to is, if the base spec specifically renders such
>> extensions impossible
>>
>>
>>
>>
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *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:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
>> ]
>> *Sent:* 17 March 2016 16:48
>> *To:* Dearlove, Christopher (UK)
>> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
>> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>>
>>
>>
>> **** 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
>> .*
>>
>> Hi all,
>>
>>
>>
>> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com>:
>>
>>
>>
>> Good point about whether you just pass on one cost or a set of costs. As
>> I said, not looked at details - I will, when time permits. One cost is m=
uch
>> easier, and yes, it reduces the fixed size aggregated signatures problem=
 to
>> =E2=80=9Cjust=E2=80=9D one of computational load.
>>
>>
>>
>> For the record, Thomas=E2=80=99 understanding is correct; the cost is on=
e
>> aggregated value.
>>
>>
>>
>> Best regards,
>>
>> Lotte Steenrbink
>>
>>
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>> ]
>> *Sent:* 17 March 2016 16:38
>> *To:* Dearlove, Christopher (UK)
>> *Cc:* Mobile Ad Hoc Networks mailing list
>> *Subject:* Re: Message integrity and message mutability (was RE: [manet]
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>>
>>
>>
>> **** 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 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>>
>>
>> I appreciate Thomas=E2=80=99s comments about the limitations of message
>> regeneration, but I would be a bit less absolute.
>>
>>
>>
>> The issues over end to end authentication and more advanced signatures
>> are valid. I need to read the given reference on aggregate signatures to
>> increase my knowledge (thanks for it), but my understanding of the
>> possibilities in this field may offer a solution to the problem, but wit=
h
>> some other issues (possibly including a new type of TLV).
>>
>>
>>
>> But the hop count/limit point I don=E2=80=99t fully agree with, you can
>> regenerate with an incremented/decremented count/limit, which leaves the
>> ability to prevent messages propagating indefinitely, including expandin=
g
>> ring searches, and retains the ability to use RFC 5497 interval and
>> validity times that might be useful with an expanding ring search (or mi=
ght
>> not).
>>
>>
>>
>> But the key issue is that AODVv2 wants to accumulate metrics. I still
>> haven=E2=80=99t got to the bottom of many details here, but let=E2=80=99=
s for the moment
>> just consider that conceptually.
>>
>>
>>
>> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft attempts=
 to do an end to
>> end of some information, not this information. I=E2=80=99m not sure if t=
hat=E2=80=99s
>> useful (and the specialised format is better avoided if possible). Other
>> approaches are hop by hop (might as well use packet signatures) and shar=
ed
>> key (might as well go hop by hop). Pairwise signatures for each pair of
>> routers I=E2=80=99m discounting as scaling terribly. In the interests of
>> completeness let=E2=80=99s mention not accumulating metrics, which puts =
us back to
>> hop count and that=E2=80=99s not ideal either.
>>
>>
>>
>> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=80=
=99ve seen about
>> aggregating, but that has some issues of its own, even apart from
>> computational load.) I=E2=80=99d love to be proved wrong - someone with =
the perfect
>> solution to come along.
>>
>>
>>
>> Which means that either we make an arbitrary choice - which will be
>> disagreed with, but needs discussing first - or create something flexibl=
e.
>> Unfortunately flexible in that regard constrains in others, e.g. some
>> (many? most?) aggregating signatures need fixed data sizes (which we can=
 do
>> by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but th=
at has a cost too).
>>
>>
>>
>> I have been told by people much more well versed in this than I in
>> cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>>
>>
>>
>> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does t=
hat mean that the
>> message grows as it is being forwarded, and that the recipient of a
>> RREQ/RREP will know the individual costs of each path segment? My
>> understanding is, that the recipient will get =E2=80=9Cthe sum the costs=
 of each
>> path segment=E2=80=9D which should be fitting within a fixed size?
>>
>>
>>
>> Thomas
>>
>>
>>
>>
>>
>>
>>
>>
>> Sorry, no answers, just comments. And I=E2=80=99m not addressing Thomas=
=E2=80=99s later
>> points here.
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *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 *ietf@thomasclausen.org
>> *Sent:* 17 March 2016 16:00
>> *To:* Mobile Ad Hoc Networks mailing list
>> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of big
>> ticket Items
>>
>>
>>
>>
>>
>> **** 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.
>>
>>
>>
>> Dear all,
>>
>>
>>
>> Apologies for not having gotten this done sooner - day-job leaving few
>> spare cycles.
>>
>>
>>
>> I=E2=80=99ve previously offered reviews and comments, and some of those =
have been
>> addressed in the latest I-D =E2=80=94 others have not, but should be. I =
recall that
>> there was some mail attempting to rebut parts of the review, and I will =
dig
>> it out and reply to that.
>>
>>
>>
>> With that being said, I have reviewed the latest version of the document=
,
>> and full details will be forthcoming. There=E2=80=99re a couple of
>> big-ticket/architectural items that I want to address up front, as I
>> believe that before we have those hammered out, it will be useless to go
>> into details. Note, I do not claim that this is an exhaustive list of =
=E2=80=9Cbig
>> ticket items=E2=80=9D, but that=E2=80=99s as far as I have gotten in thi=
nking this through.
>>
>>
>>
>> I also bring these up as they are items that have been brought up
>> repeatedly over the past years, but not resolved nor discussed.
>>
>>
>>
>> *Loops*
>>
>> Just to bring this out: I share Chris=E2=80=99 worry about conflicting a=
nd
>> concurrent statements from the authors on =E2=80=9CThere are no loops po=
ssible=E2=80=9D and
>> =E2=80=9CWe need to fix two situations where loops can occur=E2=80=9D an=
d =E2=80=9Cwe are still
>> investigating some loop conditions=E2=80=9D
>>
>>
>>
>> I particularly worry that this is not a discussion had in public, but
>> apparently in some other forum=E2=80=A6
>>
>>
>>
>>
>>
>> *Intermediate Route Replies, and all of section 10*
>>
>> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=80=
=9D, which is
>> incoherent with the intended status indicated for this document.
>>
>>
>>
>> Specifically, and this is not unrelated to the point about loops above,
>> intermediate RREPs (section 10.3) are a potential source for loops.
>>
>>
>>
>> Expanding Ring Multicast (section 10.1) is not documented in a way that
>> can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=E2=
=80=9D below, it is
>> in the present form of this protocol impossible), etc.
>>
>>
>>
>>
>>
>> *Forwarding-vs-regeneration*
>>
>> Recent exchanges on the list made me understand that protocol control
>> messages are *not* forwarded, but are consumed at each hop, then a new
>> message with (almost-but-not-quite) the same content is generated and
>> transmitted.
>>
>>
>>
>> I have thought some more on this (& read some of the exchanges on the
>> list on this topic by Chris, Ulrich, and others), and I am convinced tha=
t
>> this is not the right way to go, *at least* for the following reasons:
>>
>>
>>
>>
>>
>>             o          *It renders the hop-limit/hop-count fields in the
>> RFC5444 message header useless.*
>>
>>                         This would not be bad if the functionality
>> offered by those fields was not useful
>>
>>                         =E2=80=94 sadly, it is. For example, for scope l=
imited
>> flooding (expanding ring search, and
>>
>>                         such) which may be of interest, and which requir=
e
>> hop-limit.
>>
>>                         A hop-count field may also provide a =E2=80=9Cch=
eap=E2=80=9D (in
>> terms of overhead) additional piece
>>
>>                         of information to use conjunctively with a =E2=
=80=9Creal=E2=80=9D
>> metric.
>>
>>
>>
>>                         The only practical solution would be to
>> re-introduce these functions by way of inserting a
>>
>>                         MessageTLV =E2=80=94 which (i) is not specified =
in this
>> document, and (ii) which would just
>>
>>                         serve to render messages bigger than strictly
>> needed.
>>
>>
>>
>>                         Scope limited flooding  does seem to be a
>> necessary requirement, if for no
>>
>>                         other reason than to prevent information from
>> =E2=80=9Ccirculating forever in the network=E2=80=9D.
>>
>>
>>
>>             o          *It makes end-to-end authentication unnecessarily
>> hard.*
>>
>>                         I think Chris called this out already, but it
>> bears repeating: S generates a message
>>
>>                         (say, a RREQ), and includes an ICV calculated
>> over the content of the message.
>>
>>                         For any recipient to be able to validate the ICV=
,
>> the message has to be exactly
>>
>>                         the same =E2=80=94 not just in content, but in s=
tructure
>> =E2=80=94 as what was generated.
>>
>>
>>
>>                         =E2=80=9CRegenerating=E2=80=9D rather than =E2=
=80=9Cforwarding=E2=80=9D messages
>> means, that the intermediate
>>
>>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ m=
ay chose a
>> different structure (e.g., include TLVs
>>
>>                         in a different order).
>>
>>
>>
>>                         The proposal from
>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>>
>>                         is to add constraints on (i) the set of elements
>> to include in a signature and (ii) the
>>
>>                         order of these elements.
>>
>>
>>
>>                         One problem with that approach is (i): if an
>> extension adds a message TLV, or an
>>
>>                         Address TLV, to a message, then that will not be
>> =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>>
>>                         Rather for *each* extension developed, an
>> =E2=80=9Cupdates e2esec=E2=80=9D clause needs to be done.
>>
>>
>>
>>                         I=E2=80=99d say that this approach would be pron=
e to
>> errors =E2=80=94 and add entropy to the process
>>
>>                         of designing protocol extensions. The
>> alternative, a message being generated by the
>>
>>                         source and *forwarded* (as we do in OLSRv2, for
>> example) would allow ICV TLVs
>>
>>                         (even, allow reuse of those specified for OLSRv2=
)
>> for covering a message and
>>
>>                         extensions.
>>
>>
>>
>>                         =E2=80=9CBut what about the metrics value which =
will
>> change on each hop=E2=80=9D, you may say?
>>
>>                         Fortunately, that is relatively easy to handle:
>> simply zero out the value of that TLV when
>>
>>                         generating or verifying the ICV MessageTLV. And
>> use Packet-TLVs for hop-by-hop
>>
>>                         authentication, if needed (but, see below).
>>
>>
>>
>>             o          *It prevents the use of more clever/advanced
>> signature schemes/ICVs*
>>
>>                         Aggregate signature algorithms (
>> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>>
>>                         exist, and an interesting use-case can be found
>> in also reactive protocols, allowing verifying
>>
>>                         not =E2=80=9Cjust=E2=80=9D the end points, but a=
lso the
>> intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D
>>
>>                         discussed above, or something smarter).
>>
>>                         Regeneration of messages, rather than forwarding=
,
>> renders that impossible (or, if used,
>>
>>                         updating to
>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>>
>>
>>
>> There are other reasons, but the above are those that jump at me as
>> immediate show-stoppers.
>>
>>
>>
>> I do honestly not see what possible benefit there is from =E2=80=9Cregen=
eration=E2=80=9D
>> =E2=80=94 but I see very clear inconveniences, and security is not the l=
east of
>> these. Insisting on =E2=80=9Cregeneration=E2=80=9D requires development =
of =E2=80=9Cnon-general
>> workarounds=E2=80=9D as pointed out above.
>>
>>
>>
>> *Security Considerations*
>>
>> This is an always thorny subject. When OLSRv2 was going through the
>> process we got a thorough education in how little we knew about security
>> from the SEC-ADs, and had to spend about a year or so developing RFC7183=
.
>> The bottom line is, that this protocol needs its =E2=80=9CRFC7183  equiv=
alent=E2=80=9D,
>> either as part of the main document, or as an independent document.
>> currently, that is not the case.
>>
>>
>>
>> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration from =
RFC7183
>> might be aw good idea, as that was the most recent that went through the
>> SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to implement=E2=
=80=9D security
>> mechanism most be specified (I think the right term was =E2=80=9CMUST im=
plement,
>> SHOULD use=E2=80=9D), in sufficient detail to ensure interoperable imple=
mentations.
>>
>>
>>
>> As an example, both [RFC6130] and [RFC7181] set out that that:
>>
>>
>>
>>       On receiving a ... message, a router MUST first check if the
>>
>>       message is invalid for processing by this router
>>
>>
>>
>> and then proceed to give a number of conditions that, each, will lead to
>> a rejection of the message as "badly formed and therefore invalid for
>> processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That ga=
ve a =E2=80=9Chook=E2=80=9D for
>> RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message gene=
ration.
>>
>>
>>
>> If I was to do RFC7181/RFC6130 today, I would include that directly into
>> the protocol specifications. It turned out to be more overhead (and slow
>> down publication anyways) to do it as separate documents.
>>
>>
>>
>> Secondly, we need to be a lot more rigid in terms of what ICVs,
>> Timestamps, etc. are added/removed, and what that brings.
>>
>>
>>
>> For example (with the assumption that messages are *forwarded* and *not*
>> regenerated), this could be one option:
>>
>>
>>
>>                         o          When a RREQ, RREP message is
>> generated, add an ICV Message TLV, which is calculated 
>>
>>                                      =E2=80=A6(take inspiration from RFC=
7183 here)
>>
>>
>>
>> ...
>>
>> [Message clipped]
>> _______________________________________________
>> 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
>>
>>
>>
>> ********************************************************************
>> 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
>>
>>
>

--001a114fd8864bf6c605314ef6ed
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Jiazi,




On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <ietf@ji=
aziyi.com> wrote:
Hi,=C2=A0

On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christo=
pher (UK) <chris.dearlove@baesystems.com> wrote:=












With regard to your =
validity time point, we here have a tradeoff. If you allow that feature, it=
 significantly impacts on the approach that was coming together
 on as best you can end to end encryption.


=C2=A0=



So the question is, =
is this a feature that=E2=80=99s really wanted? Unfortunately I think we kn=
ow that the answer to that is, we don=E2=80=99t know because we don=E2=80=
=99t have any
 experience. My view would be that in the tradeoff of an untested feature (=
unless I=E2=80=99m wrong about that) and the security complication, securit=
y wins and drop the feature. If there is some real requirement, then there=
=E2=80=99s a discussion. (Questions like how often
 the intermediate routers actually have any knowledge - typically links bre=
ak for unexpected rather than expected reasons. Andan intermediate router c=
ould possibly use a validity time to influence its behaviour.) Note that dr=
opping the ability of intermediate
 routers to modify/set still allows validity times per route to be set at e=
ndpoints.

I agree wi=
th Chris' concern.
The ValidityTime is optional, which makes =
the integrity protection hard. Furthermore, it gives a potential attack vec=
tor: as all the routers in a path will take the shortest validityTime, a co=
mpromised router can set the the validityTime to a very short value, which =
will make the route installed along the path became invalid (very soon).=C2=
=A0

On the other hand, I'm not sure this optio=
n will give us much help. Chris mentioned much knowledge intermediate route=
r would have to decide this value (and how much sense the value would make)=
.=C2=A0
Another issue is, a route to a destination might be updat=
ed by different sources. For example, in the network below:

<=
/div>
A----B-----C

A first establish a route to B with long validity time. The=
n A initiates a route discovery to C. C tends to set a short validity time,=
 which will make the route between B and A expire earlier than expected.=C2=
=A0
Is this a problem? Maybe yes, maybe no -- I'm not sure it=
's considered or not.=C2=A0
=C2=A0

Not sure I follow here.

Cur=
rently, the validity time of the route between A and B would not affected b=
y a short validity time of a route between A and C. Validity times are per-=
route, and the route A-B and the route A-C are separate.

=
If we switched to a validity time per neighbor (so that we can keep validit=
y time separate from route advertisements) as I mentioned in the email belo=
w, then the validity of a route between A and C would be affected if there =
was a short validity time between A and B. But, if B will only route for a =
certain amount of time, then the route between A and C will of course be af=
fected. Is it best to know in advance that there's a time limit, or jus=
t deal with RERRs when they happen?


=C2=A0=

<=
/u>


=C2=A0=



With regard to the a=
cknowledgements, the problem (with regard to security) comes from trying to=
 do two jobs with the same message - end to end route advertisement
 and hop by hop acknowledgement. I understand the reasons - saving bytes an=
d message types. (I would have to study the protocol really hard to identif=
y if any message types can be folded together and recognised by content rat=
her than type efficiently. This
 I do not expect to do.) Again a tradeoff. This one is in discussion space,=
 though that needs people who understand both sides of the issue, including=
 the details of the bidirectionality mechanism. Of course, as has been said=
, we need one of those.

<=
div>I haven't finished my review of the latest draft, and I don't g=
et the necessity of AckReq and the corresponding multicast RREP yet.=C2=A0<=
/div>
If possible, this "optional" field should be avoided.=
=C2=A0


To give =
an overview of AckReq and RREP:

Since AODVv2 requires bid=
irectional links, this is the way to determine if a link is bidirectional.<=
br>
A----B----C

1) A sends RREQ, B forwards=
 it, C receives the RREQ. B and C both install a route to OrigAddr but they=
 dont yet know if it's valid because they dont know if the link to thei=
r next hop is available in the reverse direction.
2) C create=
s the RREP. Since it doesnt know if the link to B is bidirectional, it incl=
udes the AckReq (an address to indicate that it expects to receive a RREP_A=
ck from B).
3) B receives the RREP, installs a route to TargA=
ddr and marks it as valid, since it knows the link to C is bidirectional, b=
ecause the RREQ went in one direction and the RREP came in the other. B als=
o sends the RREP_Ack to C and forwards the RREP to A (and might change the =
message to indicate its own AckReq - ie that it requires an ack from A).
4) C receives the RREP_Ack from B, and therefore knows that B r=
eceived the RREP, therefore the link is bidirectional. C can then mark its =
route to OrigAddr as valid.
5) Similarly, A receives the RREP=
, installs the route to TargAddr and sends an RREP_Ack to B.
=
6) B receives the RREP_Ack and marks its route to OrigAddr as valid.

Alternatively, in step 2, if C knows the link to B i=
s bidirectional (perhaps from some earlier route discovery), it doesnt need=
 to put the AckReq in the RREP. Then in step 3, since B doesnt know if the =
link to A is bidirectional, it changes the message to add the AckReq addres=
s, in order to get an RREP_Ack from A.

If we want to avoi=
d changing the message, we'll need to look at forwarding the RREP as-is=
, and creating a second message to solicit an RREP_Ack, in order to verify =
that the link is bidirectional before marking the route to OrigAddr as vali=
d. 

Kind regards,
Victoria.
<=
br>
=C2=A0
regards

Jiazi
=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, 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:<=
span style=3D"font-size:10pt;font-family:"Tahoma","sans-seri=
f"" lang=3D"EN-US"> Victoria Mercieca [mailto:vmercieca0@gmail.com]


Sent: 23 April 2016 10:55

To: Christopher Dearlove

Cc: ietf=
@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc Networks =
mailing list


Subject: Re: [manet] Message integrity and message mutability (was R=
E: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)=



=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>








Hi Chris,




=C2=A0






These have both been in the draft in some form since=
 before I got involved... but I'll do my best to explain.=





=C2=A0






- For Validity Time, its a way to advertise that you=
 would only support the route contained in the message for a certain period=
 of time. The originator might use this, but the draft was written to allow=
 any intermediate node to be able
 to add it or update it too. The route created in the Local Route Set has a=
n expiration time associated with it, based on the received validity time.<=
u>






- For the AckReq address, its so that you can add in=
to a RREP a request for an acknowledgement, so that you don't have to h=
ave a different message type altogether for working out whether links to ne=
ighbors are bidirectional, and also, since
 you only care about bidirectionality on routes that are being set up, you =
dont need to constantly monitor all neighbors.






=C2=A0






=C2=A0






In order to avoid the potential AckReq-related chang=
es to each message, maybe we do need to introduce a different message speci=
fically for this. We could maybe use RREP_Ack to both request and acknowled=
ge? It means an extra message of control
 traffic that needs to be sent, maybe one extra message per hop on the path=
 of a RREP, but it could still be limited to neighbors which have participa=
ted in the route discovery rather than monitoring all neighbors at all time=
s.=C2=A0






=C2=A0






This message could maybe also include "I'm =
happy to route anywhere for a certain amount of time", sort of like wi=
llingness in OLSR/OLSRv2. So instead of having a validity time per route, i=
ts a validity time per neighbor. Then, for RREQ
 and RREP, only the metric value would change in transit, as discussed. How=
ever, that leads to some issues with deciding what a route's expiration=
 time is. You might know how long the next hop router is valid for, but wha=
t if a router beyond that, which was
 also part of the route, had a lower validity time? You couldn't determ=
ine the real validity time. Do we remove the route expiration time altogeth=
er to avoid this issue? In which case, we would have to rely on RERR messag=
es being sent for routes which become
 invalid when the neighbor's validity time has expired? So neighbor val=
idity time expiration is treated the same as a link break.





=C2=A0






What do you think?






=C2=A0






Kind regards,






Victoria.






=C2=A0






=C2=A0






=C2=A0






=C2=A0






=C2=A0








=C2=A0




On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlov=
e <chri=
s@mnemosyne.demon.co.uk> wrote:






Pretty much all of the discussion has been assuming =
only a metric value change. With multiple things changing many of the ideas=
 go out of the window. That reinforces the point about not making specifica=
tions now that might turn out to be
 wrong for ICVs.






=C2=A0






Ignoring how this misunderstanding happened, I'l=
l start by asking why. Metric changing I understand. Why the other two? (th=
ere's a partial explanation of one). What alternatives have people impl=
emented in comparable protocols?



-- =C2=A0




Christopher Dearlove












On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmail.com> wrote:
















Hi all,






=C2=A0






Continued in this thread because the other one seems=
 to be more about TLV types and metric type numbers, whereas this is about =
regeneration/forwarding.






=C2=A0






To recap, in the current draft, there are 3 things t=
hat might change at each hop:


- the metric value (happens in RREQ and RREP), 

- adding/changing Validity Time using the Validity Time TLV (can happen in =
RREQ and RREP),


- adding an address (and corresponding value in the AddressType TLV to indi=
cate how to interpret the address) to indicate the address from which an RR=
EP_Ack is expected, to accomplish the bidirectionality check (can happen in=
 RREP).



If we define=C2=A0a certain portion of the message as immutable and include=
 the ICV to verify that part, end to end:


- The metric value would be excluded from the ICV since it needs changing a=
t each hop.=C2=A0

- Would adding a Validity Time TLV at an intermediate hop be acceptable? Th=
e whole TLV could be removed in order to calculate the ICV?



- Would adding an address cause issues for the ICV, =
because it's in the address block? Could the rule be "if it contai=
ns an AckReq address, remove it (and the corresponding value in the Address=
Type TLV), before checking the ICV", is that
 OK? Or would we need to avoid touching the ICV'ed part of the message =
altogether, maybe put the AckReq address in a separate Address Block, with =
an extra AddressType TLV following that address block? Is there a way to ac=
complish this?






=C2=A0






Also, to be thorough, do we need to consider RERR me=
ssages while we discuss regeneration vs forwarding?=C2=A0






- RERR (sent when a link breaks) is a way of saying =
"I've lost my route so I'm telling others" and "you =
were my next hop, so=C2=A0now=C2=A0I've also lost my route, I'll te=
ll others", etc. It's going to be tailored at each step to include=
 the relevant
 routes that got deleted, it's not one message being sent end-to-end li=
ke RREQ and RREP are.=C2=A0






- However, RERR (sent when a source of traffic is se=
nding data on a route which comes through you, and you want to tell the Pac=
ket Source's router to delete the route) could be seen as an end-to-end=
 message which all intermediate routers
 learn from, similar to RREQ and RREP. It reports one route, and doesn'=
t need changing at intermediate hops, so could be protected with ICV.






- Would it be OK to only require a message ICV if a =
PktSource address was included, i.e. when the message needs to go via a num=
ber of intermediate hops to PktSource's router? All other RERRs are int=
ended to be one-hop messages, which may
 in turn prompt other one-hop messages, etc..., and a packet ICV might be m=
ore appropriate?






=C2=A0




Kind regards,




Victoria.






=C2=A0




On Thu, Mar 17, 2016 at 5:26 PM, <ietf@thomasclausen.org>=
 wrote:




=C2=A0








On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK)=
 <chr=
is.dearlove@baesystems.com> wrote:




=C2=A0








Yes, I meant AODVv2,=
 thanks for the catch.






=C2=A0=







So is your (Thomas) =
proposed base specification a hop count only metric?











=C2=A0




No, the would be silly as base specification, given =
that hop count mostly is useless.






=C2=A0






As base specification I would simply say =E2=80=9CIn=
clude a Metric Type Message TLV with a value field, and a 7182 Message TLV =
& Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage =
as to generation and processing).=C2=A0






=C2=A0






With the message generated by the originator of the =
RREQ/RREP and *not* deconstructed/reconstructed/reordered (as is the risk w=
ith =E2=80=9Cregeneration) allows knowing that it would be *only* that metr=
ic field being modified (other than hop count/limit)
 for when eventually writing up the extension.






=C2=A0=













(Actually doesn=E2=
=80=99t the current specification only define hop count, or has that change=
d in latest draft?)










=C2=A0




No. That is one of the issues I raise in my original=
. For some reason, it cites RFC6551, which is a ROLL document and which has=
 in its abstract that:






=C2=A0






=C2=A0=C2=A0 Low-Power and Lossy Networks (LLNs) have unique character=
istics


=C2=A0=C2=A0 compared with traditional wired and ad hoc networks that =
require the


=C2=A0=C2=A0 specification of new routing metrics and constraints. =





=C2=A0






I.e. this document cites a metric document which cle=
arly claims to be inapplicable in ad hoc networks. I note that this is anot=
her thing I=E2=80=99ve raised for years without seeing it attempted resolve=
d.






=C2=A0






Best,






=C2=A0






Thomas






=C2=A0






=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:=C2=A0chris.dearlove@baesystem=
s.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<=
/span>






=C2=A0=











From:=C2=A0ietf@thomasclausen.org=C2=
=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 17:10

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Lotte Steenbrink; Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)










=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=C2=A0=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=A0












On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:








=C2=A0










OK, so we have a mes=
sage that mutates by:










- Modifying hop coun=
t/limit.










- Modifying a metric=
 value.










Anything else?










=C2=A0=











As mutating (other t=
han hop count/limit) messages aren=E2=80=99t covered by 5444 or any derivat=
ive document (but only recommended against, not banned) that you may
 need to make the message otherwise immutable (no deconstruction and rebuil=
ding, other than guaranteed unchanging) that would have to be specified by =
AODVv2. (Easy to say, but needs saying.)














=C2=A0








With you so far.










=C2=A0







Then that informatio=
n is not in a guaranteed fixed location given by a simple offset. So any si=
gnature algorithm that finds it and ignores it or aggregates
 on it is specific to OLSRv2.










=C2=A0








Surely you mean AODVv2










=C2=A0







So standard 7182 ICV=
s don=E2=80=99t do the job, you would need an AODVv2 specialised variant. W=
hich is the sort of thing that the message specific TLV space is there
 for, I=E2=80=99d be strongly against a =E2=80=9Cbut ignore the value of th=
is specific TLV should it occur=E2=80=9D being in the general space. Howeve=
r it can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like =
that TLV, except if an X TLV is present, set its value field to
 zero=E2=80=9D).










=C2=A0=











Messy, but could wor=
k.










=C2=A0








Not that messy, actually, although clearly not as ni=
ce as =E2=80=9Cfixed offset=E2=80=9D.










=C2=A0










That said, I am arguing for the base spec being:<=
/u>










=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=E2=80=9Cmake the message otherwise immutable (no deco=
nstruction and rebuilding, other=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=A0than guaranteed unchanging)=E2=80=9D which is af=
forded by forwarding










=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7182 Timestamps and ICVs.










=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7183 style text bringing it all together.=











=C2=A0










The =E2=80=9Caggregated signatures around mutable fi=
eld=E2=80=9D would very be an experimental extension.










=C2=A0










What I object to is, if the base spec specifically r=
enders such extensions impossible










=C2=A0










=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:=C2=A0chris.dearlove@baesystem=
s.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<=
/span>








=C2=A0=















From:=C2=A0Lotte Steenbrink [mailto:lotte.=
steenbrink@fu-berlin.de]=C2=A0

Sent:=C2=A017 March 2016 16:48

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0ietf@thomasclausen.org; Mobile Ad =
Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=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=C2=A0=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.










Hi all,












=C2=A0
















Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher=
 (UK) <chris.dearlove@baesystems.com>=
:












=C2=A0














Good point about whe=
ther you just pass on one cost or a set of costs. As I said, not looked at =
details - I will, when time permits. One cost is much easier,
 and yes, it reduces the fixed size aggregated signatures problem to =E2=80=
=9Cjust=E2=80=9D one of computational load.


















=C2=A0














For the record, Thomas=E2=80=99 understanding is cor=
rect; the cost is one aggregated value.=C2=A0














=C2=A0














Best regards,=C2=A0














Lotte Steenrbink































=C2=A0=











--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________=
_____________________________________________



T: =C2=A0+44 (0)1245 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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<=
/span>










=C2=A0=



















From:=C2=A0ietf@thomasclausen.org=C2=
=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 16:38

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: Message integrity and message mutability (was RE: =
[manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)


















=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=C2=A0=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=A0




















On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:
















=C2=A0


















I appreciate Thomas=
=E2=80=99s comments about the limitations of message regeneration, but I wo=
uld be a bit less absolute.


















=C2=A0=



















The issues over end =
to end authentication and more advanced signatures are valid. I need to rea=
d the given reference on aggregate signatures to increase my
 knowledge (thanks for it), but my understanding of the possibilities in th=
is field may offer a solution to the problem, but with some other issues (p=
ossibly including a new type of TLV).


















=C2=A0=



















But the hop count/li=
mit point I don=E2=80=99t fully agree with, you can regenerate with an incr=
emented/decremented count/limit, which leaves the ability to prevent
 messages propagating indefinitely, including expanding ring searches, and =
retains the ability to use RFC 5497 interval and validity times that might =
be useful with an expanding ring search (or might not).


















=C2=A0=



















But the key issue is=
 that AODVv2 wants to accumulate metrics. I still haven=E2=80=99t got to th=
e bottom of many details here, but let=E2=80=99s for the moment just consid=
er
 that conceptually.


















=C2=A0=



















It=E2=80=99s hard to=
 handle end to end. Charlie=E2=80=99s draft attempts to do an end to end of=
 some information, not this information. I=E2=80=99m not sure if that=E2=80=
=99s useful (and the
 specialised format is better avoided if possible). Other approaches are ho=
p by hop (might as well use packet signatures) and shared key (might as wel=
l go hop by hop). Pairwise signatures for each pair of routers I=E2=80=99m =
discounting as scaling terribly. In the
 interests of completeness let=E2=80=99s mention not accumulating metrics, =
which puts us back to hop count and that=E2=80=99s not ideal either.=



















=C2=A0=



















I don=E2=80=99t thin=
k there is an ideal solution. (I like ideas I=E2=80=99ve seen about aggrega=
ting, but that has some issues of its own, even apart from computational lo=
ad.)
 I=E2=80=99d love to be proved wrong - someone with the perfect solution to=
 come along.


















=C2=A0=



















Which means that eit=
her we make an arbitrary choice - which will be disagreed with, but needs d=
iscussing first - or create something flexible. Unfortunately
 flexible in that regard constrains in others, e.g. some (many? most?) aggr=
egating signatures need fixed data sizes (which we can do by defining a TLV=
 that =E2=80=9Cfills up=E2=80=9D with hop count, but that has a cost too).<=
/span>






















=C2=A0
















I have been told by people much more well versed in =
this than I in cryptology, that the correct answer is =E2=80=9Csome=E2=80=
=9D.


















=C2=A0


















That said, "AODVv2 wants to accumulate metrics=
=E2=80=9D =E2=80=94 does that mean that the message grows as it is being fo=
rwarded, and that the recipient of a RREQ/RREP will know the individual cos=
ts of each path segment? My understanding is, that the recipient
 will get =E2=80=9Cthe sum the costs of each path segment=E2=80=9D which sh=
ould be fitting within a fixed size?


















=C2=A0


















Thomas


















=C2=A0











































=C2=A0=



















Sorry, no answers, j=
ust comments. And I=E2=80=99m not addressing Thomas=E2=80=99s later points =
here.


















=C2=A0=













--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________=
_____________________________________________



T: =C2=A0+44 (0)1245 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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<=
/span>












=C2=A0=























From:=C2=A0manet [mailto:manet-bounces@ietf.org]=C2=A0On
 Behalf Of=C2=A0ietf@thomasclausen.org

Sent:=C2=A017 March 2016 16:00

To:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0[manet] draft-ietf-manet-aodvv2-13 review - a couple o=
f big ticket Items






















=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=C2=A0=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*=
**

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












=C2=A0




















Dear all,




















=C2=A0






















Apologies for not having gotten this done sooner - d=
ay-job leaving few spare cycles.






















=C2=A0






















I=E2=80=99ve previously offered reviews and comments=
, and some of those have been addressed in the latest I-D =E2=80=94 others =
have not, but should be. I recall that there was some mail attempting to re=
but parts of the review, and I will dig it out and
 reply to that.






















=C2=A0






















With that being said, I have reviewed the latest ver=
sion of the document, and full details will be forthcoming. There=E2=80=99r=
e a couple of big-ticket/architectural items that I want to address up fron=
t, as I believe that before we have those
 hammered out, it will be useless to go into details. Note, I do not claim =
that this is an exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D, but =
that=E2=80=99s as far as I have gotten in thinking this through.<=
/u>






















=C2=A0






















I also bring these up as they are items that have be=
en brought up repeatedly over the past years, but not resolved nor discusse=
d.






















=C2=A0






















Loops






















Just to bring this out: I share Chris=E2=80=99 worry=
 about conflicting and concurrent statements from the authors on =E2=80=9CT=
here are no loops possible=E2=80=9D and =E2=80=9CWe need to fix two situati=
ons where loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating =
some loop
 conditions=E2=80=9D






















=C2=A0






















I particularly worry that this is not a discussion h=
ad in public, but apparently in some other forum=E2=80=A6






















=C2=A0






















=C2=A0
























Intermediate Route Replies, and all of section=
 10






















Section 10 contains a set of =E2=80=9Cvaguely specif=
ied extensions=E2=80=9D, which is incoherent with the intended status indic=
ated for this document.=C2=A0






















=C2=A0






















Specifically, and this is not unrelated to the point=
 about loops above, intermediate RREPs (section 10.3) are a potential sourc=
e for loops.






















=C2=A0






















Expanding Ring Multicast (section 10.1) is not docum=
ented in a way that can be implemented (and also, see =E2=80=9CForwarding-v=
s-regeneration=E2=80=9D below, it is in the present form of this protocol i=
mpossible), etc.
























=C2=A0






















=C2=A0






















Forwarding-vs-regeneration






















Recent exchanges on the list made me understand that=
 protocol control messages are *not* forwarded, but are consumed at each ho=
p, then a new message with (almost-but-not-quite) the same content is gener=
ated and transmitted.






















=C2=A0






















I have thought some more on this (& read some of=
 the exchanges on the list on this topic by Chris, Ulrich, and others), and=
 I am convinced that this is not the right way to go,=C2=A0at least=
=C2=A0for the following reasons:






















=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It renders the hop-limit/hop-count fields in the RFC5444 messag=
e header useless.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0This would not be bad if the functionality offered by tho=
se fields was not useful






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=94 sadly, it is. For example, for scope limited fl=
ooding (expanding ring search, and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0such) which may be of interest, and which require hop-lim=
it.=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0A hop-count field may also provide a =E2=80=9Ccheap=E2=80=
=9D (in terms of overhead) additional piece






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of information to use conjunctively with a =E2=80=9Creal=
=E2=80=9D metric.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The only practical solution would be to re-introduce thes=
e functions by way of inserting a






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0MessageTLV =E2=80=94 which (i) is not specified in this d=
ocument, and (ii) which would just






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0serve to render messages bigger than strictly needed.<=
/u>






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Scope limited flooding =C2=A0does seem to be a necessary =
requirement, if for no






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0other reason than to prevent information from =E2=80=9Cci=
rculating forever in the network=E2=80=9D.






















=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It makes end-to-end authentication unnecessarily hard.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I think Chris called this out already, but it bears repea=
ting: S generates a message=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(say, a RREQ), and includes an ICV calculated over the co=
ntent of the message.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0For any recipient to be able to validate the ICV, the mes=
sage has to be exactly






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0the same =E2=80=94 not just in content, but in structure =
=E2=80=94 as what was generated.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforwa=
rding=E2=80=9D messages means, that the intermediate






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose =
a different structure (e.g., include TLVs






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0in a different order).






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The proposal from=C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00=























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0is to add constraints on (i) the set of elements to inclu=
de in a signature and (ii) the






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0order of these elements.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0One=C2=A0problem with that approach is (i): if an extensi=
on adds a message TLV, or an=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Address TLV, to a message, then that will not be =E2=80=
=9Ccovered=E2=80=9D by the proposed e2esec TLV.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Rather for *each* extension developed, an =E2=80=9Cupdate=
s e2esec=E2=80=9D clause needs to be done.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I=E2=80=99d say that this approach would be prone to erro=
rs =E2=80=94 and add entropy to the process






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of designing protocol extensions. The alternative, a mess=
age being generated by the






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0source and *forwarded* (as we do in OLSRv2, for example) =
would allow ICV TLVs=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(even, allow reuse of those specified for OLSRv2) for cov=
ering a message and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0extensions.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CBut what about the metrics value which will chan=
ge on each hop=E2=80=9D, you may say?






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Fortunately, that is relatively easy to handle: simply ze=
ro out the value of that TLV when






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0generating or verifying the ICV MessageTLV. And use Packe=
t-TLVs for hop-by-hop=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0authentication, if needed (but, see below).=























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It prevents the use of more clever/advanced signature scheme=
s/ICVs






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Aggregate signature algorithms (=C2=A0https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf<=
/span>)






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0exist, and an interesting use-case can be found in also r=
eactive protocols, allowing verifying






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0not =E2=80=9Cjust=E2=80=9D the end points, but also the i=
ntermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0discussed above, or something smarter).






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Regeneration of messages, rather than forwarding, renders=
 that impossible (or, if used,






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0updating to =C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)






















=C2=A0






















There are other reasons, but the above are those tha=
t jump at me as immediate show-stoppers.






















=C2=A0






















I do honestly not see what possible benefit there is=
 from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inconve=
niences, and security is not the least of these. Insisting on =E2=80=9Crege=
neration=E2=80=9D requires development of =E2=80=9Cnon-general workarounds=
=E2=80=9D as pointed
 out above.






















=C2=A0






















Security Considerations<=
/p>





















This is an always thorny subject. When OLSRv2 was go=
ing through the process we got a thorough education in how little we knew a=
bout security from the SEC-ADs, and had to spend about a year or so develop=
ing RFC7183. The bottom line is, that
 this protocol needs its =E2=80=9CRFC7183 =C2=A0equivalent=E2=80=9D, either=
 as part of the main document, or as an independent document. currently, th=
at is not the case.






















=C2=A0






















A minima, looking at BCP72 and BCP107 =E2=80=94 taki=
ng inspiration from RFC7183 might be aw good idea, as that was the most rec=
ent that went through the SEC AD. Regardless of how, however, a =E2=80=9Cma=
ndatory to implement=E2=80=9D security mechanism most be specified
 (I think the right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D),=
 in sufficient detail to ensure interoperable implementations.






















=C2=A0






















As an example, both [RFC6130] and [RFC7181] set out =
that that:
























=C2=A0






















=C2=A0 =C2=A0 =C2=A0 On receiving a ... message, a r=
outer MUST first check if the






















=C2=A0 =C2=A0 =C2=A0 message is invalid for processi=
ng by this router






















=C2=A0






















and then proceed to give a number of conditions that=
, each, will lead to a rejection of the message as "badly formed and t=
herefore invalid for processing=E2=80=9D =E2=80=94 a list which RFC7183 the=
n amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting
 =E2=80=9Crejection=E2=80=9D. Idem for message generation.





















=C2=A0






















If I was to do RFC7181/RFC6130 today, I would includ=
e that directly into the protocol specifications. It turned out to be more =
overhead (and slow down publication anyways) to do it as separate documents=
.
























=C2=A0






















Secondly, we need to be a lot more rigid in terms of=
 what ICVs, Timestamps, etc. are added/removed, and what that brings.






















=C2=A0






















For example (with the assumption that messages are *=
forwarded* and *not* regenerated), this could be one option:<=
/p>





















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0When a RREQ, RREP message is generated, add an ICV Message TLV, which=
 is calculated <this way>






















=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=E2=80=A6(take inspiration from RFC7183 here)






















=C2=A0
































...



[Message clipped]=C2=A0=C2=A0

_______________________________________________

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










=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








--001a114fd8864bf6c605314ef6ed--


From nobody Mon Apr 25 06:28: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 4059512D179 for ; Mon, 25 Apr 2016 06:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.82
X-Spam-Level: 
X-Spam-Status: No, score=-4.82 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, TRACKER_ID=1.306] 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 wKB-usna_ceS for ; Mon, 25 Apr 2016 06:28: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 20D0812D14C for ; Mon, 25 Apr 2016 06:28:28 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,532,1454976000"; d="scan'208,217"; a="34180607"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 25 Apr 2016 14:28:27 +0100
X-IronPort-AV: E=Sophos;i="5.24,532,1454976000";  d="scan'208,217";a="115364113"
Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 25 Apr 2016 14:27:20 +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; Mon, 25 Apr 2016 14:27:20 +0100
From: "Dearlove, Christopher (UK)" 
To: Victoria Mercieca , Jiazi YI 
Thread-Topic: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
Thread-Index: AQHRgGzYnQ0jbgFSiUepI05etGsIBJ9d2vAQgAAD6gCAAAGt4IAAAs+AgDjn+gCAAAvpAIAAo5QAgAMoSiCAACB6gIAAE7kAgAARySA=
Date: Mon, 25 Apr 2016 13:27:20 +0000
Message-ID: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>      
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1556GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: 
Cc: Christopher Dearlove , Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 13:28:36 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1556GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QXNzdW1pbmcgZm9yIHRoZSBtb21lbnQgdGhhdCBldmVyeW9uZSB3aWxsIG5lZWQgYW4gUlJFUC1B
Y2sgb3Igd29u4oCZdCAobGV04oCZcyBjb21lIGJhY2sgdG8gdGhhdCkgd2h5IGRvIEMgYW5kIEIg
bmVlZCB0byBwdXQgYW4gYWRkcmVzcyBpbiBhcyBhbiBSUkVRLUFjayByZXF1ZXN0PyBXaHkgbm90
IGEgZmxhZywgYmVjYXVzZSB0aGUgYWRkcmVzcyB3aWxsIGJlIGluY2x1ZGVkIGFzIHRoZSBJUCBz
ZW5kaW5nIGFkZHJlc3MgLSBhbmQgd2Uga25vdyA1NDQ0IGlzIHJlcXVpcmVkIHRvIHBhc3MgdGhh
dCBvbi4gKEl04oCZcyB1c2VkIGJ5IE5IRFAgYXMgd2VsbC4pIFRoZW4gd2UgZG9u4oCZdCBuZWVk
IHRvIGNoYW5nZSB0aGUgUlJFUCwgaXQgd2lsbCBoYXZlIGEgZmxhZyBzZXQgb3Igbm90LCBhbmQg
d29u4oCZdCBjaGFuZ2UgKGluIHRoaXMgcmVnYXJkKS4NCg0KTm93IGxldOKAmXMgY29uc2lkZXIg
ZG8gd2Uga25vdyB3aGV0aGVyIHdlIGNhbiBzZXQgYSBmaXhlZCBmbGFnLiBGaXJzdCBJ4oCZZCBz
YXkgdGhlcmUgYXJlIHR3byBjYXNlcyAtIHlvdeKAmXZlIGdvdCBhIGZpcm0gY29udHJvbCBvbiB3
aGF04oCZcyBnb2luZyBvbiBpbiB5b3VyIG5ldHdvcmssIG9yIGl04oCZcyBvbmUgb2YgdW5rbm93
biBwYXJ0aWVzIGFuZCBiZWhhdmlvdXIgKGNvbnNpc3RlbnQgd2l0aCBzcGVjaWZpY2F0aW9uKS4g
SW4gdGhlIGZvcm1lciBjYXNlIHlvdSBvbmx5IHdhbnQgb25lIHNldHRpbmcsIGZvciBleGFtcGxl
IG5vLUFjayBpZiBydW5uaW5nIE5IRFAgb3IgeW91ciBNQUMgbGF5ZXIgdGVsbHMgeW91IGFib3V0
IGJpZGlyZWN0aW9uYWxpdHksIEFjayBvdGhlcndpc2UuIEluIHRoZSBsYXR0ZXIgY2FzZSwgSSB0
aGluayB5b3UganVzdCBhbHdheXMgd2FudCBhbiBBY2suIFNvIGJvdGggY2FzZXMgZ2V0IHlvdSB0
byB0aGUgc2FtZSBwbGFjZS4NCg0KU2hvdWxkIHRoYXQgbm90IGJlIGFuIGFjY2VwdGFibGUgYXJn
dW1lbnQgKHRob3VnaCBJIHRoaW5rIGl04oCZcyBnb29kIGZvciB3aGVyZSB3ZSBhcmUgLSBpbiBm
YWN0IGFsd2F5cyBBY2sgaXMgY2xvc2UpIHRoZW4gYXQgZmxhZyBpcyBhIHN0ZXAgYmV0dGVyLCBp
dOKAmXMgYSBmaXhlZCBsb2NhdGlvbiB0byBjaGFuZ2UuIEhvd2V2ZXIgaXQgd291bGQgYmUgYmV0
dGVyIGluIHRoYXQgY2FzZSBpZiB0aGUgdHdvIHRoaW5ncyB0byBjaGFuZ2UgKG1ldHJpYyBhbmQg
YWNrIGZsYWcpIHdlcmUgdG9nZXRoZXIuIEJ1dCB0aGF0IGhhcyBpdHMgb3duIGlzc3Vlcywgc28g
SSB3b27igJl0IGdvIHRoZXJlLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQ
cmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9y
YXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAg
RTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh
ZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1z
Zm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00y
IDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2Fp
Pg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBp
biBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5
IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IFZpY3Rv
cmlhIE1lcmNpZWNhIFttYWlsdG86dm1lcmNpZWNhMEBnbWFpbC5jb21dDQpTZW50OiAyNSBBcHJp
bCAyMDE2IDE0OjE1DQpUbzogSmlhemkgWUkNCkNjOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVL
KTsgQ2hyaXN0b3BoZXIgRGVhcmxvdmU7IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBs
aXN0DQpTdWJqZWN0OiBSZTogW21hbmV0XSBNZXNzYWdlIGludGVncml0eSBhbmQgbWVzc2FnZSBt
dXRhYmlsaXR5ICh3YXMgUkU6IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEg
Y291cGxlIG9mIGJpZyB0aWNrZXQgSXRlbXMpDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1l
c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZy
b20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVs
bHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNo
bWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0
IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxo
dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90
bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWls
IGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5l
dC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1l
bnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KSGkgSmlhemks
DQoNCg0KDQpPbiBNb24sIEFwciAyNSwgMjAxNiBhdCAxOjA0IFBNLCBKaWF6aSBZSSA8aWV0ZkBq
aWF6aXlpLmNvbTxtYWlsdG86aWV0ZkBqaWF6aXlpLmNvbT4+IHdyb3RlOg0KSGksDQoNCk9uIE1v
biwgQXByIDI1LCAyMDE2IGF0IDExOjIwIEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8
Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5
c3RlbXMuY29tPj4gd3JvdGU6DQpXaXRoIHJlZ2FyZCB0byB5b3VyIHZhbGlkaXR5IHRpbWUgcG9p
bnQsIHdlIGhlcmUgaGF2ZSBhIHRyYWRlb2ZmLiBJZiB5b3UgYWxsb3cgdGhhdCBmZWF0dXJlLCBp
dCBzaWduaWZpY2FudGx5IGltcGFjdHMgb24gdGhlIGFwcHJvYWNoIHRoYXQgd2FzIGNvbWluZyB0
b2dldGhlciBvbiBhcyBiZXN0IHlvdSBjYW4gZW5kIHRvIGVuZCBlbmNyeXB0aW9uLg0KDQpTbyB0
aGUgcXVlc3Rpb24gaXMsIGlzIHRoaXMgYSBmZWF0dXJlIHRoYXTigJlzIHJlYWxseSB3YW50ZWQ/
IFVuZm9ydHVuYXRlbHkgSSB0aGluayB3ZSBrbm93IHRoYXQgdGhlIGFuc3dlciB0byB0aGF0IGlz
LCB3ZSBkb27igJl0IGtub3cgYmVjYXVzZSB3ZSBkb27igJl0IGhhdmUgYW55IGV4cGVyaWVuY2Uu
IE15IHZpZXcgd291bGQgYmUgdGhhdCBpbiB0aGUgdHJhZGVvZmYgb2YgYW4gdW50ZXN0ZWQgZmVh
dHVyZSAodW5sZXNzIEnigJltIHdyb25nIGFib3V0IHRoYXQpIGFuZCB0aGUgc2VjdXJpdHkgY29t
cGxpY2F0aW9uLCBzZWN1cml0eSB3aW5zIGFuZCBkcm9wIHRoZSBmZWF0dXJlLiBJZiB0aGVyZSBp
cyBzb21lIHJlYWwgcmVxdWlyZW1lbnQsIHRoZW4gdGhlcmXigJlzIGEgZGlzY3Vzc2lvbi4gKFF1
ZXN0aW9ucyBsaWtlIGhvdyBvZnRlbiB0aGUgaW50ZXJtZWRpYXRlIHJvdXRlcnMgYWN0dWFsbHkg
aGF2ZSBhbnkga25vd2xlZGdlIC0gdHlwaWNhbGx5IGxpbmtzIGJyZWFrIGZvciB1bmV4cGVjdGVk
IHJhdGhlciB0aGFuIGV4cGVjdGVkIHJlYXNvbnMuIEFuZGFuIGludGVybWVkaWF0ZSByb3V0ZXIg
Y291bGQgcG9zc2libHkgdXNlIGEgdmFsaWRpdHkgdGltZSB0byBpbmZsdWVuY2UgaXRzIGJlaGF2
aW91ci4pIE5vdGUgdGhhdCBkcm9wcGluZyB0aGUgYWJpbGl0eSBvZiBpbnRlcm1lZGlhdGUgcm91
dGVycyB0byBtb2RpZnkvc2V0IHN0aWxsIGFsbG93cyB2YWxpZGl0eSB0aW1lcyBwZXIgcm91dGUg
dG8gYmUgc2V0IGF0IGVuZHBvaW50cy4NCg0KSSBhZ3JlZSB3aXRoIENocmlzJyBjb25jZXJuLg0K
VGhlIFZhbGlkaXR5VGltZSBpcyBvcHRpb25hbCwgd2hpY2ggbWFrZXMgdGhlIGludGVncml0eSBw
cm90ZWN0aW9uIGhhcmQuIEZ1cnRoZXJtb3JlLCBpdCBnaXZlcyBhIHBvdGVudGlhbCBhdHRhY2sg
dmVjdG9yOiBhcyBhbGwgdGhlIHJvdXRlcnMgaW4gYSBwYXRoIHdpbGwgdGFrZSB0aGUgc2hvcnRl
c3QgdmFsaWRpdHlUaW1lLCBhIGNvbXByb21pc2VkIHJvdXRlciBjYW4gc2V0IHRoZSB0aGUgdmFs
aWRpdHlUaW1lIHRvIGEgdmVyeSBzaG9ydCB2YWx1ZSwgd2hpY2ggd2lsbCBtYWtlIHRoZSByb3V0
ZSBpbnN0YWxsZWQgYWxvbmcgdGhlIHBhdGggYmVjYW1lIGludmFsaWQgKHZlcnkgc29vbikuDQoN
Ck9uIHRoZSBvdGhlciBoYW5kLCBJJ20gbm90IHN1cmUgdGhpcyBvcHRpb24gd2lsbCBnaXZlIHVz
IG11Y2ggaGVscC4gQ2hyaXMgbWVudGlvbmVkIG11Y2gga25vd2xlZGdlIGludGVybWVkaWF0ZSBy
b3V0ZXIgd291bGQgaGF2ZSB0byBkZWNpZGUgdGhpcyB2YWx1ZSAoYW5kIGhvdyBtdWNoIHNlbnNl
IHRoZSB2YWx1ZSB3b3VsZCBtYWtlKS4NCkFub3RoZXIgaXNzdWUgaXMsIGEgcm91dGUgdG8gYSBk
ZXN0aW5hdGlvbiBtaWdodCBiZSB1cGRhdGVkIGJ5IGRpZmZlcmVudCBzb3VyY2VzLiBGb3IgZXhh
bXBsZSwgaW4gdGhlIG5ldHdvcmsgYmVsb3c6DQoNCkEtLS0tQi0tLS0tQw0KDQpBIGZpcnN0IGVz
dGFibGlzaCBhIHJvdXRlIHRvIEIgd2l0aCBsb25nIHZhbGlkaXR5IHRpbWUuIFRoZW4gQSBpbml0
aWF0ZXMgYSByb3V0ZSBkaXNjb3ZlcnkgdG8gQy4gQyB0ZW5kcyB0byBzZXQgYSBzaG9ydCB2YWxp
ZGl0eSB0aW1lLCB3aGljaCB3aWxsIG1ha2UgdGhlIHJvdXRlIGJldHdlZW4gQiBhbmQgQSBleHBp
cmUgZWFybGllciB0aGFuIGV4cGVjdGVkLg0KSXMgdGhpcyBhIHByb2JsZW0/IE1heWJlIHllcywg
bWF5YmUgbm8gLS0gSSdtIG5vdCBzdXJlIGl0J3MgY29uc2lkZXJlZCBvciBub3QuDQoNCg0KTm90
IHN1cmUgSSBmb2xsb3cgaGVyZS4NCkN1cnJlbnRseSwgdGhlIHZhbGlkaXR5IHRpbWUgb2YgdGhl
IHJvdXRlIGJldHdlZW4gQSBhbmQgQiB3b3VsZCBub3QgYWZmZWN0ZWQgYnkgYSBzaG9ydCB2YWxp
ZGl0eSB0aW1lIG9mIGEgcm91dGUgYmV0d2VlbiBBIGFuZCBDLiBWYWxpZGl0eSB0aW1lcyBhcmUg
cGVyLXJvdXRlLCBhbmQgdGhlIHJvdXRlIEEtQiBhbmQgdGhlIHJvdXRlIEEtQyBhcmUgc2VwYXJh
dGUuDQpJZiB3ZSBzd2l0Y2hlZCB0byBhIHZhbGlkaXR5IHRpbWUgcGVyIG5laWdoYm9yIChzbyB0
aGF0IHdlIGNhbiBrZWVwIHZhbGlkaXR5IHRpbWUgc2VwYXJhdGUgZnJvbSByb3V0ZSBhZHZlcnRp
c2VtZW50cykgYXMgSSBtZW50aW9uZWQgaW4gdGhlIGVtYWlsIGJlbG93LCB0aGVuIHRoZSB2YWxp
ZGl0eSBvZiBhIHJvdXRlIGJldHdlZW4gQSBhbmQgQyB3b3VsZCBiZSBhZmZlY3RlZCBpZiB0aGVy
ZSB3YXMgYSBzaG9ydCB2YWxpZGl0eSB0aW1lIGJldHdlZW4gQSBhbmQgQi4gQnV0LCBpZiBCIHdp
bGwgb25seSByb3V0ZSBmb3IgYSBjZXJ0YWluIGFtb3VudCBvZiB0aW1lLCB0aGVuIHRoZSByb3V0
ZSBiZXR3ZWVuIEEgYW5kIEMgd2lsbCBvZiBjb3Vyc2UgYmUgYWZmZWN0ZWQuIElzIGl0IGJlc3Qg
dG8ga25vdyBpbiBhZHZhbmNlIHRoYXQgdGhlcmUncyBhIHRpbWUgbGltaXQsIG9yIGp1c3QgZGVh
bCB3aXRoIFJFUlJzIHdoZW4gdGhleSBoYXBwZW4/DQoNCg0KDQpXaXRoIHJlZ2FyZCB0byB0aGUg
YWNrbm93bGVkZ2VtZW50cywgdGhlIHByb2JsZW0gKHdpdGggcmVnYXJkIHRvIHNlY3VyaXR5KSBj
b21lcyBmcm9tIHRyeWluZyB0byBkbyB0d28gam9icyB3aXRoIHRoZSBzYW1lIG1lc3NhZ2UgLSBl
bmQgdG8gZW5kIHJvdXRlIGFkdmVydGlzZW1lbnQgYW5kIGhvcCBieSBob3AgYWNrbm93bGVkZ2Vt
ZW50LiBJIHVuZGVyc3RhbmQgdGhlIHJlYXNvbnMgLSBzYXZpbmcgYnl0ZXMgYW5kIG1lc3NhZ2Ug
dHlwZXMuIChJIHdvdWxkIGhhdmUgdG8gc3R1ZHkgdGhlIHByb3RvY29sIHJlYWxseSBoYXJkIHRv
IGlkZW50aWZ5IGlmIGFueSBtZXNzYWdlIHR5cGVzIGNhbiBiZSBmb2xkZWQgdG9nZXRoZXIgYW5k
IHJlY29nbmlzZWQgYnkgY29udGVudCByYXRoZXIgdGhhbiB0eXBlIGVmZmljaWVudGx5LiBUaGlz
IEkgZG8gbm90IGV4cGVjdCB0byBkby4pIEFnYWluIGEgdHJhZGVvZmYuIFRoaXMgb25lIGlzIGlu
IGRpc2N1c3Npb24gc3BhY2UsIHRob3VnaCB0aGF0IG5lZWRzIHBlb3BsZSB3aG8gdW5kZXJzdGFu
ZCBib3RoIHNpZGVzIG9mIHRoZSBpc3N1ZSwgaW5jbHVkaW5nIHRoZSBkZXRhaWxzIG9mIHRoZSBi
aWRpcmVjdGlvbmFsaXR5IG1lY2hhbmlzbS4gT2YgY291cnNlLCBhcyBoYXMgYmVlbiBzYWlkLCB3
ZSBuZWVkIG9uZSBvZiB0aG9zZS4NCg0KSSBoYXZlbid0IGZpbmlzaGVkIG15IHJldmlldyBvZiB0
aGUgbGF0ZXN0IGRyYWZ0LCBhbmQgSSBkb24ndCBnZXQgdGhlIG5lY2Vzc2l0eSBvZiBBY2tSZXEg
YW5kIHRoZSBjb3JyZXNwb25kaW5nIG11bHRpY2FzdCBSUkVQIHlldC4NCklmIHBvc3NpYmxlLCB0
aGlzICJvcHRpb25hbCIgZmllbGQgc2hvdWxkIGJlIGF2b2lkZWQuDQoNCg0KVG8gZ2l2ZSBhbiBv
dmVydmlldyBvZiBBY2tSZXEgYW5kIFJSRVA6DQpTaW5jZSBBT0RWdjIgcmVxdWlyZXMgYmlkaXJl
Y3Rpb25hbCBsaW5rcywgdGhpcyBpcyB0aGUgd2F5IHRvIGRldGVybWluZSBpZiBhIGxpbmsgaXMg
YmlkaXJlY3Rpb25hbC4NCkEtLS0tQi0tLS1DDQoNCjEpIEEgc2VuZHMgUlJFUSwgQiBmb3J3YXJk
cyBpdCwgQyByZWNlaXZlcyB0aGUgUlJFUS4gQiBhbmQgQyBib3RoIGluc3RhbGwgYSByb3V0ZSB0
byBPcmlnQWRkciBidXQgdGhleSBkb250IHlldCBrbm93IGlmIGl0J3MgdmFsaWQgYmVjYXVzZSB0
aGV5IGRvbnQga25vdyBpZiB0aGUgbGluayB0byB0aGVpciBuZXh0IGhvcCBpcyBhdmFpbGFibGUg
aW4gdGhlIHJldmVyc2UgZGlyZWN0aW9uLg0KMikgQyBjcmVhdGVzIHRoZSBSUkVQLiBTaW5jZSBp
dCBkb2VzbnQga25vdyBpZiB0aGUgbGluayB0byBCIGlzIGJpZGlyZWN0aW9uYWwsIGl0IGluY2x1
ZGVzIHRoZSBBY2tSZXEgKGFuIGFkZHJlc3MgdG8gaW5kaWNhdGUgdGhhdCBpdCBleHBlY3RzIHRv
IHJlY2VpdmUgYSBSUkVQX0FjayBmcm9tIEIpLg0KMykgQiByZWNlaXZlcyB0aGUgUlJFUCwgaW5z
dGFsbHMgYSByb3V0ZSB0byBUYXJnQWRkciBhbmQgbWFya3MgaXQgYXMgdmFsaWQsIHNpbmNlIGl0
IGtub3dzIHRoZSBsaW5rIHRvIEMgaXMgYmlkaXJlY3Rpb25hbCwgYmVjYXVzZSB0aGUgUlJFUSB3
ZW50IGluIG9uZSBkaXJlY3Rpb24gYW5kIHRoZSBSUkVQIGNhbWUgaW4gdGhlIG90aGVyLiBCIGFs
c28gc2VuZHMgdGhlIFJSRVBfQWNrIHRvIEMgYW5kIGZvcndhcmRzIHRoZSBSUkVQIHRvIEEgKGFu
ZCBtaWdodCBjaGFuZ2UgdGhlIG1lc3NhZ2UgdG8gaW5kaWNhdGUgaXRzIG93biBBY2tSZXEgLSBp
ZSB0aGF0IGl0IHJlcXVpcmVzIGFuIGFjayBmcm9tIEEpLg0KNCkgQyByZWNlaXZlcyB0aGUgUlJF
UF9BY2sgZnJvbSBCLCBhbmQgdGhlcmVmb3JlIGtub3dzIHRoYXQgQiByZWNlaXZlZCB0aGUgUlJF
UCwgdGhlcmVmb3JlIHRoZSBsaW5rIGlzIGJpZGlyZWN0aW9uYWwuIEMgY2FuIHRoZW4gbWFyayBp
dHMgcm91dGUgdG8gT3JpZ0FkZHIgYXMgdmFsaWQuDQo1KSBTaW1pbGFybHksIEEgcmVjZWl2ZXMg
dGhlIFJSRVAsIGluc3RhbGxzIHRoZSByb3V0ZSB0byBUYXJnQWRkciBhbmQgc2VuZHMgYW4gUlJF
UF9BY2sgdG8gQi4NCjYpIEIgcmVjZWl2ZXMgdGhlIFJSRVBfQWNrIGFuZCBtYXJrcyBpdHMgcm91
dGUgdG8gT3JpZ0FkZHIgYXMgdmFsaWQuDQoNCkFsdGVybmF0aXZlbHksIGluIHN0ZXAgMiwgaWYg
QyBrbm93cyB0aGUgbGluayB0byBCIGlzIGJpZGlyZWN0aW9uYWwgKHBlcmhhcHMgZnJvbSBzb21l
IGVhcmxpZXIgcm91dGUgZGlzY292ZXJ5KSwgaXQgZG9lc250IG5lZWQgdG8gcHV0IHRoZSBBY2tS
ZXEgaW4gdGhlIFJSRVAuIFRoZW4gaW4gc3RlcCAzLCBzaW5jZSBCIGRvZXNudCBrbm93IGlmIHRo
ZSBsaW5rIHRvIEEgaXMgYmlkaXJlY3Rpb25hbCwgaXQgY2hhbmdlcyB0aGUgbWVzc2FnZSB0byBh
ZGQgdGhlIEFja1JlcSBhZGRyZXNzLCBpbiBvcmRlciB0byBnZXQgYW4gUlJFUF9BY2sgZnJvbSBB
Lg0KSWYgd2Ugd2FudCB0byBhdm9pZCBjaGFuZ2luZyB0aGUgbWVzc2FnZSwgd2UnbGwgbmVlZCB0
byBsb29rIGF0IGZvcndhcmRpbmcgdGhlIFJSRVAgYXMtaXMsIGFuZCBjcmVhdGluZyBhIHNlY29u
ZCBtZXNzYWdlIHRvIHNvbGljaXQgYW4gUlJFUF9BY2ssIGluIG9yZGVyIHRvIHZlcmlmeSB0aGF0
IHRoZSBsaW5rIGlzIGJpZGlyZWN0aW9uYWwgYmVmb3JlIG1hcmtpbmcgdGhlIHJvdXRlIHRvIE9y
aWdBZGRyIGFzIHZhbGlkLg0KS2luZCByZWdhcmRzLA0KVmljdG9yaWEuDQoNCg0KcmVnYXJkcw0K
DQpKaWF6aQ0KDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBF
bmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUy
ODAlMjkxMjQ1JTIwMjQyMTk0PiAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208
bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBs
aWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRv
dywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRw
Oi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu
Y2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpS
ZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5
LCBHVTIgN1lQDQoNCkZyb206IFZpY3RvcmlhIE1lcmNpZWNhIFttYWlsdG86dm1lcmNpZWNhMEBn
bWFpbC5jb208bWFpbHRvOnZtZXJjaWVjYTBAZ21haWwuY29tPl0NClNlbnQ6IDIzIEFwcmlsIDIw
MTYgMTA6NTUNClRvOiBDaHJpc3RvcGhlciBEZWFybG92ZQ0KQ2M6IGlldGZAdGhvbWFzY2xhdXNl
bi5vcmc8bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmc+OyBEZWFybG92ZSwgQ2hyaXN0b3Bo
ZXIgKFVLKTsgTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3QNCg0KU3ViamVjdDog
UmU6IFttYW5ldF0gTWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2UgbXV0YWJpbGl0eSAod2Fz
IFJFOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcg
dGlja2V0IEl0ZW1zKQ0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0
ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFs
IHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91
IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5
Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sg
b3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0
LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVu
dHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3Vz
LCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3Rl
bXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIw
V2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCkhpIENocmlzLA0KDQpUaGVzZSBoYXZl
IGJvdGggYmVlbiBpbiB0aGUgZHJhZnQgaW4gc29tZSBmb3JtIHNpbmNlIGJlZm9yZSBJIGdvdCBp
bnZvbHZlZC4uLiBidXQgSSdsbCBkbyBteSBiZXN0IHRvIGV4cGxhaW4uDQoNCi0gRm9yIFZhbGlk
aXR5IFRpbWUsIGl0cyBhIHdheSB0byBhZHZlcnRpc2UgdGhhdCB5b3Ugd291bGQgb25seSBzdXBw
b3J0IHRoZSByb3V0ZSBjb250YWluZWQgaW4gdGhlIG1lc3NhZ2UgZm9yIGEgY2VydGFpbiBwZXJp
b2Qgb2YgdGltZS4gVGhlIG9yaWdpbmF0b3IgbWlnaHQgdXNlIHRoaXMsIGJ1dCB0aGUgZHJhZnQg
d2FzIHdyaXR0ZW4gdG8gYWxsb3cgYW55IGludGVybWVkaWF0ZSBub2RlIHRvIGJlIGFibGUgdG8g
YWRkIGl0IG9yIHVwZGF0ZSBpdCB0b28uIFRoZSByb3V0ZSBjcmVhdGVkIGluIHRoZSBMb2NhbCBS
b3V0ZSBTZXQgaGFzIGFuIGV4cGlyYXRpb24gdGltZSBhc3NvY2lhdGVkIHdpdGggaXQsIGJhc2Vk
IG9uIHRoZSByZWNlaXZlZCB2YWxpZGl0eSB0aW1lLg0KLSBGb3IgdGhlIEFja1JlcSBhZGRyZXNz
LCBpdHMgc28gdGhhdCB5b3UgY2FuIGFkZCBpbnRvIGEgUlJFUCBhIHJlcXVlc3QgZm9yIGFuIGFj
a25vd2xlZGdlbWVudCwgc28gdGhhdCB5b3UgZG9uJ3QgaGF2ZSB0byBoYXZlIGEgZGlmZmVyZW50
IG1lc3NhZ2UgdHlwZSBhbHRvZ2V0aGVyIGZvciB3b3JraW5nIG91dCB3aGV0aGVyIGxpbmtzIHRv
IG5laWdoYm9ycyBhcmUgYmlkaXJlY3Rpb25hbCwgYW5kIGFsc28sIHNpbmNlIHlvdSBvbmx5IGNh
cmUgYWJvdXQgYmlkaXJlY3Rpb25hbGl0eSBvbiByb3V0ZXMgdGhhdCBhcmUgYmVpbmcgc2V0IHVw
LCB5b3UgZG9udCBuZWVkIHRvIGNvbnN0YW50bHkgbW9uaXRvciBhbGwgbmVpZ2hib3JzLg0KDQoN
CkluIG9yZGVyIHRvIGF2b2lkIHRoZSBwb3RlbnRpYWwgQWNrUmVxLXJlbGF0ZWQgY2hhbmdlcyB0
byBlYWNoIG1lc3NhZ2UsIG1heWJlIHdlIGRvIG5lZWQgdG8gaW50cm9kdWNlIGEgZGlmZmVyZW50
IG1lc3NhZ2Ugc3BlY2lmaWNhbGx5IGZvciB0aGlzLiBXZSBjb3VsZCBtYXliZSB1c2UgUlJFUF9B
Y2sgdG8gYm90aCByZXF1ZXN0IGFuZCBhY2tub3dsZWRnZT8gSXQgbWVhbnMgYW4gZXh0cmEgbWVz
c2FnZSBvZiBjb250cm9sIHRyYWZmaWMgdGhhdCBuZWVkcyB0byBiZSBzZW50LCBtYXliZSBvbmUg
ZXh0cmEgbWVzc2FnZSBwZXIgaG9wIG9uIHRoZSBwYXRoIG9mIGEgUlJFUCwgYnV0IGl0IGNvdWxk
IHN0aWxsIGJlIGxpbWl0ZWQgdG8gbmVpZ2hib3JzIHdoaWNoIGhhdmUgcGFydGljaXBhdGVkIGlu
IHRoZSByb3V0ZSBkaXNjb3ZlcnkgcmF0aGVyIHRoYW4gbW9uaXRvcmluZyBhbGwgbmVpZ2hib3Jz
IGF0IGFsbCB0aW1lcy4NCg0KVGhpcyBtZXNzYWdlIGNvdWxkIG1heWJlIGFsc28gaW5jbHVkZSAi
SSdtIGhhcHB5IHRvIHJvdXRlIGFueXdoZXJlIGZvciBhIGNlcnRhaW4gYW1vdW50IG9mIHRpbWUi
LCBzb3J0IG9mIGxpa2Ugd2lsbGluZ25lc3MgaW4gT0xTUi9PTFNSdjIuIFNvIGluc3RlYWQgb2Yg
aGF2aW5nIGEgdmFsaWRpdHkgdGltZSBwZXIgcm91dGUsIGl0cyBhIHZhbGlkaXR5IHRpbWUgcGVy
IG5laWdoYm9yLiBUaGVuLCBmb3IgUlJFUSBhbmQgUlJFUCwgb25seSB0aGUgbWV0cmljIHZhbHVl
IHdvdWxkIGNoYW5nZSBpbiB0cmFuc2l0LCBhcyBkaXNjdXNzZWQuIEhvd2V2ZXIsIHRoYXQgbGVh
ZHMgdG8gc29tZSBpc3N1ZXMgd2l0aCBkZWNpZGluZyB3aGF0IGEgcm91dGUncyBleHBpcmF0aW9u
IHRpbWUgaXMuIFlvdSBtaWdodCBrbm93IGhvdyBsb25nIHRoZSBuZXh0IGhvcCByb3V0ZXIgaXMg
dmFsaWQgZm9yLCBidXQgd2hhdCBpZiBhIHJvdXRlciBiZXlvbmQgdGhhdCwgd2hpY2ggd2FzIGFs
c28gcGFydCBvZiB0aGUgcm91dGUsIGhhZCBhIGxvd2VyIHZhbGlkaXR5IHRpbWU/IFlvdSBjb3Vs
ZG4ndCBkZXRlcm1pbmUgdGhlIHJlYWwgdmFsaWRpdHkgdGltZS4gRG8gd2UgcmVtb3ZlIHRoZSBy
b3V0ZSBleHBpcmF0aW9uIHRpbWUgYWx0b2dldGhlciB0byBhdm9pZCB0aGlzIGlzc3VlPyBJbiB3
aGljaCBjYXNlLCB3ZSB3b3VsZCBoYXZlIHRvIHJlbHkgb24gUkVSUiBtZXNzYWdlcyBiZWluZyBz
ZW50IGZvciByb3V0ZXMgd2hpY2ggYmVjb21lIGludmFsaWQgd2hlbiB0aGUgbmVpZ2hib3IncyB2
YWxpZGl0eSB0aW1lIGhhcyBleHBpcmVkPyBTbyBuZWlnaGJvciB2YWxpZGl0eSB0aW1lIGV4cGly
YXRpb24gaXMgdHJlYXRlZCB0aGUgc2FtZSBhcyBhIGxpbmsgYnJlYWsuDQoNCldoYXQgZG8geW91
IHRoaW5rPw0KDQpLaW5kIHJlZ2FyZHMsDQpWaWN0b3JpYS4NCg0KDQoNCg0KDQoNCk9uIFNhdCwg
QXByIDIzLCAyMDE2IGF0IDE6MDkgQU0sIENocmlzdG9waGVyIERlYXJsb3ZlIDxjaHJpc0BtbmVt
b3N5bmUuZGVtb24uY28udWs8bWFpbHRvOmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51az4+IHdy
b3RlOg0KUHJldHR5IG11Y2ggYWxsIG9mIHRoZSBkaXNjdXNzaW9uIGhhcyBiZWVuIGFzc3VtaW5n
IG9ubHkgYSBtZXRyaWMgdmFsdWUgY2hhbmdlLiBXaXRoIG11bHRpcGxlIHRoaW5ncyBjaGFuZ2lu
ZyBtYW55IG9mIHRoZSBpZGVhcyBnbyBvdXQgb2YgdGhlIHdpbmRvdy4gVGhhdCByZWluZm9yY2Vz
IHRoZSBwb2ludCBhYm91dCBub3QgbWFraW5nIHNwZWNpZmljYXRpb25zIG5vdyB0aGF0IG1pZ2h0
IHR1cm4gb3V0IHRvIGJlIHdyb25nIGZvciBJQ1ZzLg0KDQpJZ25vcmluZyBob3cgdGhpcyBtaXN1
bmRlcnN0YW5kaW5nIGhhcHBlbmVkLCBJJ2xsIHN0YXJ0IGJ5IGFza2luZyB3aHkuIE1ldHJpYyBj
aGFuZ2luZyBJIHVuZGVyc3RhbmQuIFdoeSB0aGUgb3RoZXIgdHdvPyAodGhlcmUncyBhIHBhcnRp
YWwgZXhwbGFuYXRpb24gb2Ygb25lKS4gV2hhdCBhbHRlcm5hdGl2ZXMgaGF2ZSBwZW9wbGUgaW1w
bGVtZW50ZWQgaW4gY29tcGFyYWJsZSBwcm90b2NvbHM/DQoNCi0tDQpDaHJpc3RvcGhlciBEZWFy
bG92ZQ0KY2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tPG1haWx0bzpjaHJpc3RvcGhlci5k
ZWFybG92ZUBnbWFpbC5jb20+IChpUGhvbmUpDQpjaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWs8
bWFpbHRvOmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51az4gKGhvbWUpDQoNCk9uIDIzIEFwciAy
MDE2LCBhdCAwMDoyNiwgVmljdG9yaWEgTWVyY2llY2EgPHZtZXJjaWVjYTBAZ21haWwuY29tPG1h
aWx0bzp2bWVyY2llY2EwQGdtYWlsLmNvbT4+IHdyb3RlOg0KSGkgYWxsLA0KDQpDb250aW51ZWQg
aW4gdGhpcyB0aHJlYWQgYmVjYXVzZSB0aGUgb3RoZXIgb25lIHNlZW1zIHRvIGJlIG1vcmUgYWJv
dXQgVExWIHR5cGVzIGFuZCBtZXRyaWMgdHlwZSBudW1iZXJzLCB3aGVyZWFzIHRoaXMgaXMgYWJv
dXQgcmVnZW5lcmF0aW9uL2ZvcndhcmRpbmcuDQoNClRvIHJlY2FwLCBpbiB0aGUgY3VycmVudCBk
cmFmdCwgdGhlcmUgYXJlIDMgdGhpbmdzIHRoYXQgbWlnaHQgY2hhbmdlIGF0IGVhY2ggaG9wOg0K
LSB0aGUgbWV0cmljIHZhbHVlIChoYXBwZW5zIGluIFJSRVEgYW5kIFJSRVApLA0KLSBhZGRpbmcv
Y2hhbmdpbmcgVmFsaWRpdHkgVGltZSB1c2luZyB0aGUgVmFsaWRpdHkgVGltZSBUTFYgKGNhbiBo
YXBwZW4gaW4gUlJFUSBhbmQgUlJFUCksDQotIGFkZGluZyBhbiBhZGRyZXNzIChhbmQgY29ycmVz
cG9uZGluZyB2YWx1ZSBpbiB0aGUgQWRkcmVzc1R5cGUgVExWIHRvIGluZGljYXRlIGhvdyB0byBp
bnRlcnByZXQgdGhlIGFkZHJlc3MpIHRvIGluZGljYXRlIHRoZSBhZGRyZXNzIGZyb20gd2hpY2gg
YW4gUlJFUF9BY2sgaXMgZXhwZWN0ZWQsIHRvIGFjY29tcGxpc2ggdGhlIGJpZGlyZWN0aW9uYWxp
dHkgY2hlY2sgKGNhbiBoYXBwZW4gaW4gUlJFUCkuDQoNCklmIHdlIGRlZmluZSBhIGNlcnRhaW4g
cG9ydGlvbiBvZiB0aGUgbWVzc2FnZSBhcyBpbW11dGFibGUgYW5kIGluY2x1ZGUgdGhlIElDViB0
byB2ZXJpZnkgdGhhdCBwYXJ0LCBlbmQgdG8gZW5kOg0KLSBUaGUgbWV0cmljIHZhbHVlIHdvdWxk
IGJlIGV4Y2x1ZGVkIGZyb20gdGhlIElDViBzaW5jZSBpdCBuZWVkcyBjaGFuZ2luZyBhdCBlYWNo
IGhvcC4NCi0gV291bGQgYWRkaW5nIGEgVmFsaWRpdHkgVGltZSBUTFYgYXQgYW4gaW50ZXJtZWRp
YXRlIGhvcCBiZSBhY2NlcHRhYmxlPyBUaGUgd2hvbGUgVExWIGNvdWxkIGJlIHJlbW92ZWQgaW4g
b3JkZXIgdG8gY2FsY3VsYXRlIHRoZSBJQ1Y/DQotIFdvdWxkIGFkZGluZyBhbiBhZGRyZXNzIGNh
dXNlIGlzc3VlcyBmb3IgdGhlIElDViwgYmVjYXVzZSBpdCdzIGluIHRoZSBhZGRyZXNzIGJsb2Nr
PyBDb3VsZCB0aGUgcnVsZSBiZSAiaWYgaXQgY29udGFpbnMgYW4gQWNrUmVxIGFkZHJlc3MsIHJl
bW92ZSBpdCAoYW5kIHRoZSBjb3JyZXNwb25kaW5nIHZhbHVlIGluIHRoZSBBZGRyZXNzVHlwZSBU
TFYpLCBiZWZvcmUgY2hlY2tpbmcgdGhlIElDViIsIGlzIHRoYXQgT0s/IE9yIHdvdWxkIHdlIG5l
ZWQgdG8gYXZvaWQgdG91Y2hpbmcgdGhlIElDVidlZCBwYXJ0IG9mIHRoZSBtZXNzYWdlIGFsdG9n
ZXRoZXIsIG1heWJlIHB1dCB0aGUgQWNrUmVxIGFkZHJlc3MgaW4gYSBzZXBhcmF0ZSBBZGRyZXNz
IEJsb2NrLCB3aXRoIGFuIGV4dHJhIEFkZHJlc3NUeXBlIFRMViBmb2xsb3dpbmcgdGhhdCBhZGRy
ZXNzIGJsb2NrPyBJcyB0aGVyZSBhIHdheSB0byBhY2NvbXBsaXNoIHRoaXM/DQoNCkFsc28sIHRv
IGJlIHRob3JvdWdoLCBkbyB3ZSBuZWVkIHRvIGNvbnNpZGVyIFJFUlIgbWVzc2FnZXMgd2hpbGUg
d2UgZGlzY3VzcyByZWdlbmVyYXRpb24gdnMgZm9yd2FyZGluZz8NCi0gUkVSUiAoc2VudCB3aGVu
IGEgbGluayBicmVha3MpIGlzIGEgd2F5IG9mIHNheWluZyAiSSd2ZSBsb3N0IG15IHJvdXRlIHNv
IEknbSB0ZWxsaW5nIG90aGVycyIgYW5kICJ5b3Ugd2VyZSBteSBuZXh0IGhvcCwgc28gbm93IEkn
dmUgYWxzbyBsb3N0IG15IHJvdXRlLCBJJ2xsIHRlbGwgb3RoZXJzIiwgZXRjLiBJdCdzIGdvaW5n
IHRvIGJlIHRhaWxvcmVkIGF0IGVhY2ggc3RlcCB0byBpbmNsdWRlIHRoZSByZWxldmFudCByb3V0
ZXMgdGhhdCBnb3QgZGVsZXRlZCwgaXQncyBub3Qgb25lIG1lc3NhZ2UgYmVpbmcgc2VudCBlbmQt
dG8tZW5kIGxpa2UgUlJFUSBhbmQgUlJFUCBhcmUuDQotIEhvd2V2ZXIsIFJFUlIgKHNlbnQgd2hl
biBhIHNvdXJjZSBvZiB0cmFmZmljIGlzIHNlbmRpbmcgZGF0YSBvbiBhIHJvdXRlIHdoaWNoIGNv
bWVzIHRocm91Z2ggeW91LCBhbmQgeW91IHdhbnQgdG8gdGVsbCB0aGUgUGFja2V0IFNvdXJjZSdz
IHJvdXRlciB0byBkZWxldGUgdGhlIHJvdXRlKSBjb3VsZCBiZSBzZWVuIGFzIGFuIGVuZC10by1l
bmQgbWVzc2FnZSB3aGljaCBhbGwgaW50ZXJtZWRpYXRlIHJvdXRlcnMgbGVhcm4gZnJvbSwgc2lt
aWxhciB0byBSUkVRIGFuZCBSUkVQLiBJdCByZXBvcnRzIG9uZSByb3V0ZSwgYW5kIGRvZXNuJ3Qg
bmVlZCBjaGFuZ2luZyBhdCBpbnRlcm1lZGlhdGUgaG9wcywgc28gY291bGQgYmUgcHJvdGVjdGVk
IHdpdGggSUNWLg0KLSBXb3VsZCBpdCBiZSBPSyB0byBvbmx5IHJlcXVpcmUgYSBtZXNzYWdlIElD
ViBpZiBhIFBrdFNvdXJjZSBhZGRyZXNzIHdhcyBpbmNsdWRlZCwgaS5lLiB3aGVuIHRoZSBtZXNz
YWdlIG5lZWRzIHRvIGdvIHZpYSBhIG51bWJlciBvZiBpbnRlcm1lZGlhdGUgaG9wcyB0byBQa3RT
b3VyY2UncyByb3V0ZXI/IEFsbCBvdGhlciBSRVJScyBhcmUgaW50ZW5kZWQgdG8gYmUgb25lLWhv
cCBtZXNzYWdlcywgd2hpY2ggbWF5IGluIHR1cm4gcHJvbXB0IG90aGVyIG9uZS1ob3AgbWVzc2Fn
ZXMsIGV0Yy4uLiwgYW5kIGEgcGFja2V0IElDViBtaWdodCBiZSBtb3JlIGFwcHJvcHJpYXRlPw0K
DQpLaW5kIHJlZ2FyZHMsDQpWaWN0b3JpYS4NCg0KT24gVGh1LCBNYXIgMTcsIDIwMTYgYXQgNToy
NiBQTSwgPGlldGZAdGhvbWFzY2xhdXNlbi5vcmc8bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5v
cmc+PiB3cm90ZToNCg0KT24gMTcgTWFyIDIwMTYsIGF0IDE4OjE3LCBEZWFybG92ZSwgQ2hyaXN0
b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRl
YXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQoNClllcywgSSBtZWFudCBBT0RWdjIsIHRo
YW5rcyBmb3IgdGhlIGNhdGNoLg0KDQpTbyBpcyB5b3VyIChUaG9tYXMpIHByb3Bvc2VkIGJhc2Ug
c3BlY2lmaWNhdGlvbiBhIGhvcCBjb3VudCBvbmx5IG1ldHJpYz8NCg0KTm8sIHRoZSB3b3VsZCBi
ZSBzaWxseSBhcyBiYXNlIHNwZWNpZmljYXRpb24sIGdpdmVuIHRoYXQgaG9wIGNvdW50IG1vc3Rs
eSBpcyB1c2VsZXNzLg0KDQpBcyBiYXNlIHNwZWNpZmljYXRpb24gSSB3b3VsZCBzaW1wbHkgc2F5
IOKAnEluY2x1ZGUgYSBNZXRyaWMgVHlwZSBNZXNzYWdlIFRMViB3aXRoIGEgdmFsdWUgZmllbGQs
IGFuZCBhIDcxODIgTWVzc2FnZSBUTFYgJiBUaW1lc3RhbXDigJ0gYXMgd2UgZG8gaW4gT0xTUnYy
ICh3aXRoIHRoZSBhcHByb3ByaWF0ZSB2ZXJiaWFnZSBhcyB0byBnZW5lcmF0aW9uIGFuZCBwcm9j
ZXNzaW5nKS4NCg0KV2l0aCB0aGUgbWVzc2FnZSBnZW5lcmF0ZWQgYnkgdGhlIG9yaWdpbmF0b3Ig
b2YgdGhlIFJSRVEvUlJFUCBhbmQgKm5vdCogZGVjb25zdHJ1Y3RlZC9yZWNvbnN0cnVjdGVkL3Jl
b3JkZXJlZCAoYXMgaXMgdGhlIHJpc2sgd2l0aCDigJxyZWdlbmVyYXRpb24pIGFsbG93cyBrbm93
aW5nIHRoYXQgaXQgd291bGQgYmUgKm9ubHkqIHRoYXQgbWV0cmljIGZpZWxkIGJlaW5nIG1vZGlm
aWVkIChvdGhlciB0aGFuIGhvcCBjb3VudC9saW1pdCkgZm9yIHdoZW4gZXZlbnR1YWxseSB3cml0
aW5nIHVwIHRoZSBleHRlbnNpb24uDQoNCihBY3R1YWxseSBkb2VzbuKAmXQgdGhlIGN1cnJlbnQg
c3BlY2lmaWNhdGlvbiBvbmx5IGRlZmluZSBob3AgY291bnQsIG9yIGhhcyB0aGF0IGNoYW5nZWQg
aW4gbGF0ZXN0IGRyYWZ0PykNCg0KTm8uIFRoYXQgaXMgb25lIG9mIHRoZSBpc3N1ZXMgSSByYWlz
ZSBpbiBteSBvcmlnaW5hbC4gRm9yIHNvbWUgcmVhc29uLCBpdCBjaXRlcyBSRkM2NTUxLCB3aGlj
aCBpcyBhIFJPTEwgZG9jdW1lbnQgYW5kIHdoaWNoIGhhcyBpbiBpdHMgYWJzdHJhY3QgdGhhdDoN
Cg0KDQogICBMb3ctUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzIChMTE5zKSBoYXZlIHVuaXF1ZSBj
aGFyYWN0ZXJpc3RpY3MNCg0KICAgY29tcGFyZWQgd2l0aCB0cmFkaXRpb25hbCB3aXJlZCBhbmQg
YWQgaG9jIG5ldHdvcmtzIHRoYXQgcmVxdWlyZSB0aGUNCg0KICAgc3BlY2lmaWNhdGlvbiBvZiBu
ZXcgcm91dGluZyBtZXRyaWNzIGFuZCBjb25zdHJhaW50cy4NCg0KSS5lLiB0aGlzIGRvY3VtZW50
IGNpdGVzIGEgbWV0cmljIGRvY3VtZW50IHdoaWNoIGNsZWFybHkgY2xhaW1zIHRvIGJlIGluYXBw
bGljYWJsZSBpbiBhZCBob2MgbmV0d29ya3MuIEkgbm90ZSB0aGF0IHRoaXMgaXMgYW5vdGhlciB0
aGluZyBJ4oCZdmUgcmFpc2VkIGZvciB5ZWFycyB3aXRob3V0IHNlZWluZyBpdCBhdHRlbXB0ZWQg
cmVzb2x2ZWQuDQoNCkJlc3QsDQoNClRob21hcw0KDQoNCg0KLS0NCkNocmlzdG9waGVyIERlYXJs
b3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs
bGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0
NSAyNDIxOTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5k
ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j
b20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hu
b2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3
LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lz
dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQg
JiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2gg
UGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTogaWV0ZkB0aG9tYXNjbGF1
c2VuLm9yZzxtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZz4gW21haWx0bzppZXRmQHRob21h
c2NsYXVzZW4ub3JnXQ0KU2VudDogMTcgTWFyY2ggMjAxNiAxNzoxMA0KVG86IERlYXJsb3ZlLCBD
aHJpc3RvcGhlciAoVUspDQpDYzogTG90dGUgU3RlZW5icmluazsgTW9iaWxlIEFkIEhvYyBOZXR3
b3JrcyBtYWlsaW5nIGxpc3QNClN1YmplY3Q6IFJlOiBbbWFuZXRdIE1lc3NhZ2UgaW50ZWdyaXR5
IGFuZCBtZXNzYWdlIG11dGFiaWxpdHkgKHdhcyBSRTogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djIt
MTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcykNCg0KDQoqKiogV0FSTklO
RyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0
aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNv
bnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBv
cGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcg
UmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZl
LCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3Jr
L3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3Ug
ZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8
aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3Bv
dGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBk
Zj4uDQoNCk9uIDE3IE1hciAyMDE2LCBhdCAxODowNCwgRGVhcmxvdmUsIENocmlzdG9waGVyIChV
SykgPGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBi
YWVzeXN0ZW1zLmNvbT4+IHdyb3RlOg0KDQpPSywgc28gd2UgaGF2ZSBhIG1lc3NhZ2UgdGhhdCBt
dXRhdGVzIGJ5Og0KLSBNb2RpZnlpbmcgaG9wIGNvdW50L2xpbWl0Lg0KLSBNb2RpZnlpbmcgYSBt
ZXRyaWMgdmFsdWUuDQpBbnl0aGluZyBlbHNlPw0KDQpBcyBtdXRhdGluZyAob3RoZXIgdGhhbiBo
b3AgY291bnQvbGltaXQpIG1lc3NhZ2VzIGFyZW7igJl0IGNvdmVyZWQgYnkgNTQ0NCBvciBhbnkg
ZGVyaXZhdGl2ZSBkb2N1bWVudCAoYnV0IG9ubHkgcmVjb21tZW5kZWQgYWdhaW5zdCwgbm90IGJh
bm5lZCkgdGhhdCB5b3UgbWF5IG5lZWQgdG8gbWFrZSB0aGUgbWVzc2FnZSBvdGhlcndpc2UgaW1t
dXRhYmxlIChubyBkZWNvbnN0cnVjdGlvbiBhbmQgcmVidWlsZGluZywgb3RoZXIgdGhhbiBndWFy
YW50ZWVkIHVuY2hhbmdpbmcpIHRoYXQgd291bGQgaGF2ZSB0byBiZSBzcGVjaWZpZWQgYnkgQU9E
VnYyLiAoRWFzeSB0byBzYXksIGJ1dCBuZWVkcyBzYXlpbmcuKQ0KDQpXaXRoIHlvdSBzbyBmYXIu
DQoNClRoZW4gdGhhdCBpbmZvcm1hdGlvbiBpcyBub3QgaW4gYSBndWFyYW50ZWVkIGZpeGVkIGxv
Y2F0aW9uIGdpdmVuIGJ5IGEgc2ltcGxlIG9mZnNldC4gU28gYW55IHNpZ25hdHVyZSBhbGdvcml0
aG0gdGhhdCBmaW5kcyBpdCBhbmQgaWdub3JlcyBpdCBvciBhZ2dyZWdhdGVzIG9uIGl0IGlzIHNw
ZWNpZmljIHRvIE9MU1J2Mi4NCg0KU3VyZWx5IHlvdSBtZWFuIEFPRFZ2Mg0KDQpTbyBzdGFuZGFy
ZCA3MTgyIElDVnMgZG9u4oCZdCBkbyB0aGUgam9iLCB5b3Ugd291bGQgbmVlZCBhbiBBT0RWdjIg
c3BlY2lhbGlzZWQgdmFyaWFudC4gV2hpY2ggaXMgdGhlIHNvcnQgb2YgdGhpbmcgdGhhdCB0aGUg
bWVzc2FnZSBzcGVjaWZpYyBUTFYgc3BhY2UgaXMgdGhlcmUgZm9yLCBJ4oCZZCBiZSBzdHJvbmds
eSBhZ2FpbnN0IGEg4oCcYnV0IGlnbm9yZSB0aGUgdmFsdWUgb2YgdGhpcyBzcGVjaWZpYyBUTFYg
c2hvdWxkIGl0IG9jY3Vy4oCdIGJlaW5nIGluIHRoZSBnZW5lcmFsIHNwYWNlLiBIb3dldmVyIGl0
IGNhbiBlYXNpbHkgYmUgZGVmaW5lZCBieSByZWZlcmVuY2UgdG8gNzE4MiAo4oCcdGhpcyBUTFYg
aXMgbGlrZSB0aGF0IFRMViwgZXhjZXB0IGlmIGFuIFggVExWIGlzIHByZXNlbnQsIHNldCBpdHMg
dmFsdWUgZmllbGQgdG8gemVyb+KAnSkuDQoNCk1lc3N5LCBidXQgY291bGQgd29yay4NCg0KTm90
IHRoYXQgbWVzc3ksIGFjdHVhbGx5LCBhbHRob3VnaCBjbGVhcmx5IG5vdCBhcyBuaWNlIGFzIOKA
nGZpeGVkIG9mZnNldOKAnS4NCg0KVGhhdCBzYWlkLCBJIGFtIGFyZ3VpbmcgZm9yIHRoZSBiYXNl
IHNwZWMgYmVpbmc6DQoNCiAgICAgICAgICAgIOKAnG1ha2UgdGhlIG1lc3NhZ2Ugb3RoZXJ3aXNl
IGltbXV0YWJsZSAobm8gZGVjb25zdHJ1Y3Rpb24gYW5kIHJlYnVpbGRpbmcsIG90aGVyDQogICAg
ICAgICAgICAgdGhhbiBndWFyYW50ZWVkIHVuY2hhbmdpbmcp4oCdIHdoaWNoIGlzIGFmZm9yZGVk
IGJ5IGZvcndhcmRpbmcNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKw0K
DQogICAgICAgICAgICBSRkM3MTgyIFRpbWVzdGFtcHMgYW5kIElDVnMuDQoNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICsNCg0KICAgICAgICAgICAgUkZDNzE4MyBzdHlsZSB0
ZXh0IGJyaW5naW5nIGl0IGFsbCB0b2dldGhlci4NCg0KVGhlIOKAnGFnZ3JlZ2F0ZWQgc2lnbmF0
dXJlcyBhcm91bmQgbXV0YWJsZSBmaWVsZOKAnSB3b3VsZCB2ZXJ5IGJlIGFuIGV4cGVyaW1lbnRh
bCBleHRlbnNpb24uDQoNCldoYXQgSSBvYmplY3QgdG8gaXMsIGlmIHRoZSBiYXNlIHNwZWMgc3Bl
Y2lmaWNhbGx5IHJlbmRlcnMgc3VjaCBleHRlbnNpb25zIGltcG9zc2libGUNCg0KDQoNCi0tDQpD
aHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3Rl
bXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
DQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0
PiAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJs
b3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwg
Q2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNz
ZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMu
Y29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0
ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTog
U3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206
IExvdHRlIFN0ZWVuYnJpbmsgW21haWx0bzpsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZV0N
ClNlbnQ6IDE3IE1hcmNoIDIwMTYgMTY6NDgNClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVL
KQ0KQ2M6IGlldGZAdGhvbWFzY2xhdXNlbi5vcmc8bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5v
cmc+OyBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdA0KU3ViamVjdDogUmU6IFtt
YW5ldF0gTWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2UgbXV0YWJpbGl0eSAod2FzIFJFOiBk
cmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0
IEl0ZW1zKQ0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJv
bSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRu
ZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3Vs
ZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9y
IGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZv
ciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5i
YWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVk
JTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVh
c2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29t
L2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUy
MFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCkhpIGFsbCwNCg0KQW0gMTcuMDMuMjAxNiB1bSAx
Nzo0NCBzY2hyaWViIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92ZUBi
YWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PjoNCg0K
R29vZCBwb2ludCBhYm91dCB3aGV0aGVyIHlvdSBqdXN0IHBhc3Mgb24gb25lIGNvc3Qgb3IgYSBz
ZXQgb2YgY29zdHMuIEFzIEkgc2FpZCwgbm90IGxvb2tlZCBhdCBkZXRhaWxzIC0gSSB3aWxsLCB3
aGVuIHRpbWUgcGVybWl0cy4gT25lIGNvc3QgaXMgbXVjaCBlYXNpZXIsIGFuZCB5ZXMsIGl0IHJl
ZHVjZXMgdGhlIGZpeGVkIHNpemUgYWdncmVnYXRlZCBzaWduYXR1cmVzIHByb2JsZW0gdG8g4oCc
anVzdOKAnSBvbmUgb2YgY29tcHV0YXRpb25hbCBsb2FkLg0KDQpGb3IgdGhlIHJlY29yZCwgVGhv
bWFz4oCZIHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdDsgdGhlIGNvc3QgaXMgb25lIGFnZ3JlZ2F0
ZWQgdmFsdWUuDQoNCkJlc3QgcmVnYXJkcywNCkxvdHRlIFN0ZWVucmJpbmsNCg0KDQotLQ0KQ2hy
aXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1z
IEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K
VDogICs0NCAoMCkxMjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4g
IHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92
ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENo
ZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4
IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNv
bS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVy
ZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1
cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBp
ZXRmQHRob21hc2NsYXVzZW4ub3JnPG1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3JnPiBbbWFp
bHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmddDQpTZW50OiAxNyBNYXJjaCAyMDE2IDE2OjM4DQpU
bzogRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNCkNjOiBNb2JpbGUgQWQgSG9jIE5ldHdvcmtz
IG1haWxpbmcgbGlzdA0KU3ViamVjdDogUmU6IE1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBtZXNzYWdl
IG11dGFiaWxpdHkgKHdhcyBSRTogW21hbmV0XSBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyBy
ZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKQ0KDQoNCioqKiBXQVJOSU5HICoq
Kg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24s
IGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lk
ZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4g
YW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQg
RmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNs
aWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2Vj
dXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVs
IHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRw
Oi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGln
aHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4N
Cg0KT24gMTcgTWFyIDIwMTYsIGF0IDE3OjMwLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8
Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5
c3RlbXMuY29tPj4gd3JvdGU6DQoNCkkgYXBwcmVjaWF0ZSBUaG9tYXPigJlzIGNvbW1lbnRzIGFi
b3V0IHRoZSBsaW1pdGF0aW9ucyBvZiBtZXNzYWdlIHJlZ2VuZXJhdGlvbiwgYnV0IEkgd291bGQg
YmUgYSBiaXQgbGVzcyBhYnNvbHV0ZS4NCg0KVGhlIGlzc3VlcyBvdmVyIGVuZCB0byBlbmQgYXV0
aGVudGljYXRpb24gYW5kIG1vcmUgYWR2YW5jZWQgc2lnbmF0dXJlcyBhcmUgdmFsaWQuIEkgbmVl
ZCB0byByZWFkIHRoZSBnaXZlbiByZWZlcmVuY2Ugb24gYWdncmVnYXRlIHNpZ25hdHVyZXMgdG8g
aW5jcmVhc2UgbXkga25vd2xlZGdlICh0aGFua3MgZm9yIGl0KSwgYnV0IG15IHVuZGVyc3RhbmRp
bmcgb2YgdGhlIHBvc3NpYmlsaXRpZXMgaW4gdGhpcyBmaWVsZCBtYXkgb2ZmZXIgYSBzb2x1dGlv
biB0byB0aGUgcHJvYmxlbSwgYnV0IHdpdGggc29tZSBvdGhlciBpc3N1ZXMgKHBvc3NpYmx5IGlu
Y2x1ZGluZyBhIG5ldyB0eXBlIG9mIFRMVikuDQoNCkJ1dCB0aGUgaG9wIGNvdW50L2xpbWl0IHBv
aW50IEkgZG9u4oCZdCBmdWxseSBhZ3JlZSB3aXRoLCB5b3UgY2FuIHJlZ2VuZXJhdGUgd2l0aCBh
biBpbmNyZW1lbnRlZC9kZWNyZW1lbnRlZCBjb3VudC9saW1pdCwgd2hpY2ggbGVhdmVzIHRoZSBh
YmlsaXR5IHRvIHByZXZlbnQgbWVzc2FnZXMgcHJvcGFnYXRpbmcgaW5kZWZpbml0ZWx5LCBpbmNs
dWRpbmcgZXhwYW5kaW5nIHJpbmcgc2VhcmNoZXMsIGFuZCByZXRhaW5zIHRoZSBhYmlsaXR5IHRv
IHVzZSBSRkMgNTQ5NyBpbnRlcnZhbCBhbmQgdmFsaWRpdHkgdGltZXMgdGhhdCBtaWdodCBiZSB1
c2VmdWwgd2l0aCBhbiBleHBhbmRpbmcgcmluZyBzZWFyY2ggKG9yIG1pZ2h0IG5vdCkuDQoNCkJ1
dCB0aGUga2V5IGlzc3VlIGlzIHRoYXQgQU9EVnYyIHdhbnRzIHRvIGFjY3VtdWxhdGUgbWV0cmlj
cy4gSSBzdGlsbCBoYXZlbuKAmXQgZ290IHRvIHRoZSBib3R0b20gb2YgbWFueSBkZXRhaWxzIGhl
cmUsIGJ1dCBsZXTigJlzIGZvciB0aGUgbW9tZW50IGp1c3QgY29uc2lkZXIgdGhhdCBjb25jZXB0
dWFsbHkuDQoNCkl04oCZcyBoYXJkIHRvIGhhbmRsZSBlbmQgdG8gZW5kLiBDaGFybGll4oCZcyBk
cmFmdCBhdHRlbXB0cyB0byBkbyBhbiBlbmQgdG8gZW5kIG9mIHNvbWUgaW5mb3JtYXRpb24sIG5v
dCB0aGlzIGluZm9ybWF0aW9uLiBJ4oCZbSBub3Qgc3VyZSBpZiB0aGF04oCZcyB1c2VmdWwgKGFu
ZCB0aGUgc3BlY2lhbGlzZWQgZm9ybWF0IGlzIGJldHRlciBhdm9pZGVkIGlmIHBvc3NpYmxlKS4g
T3RoZXIgYXBwcm9hY2hlcyBhcmUgaG9wIGJ5IGhvcCAobWlnaHQgYXMgd2VsbCB1c2UgcGFja2V0
IHNpZ25hdHVyZXMpIGFuZCBzaGFyZWQga2V5IChtaWdodCBhcyB3ZWxsIGdvIGhvcCBieSBob3Ap
LiBQYWlyd2lzZSBzaWduYXR1cmVzIGZvciBlYWNoIHBhaXIgb2Ygcm91dGVycyBJ4oCZbSBkaXNj
b3VudGluZyBhcyBzY2FsaW5nIHRlcnJpYmx5LiBJbiB0aGUgaW50ZXJlc3RzIG9mIGNvbXBsZXRl
bmVzcyBsZXTigJlzIG1lbnRpb24gbm90IGFjY3VtdWxhdGluZyBtZXRyaWNzLCB3aGljaCBwdXRz
IHVzIGJhY2sgdG8gaG9wIGNvdW50IGFuZCB0aGF04oCZcyBub3QgaWRlYWwgZWl0aGVyLg0KDQpJ
IGRvbuKAmXQgdGhpbmsgdGhlcmUgaXMgYW4gaWRlYWwgc29sdXRpb24uIChJIGxpa2UgaWRlYXMg
SeKAmXZlIHNlZW4gYWJvdXQgYWdncmVnYXRpbmcsIGJ1dCB0aGF0IGhhcyBzb21lIGlzc3VlcyBv
ZiBpdHMgb3duLCBldmVuIGFwYXJ0IGZyb20gY29tcHV0YXRpb25hbCBsb2FkLikgSeKAmWQgbG92
ZSB0byBiZSBwcm92ZWQgd3JvbmcgLSBzb21lb25lIHdpdGggdGhlIHBlcmZlY3Qgc29sdXRpb24g
dG8gY29tZSBhbG9uZy4NCg0KV2hpY2ggbWVhbnMgdGhhdCBlaXRoZXIgd2UgbWFrZSBhbiBhcmJp
dHJhcnkgY2hvaWNlIC0gd2hpY2ggd2lsbCBiZSBkaXNhZ3JlZWQgd2l0aCwgYnV0IG5lZWRzIGRp
c2N1c3NpbmcgZmlyc3QgLSBvciBjcmVhdGUgc29tZXRoaW5nIGZsZXhpYmxlLiBVbmZvcnR1bmF0
ZWx5IGZsZXhpYmxlIGluIHRoYXQgcmVnYXJkIGNvbnN0cmFpbnMgaW4gb3RoZXJzLCBlLmcuIHNv
bWUgKG1hbnk/IG1vc3Q/KSBhZ2dyZWdhdGluZyBzaWduYXR1cmVzIG5lZWQgZml4ZWQgZGF0YSBz
aXplcyAod2hpY2ggd2UgY2FuIGRvIGJ5IGRlZmluaW5nIGEgVExWIHRoYXQg4oCcZmlsbHMgdXDi
gJ0gd2l0aCBob3AgY291bnQsIGJ1dCB0aGF0IGhhcyBhIGNvc3QgdG9vKS4NCg0KSSBoYXZlIGJl
ZW4gdG9sZCBieSBwZW9wbGUgbXVjaCBtb3JlIHdlbGwgdmVyc2VkIGluIHRoaXMgdGhhbiBJIGlu
IGNyeXB0b2xvZ3ksIHRoYXQgdGhlIGNvcnJlY3QgYW5zd2VyIGlzIOKAnHNvbWXigJ0uDQoNClRo
YXQgc2FpZCwgIkFPRFZ2MiB3YW50cyB0byBhY2N1bXVsYXRlIG1ldHJpY3PigJ0g4oCUIGRvZXMg
dGhhdCBtZWFuIHRoYXQgdGhlIG1lc3NhZ2UgZ3Jvd3MgYXMgaXQgaXMgYmVpbmcgZm9yd2FyZGVk
LCBhbmQgdGhhdCB0aGUgcmVjaXBpZW50IG9mIGEgUlJFUS9SUkVQIHdpbGwga25vdyB0aGUgaW5k
aXZpZHVhbCBjb3N0cyBvZiBlYWNoIHBhdGggc2VnbWVudD8gTXkgdW5kZXJzdGFuZGluZyBpcywg
dGhhdCB0aGUgcmVjaXBpZW50IHdpbGwgZ2V0IOKAnHRoZSBzdW0gdGhlIGNvc3RzIG9mIGVhY2gg
cGF0aCBzZWdtZW504oCdIHdoaWNoIHNob3VsZCBiZSBmaXR0aW5nIHdpdGhpbiBhIGZpeGVkIHNp
emU/DQoNClRob21hcw0KDQoNCg0KDQpTb3JyeSwgbm8gYW5zd2VycywganVzdCBjb21tZW50cy4g
QW5kIEnigJltIG5vdCBhZGRyZXNzaW5nIFRob21hc+KAmXMgbGF0ZXIgcG9pbnRzIGhlcmUuDQoN
Ci0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFF
IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIw
MjQyMTk0PiAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlz
LmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln
ZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9y
ZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5
c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0K
UmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9m
ZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoN
CkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IGlldGZAdGhvbWFzY2xhdXNlbi5vcmc8bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmc+DQpT
ZW50OiAxNyBNYXJjaCAyMDE2IDE2OjAwDQpUbzogTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWls
aW5nIGxpc3QNClN1YmplY3Q6IFttYW5ldF0gZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2
aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcw0KDQoNCioqKiBXQVJOSU5HICoqKg0K
VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVp
dGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIg
Y2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55
IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxh
Z3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNr
IGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJp
dHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRo
ZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8v
aW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRz
L0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCioq
KiBXQVJOSU5HICoqKg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMg
ZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb24uDQoNCkRlYXIgYWxsLA0KDQpBcG9sb2dpZXMg
Zm9yIG5vdCBoYXZpbmcgZ290dGVuIHRoaXMgZG9uZSBzb29uZXIgLSBkYXktam9iIGxlYXZpbmcg
ZmV3IHNwYXJlIGN5Y2xlcy4NCg0KSeKAmXZlIHByZXZpb3VzbHkgb2ZmZXJlZCByZXZpZXdzIGFu
ZCBjb21tZW50cywgYW5kIHNvbWUgb2YgdGhvc2UgaGF2ZSBiZWVuIGFkZHJlc3NlZCBpbiB0aGUg
bGF0ZXN0IEktRCDigJQgb3RoZXJzIGhhdmUgbm90LCBidXQgc2hvdWxkIGJlLiBJIHJlY2FsbCB0
aGF0IHRoZXJlIHdhcyBzb21lIG1haWwgYXR0ZW1wdGluZyB0byByZWJ1dCBwYXJ0cyBvZiB0aGUg
cmV2aWV3LCBhbmQgSSB3aWxsIGRpZyBpdCBvdXQgYW5kIHJlcGx5IHRvIHRoYXQuDQoNCldpdGgg
dGhhdCBiZWluZyBzYWlkLCBJIGhhdmUgcmV2aWV3ZWQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRo
ZSBkb2N1bWVudCwgYW5kIGZ1bGwgZGV0YWlscyB3aWxsIGJlIGZvcnRoY29taW5nLiBUaGVyZeKA
mXJlIGEgY291cGxlIG9mIGJpZy10aWNrZXQvYXJjaGl0ZWN0dXJhbCBpdGVtcyB0aGF0IEkgd2Fu
dCB0byBhZGRyZXNzIHVwIGZyb250LCBhcyBJIGJlbGlldmUgdGhhdCBiZWZvcmUgd2UgaGF2ZSB0
aG9zZSBoYW1tZXJlZCBvdXQsIGl0IHdpbGwgYmUgdXNlbGVzcyB0byBnbyBpbnRvIGRldGFpbHMu
IE5vdGUsIEkgZG8gbm90IGNsYWltIHRoYXQgdGhpcyBpcyBhbiBleGhhdXN0aXZlIGxpc3Qgb2Yg
4oCcYmlnIHRpY2tldCBpdGVtc+KAnSwgYnV0IHRoYXTigJlzIGFzIGZhciBhcyBJIGhhdmUgZ290
dGVuIGluIHRoaW5raW5nIHRoaXMgdGhyb3VnaC4NCg0KSSBhbHNvIGJyaW5nIHRoZXNlIHVwIGFz
IHRoZXkgYXJlIGl0ZW1zIHRoYXQgaGF2ZSBiZWVuIGJyb3VnaHQgdXAgcmVwZWF0ZWRseSBvdmVy
IHRoZSBwYXN0IHllYXJzLCBidXQgbm90IHJlc29sdmVkIG5vciBkaXNjdXNzZWQuDQoNCkxvb3Bz
DQpKdXN0IHRvIGJyaW5nIHRoaXMgb3V0OiBJIHNoYXJlIENocmlz4oCZIHdvcnJ5IGFib3V0IGNv
bmZsaWN0aW5nIGFuZCBjb25jdXJyZW50IHN0YXRlbWVudHMgZnJvbSB0aGUgYXV0aG9ycyBvbiDi
gJxUaGVyZSBhcmUgbm8gbG9vcHMgcG9zc2libGXigJ0gYW5kIOKAnFdlIG5lZWQgdG8gZml4IHR3
byBzaXR1YXRpb25zIHdoZXJlIGxvb3BzIGNhbiBvY2N1cuKAnSBhbmQg4oCcd2UgYXJlIHN0aWxs
IGludmVzdGlnYXRpbmcgc29tZSBsb29wIGNvbmRpdGlvbnPigJ0NCg0KSSBwYXJ0aWN1bGFybHkg
d29ycnkgdGhhdCB0aGlzIGlzIG5vdCBhIGRpc2N1c3Npb24gaGFkIGluIHB1YmxpYywgYnV0IGFw
cGFyZW50bHkgaW4gc29tZSBvdGhlciBmb3J1beKApg0KDQoNCkludGVybWVkaWF0ZSBSb3V0ZSBS
ZXBsaWVzLCBhbmQgYWxsIG9mIHNlY3Rpb24gMTANClNlY3Rpb24gMTAgY29udGFpbnMgYSBzZXQg
b2Yg4oCcdmFndWVseSBzcGVjaWZpZWQgZXh0ZW5zaW9uc+KAnSwgd2hpY2ggaXMgaW5jb2hlcmVu
dCB3aXRoIHRoZSBpbnRlbmRlZCBzdGF0dXMgaW5kaWNhdGVkIGZvciB0aGlzIGRvY3VtZW50Lg0K
DQpTcGVjaWZpY2FsbHksIGFuZCB0aGlzIGlzIG5vdCB1bnJlbGF0ZWQgdG8gdGhlIHBvaW50IGFi
b3V0IGxvb3BzIGFib3ZlLCBpbnRlcm1lZGlhdGUgUlJFUHMgKHNlY3Rpb24gMTAuMykgYXJlIGEg
cG90ZW50aWFsIHNvdXJjZSBmb3IgbG9vcHMuDQoNCkV4cGFuZGluZyBSaW5nIE11bHRpY2FzdCAo
c2VjdGlvbiAxMC4xKSBpcyBub3QgZG9jdW1lbnRlZCBpbiBhIHdheSB0aGF0IGNhbiBiZSBpbXBs
ZW1lbnRlZCAoYW5kIGFsc28sIHNlZSDigJxGb3J3YXJkaW5nLXZzLXJlZ2VuZXJhdGlvbuKAnSBi
ZWxvdywgaXQgaXMgaW4gdGhlIHByZXNlbnQgZm9ybSBvZiB0aGlzIHByb3RvY29sIGltcG9zc2li
bGUpLCBldGMuDQoNCg0KRm9yd2FyZGluZy12cy1yZWdlbmVyYXRpb24NClJlY2VudCBleGNoYW5n
ZXMgb24gdGhlIGxpc3QgbWFkZSBtZSB1bmRlcnN0YW5kIHRoYXQgcHJvdG9jb2wgY29udHJvbCBt
ZXNzYWdlcyBhcmUgKm5vdCogZm9yd2FyZGVkLCBidXQgYXJlIGNvbnN1bWVkIGF0IGVhY2ggaG9w
LCB0aGVuIGEgbmV3IG1lc3NhZ2Ugd2l0aCAoYWxtb3N0LWJ1dC1ub3QtcXVpdGUpIHRoZSBzYW1l
IGNvbnRlbnQgaXMgZ2VuZXJhdGVkIGFuZCB0cmFuc21pdHRlZC4NCg0KSSBoYXZlIHRob3VnaHQg
c29tZSBtb3JlIG9uIHRoaXMgKCYgcmVhZCBzb21lIG9mIHRoZSBleGNoYW5nZXMgb24gdGhlIGxp
c3Qgb24gdGhpcyB0b3BpYyBieSBDaHJpcywgVWxyaWNoLCBhbmQgb3RoZXJzKSwgYW5kIEkgYW0g
Y29udmluY2VkIHRoYXQgdGhpcyBpcyBub3QgdGhlIHJpZ2h0IHdheSB0byBnbywgYXQgbGVhc3Qg
Zm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczoNCg0KDQogICAgICAgICAgICBvICAgICAgICAgIEl0
IHJlbmRlcnMgdGhlIGhvcC1saW1pdC9ob3AtY291bnQgZmllbGRzIGluIHRoZSBSRkM1NDQ0IG1l
c3NhZ2UgaGVhZGVyIHVzZWxlc3MuDQogICAgICAgICAgICAgICAgICAgICAgICBUaGlzIHdvdWxk
IG5vdCBiZSBiYWQgaWYgdGhlIGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBieSB0aG9zZSBmaWVsZHMg
d2FzIG5vdCB1c2VmdWwNCiAgICAgICAgICAgICAgICAgICAgICAgIOKAlCBzYWRseSwgaXQgaXMu
IEZvciBleGFtcGxlLCBmb3Igc2NvcGUgbGltaXRlZCBmbG9vZGluZyAoZXhwYW5kaW5nIHJpbmcg
c2VhcmNoLCBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgIHN1Y2gpIHdoaWNoIG1heSBiZSBv
ZiBpbnRlcmVzdCwgYW5kIHdoaWNoIHJlcXVpcmUgaG9wLWxpbWl0Lg0KICAgICAgICAgICAgICAg
ICAgICAgICAgQSBob3AtY291bnQgZmllbGQgbWF5IGFsc28gcHJvdmlkZSBhIOKAnGNoZWFw4oCd
IChpbiB0ZXJtcyBvZiBvdmVyaGVhZCkgYWRkaXRpb25hbCBwaWVjZQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgb2YgaW5mb3JtYXRpb24gdG8gdXNlIGNvbmp1bmN0aXZlbHkgd2l0aCBhIOKAnHJl
YWzigJ0gbWV0cmljLg0KDQogICAgICAgICAgICAgICAgICAgICAgICBUaGUgb25seSBwcmFjdGlj
YWwgc29sdXRpb24gd291bGQgYmUgdG8gcmUtaW50cm9kdWNlIHRoZXNlIGZ1bmN0aW9ucyBieSB3
YXkgb2YgaW5zZXJ0aW5nIGENCiAgICAgICAgICAgICAgICAgICAgICAgIE1lc3NhZ2VUTFYg4oCU
IHdoaWNoIChpKSBpcyBub3Qgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQsIGFuZCAoaWkpIHdo
aWNoIHdvdWxkIGp1c3QNCiAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZlIHRvIHJlbmRlciBt
ZXNzYWdlcyBiaWdnZXIgdGhhbiBzdHJpY3RseSBuZWVkZWQuDQoNCiAgICAgICAgICAgICAgICAg
ICAgICAgIFNjb3BlIGxpbWl0ZWQgZmxvb2RpbmcgIGRvZXMgc2VlbSB0byBiZSBhIG5lY2Vzc2Fy
eSByZXF1aXJlbWVudCwgaWYgZm9yIG5vDQogICAgICAgICAgICAgICAgICAgICAgICBvdGhlciBy
ZWFzb24gdGhhbiB0byBwcmV2ZW50IGluZm9ybWF0aW9uIGZyb20g4oCcY2lyY3VsYXRpbmcgZm9y
ZXZlciBpbiB0aGUgbmV0d29ya+KAnS4NCg0KICAgICAgICAgICAgbyAgICAgICAgICBJdCBtYWtl
cyBlbmQtdG8tZW5kIGF1dGhlbnRpY2F0aW9uIHVubmVjZXNzYXJpbHkgaGFyZC4NCiAgICAgICAg
ICAgICAgICAgICAgICAgIEkgdGhpbmsgQ2hyaXMgY2FsbGVkIHRoaXMgb3V0IGFscmVhZHksIGJ1
dCBpdCBiZWFycyByZXBlYXRpbmc6IFMgZ2VuZXJhdGVzIGEgbWVzc2FnZQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgKHNheSwgYSBSUkVRKSwgYW5kIGluY2x1ZGVzIGFuIElDViBjYWxjdWxhdGVk
IG92ZXIgdGhlIGNvbnRlbnQgb2YgdGhlIG1lc3NhZ2UuDQogICAgICAgICAgICAgICAgICAgICAg
ICBGb3IgYW55IHJlY2lwaWVudCB0byBiZSBhYmxlIHRvIHZhbGlkYXRlIHRoZSBJQ1YsIHRoZSBt
ZXNzYWdlIGhhcyB0byBiZSBleGFjdGx5DQogICAgICAgICAgICAgICAgICAgICAgICB0aGUgc2Ft
ZSDigJQgbm90IGp1c3QgaW4gY29udGVudCwgYnV0IGluIHN0cnVjdHVyZSDigJQgYXMgd2hhdCB3
YXMgZ2VuZXJhdGVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICDigJxSZWdlbmVyYXRpbmfi
gJ0gcmF0aGVyIHRoYW4g4oCcZm9yd2FyZGluZ+KAnSBtZXNzYWdlcyBtZWFucywgdGhhdCB0aGUg
aW50ZXJtZWRpYXRlDQogICAgICAgICAgICAgICAgICAgICAgICByb3V0ZXIg4oCccmVnZW5lcmF0
aW5n4oCdIHRoZSBSUkVRIG1heSBjaG9zZSBhIGRpZmZlcmVudCBzdHJ1Y3R1cmUgKGUuZy4sIGlu
Y2x1ZGUgVExWcw0KICAgICAgICAgICAgICAgICAgICAgICAgaW4gYSBkaWZmZXJlbnQgb3JkZXIp
Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICBUaGUgcHJvcG9zYWwgZnJvbSBodHRwczovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMA0KICAg
ICAgICAgICAgICAgICAgICAgICAgaXMgdG8gYWRkIGNvbnN0cmFpbnRzIG9uIChpKSB0aGUgc2V0
IG9mIGVsZW1lbnRzIHRvIGluY2x1ZGUgaW4gYSBzaWduYXR1cmUgYW5kIChpaSkgdGhlDQogICAg
ICAgICAgICAgICAgICAgICAgICBvcmRlciBvZiB0aGVzZSBlbGVtZW50cy4NCg0KICAgICAgICAg
ICAgICAgICAgICAgICAgT25lIHByb2JsZW0gd2l0aCB0aGF0IGFwcHJvYWNoIGlzIChpKTogaWYg
YW4gZXh0ZW5zaW9uIGFkZHMgYSBtZXNzYWdlIFRMViwgb3IgYW4NCiAgICAgICAgICAgICAgICAg
ICAgICAgIEFkZHJlc3MgVExWLCB0byBhIG1lc3NhZ2UsIHRoZW4gdGhhdCB3aWxsIG5vdCBiZSDi
gJxjb3ZlcmVk4oCdIGJ5IHRoZSBwcm9wb3NlZCBlMmVzZWMgVExWLg0KICAgICAgICAgICAgICAg
ICAgICAgICAgUmF0aGVyIGZvciAqZWFjaCogZXh0ZW5zaW9uIGRldmVsb3BlZCwgYW4g4oCcdXBk
YXRlcyBlMmVzZWPigJ0gY2xhdXNlIG5lZWRzIHRvIGJlIGRvbmUuDQoNCiAgICAgICAgICAgICAg
ICAgICAgICAgIEnigJlkIHNheSB0aGF0IHRoaXMgYXBwcm9hY2ggd291bGQgYmUgcHJvbmUgdG8g
ZXJyb3JzIOKAlCBhbmQgYWRkIGVudHJvcHkgdG8gdGhlIHByb2Nlc3MNCiAgICAgICAgICAgICAg
ICAgICAgICAgIG9mIGRlc2lnbmluZyBwcm90b2NvbCBleHRlbnNpb25zLiBUaGUgYWx0ZXJuYXRp
dmUsIGEgbWVzc2FnZSBiZWluZyBnZW5lcmF0ZWQgYnkgdGhlDQogICAgICAgICAgICAgICAgICAg
ICAgICBzb3VyY2UgYW5kICpmb3J3YXJkZWQqIChhcyB3ZSBkbyBpbiBPTFNSdjIsIGZvciBleGFt
cGxlKSB3b3VsZCBhbGxvdyBJQ1YgVExWcw0KICAgICAgICAgICAgICAgICAgICAgICAgKGV2ZW4s
IGFsbG93IHJldXNlIG9mIHRob3NlIHNwZWNpZmllZCBmb3IgT0xTUnYyKSBmb3IgY292ZXJpbmcg
YSBtZXNzYWdlIGFuZA0KICAgICAgICAgICAgICAgICAgICAgICAgZXh0ZW5zaW9ucy4NCg0KICAg
ICAgICAgICAgICAgICAgICAgICAg4oCcQnV0IHdoYXQgYWJvdXQgdGhlIG1ldHJpY3MgdmFsdWUg
d2hpY2ggd2lsbCBjaGFuZ2Ugb24gZWFjaCBob3DigJ0sIHlvdSBtYXkgc2F5Pw0KICAgICAgICAg
ICAgICAgICAgICAgICAgRm9ydHVuYXRlbHksIHRoYXQgaXMgcmVsYXRpdmVseSBlYXN5IHRvIGhh
bmRsZTogc2ltcGx5IHplcm8gb3V0IHRoZSB2YWx1ZSBvZiB0aGF0IFRMViB3aGVuDQogICAgICAg
ICAgICAgICAgICAgICAgICBnZW5lcmF0aW5nIG9yIHZlcmlmeWluZyB0aGUgSUNWIE1lc3NhZ2VU
TFYuIEFuZCB1c2UgUGFja2V0LVRMVnMgZm9yIGhvcC1ieS1ob3ANCiAgICAgICAgICAgICAgICAg
ICAgICAgIGF1dGhlbnRpY2F0aW9uLCBpZiBuZWVkZWQgKGJ1dCwgc2VlIGJlbG93KS4NCg0KICAg
ICAgICAgICAgbyAgICAgICAgICBJdCBwcmV2ZW50cyB0aGUgdXNlIG9mIG1vcmUgY2xldmVyL2Fk
dmFuY2VkIHNpZ25hdHVyZSBzY2hlbWVzL0lDVnMNCiAgICAgICAgICAgICAgICAgICAgICAgIEFn
Z3JlZ2F0ZSBzaWduYXR1cmUgYWxnb3JpdGhtcyAoIGh0dHBzOi8vY3J5cHRvLnN0YW5mb3JkLmVk
dS9+ZGFiby9wYXBlcnMvYWdnc3VydmV5LnBkZikNCiAgICAgICAgICAgICAgICAgICAgICAgIGV4
aXN0LCBhbmQgYW4gaW50ZXJlc3RpbmcgdXNlLWNhc2UgY2FuIGJlIGZvdW5kIGluIGFsc28gcmVh
Y3RpdmUgcHJvdG9jb2xzLCBhbGxvd2luZyB2ZXJpZnlpbmcNCiAgICAgICAgICAgICAgICAgICAg
ICAgIG5vdCDigJxqdXN04oCdIHRoZSBlbmQgcG9pbnRzLCBidXQgYWxzbyB0aGUgaW50ZXJtZWRp
YXJpZXMgKGFnYWluLCB3aXRoIHRoZSBhcHByb3ByaWF0ZSDigJx6ZXJvIG91dOKAnQ0KICAgICAg
ICAgICAgICAgICAgICAgICAgZGlzY3Vzc2VkIGFib3ZlLCBvciBzb21ldGhpbmcgc21hcnRlciku
DQogICAgICAgICAgICAgICAgICAgICAgICBSZWdlbmVyYXRpb24gb2YgbWVzc2FnZXMsIHJhdGhl
ciB0aGFuIGZvcndhcmRpbmcsIHJlbmRlcnMgdGhhdCBpbXBvc3NpYmxlIChvciwgaWYgdXNlZCwN
CiAgICAgICAgICAgICAgICAgICAgICAgIHVwZGF0aW5nIHRvICBodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMCkNCg0KVGhlcmUgYXJl
IG90aGVyIHJlYXNvbnMsIGJ1dCB0aGUgYWJvdmUgYXJlIHRob3NlIHRoYXQganVtcCBhdCBtZSBh
cyBpbW1lZGlhdGUgc2hvdy1zdG9wcGVycy4NCg0KSSBkbyBob25lc3RseSBub3Qgc2VlIHdoYXQg
cG9zc2libGUgYmVuZWZpdCB0aGVyZSBpcyBmcm9tIOKAnHJlZ2VuZXJhdGlvbuKAnSDigJQgYnV0
IEkgc2VlIHZlcnkgY2xlYXIgaW5jb252ZW5pZW5jZXMsIGFuZCBzZWN1cml0eSBpcyBub3QgdGhl
IGxlYXN0IG9mIHRoZXNlLiBJbnNpc3Rpbmcgb24g4oCccmVnZW5lcmF0aW9u4oCdIHJlcXVpcmVz
IGRldmVsb3BtZW50IG9mIOKAnG5vbi1nZW5lcmFsIHdvcmthcm91bmRz4oCdIGFzIHBvaW50ZWQg
b3V0IGFib3ZlLg0KDQpTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KVGhpcyBpcyBhbiBhbHdheXMg
dGhvcm55IHN1YmplY3QuIFdoZW4gT0xTUnYyIHdhcyBnb2luZyB0aHJvdWdoIHRoZSBwcm9jZXNz
IHdlIGdvdCBhIHRob3JvdWdoIGVkdWNhdGlvbiBpbiBob3cgbGl0dGxlIHdlIGtuZXcgYWJvdXQg
c2VjdXJpdHkgZnJvbSB0aGUgU0VDLUFEcywgYW5kIGhhZCB0byBzcGVuZCBhYm91dCBhIHllYXIg
b3Igc28gZGV2ZWxvcGluZyBSRkM3MTgzLiBUaGUgYm90dG9tIGxpbmUgaXMsIHRoYXQgdGhpcyBw
cm90b2NvbCBuZWVkcyBpdHMg4oCcUkZDNzE4MyAgZXF1aXZhbGVudOKAnSwgZWl0aGVyIGFzIHBh
cnQgb2YgdGhlIG1haW4gZG9jdW1lbnQsIG9yIGFzIGFuIGluZGVwZW5kZW50IGRvY3VtZW50LiBj
dXJyZW50bHksIHRoYXQgaXMgbm90IHRoZSBjYXNlLg0KDQpBIG1pbmltYSwgbG9va2luZyBhdCBC
Q1A3MiBhbmQgQkNQMTA3IOKAlCB0YWtpbmcgaW5zcGlyYXRpb24gZnJvbSBSRkM3MTgzIG1pZ2h0
IGJlIGF3IGdvb2QgaWRlYSwgYXMgdGhhdCB3YXMgdGhlIG1vc3QgcmVjZW50IHRoYXQgd2VudCB0
aHJvdWdoIHRoZSBTRUMgQUQuIFJlZ2FyZGxlc3Mgb2YgaG93LCBob3dldmVyLCBhIOKAnG1hbmRh
dG9yeSB0byBpbXBsZW1lbnTigJ0gc2VjdXJpdHkgbWVjaGFuaXNtIG1vc3QgYmUgc3BlY2lmaWVk
IChJIHRoaW5rIHRoZSByaWdodCB0ZXJtIHdhcyDigJxNVVNUIGltcGxlbWVudCwgU0hPVUxEIHVz
ZeKAnSksIGluIHN1ZmZpY2llbnQgZGV0YWlsIHRvIGVuc3VyZSBpbnRlcm9wZXJhYmxlIGltcGxl
bWVudGF0aW9ucy4NCg0KQXMgYW4gZXhhbXBsZSwgYm90aCBbUkZDNjEzMF0gYW5kIFtSRkM3MTgx
XSBzZXQgb3V0IHRoYXQgdGhhdDoNCg0KICAgICAgT24gcmVjZWl2aW5nIGEgLi4uIG1lc3NhZ2Us
IGEgcm91dGVyIE1VU1QgZmlyc3QgY2hlY2sgaWYgdGhlDQogICAgICBtZXNzYWdlIGlzIGludmFs
aWQgZm9yIHByb2Nlc3NpbmcgYnkgdGhpcyByb3V0ZXINCg0KYW5kIHRoZW4gcHJvY2VlZCB0byBn
aXZlIGEgbnVtYmVyIG9mIGNvbmRpdGlvbnMgdGhhdCwgZWFjaCwgd2lsbCBsZWFkIHRvIGEgcmVq
ZWN0aW9uIG9mIHRoZSBtZXNzYWdlIGFzICJiYWRseSBmb3JtZWQgYW5kIHRoZXJlZm9yZSBpbnZh
bGlkIGZvciBwcm9jZXNzaW5n4oCdIOKAlCBhIGxpc3Qgd2hpY2ggUkZDNzE4MyB0aGVuIGFtZW5k
ZWQuIFRoYXQgZ2F2ZSBhIOKAnGhvb2vigJ0gZm9yIFJGQzcxODMgZm9yIGluc2VydGluZyDigJxy
ZWplY3Rpb27igJ0uIElkZW0gZm9yIG1lc3NhZ2UgZ2VuZXJhdGlvbi4NCg0KSWYgSSB3YXMgdG8g
ZG8gUkZDNzE4MS9SRkM2MTMwIHRvZGF5LCBJIHdvdWxkIGluY2x1ZGUgdGhhdCBkaXJlY3RseSBp
bnRvIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucy4gSXQgdHVybmVkIG91dCB0byBiZSBtb3Jl
IG92ZXJoZWFkIChhbmQgc2xvdyBkb3duIHB1YmxpY2F0aW9uIGFueXdheXMpIHRvIGRvIGl0IGFz
IHNlcGFyYXRlIGRvY3VtZW50cy4NCg0KU2Vjb25kbHksIHdlIG5lZWQgdG8gYmUgYSBsb3QgbW9y
ZSByaWdpZCBpbiB0ZXJtcyBvZiB3aGF0IElDVnMsIFRpbWVzdGFtcHMsIGV0Yy4gYXJlIGFkZGVk
L3JlbW92ZWQsIGFuZCB3aGF0IHRoYXQgYnJpbmdzLg0KDQpGb3IgZXhhbXBsZSAod2l0aCB0aGUg
YXNzdW1wdGlvbiB0aGF0IG1lc3NhZ2VzIGFyZSAqZm9yd2FyZGVkKiBhbmQgKm5vdCogcmVnZW5l
cmF0ZWQpLCB0aGlzIGNvdWxkIGJlIG9uZSBvcHRpb246DQoNCiAgICAgICAgICAgICAgICAgICAg
ICAgIG8gICAgICAgICAgV2hlbiBhIFJSRVEsIFJSRVAgbWVzc2FnZSBpcyBnZW5lcmF0ZWQsIGFk
ZCBhbiBJQ1YgTWVzc2FnZSBUTFYsIHdoaWNoIGlzIGNhbGN1bGF0ZWQgPHRoaXMgd2F5Pg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIOKApih0YWtlIGluc3BpcmF0aW9uIGZy
b20gUkZDNzE4MyBoZXJlKQ0KDQouLi4NCg0KW01lc3NhZ2UgY2xpcHBlZF0NCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QN
Cm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8
bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9tYW5ldA0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqDQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVu
dHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCBhbmQgbWF5IGFs
c28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGllbnQg
cGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4N
CllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlz
Y2xvc2Ugb3INCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uDQoq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0
Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCg0K

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1556GLKXM0002VGREEN_
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
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFz
c3VtaW5nIGZvciB0aGUgbW9tZW50IHRoYXQgZXZlcnlvbmUgd2lsbCBuZWVkIGFuIFJSRVAtQWNr
IG9yIHdvbuKAmXQgKGxldOKAmXMgY29tZSBiYWNrIHRvIHRoYXQpIHdoeSBkbyBDIGFuZCBCIG5l
ZWQgdG8gcHV0IGFuIGFkZHJlc3MgaW4gYXMgYW4gUlJFUS1BY2sgcmVxdWVzdD8NCiBXaHkgbm90
IGEgZmxhZywgYmVjYXVzZSB0aGUgYWRkcmVzcyB3aWxsIGJlIGluY2x1ZGVkIGFzIHRoZSBJUCBz
ZW5kaW5nIGFkZHJlc3MgLSBhbmQgd2Uga25vdyA1NDQ0IGlzIHJlcXVpcmVkIHRvIHBhc3MgdGhh
dCBvbi4gKEl04oCZcyB1c2VkIGJ5IE5IRFAgYXMgd2VsbC4pIFRoZW4gd2UgZG9u4oCZdCBuZWVk
IHRvIGNoYW5nZSB0aGUgUlJFUCwgaXQgd2lsbCBoYXZlIGEgZmxhZyBzZXQgb3Igbm90LCBhbmQg
d29u4oCZdCBjaGFuZ2UgKGluIHRoaXMgcmVnYXJkKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vdyBsZXTigJlzIGNv
bnNpZGVyIGRvIHdlIGtub3cgd2hldGhlciB3ZSBjYW4gc2V0IGEgZml4ZWQgZmxhZy4gRmlyc3Qg
SeKAmWQgc2F5IHRoZXJlIGFyZSB0d28gY2FzZXMgLSB5b3XigJl2ZSBnb3QgYSBmaXJtIGNvbnRy
b2wgb24gd2hhdOKAmXMgZ29pbmcgb24gaW4geW91ciBuZXR3b3JrLA0KIG9yIGl04oCZcyBvbmUg
b2YgdW5rbm93biBwYXJ0aWVzIGFuZCBiZWhhdmlvdXIgKGNvbnNpc3RlbnQgd2l0aCBzcGVjaWZp
Y2F0aW9uKS4gSW4gdGhlIGZvcm1lciBjYXNlIHlvdSBvbmx5IHdhbnQgb25lIHNldHRpbmcsIGZv
ciBleGFtcGxlIG5vLUFjayBpZiBydW5uaW5nIE5IRFAgb3IgeW91ciBNQUMgbGF5ZXIgdGVsbHMg
eW91IGFib3V0IGJpZGlyZWN0aW9uYWxpdHksIEFjayBvdGhlcndpc2UuIEluIHRoZSBsYXR0ZXIg
Y2FzZSwgSSB0aGluayB5b3UNCiBqdXN0IGFsd2F5cyB3YW50IGFuIEFjay4gU28gYm90aCBjYXNl
cyBnZXQgeW91IHRvIHRoZSBzYW1lIHBsYWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2hvdWxkIHRoYXQgbm90IGJl
IGFuIGFjY2VwdGFibGUgYXJndW1lbnQgKHRob3VnaCBJIHRoaW5rIGl04oCZcyBnb29kIGZvciB3
aGVyZSB3ZSBhcmUgLSBpbiBmYWN0IGFsd2F5cyBBY2sgaXMgY2xvc2UpIHRoZW4gYXQgZmxhZyBp
cyBhIHN0ZXAgYmV0dGVyLCBpdOKAmXMgYSBmaXhlZA0KIGxvY2F0aW9uIHRvIGNoYW5nZS4gSG93
ZXZlciBpdCB3b3VsZCBiZSBiZXR0ZXIgaW4gdGhhdCBjYXNlIGlmIHRoZSB0d28gdGhpbmdzIHRv
IGNoYW5nZSAobWV0cmljIGFuZCBhY2sgZmxhZykgd2VyZSB0b2dldGhlci4gQnV0IHRoYXQgaGFz
IGl0cyBvd24gaXNzdWVzLCBzbyBJIHdvbuKAmXQgZ28gdGhlcmUuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxi
cj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIElu
dGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOyYjNDM7NDQgKDAp
MTI0NSAyNDIxOTQgJm5ic3A7fCAmbmJzcDs8Yj5FOg0KPC9iPjxhIGhyZWY9Im1haWx0bzpjaHJp
cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208
L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48
YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBT
eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywg
R3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0
dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53
d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4Qjky
Ij5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJl
ZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBT
dXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij4gVmljdG9yaWEgTWVyY2llY2EgW21haWx0bzp2bWVyY2llY2EwQGdtYWlsLmNvbV0NCjxicj4N
CjxiPlNlbnQ6PC9iPiAyNSBBcHJpbCAyMDE2IDE0OjE1PGJyPg0KPGI+VG86PC9iPiBKaWF6aSBZ
STxicj4NCjxiPkNjOjwvYj4gRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk7IENocmlzdG9waGVy
IERlYXJsb3ZlOyBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdDxicj4NCjxiPlN1
YmplY3Q6PC9iPiBSZTogW21hbmV0XSBNZXNzYWdlIGludGVncml0eSBhbmQgbWVzc2FnZSBtdXRh
YmlsaXR5ICh3YXMgUkU6IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEgY291
cGxlIG9mIGJpZyB0aWNrZXQgSXRlbXMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29s
aWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFj
a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls
ZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8bzpwPjwvbzpwPjwvc3Bh
bj48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl
bnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tn
cm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3
MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24s
IGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48
L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVt
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9u
IGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJy
Pg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+
PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVk
Ij5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5
b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3Rl
bXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFn
cy5wZGYiPg0KaGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFp
bCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBocmVmPSJodHRwOi8vaW50cmFuZXQu
ZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50
cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIj4NCnRoaXMgcHJvY2Vz
czwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMzMzM5NzIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBK
aWF6aSw8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5PbiBNb24sIEFwciAyNSwgMjAxNiBhdCAxOjA0IFBNLCBKaWF6aSBZSSAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmlldGZAamlheml5aS5jb20iIHRhcmdldD0iX2JsYW5rIj5pZXRmQGppYXppeWku
Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SGksJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g
TW9uLCBBcHIgMjUsIDIwMTYgYXQgMTE6MjAgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp
ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdl
dD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaXRoIHJlZ2FyZCB0byB5b3Vy
IHZhbGlkaXR5IHRpbWUgcG9pbnQsIHdlIGhlcmUgaGF2ZSBhIHRyYWRlb2ZmLiBJZiB5b3UgYWxs
b3cgdGhhdCBmZWF0dXJlLCBpdCBzaWduaWZpY2FudGx5DQogaW1wYWN0cyBvbiB0aGUgYXBwcm9h
Y2ggdGhhdCB3YXMgY29taW5nIHRvZ2V0aGVyIG9uIGFzIGJlc3QgeW91IGNhbiBlbmQgdG8gZW5k
IGVuY3J5cHRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28gdGhlIHF1ZXN0aW9uIGlzLCBpcyB0aGlzIGEg
ZmVhdHVyZSB0aGF04oCZcyByZWFsbHkgd2FudGVkPyBVbmZvcnR1bmF0ZWx5IEkgdGhpbmsgd2Ug
a25vdyB0aGF0IHRoZQ0KIGFuc3dlciB0byB0aGF0IGlzLCB3ZSBkb27igJl0IGtub3cgYmVjYXVz
ZSB3ZSBkb27igJl0IGhhdmUgYW55IGV4cGVyaWVuY2UuIE15IHZpZXcgd291bGQgYmUgdGhhdCBp
biB0aGUgdHJhZGVvZmYgb2YgYW4gdW50ZXN0ZWQgZmVhdHVyZSAodW5sZXNzIEnigJltIHdyb25n
IGFib3V0IHRoYXQpIGFuZCB0aGUgc2VjdXJpdHkgY29tcGxpY2F0aW9uLCBzZWN1cml0eSB3aW5z
IGFuZCBkcm9wIHRoZSBmZWF0dXJlLiBJZiB0aGVyZSBpcyBzb21lIHJlYWwgcmVxdWlyZW1lbnQs
DQogdGhlbiB0aGVyZeKAmXMgYSBkaXNjdXNzaW9uLiAoUXVlc3Rpb25zIGxpa2UgaG93IG9mdGVu
IHRoZSBpbnRlcm1lZGlhdGUgcm91dGVycyBhY3R1YWxseSBoYXZlIGFueSBrbm93bGVkZ2UgLSB0
eXBpY2FsbHkgbGlua3MgYnJlYWsgZm9yIHVuZXhwZWN0ZWQgcmF0aGVyIHRoYW4gZXhwZWN0ZWQg
cmVhc29ucy4gQW5kYW4gaW50ZXJtZWRpYXRlIHJvdXRlciBjb3VsZCBwb3NzaWJseSB1c2UgYSB2
YWxpZGl0eSB0aW1lIHRvIGluZmx1ZW5jZSBpdHMgYmVoYXZpb3VyLikNCiBOb3RlIHRoYXQgZHJv
cHBpbmcgdGhlIGFiaWxpdHkgb2YgaW50ZXJtZWRpYXRlIHJvdXRlcnMgdG8gbW9kaWZ5L3NldCBz
dGlsbCBhbGxvd3MgdmFsaWRpdHkgdGltZXMgcGVyIHJvdXRlIHRvIGJlIHNldCBhdCBlbmRwb2lu
dHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgd2l0aCBDaHJpcycgY29uY2Vybi48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBWYWxpZGl0eVRpbWUg
aXMgb3B0aW9uYWwsIHdoaWNoIG1ha2VzIHRoZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBoYXJkLiBG
dXJ0aGVybW9yZSwgaXQgZ2l2ZXMgYSBwb3RlbnRpYWwgYXR0YWNrIHZlY3RvcjogYXMgYWxsIHRo
ZSByb3V0ZXJzIGluIGEgcGF0aCB3aWxsIHRha2UgdGhlIHNob3J0ZXN0IHZhbGlkaXR5VGltZSwg
YSBjb21wcm9taXNlZCByb3V0ZXIgY2FuIHNldCB0aGUgdGhlIHZhbGlkaXR5VGltZQ0KIHRvIGEg
dmVyeSBzaG9ydCB2YWx1ZSwgd2hpY2ggd2lsbCBtYWtlIHRoZSByb3V0ZSBpbnN0YWxsZWQgYWxv
bmcgdGhlIHBhdGggYmVjYW1lIGludmFsaWQgKHZlcnkgc29vbikuJm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIHRoZSBvdGhlciBo
YW5kLCBJJ20gbm90IHN1cmUgdGhpcyBvcHRpb24gd2lsbCBnaXZlIHVzIG11Y2ggaGVscC4gQ2hy
aXMgbWVudGlvbmVkIG11Y2gga25vd2xlZGdlIGludGVybWVkaWF0ZSByb3V0ZXIgd291bGQgaGF2
ZSB0byBkZWNpZGUgdGhpcyB2YWx1ZSAoYW5kIGhvdyBtdWNoIHNlbnNlIHRoZSB2YWx1ZSB3b3Vs
ZCBtYWtlKS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkFub3RoZXIgaXNzdWUgaXMsIGEgcm91dGUgdG8gYSBkZXN0aW5hdGlvbiBtaWdo
dCBiZSB1cGRhdGVkIGJ5IGRpZmZlcmVudCBzb3VyY2VzLiBGb3IgZXhhbXBsZSwgaW4gdGhlIG5l
dHdvcmsgYmVsb3c6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+QS0tLS1CLS0tLS1DPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGZpcnN0IGVzdGFibGlzaCBhIHJvdXRlIHRvIEIgd2l0aCBs
b25nIHZhbGlkaXR5IHRpbWUuIFRoZW4gQSBpbml0aWF0ZXMgYSByb3V0ZSBkaXNjb3ZlcnkgdG8g
Qy4gQyB0ZW5kcyB0byBzZXQgYSBzaG9ydCB2YWxpZGl0eSB0aW1lLCB3aGljaCB3aWxsIG1ha2Ug
dGhlIHJvdXRlIGJldHdlZW4gQiBhbmQgQSBleHBpcmUgZWFybGllciB0aGFuIGV4cGVjdGVkLiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SXMgdGhpcyBhIHByb2JsZW0/IE1heWJlIHllcywgbWF5YmUgbm8gLS0gSSdtIG5vdCBzdXJlIGl0
J3MgY29uc2lkZXJlZCBvciBub3QuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Ob3Qgc3VyZSBJIGZvbGxvdyBoZXJlLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0Ij5DdXJyZW50bHksIHRoZSB2YWxpZGl0eSB0aW1lIG9mIHRoZSByb3V0ZSBi
ZXR3ZWVuIEEgYW5kIEIgd291bGQgbm90IGFmZmVjdGVkIGJ5IGEgc2hvcnQgdmFsaWRpdHkgdGlt
ZSBvZiBhIHJvdXRlIGJldHdlZW4gQSBhbmQgQy4gVmFsaWRpdHkgdGltZXMgYXJlIHBlci1yb3V0
ZSwgYW5kIHRoZSByb3V0ZSBBLUIgYW5kIHRoZSByb3V0ZSBBLUMgYXJlIHNlcGFyYXRlLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2Ugc3dp
dGNoZWQgdG8gYSB2YWxpZGl0eSB0aW1lIHBlciBuZWlnaGJvciAoc28gdGhhdCB3ZSBjYW4ga2Vl
cCB2YWxpZGl0eSB0aW1lIHNlcGFyYXRlIGZyb20gcm91dGUgYWR2ZXJ0aXNlbWVudHMpIGFzIEkg
bWVudGlvbmVkIGluIHRoZSBlbWFpbCBiZWxvdywgdGhlbiB0aGUgdmFsaWRpdHkgb2YgYSByb3V0
ZSBiZXR3ZWVuIEEgYW5kIEMgd291bGQgYmUgYWZmZWN0ZWQgaWYgdGhlcmUgd2FzIGEgc2hvcnQN
CiB2YWxpZGl0eSB0aW1lIGJldHdlZW4gQSBhbmQgQi4gQnV0LCBpZiBCIHdpbGwgb25seSByb3V0
ZSBmb3IgYSBjZXJ0YWluIGFtb3VudCBvZiB0aW1lLCB0aGVuIHRoZSByb3V0ZSBiZXR3ZWVuIEEg
YW5kIEMgd2lsbCBvZiBjb3Vyc2UgYmUgYWZmZWN0ZWQuIElzIGl0IGJlc3QgdG8ga25vdyBpbiBh
ZHZhbmNlIHRoYXQgdGhlcmUncyBhIHRpbWUgbGltaXQsIG9yIGp1c3QgZGVhbCB3aXRoIFJFUlJz
IHdoZW4gdGhleSBoYXBwZW4/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu
LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw
dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo
dDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5XaXRoIHJlZ2FyZCB0byB0aGUgYWNrbm93bGVkZ2VtZW50cywgdGhlIHBy
b2JsZW0gKHdpdGggcmVnYXJkIHRvIHNlY3VyaXR5KSBjb21lcyBmcm9tIHRyeWluZyB0byBkbw0K
IHR3byBqb2JzIHdpdGggdGhlIHNhbWUgbWVzc2FnZSAtIGVuZCB0byBlbmQgcm91dGUgYWR2ZXJ0
aXNlbWVudCBhbmQgaG9wIGJ5IGhvcCBhY2tub3dsZWRnZW1lbnQuIEkgdW5kZXJzdGFuZCB0aGUg
cmVhc29ucyAtIHNhdmluZyBieXRlcyBhbmQgbWVzc2FnZSB0eXBlcy4gKEkgd291bGQgaGF2ZSB0
byBzdHVkeSB0aGUgcHJvdG9jb2wgcmVhbGx5IGhhcmQgdG8gaWRlbnRpZnkgaWYgYW55IG1lc3Nh
Z2UgdHlwZXMgY2FuIGJlIGZvbGRlZCB0b2dldGhlcg0KIGFuZCByZWNvZ25pc2VkIGJ5IGNvbnRl
bnQgcmF0aGVyIHRoYW4gdHlwZSBlZmZpY2llbnRseS4gVGhpcyBJIGRvIG5vdCBleHBlY3QgdG8g
ZG8uKSBBZ2FpbiBhIHRyYWRlb2ZmLiBUaGlzIG9uZSBpcyBpbiBkaXNjdXNzaW9uIHNwYWNlLCB0
aG91Z2ggdGhhdCBuZWVkcyBwZW9wbGUgd2hvIHVuZGVyc3RhbmQgYm90aCBzaWRlcyBvZiB0aGUg
aXNzdWUsIGluY2x1ZGluZyB0aGUgZGV0YWlscyBvZiB0aGUgYmlkaXJlY3Rpb25hbGl0eSBtZWNo
YW5pc20uDQogT2YgY291cnNlLCBhcyBoYXMgYmVlbiBzYWlkLCB3ZSBuZWVkIG9uZSBvZiB0aG9z
ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlbid0IGZpbmlzaGVkIG15IHJldmll
dyBvZiB0aGUgbGF0ZXN0IGRyYWZ0LCBhbmQgSSBkb24ndCBnZXQgdGhlIG5lY2Vzc2l0eSBvZiBB
Y2tSZXEgYW5kIHRoZSBjb3JyZXNwb25kaW5nIG11bHRpY2FzdCBSUkVQIHlldC4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHBvc3Np
YmxlLCB0aGlzICZxdW90O29wdGlvbmFsJnF1b3Q7IGZpZWxkIHNob3VsZCBiZSBhdm9pZGVkLiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv
dHRvbToxMi4wcHQiPjxicj4NClRvIGdpdmUgYW4gb3ZlcnZpZXcgb2YgQWNrUmVxIGFuZCBSUkVQ
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5TaW5jZSBBT0RWdjIgcmVxdWlyZXMgYmlkaXJlY3Rp
b25hbCBsaW5rcywgdGhpcyBpcyB0aGUgd2F5IHRvIGRldGVybWluZSBpZiBhIGxpbmsgaXMgYmlk
aXJlY3Rpb25hbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkEtLS0tQi0tLS1DPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48YnI+DQoxKSBBIHNlbmRzIFJSRVEsIEIgZm9yd2FyZHMgaXQsIEMgcmVj
ZWl2ZXMgdGhlIFJSRVEuIEIgYW5kIEMgYm90aCBpbnN0YWxsIGEgcm91dGUgdG8gT3JpZ0FkZHIg
YnV0IHRoZXkgZG9udCB5ZXQga25vdyBpZiBpdCdzIHZhbGlkIGJlY2F1c2UgdGhleSBkb250IGtu
b3cgaWYgdGhlIGxpbmsgdG8gdGhlaXIgbmV4dCBob3AgaXMgYXZhaWxhYmxlIGluIHRoZSByZXZl
cnNlIGRpcmVjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjIpIEMgY3JlYXRlcyB0aGUgUlJFUC4gU2luY2UgaXQgZG9lc250IGtub3cgaWYg
dGhlIGxpbmsgdG8gQiBpcyBiaWRpcmVjdGlvbmFsLCBpdCBpbmNsdWRlcyB0aGUgQWNrUmVxIChh
biBhZGRyZXNzIHRvIGluZGljYXRlIHRoYXQgaXQgZXhwZWN0cyB0byByZWNlaXZlIGEgUlJFUF9B
Y2sgZnJvbSBCKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjMpIEIgcmVjZWl2ZXMgdGhlIFJSRVAsIGluc3RhbGxzIGEgcm91dGUgdG8gVGFyZ0Fk
ZHIgYW5kIG1hcmtzIGl0IGFzIHZhbGlkLCBzaW5jZSBpdCBrbm93cyB0aGUgbGluayB0byBDIGlz
IGJpZGlyZWN0aW9uYWwsIGJlY2F1c2UgdGhlIFJSRVEgd2VudCBpbiBvbmUgZGlyZWN0aW9uIGFu
ZCB0aGUgUlJFUCBjYW1lIGluIHRoZSBvdGhlci4gQiBhbHNvIHNlbmRzIHRoZSBSUkVQX0FjayB0
byBDIGFuZCBmb3J3YXJkcw0KIHRoZSBSUkVQIHRvIEEgKGFuZCBtaWdodCBjaGFuZ2UgdGhlIG1l
c3NhZ2UgdG8gaW5kaWNhdGUgaXRzIG93biBBY2tSZXEgLSBpZSB0aGF0IGl0IHJlcXVpcmVzIGFu
IGFjayBmcm9tIEEpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+NCkgQyByZWNlaXZlcyB0aGUgUlJFUF9BY2sgZnJvbSBCLCBhbmQgdGhlcmVmb3Jl
IGtub3dzIHRoYXQgQiByZWNlaXZlZCB0aGUgUlJFUCwgdGhlcmVmb3JlIHRoZSBsaW5rIGlzIGJp
ZGlyZWN0aW9uYWwuIEMgY2FuIHRoZW4gbWFyayBpdHMgcm91dGUgdG8gT3JpZ0FkZHIgYXMgdmFs
aWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj41
KSBTaW1pbGFybHksIEEgcmVjZWl2ZXMgdGhlIFJSRVAsIGluc3RhbGxzIHRoZSByb3V0ZSB0byBU
YXJnQWRkciBhbmQgc2VuZHMgYW4gUlJFUF9BY2sgdG8gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjYpIEIgcmVjZWl2ZXMgdGhlIFJSRVBfQWNr
IGFuZCBtYXJrcyBpdHMgcm91dGUgdG8gT3JpZ0FkZHIgYXMgdmFsaWQuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjEyLjBwdCI+QWx0ZXJuYXRpdmVseSwgaW4gc3RlcCAyLCBpZiBDIGtub3dzIHRoZSBsaW5r
IHRvIEIgaXMgYmlkaXJlY3Rpb25hbCAocGVyaGFwcyBmcm9tIHNvbWUgZWFybGllciByb3V0ZSBk
aXNjb3ZlcnkpLCBpdCBkb2VzbnQgbmVlZCB0byBwdXQgdGhlIEFja1JlcSBpbiB0aGUgUlJFUC4g
VGhlbiBpbiBzdGVwIDMsIHNpbmNlIEIgZG9lc250IGtub3cgaWYgdGhlIGxpbmsNCiB0byBBIGlz
IGJpZGlyZWN0aW9uYWwsIGl0IGNoYW5nZXMgdGhlIG1lc3NhZ2UgdG8gYWRkIHRoZSBBY2tSZXEg
YWRkcmVzcywgaW4gb3JkZXIgdG8gZ2V0IGFuIFJSRVBfQWNrIGZyb20gQS48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjEyLjBwdCI+SWYgd2Ugd2FudCB0byBhdm9pZCBjaGFuZ2luZyB0aGUgbWVzc2FnZSwgd2Un
bGwgbmVlZCB0byBsb29rIGF0IGZvcndhcmRpbmcgdGhlIFJSRVAgYXMtaXMsIGFuZCBjcmVhdGlu
ZyBhIHNlY29uZCBtZXNzYWdlIHRvIHNvbGljaXQgYW4gUlJFUF9BY2ssIGluIG9yZGVyIHRvIHZl
cmlmeSB0aGF0IHRoZSBsaW5rIGlzIGJpZGlyZWN0aW9uYWwgYmVmb3JlIG1hcmtpbmcNCiB0aGUg
cm91dGUgdG8gT3JpZ0FkZHIgYXMgdmFsaWQuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2luZCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VmljdG9yaWEuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv
bToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6
MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVnYXJkczxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaWF6
aTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w
cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPC9zcGFuPjwvYj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmlu
Y2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJv
cmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOzxhIGhyZWY9InRlbDolMkI0NCUyMCUyODAl
MjkxMjQ1JTIwMjQyMTk0IiB0YXJnZXQ9Il9ibGFuayI+JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NDwv
YT4NCiAmbmJzcDt8ICZuYnNwOzxiPkU6IDwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxv
dmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0
ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw
MDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5
MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9n
eSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEg
aHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu
IHN0eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdl
bmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAx
MzM3NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBS
ZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G
cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g
VmljdG9yaWENCiBNZXJjaWVjYSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2bWVyY2llY2EwQGdt
YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZtZXJjaWVjYTBAZ21haWwuY29tPC9hPl0NCjxicj4N
CjxiPlNlbnQ6PC9iPiAyMyBBcHJpbCAyMDE2IDEwOjU1PGJyPg0KPGI+VG86PC9iPiBDaHJpc3Rv
cGhlciBEZWFybG92ZTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmlldGZAdGhvbWFz
Y2xhdXNlbi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZXRmQHRob21hc2NsYXVzZW4ub3JnPC9hPjsg
RGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk7IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGlu
ZyBsaXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gTWVzc2FnZSBpbnRlZ3Jp
dHkgYW5kIG1lc3NhZ2UgbXV0YWJpbGl0eSAod2FzIFJFOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2
Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKTxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBw
dDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlO2JhY2tn
cm91bmQtYXR0YWNobWVudDpzY3JvbGw7YmFja2dyb3VuZC1wb3NpdGlvbi14OjAlO2JhY2tncm91
bmQtcG9zaXRpb24teTowJSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtYXR0YWNobWVu
dDpzY3JvbGw7YmFja2dyb3VuZC1wb3NpdGlvbi14OjAlO2JhY2tncm91bmQtcG9zaXRpb24teTow
JSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJO
SU5HICoqKjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0
ZTtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6c2Nyb2xsO2JhY2tncm91bmQtcG9zaXRpb24teDowJTti
YWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCUiPg0KPGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9y
Z2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJu
ZXQuPGJyPg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBh
bnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljxicj4NCkZvciBpbmZvcm1h
dGlvbiByZWdhcmRpbmcgPC9zcGFuPjwvaT48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L2I+PGk+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFp
bHMNCiB5b3UgcmVjZWl2ZSwgY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVz
eXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIw
RmxhZ3MucGRmIiB0YXJnZXQ9Il9ibGFuayI+DQpoZXJlPC9hPi48YnI+DQpJZiB5b3UgZmVlbCB0
aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyA8YSBocmVmPSJodHRwOi8vaW50
cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0Rv
Y3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIiB0YXJnZXQ9
Il9ibGFuayI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgQ2hyaXMsPG86
cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlc2UgaGF2
ZSBib3RoIGJlZW4gaW4gdGhlIGRyYWZ0IGluIHNvbWUgZm9ybSBzaW5jZSBiZWZvcmUgSSBnb3Qg
aW52b2x2ZWQuLi4gYnV0IEknbGwgZG8gbXkgYmVzdCB0byBleHBsYWluLjxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gRm9yIFZhbGlkaXR5IFRpbWUs
IGl0cyBhIHdheSB0byBhZHZlcnRpc2UgdGhhdCB5b3Ugd291bGQgb25seSBzdXBwb3J0IHRoZSBy
b3V0ZSBjb250YWluZWQgaW4gdGhlIG1lc3NhZ2UgZm9yIGEgY2VydGFpbiBwZXJpb2Qgb2YgdGlt
ZS4gVGhlIG9yaWdpbmF0b3IgbWlnaHQgdXNlIHRoaXMsIGJ1dCB0aGUgZHJhZnQNCiB3YXMgd3Jp
dHRlbiB0byBhbGxvdyBhbnkgaW50ZXJtZWRpYXRlIG5vZGUgdG8gYmUgYWJsZSB0byBhZGQgaXQg
b3IgdXBkYXRlIGl0IHRvby4gVGhlIHJvdXRlIGNyZWF0ZWQgaW4gdGhlIExvY2FsIFJvdXRlIFNl
dCBoYXMgYW4gZXhwaXJhdGlvbiB0aW1lIGFzc29jaWF0ZWQgd2l0aCBpdCwgYmFzZWQgb24gdGhl
IHJlY2VpdmVkIHZhbGlkaXR5IHRpbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gRm9yIHRoZSBBY2tSZXEgYWRkcmVzcywgaXRzIHNvIHRo
YXQgeW91IGNhbiBhZGQgaW50byBhIFJSRVAgYSByZXF1ZXN0IGZvciBhbiBhY2tub3dsZWRnZW1l
bnQsIHNvIHRoYXQgeW91IGRvbid0IGhhdmUgdG8gaGF2ZSBhIGRpZmZlcmVudCBtZXNzYWdlIHR5
cGUgYWx0b2dldGhlciBmb3Igd29ya2luZyBvdXQNCiB3aGV0aGVyIGxpbmtzIHRvIG5laWdoYm9y
cyBhcmUgYmlkaXJlY3Rpb25hbCwgYW5kIGFsc28sIHNpbmNlIHlvdSBvbmx5IGNhcmUgYWJvdXQg
YmlkaXJlY3Rpb25hbGl0eSBvbiByb3V0ZXMgdGhhdCBhcmUgYmVpbmcgc2V0IHVwLCB5b3UgZG9u
dCBuZWVkIHRvIGNvbnN0YW50bHkgbW9uaXRvciBhbGwgbmVpZ2hib3JzLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIG9yZGVy
IHRvIGF2b2lkIHRoZSBwb3RlbnRpYWwgQWNrUmVxLXJlbGF0ZWQgY2hhbmdlcyB0byBlYWNoIG1l
c3NhZ2UsIG1heWJlIHdlIGRvIG5lZWQgdG8gaW50cm9kdWNlIGEgZGlmZmVyZW50IG1lc3NhZ2Ug
c3BlY2lmaWNhbGx5IGZvciB0aGlzLiBXZSBjb3VsZCBtYXliZSB1c2UgUlJFUF9BY2sgdG8gYm90
aA0KIHJlcXVlc3QgYW5kIGFja25vd2xlZGdlPyBJdCBtZWFucyBhbiBleHRyYSBtZXNzYWdlIG9m
IGNvbnRyb2wgdHJhZmZpYyB0aGF0IG5lZWRzIHRvIGJlIHNlbnQsIG1heWJlIG9uZSBleHRyYSBt
ZXNzYWdlIHBlciBob3Agb24gdGhlIHBhdGggb2YgYSBSUkVQLCBidXQgaXQgY291bGQgc3RpbGwg
YmUgbGltaXRlZCB0byBuZWlnaGJvcnMgd2hpY2ggaGF2ZSBwYXJ0aWNpcGF0ZWQgaW4gdGhlIHJv
dXRlIGRpc2NvdmVyeSByYXRoZXIgdGhhbiBtb25pdG9yaW5nDQogYWxsIG5laWdoYm9ycyBhdCBh
bGwgdGltZXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5UaGlzIG1lc3NhZ2UgY291bGQgbWF5YmUgYWxzbyBpbmNsdWRlICZx
dW90O0knbSBoYXBweSB0byByb3V0ZSBhbnl3aGVyZSBmb3IgYSBjZXJ0YWluIGFtb3VudCBvZiB0
aW1lJnF1b3Q7LCBzb3J0IG9mIGxpa2Ugd2lsbGluZ25lc3MgaW4gT0xTUi9PTFNSdjIuIFNvIGlu
c3RlYWQgb2YgaGF2aW5nIGEgdmFsaWRpdHkgdGltZSBwZXINCiByb3V0ZSwgaXRzIGEgdmFsaWRp
dHkgdGltZSBwZXIgbmVpZ2hib3IuIFRoZW4sIGZvciBSUkVRIGFuZCBSUkVQLCBvbmx5IHRoZSBt
ZXRyaWMgdmFsdWUgd291bGQgY2hhbmdlIGluIHRyYW5zaXQsIGFzIGRpc2N1c3NlZC4gSG93ZXZl
ciwgdGhhdCBsZWFkcyB0byBzb21lIGlzc3VlcyB3aXRoIGRlY2lkaW5nIHdoYXQgYSByb3V0ZSdz
IGV4cGlyYXRpb24gdGltZSBpcy4gWW91IG1pZ2h0IGtub3cgaG93IGxvbmcgdGhlIG5leHQgaG9w
IHJvdXRlciBpcw0KIHZhbGlkIGZvciwgYnV0IHdoYXQgaWYgYSByb3V0ZXIgYmV5b25kIHRoYXQs
IHdoaWNoIHdhcyBhbHNvIHBhcnQgb2YgdGhlIHJvdXRlLCBoYWQgYSBsb3dlciB2YWxpZGl0eSB0
aW1lPyBZb3UgY291bGRuJ3QgZGV0ZXJtaW5lIHRoZSByZWFsIHZhbGlkaXR5IHRpbWUuIERvIHdl
IHJlbW92ZSB0aGUgcm91dGUgZXhwaXJhdGlvbiB0aW1lIGFsdG9nZXRoZXIgdG8gYXZvaWQgdGhp
cyBpc3N1ZT8gSW4gd2hpY2ggY2FzZSwgd2Ugd291bGQgaGF2ZSB0bw0KIHJlbHkgb24gUkVSUiBt
ZXNzYWdlcyBiZWluZyBzZW50IGZvciByb3V0ZXMgd2hpY2ggYmVjb21lIGludmFsaWQgd2hlbiB0
aGUgbmVpZ2hib3IncyB2YWxpZGl0eSB0aW1lIGhhcyBleHBpcmVkPyBTbyBuZWlnaGJvciB2YWxp
ZGl0eSB0aW1lIGV4cGlyYXRpb24gaXMgdHJlYXRlZCB0aGUgc2FtZSBhcyBhIGxpbmsgYnJlYWsu
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5XaGF0IGRvIHlvdSB0aGluaz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPktpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VmljdG9yaWEuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+T24gU2F0LCBBcHIgMjMsIDIwMTYgYXQgMTowOSBBTSwgQ2hyaXN0b3BoZXIgRGVhcmxv
dmUgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWsiIHRhcmdl
dD0iX2JsYW5rIj5jaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWs8L2E+Jmd0OyB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QcmV0dHkg
bXVjaCBhbGwgb2YgdGhlIGRpc2N1c3Npb24gaGFzIGJlZW4gYXNzdW1pbmcgb25seSBhIG1ldHJp
YyB2YWx1ZSBjaGFuZ2UuIFdpdGggbXVsdGlwbGUgdGhpbmdzIGNoYW5naW5nIG1hbnkgb2YgdGhl
IGlkZWFzIGdvIG91dCBvZiB0aGUgd2luZG93LiBUaGF0IHJlaW5mb3JjZXMgdGhlIHBvaW50IGFi
b3V0DQogbm90IG1ha2luZyBzcGVjaWZpY2F0aW9ucyBub3cgdGhhdCBtaWdodCB0dXJuIG91dCB0
byBiZSB3cm9uZyBmb3IgSUNWcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPklnbm9yaW5nIGhvdyB0aGlzIG1pc3VuZGVyc3RhbmRpbmcg
aGFwcGVuZWQsIEknbGwgc3RhcnQgYnkgYXNraW5nIHdoeS4gTWV0cmljIGNoYW5naW5nIEkgdW5k
ZXJzdGFuZC4gV2h5IHRoZSBvdGhlciB0d28/ICh0aGVyZSdzIGEgcGFydGlhbCBleHBsYW5hdGlv
biBvZiBvbmUpLiBXaGF0IGFsdGVybmF0aXZlcw0KIGhhdmUgcGVvcGxlIGltcGxlbWVudGVkIGlu
IGNvbXBhcmFibGUgcHJvdG9jb2xzPzxicj4NCjxicj4NCi0tICZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJl
Zj0ibWFpbHRvOmNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
PmNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNvbTwvYT4gKGlQaG9uZSk8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0ibWFpbHRv
OmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51ayIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzQG1uZW1v
c3luZS5kZW1vbi5jby51azwvYT4gKGhvbWUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gMjMgQXByIDIwMTYsIGF0IDAwOjI2
LCBWaWN0b3JpYSBNZXJjaWVjYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZtZXJjaWVjYTBAZ21haWwu
Y29tIiB0YXJnZXQ9Il9ibGFuayI+dm1lcmNpZWNhMEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q29udGludWVkIGluIHRoaXMgdGhy
ZWFkIGJlY2F1c2UgdGhlIG90aGVyIG9uZSBzZWVtcyB0byBiZSBtb3JlIGFib3V0IFRMViB0eXBl
cyBhbmQgbWV0cmljIHR5cGUgbnVtYmVycywgd2hlcmVhcyB0aGlzIGlzIGFib3V0IHJlZ2VuZXJh
dGlvbi9mb3J3YXJkaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+VG8gcmVjYXAsIGluIHRoZSBjdXJyZW50IGRyYWZ0LCB0aGVyZSBh
cmUgMyB0aGluZ3MgdGhhdCBtaWdodCBjaGFuZ2UgYXQgZWFjaCBob3A6DQo8YnI+DQotIHRoZSBt
ZXRyaWMgdmFsdWUgKGhhcHBlbnMgaW4gUlJFUSBhbmQgUlJFUCksIDxicj4NCi0gYWRkaW5nL2No
YW5naW5nIFZhbGlkaXR5IFRpbWUgdXNpbmcgdGhlIFZhbGlkaXR5IFRpbWUgVExWIChjYW4gaGFw
cGVuIGluIFJSRVEgYW5kIFJSRVApLA0KPGJyPg0KLSBhZGRpbmcgYW4gYWRkcmVzcyAoYW5kIGNv
cnJlc3BvbmRpbmcgdmFsdWUgaW4gdGhlIEFkZHJlc3NUeXBlIFRMViB0byBpbmRpY2F0ZSBob3cg
dG8gaW50ZXJwcmV0IHRoZSBhZGRyZXNzKSB0byBpbmRpY2F0ZSB0aGUgYWRkcmVzcyBmcm9tIHdo
aWNoIGFuIFJSRVBfQWNrIGlzIGV4cGVjdGVkLCB0byBhY2NvbXBsaXNoIHRoZSBiaWRpcmVjdGlv
bmFsaXR5IGNoZWNrIChjYW4gaGFwcGVuIGluIFJSRVApLjxicj4NCjxicj4NCklmIHdlIGRlZmlu
ZSZuYnNwO2EgY2VydGFpbiBwb3J0aW9uIG9mIHRoZSBtZXNzYWdlIGFzIGltbXV0YWJsZSBhbmQg
aW5jbHVkZSB0aGUgSUNWIHRvIHZlcmlmeSB0aGF0IHBhcnQsIGVuZCB0byBlbmQ6DQo8YnI+DQot
IFRoZSBtZXRyaWMgdmFsdWUgd291bGQgYmUgZXhjbHVkZWQgZnJvbSB0aGUgSUNWIHNpbmNlIGl0
IG5lZWRzIGNoYW5naW5nIGF0IGVhY2ggaG9wLiZuYnNwOzxicj4NCi0gV291bGQgYWRkaW5nIGEg
VmFsaWRpdHkgVGltZSBUTFYgYXQgYW4gaW50ZXJtZWRpYXRlIGhvcCBiZSBhY2NlcHRhYmxlPyBU
aGUgd2hvbGUgVExWIGNvdWxkIGJlIHJlbW92ZWQgaW4gb3JkZXIgdG8gY2FsY3VsYXRlIHRoZSBJ
Q1Y/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBXb3Vs
ZCBhZGRpbmcgYW4gYWRkcmVzcyBjYXVzZSBpc3N1ZXMgZm9yIHRoZSBJQ1YsIGJlY2F1c2UgaXQn
cyBpbiB0aGUgYWRkcmVzcyBibG9jaz8gQ291bGQgdGhlIHJ1bGUgYmUgJnF1b3Q7aWYgaXQgY29u
dGFpbnMgYW4gQWNrUmVxIGFkZHJlc3MsIHJlbW92ZSBpdCAoYW5kIHRoZSBjb3JyZXNwb25kaW5n
IHZhbHVlDQogaW4gdGhlIEFkZHJlc3NUeXBlIFRMViksIGJlZm9yZSBjaGVja2luZyB0aGUgSUNW
JnF1b3Q7LCBpcyB0aGF0IE9LPyBPciB3b3VsZCB3ZSBuZWVkIHRvIGF2b2lkIHRvdWNoaW5nIHRo
ZSBJQ1YnZWQgcGFydCBvZiB0aGUgbWVzc2FnZSBhbHRvZ2V0aGVyLCBtYXliZSBwdXQgdGhlIEFj
a1JlcSBhZGRyZXNzIGluIGEgc2VwYXJhdGUgQWRkcmVzcyBCbG9jaywgd2l0aCBhbiBleHRyYSBB
ZGRyZXNzVHlwZSBUTFYgZm9sbG93aW5nIHRoYXQgYWRkcmVzcyBibG9jaz8NCiBJcyB0aGVyZSBh
IHdheSB0byBhY2NvbXBsaXNoIHRoaXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbHNvLCB0byBiZSB0aG9yb3VnaCwgZG8gd2UgbmVl
ZCB0byBjb25zaWRlciBSRVJSIG1lc3NhZ2VzIHdoaWxlIHdlIGRpc2N1c3MgcmVnZW5lcmF0aW9u
IHZzIGZvcndhcmRpbmc/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPi0gUkVSUiAoc2VudCB3aGVuIGEgbGluayBicmVha3MpIGlzIGEg
d2F5IG9mIHNheWluZyAmcXVvdDtJJ3ZlIGxvc3QgbXkgcm91dGUgc28gSSdtIHRlbGxpbmcgb3Ro
ZXJzJnF1b3Q7IGFuZCAmcXVvdDt5b3Ugd2VyZSBteSBuZXh0IGhvcCwgc28mbmJzcDtub3cmbmJz
cDtJJ3ZlIGFsc28gbG9zdCBteSByb3V0ZSwgSSdsbCB0ZWxsIG90aGVycyZxdW90OywgZXRjLg0K
IEl0J3MgZ29pbmcgdG8gYmUgdGFpbG9yZWQgYXQgZWFjaCBzdGVwIHRvIGluY2x1ZGUgdGhlIHJl
bGV2YW50IHJvdXRlcyB0aGF0IGdvdCBkZWxldGVkLCBpdCdzIG5vdCBvbmUgbWVzc2FnZSBiZWlu
ZyBzZW50IGVuZC10by1lbmQgbGlrZSBSUkVRIGFuZCBSUkVQIGFyZS4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBIb3dldmVyLCBS
RVJSIChzZW50IHdoZW4gYSBzb3VyY2Ugb2YgdHJhZmZpYyBpcyBzZW5kaW5nIGRhdGEgb24gYSBy
b3V0ZSB3aGljaCBjb21lcyB0aHJvdWdoIHlvdSwgYW5kIHlvdSB3YW50IHRvIHRlbGwgdGhlIFBh
Y2tldCBTb3VyY2UncyByb3V0ZXIgdG8gZGVsZXRlIHRoZSByb3V0ZSkgY291bGQgYmUNCiBzZWVu
IGFzIGFuIGVuZC10by1lbmQgbWVzc2FnZSB3aGljaCBhbGwgaW50ZXJtZWRpYXRlIHJvdXRlcnMg
bGVhcm4gZnJvbSwgc2ltaWxhciB0byBSUkVRIGFuZCBSUkVQLiBJdCByZXBvcnRzIG9uZSByb3V0
ZSwgYW5kIGRvZXNuJ3QgbmVlZCBjaGFuZ2luZyBhdCBpbnRlcm1lZGlhdGUgaG9wcywgc28gY291
bGQgYmUgcHJvdGVjdGVkIHdpdGggSUNWLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIFdvdWxkIGl0IGJlIE9LIHRvIG9ubHkgcmVxdWlyZSBh
IG1lc3NhZ2UgSUNWIGlmIGEgUGt0U291cmNlIGFkZHJlc3Mgd2FzIGluY2x1ZGVkLCBpLmUuIHdo
ZW4gdGhlIG1lc3NhZ2UgbmVlZHMgdG8gZ28gdmlhIGEgbnVtYmVyIG9mIGludGVybWVkaWF0ZSBo
b3BzIHRvIFBrdFNvdXJjZSdzIHJvdXRlcj8gQWxsDQogb3RoZXIgUkVSUnMgYXJlIGludGVuZGVk
IHRvIGJlIG9uZS1ob3AgbWVzc2FnZXMsIHdoaWNoIG1heSBpbiB0dXJuIHByb21wdCBvdGhlciBv
bmUtaG9wIG1lc3NhZ2VzLCBldGMuLi4sIGFuZCBhIHBhY2tldCBJQ1YgbWlnaHQgYmUgbW9yZSBh
cHByb3ByaWF0ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+S2luZCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPlZpY3RvcmlhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPk9uIFRodSwgTWFyIDE3LCAyMDE2IGF0IDU6MjYgUE0sICZsdDs8YSBocmVm
PSJtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAdGhv
bWFzY2xhdXNlbi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gMTcgTWFyIDIwMTYsIGF0IDE4OjE3LCBEZWFybG92
ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh
ZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j
b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPlllcywgSSBtZWFudCBBT0RWdjIsIHRoYW5rcyBmb3IgdGhlIGNhdGNoLjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIGlzIHlvdXIgKFRob21hcykgcHJv
cG9zZWQgYmFzZSBzcGVjaWZpY2F0aW9uIGEgaG9wIGNvdW50IG9ubHkgbWV0cmljPzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vLCB0aGUgd291bGQgYmUgc2lsbHkgYXMgYmFzZSBz
cGVjaWZpY2F0aW9uLCBnaXZlbiB0aGF0IGhvcCBjb3VudCBtb3N0bHkgaXMgdXNlbGVzcy48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFz
IGJhc2Ugc3BlY2lmaWNhdGlvbiBJIHdvdWxkIHNpbXBseSBzYXkg4oCcSW5jbHVkZSBhIE1ldHJp
YyBUeXBlIE1lc3NhZ2UgVExWIHdpdGggYSB2YWx1ZSBmaWVsZCwgYW5kIGEgNzE4MiBNZXNzYWdl
IFRMViAmYW1wOyBUaW1lc3RhbXDigJ0gYXMgd2UgZG8gaW4gT0xTUnYyICh3aXRoIHRoZSBhcHBy
b3ByaWF0ZSB2ZXJiaWFnZQ0KIGFzIHRvIGdlbmVyYXRpb24gYW5kIHByb2Nlc3NpbmcpLiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+V2l0aCB0aGUgbWVzc2FnZSBnZW5lcmF0ZWQgYnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIFJS
RVEvUlJFUCBhbmQgKm5vdCogZGVjb25zdHJ1Y3RlZC9yZWNvbnN0cnVjdGVkL3Jlb3JkZXJlZCAo
YXMgaXMgdGhlIHJpc2sgd2l0aCDigJxyZWdlbmVyYXRpb24pIGFsbG93cyBrbm93aW5nIHRoYXQg
aXQgd291bGQgYmUNCiAqb25seSogdGhhdCBtZXRyaWMgZmllbGQgYmVpbmcgbW9kaWZpZWQgKG90
aGVyIHRoYW4gaG9wIGNvdW50L2xpbWl0KSBmb3Igd2hlbiBldmVudHVhbGx5IHdyaXRpbmcgdXAg
dGhlIGV4dGVuc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj4oQWN0dWFsbHkgZG9lc27igJl0IHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24g
b25seSBkZWZpbmUgaG9wIGNvdW50LCBvciBoYXMgdGhhdCBjaGFuZ2VkIGluIGxhdGVzdA0KIGRy
YWZ0Pyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm8uIFRoYXQgaXMgb25lIG9mIHRoZSBpc3N1
ZXMgSSByYWlzZSBpbiBteSBvcmlnaW5hbC4gRm9yIHNvbWUgcmVhc29uLCBpdCBjaXRlcyBSRkM2
NTUxLCB3aGljaCBpcyBhIFJPTEwgZG9jdW1lbnQgYW5kIHdoaWNoIGhhcyBpbiBpdHMgYWJzdHJh
Y3QgdGhhdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPiZuYnNwOyZu
YnNwOyBMb3ctUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzIChMTE5zKSBoYXZlIHVuaXF1ZSBjaGFy
YWN0ZXJpc3RpY3M8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY29tcGFyZWQg
d2l0aCB0cmFkaXRpb25hbCB3aXJlZCBhbmQgYWQgaG9jIG5ldHdvcmtzIHRoYXQgcmVxdWlyZSB0
aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlvbiBvZiBu
ZXcgcm91dGluZyBtZXRyaWNzIGFuZCBjb25zdHJhaW50cy4gPG86cD48L286cD48L3ByZT4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JLmUuIHRoaXMgZG9jdW1lbnQgY2l0ZXMg
YSBtZXRyaWMgZG9jdW1lbnQgd2hpY2ggY2xlYXJseSBjbGFpbXMgdG8gYmUgaW5hcHBsaWNhYmxl
IGluIGFkIGhvYyBuZXR3b3Jrcy4gSSBub3RlIHRoYXQgdGhpcyBpcyBhbm90aGVyIHRoaW5nIEni
gJl2ZSByYWlzZWQgZm9yIHllYXJzIHdpdGhvdXQgc2VlaW5nIGl0DQogYXR0ZW1wdGVkIHJlc29s
dmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPlRob21hczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzAwN0U3RSI+LS08L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVy
IERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1z
IEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi
cj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxi
cj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7
PGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQiIHRhcmdldD0iX2JsYW5r
Ij4mIzQzOzQ0ICgwKTEyNDUgMjQyMTk0PC9hPg0KICZuYnNwO3wgJm5ic3A7PGI+RTombmJzcDs8
L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9
Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lz
dGVtcy5jb208L3NwYW4+PC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBU
ZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48
YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIiB0YXJnZXQ9Il9ibGFu
ayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bh
bj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFw
cGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFt
cDsgV2FsZXMgTm86IDAxMzM3NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv
dHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdp
c3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBH
VTIgN1lQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQg
MGNtIDBjbSAwY207Ym9yZGVyLWNvbG9yOi1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4
dC1jb2xvciI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxhIGhyZWY9Im1haWx0bzppZXRmQHRo
b21hc2NsYXVzZW4ub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs
ZSI+aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzwvc3Bhbj48L2E+Jm5ic3A7WzxhIGhyZWY9Im1haWx0
bzppZXRmQHRob21hc2NsYXVzZW4ub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv
bG9yOnB1cnBsZSI+bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmc8L3NwYW4+PC9hPl0mbmJz
cDs8YnI+DQo8Yj5TZW50OjwvYj4mbmJzcDsxNyBNYXJjaCAyMDE2IDE3OjEwPGJyPg0KPGI+VG86
PC9iPiZuYnNwO0RlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspPGJyPg0KPGI+Q2M6PC9iPiZuYnNw
O0xvdHRlIFN0ZWVuYnJpbms7IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0PGJy
Pg0KPGI+U3ViamVjdDo8L2I+Jm5ic3A7UmU6IFttYW5ldF0gTWVzc2FnZSBpbnRlZ3JpdHkgYW5k
IG1lc3NhZ2UgbXV0YWJpbGl0eSAod2FzIFJFOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyBy
ZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKTwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQg
YmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3
aGl0ZTtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6c2Nyb2xsO2JhY2tncm91bmQtcG9zaXRpb24teDow
JTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6
c2Nyb2xsO2JhY2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCUi
Pg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklO
RyAqKio8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGU7
YmFja2dyb3VuZC1hdHRhY2htZW50OnNjcm9sbDtiYWNrZ3JvdW5kLXBvc2l0aW9uLXg6MCU7YmFj
a2dyb3VuZC1wb3NpdGlvbi15OjAlIj4NCjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdh
bmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0
Ljxicj4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55
IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48YnI+DQpGb3IgaW5mb3JtYXRp
b24gcmVnYXJkaW5nJm5ic3A7PC9zcGFuPjwvaT48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L2I+PGk+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4mbmJzcDt0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9y
IGluIGVtYWlscw0KIHlvdSByZWNlaXZlLCBjbGljayZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9pbnRy
YW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9j
dW1lbnRzL1JlZCUyMEZsYWdzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPmhlcmU8L3NwYW4+PC9hPi48YnI+DQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMg
c3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5l
bnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRz
L0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiIHRhcmdldD0iX2JsYW5r
Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50aGlzIHByb2Nlc3M8L3NwYW4+PC9hPi48L3Nw
YW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gMTcgTWFyIDIwMTYsIGF0IDE4OjA0
LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRl
YXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y
OnB1cnBsZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPiZndDsNCiB3
cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+T0ssIHNvIHdlIGhhdmUgYSBtZXNzYWdlIHRoYXQgbXV0YXRlcyBieTo8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj4tIE1vZGlmeWluZyBob3AgY291bnQvbGltaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LSBNb2RpZnlpbmcgYSBtZXRy
aWMgdmFsdWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+QW55dGhpbmcgZWxzZT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBtdXRhdGlu
ZyAob3RoZXIgdGhhbiBob3AgY291bnQvbGltaXQpIG1lc3NhZ2VzIGFyZW7igJl0IGNvdmVyZWQg
YnkgNTQ0NCBvciBhbnkgZGVyaXZhdGl2ZSBkb2N1bWVudA0KIChidXQgb25seSByZWNvbW1lbmRl
ZCBhZ2FpbnN0LCBub3QgYmFubmVkKSB0aGF0IHlvdSBtYXkgbmVlZCB0byBtYWtlIHRoZSBtZXNz
YWdlIG90aGVyd2lzZSBpbW11dGFibGUgKG5vIGRlY29uc3RydWN0aW9uIGFuZCByZWJ1aWxkaW5n
LCBvdGhlciB0aGFuIGd1YXJhbnRlZWQgdW5jaGFuZ2luZykgdGhhdCB3b3VsZCBoYXZlIHRvIGJl
IHNwZWNpZmllZCBieSBBT0RWdjIuIChFYXN5IHRvIHNheSwgYnV0IG5lZWRzIHNheWluZy4pPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldpdGgg
eW91IHNvIGZhci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn
aW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+VGhlbiB0aGF0IGluZm9ybWF0aW9uIGlzIG5vdCBpbiBhIGd1YXJhbnRl
ZWQgZml4ZWQgbG9jYXRpb24gZ2l2ZW4gYnkgYSBzaW1wbGUgb2Zmc2V0LiBTbyBhbnkgc2lnbmF0
dXJlDQogYWxnb3JpdGhtIHRoYXQgZmluZHMgaXQgYW5kIGlnbm9yZXMgaXQgb3IgYWdncmVnYXRl
cyBvbiBpdCBpcyBzcGVjaWZpYyB0byBPTFNSdjIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5TdXJlbHkgeW91IG1lYW4gQU9EVnYyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIHN0YW5kYXJkIDcxODIgSUNWcyBkb27i
gJl0IGRvIHRoZSBqb2IsIHlvdSB3b3VsZCBuZWVkIGFuIEFPRFZ2MiBzcGVjaWFsaXNlZCB2YXJp
YW50LiBXaGljaCBpcyB0aGUNCiBzb3J0IG9mIHRoaW5nIHRoYXQgdGhlIG1lc3NhZ2Ugc3BlY2lm
aWMgVExWIHNwYWNlIGlzIHRoZXJlIGZvciwgSeKAmWQgYmUgc3Ryb25nbHkgYWdhaW5zdCBhIOKA
nGJ1dCBpZ25vcmUgdGhlIHZhbHVlIG9mIHRoaXMgc3BlY2lmaWMgVExWIHNob3VsZCBpdCBvY2N1
cuKAnSBiZWluZyBpbiB0aGUgZ2VuZXJhbCBzcGFjZS4gSG93ZXZlciBpdCBjYW4gZWFzaWx5IGJl
IGRlZmluZWQgYnkgcmVmZXJlbmNlIHRvIDcxODIgKOKAnHRoaXMgVExWIGlzIGxpa2UgdGhhdA0K
IFRMViwgZXhjZXB0IGlmIGFuIFggVExWIGlzIHByZXNlbnQsIHNldCBpdHMgdmFsdWUgZmllbGQg
dG8gemVyb+KAnSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWVzc3ksIGJ1dCBjb3VsZCB3b3JrLjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm90IHRoYXQgbWVzc3ksIGFjdHVhbGx5LCBhbHRo
b3VnaCBjbGVhcmx5IG5vdCBhcyBuaWNlIGFzIOKAnGZpeGVkIG9mZnNldOKAnS48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYXQgc2FpZCwgSSBhbSBhcmd1aW5nIGZvciB0aGUgYmFz
ZSBzcGVjIGJlaW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A74oCcbWFrZSB0aGUgbWVzc2FnZSBvdGhlcndpc2UgaW1tdXRhYmxlIChubyBkZWNvbnN0cnVj
dGlvbiBhbmQgcmVidWlsZGluZywgb3RoZXImbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7dGhhbiBndWFyYW50ZWVkIHVuY2hhbmdpbmcp4oCdIHdoaWNoIGlzIGFmZm9yZGVk
IGJ5IGZvcndhcmRpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtSRkM3MTgyIFRpbWVzdGFtcHMgYW5kIElDVnMu
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7UkZDNzE4MyBzdHlsZSB0ZXh0IGJyaW5naW5nIGl0IGFsbCB0b2dldGhl
ci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSDigJxhZ2dyZWdhdGVkIHNpZ25h
dHVyZXMgYXJvdW5kIG11dGFibGUgZmllbGTigJ0gd291bGQgdmVyeSBiZSBhbiBleHBlcmltZW50
YWwgZXh0ZW5zaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hhdCBJIG9iamVj
dCB0byBpcywgaWYgdGhlIGJhc2Ugc3BlYyBzcGVjaWZpY2FsbHkgcmVuZGVycyBzdWNoIGV4dGVu
c2lvbnMgaW1wb3NzaWJsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS08L3NwYW4+PC9iPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBh
bCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRv
cmllczxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
QkVCRUJFIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEy
NDUlMjAyNDIxOTQiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzQ0ICgwKTEyNDUgMjQyMTk0PC9hPg0K
ICZuYnNwO3wgJm5ic3A7PGI+RTombmJzcDs8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJs
b3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1
cnBsZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPjxicj4NCjwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVk
IEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywg
Q2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5
c3RlbXMuY29tL2FpIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTIi
Pnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1p
dGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTog
U3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQg
MGNtIDBjbSAwY207Ym9yZGVyLWNvbG9yOi1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4
dC1jb2xvciI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDtMb3R0ZQ0KIFN0ZWVuYnJp
bmsgWzxhIGhyZWY9Im1haWx0bzpsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZSIgdGFyZ2V0
PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpsb3R0ZS5zdGVlbmJy
aW5rQGZ1LWJlcmxpbi5kZTwvc3Bhbj48L2E+XSZuYnNwOzxicj4NCjxiPlNlbnQ6PC9iPiZuYnNw
OzE3IE1hcmNoIDIwMTYgMTY6NDg8YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7RGVhcmxvdmUsIENocmlz
dG9waGVyIChVSyk8YnI+DQo8Yj5DYzo8L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmlldGZAdGhv
bWFzY2xhdXNlbi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl
Ij5pZXRmQHRob21hc2NsYXVzZW4ub3JnPC9zcGFuPjwvYT47IE1vYmlsZSBBZCBIb2MgTmV0d29y
a3MgbWFpbGluZyBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+Jm5ic3A7UmU6IFttYW5ldF0gTWVz
c2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2UgbXV0YWJpbGl0eSAod2FzIFJFOiBkcmFmdC1pZXRm
LW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKTwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRk
aW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu
PSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQt
YXR0YWNobWVudDpzY3JvbGw7YmFja2dyb3VuZC1wb3NpdGlvbi14OjAlO2JhY2tncm91bmQtcG9z
aXRpb24teTowJSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRl
cjtiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtYXR0YWNobWVudDpzY3JvbGw7YmFja2dyb3Vu
ZC1wb3NpdGlvbi14OjAlO2JhY2tncm91bmQtcG9zaXRpb24teTowJSI+DQo8Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjwvc3Bhbj48L2I+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln
bj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox
Mi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLWF0dGFj
aG1lbnQ6c2Nyb2xsO2JhY2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3JvdW5kLXBvc2l0aW9u
LXk6MCUiPg0KPGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlz
IG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVy
IGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPGJyPg0KQ29uc2lkZXIg
Y2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55
IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljxicj4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcmbmJz
cDs8L3NwYW4+PC9pPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5S
ZWQgRmxhZ3M8L3NwYW4+PC9pPjwvYj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMzMzM5NzIiPiZuYnNwO3RoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzDQogeW91
IHJlY2VpdmUsIGNsaWNrJm5ic3A7PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0
ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxh
Z3MucGRmIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aGVyZTwv
c3Bhbj48L2E+Ljxicj4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVh
c2UgZm9sbG93Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNv
bS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGgl
MjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj
b2xvcjpwdXJwbGUiPnRoaXMgcHJvY2Vzczwvc3Bhbj48L2E+Ljwvc3Bhbj48L2k+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+QW0gMTcuMDMuMjAxNiB1bSAxNzo0NCBzY2hyaWViIERlYXJsb3ZlLCBDaHJpc3Rv
cGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j
b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5jaHJpcy5kZWFy
bG92ZUBiYWVzeXN0ZW1zLmNvbTwvc3Bhbj48L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+R29vZCBwb2ludCBhYm91dCB3aGV0aGVyIHlvdSBqdXN0IHBhc3Mg
b24gb25lIGNvc3Qgb3IgYSBzZXQgb2YgY29zdHMuIEFzIEkgc2FpZCwgbm90IGxvb2tlZCBhdCBk
ZXRhaWxzDQogLSBJIHdpbGwsIHdoZW4gdGltZSBwZXJtaXRzLiBPbmUgY29zdCBpcyBtdWNoIGVh
c2llciwgYW5kIHllcywgaXQgcmVkdWNlcyB0aGUgZml4ZWQgc2l6ZSBhZ2dyZWdhdGVkIHNpZ25h
dHVyZXMgcHJvYmxlbSB0byDigJxqdXN04oCdIG9uZSBvZiBjb21wdXRhdGlvbmFsIGxvYWQuPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3IgdGhlIHJlY29yZCwgVGhvbWFz4oCZ
IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdDsgdGhlIGNvc3QgaXMgb25lIGFnZ3JlZ2F0ZWQgdmFs
dWUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5CZXN0IHJlZ2FyZHMsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPkxvdHRlIFN0ZWVucmJpbms8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn
aW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3
RTdFIj4tLTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxv
dmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGll
ZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9z
cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9z
cGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDs8YSBocmVm
PSJ0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5NCIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7
NDQgKDApMTI0NSAyNDIxOTQ8L2E+DQogJm5ic3A7fCAmbmJzcDs8Yj5FOiZuYnNwOzwvYj48YSBo
cmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5r
Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNv
bTwvc3Bhbj48L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MDAwMDdFIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThC
OTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xv
Z3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxh
IGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj48c3Bh
biBzdHlsZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48
L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lz
dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmds
YW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFy
aywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g
MGNtIDBjbTtib3JkZXItY29sb3I6LW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNv
bG9yIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8YSBocmVmPSJtYWls
dG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj
b2xvcjpwdXJwbGUiPmlldGZAdGhvbWFzY2xhdXNlbi5vcmc8L3NwYW4+PC9hPiZuYnNwO1s8YSBo
cmVmPSJtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu
IHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3JnPC9zcGFu
PjwvYT5dJm5ic3A7PGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7MTcgTWFyY2ggMjAxNiAxNjozODxi
cj4NCjxiPlRvOjwvYj4mbmJzcDtEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4NCjxiPkNj
OjwvYj4mbmJzcDtNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdDxicj4NCjxiPlN1
YmplY3Q6PC9iPiZuYnNwO1JlOiBNZXNzYWdlIGludGVncml0eSBhbmQgbWVzc2FnZSBtdXRhYmls
aXR5ICh3YXMgUkU6IFttYW5ldF0gZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3IC0g
YSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5n
OjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj
ZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtYXR0
YWNobWVudDpzY3JvbGw7YmFja2dyb3VuZC1wb3NpdGlvbi14OjAlO2JhY2tncm91bmQtcG9zaXRp
b24teTowJSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjti
YWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtYXR0YWNobWVudDpzY3JvbGw7YmFja2dyb3VuZC1w
b3NpdGlvbi14OjAlO2JhY2tncm91bmQtcG9zaXRpb24teTowJSI+DQo8Yj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjwvc3Bhbj48L2I+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i
Y2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w
cHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLWF0dGFjaG1l
bnQ6c2Nyb2xsO2JhY2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6
MCUiPg0KPGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1l
c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZy
b20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPGJyPg0KQ29uc2lkZXIgY2Fy
ZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0
dGFjaG1lbnRzIG9yIHJlcGx5Ljxicj4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcmbmJzcDs8
L3NwYW4+PC9pPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQg
RmxhZ3M8L3NwYW4+PC9pPjwvYj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz
MzM5NzIiPiZuYnNwO3RoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzDQogeW91IHJl
Y2VpdmUsIGNsaWNrJm5ic3A7PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1z
LmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3Mu
cGRmIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aGVyZTwvc3Bh
bj48L2E+Ljxicj4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2Ug
Zm9sbG93Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9o
b3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBT
dXNwaWNpb3VzJTIwRW1haWxzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPnRoaXMgcHJvY2Vzczwvc3Bhbj48L2E+Ljwvc3Bhbj48L2k+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
Pk9uIDE3IE1hciAyMDE2LCBhdCAxNzozMCwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgJmx0
OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl
bXMuY29tPC9zcGFuPjwvYT4mZ3Q7DQogd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYXBwcmVjaWF0ZSBU
aG9tYXPigJlzIGNvbW1lbnRzIGFib3V0IHRoZSBsaW1pdGF0aW9ucyBvZiBtZXNzYWdlIHJlZ2Vu
ZXJhdGlvbiwgYnV0IEkgd291bGQgYmUgYSBiaXQNCiBsZXNzIGFic29sdXRlLjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPlRoZSBpc3N1ZXMgb3ZlciBlbmQgdG8gZW5kIGF1dGhlbnRpY2F0aW9uIGFuZCBt
b3JlIGFkdmFuY2VkIHNpZ25hdHVyZXMgYXJlIHZhbGlkLiBJIG5lZWQgdG8gcmVhZA0KIHRoZSBn
aXZlbiByZWZlcmVuY2Ugb24gYWdncmVnYXRlIHNpZ25hdHVyZXMgdG8gaW5jcmVhc2UgbXkga25v
d2xlZGdlICh0aGFua3MgZm9yIGl0KSwgYnV0IG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHBvc3Np
YmlsaXRpZXMgaW4gdGhpcyBmaWVsZCBtYXkgb2ZmZXIgYSBzb2x1dGlvbiB0byB0aGUgcHJvYmxl
bSwgYnV0IHdpdGggc29tZSBvdGhlciBpc3N1ZXMgKHBvc3NpYmx5IGluY2x1ZGluZyBhIG5ldyB0
eXBlIG9mIFRMVikuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0IHRoZSBob3AgY291bnQvbGltaXQg
cG9pbnQgSSBkb27igJl0IGZ1bGx5IGFncmVlIHdpdGgsIHlvdSBjYW4gcmVnZW5lcmF0ZSB3aXRo
IGFuIGluY3JlbWVudGVkL2RlY3JlbWVudGVkDQogY291bnQvbGltaXQsIHdoaWNoIGxlYXZlcyB0
aGUgYWJpbGl0eSB0byBwcmV2ZW50IG1lc3NhZ2VzIHByb3BhZ2F0aW5nIGluZGVmaW5pdGVseSwg
aW5jbHVkaW5nIGV4cGFuZGluZyByaW5nIHNlYXJjaGVzLCBhbmQgcmV0YWlucyB0aGUgYWJpbGl0
eSB0byB1c2UgUkZDIDU0OTcgaW50ZXJ2YWwgYW5kIHZhbGlkaXR5IHRpbWVzIHRoYXQgbWlnaHQg
YmUgdXNlZnVsIHdpdGggYW4gZXhwYW5kaW5nIHJpbmcgc2VhcmNoIChvciBtaWdodCBub3QpLjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCB0aGUga2V5IGlzc3VlIGlzIHRoYXQgQU9EVnYyIHdhbnRz
IHRvIGFjY3VtdWxhdGUgbWV0cmljcy4gSSBzdGlsbCBoYXZlbuKAmXQgZ290IHRvIHRoZSBib3R0
b20gb2YNCiBtYW55IGRldGFpbHMgaGVyZSwgYnV0IGxldOKAmXMgZm9yIHRoZSBtb21lbnQganVz
dCBjb25zaWRlciB0aGF0IGNvbmNlcHR1YWxseS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdOKAmXMg
aGFyZCB0byBoYW5kbGUgZW5kIHRvIGVuZC4gQ2hhcmxpZeKAmXMgZHJhZnQgYXR0ZW1wdHMgdG8g
ZG8gYW4gZW5kIHRvIGVuZCBvZiBzb21lIGluZm9ybWF0aW9uLA0KIG5vdCB0aGlzIGluZm9ybWF0
aW9uLiBJ4oCZbSBub3Qgc3VyZSBpZiB0aGF04oCZcyB1c2VmdWwgKGFuZCB0aGUgc3BlY2lhbGlz
ZWQgZm9ybWF0IGlzIGJldHRlciBhdm9pZGVkIGlmIHBvc3NpYmxlKS4gT3RoZXIgYXBwcm9hY2hl
cyBhcmUgaG9wIGJ5IGhvcCAobWlnaHQgYXMgd2VsbCB1c2UgcGFja2V0IHNpZ25hdHVyZXMpIGFu
ZCBzaGFyZWQga2V5IChtaWdodCBhcyB3ZWxsIGdvIGhvcCBieSBob3ApLiBQYWlyd2lzZSBzaWdu
YXR1cmVzIGZvciBlYWNoDQogcGFpciBvZiByb3V0ZXJzIEnigJltIGRpc2NvdW50aW5nIGFzIHNj
YWxpbmcgdGVycmlibHkuIEluIHRoZSBpbnRlcmVzdHMgb2YgY29tcGxldGVuZXNzIGxldOKAmXMg
bWVudGlvbiBub3QgYWNjdW11bGF0aW5nIG1ldHJpY3MsIHdoaWNoIHB1dHMgdXMgYmFjayB0byBo
b3AgY291bnQgYW5kIHRoYXTigJlzIG5vdCBpZGVhbCBlaXRoZXIuPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+SSBkb27igJl0IHRoaW5rIHRoZXJlIGlzIGFuIGlkZWFsIHNvbHV0aW9uLiAoSSBsaWtlIGlk
ZWFzIEnigJl2ZSBzZWVuIGFib3V0IGFnZ3JlZ2F0aW5nLCBidXQgdGhhdCBoYXMNCiBzb21lIGlz
c3VlcyBvZiBpdHMgb3duLCBldmVuIGFwYXJ0IGZyb20gY29tcHV0YXRpb25hbCBsb2FkLikgSeKA
mWQgbG92ZSB0byBiZSBwcm92ZWQgd3JvbmcgLSBzb21lb25lIHdpdGggdGhlIHBlcmZlY3Qgc29s
dXRpb24gdG8gY29tZSBhbG9uZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGljaCBtZWFucyB0aGF0
IGVpdGhlciB3ZSBtYWtlIGFuIGFyYml0cmFyeSBjaG9pY2UgLSB3aGljaCB3aWxsIGJlIGRpc2Fn
cmVlZCB3aXRoLCBidXQgbmVlZHMgZGlzY3Vzc2luZw0KIGZpcnN0IC0gb3IgY3JlYXRlIHNvbWV0
aGluZyBmbGV4aWJsZS4gVW5mb3J0dW5hdGVseSBmbGV4aWJsZSBpbiB0aGF0IHJlZ2FyZCBjb25z
dHJhaW5zIGluIG90aGVycywgZS5nLiBzb21lIChtYW55PyBtb3N0PykgYWdncmVnYXRpbmcgc2ln
bmF0dXJlcyBuZWVkIGZpeGVkIGRhdGEgc2l6ZXMgKHdoaWNoIHdlIGNhbiBkbyBieSBkZWZpbmlu
ZyBhIFRMViB0aGF0IOKAnGZpbGxzIHVw4oCdIHdpdGggaG9wIGNvdW50LCBidXQgdGhhdCBoYXMg
YSBjb3N0IHRvbykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPkkgaGF2ZSBiZWVuIHRvbGQgYnkgcGVvcGxlIG11Y2ggbW9yZSB3ZWxsIHZl
cnNlZCBpbiB0aGlzIHRoYW4gSSBpbiBjcnlwdG9sb2d5LCB0aGF0IHRoZSBjb3JyZWN0IGFuc3dl
ciBpcyDigJxzb21l4oCdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhdCBz
YWlkLCAmcXVvdDtBT0RWdjIgd2FudHMgdG8gYWNjdW11bGF0ZSBtZXRyaWNz4oCdIOKAlCBkb2Vz
IHRoYXQgbWVhbiB0aGF0IHRoZSBtZXNzYWdlIGdyb3dzIGFzIGl0IGlzIGJlaW5nIGZvcndhcmRl
ZCwgYW5kIHRoYXQgdGhlIHJlY2lwaWVudCBvZiBhIFJSRVEvUlJFUCB3aWxsIGtub3cgdGhlIGlu
ZGl2aWR1YWwNCiBjb3N0cyBvZiBlYWNoIHBhdGggc2VnbWVudD8gTXkgdW5kZXJzdGFuZGluZyBp
cywgdGhhdCB0aGUgcmVjaXBpZW50IHdpbGwgZ2V0IOKAnHRoZSBzdW0gdGhlIGNvc3RzIG9mIGVh
Y2ggcGF0aCBzZWdtZW504oCdIHdoaWNoIHNob3VsZCBiZSBmaXR0aW5nIHdpdGhpbiBhIGZpeGVk
IHNpemU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaG9tYXM8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy
Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tb3JyeSwgbm8gYW5z
d2VycywganVzdCBjb21tZW50cy4gQW5kIEnigJltIG5vdCBhZGRyZXNzaW5nIFRob21hc+KAmXMg
bGF0ZXIgcG9pbnRzIGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMwMDdFN0UiPi0tPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw
dCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhl
ciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVt
cyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48
YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNw
OzxhIGhyZWY9InRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0IiB0YXJnZXQ9Il9ibGFu
ayI+JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NDwvYT4NCiAmbmJzcDt8ICZuYnNwOzxiPkU6Jm5ic3A7
PC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0
PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5
c3RlbXMuY29tPC9zcGFuPjwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQg
VGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4u
PGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxh
bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3Nw
YW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
M0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVn
aXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZp
Y2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s
aWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtO2JvcmRlci1jb2xv
cjotbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3IiPg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDttYW5ldA0KIFs8YSBocmVmPSJtYWlsdG86
bWFuZXQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPm1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dJm5ic3A7
PGI+T24gQmVoYWxmIE9mJm5ic3A7PC9iPjxhIGhyZWY9Im1haWx0bzppZXRmQHRob21hc2NsYXVz
ZW4ub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWV0ZkB0
aG9tYXNjbGF1c2VuLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7MTcgTWFy
Y2ggMjAxNiAxNjowMDxicj4NCjxiPlRvOjwvYj4mbmJzcDtNb2JpbGUgQWQgSG9jIE5ldHdvcmtz
IG1haWxpbmcgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiZuYnNwO1ttYW5ldF0gZHJhZnQtaWV0
Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtczwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAy
LjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6
c2Nyb2xsO2JhY2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCUi
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3Vu
ZDp3aGl0ZTtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6c2Nyb2xsO2JhY2tncm91bmQtcG9zaXRpb24t
eDowJTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCUiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8L3NwYW4+PC9iPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O3RleHQt
YWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1hdHRhY2htZW50OnNjcm9s
bDtiYWNrZ3JvdW5kLXBvc2l0aW9uLXg6MCU7YmFja2dyb3VuZC1wb3NpdGlvbi15OjAlIj4NCjxp
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9y
aWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4
dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljxicj4NCkNvbnNpZGVyIGNhcmVmdWxseSB3
aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50
cyBvciByZXBseS48YnI+DQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nJm5ic3A7PC9zcGFuPjwv
aT48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9z
cGFuPjwvaT48L2I+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4m
bmJzcDt0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscw0KIHlvdSByZWNlaXZlLCBj
bGljayZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93
d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiIgdGFy
Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmhlcmU8L3NwYW4+PC9hPi48
YnI+DQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyZu
YnNwOzxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3Jr
L3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91
cyUyMEVtYWlscy5wZGYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl
Ij50aGlzIHByb2Nlc3M8L3NwYW4+PC9hPi48L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAx
LjBwdDtwYWRkaW5nOjEuMHB0IDQuMHB0IDEuMHB0IDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KjxiPioq
Jm5ic3A7PC9iPjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XQVJOSU5HJm5i
c3A7PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KioqPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5FWFRFUk5B
TCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2Fu
aXphdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi48L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPkRlYXIgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPkFwb2xvZ2llcyBmb3Igbm90IGhhdmluZyBnb3R0ZW4gdGhpcyBk
b25lIHNvb25lciAtIGRheS1qb2IgbGVhdmluZyBmZXcgc3BhcmUgY3ljbGVzLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SeKA
mXZlIHByZXZpb3VzbHkgb2ZmZXJlZCByZXZpZXdzIGFuZCBjb21tZW50cywgYW5kIHNvbWUgb2Yg
dGhvc2UgaGF2ZSBiZWVuIGFkZHJlc3NlZCBpbiB0aGUgbGF0ZXN0IEktRCDigJQgb3RoZXJzIGhh
dmUgbm90LCBidXQgc2hvdWxkIGJlLiBJIHJlY2FsbCB0aGF0IHRoZXJlIHdhcyBzb21lIG1haWwg
YXR0ZW1wdGluZw0KIHRvIHJlYnV0IHBhcnRzIG9mIHRoZSByZXZpZXcsIGFuZCBJIHdpbGwgZGln
IGl0IG91dCBhbmQgcmVwbHkgdG8gdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldpdGggdGhhdCBiZWluZyBzYWlkLCBJ
IGhhdmUgcmV2aWV3ZWQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCwgYW5kIGZ1
bGwgZGV0YWlscyB3aWxsIGJlIGZvcnRoY29taW5nLiBUaGVyZeKAmXJlIGEgY291cGxlIG9mIGJp
Zy10aWNrZXQvYXJjaGl0ZWN0dXJhbCBpdGVtcyB0aGF0IEkgd2FudCB0bw0KIGFkZHJlc3MgdXAg
ZnJvbnQsIGFzIEkgYmVsaWV2ZSB0aGF0IGJlZm9yZSB3ZSBoYXZlIHRob3NlIGhhbW1lcmVkIG91
dCwgaXQgd2lsbCBiZSB1c2VsZXNzIHRvIGdvIGludG8gZGV0YWlscy4gTm90ZSwgSSBkbyBub3Qg
Y2xhaW0gdGhhdCB0aGlzIGlzIGFuIGV4aGF1c3RpdmUgbGlzdCBvZiDigJxiaWcgdGlja2V0IGl0
ZW1z4oCdLCBidXQgdGhhdOKAmXMgYXMgZmFyIGFzIEkgaGF2ZSBnb3R0ZW4gaW4gdGhpbmtpbmcg
dGhpcyB0aHJvdWdoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhbHNvIGJyaW5nIHRoZXNlIHVwIGFzIHRoZXkgYXJlIGl0
ZW1zIHRoYXQgaGF2ZSBiZWVuIGJyb3VnaHQgdXAgcmVwZWF0ZWRseSBvdmVyIHRoZSBwYXN0IHll
YXJzLCBidXQgbm90IHJlc29sdmVkIG5vciBkaXNjdXNzZWQuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48dT5Mb29wczwv
dT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPkp1c3QgdG8gYnJpbmcgdGhpcyBvdXQ6IEkgc2hhcmUgQ2hyaXPigJkgd29ycnkgYWJv
dXQgY29uZmxpY3RpbmcgYW5kIGNvbmN1cnJlbnQgc3RhdGVtZW50cyBmcm9tIHRoZSBhdXRob3Jz
IG9uIOKAnFRoZXJlIGFyZSBubyBsb29wcyBwb3NzaWJsZeKAnSBhbmQg4oCcV2UgbmVlZCB0byBm
aXggdHdvIHNpdHVhdGlvbnMgd2hlcmUNCiBsb29wcyBjYW4gb2NjdXLigJ0gYW5kIOKAnHdlIGFy
ZSBzdGlsbCBpbnZlc3RpZ2F0aW5nIHNvbWUgbG9vcCBjb25kaXRpb25z4oCdPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHBh
cnRpY3VsYXJseSB3b3JyeSB0aGF0IHRoaXMgaXMgbm90IGEgZGlzY3Vzc2lvbiBoYWQgaW4gcHVi
bGljLCBidXQgYXBwYXJlbnRseSBpbiBzb21lIG90aGVyIGZvcnVt4oCmPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxiPjx1PkludGVybWVkaWF0ZSBSb3V0ZSBSZXBsaWVzLCBhbmQgYWxsIG9mIHNlY3Rp
b24gMTA8L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5TZWN0aW9uIDEwIGNvbnRhaW5zIGEgc2V0IG9mIOKAnHZhZ3VlbHkgc3Bl
Y2lmaWVkIGV4dGVuc2lvbnPigJ0sIHdoaWNoIGlzIGluY29oZXJlbnQgd2l0aCB0aGUgaW50ZW5k
ZWQgc3RhdHVzIGluZGljYXRlZCBmb3IgdGhpcyBkb2N1bWVudC4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNwZWNp
ZmljYWxseSwgYW5kIHRoaXMgaXMgbm90IHVucmVsYXRlZCB0byB0aGUgcG9pbnQgYWJvdXQgbG9v
cHMgYWJvdmUsIGludGVybWVkaWF0ZSBSUkVQcyAoc2VjdGlvbiAxMC4zKSBhcmUgYSBwb3RlbnRp
YWwgc291cmNlIGZvciBsb29wcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkV4cGFuZGluZyBSaW5nIE11bHRpY2FzdCAoc2Vj
dGlvbiAxMC4xKSBpcyBub3QgZG9jdW1lbnRlZCBpbiBhIHdheSB0aGF0IGNhbiBiZSBpbXBsZW1l
bnRlZCAoYW5kIGFsc28sIHNlZSDigJxGb3J3YXJkaW5nLXZzLXJlZ2VuZXJhdGlvbuKAnSBiZWxv
dywgaXQgaXMgaW4gdGhlIHByZXNlbnQgZm9ybSBvZiB0aGlzIHByb3RvY29sDQogaW1wb3NzaWJs
ZSksIGV0Yy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjx1PkZvcndhcmRpbmctdnMtcmVnZW5l
cmF0aW9uPC91PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+UmVjZW50IGV4Y2hhbmdlcyBvbiB0aGUgbGlzdCBtYWRlIG1lIHVuZGVy
c3RhbmQgdGhhdCBwcm90b2NvbCBjb250cm9sIG1lc3NhZ2VzIGFyZSAqbm90KiBmb3J3YXJkZWQs
IGJ1dCBhcmUgY29uc3VtZWQgYXQgZWFjaCBob3AsIHRoZW4gYSBuZXcgbWVzc2FnZSB3aXRoIChh
bG1vc3QtYnV0LW5vdC1xdWl0ZSkNCiB0aGUgc2FtZSBjb250ZW50IGlzIGdlbmVyYXRlZCBhbmQg
dHJhbnNtaXR0ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5JIGhhdmUgdGhvdWdodCBzb21lIG1vcmUgb24gdGhpcyAoJmFt
cDsgcmVhZCBzb21lIG9mIHRoZSBleGNoYW5nZXMgb24gdGhlIGxpc3Qgb24gdGhpcyB0b3BpYyBi
eSBDaHJpcywgVWxyaWNoLCBhbmQgb3RoZXJzKSwgYW5kIEkgYW0gY29udmluY2VkIHRoYXQgdGhp
cyBpcyBub3QgdGhlIHJpZ2h0IHdheSB0byBnbywmbmJzcDs8Yj5hdA0KIGxlYXN0PC9iPiZuYnNw
O2ZvciB0aGUgZm9sbG93aW5nIHJlYXNvbnM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
byZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOzxiPkl0IHJlbmRlcnMgdGhlIGhvcC1saW1pdC9ob3AtY291bnQgZmllbGRzIGluIHRoZSBS
RkM1NDQ0IG1lc3NhZ2UgaGVhZGVyIHVzZWxlc3MuPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDtUaGlzIHdvdWxkIG5vdCBiZSBiYWQgaWYgdGhlIGZ1bmN0aW9uYWxpdHkgb2ZmZXJl
ZCBieSB0aG9zZSBmaWVsZHMgd2FzIG5vdCB1c2VmdWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A74oCUIHNhZGx5LCBpdCBpcy4gRm9yIGV4YW1wbGUsIGZvciBzY29wZSBsaW1pdGVkIGZs
b29kaW5nIChleHBhbmRpbmcgcmluZyBzZWFyY2gsIGFuZCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDtzdWNoKSB3aGljaCBtYXkgYmUgb2YgaW50ZXJlc3QsIGFuZCB3aGljaCBy
ZXF1aXJlIGhvcC1saW1pdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QSBo
b3AtY291bnQgZmllbGQgbWF5IGFsc28gcHJvdmlkZSBhIOKAnGNoZWFw4oCdIChpbiB0ZXJtcyBv
ZiBvdmVyaGVhZCkgYWRkaXRpb25hbCBwaWVjZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDtvZiBpbmZvcm1hdGlvbiB0byB1c2UgY29uanVuY3RpdmVseSB3aXRoIGEg4oCccmVhbOKAnSBt
ZXRyaWMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgb25seSBwcmFj
dGljYWwgc29sdXRpb24gd291bGQgYmUgdG8gcmUtaW50cm9kdWNlIHRoZXNlIGZ1bmN0aW9ucyBi
eSB3YXkgb2YgaW5zZXJ0aW5nIGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TWVzc2Fn
ZVRMViDigJQgd2hpY2ggKGkpIGlzIG5vdCBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCwgYW5k
IChpaSkgd2hpY2ggd291bGQganVzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzZXJ2
ZSB0byByZW5kZXIgbWVzc2FnZXMgYmlnZ2VyIHRoYW4gc3RyaWN0bHkgbmVlZGVkLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U2NvcGUgbGltaXRlZCBmbG9vZGluZyAmbmJz
cDtkb2VzIHNlZW0gdG8gYmUgYSBuZWNlc3NhcnkgcmVxdWlyZW1lbnQsIGlmIGZvciBubzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvdGhlciByZWFzb24gdGhhbiB0byBwcmV2ZW50IGlu
Zm9ybWF0aW9uIGZyb20g4oCcY2lyY3VsYXRpbmcgZm9yZXZlciBpbiB0aGUgbmV0d29ya+KAnS48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwO28mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8Yj48dT5JdCBtYWtlcyBlbmQtdG8tZW5kIGF1dGhl
bnRpY2F0aW9uIHVubmVjZXNzYXJpbHkgaGFyZC48L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDtJIHRoaW5rIENocmlzIGNhbGxlZCB0aGlzIG91dCBhbHJlYWR5LCBidXQgaXQg
YmVhcnMgcmVwZWF0aW5nOiBTIGdlbmVyYXRlcyBhIG1lc3NhZ2UmbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7KHNheSwgYSBSUkVRKSwgYW5kIGluY2x1ZGVzIGFuIElDViBjYWxj
dWxhdGVkIG92ZXIgdGhlIGNvbnRlbnQgb2YgdGhlIG1lc3NhZ2UuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwO0ZvciBhbnkgcmVjaXBpZW50IHRvIGJlIGFibGUgdG8gdmFsaWRhdGUgdGhl
IElDViwgdGhlIG1lc3NhZ2UgaGFzIHRvIGJlIGV4YWN0bHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7dGhlIHNhbWUg4oCUIG5vdCBqdXN0IGluIGNvbnRlbnQsIGJ1dCBpbiBzdHJ1Y3R1
cmUg4oCUIGFzIHdoYXQgd2FzIGdlbmVyYXRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwO+KAnFJlZ2VuZXJhdGluZ+KAnSByYXRoZXIgdGhhbiDigJxmb3J3YXJkaW5n4oCd
IG1lc3NhZ2VzIG1lYW5zLCB0aGF0IHRoZSBpbnRlcm1lZGlhdGU8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7cm91dGVyIOKAnHJlZ2VuZXJhdGluZ+KAnSB0aGUgUlJFUSBtYXkgY2hvc2Ug
YSBkaWZmZXJlbnQgc3RydWN0dXJlIChlLmcuLCBpbmNsdWRlIFRMVnM8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7aW4gYSBkaWZmZXJlbnQgb3JkZXIpLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIHByb3Bvc2FsIGZyb20mbmJzcDs8YSBocmVmPSJodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMCIg
dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1wZXJraW5zLW1hbmV0LWFvZHYtZTJlc2VjLTAwPC9zcGFuPjwv
YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aXMgdG8gYWRkIGNvbnN0cmFpbnRzIG9u
IChpKSB0aGUgc2V0IG9mIGVsZW1lbnRzIHRvIGluY2x1ZGUgaW4gYSBzaWduYXR1cmUgYW5kIChp
aSkgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO29yZGVyIG9mIHRoZXNlIGVsZW1l
bnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7T25lJm5ic3A7cHJvYmxl
bSB3aXRoIHRoYXQgYXBwcm9hY2ggaXMgKGkpOiBpZiBhbiBleHRlbnNpb24gYWRkcyBhIG1lc3Nh
Z2UgVExWLCBvciBhbiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBZGRyZXNz
IFRMViwgdG8gYSBtZXNzYWdlLCB0aGVuIHRoYXQgd2lsbCBub3QgYmUg4oCcY292ZXJlZOKAnSBi
eSB0aGUgcHJvcG9zZWQgZTJlc2VjIFRMVi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
UmF0aGVyIGZvciAqZWFjaCogZXh0ZW5zaW9uIGRldmVsb3BlZCwgYW4g4oCcdXBkYXRlcyBlMmVz
ZWPigJ0gY2xhdXNlIG5lZWRzIHRvIGJlIGRvbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDtJ4oCZZCBzYXkgdGhhdCB0aGlzIGFwcHJvYWNoIHdvdWxkIGJlIHByb25lIHRv
IGVycm9ycyDigJQgYW5kIGFkZCBlbnRyb3B5IHRvIHRoZSBwcm9jZXNzPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO29mIGRlc2lnbmluZyBwcm90b2NvbCBleHRlbnNpb25zLiBUaGUgYWx0
ZXJuYXRpdmUsIGEgbWVzc2FnZSBiZWluZyBnZW5lcmF0ZWQgYnkgdGhlPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO3NvdXJjZSBhbmQgKmZvcndhcmRlZCogKGFzIHdlIGRvIGluIE9MU1J2
MiwgZm9yIGV4YW1wbGUpIHdvdWxkIGFsbG93IElDViBUTFZzJm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyhldmVuLCBhbGxvdyByZXVzZSBvZiB0aG9zZSBzcGVjaWZpZWQgZm9y
IE9MU1J2MikgZm9yIGNvdmVyaW5nIGEgbWVzc2FnZSBhbmQmbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7ZXh0ZW5zaW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO+KAnEJ1dCB3aGF0IGFib3V0IHRoZSBtZXRyaWNzIHZhbHVlIHdoaWNoIHdpbGwgY2hh
bmdlIG9uIGVhY2ggaG9w4oCdLCB5b3UgbWF5IHNheT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Rm9ydHVuYXRlbHksIHRoYXQgaXMgcmVsYXRpdmVseSBlYXN5IHRvIGhhbmRsZTogc2lt
cGx5IHplcm8gb3V0IHRoZSB2YWx1ZSBvZiB0aGF0IFRMViB3aGVuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwO2dlbmVyYXRpbmcgb3IgdmVyaWZ5aW5nIHRoZSBJQ1YgTWVzc2FnZVRMVi4g
QW5kIHVzZSBQYWNrZXQtVExWcyBmb3IgaG9wLWJ5LWhvcCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDthdXRoZW50aWNhdGlvbiwgaWYgbmVlZGVkIChidXQsIHNlZSBiZWxvdyku
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGI+PHU+SXQgcHJldmVudHMgdGhlIHVzZSBvZiBt
b3JlIGNsZXZlci9hZHZhbmNlZCBzaWduYXR1cmUgc2NoZW1lcy9JQ1ZzPC91PjwvYj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QWdncmVnYXRlIHNpZ25hdHVyZSBhbGdvcml0aG1zICgm
bmJzcDs8YSBocmVmPSJodHRwczovL2NyeXB0by5zdGFuZm9yZC5lZHUvfmRhYm8vcGFwZXJzL2Fn
Z3N1cnZleS5wZGYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5o
dHRwczovL2NyeXB0by5zdGFuZm9yZC5lZHUvfmRhYm8vcGFwZXJzL2FnZ3N1cnZleS5wZGY8L3Nw
YW4+PC9hPik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZXhpc3QsIGFuZCBhbiBpbnRl
cmVzdGluZyB1c2UtY2FzZSBjYW4gYmUgZm91bmQgaW4gYWxzbyByZWFjdGl2ZSBwcm90b2NvbHMs
IGFsbG93aW5nIHZlcmlmeWluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtub3Qg4oCc
anVzdOKAnSB0aGUgZW5kIHBvaW50cywgYnV0IGFsc28gdGhlIGludGVybWVkaWFyaWVzIChhZ2Fp
biwgd2l0aCB0aGUgYXBwcm9wcmlhdGUg4oCcemVybyBvdXTigJ08bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7ZGlzY3Vzc2VkIGFib3ZlLCBvciBzb21ldGhpbmcgc21hcnRlcikuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1JlZ2VuZXJhdGlvbiBvZiBtZXNzYWdlcywgcmF0aGVy
IHRoYW4gZm9yd2FyZGluZywgcmVuZGVycyB0aGF0IGltcG9zc2libGUgKG9yLCBpZiB1c2VkLDxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt1cGRhdGluZyB0byAmbmJzcDs8YSBocmVmPSJo
dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNl
Yy0wMCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wZXJraW5zLW1hbmV0LWFvZHYtZTJlc2VjLTAwPC9z
cGFuPjwvYT4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5UaGVyZSBhcmUgb3RoZXIgcmVhc29ucywgYnV0IHRoZSBhYm92ZSBh
cmUgdGhvc2UgdGhhdCBqdW1wIGF0IG1lIGFzIGltbWVkaWF0ZSBzaG93LXN0b3BwZXJzLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+SSBkbyBob25lc3RseSBub3Qgc2VlIHdoYXQgcG9zc2libGUgYmVuZWZpdCB0aGVyZSBpcyBm
cm9tIOKAnHJlZ2VuZXJhdGlvbuKAnSDigJQgYnV0IEkgc2VlIHZlcnkgY2xlYXIgaW5jb252ZW5p
ZW5jZXMsIGFuZCBzZWN1cml0eSBpcyBub3QgdGhlIGxlYXN0IG9mIHRoZXNlLiBJbnNpc3Rpbmcg
b24g4oCccmVnZW5lcmF0aW9u4oCdDQogcmVxdWlyZXMgZGV2ZWxvcG1lbnQgb2Yg4oCcbm9uLWdl
bmVyYWwgd29ya2Fyb3VuZHPigJ0gYXMgcG9pbnRlZCBvdXQgYWJvdmUuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48dT5T
ZWN1cml0eSBDb25zaWRlcmF0aW9uczwvdT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgaXMgYW4gYWx3YXlzIHRob3JueSBz
dWJqZWN0LiBXaGVuIE9MU1J2MiB3YXMgZ29pbmcgdGhyb3VnaCB0aGUgcHJvY2VzcyB3ZSBnb3Qg
YSB0aG9yb3VnaCBlZHVjYXRpb24gaW4gaG93IGxpdHRsZSB3ZSBrbmV3IGFib3V0IHNlY3VyaXR5
IGZyb20gdGhlIFNFQy1BRHMsIGFuZCBoYWQgdG8gc3BlbmQgYWJvdXQNCiBhIHllYXIgb3Igc28g
ZGV2ZWxvcGluZyBSRkM3MTgzLiBUaGUgYm90dG9tIGxpbmUgaXMsIHRoYXQgdGhpcyBwcm90b2Nv
bCBuZWVkcyBpdHMg4oCcUkZDNzE4MyAmbmJzcDtlcXVpdmFsZW504oCdLCBlaXRoZXIgYXMgcGFy
dCBvZiB0aGUgbWFpbiBkb2N1bWVudCwgb3IgYXMgYW4gaW5kZXBlbmRlbnQgZG9jdW1lbnQuIGN1
cnJlbnRseSwgdGhhdCBpcyBub3QgdGhlIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BIG1pbmltYSwgbG9va2luZyBh
dCBCQ1A3MiBhbmQgQkNQMTA3IOKAlCB0YWtpbmcgaW5zcGlyYXRpb24gZnJvbSBSRkM3MTgzIG1p
Z2h0IGJlIGF3IGdvb2QgaWRlYSwgYXMgdGhhdCB3YXMgdGhlIG1vc3QgcmVjZW50IHRoYXQgd2Vu
dCB0aHJvdWdoIHRoZSBTRUMgQUQuIFJlZ2FyZGxlc3Mgb2YgaG93LCBob3dldmVyLA0KIGEg4oCc
bWFuZGF0b3J5IHRvIGltcGxlbWVudOKAnSBzZWN1cml0eSBtZWNoYW5pc20gbW9zdCBiZSBzcGVj
aWZpZWQgKEkgdGhpbmsgdGhlIHJpZ2h0IHRlcm0gd2FzIOKAnE1VU1QgaW1wbGVtZW50LCBTSE9V
TEQgdXNl4oCdKSwgaW4gc3VmZmljaWVudCBkZXRhaWwgdG8gZW5zdXJlIGludGVyb3BlcmFibGUg
aW1wbGVtZW50YXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgYW4gZXhhbXBsZSwgYm90aCBbUkZDNjEzMF0gYW5k
IFtSRkM3MTgxXSBzZXQgb3V0IHRoYXQgdGhhdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7
ICZuYnNwOyBPbiByZWNlaXZpbmcgYSAuLi4gbWVzc2FnZSwgYSByb3V0ZXIgTVVTVCBmaXJzdCBj
aGVjayBpZiB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgbWVzc2FnZSBpcyBpbnZhbGlkIGZvciBw
cm9jZXNzaW5nIGJ5IHRoaXMgcm91dGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5hbmQgdGhlbiBwcm9jZWVkIHRvIGdpdmUg
YSBudW1iZXIgb2YgY29uZGl0aW9ucyB0aGF0LCBlYWNoLCB3aWxsIGxlYWQgdG8gYSByZWplY3Rp
b24gb2YgdGhlIG1lc3NhZ2UgYXMgJnF1b3Q7YmFkbHkgZm9ybWVkIGFuZCB0aGVyZWZvcmUgaW52
YWxpZCBmb3IgcHJvY2Vzc2luZ+KAnSDigJQgYSBsaXN0IHdoaWNoIFJGQzcxODMNCiB0aGVuIGFt
ZW5kZWQuIFRoYXQgZ2F2ZSBhIOKAnGhvb2vigJ0gZm9yIFJGQzcxODMgZm9yIGluc2VydGluZyDi
gJxyZWplY3Rpb27igJ0uIElkZW0gZm9yIG1lc3NhZ2UgZ2VuZXJhdGlvbi48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIEkg
d2FzIHRvIGRvIFJGQzcxODEvUkZDNjEzMCB0b2RheSwgSSB3b3VsZCBpbmNsdWRlIHRoYXQgZGly
ZWN0bHkgaW50byB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMuIEl0IHR1cm5lZCBvdXQgdG8g
YmUgbW9yZSBvdmVyaGVhZCAoYW5kIHNsb3cgZG93biBwdWJsaWNhdGlvbiBhbnl3YXlzKSB0byBk
bw0KIGl0IGFzIHNlcGFyYXRlIGRvY3VtZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2Vjb25kbHksIHdl
IG5lZWQgdG8gYmUgYSBsb3QgbW9yZSByaWdpZCBpbiB0ZXJtcyBvZiB3aGF0IElDVnMsIFRpbWVz
dGFtcHMsIGV0Yy4gYXJlIGFkZGVkL3JlbW92ZWQsIGFuZCB3aGF0IHRoYXQgYnJpbmdzLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Rm9yIGV4YW1wbGUgKHdpdGggdGhlIGFzc3VtcHRpb24gdGhhdCBtZXNzYWdlcyBhcmUgKmZv
cndhcmRlZCogYW5kICpub3QqIHJlZ2VuZXJhdGVkKSwgdGhpcyBjb3VsZCBiZSBvbmUgb3B0aW9u
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7byZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1doZW4gYSBSUkVRLCBS
UkVQIG1lc3NhZ2UgaXMgZ2VuZXJhdGVkLCBhZGQgYW4gSUNWIE1lc3NhZ2UgVExWLCB3aGljaCBp
cyBjYWxjdWxhdGVkICZsdDt0aGlzIHdheSZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A74oCmKHRha2UgaW5zcGlyYXRpb24gZnJvbSBSRkM3MTgz
IGhlcmUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw
dCI+Li4uPGJyPg0KPGJyPg0KW01lc3NhZ2UgY2xpcHBlZF0mbmJzcDsmbmJzcDs8YnI+DQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1h
aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJf
YmxhbmsiPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBt
YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KVGhpcyBlbWFpbCBhbmQg
YW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPg0KcmVj
aXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50
ZW5kZWQ8YnI+DQpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFu
ZCBub3RpZnkgdGhlIHNlbmRlci48YnI+DQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBp
dCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPg0KZGlzdHJpYnV0ZSBpdHMgY29u
dGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w
cHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYu
b3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PG86cD48L286
cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1556GLKXM0002VGREEN_--


From nobody Mon Apr 25 06:56: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 B66C112B014 for ; Mon, 25 Apr 2016 06:56:44 -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 7ZlIf8sCwP9Q for ; Mon, 25 Apr 2016 06:56:42 -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 7412F12D14C for ; Mon, 25 Apr 2016 06:56:42 -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 A3F79C0C16 for ; Mon, 25 Apr 2016 15:56:38 +0200 (CEST)
Date: Mon, 25 Apr 2016 16:00:01 +0200
From: Mattia Campana 
To: manet@ietf.org
Message-ID: <571e22e1.CSj7+MMVQ5eVvWDX%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: Mon, 25 Apr 2016 13:56:44 -0000

[Apologies for possible duplicates]

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: TBA
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 Mon Apr 25 07:18: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 7CEC812B014 for ; Mon, 25 Apr 2016 07:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.884
X-Spam-Level: 
X-Spam-Status: No, score=0.884 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, MANY_SPAN_IN_TEXT=2.299, 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, TRACKER_ID=1.306] autolearn=no 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 WgcYeiP5gvaW for ; Mon, 25 Apr 2016 07:18:43 -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 4149B12B040 for ; Mon, 25 Apr 2016 07:18:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id F04F492085D; Mon, 25 Apr 2016 07:18:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461593922; bh=jPzHR2CdhyK8K+JTRTbboXlePr/cHRimdXvWZ0iOMXA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Rbz2onStQO8UDr7oxaofVXQETp0X+5Fal3I/UfbYIqemLsoCX9EL8NI29RkURaQlx zNZc9CfQhQttbansG07jCBBwXDCE4K8sQ2J0OAAVU7EnuyoDzJsompjQMytSVkKA48 Ixs/xY2NXyl3ah7TSYVXacQ10MjKkChje4L+cvaA=
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 6525292085C; Mon, 25 Apr 2016 07:18:40 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_FDF25E9C-11FF-4824-B200-F0518054F194"
From: ietf@thomasclausen.org
In-Reply-To: 
Date: Mon, 25 Apr 2016 16:18:37 +0200
Sendlaterdate: Mon, 25 Apr 2016 16:18:37 +0200
Message-Id: <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org>
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>       
To: Christopher Dearlove 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 14:18:48 -0000

--Apple-Mail=_FDF25E9C-11FF-4824-B200-F0518054F194
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

I must admit that while I have reviewed the protocol several times, =
I=E2=80=99ve not been digging that deep into the protocol functioning to =
catch this issue of how invasive the protocol operations are when =
forwarding a message: there were other =E2=80=9Cmajor=E2=80=9D issues to =
address (and which obscured the details), so as a first order: thank you =
Victoria, for having called attention to this.

To the substance of these emails.

I am afraid that I do not understand the use of inserting validity TLVs =
while in-flight, into a message. Actually, I am dubious for both the =
originator inserting this (how can the originator of a message know how =
=E2=80=9Clatter parts of the path=E2=80=9D will be have=E2=80=9D) except =
if we are talking duty-cycling of devices and inserting =E2=80=9Cthe =
remaining time that I am going to be up before I suspend=E2=80=9D. =
Intuitively, that would also assume fairly long duty cycles =E2=80=9CI =
am up for tens of seconds=E2=80=9D, which I am not sure are actually =
realistic. And, as Chris says in another email, this is trading off =
=E2=80=9Cthe ability to do security=E2=80=9D for an unknown/untested =
feature =E2=80=94 which I think is the wrong trade-off.

On he topic of =E2=80=9Cneeding to put an address in=E2=80=9D for =
RREP-ACK, I must admit that this seems roundabout. I can see three =
issues here:

	o	I am not sure that adding an address vs. a flag may not =
have to do with the =E2=80=9Cmultiple interfaces/
		multiple addresses=E2=80=9D discrimination mechanics of =
the protocol? I haven=E2=80=99t worked it through, though,=20
		but that would be a guess.

	o	The end-to-end topology diffusion mechanism should not =
need to be concerned with the=20
		=E2=80=9Cbidirectionally check=E2=80=9D of a local link =
(in part, as it encumbers security, but not only).  In short, a
		flag or an address, both are (equally) bad.

	o	A cleaner mechanism would be a =E2=80=9Chello =
mechanism=E2=80=9D, not necessarily as NHDP, but a =E2=80=9Cwhen=20
		forwarding a RREQ/RREP, trigger a 3-way hello exchange, =
if the link is estimated to be of a=20
		type which potentially can be unidirectional=E2=80=9D. =
There is another benefit to doing that, see the end=20
		of this email.

Either way, I do not like the notion of fusing =
metrics-and-link-bidirectionality-detection any more than I like fusing =
global-topology-diffusion-and-link-bidirectionality-detection.=20

The solution all this is, to me, threefold

	1)	Factor out the bidirectionally check in a (triggered) =
neighbour detection mechanism=20
		(triggered HELLO message)

	2)	Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, since =
they add complexity for no perceivable benefits

	3)	Use the security model that we=E2=80=99ve discussed =
previously, where (only) the metrics change per hop.

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 related 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 this
   assumption is not always correct, calculating incoming/outgoing
   metric data is outside of scope of this document.=20

I do not know of any wireless systems, where the assumption that =E2=80=9C=
link metrics are symmetric=E2=80=9D actually holds. Consequently, the =
conclusion 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 link =
the metrics is 4 or 5=E2=80=9D, the protocol must be able to convey and =
distinguish 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.

Hope this helps,


Thomas

> On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK) =
 wrote:
>=20
> Assuming for the moment that everyone will need an RREP-Ack or won=E2=80=
=99t (let=E2=80=99s come back to that) why do C and B need to put an =
address in as an RREQ-Ack request? Why not a flag, because the address =
will be included as the IP sending address - and we know 5444 is =
required to pass that on. (It=E2=80=99s used by NHDP as well.) Then we =
don=E2=80=99t need to change the RREP, it will have a flag set or not, =
and won=E2=80=99t change (in this regard).
> =20
> Now let=E2=80=99s consider do we know whether we can set a fixed flag. =
First I=E2=80=99d say there are two cases - you=E2=80=99ve got a firm =
control on what=E2=80=99s going on in your network, or it=E2=80=99s one =
of unknown parties and behaviour (consistent with specification). In the =
former case you only want one setting, for example no-Ack if running =
NHDP or your MAC layer tells you about bidirectionality, Ack otherwise. =
In the latter case, I think you just always want an Ack. So both cases =
get you to the same place.
> =20
> Should that not be an acceptable argument (though I think it=E2=80=99s =
good for where we are - in fact always Ack is close) then at flag is a =
step better, it=E2=80=99s a fixed location to change. However it would =
be better in that case if the two things to change (metric and ack flag) =
were together. But that has its own issues, so I won=E2=80=99t go there.
> =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: Victoria Mercieca [mailto:vmercieca0@gmail.com =
]=20
> Sent: 25 April 2016 14:15
> To: Jiazi YI
> Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc =
Networks mailing list
> Subject: Re: [manet] Message integrity and message mutability (was RE: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
> =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
> Hi Jiazi,
>=20
>=20
>=20
> =20
> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI > wrote:
> Hi,=20
> =20
> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) =
> =
wrote:
> With regard to your validity time point, we here have a tradeoff. If =
you allow that feature, it significantly impacts on the approach that =
was coming together on as best you can end to end encryption.
> =20
> So the question is, is this a feature that=E2=80=99s really wanted? =
Unfortunately I think we know that the answer to that is, we don=E2=80=99t=
 know because we don=E2=80=99t have any experience. My view would be =
that in the tradeoff of an untested feature (unless I=E2=80=99m wrong =
about that) and the security complication, security wins and drop the =
feature. If there is some real requirement, then there=E2=80=99s a =
discussion. (Questions like how often the intermediate routers actually =
have any knowledge - typically links break for unexpected rather than =
expected reasons. Andan intermediate router could possibly use a =
validity time to influence its behaviour.) Note that dropping the =
ability of intermediate routers to modify/set still allows validity =
times per route to be set at endpoints.
> =20
> I agree with Chris' concern.
> The ValidityTime is optional, which makes the integrity protection =
hard. Furthermore, it gives a potential attack vector: as all the =
routers in a path will take the shortest validityTime, a compromised =
router can set the the validityTime to a very short value, which will =
make the route installed along the path became invalid (very soon).=20
> =20
> On the other hand, I'm not sure this option will give us much help. =
Chris mentioned much knowledge intermediate router would have to decide =
this value (and how much sense the value would make).=20
> Another issue is, a route to a destination might be updated by =
different sources. For example, in the network below:
> =20
> A----B-----C
> =20
> A first establish a route to B with long validity time. Then A =
initiates a route discovery to C. C tends to set a short validity time, =
which will make the route between B and A expire earlier than expected.=20=

> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered =
or not.=20
> =20
> =20
> Not sure I follow here.
>=20
> Currently, the validity time of the route between A and B would not =
affected by a short validity time of a route between A and C. Validity =
times are per-route, and the route A-B and the route A-C are separate.
>=20
> If we switched to a validity time per neighbor (so that we can keep =
validity time separate from route advertisements) as I mentioned in the =
email below, then the validity of a route between A and C would be =
affected if there was a short validity time between A and B. But, if B =
will only route for a certain amount of time, then the route between A =
and C will of course be affected. Is it best to know in advance that =
there's a time limit, or just deal with RERRs when they happen?
> =20
>=20
> =20
> =20
> With regard to the acknowledgements, the problem (with regard to =
security) comes from trying to do two jobs with the same message - end =
to end route advertisement and hop by hop acknowledgement. I understand =
the reasons - saving bytes and message types. (I would have to study the =
protocol really hard to identify if any message types can be folded =
together and recognised by content rather than type efficiently. This I =
do not expect to do.) Again a tradeoff. This one is in discussion space, =
though that needs people who understand both sides of the issue, =
including the details of the bidirectionality mechanism. Of course, as =
has been said, we need one of those.
> =20
> I haven't finished my review of the latest draft, and I don't get the =
necessity of AckReq and the corresponding multicast RREP yet.=20
> If possible, this "optional" field should be avoided.=20
> =20
>=20
> To give an overview of AckReq and RREP:
>=20
> Since AODVv2 requires bidirectional links, this is the way to =
determine if a link is bidirectional.
>=20
> A----B----C
>=20
> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both =
install a route to OrigAddr but they dont yet know if it's valid because =
they dont know if the link to their next hop is available in the reverse =
direction.
> 2) C creates the RREP. Since it doesnt know if the link to B is =
bidirectional, it includes the AckReq (an address to indicate that it =
expects to receive a RREP_Ack from B).
> 3) B receives the RREP, installs a route to TargAddr and marks it as =
valid, since it knows the link to C is bidirectional, because the RREQ =
went in one direction and the RREP came in the other. B also sends the =
RREP_Ack to C and forwards the RREP to A (and might change the message =
to indicate its own AckReq - ie that it requires an ack from A).
> 4) C receives the RREP_Ack from B, and therefore knows that B received =
the RREP, therefore the link is bidirectional. C can then mark its route =
to OrigAddr as valid.
> 5) Similarly, A receives the RREP, installs the route to TargAddr and =
sends an RREP_Ack to B.
> 6) B receives the RREP_Ack and marks its route to OrigAddr as valid.
> =20
> Alternatively, in step 2, if C knows the link to B is bidirectional =
(perhaps from some earlier route discovery), it doesnt need to put the =
AckReq in the RREP. Then in step 3, since B doesnt know if the link to A =
is bidirectional, it changes the message to add the AckReq address, in =
order to get an RREP_Ack from A.
>=20
> If we want to avoid changing the message, we'll need to look at =
forwarding the RREP as-is, and creating a second message to solicit an =
RREP_Ack, in order to verify that the link is bidirectional before =
marking the route to OrigAddr as valid.=20
>=20
> Kind regards,
> Victoria.
> =20
>=20
> =20
> regards
> =20
> Jiazi
> =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 
> BAE Systems Applied Intelligence Limited
> Registered in England & Wales No: 01337451
> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>=20
> =20
> From: Victoria Mercieca [mailto:vmercieca0@gmail.com =
]=20
> Sent: 23 April 2016 10:55
> To: Christopher Dearlove
> Cc: ietf@thomasclausen.org ; Dearlove, =
Christopher (UK); Mobile Ad Hoc Networks mailing list
>=20
> Subject: Re: [manet] Message integrity and message mutability (was RE: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
> =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
> Hi Chris,
> =20
> These have both been in the draft in some form since before I got =
involved... but I'll do my best to explain.
> =20
> - For Validity Time, its a way to advertise that you would only =
support the route contained in the message for a certain period of time. =
The originator might use this, but the draft was written to allow any =
intermediate node to be able to add it or update it too. The route =
created in the Local Route Set has an expiration time associated with =
it, based on the received validity time.
> - For the AckReq address, its so that you can add into a RREP a =
request for an acknowledgement, so that you don't have to have a =
different message type altogether for working out whether links to =
neighbors are bidirectional, and also, since you only care about =
bidirectionality on routes that are being set up, you dont need to =
constantly monitor all neighbors.
> =20
> =20
> In order to avoid the potential AckReq-related changes to each =
message, maybe we do need to introduce a different message specifically =
for this. We could maybe use RREP_Ack to both request and acknowledge? =
It means an extra message of control traffic that needs to be sent, =
maybe one extra message per hop on the path of a RREP, but it could =
still be limited to neighbors which have participated in the route =
discovery rather than monitoring all neighbors at all times.=20
> =20
> This message could maybe also include "I'm happy to route anywhere for =
a certain amount of time", sort of like willingness in OLSR/OLSRv2. So =
instead of having a validity time per route, its a validity time per =
neighbor. Then, for RREQ and RREP, only the metric value would change in =
transit, as discussed. However, that leads to some issues with deciding =
what a route's expiration time is. You might know how long the next hop =
router is valid for, but what if a router beyond that, which was also =
part of the route, had a lower validity time? You couldn't determine the =
real validity time. Do we remove the route expiration time altogether to =
avoid this issue? In which case, we would have to rely on RERR messages =
being sent for routes which become invalid when the neighbor's validity =
time has expired? So neighbor validity time expiration is treated the =
same as a link break.
> =20
> What do you think?
> =20
> Kind regards,
> Victoria.
> =20
> =20
> =20
> =20
> =20
> =20
> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove =
> =
wrote:
> Pretty much all of the discussion has been assuming only a metric =
value change. With multiple things changing many of the ideas go out of =
the window. That reinforces the point about not making specifications =
now that might turn out to be wrong for ICVs.
> =20
> Ignoring how this misunderstanding happened, I'll start by asking why. =
Metric changing I understand. Why the other two? (there's a partial =
explanation of one). What alternatives have people implemented in =
comparable protocols?
>=20
> -- =20
> Christopher Dearlove
> christopher.dearlove@gmail.com  =
(iPhone)
> chris@mnemosyne.demon.co.uk  =
(home)
>=20
> On 23 Apr 2016, at 00:26, Victoria Mercieca > wrote:
>=20
> Hi all,
> =20
> Continued in this thread because the other one seems to be more about =
TLV types and metric type numbers, whereas this is about =
regeneration/forwarding.
> =20
> To recap, in the current draft, there are 3 things that might change =
at each hop:=20
> - the metric value (happens in RREQ and RREP),=20
> - adding/changing Validity Time using the Validity Time TLV (can =
happen in RREQ and RREP),=20
> - adding an address (and corresponding value in the AddressType TLV to =
indicate how to interpret the address) to indicate the address from =
which an RREP_Ack is expected, to accomplish the bidirectionality check =
(can happen in RREP).
>=20
> If we define a certain portion of the message as immutable and include =
the ICV to verify that part, end to end:=20
> - The metric value would be excluded from the ICV since it needs =
changing at each hop.=20
> - Would adding a Validity Time TLV at an intermediate hop be =
acceptable? The whole TLV could be removed in order to calculate the =
ICV?
> - Would adding an address cause issues for the ICV, because it's in =
the address block? Could the rule be "if it contains an AckReq address, =
remove it (and the corresponding value in the AddressType TLV), before =
checking the ICV", is that OK? Or would we need to avoid touching the =
ICV'ed part of the message altogether, maybe put the AckReq address in a =
separate Address Block, with an extra AddressType TLV following that =
address block? Is there a way to accomplish this?
> =20
> Also, to be thorough, do we need to consider RERR messages while we =
discuss regeneration vs forwarding?=20
> - RERR (sent when a link breaks) is a way of saying "I've lost my =
route so I'm telling others" and "you were my next hop, so now I've also =
lost my route, I'll tell others", etc. It's going to be tailored at each =
step to include the relevant routes that got deleted, it's not one =
message being sent end-to-end like RREQ and RREP are.=20
> - However, RERR (sent when a source of traffic is sending data on a =
route which comes through you, and you want to tell the Packet Source's =
router to delete the route) could be seen as an end-to-end message which =
all intermediate routers learn from, similar to RREQ and RREP. It =
reports one route, and doesn't need changing at intermediate hops, so =
could be protected with ICV.
> - Would it be OK to only require a message ICV if a PktSource address =
was included, i.e. when the message needs to go via a number of =
intermediate hops to PktSource's router? All other RERRs are intended to =
be one-hop messages, which may in turn prompt other one-hop messages, =
etc..., and a packet ICV might be more appropriate?
> =20
> Kind regards,
> Victoria.
> =20
> On Thu, Mar 17, 2016 at 5:26 PM, > wrote:
> =20
> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) =
> =
wrote:
> =20
> Yes, I meant AODVv2, thanks for the catch.
> =20
> So is your (Thomas) proposed base specification a hop count only =
metric?
> =20
> No, the would be silly as base specification, given that hop count =
mostly is useless.
> =20
> As base specification I would simply say =E2=80=9CInclude a Metric =
Type Message TLV with a value field, and a 7182 Message TLV & =
Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage as =
to generation and processing).=20
> =20
> With the message generated by the originator of the RREQ/RREP and =
*not* deconstructed/reconstructed/reordered (as is the risk with =
=E2=80=9Cregeneration) allows knowing that it would be *only* that =
metric field being modified (other than hop count/limit) for when =
eventually writing up the extension.
> =20
> (Actually doesn=E2=80=99t the current specification only define hop =
count, or has that changed in latest draft?)
> =20
> No. That is one of the issues I raise in my original. For some reason, =
it cites RFC6551, which is a ROLL document and which has in its abstract =
that:
> =20
>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>    compared with traditional wired and ad hoc networks that require =
the
>    specification of new routing metrics and constraints.=20
> =20
> I.e. this document cites a metric document which clearly claims to be =
inapplicable in ad hoc networks. I note that this is another thing =
I=E2=80=99ve raised for years without seeing it attempted resolved.
> =20
> Best,
> =20
> Thomas
> =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 =
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: ietf@thomasclausen.org  =
[mailto:ietf@thomasclausen.org ]=20
> Sent: 17 March 2016 17:10
> To: Dearlove, Christopher (UK)
> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
> Subject: Re: [manet] Message integrity and message mutability (was RE: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
> =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
> =20
> On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) =
> =
wrote:
> =20
> OK, so we have a message that mutates by:
> - Modifying hop count/limit.
> - Modifying a metric value.
> Anything else?
> =20
> As mutating (other than hop count/limit) messages aren=E2=80=99t =
covered by 5444 or any derivative document (but only recommended =
against, not banned) that you may need to make the message otherwise =
immutable (no deconstruction and rebuilding, other than guaranteed =
unchanging) that would have to be specified by AODVv2. (Easy to say, but =
needs saying.)
> =20
> With you so far.
> =20
>=20
> Then that information is not in a guaranteed fixed location given by a =
simple offset. So any signature algorithm that finds it and ignores it =
or aggregates on it is specific to OLSRv2.
> =20
> Surely you mean AODVv2
> =20
>=20
> So standard 7182 ICVs don=E2=80=99t do the job, you would need an =
AODVv2 specialised variant. Which is the sort of thing that the message =
specific TLV space is there for, I=E2=80=99d be strongly against a =
=E2=80=9Cbut ignore the value of this specific TLV should it occur=E2=80=9D=
 being in the general space. However it can easily be defined by =
reference to 7182 (=E2=80=9Cthis TLV is like that TLV, except if an X =
TLV is present, set its value field to zero=E2=80=9D).
> =20
> Messy, but could work.
> =20
> Not that messy, actually, although clearly not as nice as =E2=80=9Cfixed=
 offset=E2=80=9D.
> =20
> That said, I am arguing for the base spec being:
> =20
>             =E2=80=9Cmake the message otherwise immutable (no =
deconstruction and rebuilding, other=20
>              than guaranteed unchanging)=E2=80=9D which is afforded by =
forwarding
> =20
>                                     +
> =20
>             RFC7182 Timestamps and ICVs.
> =20
>                                     +
> =20
>             RFC7183 style text bringing it all together.
> =20
> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would =
very be an experimental extension.
> =20
> What I object to is, if the base spec specifically renders such =
extensions impossible
> =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 =
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: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de =
]=20
> Sent: 17 March 2016 16:48
> To: Dearlove, Christopher (UK)
> Cc: ietf@thomasclausen.org ; Mobile Ad =
Hoc Networks mailing list
> Subject: Re: [manet] Message integrity and message mutability (was RE: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
> =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
> Hi all,
> =20
> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) =
>:
> =20
> Good point about whether you just pass on one cost or a set of costs. =
As I said, not looked at details - I will, when time permits. One cost =
is much easier, and yes, it reduces the fixed size aggregated signatures =
problem to =E2=80=9Cjust=E2=80=9D one of computational load.
> =20
> For the record, Thomas=E2=80=99 understanding is correct; the cost is =
one aggregated value.=20
> =20
> Best regards,=20
> Lotte Steenrbink
> =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 =
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: ietf@thomasclausen.org  =
[mailto:ietf@thomasclausen.org ]=20
> Sent: 17 March 2016 16:38
> To: Dearlove, Christopher (UK)
> Cc: Mobile Ad Hoc Networks mailing list
> Subject: Re: Message integrity and message mutability (was RE: [manet] =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
> =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
> =20
> On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) =
> =
wrote:
> =20
> I appreciate Thomas=E2=80=99s comments about the limitations of =
message regeneration, but I would be a bit less absolute.
> =20
> The issues over end to end authentication and more advanced signatures =
are valid. I need to read the given reference on aggregate signatures to =
increase my knowledge (thanks for it), but my understanding of the =
possibilities in this field may offer a solution to the problem, but =
with some other issues (possibly including a new type of TLV).
> =20
> But the hop count/limit point I don=E2=80=99t fully agree with, you =
can regenerate with an incremented/decremented count/limit, which leaves =
the ability to prevent messages propagating indefinitely, including =
expanding ring searches, and retains the ability to use RFC 5497 =
interval and validity times that might be useful with an expanding ring =
search (or might not).
> =20
> But the key issue is that AODVv2 wants to accumulate metrics. I still =
haven=E2=80=99t got to the bottom of many details here, but let=E2=80=99s =
for the moment just consider that conceptually.
> =20
> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft =
attempts to do an end to end of some information, not this information. =
I=E2=80=99m not sure if that=E2=80=99s useful (and the specialised =
format is better avoided if possible). Other approaches are hop by hop =
(might as well use packet signatures) and shared key (might as well go =
hop by hop). Pairwise signatures for each pair of routers I=E2=80=99m =
discounting as scaling terribly. In the interests of completeness =
let=E2=80=99s mention not accumulating metrics, which puts us back to =
hop count and that=E2=80=99s not ideal either.
> =20
> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=80=99=
ve seen about aggregating, but that has some issues of its own, even =
apart from computational load.) I=E2=80=99d love to be proved wrong - =
someone with the perfect solution to come along.
> =20
> Which means that either we make an arbitrary choice - which will be =
disagreed with, but needs discussing first - or create something =
flexible. Unfortunately flexible in that regard constrains in others, =
e.g. some (many? most?) aggregating signatures need fixed data sizes =
(which we can do by defining a TLV that =E2=80=9Cfills up=E2=80=9D with =
hop count, but that has a cost too).
> =20
> I have been told by people much more well versed in this than I in =
cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
> =20
> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does =
that mean that the message grows as it is being forwarded, and that the =
recipient of a RREQ/RREP will know the individual costs of each path =
segment? My understanding is, that the recipient will get =E2=80=9Cthe =
sum the costs of each path segment=E2=80=9D which should be fitting =
within a fixed size?
> =20
> Thomas
> =20
>=20
>=20
>=20
> =20
> Sorry, no answers, just comments. And I=E2=80=99m not addressing =
Thomas=E2=80=99s later points here.
> =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 ietf@thomasclausen.org =

> Sent: 17 March 2016 16:00
> To: Mobile Ad Hoc Networks mailing list
> Subject: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big =
ticket Items
> =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
> Dear all,
> =20
> Apologies for not having gotten this done sooner - day-job leaving few =
spare cycles.
> =20
> I=E2=80=99ve previously offered reviews and comments, and some of =
those have been addressed in the latest I-D =E2=80=94 others have not, =
but should be. I recall that there was some mail attempting to rebut =
parts of the review, and I will dig it out and reply to that.
> =20
> With that being said, I have reviewed the latest version of the =
document, and full details will be forthcoming. There=E2=80=99re a =
couple of big-ticket/architectural items that I want to address up =
front, as I believe that before we have those hammered out, it will be =
useless to go into details. Note, I do not claim that this is an =
exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D, but that=E2=80=99s =
as far as I have gotten in thinking this through.
> =20
> I also bring these up as they are items that have been brought up =
repeatedly over the past years, but not resolved nor discussed.
> =20
> Loops
> Just to bring this out: I share Chris=E2=80=99 worry about conflicting =
and concurrent statements from the authors on =E2=80=9CThere are no =
loops possible=E2=80=9D and =E2=80=9CWe need to fix two situations where =
loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating some =
loop conditions=E2=80=9D
> =20
> I particularly worry that this is not a discussion had in public, but =
apparently in some other forum=E2=80=A6
> =20
> =20
> Intermediate Route Replies, and all of section 10
> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=80=
=9D, which is incoherent with the intended status indicated for this =
document.=20
> =20
> Specifically, and this is not unrelated to the point about loops =
above, intermediate RREPs (section 10.3) are a potential source for =
loops.
> =20
> Expanding Ring Multicast (section 10.1) is not documented in a way =
that can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=
=E2=80=9D below, it is in the present form of this protocol impossible), =
etc.
> =20
> =20
> Forwarding-vs-regeneration
> Recent exchanges on the list made me understand that protocol control =
messages are *not* forwarded, but are consumed at each hop, then a new =
message with (almost-but-not-quite) the same content is generated and =
transmitted.
> =20
> I have thought some more on this (& read some of the exchanges on the =
list on this topic by Chris, Ulrich, and others), and I am convinced =
that this is not the right way to go, at least for the following =
reasons:
> =20
> =20
>             o          It renders the hop-limit/hop-count fields in =
the RFC5444 message header useless.
>                         This would not be bad if the functionality =
offered by those fields was not useful
>                         =E2=80=94 sadly, it is. For example, for scope =
limited flooding (expanding ring search, and=20
>                         such) which may be of interest, and which =
require hop-limit.=20
>                         A hop-count field may also provide a =
=E2=80=9Ccheap=E2=80=9D (in terms of overhead) additional piece
>                         of information to use conjunctively with a =
=E2=80=9Creal=E2=80=9D metric.
> =20
>                         The only practical solution would be to =
re-introduce these functions by way of inserting a
>                         MessageTLV =E2=80=94 which (i) is not =
specified in this document, and (ii) which would just
>                         serve to render messages bigger than strictly =
needed.
> =20
>                         Scope limited flooding  does seem to be a =
necessary requirement, if for no
>                         other reason than to prevent information from =
=E2=80=9Ccirculating forever in the network=E2=80=9D.
> =20
>             o          It makes end-to-end authentication =
unnecessarily hard.
>                         I think Chris called this out already, but it =
bears repeating: S generates a message=20
>                         (say, a RREQ), and includes an ICV calculated =
over the content of the message.
>                         For any recipient to be able to validate the =
ICV, the message has to be exactly
>                         the same =E2=80=94 not just in content, but in =
structure =E2=80=94 as what was generated.
> =20
>                         =E2=80=9CRegenerating=E2=80=9D rather than =
=E2=80=9Cforwarding=E2=80=9D messages means, that the intermediate
>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ =
may chose a different structure (e.g., include TLVs
>                         in a different order).
> =20
>                         The proposal from =
https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00 =

>                         is to add constraints on (i) the set of =
elements to include in a signature and (ii) the
>                         order of these elements.
> =20
>                         One problem with that approach is (i): if an =
extension adds a message TLV, or an=20
>                         Address TLV, to a message, then that will not =
be =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>                         Rather for *each* extension developed, an =
=E2=80=9Cupdates e2esec=E2=80=9D clause needs to be done.
> =20
>                         I=E2=80=99d say that this approach would be =
prone to errors =E2=80=94 and add entropy to the process
>                         of designing protocol extensions. The =
alternative, a message being generated by the
>                         source and *forwarded* (as we do in OLSRv2, =
for example) would allow ICV TLVs=20
>                         (even, allow reuse of those specified for =
OLSRv2) for covering a message and=20
>                         extensions.
> =20
>                         =E2=80=9CBut what about the metrics value =
which will change on each hop=E2=80=9D, you may say?
>                         Fortunately, that is relatively easy to =
handle: simply zero out the value of that TLV when
>                         generating or verifying the ICV MessageTLV. =
And use Packet-TLVs for hop-by-hop=20
>                         authentication, if needed (but, see below).
> =20
>             o          It prevents the use of more clever/advanced =
signature schemes/ICVs
>                         Aggregate signature algorithms ( =
https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf =
)
>                         exist, and an interesting use-case can be =
found in also reactive protocols, allowing verifying
>                         not =E2=80=9Cjust=E2=80=9D the end points, but =
also the intermediaries (again, with the appropriate =E2=80=9Czero =
out=E2=80=9D
>                         discussed above, or something smarter).
>                         Regeneration of messages, rather than =
forwarding, renders that impossible (or, if used,
>                         updating to  =
https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00 =
)
> =20
> There are other reasons, but the above are those that jump at me as =
immediate show-stoppers.
> =20
> I do honestly not see what possible benefit there is from =
=E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear =
inconveniences, and security is not the least of these. Insisting on =
=E2=80=9Cregeneration=E2=80=9D requires development of =E2=80=9Cnon-genera=
l workarounds=E2=80=9D as pointed out above.
> =20
> Security Considerations
> This is an always thorny subject. When OLSRv2 was going through the =
process we got a thorough education in how little we knew about security =
from the SEC-ADs, and had to spend about a year or so developing =
RFC7183. The bottom line is, that this protocol needs its =E2=80=9CRFC7183=
  equivalent=E2=80=9D, either as part of the main document, or as an =
independent document. currently, that is not the case.
> =20
> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration =
from RFC7183 might be aw good idea, as that was the most recent that =
went through the SEC AD. Regardless of how, however, a =E2=80=9Cmandatory =
to implement=E2=80=9D security mechanism most be specified (I think the =
right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D), in =
sufficient detail to ensure interoperable implementations.
> =20
> As an example, both [RFC6130] and [RFC7181] set out that that:
> =20
>       On receiving a ... message, a router MUST first check if the
>       message is invalid for processing by this router
> =20
> and then proceed to give a number of conditions that, each, will lead =
to a rejection of the message as "badly formed and therefore invalid for =
processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That =
gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting =E2=80=9Crejection=
=E2=80=9D. Idem for message generation.
> =20
> If I was to do RFC7181/RFC6130 today, I would include that directly =
into the protocol specifications. It turned out to be more overhead (and =
slow down publication anyways) to do it as separate documents.
> =20
> Secondly, we need to be a lot more rigid in terms of what ICVs, =
Timestamps, etc. are added/removed, and what that brings.
> =20
> For example (with the assumption that messages are *forwarded* and =
*not* regenerated), this could be one option:
> =20
>                         o          When a RREQ, RREP message is =
generated, add an ICV Message TLV, which is calculated 
>                                      =E2=80=A6(take inspiration from =
RFC7183 here)
> =20
> ...
>=20
> [Message clipped] =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
> ********************************************************************
> 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
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


--Apple-Mail=_FDF25E9C-11FF-4824-B200-F0518054F194
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi,

I =
must admit that while I have reviewed the protocol several times, I=E2=80=99=
ve not been digging that deep into the protocol functioning to catch =
this issue of how invasive the protocol operations are when forwarding a =
message: there were other =E2=80=9Cmajor=E2=80=9D issues to address (and =
which obscured the details), so as a first order: thank you Victoria, =
for having called attention to this.

To the substance of these =
emails.

I am =
afraid that I do not understand the use of inserting validity TLVs while =
in-flight, into a message. Actually, I am dubious for both the =
originator inserting this (how can the originator of a message know how =
=E2=80=9Clatter parts of the path=E2=80=9D will be have=E2=80=9D) except =
if we are talking duty-cycling of devices and inserting =E2=80=9Cthe =
remaining time that I am going to be up before I suspend=E2=80=9D. =
Intuitively, that would also assume fairly long duty cycles =E2=80=9CI =
am up for tens of seconds=E2=80=9D, which I am not sure are actually =
realistic. And, as Chris says in another email, this is trading off =
=E2=80=9Cthe ability to do security=E2=80=9D for an unknown/untested =
feature =E2=80=94 which I think is the wrong trade-off.

On he topic of =
=E2=80=9Cneeding to put an address in=E2=80=9D for RREP-ACK, I must =
admit that this seems roundabout. I can see three issues here:

	o	I am not =
sure that adding an address vs. a flag may not have to do with the =
=E2=80=9Cmultiple interfaces/
		=
multiple addresses=E2=80=9D discrimination mechanics of the =
protocol? I haven=E2=80=99t worked it through, though, 
		=
but that would be a guess.

	o	The end-to-end topology diffusion =
mechanism should not need to be concerned with the 
		=
=E2=80=9Cbidirectionally check=E2=80=9D of a local link (in part, =
as it encumbers security, but not only).  In short, a
		=
flag or an address, both are (equally) bad.

	o	A cleaner =
mechanism would be a =E2=80=9Chello mechanism=E2=80=9D, not necessarily =
as NHDP, but a =E2=80=9Cwhen 
		=
forwarding a RREQ/RREP, trigger a 3-way hello exchange, if the =
link is estimated to be of a 
		=
type which potentially can be unidirectional=E2=80=9D. There =
is another benefit to doing that, see the end 
		=
of this email.

Either way, I do not like the notion of fusing =
metrics-and-link-bidirectionality-detection any more than I like fusing =
global-topology-diffusion-and-link-bidirectionality-detection. 
=


The solution all =
this is, to me, threefold

	=
1)	=
Factor out the bidirectionally check in a (triggered) neighbour =
detection mechanism 
		=
(triggered HELLO message)

	2)	Remove the =E2=80=9Cvalidity time =
TLVs=E2=80=9D, since they add complexity for no perceivable =
benefits

	3)	Use the =
security model that we=E2=80=99ve discussed previously, where (only) the =
metrics change per hop.

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 related 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 this
   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 conclusion 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 link the metrics is 4 or 5=E2=80=9D, the protocol must be able to =
convey and distinguish 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.

Hope =
this helps,


Thomas

 
***************************************************************=
*****
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
=

--Apple-Mail=_FDF25E9C-11FF-4824-B200-F0518054F194--


From nobody Mon Apr 25 07:20: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 872DE12D5E0 for ; Mon, 25 Apr 2016 07:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.393
X-Spam-Level: 
X-Spam-Status: No, score=-1.393 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, TRACKER_ID=1.306] 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 3dSFrAqO6v4c for ; Mon, 25 Apr 2016 07:20:21 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 F086112D5DF for ; Mon, 25 Apr 2016 07:20:20 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id g133so186708302ywb.2 for ; Mon, 25 Apr 2016 07:20:20 -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=gEIxmBtq/LX6GLRiO6FrQHYaQRdEHDcj1zG+Ze3RZDU=; b=UM+CxwS69wyK6AASI2XZ7kbgKoe23+kIA1OO/c+vo7YyM0yIYCtQ1IhuapHu3Ne7cR ovU8fYRYJoEcNMPXkRuCl2qvvxol4I7JpO7c2rUgdaTj13fZllBcIaWofdlMrreit78M X8yMS9bLc0la+78sZrCg1LpvGfQLjXM9b1glsL6nknyA+QGVcH7DOeyQ53mgrSRWJ5PO 4khKp1nSVyk5omJvm6FZm38MKSIsTEUtXJF9oSgTuew0ZcD4S95uJoU08V7DQ8Y2k+3N 7LNHk3fSbt1cs6dlwKdqUoRvwioIeQF032ZRanpcSzQX6f8TAfAqZlVl5ZSLRwnxhG0b /mog==
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=gEIxmBtq/LX6GLRiO6FrQHYaQRdEHDcj1zG+Ze3RZDU=; b=TLy1hFivcz9mkHBy8xuD6jAorn4fPlqJV6PdEZz9/SJa39qCK62Lgu10pF+7kKahw7 ccJ81AQVIjdb9pWCvpqVlM66rkYCnpkeplVV0VYcWwwoOAK4lqFakv8o1Z1KZyTzspIo kk/mvYD7RQc39pZi0vVOShnD3BEVSCwZDMVRndQp41bpdcQUYNrCQKma+PjxTDyfbM0h 7KL6vRsX35VvF1c8fCX7PxFNUtGfGpWSOa7Ecmzi4kBInpgKeB4JZRl75cbsFhy/OHaW vf6XM70GkEfBCPTKKtB2cFcNiC8jGVhhLyIMnwXDAt+vdeh6MFESERVrozfK6FJDJM9V Iz3g==
X-Gm-Message-State: AOPr4FW+PnLU6J0l316q1LdIRpPRc/ydg82f6rQnGoG3cqxKylgjQghy0CiRjNjR2lio2zaKZLaFJLU5g91gww==
MIME-Version: 1.0
X-Received: by 10.159.33.4 with SMTP id 4mr7620452uab.155.1461594019905; Mon, 25 Apr 2016 07:20:19 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Mon, 25 Apr 2016 07:20:19 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>       
Date: Mon, 25 Apr 2016 10:20:19 -0400
Message-ID: 
From: Justin Dean 
To: "Dearlove, Christopher (UK)" 
Content-Type: multipart/alternative; boundary=94eb2c0b66e65cedad05314fe050
Archived-At: 
Cc: Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 14:20:26 -0000

--94eb2c0b66e65cedad05314fe050
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

A thought regarding integrity checking.  A possible future "fix" for
integrity could be done on a "virtual" packet in which known TLVs/values
along with ordered addresses are uncompressed and then verified.  It could
allow extra TLV tagging without modifying the validity of that data.  The
very big drawback would be the overhead of having to uncompressed
everything to check the validity.  It's functionally the same as zeroing
out local (this is my stuff) TLV data vs remote (this is not my stuff) TLV
data.

As for the RREP-Ack having a flag vs an address doesn't much bother me as
either would have to be zeroed out for this type of future integrity
checking.

Justin

On Mon, Apr 25, 2016 at 9:27 AM, Dearlove, Christopher (UK) <
chris.dearlove@baesystems.com> wrote:

> Assuming for the moment that everyone will need an RREP-Ack or won=E2=80=
=99t
> (let=E2=80=99s come back to that) why do C and B need to put an address i=
n as an
> RREQ-Ack request? Why not a flag, because the address will be included as
> the IP sending address - and we know 5444 is required to pass that on.
> (It=E2=80=99s used by NHDP as well.) Then we don=E2=80=99t need to change=
 the RREP, it will
> have a flag set or not, and won=E2=80=99t change (in this regard).
>
>
>
> Now let=E2=80=99s consider do we know whether we can set a fixed flag. Fi=
rst I=E2=80=99d
> say there are two cases - you=E2=80=99ve got a firm control on what=E2=80=
=99s going on in
> your network, or it=E2=80=99s one of unknown parties and behaviour (consi=
stent with
> specification). In the former case you only want one setting, for example
> no-Ack if running NHDP or your MAC layer tells you about bidirectionality=
,
> Ack otherwise. In the latter case, I think you just always want an Ack. S=
o
> both cases get you to the same place.
>
>
>
> Should that not be an acceptable argument (though I think it=E2=80=99s go=
od for
> where we are - in fact always Ack is close) then at flag is a step better=
,
> it=E2=80=99s a fixed location to change. However it would be better in th=
at case if
> the two things to change (metric and ack flag) were together. But that ha=
s
> its own issues, so I won=E2=80=99t go there.
>
>
>
> *-- *
>
>
>
>
> *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
> *Sent:* 25 April 2016 14:15
> *To:* Jiazi YI
> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
> Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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
> .*
>
> Hi Jiazi,
>
>
>
>
> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI  wrote:
>
> Hi,
>
>
>
> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
> With regard to your validity time point, we here have a tradeoff. If you
> allow that feature, it significantly impacts on the approach that was
> coming together on as best you can end to end encryption.
>
>
>
> So the question is, is this a feature that=E2=80=99s really wanted? Unfor=
tunately
> I think we know that the answer to that is, we don=E2=80=99t know because=
 we don=E2=80=99t
> have any experience. My view would be that in the tradeoff of an untested
> feature (unless I=E2=80=99m wrong about that) and the security complicati=
on,
> security wins and drop the feature. If there is some real requirement, th=
en
> there=E2=80=99s a discussion. (Questions like how often the intermediate =
routers
> actually have any knowledge - typically links break for unexpected rather
> than expected reasons. Andan intermediate router could possibly use a
> validity time to influence its behaviour.) Note that dropping the ability
> of intermediate routers to modify/set still allows validity times per rou=
te
> to be set at endpoints.
>
>
>
> I agree with Chris' concern.
>
> The ValidityTime is optional, which makes the integrity protection hard.
> Furthermore, it gives a potential attack vector: as all the routers in a
> path will take the shortest validityTime, a compromised router can set th=
e
> the validityTime to a very short value, which will make the route install=
ed
> along the path became invalid (very soon).
>
>
>
> On the other hand, I'm not sure this option will give us much help. Chris
> mentioned much knowledge intermediate router would have to decide this
> value (and how much sense the value would make).
>
> Another issue is, a route to a destination might be updated by different
> sources. For example, in the network below:
>
>
>
> A----B-----C
>
>
>
> A first establish a route to B with long validity time. Then A initiates =
a
> route discovery to C. C tends to set a short validity time, which will ma=
ke
> the route between B and A expire earlier than expected.
>
> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered or
> not.
>
>
>
>
>
> Not sure I follow here.
>
> Currently, the validity time of the route between A and B would not
> affected by a short validity time of a route between A and C. Validity
> times are per-route, and the route A-B and the route A-C are separate.
>
> If we switched to a validity time per neighbor (so that we can keep
> validity time separate from route advertisements) as I mentioned in the
> email below, then the validity of a route between A and C would be affect=
ed
> if there was a short validity time between A and B. But, if B will only
> route for a certain amount of time, then the route between A and C will o=
f
> course be affected. Is it best to know in advance that there's a time
> limit, or just deal with RERRs when they happen?
>
>
>
>
>
>
>
> With regard to the acknowledgements, the problem (with regard to security=
)
> comes from trying to do two jobs with the same message - end to end route
> advertisement and hop by hop acknowledgement. I understand the reasons -
> saving bytes and message types. (I would have to study the protocol reall=
y
> hard to identify if any message types can be folded together and recognis=
ed
> by content rather than type efficiently. This I do not expect to do.) Aga=
in
> a tradeoff. This one is in discussion space, though that needs people who
> understand both sides of the issue, including the details of the
> bidirectionality mechanism. Of course, as has been said, we need one of
> those.
>
>
>
> I haven't finished my review of the latest draft, and I don't get the
> necessity of AckReq and the corresponding multicast RREP yet.
>
> If possible, this "optional" field should be avoided.
>
>
>
>
> To give an overview of AckReq and RREP:
>
> Since AODVv2 requires bidirectional links, this is the way to determine i=
f
> a link is bidirectional.
>
> A----B----C
>
>
> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install
> a route to OrigAddr but they dont yet know if it's valid because they don=
t
> know if the link to their next hop is available in the reverse direction.
>
> 2) C creates the RREP. Since it doesnt know if the link to B is
> bidirectional, it includes the AckReq (an address to indicate that it
> expects to receive a RREP_Ack from B).
>
> 3) B receives the RREP, installs a route to TargAddr and marks it as
> valid, since it knows the link to C is bidirectional, because the RREQ we=
nt
> in one direction and the RREP came in the other. B also sends the RREP_Ac=
k
> to C and forwards the RREP to A (and might change the message to indicate
> its own AckReq - ie that it requires an ack from A).
>
> 4) C receives the RREP_Ack from B, and therefore knows that B received th=
e
> RREP, therefore the link is bidirectional. C can then mark its route to
> OrigAddr as valid.
>
> 5) Similarly, A receives the RREP, installs the route to TargAddr and
> sends an RREP_Ack to B.
>
> 6) B receives the RREP_Ack and marks its route to OrigAddr as valid.
>
>
>
> Alternatively, in step 2, if C knows the link to B is bidirectional
> (perhaps from some earlier route discovery), it doesnt need to put the
> AckReq in the RREP. Then in step 3, since B doesnt know if the link to A =
is
> bidirectional, it changes the message to add the AckReq address, in order
> to get an RREP_Ack from A.
>
> If we want to avoid changing the message, we'll need to look at forwardin=
g
> the RREP as-is, and creating a second message to solicit an RREP_Ack, in
> order to verify that the link is bidirectional before marking the route t=
o
> OrigAddr as valid.
>
> Kind regards,
>
> Victoria.
>
>
>
>
>
> 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
>
>
>
> *From:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
> *Sent:* 23 April 2016 10:55
> *To:* Christopher Dearlove
> *Cc:* ietf@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc
> Networks mailing list
>
>
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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
> .*
>
> Hi Chris,
>
>
>
> These have both been in the draft in some form since before I got
> involved... but I'll do my best to explain.
>
>
>
> - For Validity Time, its a way to advertise that you would only support
> the route contained in the message for a certain period of time. The
> originator might use this, but the draft was written to allow any
> intermediate node to be able to add it or update it too. The route create=
d
> in the Local Route Set has an expiration time associated with it, based o=
n
> the received validity time.
>
> - For the AckReq address, its so that you can add into a RREP a request
> for an acknowledgement, so that you don't have to have a different messag=
e
> type altogether for working out whether links to neighbors are
> bidirectional, and also, since you only care about bidirectionality on
> routes that are being set up, you dont need to constantly monitor all
> neighbors.
>
>
>
>
>
> In order to avoid the potential AckReq-related changes to each message,
> maybe we do need to introduce a different message specifically for this. =
We
> could maybe use RREP_Ack to both request and acknowledge? It means an ext=
ra
> message of control traffic that needs to be sent, maybe one extra message
> per hop on the path of a RREP, but it could still be limited to neighbors
> which have participated in the route discovery rather than monitoring all
> neighbors at all times.
>
>
>
> This message could maybe also include "I'm happy to route anywhere for a
> certain amount of time", sort of like willingness in OLSR/OLSRv2. So
> instead of having a validity time per route, its a validity time per
> neighbor. Then, for RREQ and RREP, only the metric value would change in
> transit, as discussed. However, that leads to some issues with deciding
> what a route's expiration time is. You might know how long the next hop
> router is valid for, but what if a router beyond that, which was also par=
t
> of the route, had a lower validity time? You couldn't determine the real
> validity time. Do we remove the route expiration time altogether to avoid
> this issue? In which case, we would have to rely on RERR messages being
> sent for routes which become invalid when the neighbor's validity time ha=
s
> expired? So neighbor validity time expiration is treated the same as a li=
nk
> break.
>
>
>
> What do you think?
>
>
>
> Kind regards,
>
> Victoria.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
> chris@mnemosyne.demon.co.uk> wrote:
>
> Pretty much all of the discussion has been assuming only a metric value
> change. With multiple things changing many of the ideas go out of the
> window. That reinforces the point about not making specifications now tha=
t
> might turn out to be wrong for ICVs.
>
>
>
> Ignoring how this misunderstanding happened, I'll start by asking why.
> Metric changing I understand. Why the other two? (there's a partial
> explanation of one). What alternatives have people implemented in
> comparable protocols?
>
> --
>
> Christopher Dearlove
>
> christopher.dearlove@gmail.com (iPhone)
>
> chris@mnemosyne.demon.co.uk (home)
>
>
> On 23 Apr 2016, at 00:26, Victoria Mercieca  wrote:
>
> Hi all,
>
>
>
> Continued in this thread because the other one seems to be more about TLV
> types and metric type numbers, whereas this is about
> regeneration/forwarding.
>
>
>
> To recap, in the current draft, there are 3 things that might change at
> each hop:
> - the metric value (happens in RREQ and RREP),
> - adding/changing Validity Time using the Validity Time TLV (can happen i=
n
> RREQ and RREP),
> - adding an address (and corresponding value in the AddressType TLV to
> indicate how to interpret the address) to indicate the address from which
> an RREP_Ack is expected, to accomplish the bidirectionality check (can
> happen in RREP).
>
> If we define a certain portion of the message as immutable and include th=
e
> ICV to verify that part, end to end:
> - The metric value would be excluded from the ICV since it needs changing
> at each hop.
> - Would adding a Validity Time TLV at an intermediate hop be acceptable?
> The whole TLV could be removed in order to calculate the ICV?
>
> - Would adding an address cause issues for the ICV, because it's in the
> address block? Could the rule be "if it contains an AckReq address, remov=
e
> it (and the corresponding value in the AddressType TLV), before checking
> the ICV", is that OK? Or would we need to avoid touching the ICV'ed part =
of
> the message altogether, maybe put the AckReq address in a separate Addres=
s
> Block, with an extra AddressType TLV following that address block? Is the=
re
> a way to accomplish this?
>
>
>
> Also, to be thorough, do we need to consider RERR messages while we
> discuss regeneration vs forwarding?
>
> - RERR (sent when a link breaks) is a way of saying "I've lost my route s=
o
> I'm telling others" and "you were my next hop, so now I've also lost my
> route, I'll tell others", etc. It's going to be tailored at each step to
> include the relevant routes that got deleted, it's not one message being
> sent end-to-end like RREQ and RREP are.
>
> - However, RERR (sent when a source of traffic is sending data on a route
> which comes through you, and you want to tell the Packet Source's router =
to
> delete the route) could be seen as an end-to-end message which all
> intermediate routers learn from, similar to RREQ and RREP. It reports one
> route, and doesn't need changing at intermediate hops, so could be
> protected with ICV.
>
> - Would it be OK to only require a message ICV if a PktSource address was
> included, i.e. when the message needs to go via a number of intermediate
> hops to PktSource's router? All other RERRs are intended to be one-hop
> messages, which may in turn prompt other one-hop messages, etc..., and a
> packet ICV might be more appropriate?
>
>
>
> Kind regards,
>
> Victoria.
>
>
>
> On Thu, Mar 17, 2016 at 5:26 PM,  wrote:
>
>
>
> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>
>
> Yes, I meant AODVv2, thanks for the catch.
>
>
>
> So is your (Thomas) proposed base specification a hop count only metric?
>
>
>
> No, the would be silly as base specification, given that hop count mostly
> is useless.
>
>
>
> As base specification I would simply say =E2=80=9CInclude a Metric Type M=
essage
> TLV with a value field, and a 7182 Message TLV & Timestamp=E2=80=9D as we=
 do in
> OLSRv2 (with the appropriate verbiage as to generation and processing).
>
>
>
> With the message generated by the originator of the RREQ/RREP and *not*
> deconstructed/reconstructed/reordered (as is the risk with =E2=80=9Cregen=
eration)
> allows knowing that it would be *only* that metric field being modified
> (other than hop count/limit) for when eventually writing up the extension=
.
>
>
>
> (Actually doesn=E2=80=99t the current specification only define hop count=
, or has
> that changed in latest draft?)
>
>
>
> No. That is one of the issues I raise in my original. For some reason, it
> cites RFC6551, which is a ROLL document and which has in its abstract tha=
t:
>
>
>
>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>
>    compared with traditional wired and ad hoc networks that require the
>
>    specification of new routing metrics and constraints.
>
>
>
> I.e. this document cites a metric document which clearly claims to be
> inapplicable in ad hoc networks. I note that this is another thing I=E2=
=80=99ve
> raised for years without seeing it attempted resolved.
>
>
>
> Best,
>
>
>
> Thomas
>
>
>
>
>
>
>
> *--*
>
>
>
>
> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
> ]
> *Sent:* 17 March 2016 17:10
> *To:* Dearlove, Christopher (UK)
> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>
>
> OK, so we have a message that mutates by:
>
> - Modifying hop count/limit.
>
> - Modifying a metric value.
>
> Anything else?
>
>
>
> As mutating (other than hop count/limit) messages aren=E2=80=99t covered =
by 5444
> or any derivative document (but only recommended against, not banned) tha=
t
> you may need to make the message otherwise immutable (no deconstruction a=
nd
> rebuilding, other than guaranteed unchanging) that would have to be
> specified by AODVv2. (Easy to say, but needs saying.)
>
>
>
> With you so far.
>
>
>
> Then that information is not in a guaranteed fixed location given by a
> simple offset. So any signature algorithm that finds it and ignores it or
> aggregates on it is specific to OLSRv2.
>
>
>
> Surely you mean AODVv2
>
>
>
> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AODVv2
> specialised variant. Which is the sort of thing that the message specific
> TLV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cbut ig=
nore the value of
> this specific TLV should it occur=E2=80=9D being in the general space. Ho=
wever it
> can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like tha=
t TLV,
> except if an X TLV is present, set its value field to zero=E2=80=9D).
>
>
>
> Messy, but could work.
>
>
>
> Not that messy, actually, although clearly not as nice as =E2=80=9Cfixed =
offset=E2=80=9D.
>
>
>
> That said, I am arguing for the base spec being:
>
>
>
>             =E2=80=9Cmake the message otherwise immutable (no deconstruct=
ion and
> rebuilding, other
>
>              than guaranteed unchanging)=E2=80=9D which is afforded by fo=
rwarding
>
>
>
>                                     +
>
>
>
>             RFC7182 Timestamps and ICVs.
>
>
>
>                                     +
>
>
>
>             RFC7183 style text bringing it all together.
>
>
>
> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would ve=
ry be an
> experimental extension.
>
>
>
> What I object to is, if the base spec specifically renders such extension=
s
> impossible
>
>
>
>
>
>
>
> *--*
>
>
>
>
> *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:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
> ]
> *Sent:* 17 March 2016 16:48
> *To:* Dearlove, Christopher (UK)
> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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
> .*
>
> Hi all,
>
>
>
> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com>:
>
>
>
> Good point about whether you just pass on one cost or a set of costs. As =
I
> said, not looked at details - I will, when time permits. One cost is much
> easier, and yes, it reduces the fixed size aggregated signatures problem =
to
> =E2=80=9Cjust=E2=80=9D one of computational load.
>
>
>
> For the record, Thomas=E2=80=99 understanding is correct; the cost is one
> aggregated value.
>
>
>
> Best regards,
>
> Lotte Steenrbink
>
>
>
>
>
> *--*
>
>
>
>
> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
> ]
> *Sent:* 17 March 2016 16:38
> *To:* Dearlove, Christopher (UK)
> *Cc:* Mobile Ad Hoc Networks mailing list
> *Subject:* Re: Message integrity and message mutability (was RE: [manet]
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>
>
> I appreciate Thomas=E2=80=99s comments about the limitations of message
> regeneration, but I would be a bit less absolute.
>
>
>
> The issues over end to end authentication and more advanced signatures ar=
e
> valid. I need to read the given reference on aggregate signatures to
> increase my knowledge (thanks for it), but my understanding of the
> possibilities in this field may offer a solution to the problem, but with
> some other issues (possibly including a new type of TLV).
>
>
>
> But the hop count/limit point I don=E2=80=99t fully agree with, you can r=
egenerate
> with an incremented/decremented count/limit, which leaves the ability to
> prevent messages propagating indefinitely, including expanding ring
> searches, and retains the ability to use RFC 5497 interval and validity
> times that might be useful with an expanding ring search (or might not).
>
>
>
> But the key issue is that AODVv2 wants to accumulate metrics. I still
> haven=E2=80=99t got to the bottom of many details here, but let=E2=80=99s=
 for the moment
> just consider that conceptually.
>
>
>
> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft attempts =
to do an end to
> end of some information, not this information. I=E2=80=99m not sure if th=
at=E2=80=99s
> useful (and the specialised format is better avoided if possible). Other
> approaches are hop by hop (might as well use packet signatures) and share=
d
> key (might as well go hop by hop). Pairwise signatures for each pair of
> routers I=E2=80=99m discounting as scaling terribly. In the interests of
> completeness let=E2=80=99s mention not accumulating metrics, which puts u=
s back to
> hop count and that=E2=80=99s not ideal either.
>
>
>
> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=80=
=99ve seen about
> aggregating, but that has some issues of its own, even apart from
> computational load.) I=E2=80=99d love to be proved wrong - someone with t=
he perfect
> solution to come along.
>
>
>
> Which means that either we make an arbitrary choice - which will be
> disagreed with, but needs discussing first - or create something flexible=
.
> Unfortunately flexible in that regard constrains in others, e.g. some
> (many? most?) aggregating signatures need fixed data sizes (which we can =
do
> by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but tha=
t has a cost too).
>
>
>
> I have been told by people much more well versed in this than I in
> cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>
>
>
> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does th=
at mean that the
> message grows as it is being forwarded, and that the recipient of a
> RREQ/RREP will know the individual costs of each path segment? My
> understanding is, that the recipient will get =E2=80=9Cthe sum the costs =
of each
> path segment=E2=80=9D which should be fitting within a fixed size?
>
>
>
> Thomas
>
>
>
>
>
>
>
> Sorry, no answers, just comments. And I=E2=80=99m not addressing Thomas=
=E2=80=99s later
> points here.
>
>
>
> *--*
>
>
>
>
> *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 ] *O=
n
> Behalf Of *ietf@thomasclausen.org
> *Sent:* 17 March 2016 16:00
> *To:* Mobile Ad Hoc Networks mailing list
> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of big
> ticket Items
>
>
>
>
>
> **** 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.
>
>
>
> Dear all,
>
>
>
> Apologies for not having gotten this done sooner - day-job leaving few
> spare cycles.
>
>
>
> I=E2=80=99ve previously offered reviews and comments, and some of those h=
ave been
> addressed in the latest I-D =E2=80=94 others have not, but should be. I r=
ecall that
> there was some mail attempting to rebut parts of the review, and I will d=
ig
> it out and reply to that.
>
>
>
> With that being said, I have reviewed the latest version of the document,
> and full details will be forthcoming. There=E2=80=99re a couple of
> big-ticket/architectural items that I want to address up front, as I
> believe that before we have those hammered out, it will be useless to go
> into details. Note, I do not claim that this is an exhaustive list of =E2=
=80=9Cbig
> ticket items=E2=80=9D, but that=E2=80=99s as far as I have gotten in thin=
king this through.
>
>
>
> I also bring these up as they are items that have been brought up
> repeatedly over the past years, but not resolved nor discussed.
>
>
>
> *Loops*
>
> Just to bring this out: I share Chris=E2=80=99 worry about conflicting an=
d
> concurrent statements from the authors on =E2=80=9CThere are no loops pos=
sible=E2=80=9D and
> =E2=80=9CWe need to fix two situations where loops can occur=E2=80=9D and=
 =E2=80=9Cwe are still
> investigating some loop conditions=E2=80=9D
>
>
>
> I particularly worry that this is not a discussion had in public, but
> apparently in some other forum=E2=80=A6
>
>
>
>
>
> *Intermediate Route Replies, and all of section 10*
>
> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=80=
=9D, which is
> incoherent with the intended status indicated for this document.
>
>
>
> Specifically, and this is not unrelated to the point about loops above,
> intermediate RREPs (section 10.3) are a potential source for loops.
>
>
>
> Expanding Ring Multicast (section 10.1) is not documented in a way that
> can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=E2=
=80=9D below, it is
> in the present form of this protocol impossible), etc.
>
>
>
>
>
> *Forwarding-vs-regeneration*
>
> Recent exchanges on the list made me understand that protocol control
> messages are *not* forwarded, but are consumed at each hop, then a new
> message with (almost-but-not-quite) the same content is generated and
> transmitted.
>
>
>
> I have thought some more on this (& read some of the exchanges on the lis=
t
> on this topic by Chris, Ulrich, and others), and I am convinced that this
> is not the right way to go, *at least* for the following reasons:
>
>
>
>
>
>             o          *It renders the hop-limit/hop-count fields in the
> RFC5444 message header useless.*
>
>                         This would not be bad if the functionality offere=
d
> by those fields was not useful
>
>                         =E2=80=94 sadly, it is. For example, for scope li=
mited
> flooding (expanding ring search, and
>
>                         such) which may be of interest, and which require
> hop-limit.
>
>                         A hop-count field may also provide a =E2=80=9Cche=
ap=E2=80=9D (in
> terms of overhead) additional piece
>
>                         of information to use conjunctively with a =E2=80=
=9Creal=E2=80=9D
> metric.
>
>
>
>                         The only practical solution would be to
> re-introduce these functions by way of inserting a
>
>                         MessageTLV =E2=80=94 which (i) is not specified i=
n this
> document, and (ii) which would just
>
>                         serve to render messages bigger than strictly
> needed.
>
>
>
>                         Scope limited flooding  does seem to be a
> necessary requirement, if for no
>
>                         other reason than to prevent information from
> =E2=80=9Ccirculating forever in the network=E2=80=9D.
>
>
>
>             o          *It makes end-to-end authentication unnecessarily
> hard.*
>
>                         I think Chris called this out already, but it
> bears repeating: S generates a message
>
>                         (say, a RREQ), and includes an ICV calculated ove=
r
> the content of the message.
>
>                         For any recipient to be able to validate the ICV,
> the message has to be exactly
>
>                         the same =E2=80=94 not just in content, but in st=
ructure =E2=80=94
> as what was generated.
>
>
>
>                         =E2=80=9CRegenerating=E2=80=9D rather than =E2=80=
=9Cforwarding=E2=80=9D messages
> means, that the intermediate
>
>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ ma=
y chose a
> different structure (e.g., include TLVs
>
>                         in a different order).
>
>
>
>                         The proposal from
> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>
>                         is to add constraints on (i) the set of elements
> to include in a signature and (ii) the
>
>                         order of these elements.
>
>
>
>                         One problem with that approach is (i): if an
> extension adds a message TLV, or an
>
>                         Address TLV, to a message, then that will not be
> =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>
>                         Rather for *each* extension developed, an =E2=80=
=9Cupdates
> e2esec=E2=80=9D clause needs to be done.
>
>
>
>                         I=E2=80=99d say that this approach would be prone=
 to
> errors =E2=80=94 and add entropy to the process
>
>                         of designing protocol extensions. The alternative=
,
> a message being generated by the
>
>                         source and *forwarded* (as we do in OLSRv2, for
> example) would allow ICV TLVs
>
>                         (even, allow reuse of those specified for OLSRv2)
> for covering a message and
>
>                         extensions.
>
>
>
>                         =E2=80=9CBut what about the metrics value which w=
ill
> change on each hop=E2=80=9D, you may say?
>
>                         Fortunately, that is relatively easy to handle:
> simply zero out the value of that TLV when
>
>                         generating or verifying the ICV MessageTLV. And
> use Packet-TLVs for hop-by-hop
>
>                         authentication, if needed (but, see below).
>
>
>
>             o          *It prevents the use of more clever/advanced
> signature schemes/ICVs*
>
>                         Aggregate signature algorithms (
> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>
>                         exist, and an interesting use-case can be found i=
n
> also reactive protocols, allowing verifying
>
>                         not =E2=80=9Cjust=E2=80=9D the end points, but al=
so the
> intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D
>
>                         discussed above, or something smarter).
>
>                         Regeneration of messages, rather than forwarding,
> renders that impossible (or, if used,
>
>                         updating to
> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>
>
>
> There are other reasons, but the above are those that jump at me as
> immediate show-stoppers.
>
>
>
> I do honestly not see what possible benefit there is from =E2=80=9Cregene=
ration=E2=80=9D =E2=80=94
> but I see very clear inconveniences, and security is not the least of
> these. Insisting on =E2=80=9Cregeneration=E2=80=9D requires development o=
f =E2=80=9Cnon-general
> workarounds=E2=80=9D as pointed out above.
>
>
>
> *Security Considerations*
>
> This is an always thorny subject. When OLSRv2 was going through the
> process we got a thorough education in how little we knew about security
> from the SEC-ADs, and had to spend about a year or so developing RFC7183.
> The bottom line is, that this protocol needs its =E2=80=9CRFC7183  equiva=
lent=E2=80=9D,
> either as part of the main document, or as an independent document.
> currently, that is not the case.
>
>
>
> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration from R=
FC7183
> might be aw good idea, as that was the most recent that went through the
> SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to implement=E2=
=80=9D security
> mechanism most be specified (I think the right term was =E2=80=9CMUST imp=
lement,
> SHOULD use=E2=80=9D), in sufficient detail to ensure interoperable implem=
entations.
>
>
>
> As an example, both [RFC6130] and [RFC7181] set out that that:
>
>
>
>       On receiving a ... message, a router MUST first check if the
>
>       message is invalid for processing by this router
>
>
>
> and then proceed to give a number of conditions that, each, will lead to =
a
> rejection of the message as "badly formed and therefore invalid for
> processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That gav=
e a =E2=80=9Chook=E2=80=9D for
> RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message gener=
ation.
>
>
>
> If I was to do RFC7181/RFC6130 today, I would include that directly into
> the protocol specifications. It turned out to be more overhead (and slow
> down publication anyways) to do it as separate documents.
>
>
>
> Secondly, we need to be a lot more rigid in terms of what ICVs,
> Timestamps, etc. are added/removed, and what that brings.
>
>
>
> For example (with the assumption that messages are *forwarded* and *not*
> regenerated), this could be one option:
>
>
>
>                         o          When a RREQ, RREP message is generated=
,
> add an ICV Message TLV, which is calculated 
>
>                                      =E2=80=A6(take inspiration from RFC7=
183 here)
>
>
>
> ...
>
> [Message clipped]
> _______________________________________________
> 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
>
>
>
> ********************************************************************
> 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
>
>

--94eb2c0b66e65cedad05314fe050
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


A thought regarding integrity checking.=C2=A0 A possible f=
uture "fix" for integrity could be done on a "virtual" =
packet in which known TLVs/values along with ordered addresses are uncompre=
ssed and then verified.=C2=A0 It could allow extra TLV tagging without modi=
fying the validity of that data.=C2=A0 The very big drawback would be the o=
verhead of having to uncompressed everything to check the validity.=C2=A0 I=
t's functionally the same as zeroing out local (this is my stuff) TLV d=
ata vs remote (this is not my stuff) TLV data. =C2=A0

As for the RRE=
P-Ack having a flag vs an address doesn't much bother me as either woul=
d have to be zeroed out for this type of future integrity checking.

=
Justin

On Mo=
n, Apr 25, 2016 at 9:27 AM, Dearlove, Christopher (UK) &l=
t;chris.=
dearlove@baesystems.com> wrote:











Assuming for the moment t=
hat everyone will need an RREP-Ack or won=E2=80=99t (let=E2=80=99s come bac=
k to that) why do C and B need to put an address in as an RREQ-Ack request?
 Why not a flag, because the address will be included as the IP sending add=
ress - and we know 5444 is required to pass that on. (It=E2=80=99s used by =
NHDP as well.) Then we don=E2=80=99t need to change the RREP, it will have =
a flag set or not, and won=E2=80=99t change (in this regard).=



=C2=A0


Now let=E2=80=99s conside=
r do we know whether we can set a fixed flag. First I=E2=80=99d say there a=
re two cases - you=E2=80=99ve got a firm control on what=E2=80=99s going on=
 in your network,
 or it=E2=80=99s one of unknown parties and behaviour (consistent with spec=
ification). In the former case you only want one setting, for example no-Ac=
k if running NHDP or your MAC layer tells you about bidirectionality, Ack o=
therwise. In the latter case, I think you
 just always want an Ack. So both cases get you to the same place.


=C2=A0


Should that not be an acc=
eptable argument (though I think it=E2=80=99s good for where we are - in fa=
ct always Ack is close) then at flag is a step better, it=E2=80=99s a fixed
 location to change. However it would be better in that case if the two thi=
ngs to change (metric and ack flag) were together. But that has its own iss=
ues, so I won=E2=80=99t go there.


=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: Victoria Mercieca [mailto:vmercieca0@gmail.com]


Sent: 25 April 2016 14:15

To: Jiazi YI

Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc =
Networks mailing list

Subject: Re: [manet] Message integrity and message mutability (was R=
E: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)=



=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.=









Hi Jiazi,










=C2=A0




On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <ietf@jiaziyi.com> wr=
ote:




Hi,=C2=A0




=C2=A0




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






With regard to your valid=
ity time point, we here have a tradeoff. If you allow that feature, it sign=
ificantly
 impacts on the approach that was coming together on as best you can end to=
 end encryption.


=C2=A0


So the question is, is th=
is a feature that=E2=80=99s really wanted? Unfortunately I think we know th=
at the
 answer to that is, we don=E2=80=99t know because we don=E2=80=99t have any=
 experience. My view would be that in the tradeoff of an untested feature (=
unless I=E2=80=99m wrong about that) and the security complication, securit=
y wins and drop the feature. If there is some real requirement,
 then there=E2=80=99s a discussion. (Questions like how often the intermedi=
ate routers actually have any knowledge - typically links break for unexpec=
ted rather than expected reasons. Andan intermediate router could possibly =
use a validity time to influence its behaviour.)
 Note that dropping the ability of intermediate routers to modify/set still=
 allows validity times per route to be set at endpoints.








=C2=A0






I agree with Chris' concern.






The ValidityTime is optional, which makes the integr=
ity protection hard. Furthermore, it gives a potential attack vector: as al=
l the routers in a path will take the shortest validityTime, a compromised =
router can set the the validityTime
 to a very short value, which will make the route installed along the path =
became invalid (very soon).=C2=A0






=C2=A0






On the other hand, I'm not sure this option will=
 give us much help. Chris mentioned much knowledge intermediate router woul=
d have to decide this value (and how much sense the value would make).=C2=
=A0






Another issue is, a route to a destination might be =
updated by different sources. For example, in the network below:<=
/u>






=C2=A0






=
A----B-----C






=C2=A0






A first establish a route to B with long validity ti=
me. Then A initiates a route discovery to C. C tends to set a short validit=
y time, which will make the route between B and A expire earlier than expec=
ted.=C2=A0






Is this a problem? Maybe yes, maybe no -- I'm no=
t sure it's considered or not.=C2=A0






=C2=A0












=C2=A0






Not sure I follow her=
e.






Currently, the validi=
ty time of the route between A and B would not affected by a short validity=
 time of a route between A and C. Validity times are per-route, and the rou=
te A-B and the route A-C are separate.






If we switched to a validity time per neighbor (so t=
hat we can keep validity time separate from route advertisements) as I ment=
ioned in the email below, then the validity of a route between A and C woul=
d be affected if there was a short
 validity time between A and B. But, if B will only route for a certain amo=
unt of time, then the route between A and C will of course be affected. Is =
it best to know in advance that there's a time limit, or just deal with=
 RERRs when they happen?






=C2=A0<=
/p>





=C2=A0


















=C2=A0


With regard to the acknow=
ledgements, the problem (with regard to security) comes from trying to do
 two jobs with the same message - end to end route advertisement and hop by=
 hop acknowledgement. I understand the reasons - saving bytes and message t=
ypes. (I would have to study the protocol really hard to identify if any me=
ssage types can be folded together
 and recognised by content rather than type efficiently. This I do not expe=
ct to do.) Again a tradeoff. This one is in discussion space, though that n=
eeds people who understand both sides of the issue, including the details o=
f the bidirectionality mechanism.
 Of course, as has been said, we need one of those.









=C2=A0






I haven't finished my review of the latest draft=
, and I don't get the necessity of AckReq and the corresponding multica=
st RREP yet.=C2=A0






If possible, this "optional" field should =
be avoided.=C2=A0






=C2=A0
















To give an overview of AckReq and RREP:






Since AODVv2 requires=
 bidirectional links, this is the way to determine if a link is bidirection=
al.






A----B----C








1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install a=
 route to OrigAddr but they dont yet know if it's valid because they do=
nt know if the link to their next hop is available in the reverse direction=
.






2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).






3) B receives the RREP, installs a route to TargAddr=
 and marks it as valid, since it knows the link to C is bidirectional, beca=
use the RREQ went in one direction and the RREP came in the other. B also s=
ends the RREP_Ack to C and forwards
 the RREP to A (and might change the message to indicate its own AckReq - i=
e that it requires an ack from A).






4) C receives the RREP_Ack from B, and therefore kno=
ws that B received the RREP, therefore the link is bidirectional. C can the=
n mark its route to OrigAddr as valid.






5) Similarly, A receives the RREP, installs the rout=
e to TargAddr and sends an RREP_Ack to B.






6) B receives the RREP_Ack and marks its route to Or=
igAddr as valid.






=C2=A0






Alternatively, in ste=
p 2, if C knows the link to B is bidirectional (perhaps from some earlier r=
oute discovery), it doesnt need to put the AckReq in the RREP. Then in step=
 3, since B doesnt know if the link
 to A is bidirectional, it changes the message to add the AckReq address, i=
n order to get an RREP_Ack from A.






If we want to avoid c=
hanging the message, we'll need to look at forwarding the RREP as-is, a=
nd creating a second message to solicit an RREP_Ack, in order to verify tha=
t the link is bidirectional before marking
 the route to OrigAddr as valid. 






Kind regards,






Victoria.






=C2=A0<=
/p>





=C2=A0














regards






=C2=A0






Jiazi






=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: Victoria
 Mercieca [mailto:vmercieca0@gmail.com]


Sent: 23 April 2016 10:55

To: Christopher Dearlove

Cc: ietf=
@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc Networks =
mailing list








Subject: Re: [manet] Message integrity and message mutability (was R=
E: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)=











=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.








Hi Chris,




=C2=A0






These have both been in the draft in some form since=
 before I got involved... but I'll do my best to explain.=





=C2=A0






- For Validity Time, its a way to advertise that you=
 would only support the route contained in the message for a certain period=
 of time. The originator might use this, but the draft
 was written to allow any intermediate node to be able to add it or update =
it too. The route created in the Local Route Set has an expiration time ass=
ociated with it, based on the received validity time.






- For the AckReq address, its so that you can add in=
to a RREP a request for an acknowledgement, so that you don't have to h=
ave a different message type altogether for working out
 whether links to neighbors are bidirectional, and also, since you only car=
e about bidirectionality on routes that are being set up, you dont need to =
constantly monitor all neighbors.






=C2=A0






=C2=A0






In order to avoid the potential AckReq-related chang=
es to each message, maybe we do need to introduce a different message speci=
fically for this. We could maybe use RREP_Ack to both
 request and acknowledge? It means an extra message of control traffic that=
 needs to be sent, maybe one extra message per hop on the path of a RREP, b=
ut it could still be limited to neighbors which have participated in the ro=
ute discovery rather than monitoring
 all neighbors at all times.=C2=A0






=C2=A0






This message could maybe also include "I'm =
happy to route anywhere for a certain amount of time", sort of like wi=
llingness in OLSR/OLSRv2. So instead of having a validity time per
 route, its a validity time per neighbor. Then, for RREQ and RREP, only the=
 metric value would change in transit, as discussed. However, that leads to=
 some issues with deciding what a route's expiration time is. You might=
 know how long the next hop router is
 valid for, but what if a router beyond that, which was also part of the ro=
ute, had a lower validity time? You couldn't determine the real validit=
y time. Do we remove the route expiration time altogether to avoid this iss=
ue? In which case, we would have to
 rely on RERR messages being sent for routes which become invalid when the =
neighbor's validity time has expired? So neighbor validity time expirat=
ion is treated the same as a link break.






=C2=A0






What do you think?






=C2=A0






Kind regards,






Victoria.






=C2=A0






=C2=A0






=C2=A0






=C2=A0






=C2=A0








=C2=A0




On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlov=
e <chri=
s@mnemosyne.demon.co.uk> wrote:






Pretty much all of the discussion has been assuming =
only a metric value change. With multiple things changing many of the ideas=
 go out of the window. That reinforces the point about
 not making specifications now that might turn out to be wrong for ICVs.=







=C2=A0






Ignoring how this misunderstanding happened, I'l=
l start by asking why. Metric changing I understand. Why the other two? (th=
ere's a partial explanation of one). What alternatives
 have people implemented in comparable protocols?



-- =C2=A0




Christopher Dearlove












On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmail.com> wrote:
















Hi all,






=C2=A0






Continued in this thread because the other one seems=
 to be more about TLV types and metric type numbers, whereas this is about =
regeneration/forwarding.






=C2=A0






To recap, in the current draft, there are 3 things t=
hat might change at each hop:


- the metric value (happens in RREQ and RREP), 

- adding/changing Validity Time using the Validity Time TLV (can happen in =
RREQ and RREP),


- adding an address (and corresponding value in the AddressType TLV to indi=
cate how to interpret the address) to indicate the address from which an RR=
EP_Ack is expected, to accomplish the bidirectionality check (can happen in=
 RREP).



If we define=C2=A0a certain portion of the message as immutable and include=
 the ICV to verify that part, end to end:


- The metric value would be excluded from the ICV since it needs changing a=
t each hop.=C2=A0

- Would adding a Validity Time TLV at an intermediate hop be acceptable? Th=
e whole TLV could be removed in order to calculate the ICV?



- Would adding an address cause issues for the ICV, =
because it's in the address block? Could the rule be "if it contai=
ns an AckReq address, remove it (and the corresponding value
 in the AddressType TLV), before checking the ICV", is that OK? Or wou=
ld we need to avoid touching the ICV'ed part of the message altogether,=
 maybe put the AckReq address in a separate Address Block, with an extra Ad=
dressType TLV following that address block?
 Is there a way to accomplish this?






=C2=A0






Also, to be thorough, do we need to consider RERR me=
ssages while we discuss regeneration vs forwarding?=C2=A0






- RERR (sent when a link breaks) is a way of saying =
"I've lost my route so I'm telling others" and "you =
were my next hop, so=C2=A0now=C2=A0I've also lost my route, I'll te=
ll others", etc.
 It's going to be tailored at each step to include the relevant routes =
that got deleted, it's not one message being sent end-to-end like RREQ =
and RREP are.=C2=A0






- However, RERR (sent when a source of traffic is se=
nding data on a route which comes through you, and you want to tell the Pac=
ket Source's router to delete the route) could be
 seen as an end-to-end message which all intermediate routers learn from, s=
imilar to RREQ and RREP. It reports one route, and doesn't need changin=
g at intermediate hops, so could be protected with ICV.






- Would it be OK to only require a message ICV if a =
PktSource address was included, i.e. when the message needs to go via a num=
ber of intermediate hops to PktSource's router? All
 other RERRs are intended to be one-hop messages, which may in turn prompt =
other one-hop messages, etc..., and a packet ICV might be more appropriate?=







=C2=A0




Kind regards,




Victoria.






=C2=A0




On Thu, Mar 17, 2016 at 5:26 PM, <ietf@thomasclausen.org>=
 wrote:




=C2=A0








On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK)=
 <chr=
is.dearlove@baesystems.com> wrote:




=C2=A0








Yes, I meant AODVv2, than=
ks for the catch.






=C2=A0






So is your (Thomas) propo=
sed base specification a hop count only metric?












=C2=A0




No, the would be silly as base specification, given =
that hop count mostly is useless.






=C2=A0






As base specification I would simply say =E2=80=9CIn=
clude a Metric Type Message TLV with a value field, and a 7182 Message TLV =
& Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage
 as to generation and processing).=C2=A0






=C2=A0






With the message generated by the originator of the =
RREQ/RREP and *not* deconstructed/reconstructed/reordered (as is the risk w=
ith =E2=80=9Cregeneration) allows knowing that it would be
 *only* that metric field being modified (other than hop count/limit) for w=
hen eventually writing up the extension.






=C2=A0












(Actually doesn=E2=80=99t=
 the current specification only define hop count, or has that changed in la=
test
 draft?)










=C2=A0




No. That is one of the issues I raise in my original=
. For some reason, it cites RFC6551, which is a ROLL document and which has=
 in its abstract that:






=C2=A0






=C2=A0=C2=A0 Low-Power and Lossy Networks (LLNs) have unique character=
istics


=C2=A0=C2=A0 compared with traditional wired and ad hoc networks that =
require the


=C2=A0=C2=A0 specification of new routing metrics and constraints. =





=C2=A0






I.e. this document cites a metric document which cle=
arly claims to be inapplicable in ad hoc networks. I note that this is anot=
her thing I=E2=80=99ve raised for years without seeing it
 attempted resolved.






=C2=A0






Best,






=C2=A0






Thomas






=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:=C2=A0chris.dearlove@baesystem=
s.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:=C2=A0ietf@thomasclausen.org=
=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 17:10

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Lotte Steenbrink; Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)










=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.








=C2=A0












On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com>
 wrote:








=C2=A0










OK, so we have a message =
that mutates by:










- Modifying hop count/lim=
it.










- Modifying a metric valu=
e.










Anything else?<=
/u>










=C2=A0










As mutating (other than h=
op count/limit) messages aren=E2=80=99t covered by 5444 or any derivative d=
ocument
 (but only recommended against, not banned) that you may need to make the m=
essage otherwise immutable (no deconstruction and rebuilding, other than gu=
aranteed unchanging) that would have to be specified by AODVv2. (Easy to sa=
y, but needs saying.)














=C2=A0








With you so far.










=C2=A0<=
/p>







Then that information is =
not in a guaranteed fixed location given by a simple offset. So any signatu=
re
 algorithm that finds it and ignores it or aggregates on it is specific to =
OLSRv2.










=C2=A0








Surely you mean AODVv2










=C2=A0<=
/p>







So standard 7182 ICVs don=
=E2=80=99t do the job, you would need an AODVv2 specialised variant. Which =
is the
 sort of thing that the message specific TLV space is there for, I=E2=80=99=
d be strongly against a =E2=80=9Cbut ignore the value of this specific TLV =
should it occur=E2=80=9D being in the general space. However it can easily =
be defined by reference to 7182 (=E2=80=9Cthis TLV is like that
 TLV, except if an X TLV is present, set its value field to zero=E2=80=9D).=











=C2=A0










Messy, but could work.










=C2=A0








Not that messy, actually, although clearly not as ni=
ce as =E2=80=9Cfixed offset=E2=80=9D.










=C2=A0










That said, I am arguing for the base spec being:<=
/u>










=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=E2=80=9Cmake the message otherwise immutable (no deco=
nstruction and rebuilding, other=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=A0than guaranteed unchanging)=E2=80=9D which is af=
forded by forwarding










=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7182 Timestamps and ICVs.










=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7183 style text bringing it all together.=











=C2=A0










The =E2=80=9Caggregated signatures around mutable fi=
eld=E2=80=9D would very be an experimental extension.










=C2=A0










What I object to is, if the base spec specifically r=
enders such extensions impossible










=C2=A0










=C2=A0<=
/p>







=C2=A0








--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44 (0)12=
45 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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:=C2=A0Lotte
 Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]=C2=A0

Sent:=C2=A017 March 2016 16:48

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0ietf@thomasclausen.org; Mobile Ad =
Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.










Hi all,












=C2=A0
















Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher=
 (UK) <chris.dearlove@baesystems.com>=
:












=C2=A0














Good point about whether =
you just pass on one cost or a set of costs. As I said, not looked at detai=
ls
 - I will, when time permits. One cost is much easier, and yes, it reduces =
the fixed size aggregated signatures problem to =E2=80=9Cjust=E2=80=9D one =
of computational load.


















=C2=A0














For the record, Thomas=E2=80=99 understanding is cor=
rect; the cost is one aggregated value.=C2=A0














=C2=A0














Best regards,=C2=A0














Lotte Steenrbink












=C2=A0<=
/p>













=C2=A0










--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44 (0)12=
45 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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:=C2=A0ietf@thomasclausen.org=
=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 16:38

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: Message integrity and message mutability (was RE: =
[manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)


















=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.












=C2=A0




















On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com>
 wrote:
















=C2=A0


















I appreciate Thomas=E2=80=
=99s comments about the limitations of message regeneration, but I would be=
 a bit
 less absolute.


















=C2=A0


















The issues over end to en=
d authentication and more advanced signatures are valid. I need to read
 the given reference on aggregate signatures to increase my knowledge (than=
ks for it), but my understanding of the possibilities in this field may off=
er a solution to the problem, but with some other issues (possibly includin=
g a new type of TLV).


















=C2=A0


















But the hop count/limit p=
oint I don=E2=80=99t fully agree with, you can regenerate with an increment=
ed/decremented
 count/limit, which leaves the ability to prevent messages propagating inde=
finitely, including expanding ring searches, and retains the ability to use=
 RFC 5497 interval and validity times that might be useful with an expandin=
g ring search (or might not).


















=C2=A0


















But the key issue is that=
 AODVv2 wants to accumulate metrics. I still haven=E2=80=99t got to the bot=
tom of
 many details here, but let=E2=80=99s for the moment just consider that con=
ceptually.


















=C2=A0


















It=E2=80=99s hard to hand=
le end to end. Charlie=E2=80=99s draft attempts to do an end to end of some=
 information,
 not this information. I=E2=80=99m not sure if that=E2=80=99s useful (and t=
he specialised format is better avoided if possible). Other approaches are =
hop by hop (might as well use packet signatures) and shared key (might as w=
ell go hop by hop). Pairwise signatures for each
 pair of routers I=E2=80=99m discounting as scaling terribly. In the intere=
sts of completeness let=E2=80=99s mention not accumulating metrics, which p=
uts us back to hop count and that=E2=80=99s not ideal either.=



















=C2=A0


















I don=E2=80=99t think the=
re is an ideal solution. (I like ideas I=E2=80=99ve seen about aggregating,=
 but that has
 some issues of its own, even apart from computational load.) I=E2=80=99d l=
ove to be proved wrong - someone with the perfect solution to come along.


















=C2=A0


















Which means that either w=
e make an arbitrary choice - which will be disagreed with, but needs discus=
sing
 first - or create something flexible. Unfortunately flexible in that regar=
d constrains in others, e.g. some (many? most?) aggregating signatures need=
 fixed data sizes (which we can do by defining a TLV that =E2=80=9Cfills up=
=E2=80=9D with hop count, but that has a cost too).





















=C2=A0
















I have been told by people much more well versed in =
this than I in cryptology, that the correct answer is =E2=80=9Csome=E2=80=
=9D.


















=C2=A0


















That said, "AODVv2 wants to accumulate metrics=
=E2=80=9D =E2=80=94 does that mean that the message grows as it is being fo=
rwarded, and that the recipient of a RREQ/RREP will know the individual
 costs of each path segment? My understanding is, that the recipient will g=
et =E2=80=9Cthe sum the costs of each path segment=E2=80=9D which should be=
 fitting within a fixed size?


















=C2=A0


















Thomas


















=C2=A0









































=C2=A0


















Sorry, no answers, just c=
omments. And I=E2=80=99m not addressing Thomas=E2=80=99s later points here.=



















=C2=A0












--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44 (0)12=
45 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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:=C2=A0manet
 [mailto:manet-bounces@ietf.org]=C2=A0On Beha=
lf Of=C2=A0=
ietf@thomasclausen.org

Sent:=C2=A017 March 2016 16:00

To:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0[manet] draft-ietf-manet-aodvv2-13 review - a couple o=
f big ticket Items






















=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.









***=
=C2=A0WARNING=C2=A0***

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












=C2=A0




















Dear all,




















=C2=A0






















Apologies for not having gotten this done sooner - d=
ay-job leaving few spare cycles.






















=C2=A0






















I=E2=80=99ve previously offered reviews and comments=
, and some of those have been addressed in the latest I-D =E2=80=94 others =
have not, but should be. I recall that there was some mail attempting
 to rebut parts of the review, and I will dig it out and reply to that.<=
/u>






















=C2=A0






















With that being said, I have reviewed the latest ver=
sion of the document, and full details will be forthcoming. There=E2=80=99r=
e a couple of big-ticket/architectural items that I want to
 address up front, as I believe that before we have those hammered out, it =
will be useless to go into details. Note, I do not claim that this is an ex=
haustive list of =E2=80=9Cbig ticket items=E2=80=9D, but that=E2=80=99s as =
far as I have gotten in thinking this through.






















=C2=A0






















I also bring these up as they are items that have be=
en brought up repeatedly over the past years, but not resolved nor discusse=
d.






















=C2=A0






















Loops






















Just to bring this out: I share Chris=E2=80=99 worry=
 about conflicting and concurrent statements from the authors on =E2=80=9CT=
here are no loops possible=E2=80=9D and =E2=80=9CWe need to fix two situati=
ons where
 loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating some loop=
 conditions=E2=80=9D






















=C2=A0






















I particularly worry that this is not a discussion h=
ad in public, but apparently in some other forum=E2=80=A6






















=C2=A0






















=C2=A0
























Intermediate Route Replies, and all of section=
 10






















Section 10 contains a set of =E2=80=9Cvaguely specif=
ied extensions=E2=80=9D, which is incoherent with the intended status indic=
ated for this document.=C2=A0






















=C2=A0






















Specifically, and this is not unrelated to the point=
 about loops above, intermediate RREPs (section 10.3) are a potential sourc=
e for loops.






















=C2=A0






















Expanding Ring Multicast (section 10.1) is not docum=
ented in a way that can be implemented (and also, see =E2=80=9CForwarding-v=
s-regeneration=E2=80=9D below, it is in the present form of this protocol
 impossible), etc.
























=C2=A0






















=C2=A0






















Forwarding-vs-regeneration






















Recent exchanges on the list made me understand that=
 protocol control messages are *not* forwarded, but are consumed at each ho=
p, then a new message with (almost-but-not-quite)
 the same content is generated and transmitted.






















=C2=A0






















I have thought some more on this (& read some of=
 the exchanges on the list on this topic by Chris, Ulrich, and others), and=
 I am convinced that this is not the right way to go,=C2=A0at
 least=C2=A0for the following reasons:






















=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It renders the hop-limit/hop-count fields in the RFC5444 messag=
e header useless.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0This would not be bad if the functionality offered by tho=
se fields was not useful






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=94 sadly, it is. For example, for scope limited fl=
ooding (expanding ring search, and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0such) which may be of interest, and which require hop-lim=
it.=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0A hop-count field may also provide a =E2=80=9Ccheap=E2=80=
=9D (in terms of overhead) additional piece






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of information to use conjunctively with a =E2=80=9Creal=
=E2=80=9D metric.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The only practical solution would be to re-introduce thes=
e functions by way of inserting a






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0MessageTLV =E2=80=94 which (i) is not specified in this d=
ocument, and (ii) which would just






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0serve to render messages bigger than strictly needed.<=
/u>






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Scope limited flooding =C2=A0does seem to be a necessary =
requirement, if for no






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0other reason than to prevent information from =E2=80=9Cci=
rculating forever in the network=E2=80=9D.






















=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It makes end-to-end authentication unnecessarily hard.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I think Chris called this out already, but it bears repea=
ting: S generates a message=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(say, a RREQ), and includes an ICV calculated over the co=
ntent of the message.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0For any recipient to be able to validate the ICV, the mes=
sage has to be exactly






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0the same =E2=80=94 not just in content, but in structure =
=E2=80=94 as what was generated.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforwa=
rding=E2=80=9D messages means, that the intermediate






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose =
a different structure (e.g., include TLVs






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0in a different order).






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The proposal from=C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00=























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0is to add constraints on (i) the set of elements to inclu=
de in a signature and (ii) the






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0order of these elements.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0One=C2=A0problem with that approach is (i): if an extensi=
on adds a message TLV, or an=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Address TLV, to a message, then that will not be =E2=80=
=9Ccovered=E2=80=9D by the proposed e2esec TLV.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Rather for *each* extension developed, an =E2=80=9Cupdate=
s e2esec=E2=80=9D clause needs to be done.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I=E2=80=99d say that this approach would be prone to erro=
rs =E2=80=94 and add entropy to the process






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of designing protocol extensions. The alternative, a mess=
age being generated by the






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0source and *forwarded* (as we do in OLSRv2, for example) =
would allow ICV TLVs=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(even, allow reuse of those specified for OLSRv2) for cov=
ering a message and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0extensions.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CBut what about the metrics value which will chan=
ge on each hop=E2=80=9D, you may say?






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Fortunately, that is relatively easy to handle: simply ze=
ro out the value of that TLV when






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0generating or verifying the ICV MessageTLV. And use Packe=
t-TLVs for hop-by-hop=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0authentication, if needed (but, see below).=























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It prevents the use of more clever/advanced signature scheme=
s/ICVs






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Aggregate signature algorithms (=C2=A0https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf<=
/span>)






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0exist, and an interesting use-case can be found in also r=
eactive protocols, allowing verifying






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0not =E2=80=9Cjust=E2=80=9D the end points, but also the i=
ntermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0discussed above, or something smarter).






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Regeneration of messages, rather than forwarding, renders=
 that impossible (or, if used,






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0updating to =C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)






















=C2=A0






















There are other reasons, but the above are those tha=
t jump at me as immediate show-stoppers.






















=C2=A0






















I do honestly not see what possible benefit there is=
 from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inconve=
niences, and security is not the least of these. Insisting on =E2=80=9Crege=
neration=E2=80=9D
 requires development of =E2=80=9Cnon-general workarounds=E2=80=9D as point=
ed out above.






















=C2=A0






















Security Considerations<=
/p>





















This is an always thorny subject. When OLSRv2 was go=
ing through the process we got a thorough education in how little we knew a=
bout security from the SEC-ADs, and had to spend about
 a year or so developing RFC7183. The bottom line is, that this protocol ne=
eds its =E2=80=9CRFC7183 =C2=A0equivalent=E2=80=9D, either as part of the m=
ain document, or as an independent document. currently, that is not the cas=
e.






















=C2=A0






















A minima, looking at BCP72 and BCP107 =E2=80=94 taki=
ng inspiration from RFC7183 might be aw good idea, as that was the most rec=
ent that went through the SEC AD. Regardless of how, however,
 a =E2=80=9Cmandatory to implement=E2=80=9D security mechanism most be spec=
ified (I think the right term was =E2=80=9CMUST implement, SHOULD use=E2=80=
=9D), in sufficient detail to ensure interoperable implementations.<=
u>






















=C2=A0






















As an example, both [RFC6130] and [RFC7181] set out =
that that:
























=C2=A0






















=C2=A0 =C2=A0 =C2=A0 On receiving a ... message, a r=
outer MUST first check if the






















=C2=A0 =C2=A0 =C2=A0 message is invalid for processi=
ng by this router






















=C2=A0






















and then proceed to give a number of conditions that=
, each, will lead to a rejection of the message as "badly formed and t=
herefore invalid for processing=E2=80=9D =E2=80=94 a list which RFC7183
 then amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting=
 =E2=80=9Crejection=E2=80=9D. Idem for message generation.





















=C2=A0






















If I was to do RFC7181/RFC6130 today, I would includ=
e that directly into the protocol specifications. It turned out to be more =
overhead (and slow down publication anyways) to do
 it as separate documents.
























=C2=A0






















Secondly, we need to be a lot more rigid in terms of=
 what ICVs, Timestamps, etc. are added/removed, and what that brings.






















=C2=A0






















For example (with the assumption that messages are *=
forwarded* and *not* regenerated), this could be one option:<=
/p>





















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0When a RREQ, RREP message is generated, add an ICV Message TLV, which=
 is calculated <this way>






















=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=E2=80=A6(take inspiration from RFC7183 here)






















=C2=A0
































...



[Message clipped]=C2=A0=C2=A0

_______________________________________________

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










=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










=C2=A0











_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet





--94eb2c0b66e65cedad05314fe050--


From nobody Mon Apr 25 07:26:39 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 DB7A512D5DC for ; Mon, 25 Apr 2016 07:26:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.393
X-Spam-Level: 
X-Spam-Status: No, score=-1.393 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, TRACKER_ID=1.306] 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 zp_KP0jDzyPI for ; Mon, 25 Apr 2016 07:26:31 -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 C932212D5D3 for ; Mon, 25 Apr 2016 07:26:30 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id o66so214071846ywc.3 for ; Mon, 25 Apr 2016 07:26:30 -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=BTVJQLeOvudup/Ksc0IoBoqvpX/uiO/ctTXwytUS7QM=; b=WGfFIOk4O2czF4a7AwoRhjwT9PcHdOSz05kln3ShOTV/eoeYx+d8zzGYmsWqilfiJU VSrKnbN2YESoTNE/fbCPZOo6mj1Qu7PzB877iJNRBDAKkjk1tyXjSEdnjq2J47mwb6JN EmsN6wiF5mK4bdOmsk4QZsjjH/rTtMk7RQuBfDoiyZ7TSzua838knwVzY/xYfVqNvru6 dSa+51VUtprs7glMscsTSMTwnR/Ws270PpVFwcIluhjamo9guuRTsE0ResU9aKOiIlBF G1DQHpn5Ok2buD5c8a57WqxvrUwbJhuHTlBJuL+Rt9QRVuOP3v7KkdpHm4QKpcZs5Dsb lSmA==
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=BTVJQLeOvudup/Ksc0IoBoqvpX/uiO/ctTXwytUS7QM=; b=Nh/EQOW9N1z8QPRW0UUE61+RB7hWPNp7nwz6ECkwCPcoVlwZhn2RCgOj+FaFYEaIPj OHNBQF8scv7Lh5E21fP2Tf0QAidlIXzlauc1/XijCP2pg+AMGO50qpK/j1sFY2R3AZ3d yzBOtNxFyrrJYn46g2csXMKpuRzX0FVTzfDP//HtYy+lOaHSzuffChUPWHstV9v3oTb8 QOIASP8lkgEK/59qyeaaDR5b4FK71rTeV+KsPfA8f4PlhpS+ABgUZ8mvThOAGgUPxnra YmRN2DtVbH14AdrMyN1UdGDM4zZASQFTaikBLHXojfFCy39TQlIxVdTcnt55mvMCGbKO sWPw==
X-Gm-Message-State: AOPr4FUF/aa6D9llFQlIV1XAv5S6sp/MXuJukelNoL0n1vY8vmlPgGGhbQgurl0CrbqwsvdFogVjdPwqXMqkzw==
MIME-Version: 1.0
X-Received: by 10.176.1.45 with SMTP id 42mr11468557uak.65.1461594389766; Mon, 25 Apr 2016 07:26:29 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Mon, 25 Apr 2016 07:26:29 -0700 (PDT)
In-Reply-To: <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org>
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org>
Date: Mon, 25 Apr 2016 10:26:29 -0400
Message-ID: 
From: Justin Dean 
To: Thomas Heide Clausen 
Content-Type: multipart/alternative; boundary=001a11351d9e686add05314ff672
Archived-At: 
Cc: Christopher Dearlove , Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 14:26:37 -0000

--001a11351d9e686add05314ff672
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The address in the RREP_Ack may be required due to the RREP_Ack being
multicast as there is not yet a verified unicast route installed yet.
Going to double check if I'm remembering correctly.

Justin

On Mon, Apr 25, 2016 at 10:18 AM,  wrote:

> Hi,
>
> I must admit that while I have reviewed the protocol several times, I=E2=
=80=99ve
> not been digging that deep into the protocol functioning to catch this
> issue of how invasive the protocol operations are when forwarding a
> message: there were other =E2=80=9Cmajor=E2=80=9D issues to address (and =
which obscured the
> details), so as a first order: thank you Victoria, for having called
> attention to this.
>
> To the substance of these emails.
>
> I am afraid that I do not understand the use of inserting validity TLVs
> while in-flight, into a message. Actually, I am dubious for both the
> originator inserting this (how can the originator of a message know how
> =E2=80=9Clatter parts of the path=E2=80=9D will be have=E2=80=9D) except =
if we are talking
> duty-cycling of devices and inserting =E2=80=9Cthe remaining time that I =
am going
> to be up before I suspend=E2=80=9D. Intuitively, that would also assume f=
airly long
> duty cycles =E2=80=9CI am up for tens of seconds=E2=80=9D, which I am not=
 sure are actually
> realistic. And, as Chris says in another email, this is trading off =E2=
=80=9Cthe
> ability to do security=E2=80=9D for an unknown/untested feature =E2=80=94=
 which I think is
> the wrong trade-off.
>
> On he topic of =E2=80=9Cneeding to put an address in=E2=80=9D for RREP-AC=
K, I must admit
> that this seems roundabout. I can see three issues here:
>
> o I am not sure that adding an address vs. a flag may not have to do with
> the =E2=80=9Cmultiple interfaces/
> multiple addresses=E2=80=9D discrimination mechanics of the protocol? I h=
aven=E2=80=99t
> worked it through, though,
> but that would be a guess.
>
> o The end-to-end topology diffusion mechanism should not need to be
> concerned with the
> =E2=80=9Cbidirectionally check=E2=80=9D of a local link (in part, as it e=
ncumbers
> security, but not only).  In short, a
> flag or an address, both are (equally) bad.
>
> o A cleaner mechanism would be a =E2=80=9Chello mechanism=E2=80=9D, not n=
ecessarily as
> NHDP, but a =E2=80=9Cwhen
> forwarding a RREQ/RREP, trigger a 3-way hello exchange, if the link is
> estimated to be of a
> type which potentially can be unidirectional=E2=80=9D. There is another b=
enefit to
> doing that, see the end
> of this email.
>
> Either way, I do not like the notion of fusing
> metrics-and-link-bidirectionality-detection any more than I like fusing
> global-topology-diffusion-and-link-bidirectionality-detection.
>
> The solution all this is, to me, threefold
>
> 1) Factor out the bidirectionally check in a (triggered) neighbour
> detection mechanism
> (triggered HELLO message)
>
> 2) Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, since they add comple=
xity for no
> perceivable benefits
>
> 3) Use the security model that we=E2=80=99ve discussed previously, where =
(only)
> the metrics change per hop.
>
> Since we=E2=80=99re discussing bi-directionality of links here, and the n=
ecessity
> 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:
>
>    ...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 this
>    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 conclusi=
on 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 link t=
he
> metrics is 4 or 5=E2=80=9D, the protocol must be able to convey and disti=
nguish
> 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 mechanis=
m:
> that exchange could, if designed carefully, be used to probe for and conv=
ey
> metrics information, also.
>
> Hope this helps,
>
>
> Thomas
>
> On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
> Assuming for the moment that everyone will need an RREP-Ack or won=E2=80=
=99t
> (let=E2=80=99s come back to that) why do C and B need to put an address i=
n as an
> RREQ-Ack request? Why not a flag, because the address will be included as
> the IP sending address - and we know 5444 is required to pass that on.
> (It=E2=80=99s used by NHDP as well.) Then we don=E2=80=99t need to change=
 the RREP, it will
> have a flag set or not, and won=E2=80=99t change (in this regard).
>
> Now let=E2=80=99s consider do we know whether we can set a fixed flag. Fi=
rst I=E2=80=99d
> say there are two cases - you=E2=80=99ve got a firm control on what=E2=80=
=99s going on in
> your network, or it=E2=80=99s one of unknown parties and behaviour (consi=
stent with
> specification). In the former case you only want one setting, for example
> no-Ack if running NHDP or your MAC layer tells you about bidirectionality=
,
> Ack otherwise. In the latter case, I think you just always want an Ack. S=
o
> both cases get you to the same place.
>
> Should that not be an acceptable argument (though I think it=E2=80=99s go=
od for
> where we are - in fact always Ack is close) then at flag is a step better=
,
> it=E2=80=99s a fixed location to change. However it would be better in th=
at case if
> the two things to change (metric and ack flag) were together. But that ha=
s
> its own issues, so I won=E2=80=99t go there.
>
>
> *--*
>
>
>
>
> *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com
> ]
> *Sent:* 25 April 2016 14:15
> *To:* Jiazi YI
> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
> Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
> **** 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
> .*
>
> Hi Jiazi,
>
>
>
> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI  wrote:
> Hi,
>
> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
> With regard to your validity time point, we here have a tradeoff. If you
> allow that feature, it significantly impacts on the approach that was
> coming together on as best you can end to end encryption.
>
> So the question is, is this a feature that=E2=80=99s really wanted? Unfor=
tunately
> I think we know that the answer to that is, we don=E2=80=99t know because=
 we don=E2=80=99t
> have any experience. My view would be that in the tradeoff of an untested
> feature (unless I=E2=80=99m wrong about that) and the security complicati=
on,
> security wins and drop the feature. If there is some real requirement, th=
en
> there=E2=80=99s a discussion. (Questions like how often the intermediate =
routers
> actually have any knowledge - typically links break for unexpected rather
> than expected reasons. Andan intermediate router could possibly use a
> validity time to influence its behaviour.) Note that dropping the ability
> of intermediate routers to modify/set still allows validity times per rou=
te
> to be set at endpoints.
>
> I agree with Chris' concern.
> The ValidityTime is optional, which makes the integrity protection hard.
> Furthermore, it gives a potential attack vector: as all the routers in a
> path will take the shortest validityTime, a compromised router can set th=
e
> the validityTime to a very short value, which will make the route install=
ed
> along the path became invalid (very soon).
>
> On the other hand, I'm not sure this option will give us much help. Chris
> mentioned much knowledge intermediate router would have to decide this
> value (and how much sense the value would make).
> Another issue is, a route to a destination might be updated by different
> sources. For example, in the network below:
>
> A----B-----C
>
> A first establish a route to B with long validity time. Then A initiates =
a
> route discovery to C. C tends to set a short validity time, which will ma=
ke
> the route between B and A expire earlier than expected.
> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered or
> not.
>
>
>
> Not sure I follow here.
>
> Currently, the validity time of the route between A and B would not
> affected by a short validity time of a route between A and C. Validity
> times are per-route, and the route A-B and the route A-C are separate.
> If we switched to a validity time per neighbor (so that we can keep
> validity time separate from route advertisements) as I mentioned in the
> email below, then the validity of a route between A and C would be affect=
ed
> if there was a short validity time between A and B. But, if B will only
> route for a certain amount of time, then the route between A and C will o=
f
> course be affected. Is it best to know in advance that there's a time
> limit, or just deal with RERRs when they happen?
>
>
>
>
>
> With regard to the acknowledgements, the problem (with regard to security=
)
> comes from trying to do two jobs with the same message - end to end route
> advertisement and hop by hop acknowledgement. I understand the reasons -
> saving bytes and message types. (I would have to study the protocol reall=
y
> hard to identify if any message types can be folded together and recognis=
ed
> by content rather than type efficiently. This I do not expect to do.) Aga=
in
> a tradeoff. This one is in discussion space, though that needs people who
> understand both sides of the issue, including the details of the
> bidirectionality mechanism. Of course, as has been said, we need one of
> those.
>
>
> I haven't finished my review of the latest draft, and I don't get the
> necessity of AckReq and the corresponding multicast RREP yet.
> If possible, this "optional" field should be avoided.
>
>
>
> To give an overview of AckReq and RREP:
>
> Since AODVv2 requires bidirectional links, this is the way to determine i=
f
> a link is bidirectional.
> A----B----C
>
> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install
> a route to OrigAddr but they dont yet know if it's valid because they don=
t
> know if the link to their next hop is available in the reverse direction.
> 2) C creates the RREP. Since it doesnt know if the link to B is
> bidirectional, it includes the AckReq (an address to indicate that it
> expects to receive a RREP_Ack from B).
> 3) B receives the RREP, installs a route to TargAddr and marks it as
> valid, since it knows the link to C is bidirectional, because the RREQ we=
nt
> in one direction and the RREP came in the other. B also sends the RREP_Ac=
k
> to C and forwards the RREP to A (and might change the message to indicate
> its own AckReq - ie that it requires an ack from A).
> 4) C receives the RREP_Ack from B, and therefore knows that B received th=
e
> RREP, therefore the link is bidirectional. C can then mark its route to
> OrigAddr as valid.
> 5) Similarly, A receives the RREP, installs the route to TargAddr and
> sends an RREP_Ack to B.
> 6) B receives the RREP_Ack and marks its route to OrigAddr as valid.
>
>
> Alternatively, in step 2, if C knows the link to B is bidirectional
> (perhaps from some earlier route discovery), it doesnt need to put the
> AckReq in the RREP. Then in step 3, since B doesnt know if the link to A =
is
> bidirectional, it changes the message to add the AckReq address, in order
> to get an RREP_Ack from A.
>
> If we want to avoid changing the message, we'll need to look at forwardin=
g
> the RREP as-is, and creating a second message to solicit an RREP_Ack, in
> order to verify that the link is bidirectional before marking the route t=
o
> OrigAddr as valid.
> Kind regards,
> Victoria.
>
>
>
>
> regards
>
> Jiazi
>
>
>
>
> *--*
>
>
>
>
> *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
> *Sent:* 23 April 2016 10:55
> *To:* Christopher Dearlove
> *Cc:* ietf@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc
> Networks mailing list
>
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
> **** 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
> .*
> Hi Chris,
>
> These have both been in the draft in some form since before I got
> involved... but I'll do my best to explain.
>
> - For Validity Time, its a way to advertise that you would only support
> the route contained in the message for a certain period of time. The
> originator might use this, but the draft was written to allow any
> intermediate node to be able to add it or update it too. The route create=
d
> in the Local Route Set has an expiration time associated with it, based o=
n
> the received validity time.
> - For the AckReq address, its so that you can add into a RREP a request
> for an acknowledgement, so that you don't have to have a different messag=
e
> type altogether for working out whether links to neighbors are
> bidirectional, and also, since you only care about bidirectionality on
> routes that are being set up, you dont need to constantly monitor all
> neighbors.
>
>
> In order to avoid the potential AckReq-related changes to each message,
> maybe we do need to introduce a different message specifically for this. =
We
> could maybe use RREP_Ack to both request and acknowledge? It means an ext=
ra
> message of control traffic that needs to be sent, maybe one extra message
> per hop on the path of a RREP, but it could still be limited to neighbors
> which have participated in the route discovery rather than monitoring all
> neighbors at all times.
>
> This message could maybe also include "I'm happy to route anywhere for a
> certain amount of time", sort of like willingness in OLSR/OLSRv2. So
> instead of having a validity time per route, its a validity time per
> neighbor. Then, for RREQ and RREP, only the metric value would change in
> transit, as discussed. However, that leads to some issues with deciding
> what a route's expiration time is. You might know how long the next hop
> router is valid for, but what if a router beyond that, which was also par=
t
> of the route, had a lower validity time? You couldn't determine the real
> validity time. Do we remove the route expiration time altogether to avoid
> this issue? In which case, we would have to rely on RERR messages being
> sent for routes which become invalid when the neighbor's validity time ha=
s
> expired? So neighbor validity time expiration is treated the same as a li=
nk
> break.
>
> What do you think?
>
> Kind regards,
> Victoria.
>
>
>
>
>
>
> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
> chris@mnemosyne.demon.co.uk> wrote:
> Pretty much all of the discussion has been assuming only a metric value
> change. With multiple things changing many of the ideas go out of the
> window. That reinforces the point about not making specifications now tha=
t
> might turn out to be wrong for ICVs.
>
> Ignoring how this misunderstanding happened, I'll start by asking why.
> Metric changing I understand. Why the other two? (there's a partial
> explanation of one). What alternatives have people implemented in
> comparable protocols?
>
> --
> Christopher Dearlove
> christopher.dearlove@gmail.com (iPhone)
> chris@mnemosyne.demon.co.uk (home)
>
>
> On 23 Apr 2016, at 00:26, Victoria Mercieca  wrote:
>
> Hi all,
>
> Continued in this thread because the other one seems to be more about TLV
> types and metric type numbers, whereas this is about
> regeneration/forwarding.
>
> To recap, in the current draft, there are 3 things that might change at
> each hop:
> - the metric value (happens in RREQ and RREP),
> - adding/changing Validity Time using the Validity Time TLV (can happen i=
n
> RREQ and RREP),
> - adding an address (and corresponding value in the AddressType TLV to
> indicate how to interpret the address) to indicate the address from which
> an RREP_Ack is expected, to accomplish the bidirectionality check (can
> happen in RREP).
>
> If we define a certain portion of the message as immutable and include th=
e
> ICV to verify that part, end to end:
> - The metric value would be excluded from the ICV since it needs changing
> at each hop.
> - Would adding a Validity Time TLV at an intermediate hop be acceptable?
> The whole TLV could be removed in order to calculate the ICV?
> - Would adding an address cause issues for the ICV, because it's in the
> address block? Could the rule be "if it contains an AckReq address, remov=
e
> it (and the corresponding value in the AddressType TLV), before checking
> the ICV", is that OK? Or would we need to avoid touching the ICV'ed part =
of
> the message altogether, maybe put the AckReq address in a separate Addres=
s
> Block, with an extra AddressType TLV following that address block? Is the=
re
> a way to accomplish this?
>
> Also, to be thorough, do we need to consider RERR messages while we
> discuss regeneration vs forwarding?
> - RERR (sent when a link breaks) is a way of saying "I've lost my route s=
o
> I'm telling others" and "you were my next hop, so now I've also lost my
> route, I'll tell others", etc. It's going to be tailored at each step to
> include the relevant routes that got deleted, it's not one message being
> sent end-to-end like RREQ and RREP are.
> - However, RERR (sent when a source of traffic is sending data on a route
> which comes through you, and you want to tell the Packet Source's router =
to
> delete the route) could be seen as an end-to-end message which all
> intermediate routers learn from, similar to RREQ and RREP. It reports one
> route, and doesn't need changing at intermediate hops, so could be
> protected with ICV.
> - Would it be OK to only require a message ICV if a PktSource address was
> included, i.e. when the message needs to go via a number of intermediate
> hops to PktSource's router? All other RERRs are intended to be one-hop
> messages, which may in turn prompt other one-hop messages, etc..., and a
> packet ICV might be more appropriate?
>
> Kind regards,
> Victoria.
>
> On Thu, Mar 17, 2016 at 5:26 PM,  wrote:
>
>
> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
> Yes, I meant AODVv2, thanks for the catch.
>
> So is your (Thomas) proposed base specification a hop count only metric?
>
>
> No, the would be silly as base specification, given that hop count mostly
> is useless.
>
> As base specification I would simply say =E2=80=9CInclude a Metric Type M=
essage
> TLV with a value field, and a 7182 Message TLV & Timestamp=E2=80=9D as we=
 do in
> OLSRv2 (with the appropriate verbiage as to generation and processing).
>
> With the message generated by the originator of the RREQ/RREP and *not*
> deconstructed/reconstructed/reordered (as is the risk with =E2=80=9Cregen=
eration)
> allows knowing that it would be *only* that metric field being modified
> (other than hop count/limit) for when eventually writing up the extension=
.
>
>
> (Actually doesn=E2=80=99t the current specification only define hop count=
, or has
> that changed in latest draft?)
>
>
> No. That is one of the issues I raise in my original. For some reason, it
> cites RFC6551, which is a ROLL document and which has in its abstract tha=
t:
>
>
>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>
>    compared with traditional wired and ad hoc networks that require the
>
>    specification of new routing metrics and constraints.
>
>
> I.e. this document cites a metric document which clearly claims to be
> inapplicable in ad hoc networks. I note that this is another thing I=E2=
=80=99ve
> raised for years without seeing it attempted resolved.
>
> Best,
>
> Thomas
>
>
>
>
>
> *--*
>
>
>
>
> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
> ]
> *Sent:* 17 March 2016 17:10
> *To:* Dearlove, Christopher (UK)
> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
> **** 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 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
> OK, so we have a message that mutates by:
> - Modifying hop count/limit.
> - Modifying a metric value.
> Anything else?
>
> As mutating (other than hop count/limit) messages aren=E2=80=99t covered =
by 5444
> or any derivative document (but only recommended against, not banned) tha=
t
> you may need to make the message otherwise immutable (no deconstruction a=
nd
> rebuilding, other than guaranteed unchanging) that would have to be
> specified by AODVv2. (Easy to say, but needs saying.)
>
>
> With you so far.
>
>
> Then that information is not in a guaranteed fixed location given by a
> simple offset. So any signature algorithm that finds it and ignores it or
> aggregates on it is specific to OLSRv2.
>
> Surely you mean AODVv2
>
>
> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AODVv2
> specialised variant. Which is the sort of thing that the message specific
> TLV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cbut ig=
nore the value of
> this specific TLV should it occur=E2=80=9D being in the general space. Ho=
wever it
> can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like tha=
t TLV,
> except if an X TLV is present, set its value field to zero=E2=80=9D).
>
> Messy, but could work.
>
> Not that messy, actually, although clearly not as nice as =E2=80=9Cfixed =
offset=E2=80=9D.
>
> That said, I am arguing for the base spec being:
>
>             =E2=80=9Cmake the message otherwise immutable (no deconstruct=
ion and
> rebuilding, other
>              than guaranteed unchanging)=E2=80=9D which is afforded by fo=
rwarding
>
>                                     +
>
>             RFC7182 Timestamps and ICVs.
>
>                                     +
>
>             RFC7183 style text bringing it all together.
>
> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would ve=
ry be an
> experimental extension.
>
> What I object to is, if the base spec specifically renders such extension=
s
> impossible
>
>
>
>
>
> *--*
>
>
>
>
> *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:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
> ]
> *Sent:* 17 March 2016 16:48
> *To:* Dearlove, Christopher (UK)
> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
> **** 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
> .*
> Hi all,
>
>
> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com>:
>
> Good point about whether you just pass on one cost or a set of costs. As =
I
> said, not looked at details - I will, when time permits. One cost is much
> easier, and yes, it reduces the fixed size aggregated signatures problem =
to
> =E2=80=9Cjust=E2=80=9D one of computational load.
>
>
> For the record, Thomas=E2=80=99 understanding is correct; the cost is one
> aggregated value.
>
> Best regards,
> Lotte Steenrbink
>
>
>
>
> *--*
>
>
>
>
> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
> ]
> *Sent:* 17 March 2016 16:38
> *To:* Dearlove, Christopher (UK)
> *Cc:* Mobile Ad Hoc Networks mailing list
> *Subject:* Re: Message integrity and message mutability (was RE: [manet]
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
> **** 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 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
> I appreciate Thomas=E2=80=99s comments about the limitations of message
> regeneration, but I would be a bit less absolute.
>
> The issues over end to end authentication and more advanced signatures ar=
e
> valid. I need to read the given reference on aggregate signatures to
> increase my knowledge (thanks for it), but my understanding of the
> possibilities in this field may offer a solution to the problem, but with
> some other issues (possibly including a new type of TLV).
>
> But the hop count/limit point I don=E2=80=99t fully agree with, you can r=
egenerate
> with an incremented/decremented count/limit, which leaves the ability to
> prevent messages propagating indefinitely, including expanding ring
> searches, and retains the ability to use RFC 5497 interval and validity
> times that might be useful with an expanding ring search (or might not).
>
> But the key issue is that AODVv2 wants to accumulate metrics. I still
> haven=E2=80=99t got to the bottom of many details here, but let=E2=80=99s=
 for the moment
> just consider that conceptually.
>
> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft attempts =
to do an end to
> end of some information, not this information. I=E2=80=99m not sure if th=
at=E2=80=99s
> useful (and the specialised format is better avoided if possible). Other
> approaches are hop by hop (might as well use packet signatures) and share=
d
> key (might as well go hop by hop). Pairwise signatures for each pair of
> routers I=E2=80=99m discounting as scaling terribly. In the interests of
> completeness let=E2=80=99s mention not accumulating metrics, which puts u=
s back to
> hop count and that=E2=80=99s not ideal either.
>
> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=80=
=99ve seen about
> aggregating, but that has some issues of its own, even apart from
> computational load.) I=E2=80=99d love to be proved wrong - someone with t=
he perfect
> solution to come along.
>
> Which means that either we make an arbitrary choice - which will be
> disagreed with, but needs discussing first - or create something flexible=
.
> Unfortunately flexible in that regard constrains in others, e.g. some
> (many? most?) aggregating signatures need fixed data sizes (which we can =
do
> by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but tha=
t has a cost too).
>
>
> I have been told by people much more well versed in this than I in
> cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>
> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does th=
at mean that the
> message grows as it is being forwarded, and that the recipient of a
> RREQ/RREP will know the individual costs of each path segment? My
> understanding is, that the recipient will get =E2=80=9Cthe sum the costs =
of each
> path segment=E2=80=9D which should be fitting within a fixed size?
>
> Thomas
>
>
>
>
>
> Sorry, no answers, just comments. And I=E2=80=99m not addressing Thomas=
=E2=80=99s later
> points here.
>
>
> *--*
>
>
>
>
> *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 *ietf@thomasclausen.org
> *Sent:* 17 March 2016 16:00
> *To:* Mobile Ad Hoc Networks mailing list
> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of big
> ticket Items
>
>
> **** 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.
>
> Dear all,
>
> Apologies for not having gotten this done sooner - day-job leaving few
> spare cycles.
>
> I=E2=80=99ve previously offered reviews and comments, and some of those h=
ave been
> addressed in the latest I-D =E2=80=94 others have not, but should be. I r=
ecall that
> there was some mail attempting to rebut parts of the review, and I will d=
ig
> it out and reply to that.
>
> With that being said, I have reviewed the latest version of the document,
> and full details will be forthcoming. There=E2=80=99re a couple of
> big-ticket/architectural items that I want to address up front, as I
> believe that before we have those hammered out, it will be useless to go
> into details. Note, I do not claim that this is an exhaustive list of =E2=
=80=9Cbig
> ticket items=E2=80=9D, but that=E2=80=99s as far as I have gotten in thin=
king this through.
>
> I also bring these up as they are items that have been brought up
> repeatedly over the past years, but not resolved nor discussed.
>
> *Loops*
> Just to bring this out: I share Chris=E2=80=99 worry about conflicting an=
d
> concurrent statements from the authors on =E2=80=9CThere are no loops pos=
sible=E2=80=9D and
> =E2=80=9CWe need to fix two situations where loops can occur=E2=80=9D and=
 =E2=80=9Cwe are still
> investigating some loop conditions=E2=80=9D
>
> I particularly worry that this is not a discussion had in public, but
> apparently in some other forum=E2=80=A6
>
>
> *Intermediate Route Replies, and all of section 10*
> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=80=
=9D, which is
> incoherent with the intended status indicated for this document.
>
> Specifically, and this is not unrelated to the point about loops above,
> intermediate RREPs (section 10.3) are a potential source for loops.
>
> Expanding Ring Multicast (section 10.1) is not documented in a way that
> can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=E2=
=80=9D below, it is
> in the present form of this protocol impossible), etc.
>
>
> *Forwarding-vs-regeneration*
> Recent exchanges on the list made me understand that protocol control
> messages are *not* forwarded, but are consumed at each hop, then a new
> message with (almost-but-not-quite) the same content is generated and
> transmitted.
>
> I have thought some more on this (& read some of the exchanges on the lis=
t
> on this topic by Chris, Ulrich, and others), and I am convinced that this
> is not the right way to go, *at least* for the following reasons:
>
>
>             o          *It renders the hop-limit/hop-count fields in the
> RFC5444 message header useless.*
>                         This would not be bad if the functionality offere=
d
> by those fields was not useful
>                         =E2=80=94 sadly, it is. For example, for scope li=
mited
> flooding (expanding ring search, and
>                         such) which may be of interest, and which require
> hop-limit.
>                         A hop-count field may also provide a =E2=80=9Cche=
ap=E2=80=9D (in
> terms of overhead) additional piece
>                         of information to use conjunctively with a =E2=80=
=9Creal=E2=80=9D
> metric.
>
>                         The only practical solution would be to
> re-introduce these functions by way of inserting a
>                         MessageTLV =E2=80=94 which (i) is not specified i=
n this
> document, and (ii) which would just
>                         serve to render messages bigger than strictly
> needed.
>
>                         Scope limited flooding  does seem to be a
> necessary requirement, if for no
>                         other reason than to prevent information from
> =E2=80=9Ccirculating forever in the network=E2=80=9D.
>
>             o          *It makes end-to-end authentication unnecessarily
> hard.*
>                         I think Chris called this out already, but it
> bears repeating: S generates a message
>                         (say, a RREQ), and includes an ICV calculated ove=
r
> the content of the message.
>                         For any recipient to be able to validate the ICV,
> the message has to be exactly
>                         the same =E2=80=94 not just in content, but in st=
ructure =E2=80=94
> as what was generated.
>
>                         =E2=80=9CRegenerating=E2=80=9D rather than =E2=80=
=9Cforwarding=E2=80=9D messages
> means, that the intermediate
>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ ma=
y chose a
> different structure (e.g., include TLVs
>                         in a different order).
>
>                         The proposal from
> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>                         is to add constraints on (i) the set of elements
> to include in a signature and (ii) the
>                         order of these elements.
>
>                         One problem with that approach is (i): if an
> extension adds a message TLV, or an
>                         Address TLV, to a message, then that will not be
> =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>                         Rather for *each* extension developed, an =E2=80=
=9Cupdates
> e2esec=E2=80=9D clause needs to be done.
>
>                         I=E2=80=99d say that this approach would be prone=
 to
> errors =E2=80=94 and add entropy to the process
>                         of designing protocol extensions. The alternative=
,
> a message being generated by the
>                         source and *forwarded* (as we do in OLSRv2, for
> example) would allow ICV TLVs
>                         (even, allow reuse of those specified for OLSRv2)
> for covering a message and
>                         extensions.
>
>                         =E2=80=9CBut what about the metrics value which w=
ill
> change on each hop=E2=80=9D, you may say?
>                         Fortunately, that is relatively easy to handle:
> simply zero out the value of that TLV when
>                         generating or verifying the ICV MessageTLV. And
> use Packet-TLVs for hop-by-hop
>                         authentication, if needed (but, see below).
>
>             o          *It prevents the use of more clever/advanced
> signature schemes/ICVs*
>                         Aggregate signature algorithms (
> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>                         exist, and an interesting use-case can be found i=
n
> also reactive protocols, allowing verifying
>                         not =E2=80=9Cjust=E2=80=9D the end points, but al=
so the
> intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D
>                         discussed above, or something smarter).
>                         Regeneration of messages, rather than forwarding,
> renders that impossible (or, if used,
>                         updating to
> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>
> There are other reasons, but the above are those that jump at me as
> immediate show-stoppers.
>
> I do honestly not see what possible benefit there is from =E2=80=9Cregene=
ration=E2=80=9D =E2=80=94
> but I see very clear inconveniences, and security is not the least of
> these. Insisting on =E2=80=9Cregeneration=E2=80=9D requires development o=
f =E2=80=9Cnon-general
> workarounds=E2=80=9D as pointed out above.
>
> *Security Considerations*
> This is an always thorny subject. When OLSRv2 was going through the
> process we got a thorough education in how little we knew about security
> from the SEC-ADs, and had to spend about a year or so developing RFC7183.
> The bottom line is, that this protocol needs its =E2=80=9CRFC7183  equiva=
lent=E2=80=9D,
> either as part of the main document, or as an independent document.
> currently, that is not the case.
>
> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration from R=
FC7183
> might be aw good idea, as that was the most recent that went through the
> SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to implement=E2=
=80=9D security
> mechanism most be specified (I think the right term was =E2=80=9CMUST imp=
lement,
> SHOULD use=E2=80=9D), in sufficient detail to ensure interoperable implem=
entations.
>
> As an example, both [RFC6130] and [RFC7181] set out that that:
>
>       On receiving a ... message, a router MUST first check if the
>       message is invalid for processing by this router
>
> and then proceed to give a number of conditions that, each, will lead to =
a
> rejection of the message as "badly formed and therefore invalid for
> processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That gav=
e a =E2=80=9Chook=E2=80=9D for
> RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message gener=
ation.
>
> If I was to do RFC7181/RFC6130 today, I would include that directly into
> the protocol specifications. It turned out to be more overhead (and slow
> down publication anyways) to do it as separate documents.
>
> Secondly, we need to be a lot more rigid in terms of what ICVs,
> Timestamps, etc. are added/removed, and what that brings.
>
> For example (with the assumption that messages are *forwarded* and *not*
> regenerated), this could be one option:
>
>                         o          When a RREQ, RREP message is generated=
,
> add an ICV Message TLV, which is calculated 
>                                      =E2=80=A6(take inspiration from RFC7=
183 here)
>
>
> ...
>
> [Message clipped]
> _______________________________________________
> 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
>
>
>
> ********************************************************************
> 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
>
>

--001a11351d9e686add05314ff672
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The address in the RREP_Ack may be required due to the RRE=
P_Ack being multicast as there is not yet a verified unicast route installe=
d yet.=C2=A0 Going to double check if I'm remembering correctly.=C2=A0<=
br>
Justin
On 25 Apr 2016, at 15:27, Dearlove, =
Christopher (UK) <chris.dearlove@baesystems.com> wrote:

Assuming for the moment that everyone will =
need an RREP-Ack or won=E2=80=99t (let=E2=80=99s come back to that) why =
do C and B need to put an address in as an RREQ-Ack request? Why not a =
flag, because the address will be included as the IP sending address - =
and we know 5444 is required to pass that on. (It=E2=80=99s used by NHDP =
as well.) Then we don=E2=80=99t need to change the RREP, it will have a =
flag set or not, and won=E2=80=99t change (in this regard).
 
Now let=E2=80=99s =
consider do we know whether we can set a fixed flag. First I=E2=80=99d =
say there are two cases - you=E2=80=99ve got a firm control on what=E2=80=99=
s going on in your network, or it=E2=80=99s one of unknown parties and =
behaviour (consistent with specification). In the former case you only =
want one setting, for example no-Ack if running NHDP or your MAC layer =
tells you about bidirectionality, Ack otherwise. In the latter case, I =
think you just always want an Ack. So both cases get you to the same =
place.
 
Should that not be an =
acceptable argument (though I think it=E2=80=99s good for where we are - =
in fact always Ack is close) then at flag is a step better, it=E2=80=99s =
a fixed location to change. However it would be better in that case if =
the two things to change (metric and ack flag) were together. But that =
has its own issues, so I won=E2=80=99t go there.
 
--
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: Victoria Mercieca [mailto:vmercieca0@gmail.com] 
Sent: 25 =
April 2016 14:15
To: Jiazi YI
Cc: Dearlove, Christopher (UK); =
Christopher Dearlove; Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] Message =
integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 =
review - a couple of big ticket Items)
 
 
*** 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.
Hi Jiazi,


 
On Mon, Apr 25, 2016 =
at 1:04 PM, Jiazi YI <ietf@jiaziyi.com> wrote:
Hi, 
 
On Mon, Apr 25, 2016 at 11:20 AM, =
Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
With regard to your validity time point, we here have a =
tradeoff. If you allow that feature, it significantly impacts on the =
approach that was coming together on as best you can end to end =
encryption.
 
So the question is, is this a feature =
that=E2=80=99s really wanted? Unfortunately I think we know that the =
answer to that is, we don=E2=80=99t know because we don=E2=80=99t have =
any experience. My view would be that in the tradeoff of an untested =
feature (unless I=E2=80=99m wrong about that) and the security =
complication, security wins and drop the feature. If there is some real =
requirement, then there=E2=80=99s a discussion. (Questions like how =
often the intermediate routers actually have any knowledge - typically =
links break for unexpected rather than expected reasons. Andan =
intermediate router could possibly use a validity time to influence its =
behaviour.) Note that dropping the ability of intermediate routers to =
modify/set still allows validity times per route to be set at =
endpoints.
 
I agree with Chris' concern.
The ValidityTime is optional, which makes the integrity =
protection hard. Furthermore, it gives a potential attack vector: as all =
the routers in a path will take the shortest validityTime, a compromised =
router can set the the validityTime to a very short value, which will =
make the route installed along the path became invalid (very =
soon). 
 
On the other hand, I'm not sure this option will give =
us much help. Chris mentioned much knowledge intermediate router would =
have to decide this value (and how much sense the value would =
make). 
Another issue is, a route to a =
destination might be updated by different sources. For example, in the =
network below:
 
A----B-----C
 
A first establish a route to B with long validity =
time. Then A initiates a route discovery to C. C tends to set a short =
validity time, which will make the route between B and A expire earlier =
than expected. 
Is this a problem? Maybe yes, maybe no -- =
I'm not sure it's considered or not. 
 
 
Not sure I follow here.
Currently, the validity time of the route between A and =
B would not affected by a short validity time of a route between A and =
C. Validity times are per-route, and the route A-B and the route A-C are =
separate.
If we switched to a validity time per =
neighbor (so that we can keep validity time separate from route =
advertisements) as I mentioned in the email below, then the validity of =
a route between A and C would be affected if there was a short validity =
time between A and B. But, if B will only route for a certain amount of =
time, then the route between A and C will of course be affected. Is it =
best to know in advance that there's a time limit, or just deal with =
RERRs when they happen?
 
 
 
With regard to the acknowledgements, the =
problem (with regard to security) comes from trying to do two jobs with =
the same message - end to end route advertisement and hop by hop =
acknowledgement. I understand the reasons - saving bytes and message =
types. (I would have to study the protocol really hard to identify if =
any message types can be folded together and recognised by content =
rather than type efficiently. This I do not expect to do.) Again a =
tradeoff. This one is in discussion space, though that needs people who =
understand both sides of the issue, including the details of the =
bidirectionality mechanism. Of course, as has been said, we need one of =
those.
 
I haven't finished my review of the latest draft, and =
I don't get the necessity of AckReq and the corresponding multicast RREP =
yet. 
If possible, this "optional" field should =
be avoided. 
 

To=
 give an overview of AckReq and RREP:
Since AODVv2 =
requires bidirectional links, this is the way to determine if a link is =
bidirectional.
A----B----C

1) A sends RREQ, B forwards it, C receives the =
RREQ. B and C both install a route to OrigAddr but they dont yet know if =
it's valid because they dont know if the link to their next hop is =
available in the reverse direction.
2) C creates the =
RREP. Since it doesnt know if the link to B is bidirectional, it =
includes the AckReq (an address to indicate that it expects to receive a =
RREP_Ack from B).
3) B receives the RREP, installs a route =
to TargAddr and marks it as valid, since it knows the link to C is =
bidirectional, because the RREQ went in one direction and the RREP came =
in the other. B also sends the RREP_Ack to C and forwards the RREP to A =
(and might change the message to indicate its own AckReq - ie that it =
requires an ack from A).
4) C receives the =
RREP_Ack from B, and therefore knows that B received the RREP, therefore =
the link is bidirectional. C can then mark its route to OrigAddr as =
valid.
5) Similarly, A receives the RREP, =
installs the route to TargAddr and sends an RREP_Ack to B.
6) B receives the RREP_Ack and marks its route to OrigAddr as =
valid.
 
Alternatively, in step 2, if C knows the link to B is =
bidirectional (perhaps from some earlier route discovery), it doesnt =
need to put the AckReq in the RREP. Then in step 3, since B doesnt know =
if the link to A is bidirectional, it changes the message to add the =
AckReq address, in order to get an RREP_Ack from A.
If we want to avoid changing the message, we'll need to =
look at forwarding the RREP as-is, and creating a second message to =
solicit an RREP_Ack, in order to verify that the link is bidirectional =
before marking the route to OrigAddr as valid. 
Kind regards,
Victoria.
 
 
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
 
From: Victoria Mercieca =
[mailto:vmercieca0@gmail.com] 
Sent: 23 =
April 2016 10:55
To: Christopher Dearlove
Cc: ietf@thomasclausen.org; Dearlove, Christopher (UK); =
Mobile Ad Hoc Networks mailing list

Subject: Re: [manet] Message =
integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 =
review - a couple of big ticket Items)
 
 
*** 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.
Hi Chris,
 
These have both been in the draft in some =
form since before I got involved... but I'll do my best to explain.
 
- For Validity Time, its a way to =
advertise that you would only support the route contained in the message =
for a certain period of time. The originator might use this, but the =
draft was written to allow any intermediate node to be able to add it or =
update it too. The route created in the Local Route Set has an =
expiration time associated with it, based on the received validity =
time.
- For the AckReq address, its so that you =
can add into a RREP a request for an acknowledgement, so that you don't =
have to have a different message type altogether for working out whether =
links to neighbors are bidirectional, and also, since you only care =
about bidirectionality on routes that are being set up, you dont need to =
constantly monitor all neighbors.
 
 
In order to avoid the potential =
AckReq-related changes to each message, maybe we do need to introduce a =
different message specifically for this. We could maybe use RREP_Ack to =
both request and acknowledge? It means an extra message of control =
traffic that needs to be sent, maybe one extra message per hop on the =
path of a RREP, but it could still be limited to neighbors which have =
participated in the route discovery rather than monitoring all neighbors =
at all times. 
 
This message could maybe also include "I'm happy to route =
anywhere for a certain amount of time", sort of like willingness in =
OLSR/OLSRv2. So instead of having a validity time per route, its a =
validity time per neighbor. Then, for RREQ and RREP, only the metric =
value would change in transit, as discussed. However, that leads to some =
issues with deciding what a route's expiration time is. You might know =
how long the next hop router is valid for, but what if a router beyond =
that, which was also part of the route, had a lower validity time? You =
couldn't determine the real validity time. Do we remove the route =
expiration time altogether to avoid this issue? In which case, we would =
have to rely on RERR messages being sent for routes which become invalid =
when the neighbor's validity time has expired? So neighbor validity time =
expiration is treated the same as a link break.
 
What do you think?
 
Kind regards,
Victoria.
 
 
 
 
 
 
On Sat, Apr 23, 2016 =
at 1:09 AM, Christopher Dearlove <chris@mnemosyne.demon.co.uk> wrote:
Pretty much all of the discussion has =
been assuming only a metric value change. With multiple things changing =
many of the ideas go out of the window. That reinforces the point about =
not making specifications now that might turn out to be wrong for =
ICVs.
 
Ignoring how this misunderstanding happened, I'll start by =
asking why. Metric changing I understand. Why the other two? (there's a =
partial explanation of one). What alternatives have people implemented =
in comparable protocols?

--  
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)

On 23 Apr 2016, at 00:26, Victoria =
Mercieca <vmercieca0@gmail.com> wrote:
Hi all,
 
Continued in this thread because the other one seems to be =
more about TLV types and metric type numbers, whereas this is about =
regeneration/forwarding.
 
To recap, in the current draft, there are 3 things that might =
change at each hop: 
- the metric value (happens in RREQ and RREP), 
- =
adding/changing Validity Time using the Validity Time TLV (can happen in =
RREQ and RREP), 
- adding an address (and corresponding value in the =
AddressType TLV to indicate how to interpret the address) to indicate =
the address from which an RREP_Ack is expected, to accomplish the =
bidirectionality check (can happen in RREP).

If we define a certain portion of the message as =
immutable and include the ICV to verify that part, end to end: 
- The metric =
value would be excluded from the ICV since it needs changing at each =
hop. 
- Would adding a Validity Time TLV at an =
intermediate hop be acceptable? The whole TLV could be removed in order =
to calculate the ICV?
- Would adding an address cause issues =
for the ICV, because it's in the address block? Could the rule be "if it =
contains an AckReq address, remove it (and the corresponding value in =
the AddressType TLV), before checking the ICV", is that OK? Or would we =
need to avoid touching the ICV'ed part of the message altogether, maybe =
put the AckReq address in a separate Address Block, with an extra =
AddressType TLV following that address block? Is there a way to =
accomplish this?
 
Also, to be thorough, do we need to consider RERR messages =
while we discuss regeneration vs forwarding? 
- RERR (sent when a link breaks) is a way of saying "I've =
lost my route so I'm telling others" and "you were my next hop, =
so now I've also lost my route, I'll tell others", etc. It's =
going to be tailored at each step to include the relevant routes that =
got deleted, it's not one message being sent end-to-end like RREQ and =
RREP are. 
- However, RERR (sent when a source of =
traffic is sending data on a route which comes through you, and you want =
to tell the Packet Source's router to delete the route) could be seen as =
an end-to-end message which all intermediate routers learn from, similar =
to RREQ and RREP. It reports one route, and doesn't need changing at =
intermediate hops, so could be protected with ICV.
- Would it be OK to only require a message ICV if a PktSource =
address was included, i.e. when the message needs to go via a number of =
intermediate hops to PktSource's router? All other RERRs are intended to =
be one-hop messages, which may in turn prompt other one-hop messages, =
etc..., and a packet ICV might be more appropriate?
 
Kind regards,
Victoria.
 
On Thu, Mar 17, 2016 at 5:26 PM, <ietf@thomasclausen.org> wrote:
 
On 17 Mar 2016, at =
18:17, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
 
Yes, I meant AODVv2, thanks for the =
catch.
 
So is your (Thomas) proposed base =
specification a hop count only metric?
 
No, =
the would be silly as base specification, given that hop count mostly is =
useless.
 
As base specification I would simply say =E2=80=9CInclude a =
Metric Type Message TLV with a value field, and a 7182 Message TLV & =
Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage as =
to generation and processing). 
 
With the message generated by the originator of the RREQ/RREP =
and *not* deconstructed/reconstructed/reordered (as is the risk with =
=E2=80=9Cregeneration) allows knowing that it would be *only* that =
metric field being modified (other than hop count/limit) for when =
eventually writing up the extension.
 
(Actually doesn=E2=80=99t the current =
specification only define hop count, or has that changed in latest =
draft?)
 
No. =
That is one of the issues I raise in my original. For some reason, it =
cites RFC6551, which is a ROLL document and which has in its abstract =
that:
 
   Low-Power and Lossy Networks (LLNs) have unique =
characteristics
   compared with traditional wired and ad hoc =
networks that require the
   specification of new routing metrics and =
constraints. 
 
I.e. this document cites a metric document which clearly =
claims to be inapplicable in ad hoc networks. I note that this is =
another thing I=E2=80=99ve raised for years without seeing it attempted =
resolved.
 
Best,
 
Thomas
 
 
 
--
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: ietf@thomasclausen.org [mailto:ietf@thomasclausen.org] 
Sent: 17 March 2016 17:10
To: Dearlove, Christopher (UK)
Cc: Lotte Steenbrink; Mobile Ad Hoc =
Networks mailing list
Subject: Re: =
[manet] Message integrity and message mutability (was RE: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket =
Items)
 
 
*** 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 =
17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
 
OK, so we have a =
message that mutates by:
- =
Modifying hop count/limit.
- =
Modifying a metric value.
Anything else?
 
As mutating (other than hop count/limit) =
messages aren=E2=80=99t covered by 5444 or any derivative document (but =
only recommended against, not banned) that you may need to make the =
message otherwise immutable (no deconstruction and rebuilding, other =
than guaranteed unchanging) that would have to be specified by AODVv2. =
(Easy to say, but needs saying.)
 
With you so far.
 
Then that information is not in a guaranteed fixed location =
given by a simple offset. So any signature algorithm that finds it and =
ignores it or aggregates on it is specific to OLSRv2.
 
Surely you mean AODVv2
 
So =
standard 7182 ICVs don=E2=80=99t do the job, you would need an AODVv2 =
specialised variant. Which is the sort of thing that the message =
specific TLV space is there for, I=E2=80=99d be strongly against a =
=E2=80=9Cbut ignore the value of this specific TLV should it occur=E2=80=9D=
 being in the general space. However it can easily be defined by =
reference to 7182 (=E2=80=9Cthis TLV is like that TLV, except if an X =
TLV is present, set its value field to zero=E2=80=9D).
 
Messy, but could work.
 
Not that messy, actually, although clearly not as =
nice as =E2=80=9Cfixed offset=E2=80=9D.
 
That said, I am arguing for the base spec =
being:
 
          &nb=
sp; =E2=80=9Cmake the message otherwise immutable (no =
deconstruction and rebuilding, other 
          &nb=
sp;  than guaranteed unchanging)=E2=80=9D which is afforded by =
forwarding
 
          &nb=
sp;            =
;            &=
nbsp;+
 
          &nb=
sp; RFC7182 Timestamps and ICVs.
 
          &nb=
sp;            =
;            &=
nbsp;+
 
          &nb=
sp; RFC7183 style text bringing it all together.
 
The =E2=80=9Caggregated signatures around =
mutable field=E2=80=9D would very be an experimental extension.
 
What I object to is, if the base spec =
specifically renders such extensions impossible
 
 
 
--
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: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de] 
Sent: 17 March 2016 16:48
To: Dearlove, Christopher (UK)
Cc: ietf@thomasclausen.org; Mobile Ad Hoc =
Networks mailing list
Subject: Re: =
[manet] Message integrity and message mutability (was RE: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket =
Items)
 
 
*** 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.
Hi =
all,
 
Am 17.03.2016 um 17:44 schrieb Dearlove, =
Christopher (UK) <chris.dearlove@baesystems.com>:
 
Good point about whether you just pass on =
one cost or a set of costs. As I said, not looked at details - I will, =
when time permits. One cost is much easier, and yes, it reduces the =
fixed size aggregated signatures problem to =E2=80=9Cjust=E2=80=9D one =
of computational load.
 
For the record, Thomas=E2=80=99 understanding is correct; the =
cost is one aggregated value. 
 
Best regards, 
Lotte =
Steenrbink
 
 
--
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: ietf@thomasclausen.org [mailto:ietf@thomasclausen.org] 
Sent: 17 March 2016 16:38
To: Dearlove, Christopher (UK)
Cc: Mobile Ad Hoc Networks mailing =
list
Subject: Re: Message integrity =
and message mutability (was RE: [manet] draft-ietf-manet-aodvv2-13 =
review - a couple of big ticket Items)
 
 
*** 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 17 Mar 2016, at =
17:30, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
 
I appreciate Thomas=E2=80=99s comments =
about the limitations of message regeneration, but I would be a bit less =
absolute.
 
The issues over end to =
end authentication and more advanced signatures are valid. I need to =
read the given reference on aggregate signatures to increase my =
knowledge (thanks for it), but my understanding of the possibilities in =
this field may offer a solution to the problem, but with some other =
issues (possibly including a new type of TLV).
 
But the hop count/limit =
point I don=E2=80=99t fully agree with, you can regenerate with an =
incremented/decremented count/limit, which leaves the ability to prevent =
messages propagating indefinitely, including expanding ring searches, =
and retains the ability to use RFC 5497 interval and validity times that =
might be useful with an expanding ring search (or might not).
 
But the key issue is =
that AODVv2 wants to accumulate metrics. I still haven=E2=80=99t got to =
the bottom of many details here, but let=E2=80=99s for the moment just =
consider that conceptually.
 
It=E2=80=99s hard to =
handle end to end. Charlie=E2=80=99s draft attempts to do an end to end =
of some information, not this information. I=E2=80=99m not sure if =
that=E2=80=99s useful (and the specialised format is better avoided if =
possible). Other approaches are hop by hop (might as well use packet =
signatures) and shared key (might as well go hop by hop). Pairwise =
signatures for each pair of routers I=E2=80=99m discounting as scaling =
terribly. In the interests of completeness let=E2=80=99s mention not =
accumulating metrics, which puts us back to hop count and that=E2=80=99s =
not ideal either.
 
I don=E2=80=99t think =
there is an ideal solution. (I like ideas I=E2=80=99ve seen about =
aggregating, but that has some issues of its own, even apart from =
computational load.) I=E2=80=99d love to be proved wrong - someone with =
the perfect solution to come along.
 
Which means that either =
we make an arbitrary choice - which will be disagreed with, but needs =
discussing first - or create something flexible. Unfortunately flexible =
in that regard constrains in others, e.g. some (many? most?) aggregating =
signatures need fixed data sizes (which we can do by defining a TLV that =
=E2=80=9Cfills up=E2=80=9D with hop count, but that has a cost =
too).
 
I =
have been told by people much more well versed in this than I in =
cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
 
That said, "AODVv2 wants to accumulate =
metrics=E2=80=9D =E2=80=94 does that mean that the message grows as it =
is being forwarded, and that the recipient of a RREQ/RREP will know the =
individual costs of each path segment? My understanding is, that the =
recipient will get =E2=80=9Cthe sum the costs of each path segment=E2=80=9D=
 which should be fitting within a fixed size?
 
Thomas
 


 
Sorry, no answers, just =
comments. And I=E2=80=99m not addressing Thomas=E2=80=99s later points =
here.
 
--
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 ietf@thomasclausen.org
Sent: 17 March 2016 16:00
To: Mobile Ad Hoc Networks mailing list
Subject: [manet] =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket =
Items
 
 
*** 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.
 
Dear all,
 
Apologies for not having gotten this done =
sooner - day-job leaving few spare cycles.
 
I=E2=80=99ve previously offered reviews =
and comments, and some of those have been addressed in the latest I-D =
=E2=80=94 others have not, but should be. I recall that there was some =
mail attempting to rebut parts of the review, and I will dig it out and =
reply to that.
 
With that being said, I have reviewed the =
latest version of the document, and full details will be forthcoming. =
There=E2=80=99re a couple of big-ticket/architectural items that I want =
to address up front, as I believe that before we have those hammered =
out, it will be useless to go into details. Note, I do not claim that =
this is an exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D, but =
that=E2=80=99s as far as I have gotten in thinking this through.
 
I also bring these up as they are items =
that have been brought up repeatedly over the past years, but not =
resolved nor discussed.
 
Loops
Just to bring this out: I share Chris=E2=80=
=99 worry about conflicting and concurrent statements from the authors =
on =E2=80=9CThere are no loops possible=E2=80=9D and =E2=80=9CWe need to =
fix two situations where loops can occur=E2=80=9D and =E2=80=9Cwe are =
still investigating some loop conditions=E2=80=9D
 
I particularly worry that this is not a =
discussion had in public, but apparently in some other forum=E2=80=A6
 
 
Intermediate Route Replies, and all of section 10
Section 10 contains a set of =E2=80=9Cvague=
ly specified extensions=E2=80=9D, which is incoherent with the intended =
status indicated for this document. 
 
Specifically, and this is not unrelated =
to the point about loops above, intermediate RREPs (section 10.3) are a =
potential source for loops.
 
Expanding Ring Multicast (section 10.1) =
is not documented in a way that can be implemented (and also, see =
=E2=80=9CForwarding-vs-regeneration=E2=80=9D below, it is in the present =
form of this protocol impossible), etc.
 
 
Forwarding-vs-regeneration
Recent exchanges on the list made me =
understand that protocol control messages are *not* forwarded, but are =
consumed at each hop, then a new message with (almost-but-not-quite) the =
same content is generated and transmitted.
 
I have thought some more on this (& =
read some of the exchanges on the list on this topic by Chris, Ulrich, =
and others), and I am convinced that this is not the right way to =
go, at least for the following reasons:
 
 
          &nb=
sp; o          It renders the hop-limit/hop-count fields in the RFC5444 =
message header useless.
          &nb=
sp;            =
; This would not be bad if the functionality offered by those =
fields was not useful
          &nb=
sp;            =
; =E2=80=94 sadly, it is. For example, for scope limited flooding =
(expanding ring search, and 
          &nb=
sp;            =
; such) which may be of interest, and which require =
hop-limit. 
          &nb=
sp;            =
; A hop-count field may also provide a =E2=80=9Ccheap=E2=80=9D (in =
terms of overhead) additional piece
          &nb=
sp;            =
; of information to use conjunctively with a =E2=80=9Creal=E2=80=9D =
metric.
 
          &nb=
sp;            =
; The only practical solution would be to re-introduce these =
functions by way of inserting a
          &nb=
sp;            =
; MessageTLV =E2=80=94 which (i) is not specified in this document, =
and (ii) which would just
          &nb=
sp;            =
; serve to render messages bigger than strictly needed.
 
          &nb=
sp;            =
; Scope limited flooding  does seem to be a necessary =
requirement, if for no
          &nb=
sp;            =
; other reason than to prevent information from =E2=80=9Ccirculating =
forever in the network=E2=80=9D.
 
          &nb=
sp; o          It makes end-to-end authentication =
unnecessarily hard.
          &nb=
sp;            =
; I think Chris called this out already, but it bears repeating: S =
generates a message 
          &nb=
sp;            =
; (say, a RREQ), and includes an ICV calculated over the content of =
the message.
          &nb=
sp;            =
; For any recipient to be able to validate the ICV, the message has =
to be exactly
          &nb=
sp;            =
; the same =E2=80=94 not just in content, but in structure =E2=80=94 =
as what was generated.
 
          &nb=
sp;            =
; =E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforwarding=E2=80=
=9D messages means, that the intermediate
          &nb=
sp;            =
; router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose a =
different structure (e.g., include TLVs
          &nb=
sp;            =
; in a different order).
 
          &nb=
sp;            =
; The proposal from https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00<=
/span>
          &nb=
sp;            =
; is to add constraints on (i) the set of elements to include in a =
signature and (ii) the
          &nb=
sp;            =
; order of these elements.
 
          &nb=
sp;            =
; One problem with that approach is (i): if an extension adds =
a message TLV, or an 
          &nb=
sp;            =
; Address TLV, to a message, then that will not be =E2=80=9Ccovered=E2=
=80=9D by the proposed e2esec TLV.
          &nb=
sp;            =
; Rather for *each* extension developed, an =E2=80=9Cupdates =
e2esec=E2=80=9D clause needs to be done.
 
          &nb=
sp;            =
; I=E2=80=99d say that this approach would be prone to errors =E2=80=94=
 and add entropy to the process
          &nb=
sp;            =
; of designing protocol extensions. The alternative, a message =
being generated by the
          &nb=
sp;            =
; source and *forwarded* (as we do in OLSRv2, for example) would =
allow ICV TLVs 
          &nb=
sp;            =
; (even, allow reuse of those specified for OLSRv2) for covering a =
message and 
          &nb=
sp;            =
; extensions.
 
          &nb=
sp;            =
; =E2=80=9CBut what about the metrics value which will change on =
each hop=E2=80=9D, you may say?
          &nb=
sp;            =
; Fortunately, that is relatively easy to handle: simply zero out =
the value of that TLV when
          &nb=
sp;            =
; generating or verifying the ICV MessageTLV. And use Packet-TLVs =
for hop-by-hop 
          &nb=
sp;            =
; authentication, if needed (but, see below).
 
          &nb=
sp; o          It prevents the use of more clever/advanced =
signature schemes/ICVs
          &nb=
sp;            =
; Aggregate signature algorithms ( https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
          &nb=
sp;            =
; discussed above, or something smarter).
 
There are other reasons, but the above =
are those that jump at me as immediate show-stoppers.
 
I do honestly not see what possible =
benefit there is from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see =
very clear inconveniences, and security is not the least of these. =
Insisting on =E2=80=9Cregeneration=E2=80=9D requires development of =
=E2=80=9Cnon-general workarounds=E2=80=9D as pointed out above.
 
Security =
Considerations
This is an always thorny subject. When =
OLSRv2 was going through the process we got a thorough education in how =
little we knew about security from the SEC-ADs, and had to spend about a =
year or so developing RFC7183. The bottom line is, that this protocol =
needs its =E2=80=9CRFC7183  equivalent=E2=80=9D, either as part of =
the main document, or as an independent document. currently, that is not =
the case.
 
A minima, looking at BCP72 and BCP107 =E2=80=
=94 taking inspiration from RFC7183 might be aw good idea, as that was =
the most recent that went through the SEC AD. Regardless of how, =
however, a =E2=80=9Cmandatory to implement=E2=80=9D security mechanism =
most be specified (I think the right term was =E2=80=9CMUST implement, =
SHOULD use=E2=80=9D), in sufficient detail to ensure interoperable =
implementations.
 
As an example, both [RFC6130] and =
[RFC7181] set out that that:
 
      On receiving a ... =
message, a router MUST first check if the
      message is invalid =
for processing by this router
 
and then proceed to give a number of =
conditions that, each, will lead to a rejection of the message as "badly =
formed and therefore invalid for processing=E2=80=9D =E2=80=94 a list =
which RFC7183 then amended. That gave a =E2=80=9Chook=E2=80=9D for =
RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message =
generation.
 
If I was to do RFC7181/RFC6130 today, I =
would include that directly into the protocol specifications. It turned =
out to be more overhead (and slow down publication anyways) to do it as =
separate documents.
 
Secondly, we need to be a lot more rigid =
in terms of what ICVs, Timestamps, etc. are added/removed, and what that =
brings.
 
For example (with the assumption that =
messages are *forwarded* and *not* regenerated), this could be one =
option:
 
          &nb=
sp;            =
; o          When =
a RREQ, RREP message is generated, add an ICV Message TLV, which is =
calculated <this way>
          &nb=
sp;            =
;            &=
nbsp; =E2=80=A6(take inspiration from RFC7183 here)
 
...

[Message =
clipped]  
_______________________________________________
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

On Mon, Apr 25, 2016 at 10:18 AM,  <ietf@thomasclausen.org><=
/span> wrote:
Hi,

I must admit that while I have reviewed the=
 protocol several times, I=E2=80=99ve not been digging that deep into the p=
rotocol functioning to catch this issue of how invasive the protocol operat=
ions are when forwarding a message: there were other =E2=80=9Cmajor=E2=80=
=9D issues to address (and which obscured the details), so as a first order=
: thank you Victoria, for having called attention to this.

To the substance of these emails.

I am af=
raid that I do not understand the use of inserting validity TLVs while in-f=
light, into a message. Actually, I am dubious for both the originator inser=
ting this (how can the originator of a message know how =E2=80=9Clatter par=
ts of the path=E2=80=9D will be have=E2=80=9D) except if we are talking dut=
y-cycling of devices and inserting =E2=80=9Cthe remaining time that I am go=
ing to be up before I suspend=E2=80=9D. Intuitively, that would also assume=
 fairly long duty cycles =E2=80=9CI am up for tens of seconds=E2=80=9D, whi=
ch I am not sure are actually realistic. And, as Chris says in another emai=
l, this is trading off =E2=80=9Cthe ability to do security=E2=80=9D for an =
unknown/untested feature =E2=80=94 which I think is the wrong trade-off.

On he topic of =E2=80=9Cneeding to put an address in=
=E2=80=9D for RREP-ACK, I must admit that this seems roundabout. I can see =
three issues here:

	o	I am not sure t=
hat adding an address vs. a flag may not have to do with the =E2=80=9Cmulti=
ple interfaces/
		mul=
tiple addresses=E2=80=9D discrimination mechanics of the protocol? I haven=
=E2=80=99t worked it through, though,=C2=A0
		but that would be a guess.

	o	The end-to-end topology diffusion mechanism should not ne=
ed to be concerned with the=C2=A0
		=E2=80=9Cbidirectionally check=E2=80=9D of a local link (in =
part, as it encumbers security, but not only).=C2=A0 In short, a
=
		flag or an address, both are =
(equally) bad.

	o	A cleaner mechanism=
 would be a =E2=80=9Chello mechanism=E2=80=9D, not necessarily as NHDP, but=
 a =E2=80=9Cwhen=C2=A0
		forwarding a RREQ/RREP, trigger a 3-way hello exchange, if the link is =
estimated to be of a=C2=A0
	=
	type which potentially can be=C2=A0unidirectional=E2=80=9D. There i=
s another benefit to doing that, see the end=C2=A0
		of this email.

Eit=
her way, I do not like the notion of fusing metrics-and-link-bidirectionali=
ty-detection any more than I like fusing global-topology-diffusion-and-link=
-bidirectionality-detection.=C2=A0

The solution al=
l this is, to me, threefold

	1)	Facto=
r out the bidirectionally check in a (triggered) neighbour detection mechan=
ism=C2=A0
		(triggere=
d HELLO message)

	2)	Remove the =E2=
=80=9Cvalidity time TLVs=E2=80=9D, since they add complexity for no perceiv=
able benefits

	3)	Use the security mo=
del that we=E2=80=99ve discussed previously, where (only) the metrics chang=
e per hop.

Since we=E2=80=99re discussing bi-direc=
tionality of links here, and the necessity of a mechanism for handling thes=
e, I want to call attention to a related 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 =C2=A0of the do=
cument, however, reads:

   Assuming link metrics are sy=
mmetric, the cost of the routes installed
   in the Local Route Set at each router will be correct.  While this
   assumption is not always correct, calculating incoming/outgoing
   metric data is outside of scope of this document. 

<=
/div>
I do not know of any wireless systems, where the as=
sumption that =E2=80=9Clink metrics are symmetric=E2=80=9D actually holds. =
Consequently, the conclusion in the quoted paragraph:

   calculating incomin=
g/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 link the metr=
ics is 4 or 5=E2=80=9D, the protocol must be able to convey and distinguish=
 that =E2=80=9Cthe metric from A to B is 4, and the metric from B to A is 1=
9=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 c=
arefully, be used to probe for and convey metrics information, also.
<=
div>
Hope this helps,


Thomas

On 25 =
Apr 2016, at 15:27, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

Assuming for the moment that everyone will=
 need an RREP-Ack or won=E2=80=99t (let=E2=80=99s come back to that) why do=
 C and B need to put an address in as an RREQ-Ack request? Why not a flag, =
because the address will be included as the IP sending address - and we kno=
w 5444 is required to pass that on. (It=E2=80=99s used by NHDP as well.) Th=
en we don=E2=80=99t need to change the RREP, it will have a flag set or not=
, and won=E2=80=99t change (in this regard).
=C2=A0
Now let=E2=80=99s consider do we know whether we can set a =
fixed flag. First I=E2=80=99d say there are two cases - you=E2=80=99ve got =
a firm control on what=E2=80=99s going on in your network, or it=E2=80=99s =
one of unknown parties and behaviour (consistent with specification). In th=
e former case you only want one setting, for example no-Ack if running NHDP=
 or your MAC layer tells you about bidirectionality, Ack otherwise. In the =
latter case, I think you just always want an Ack. So both cases get you to =
the same place.
=C2=A0
Should that n=
ot be an acceptable argument (though I think it=E2=80=99s good for where we=
 are - in fact always Ack is close) then at flag is a step better, it=E2=80=
=99s a fixed location to change. However it would be better in that case if=
 the two things to change (metric and ack flag) were together. But that has=
 its own issues, so I won=E2=80=99t go there.
=C2=A0
--
Christopher Dearlove
Senior Principal =
Engineer
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, Chelmsfor=
d Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.c=
om/ai
BAE S=
ystems Applied Intelligence Limited
Registered in England & Wales No=
: 01337451
<=
span style=3D"font-size:8pt;font-family:Arial,sans-serif;color:rgb(58,139,1=
46)">Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP=

=C2=A0
From:=C2=A0V=
ictoria Mercieca [mailto:vmercieca0@gmail.c=
om]=C2=A0
Sent:=C2=A025 April 2016 =
14:15
To:=C2=A0Jiazi YI
Cc:=C2=A0Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc Network=
s mailing list
Subject:=C2=A0Re: [manet] Message int=
egrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - =
a couple of big ticket Items)
=C2=A0
=C2=A0
=
*** 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=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.
Hi Ji=
azi,


=C2=A0=

On Mon, Apr 25, 2016 at 1:04 PM, J=
iazi YI <ietf@jiaziyi.com> wrote:<=
/u>
Hi,=C2=A0
=C2=A0
On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> w=
rote:
With rega=
rd to your validity time point, we here have a tradeoff. If you allow that =
feature, it significantly impacts on the approach that was coming together =
on as best you can end to end encryption.
=C2=A0
So the question is, is this a feature that=E2=80=99s really wa=
nted? Unfortunately I think we know that the answer to that is, we don=E2=
=80=99t know because we don=E2=80=99t have any experience. My view would be=
 that in the tradeoff of an untested feature (unless I=E2=80=99m wrong abou=
t that) and the security complication, security wins and drop the feature. =
If there is some real requirement, then there=E2=80=99s a discussion. (Ques=
tions like how often the intermediate routers actually have any knowledge -=
 typically links break for unexpected rather than expected reasons. Andan i=
ntermediate router could possibly use a validity time to influence its beha=
viour.) Note that dropping the ability of intermediate routers to modify/se=
t still allows validity times per route to be set at endpoints.
=C2=A0=

I agree with Chris' concern.=

The ValidityTime is opti=
onal, which makes the integrity protection hard. Furthermore, it gives a po=
tential attack vector: as all the routers in a path will take the shortest =
validityTime, a compromised router can set the the validityTime to a very s=
hort value, which will make the route installed along the path became inval=
id (very soon).=C2=A0
=
=C2=A0
On the other ha=
nd, I'm not sure this option will give us much help. Chris mentioned mu=
ch knowledge intermediate router would have to decide this value (and how m=
uch sense the value would make).=C2=A0
Another issue is, a route to a destination might be update=
d by different sources. For example, in the network below:
=C2=A0
<=
div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">A--=
--B-----C
=C2=A0
A first establish a =
route to B with long validity time. Then A initiates a route discovery to C=
. C tends to set a short validity time, which will make the route between B=
 and A expire earlier than expected.=C2=A0
Is this a problem? Maybe yes, maybe no -- I'm not =
sure it's considered or not.=C2=A0
=C2=A0
=C2=A0
Not sure I follow here.
Currently, the validity time of the route =
between A and B would not affected by a short validity time of a route betw=
een A and C. Validity times are per-route, and the route A-B and the route =
A-C are separate.
If we =
switched to a validity time per neighbor (so that we can keep validity time=
 separate from route advertisements) as I mentioned in the email below, the=
n the validity of a route between A and C would be affected if there was a =
short validity time between A and B. But, if B will only route for a certai=
n amount of time, then the route between A and C will of course be affected=
. Is it best to know in advance that there's a time limit, or just deal=
 with RERRs when they happen?
=C2=A0
=C2=A0
<=
blockquote style=3D"border-style:none none none solid;border-left-color:rgb=
(204,204,204);border-left-width:1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8=
pt;margin-right:0cm">
=C2=A0=

With regard to the ackno=
wledgements, the problem (with regard to security) comes from trying to do =
two jobs with the same message - end to end route advertisement and hop by =
hop acknowledgement. I understand the reasons - saving bytes and message ty=
pes. (I would have to study the protocol really hard to identify if any mes=
sage types can be folded together and recognised by content rather than typ=
e efficiently. This I do not expect to do.) Again a tradeoff. This one is i=
n discussion space, though that needs people who understand both sides of t=
he issue, including the details of the bidirectionality mechanism. Of cours=
e, as has been said, we need one of those.
=

=C2=A0
I haven't finished my review of the lat=
est draft, and I don't get the necessity of AckReq and the correspondin=
g multicast RREP yet.=C2=A0
If possible, this "optional" field should be avoided.=C2=A0=

=C2=A0<=
/div>

To give an overview of AckReq and RREP:
Since AODVv2 requires bidirectio=
nal links, this is the way to determine if a link is bidirectional.<=
u>
A----B----C
=


1) A sends RREQ, B forwards it, C rec=
eives the RREQ. B and C both install a route to OrigAddr but they dont yet =
know if it's valid because they dont know if the link to their next hop=
 is available in the reverse direction.
2) C creates the RREP. Since it doesnt know if the link t=
o B is bidirectional, it includes the AckReq (an address to indicate that i=
t expects to receive a RREP_Ack from B).
3) B receives the RREP, installs a route to TargAddr and=
 marks it as valid, since it knows the link to C is bidirectional, because =
the RREQ went in one direction and the RREP came in the other. B also sends=
 the RREP_Ack to C and forwards the RREP to A (and might change the message=
 to indicate its own AckReq - ie that it requires an ack from A).=

4) C receives the RREP_Ack from=
 B, and therefore knows that B received the RREP, therefore the link is bid=
irectional. C can then mark its route to OrigAddr as valid.
5) Similarly, A receives the RREP, in=
stalls the route to TargAddr and sends an RREP_Ack to B.
6) B receives the RREP_Ack and marks its=
 route to OrigAddr as valid.
=C2=A0
Alternatively, in step 2, if C knows the link to B is bidirectional (=
perhaps from some earlier route discovery), it doesnt need to put the AckRe=
q in the RREP. Then in step 3, since B doesnt know if the link to A is bidi=
rectional, it changes the message to add the AckReq address, in order to ge=
t an RREP_Ack from A.
If we want to avoid changing the message, we'll need to loo=
k at forwarding the RREP as-is, and creating a second message to solicit an=
 RREP_Ack, in order to verify that the link is bidirectional before marking=
 the route to OrigAddr as valid.=C2=A0
=

Kind regards,
Victoria.
=C2=A0
=C2=A0
<=
div>
regards
=C2=A0
Ji=
azi
=C2=A0
=C2=A0
=
--
<=
b>Christopher Dearlove
Senior Principal Engineer
BAE Systems Ap=
plied Intelligence Laboratories
__________________=
________________________________________________________
<=
br>T: =C2=A0+44 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=
=C2=A0chris.dearlove@ba=
esystems.com

BAE Systems Applied Intellig=
ence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.<=
br>w=
ww.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England=
 & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Sur=
rey, GU2 7YP
=C2=A0<=
/span>
From:=C2=A0Victoria Mercieca [mailto:vme=
rcieca0@gmail.com]=C2=A0
Sent:=C2=A023 April 2016 10:55
To:=C2=A0Christopher DearloveCc:=C2=A0ietf@thoma=
sclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc Networks mailin=
g list

Su=
bject:=C2=A0Re: [manet] Message integrity and message muta=
bility (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket =
Items)
=C2=
=A0
=C2=A0<=
/u>
*** WARNING ***<=
/u>
This message originates from out=
side our organisation, 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=C2=A0=
=
Red Flags=C2=A0that you can look out=
 for in emails you receive, click=C2=A0her=
e.
If you feel the email is suspicious, please follow=C2=A0this process.
Hi Chris,
=C2=A0
<=
div>
These have both been in the draft in some form s=
ince before I got involved... but I'll do my best to explain.=

=C2=A0
=

- For Validity Time, its a way to advertise that you=
 would only support the route contained in the message for a certain period=
 of time. The originator might use this, but the draft was written to allow=
 any intermediate node to be able to add it or update it too. The route cre=
ated in the Local Route Set has an expiration time associated with it, base=
d on the received validity time.
- For the AckReq address, its so that you can add into a RREP =
a request for an acknowledgement, so that you don't have to have a diff=
erent message type altogether for working out whether links to neighbors ar=
e bidirectional, and also, since you only care about bidirectionality on ro=
utes that are being set up, you dont need to constantly monitor all neighbo=
rs.
=C2=A0
=C2=A0
<=
div>
In order to avoid the potential AckReq-related c=
hanges to each message, maybe we do need to introduce a different message s=
pecifically for this. We could maybe use RREP_Ack to both request and ackno=
wledge? It means an extra message of control traffic that needs to be sent,=
 maybe one extra message per hop on the path of a RREP, but it could still =
be limited to neighbors which have participated in the route discovery rath=
er than monitoring all neighbors at all times.=C2=A0
=C2=A0
This message could maybe also include "I'm happy t=
o route anywhere for a certain amount of time", sort of like willingne=
ss in OLSR/OLSRv2. So instead of having a validity time per route, its a va=
lidity time per neighbor. Then, for RREQ and RREP, only the metric value wo=
uld change in transit, as discussed. However, that leads to some issues wit=
h deciding what a route's expiration time is. You might know how long t=
he next hop router is valid for, but what if a router beyond that, which wa=
s also part of the route, had a lower validity time? You couldn't deter=
mine the real validity time. Do we remove the route expiration time altoget=
her to avoid this issue? In which case, we would have to rely on RERR messa=
ges being sent for routes which become invalid when the neighbor's vali=
dity time has expired? So neighbor validity time expiration is treated the =
same as a link break.
=
=C2=A0
What do you thi=
nk?
=C2=A0
Kind regards,
=

Victoria.
<=
div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
<=
div>
=C2=A0
On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <chris@mnemosyne.demon.co.uk> wrote:
Pretty much all of the disc=
ussion has been assuming only a metric value change. With multiple things c=
hanging many of the ideas go out of the window. That reinforces the point a=
bout not making specifications now that might turn out to be wrong for ICVs=
.
=C2=A0=

Ignoring how this misunderstanding =
happened, I'll start by asking why. Metric changing I understand. Why t=
he other two? (there's a partial explanation of one). What alternatives=
 have people implemented in comparable protocols?

-- =C2=A0
Christopher Dearlove

On 23 A=
pr 2016, at 00:26, Victoria Mercieca <vm=
ercieca0@gmail.com> wrote:
Hi all,
=
=C2=A0
Continued in th=
is thread because the other one seems to be more about TLV types and metric=
 type numbers, whereas this is about regeneration/forwarding.=

=C2=A0
To recap, in the current draft, there are 3 things=
 that might change at each hop:=C2=A0
- the metric value (h=
appens in RREQ and RREP),=C2=A0
- adding/changing Validity =
Time using the Validity Time TLV (can happen in RREQ and RREP),=C2=A0=

- adding an address (and corresponding value in the AddressType =
TLV to indicate how to interpret the address) to indicate the address from =
which an RREP_Ack is expected, to accomplish the bidirectionality check (ca=
n happen in RREP).

If we define=C2=A0a certain portion of the messag=
e as immutable and include the ICV to verify that part, end to end:=
=C2=A0
- The metric value would be excluded from the ICV since it=
 needs changing at each hop.=C2=A0
- Would adding a Validity Time TLV at=
 an intermediate hop be acceptable? The whole TLV could be removed in order=
 to calculate the ICV?
- Wo=
uld adding an address cause issues for the ICV, because it's in the add=
ress block? Could the rule be "if it contains an AckReq address, remov=
e it (and the corresponding value in the AddressType TLV), before checking =
the ICV", is that OK? Or would we need to avoid touching the ICV'e=
d part of the message altogether, maybe put the AckReq address in a separat=
e Address Block, with an extra AddressType TLV following that address block=
? Is there a way to accomplish this?
=C2=A0
=
Also, to be thorough, do we need to consider RERR messages while we discuss=
 regeneration vs forwarding?=C2=A0
- RERR (sent when a link breaks) is a way of saying "I=
9;ve lost my route so I'm telling others" and "you were my ne=
xt hop, so=C2=A0now=C2=A0I've also lost my route, I'll tell others&=
quot;, etc. It's going to be tailored at each step to include the relev=
ant routes that got deleted, it's not one message being sent end-to-end=
 like RREQ and RREP are.=C2=A0
- However, RERR (sent when a source of traffic is sending data on =
a route which comes through you, and you want to tell the Packet Source'=
;s router to delete the route) could be seen as an end-to-end message which=
 all intermediate routers learn from, similar to RREQ and RREP. It reports =
one route, and doesn't need changing at intermediate hops, so could be =
protected with ICV.
- =
Would it be OK to only require a message ICV if a PktSource address was inc=
luded, i.e. when the message needs to go via a number of intermediate hops =
to PktSource's router? All other RERRs are intended to be one-hop messa=
ges, which may in turn prompt other one-hop messages, etc..., and a packet =
ICV might be more appropriate?
=C2=A0
Kind regard=
s,
Victoria.<=
/div>
=C2=A0
On Thu, Mar 17, 2016 at 5:26 PM, <ietf@thomasclausen.org> wrote:
=C2=A0
On 17 Mar 20=
16, at 18:17, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
=C2=A0
Yes, I meant AODVv2, thanks for the catch.
=C2=A0
So is your (=
Thomas) proposed base specification a hop count only metric?<=
u>
=C2=
=A0
No, the would be silly =
as base specification, given that hop count mostly is useless.
=C2=A0
As base specification I would simply say =E2=80=
=9CInclude a Metric Type Message TLV with a value field, and a 7182 Message=
 TLV & Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verb=
iage as to generation and processing).=C2=A0
=

=C2=A0
With the message generated by the originator of the RREQ/RREP and *=
not* deconstructed/reconstructed/reordered (as is the risk with =E2=80=9Cre=
generation) allows knowing that it would be *only* that metric field being =
modified (other than hop count/limit) for when eventually writing up the ex=
tension.
=C2=
=A0
(Actually doe=
sn=E2=80=99t the current specification only define hop count, or has that c=
hanged in latest draft?)
=C2=A0
No. That is one of the issues I raise in my original. For some rea=
son, it cites RFC6551, which is a ROLL document and which has in its abstra=
ct that:
=C2=A0=

=C2=A0=C2=A0 Low-Power and Lossy Netwo=
rks (LLNs) have unique characteristics
=C2=
=A0=C2=A0 compared with traditional wired and ad hoc networks that require =
the
=C2=A0=C2=A0 specification of new routi=
ng metrics and constraints. 
=C2=A0
I.e. this docu=
ment cites a metric document which clearly claims to be inapplicable in ad =
hoc networks. I note that this is another thing I=E2=80=99ve raised for yea=
rs without seeing it attempted resolved.
=C2=A0
Best,
=C2=A0
Thomas
<=
/div>
=C2=A0
=C2=A0
=C2=
=A0
--
Christopher Dearlove
Senior Principal Engineer
BAE Syst=
ems Applied Intelligence Laboratories
____________=
______________________________________________________________

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

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow=
, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<=
u>
BAE Systems Applied Intelligenc=
e Limited
Registered in England & Wales No: 01337451
Registered Offi=
ce: Surrey Research Park, Guildford, Surrey, GU2 7YP
=C2=A0
From:=C2=A0ietf@thomasclausen.org=C2=A0[mailto:ietf@thomasclausen.or=
g]=C2=A0
Sent:=C2=A017 March 2016 17:10
To:=
=C2=A0Dearlove, Christopher (UK)
Cc:=C2=A0Lotte Steenbrink; Mobil=
e Ad Hoc Networks mailing list
Subject:=C2=A0Re: [manet] Message =
integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review=
 - a couple of big ticket Items)
=C2=A0
=C2=A0
=
*** WARNING ***
=
This message originates from outside our organisation, either from =
an external partner or the internet.
Consider carefully whether you shou=
ld click on any links, open any attachments or reply.
For information re=
garding=C2=A0Red Flags=C2=A0that yo=
u can look out for in emails you receive, click=C2=A0here.
If you feel the email is sus=
picious, please follow=C2=A0this process.
=C2=A0
On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) &l=
t;chr=
is.dearlove@baesystems.com> wrote:
<=
/div>
=C2=A0
=

OK, so we have a message that mutates b=
y:
<=
span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73=
,125)">- Modifying hop count/limit.
<=
div>
- Modifying a metric value.<=
u>
Any=
thing else?
=C2=A0
As mutating (other than hop count/limit) message=
s aren=E2=80=99t covered by 5444 or any derivative document (but only recom=
mended against, not banned) that you may need to make the message otherwise=
 immutable (no deconstruction and rebuilding, other than guaranteed unchang=
ing) that would have to be specified by AODVv2. (Easy to say, but needs say=
ing.)
=C2=A0
With you so far.
=C2=A0
Then that information is not in a guaranteed f=
ixed location given by a simple offset. So any signature algorithm that fin=
ds it and ignores it or aggregates on it is specific to OLSRv2.
=C2=A0
Surely you mean AODVv2
So=
 standard 7182 ICVs don=E2=80=99t do the job, you would need an AODVv2 spec=
ialised variant. Which is the sort of thing that the message specific TLV s=
pace is there for, I=E2=80=99d be strongly against a =E2=80=9Cbut ignore th=
e value of this specific TLV should it occur=E2=80=9D being in the general =
space. However it can easily be defined by reference to 7182 (=E2=80=9Cthis=
 TLV is like that TLV, except if an X TLV is present, set its value field t=
o zero=E2=80=9D).
=C2=A0
Messy, but could work.
=C2=A0
Not that messy, actually, althou=
gh clearly not as nice as =E2=80=9Cfixed offset=E2=80=9D.
=C2=A0
That said, I am arguing for the =
base spec being:
=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=A0than guaranteed unchanging)=E2=80=9D which is afforded by forwa=
rding
=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=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=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=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0RFC7182 Timestamps and ICVs.
=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=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=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+
=C2=A0
<=
/div>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0RFC7183 style text bringing it all toge=
ther.
=C2=
=A0
The =E2=
=80=9Caggregated signatures around mutable field=E2=80=9D would very be an =
experimental extension.
=C2=A0
What I object to is, if the base spec specifically renders such ex=
tensions impossible
=C2=A0
=C2=A0
=C2=A0
--
Christopher Dearlove
Senior Prin=
cipal Engineer
BAE Systems Applied Intelligence Laboratories
<=
/b>_____________________________________________________________=
_____________

T: =
=C2=A0+44 (0)1245 242194=C2=
=A0=C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystems.com<=
br>
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
From:=C2=A0Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]=
=C2=A0
Sent:=C2=A017 March 2016 16:48
To:=C2=A0Dearlove=
, Christopher (UK)
Cc:=C2=A0ietf@thomasclausen.org; Mobile Ad Hoc =
Networks mailing list
Subject:=C2=A0Re: [manet] Message integrity=
 and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a coup=
le of big ticket Items)
<=
div>
=C2=A0
=C2=A0
*** WARNING ***
<=
p class=3D"MsoNormal" align=3D"center" style=3D"margin:0cm 0cm 12pt;font-si=
ze:12pt;font-family:'Times New Roman',serif;text-align:center;backg=
round-color:white;background-position:0% 0%;background-repeat:initial initi=
al">This message originates from outside our organisation, eithe=
r from an external partner or the internet.
Consider carefully whether y=
ou should click on any links, open any attachments or reply.
For informa=
tion regarding=C2=A0Red Flags=C2=A0=
that you can look out for in emails you receive, click=C2=A0here.
If you feel the email=
 is suspicious, please follow=C2=A0this process.
Hi all,<=
/u>
=C2=A0=

Am 17.03.2016 um 17:44 schrieb=
 Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>:=

=C2=A0<=
u>
<=
span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73=
,125)">Good point about whether you just pass on one cost or a set of costs=
. As I said, not looked at details - I will, when time permits. One cost is=
 much easier, and yes, it reduces the fixed size aggregated signatures prob=
lem to =E2=80=9Cjust=E2=80=9D one of computational load.
=C2=A0
For the record, Thomas=E2=80=99 understanding is correct; th=
e cost is one aggregated value.=C2=A0
=

=C2=A0
Best regards,=C2=A0<=
/u>
Lotte Stee=
nrbink
=C2=A0
=C2=A0
--=

Christopher Dearlo=
ve
Senior Principal Engineer
BAE Systems Applied Intelligence Laborat=
ories
____________________________________________=
______________________________

T: =C2=A0+44 (0)1245 2=
42194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesyste=
ms.com

BAE Systems Applied Intelli=
gence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.=

=
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Regis=
tered in England & Wales No: 01337451
<=
/div>
Registered Office: Su=
rrey Research Park, Guildford, Surrey, GU2 7YP
=C2=A0=

From:=C2=A0ietf@thomasclausen.org<=
/a>=C2=A0[ma=
ilto:ietf@thomasclausen.org]=C2=A0
Sent:=C2=A017 March=
 2016 16:38
To:=C2=A0Dearlove, Christopher (UK)
Cc:=C2=
=A0Mobile Ad Hoc Networks mailing list
Subject:=C2=A0Re: Message =
integrity and message mutability (was RE: [manet] draft-ietf-manet-aodvv2-1=
3 review - a couple of big ticket Items)
=C2=A0
=C2=A0
*** WARNING ***
This message originates fr=
om outside our organisation, either from an external partner or the interne=
t.
Consider carefully whether you should click on any links, open any at=
tachments or reply.
For information regarding=C2=A0Red Fla=
gs=C2=A0that you can look out for in emails you r=
eceive, click=C2=A0here.
If you feel the email is suspicious, please follow=C2=A0this pr=
ocess.
=C2=A0
On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <=
chris=
.dearlove@baesystems.com> wrote:
=C2=A0
I appreciate Thomas=E2=80=99s comments about the limitations of message =
regeneration, but I would be a bit less absolute.
=C2=A0
The issues over end to end authentication=
 and more advanced signatures are valid. I need to read the given reference=
 on aggregate signatures to increase my knowledge (thanks for it), but my u=
nderstanding of the possibilities in this field may offer a solution to the=
 problem, but with some other issues (possibly including a new type of TLV)=
.
=C2=A0
But the hop co=
unt/limit point I don=E2=80=99t fully agree with, you can regenerate with a=
n incremented/decremented count/limit, which leaves the ability to prevent =
messages propagating indefinitely, including expanding ring searches, and r=
etains the ability to use RFC 5497 interval and validity times that might b=
e useful with an expanding ring search (or might not).=

=C2=A0
But the key issue is that AODVv2 wan=
ts to accumulate metrics. I still haven=E2=80=99t got to the bottom of many=
 details here, but let=E2=80=99s for the moment just consider that conceptu=
ally.
=C2=A0
It=E2=80=
=99s hard to handle end to end. Charlie=E2=80=99s draft attempts to do an e=
nd to end of some information, not this information. I=E2=80=99m not sure i=
f that=E2=80=99s useful (and the specialised format is better avoided if po=
ssible). Other approaches are hop by hop (might as well use packet signatur=
es) and shared key (might as well go hop by hop). Pairwise signatures for e=
ach pair of routers I=E2=80=99m discounting as scaling terribly. In the int=
erests of completeness let=E2=80=99s mention not accumulating metrics, whic=
h puts us back to hop count and that=E2=80=99s not ideal either.<=
/u>
=C2=A0
I don=E2=80=99t think ther=
e is an ideal solution. (I like ideas I=E2=80=99ve seen about aggregating, =
but that has some issues of its own, even apart from computational load.) I=
=E2=80=99d love to be proved wrong - someone with the perfect solution to c=
ome along.
=C2=A0
Whi=
ch means that either we make an arbitrary choice - which will be disagreed =
with, but needs discussing first - or create something flexible. Unfortunat=
ely flexible in that regard constrains in others, e.g. some (many? most?) a=
ggregating signatures need fixed data sizes (which we can do by defining a =
TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but that has a cost too=
).
=C2=A0
I have been told by pe=
ople much more well versed in this than I in cryptology, that the correct a=
nswer is =E2=80=9Csome=E2=80=9D.
=C2=A0
That said, &q=
uot;AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does that mean th=
at the message grows as it is being forwarded, and that the recipient of a =
RREQ/RREP will know the individual costs of each path segment? My understan=
ding is, that the recipient will get =E2=80=9Cthe sum the costs of each pat=
h segment=E2=80=9D which should be fitting within a fixed size?
=
=C2=A0
Thomas
=C2=A0
<=
/div>

=C2=A0
=

Sorry, no answers, just =
comments. And I=E2=80=99m not addressing Thomas=E2=80=99s later points here=
.
=C2=A0
--<=
u>
Christopher =
Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence L=
aboratories
______________________________________=
____________________________________

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

BAE Systems Applied Intel=
ligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8H=
N.
www.baesystems.com/ai
<=
div>
BAE Systems Applied Intelligence LimitedRegistered in England & Wales No: 01337451
=

Register=
ed Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
=C2=A0
From:=
=C2=A0manet [mailto:manet-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0<=
/b>ietf@thom=
asclausen.org
Sent:=C2=A017 March 2016 16:00
To:=
=C2=A0Mobile Ad Hoc Networks mailing list
Subject:=C2=A0[mane=
t] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items<=
u>
=

=C2=A0
=C2=A0
*** WARNING ***
This message originates from outside our organisation, e=
ither from an external partner or the internet.
Consider carefully wheth=
er you should click on any links, open any attachments or reply.
For inf=
ormation regarding=C2=A0Red Flags=
=C2=A0that you can look out for in emails you receive, click=C2=A0here.
If you feel t=
he email is suspicious, please follow=C2=A0this process.
***=C2=A0WARNING=C2=A0***
EXTERNAL EMAIL -- This message origin=
ates from outside our organization.
=C2=A0
Dear all,
=C2=A0
=

Apologies for not having gotten this done =
sooner - day-job leaving few spare cycles.
<=
/div>
=C2=A0<=
/u>
I=E2=80=99ve previously offered reviews and comments, an=
d some of those have been addressed in the latest I-D =E2=80=94 others have=
 not, but should be. I recall that there was some mail attempting to rebut =
parts of the review, and I will dig it out and reply to that.=

=C2=A0
=

With that being said, I have reviewed=
 the latest version of the document, and full details will be forthcoming. =
There=E2=80=99re a couple of big-ticket/architectural items that I want to =
address up front, as I believe that before we have those hammered out, it w=
ill be useless to go into details. Note, I do not claim that this is an exh=
austive list of =E2=80=9Cbig ticket items=E2=80=9D, but that=E2=80=99s as f=
ar as I have gotten in thinking this through.
=C2=A0<=
u>
<=
div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">I also bring these up as they are items that have bee=
n brought up repeatedly over the past years, but not resolved nor discussed=
.
=C2=A0
<=
/div>
Loops=

Just to bring this out: I share Chris=E2=80=99 worry ab=
out conflicting and concurrent statements from the authors on =E2=80=9CTher=
e are no loops possible=E2=80=9D and =E2=80=9CWe need to fix two situations=
 where loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating som=
e loop conditions=E2=80=9D
=C2=A0
=

I particularly worry that this is not a discussion had in public, but ap=
parently in some other forum=E2=80=A6
=

=C2=A0
=C2=A0
=

Intermediate Route Re=
plies, and all of section 10
<=
/div>
Section 10 conta=
ins a set of =E2=80=9Cvaguely specified extensions=E2=80=9D, which is incoh=
erent with the intended status indicated for this document.=C2=A0=

=C2=A0
<=
div>
Specifically, and this is not unr=
elated to the point about loops above, intermediate RREPs (section 10.3) ar=
e a potential source for loops.
=

=C2=A0<=
/div>
Expanding Ring Multicast (section 10.1) is not documented in a way =
that can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=
=E2=80=9D below, it is in the present form of this protocol impossible), et=
c.
=C2=A0
=

=C2=A0
Forwarding-vs-regeneration
<=
/div>
=C2=A0
I have thought some mor=
e on this (& read some of the exchanges on the list on this topic by Ch=
ris, Ulrich, and others), and I am convinced that this is not the right way=
 to go,=C2=A0at least=C2=A0for the following reasons:<=
/div>
=C2=A0
<=
div>
=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=A0o=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0It renders the hop-li=
mit/hop-count fields in the RFC5444 message header useless.
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0This would not be bad if the functionality offered by those fields=
 was not useful
=

=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=94 sadly, it is. For example, for s=
cope limited flooding (expanding ring search, and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0suc=
h) which may be of interest, and which require hop-limit.=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0A hop-count field may also provide a =E2=80=9Ccheap=E2=80=9D (in t=
erms of overhead) additional piece
=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=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0of information to use co=
njunctively with a =E2=80=9Creal=E2=80=9D metric.
=

=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0The only practical solution would be to re-introduce t=
hese functions by way of inserting a
<=
/div>
=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=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0MessageTLV =E2=80=94 =
which (i) is not specified in this document, and (ii) which would just
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0serve to render messages bigger than strictly needed.=

=C2=A0
<=
div>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Scope limited flooding =C2=A0does seem =
to be a necessary requirement, if for no
=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=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0other reason than =
to prevent information from =E2=80=9Ccirculating forever in the network=E2=
=80=9D.
=C2=A0
<=
/div>
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0It makes end-to-end auth=
entication unnecessarily hard.
=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=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I think Chris call=
ed this out already, but it bears repeating: S generates a message=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0(say, a RREQ), and includes an ICV calculated over the conte=
nt of the message.
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0For any recipient to be able to validat=
e the ICV, the message has to be exactly
=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=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the same =E2=80=94=
 not just in content, but in structure =E2=80=94 as what was generated.<=
/u>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9CRegenerating=E2=80=9D ra=
ther than =E2=80=9Cforwarding=E2=80=9D messages means, that the intermediat=
e
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose =
a different structure (e.g., include TLVs
=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=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0in a different =
order).
=C2=A0
<=
/div>
=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=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The proposal from=C2=
=A0https://tools.ietf.org/html/draft-perkins-manet-aod=
v-e2esec-00
=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=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0is to add constraints on (i) the set=
 of elements to include in a signature and (ii) the
=
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0order =
of these elements.
=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=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0One=C2=A0=
problem with that approach is (i): if an extension adds a message TLV, or a=
n=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0Address TLV, to a message, then that will not be =
=E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Rat=
her for *each* extension developed, an =E2=80=9Cupdates e2esec=E2=80=9D cla=
use needs to be done.
=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=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I=E2=
=80=99d say that this approach would be prone to errors =E2=80=94 and add e=
ntropy to the process
=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=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0of designing protocol extensions. Th=
e alternative, a message being generated by the
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0source an=
d *forwarded* (as we do in OLSRv2, for example) would allow ICV TLVs=C2=A0<=
u>
<=
div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(even, allow reuse of those specified for OLSRv2) for cov=
ering a message and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0extensions.
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9CBut what about the metrics value which wil=
l change on each hop=E2=80=9D, you may say?
=

=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=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Fortunately, th=
at is relatively easy to handle: simply zero out the value of that TLV when=

=

=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0generating or verifying the ICV MessageTLV. And use Packe=
t-TLVs for hop-by-hop=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=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0authentication, if needed (but=
, see below).
=C2=A0
<=
/div>
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0o=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0It prevents the us=
e of more clever/advanced signature schemes/ICVs
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
Aggregate signature algorithms (=C2=A0https://crypto.stanford.=
edu/~dabo/papers/aggsurvey.pdf)
<=
/div>
=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=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0exist, and an i=
nteresting use-case can be found in also reactive protocols, allowing verif=
ying
<=
div>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0not =E2=80=9Cjust=E2=80=9D the end points, but also th=
e intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D=

=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0discussed above, or something smarter).
<=
/div>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0updating to =C2=A0https://t=
ools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)=

=C2=A0
<=
div>
There are other reasons, but the =
above are those that jump at me as immediate show-stoppers.
=C2=A0
I do honestly not see what possible ben=
efit there is from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very =
clear inconveniences, and security is not the least of these. Insisting on =
=E2=80=9Cregeneration=E2=80=9D requires development of =E2=80=9Cnon-general=
 workarounds=E2=80=9D as pointed out above.
=

=C2=A0=

Security Considerations
This is an always thorny subject. When OLSRv2 was going through the pr=
ocess we got a thorough education in how little we knew about security from=
 the SEC-ADs, and had to spend about a year or so developing RFC7183. The b=
ottom line is, that this protocol needs its =E2=80=9CRFC7183 =C2=A0equivale=
nt=E2=80=9D, either as part of the main document, or as an independent docu=
ment. currently, that is not the case.
=C2=A0<=
u>
A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspi=
ration from RFC7183 might be aw good idea, as that was the most recent that=
 went through the SEC AD. Regardless of how, however, a =E2=80=9Cmandatory =
to implement=E2=80=9D security mechanism most be specified (I think the rig=
ht term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D), in sufficient de=
tail to ensure interoperable implementations.
=C2=A0<=
u>
<=
div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">As an example, both [RFC6130] and [RFC7181] set out t=
hat that:
<=
div>
=C2=A0
=

=C2=A0 =
=C2=A0 =C2=A0 On receiving a ... message, a router MUST first check if the<=
u>
<=
div style=3D"margin:0cm 0cm 0.0001pt;font-size:12pt;font-family:'Times =
New Roman',serif">=C2=A0 =C2=A0 =C2=A0 message is invalid for processin=
g by this router
=C2=A0
and the=
n proceed to give a number of conditions that, each, will lead to a rejecti=
on of the message as "badly formed and therefore invalid for processin=
g=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That gave a =E2=80=
=9Chook=E2=80=9D for RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Ide=
m for message generation.
=

=C2=A0
<=
/div>
=C2=A0
=

Secondly, we need to be a lot more ri=
gid in terms of what ICVs, Timestamps, etc. are added/removed, and what tha=
t brings.
<=
div>
=C2=A0
For example (w=
ith the assumption that messages are *forwarded* and *not* regenerated), th=
is could be one option:
=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=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0o=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0When a RREQ, RREP =
message is generated, add an ICV Message TLV, which is calculated <this =
way>
=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=A6(take inspiration from RFC7183 here)=

=C2=A0
...

[Message clipped]=C2=A0=C2=A0
_=
______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet=

=C2=A0
=

_______________________________________________
man=
et mailing list
manet@ietf.org
https://www.ietf.org/mailman/listi=
nfo/manet
=C2=A0
=

***************************************=
*****************************
This email and any attachments are confide=
ntial to the intended
recipient and may also be privileged. If you are n=
ot the intended
recipient please delete it from your system and notify t=
he 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.or=
g
https://www.ietf.o=
rg/mailman/listinfo/manet
=C2=A0
=C2=A0_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinf=
o/manet

____________=
___________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet





--001a11351d9e686add05314ff672--


From nobody Mon Apr 25 07:27: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 48E4E12D5FB for ; Mon, 25 Apr 2016 07:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.609
X-Spam-Level: 
X-Spam-Status: No, score=-6.609 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, TRACKER_ID=1.306] 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 QJ8Iv9QSaGQn for ; Mon, 25 Apr 2016 07:27:00 -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 C64FA12D603 for ; Mon, 25 Apr 2016 07:26:49 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,533,1454976000"; d="scan'208,217"; a="34189224"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 25 Apr 2016 15:26:47 +0100
X-IronPort-AV: E=Sophos;i="5.24,533,1454976000";  d="scan'208,217";a="115381046"
Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds016.greenlnk.net with ESMTP; 25 Apr 2016 15:25:39 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.34]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0248.002; Mon, 25 Apr 2016 15:25:39 +0100
From: "Dearlove, Christopher (UK)" 
To: Justin Dean 
Thread-Topic: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
Thread-Index: AQHRgGzYnQ0jbgFSiUepI05etGsIBJ9d2vAQgAAD6gCAAAGt4IAAAs+AgDjn+gCAAAvpAIAAo5QAgAMoSiCAACB6gIAAE7kAgAARySCAAACAgIAAERgg
Date: Mon, 25 Apr 2016 14:25:37 +0000
Message-ID: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1593GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: 
Cc: Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 14:27:24 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1593GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SeKAmW0gYWZyYWlkIEkgZGlkbuKAmXQgdW5kZXJzdGFuZCB5b3VyIGZpcnN0IHBhcmFncmFwaCDi
gJxmaXjigJ0uDQoNCldpdGggcmVnYXJkIHRvIHRoZSBmbGFnL2FkZHJlc3MsIEkgbXVzdCBhZG1p
dCBteSBhbmFseXNpcyB3YXMgb25lIHN0ZXAgbWlzc2luZy4gSSBnb3QgYXMgZmFyIGFzIGFyZ3Vp
bmcgaXQgd291bGQgYmUgdGhlIHNhbWUgZXZlcnl3aGVyZSBpbiBzcGFjZS4gSSBkaWRu4oCZdCB0
YWtlIHRoYXQgdGhlIGV4dHJhIHN0ZXAgKHdoaWNoIGlzIG11Y2ggdGhlIHNhbWUgYXJndW1lbnQp
IHRvIHRoZSBzYW1lIGV2ZXJ5d2hlcmUgaW4gdGltZS4gQXQgd2hpY2ggcG9pbnQgd2UgZG9u4oCZ
dCBuZWVkIHRoZSBmbGFnLSAoYW5kLCBJ4oCZbSBzYXlpbmcsIHdlIGRvbuKAmXQgbmVlZCB0aGUg
YWRkcmVzcyBiZWNhdXNlIGl04oCZcyB0aGUgSVAgc291cmNlIGFkZHJlc3MuIChUaG9tYXMgcmFp
c2VzIHRoZSBpc3N1ZSBvZiBpbnRlcmZhY2VzLiBMb2NhbGx5IHlvdSBzaG91bGQga25vdyB3aGlj
aCBpbnRlcmZhY2UgeW91IHJlY2VpdmVkIG9uIC0gYW5kIDU0NDQgdXNhZ2UgbWFrZXMgdGhhdCBj
bGVhcmVyLCBidXQgaXMgYWxyZWFkeSByZWxpZWQgb24gYnkgTkhEUC4pDQoNCi0tDQpDaHJpc3Rv
cGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBw
bGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUOiAg
KzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxt
YWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxp
ZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93
LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6
Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j
ZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJl
Z2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXks
IEdVMiA3WVANCg0KRnJvbTogSnVzdGluIERlYW4gW21haWx0bzpiZWJlbWFzdGVyQGdtYWlsLmNv
bV0NClNlbnQ6IDI1IEFwcmlsIDIwMTYgMTU6MjANClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIg
KFVLKQ0KQ2M6IFZpY3RvcmlhIE1lcmNpZWNhOyBKaWF6aSBZSTsgQ2hyaXN0b3BoZXIgRGVhcmxv
dmU7IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0DQpTdWJqZWN0OiBSZTogW21h
bmV0XSBNZXNzYWdlIGludGVncml0eSBhbmQgbWVzc2FnZSBtdXRhYmlsaXR5ICh3YXMgUkU6IGRy
YWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEgY291cGxlIG9mIGJpZyB0aWNrZXQg
SXRlbXMpDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9t
IG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5l
ciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxk
IGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3Ig
aW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9y
IGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJh
ZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQl
MjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFz
ZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20v
aG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIw
U3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KQSB0aG91Z2h0IHJlZ2FyZGluZyBpbnRlZ3JpdHkg
Y2hlY2tpbmcuICBBIHBvc3NpYmxlIGZ1dHVyZSAiZml4IiBmb3IgaW50ZWdyaXR5IGNvdWxkIGJl
IGRvbmUgb24gYSAidmlydHVhbCIgcGFja2V0IGluIHdoaWNoIGtub3duIFRMVnMvdmFsdWVzIGFs
b25nIHdpdGggb3JkZXJlZCBhZGRyZXNzZXMgYXJlIHVuY29tcHJlc3NlZCBhbmQgdGhlbiB2ZXJp
ZmllZC4gIEl0IGNvdWxkIGFsbG93IGV4dHJhIFRMViB0YWdnaW5nIHdpdGhvdXQgbW9kaWZ5aW5n
IHRoZSB2YWxpZGl0eSBvZiB0aGF0IGRhdGEuICBUaGUgdmVyeSBiaWcgZHJhd2JhY2sgd291bGQg
YmUgdGhlIG92ZXJoZWFkIG9mIGhhdmluZyB0byB1bmNvbXByZXNzZWQgZXZlcnl0aGluZyB0byBj
aGVjayB0aGUgdmFsaWRpdHkuICBJdCdzIGZ1bmN0aW9uYWxseSB0aGUgc2FtZSBhcyB6ZXJvaW5n
IG91dCBsb2NhbCAodGhpcyBpcyBteSBzdHVmZikgVExWIGRhdGEgdnMgcmVtb3RlICh0aGlzIGlz
IG5vdCBteSBzdHVmZikgVExWIGRhdGEuDQoNCkFzIGZvciB0aGUgUlJFUC1BY2sgaGF2aW5nIGEg
ZmxhZyB2cyBhbiBhZGRyZXNzIGRvZXNuJ3QgbXVjaCBib3RoZXIgbWUgYXMgZWl0aGVyIHdvdWxk
IGhhdmUgdG8gYmUgemVyb2VkIG91dCBmb3IgdGhpcyB0eXBlIG9mIGZ1dHVyZSBpbnRlZ3JpdHkg
Y2hlY2tpbmcuDQoNCkp1c3Rpbg0KDQpPbiBNb24sIEFwciAyNSwgMjAxNiBhdCA5OjI3IEFNLCBE
ZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208
bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQpBc3N1bWluZyBm
b3IgdGhlIG1vbWVudCB0aGF0IGV2ZXJ5b25lIHdpbGwgbmVlZCBhbiBSUkVQLUFjayBvciB3b27i
gJl0IChsZXTigJlzIGNvbWUgYmFjayB0byB0aGF0KSB3aHkgZG8gQyBhbmQgQiBuZWVkIHRvIHB1
dCBhbiBhZGRyZXNzIGluIGFzIGFuIFJSRVEtQWNrIHJlcXVlc3Q/IFdoeSBub3QgYSBmbGFnLCBi
ZWNhdXNlIHRoZSBhZGRyZXNzIHdpbGwgYmUgaW5jbHVkZWQgYXMgdGhlIElQIHNlbmRpbmcgYWRk
cmVzcyAtIGFuZCB3ZSBrbm93IDU0NDQgaXMgcmVxdWlyZWQgdG8gcGFzcyB0aGF0IG9uLiAoSXTi
gJlzIHVzZWQgYnkgTkhEUCBhcyB3ZWxsLikgVGhlbiB3ZSBkb27igJl0IG5lZWQgdG8gY2hhbmdl
IHRoZSBSUkVQLCBpdCB3aWxsIGhhdmUgYSBmbGFnIHNldCBvciBub3QsIGFuZCB3b27igJl0IGNo
YW5nZSAoaW4gdGhpcyByZWdhcmQpLg0KDQpOb3cgbGV04oCZcyBjb25zaWRlciBkbyB3ZSBrbm93
IHdoZXRoZXIgd2UgY2FuIHNldCBhIGZpeGVkIGZsYWcuIEZpcnN0IEnigJlkIHNheSB0aGVyZSBh
cmUgdHdvIGNhc2VzIC0geW914oCZdmUgZ290IGEgZmlybSBjb250cm9sIG9uIHdoYXTigJlzIGdv
aW5nIG9uIGluIHlvdXIgbmV0d29yaywgb3IgaXTigJlzIG9uZSBvZiB1bmtub3duIHBhcnRpZXMg
YW5kIGJlaGF2aW91ciAoY29uc2lzdGVudCB3aXRoIHNwZWNpZmljYXRpb24pLiBJbiB0aGUgZm9y
bWVyIGNhc2UgeW91IG9ubHkgd2FudCBvbmUgc2V0dGluZywgZm9yIGV4YW1wbGUgbm8tQWNrIGlm
IHJ1bm5pbmcgTkhEUCBvciB5b3VyIE1BQyBsYXllciB0ZWxscyB5b3UgYWJvdXQgYmlkaXJlY3Rp
b25hbGl0eSwgQWNrIG90aGVyd2lzZS4gSW4gdGhlIGxhdHRlciBjYXNlLCBJIHRoaW5rIHlvdSBq
dXN0IGFsd2F5cyB3YW50IGFuIEFjay4gU28gYm90aCBjYXNlcyBnZXQgeW91IHRvIHRoZSBzYW1l
IHBsYWNlLg0KDQpTaG91bGQgdGhhdCBub3QgYmUgYW4gYWNjZXB0YWJsZSBhcmd1bWVudCAodGhv
dWdoIEkgdGhpbmsgaXTigJlzIGdvb2QgZm9yIHdoZXJlIHdlIGFyZSAtIGluIGZhY3QgYWx3YXlz
IEFjayBpcyBjbG9zZSkgdGhlbiBhdCBmbGFnIGlzIGEgc3RlcCBiZXR0ZXIsIGl04oCZcyBhIGZp
eGVkIGxvY2F0aW9uIHRvIGNoYW5nZS4gSG93ZXZlciBpdCB3b3VsZCBiZSBiZXR0ZXIgaW4gdGhh
dCBjYXNlIGlmIHRoZSB0d28gdGhpbmdzIHRvIGNoYW5nZSAobWV0cmljIGFuZCBhY2sgZmxhZykg
d2VyZSB0b2dldGhlci4gQnV0IHRoYXQgaGFzIGl0cyBvd24gaXNzdWVzLCBzbyBJIHdvbuKAmXQg
Z28gdGhlcmUuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBF
bmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUy
ODAlMjkxMjQ1JTIwMjQyMTk0PiAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208
bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBs
aWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRv
dywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRw
Oi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu
Y2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpS
ZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5
LCBHVTIgN1lQDQoNCkZyb206IFZpY3RvcmlhIE1lcmNpZWNhIFttYWlsdG86dm1lcmNpZWNhMEBn
bWFpbC5jb208bWFpbHRvOnZtZXJjaWVjYTBAZ21haWwuY29tPl0NClNlbnQ6IDI1IEFwcmlsIDIw
MTYgMTQ6MTUNClRvOiBKaWF6aSBZSQ0KQ2M6IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBD
aHJpc3RvcGhlciBEZWFybG92ZTsgTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3QN
ClN1YmplY3Q6IFJlOiBbbWFuZXRdIE1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBtZXNzYWdlIG11dGFi
aWxpdHkgKHdhcyBSRTogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3Vw
bGUgb2YgYmlnIHRpY2tldCBJdGVtcykNCg0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2Fn
ZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBh
biBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3
aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50
cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91
IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6
Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdo
dHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMg
c3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVu
dC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMv
RGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQpIaSBKaWF6aSwNCg0K
DQpPbiBNb24sIEFwciAyNSwgMjAxNiBhdCAxOjA0IFBNLCBKaWF6aSBZSSA8aWV0ZkBqaWF6aXlp
LmNvbTxtYWlsdG86aWV0ZkBqaWF6aXlpLmNvbT4+IHdyb3RlOg0KSGksDQoNCk9uIE1vbiwgQXBy
IDI1LCAyMDE2IGF0IDExOjIwIEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMu
ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu
Y29tPj4gd3JvdGU6DQpXaXRoIHJlZ2FyZCB0byB5b3VyIHZhbGlkaXR5IHRpbWUgcG9pbnQsIHdl
IGhlcmUgaGF2ZSBhIHRyYWRlb2ZmLiBJZiB5b3UgYWxsb3cgdGhhdCBmZWF0dXJlLCBpdCBzaWdu
aWZpY2FudGx5IGltcGFjdHMgb24gdGhlIGFwcHJvYWNoIHRoYXQgd2FzIGNvbWluZyB0b2dldGhl
ciBvbiBhcyBiZXN0IHlvdSBjYW4gZW5kIHRvIGVuZCBlbmNyeXB0aW9uLg0KDQpTbyB0aGUgcXVl
c3Rpb24gaXMsIGlzIHRoaXMgYSBmZWF0dXJlIHRoYXTigJlzIHJlYWxseSB3YW50ZWQ/IFVuZm9y
dHVuYXRlbHkgSSB0aGluayB3ZSBrbm93IHRoYXQgdGhlIGFuc3dlciB0byB0aGF0IGlzLCB3ZSBk
b27igJl0IGtub3cgYmVjYXVzZSB3ZSBkb27igJl0IGhhdmUgYW55IGV4cGVyaWVuY2UuIE15IHZp
ZXcgd291bGQgYmUgdGhhdCBpbiB0aGUgdHJhZGVvZmYgb2YgYW4gdW50ZXN0ZWQgZmVhdHVyZSAo
dW5sZXNzIEnigJltIHdyb25nIGFib3V0IHRoYXQpIGFuZCB0aGUgc2VjdXJpdHkgY29tcGxpY2F0
aW9uLCBzZWN1cml0eSB3aW5zIGFuZCBkcm9wIHRoZSBmZWF0dXJlLiBJZiB0aGVyZSBpcyBzb21l
IHJlYWwgcmVxdWlyZW1lbnQsIHRoZW4gdGhlcmXigJlzIGEgZGlzY3Vzc2lvbi4gKFF1ZXN0aW9u
cyBsaWtlIGhvdyBvZnRlbiB0aGUgaW50ZXJtZWRpYXRlIHJvdXRlcnMgYWN0dWFsbHkgaGF2ZSBh
bnkga25vd2xlZGdlIC0gdHlwaWNhbGx5IGxpbmtzIGJyZWFrIGZvciB1bmV4cGVjdGVkIHJhdGhl
ciB0aGFuIGV4cGVjdGVkIHJlYXNvbnMuIEFuZGFuIGludGVybWVkaWF0ZSByb3V0ZXIgY291bGQg
cG9zc2libHkgdXNlIGEgdmFsaWRpdHkgdGltZSB0byBpbmZsdWVuY2UgaXRzIGJlaGF2aW91ci4p
IE5vdGUgdGhhdCBkcm9wcGluZyB0aGUgYWJpbGl0eSBvZiBpbnRlcm1lZGlhdGUgcm91dGVycyB0
byBtb2RpZnkvc2V0IHN0aWxsIGFsbG93cyB2YWxpZGl0eSB0aW1lcyBwZXIgcm91dGUgdG8gYmUg
c2V0IGF0IGVuZHBvaW50cy4NCg0KSSBhZ3JlZSB3aXRoIENocmlzJyBjb25jZXJuLg0KVGhlIFZh
bGlkaXR5VGltZSBpcyBvcHRpb25hbCwgd2hpY2ggbWFrZXMgdGhlIGludGVncml0eSBwcm90ZWN0
aW9uIGhhcmQuIEZ1cnRoZXJtb3JlLCBpdCBnaXZlcyBhIHBvdGVudGlhbCBhdHRhY2sgdmVjdG9y
OiBhcyBhbGwgdGhlIHJvdXRlcnMgaW4gYSBwYXRoIHdpbGwgdGFrZSB0aGUgc2hvcnRlc3QgdmFs
aWRpdHlUaW1lLCBhIGNvbXByb21pc2VkIHJvdXRlciBjYW4gc2V0IHRoZSB0aGUgdmFsaWRpdHlU
aW1lIHRvIGEgdmVyeSBzaG9ydCB2YWx1ZSwgd2hpY2ggd2lsbCBtYWtlIHRoZSByb3V0ZSBpbnN0
YWxsZWQgYWxvbmcgdGhlIHBhdGggYmVjYW1lIGludmFsaWQgKHZlcnkgc29vbikuDQoNCk9uIHRo
ZSBvdGhlciBoYW5kLCBJJ20gbm90IHN1cmUgdGhpcyBvcHRpb24gd2lsbCBnaXZlIHVzIG11Y2gg
aGVscC4gQ2hyaXMgbWVudGlvbmVkIG11Y2gga25vd2xlZGdlIGludGVybWVkaWF0ZSByb3V0ZXIg
d291bGQgaGF2ZSB0byBkZWNpZGUgdGhpcyB2YWx1ZSAoYW5kIGhvdyBtdWNoIHNlbnNlIHRoZSB2
YWx1ZSB3b3VsZCBtYWtlKS4NCkFub3RoZXIgaXNzdWUgaXMsIGEgcm91dGUgdG8gYSBkZXN0aW5h
dGlvbiBtaWdodCBiZSB1cGRhdGVkIGJ5IGRpZmZlcmVudCBzb3VyY2VzLiBGb3IgZXhhbXBsZSwg
aW4gdGhlIG5ldHdvcmsgYmVsb3c6DQoNCkEtLS0tQi0tLS0tQw0KDQpBIGZpcnN0IGVzdGFibGlz
aCBhIHJvdXRlIHRvIEIgd2l0aCBsb25nIHZhbGlkaXR5IHRpbWUuIFRoZW4gQSBpbml0aWF0ZXMg
YSByb3V0ZSBkaXNjb3ZlcnkgdG8gQy4gQyB0ZW5kcyB0byBzZXQgYSBzaG9ydCB2YWxpZGl0eSB0
aW1lLCB3aGljaCB3aWxsIG1ha2UgdGhlIHJvdXRlIGJldHdlZW4gQiBhbmQgQSBleHBpcmUgZWFy
bGllciB0aGFuIGV4cGVjdGVkLg0KSXMgdGhpcyBhIHByb2JsZW0/IE1heWJlIHllcywgbWF5YmUg
bm8gLS0gSSdtIG5vdCBzdXJlIGl0J3MgY29uc2lkZXJlZCBvciBub3QuDQoNCg0KTm90IHN1cmUg
SSBmb2xsb3cgaGVyZS4NCkN1cnJlbnRseSwgdGhlIHZhbGlkaXR5IHRpbWUgb2YgdGhlIHJvdXRl
IGJldHdlZW4gQSBhbmQgQiB3b3VsZCBub3QgYWZmZWN0ZWQgYnkgYSBzaG9ydCB2YWxpZGl0eSB0
aW1lIG9mIGEgcm91dGUgYmV0d2VlbiBBIGFuZCBDLiBWYWxpZGl0eSB0aW1lcyBhcmUgcGVyLXJv
dXRlLCBhbmQgdGhlIHJvdXRlIEEtQiBhbmQgdGhlIHJvdXRlIEEtQyBhcmUgc2VwYXJhdGUuDQpJ
ZiB3ZSBzd2l0Y2hlZCB0byBhIHZhbGlkaXR5IHRpbWUgcGVyIG5laWdoYm9yIChzbyB0aGF0IHdl
IGNhbiBrZWVwIHZhbGlkaXR5IHRpbWUgc2VwYXJhdGUgZnJvbSByb3V0ZSBhZHZlcnRpc2VtZW50
cykgYXMgSSBtZW50aW9uZWQgaW4gdGhlIGVtYWlsIGJlbG93LCB0aGVuIHRoZSB2YWxpZGl0eSBv
ZiBhIHJvdXRlIGJldHdlZW4gQSBhbmQgQyB3b3VsZCBiZSBhZmZlY3RlZCBpZiB0aGVyZSB3YXMg
YSBzaG9ydCB2YWxpZGl0eSB0aW1lIGJldHdlZW4gQSBhbmQgQi4gQnV0LCBpZiBCIHdpbGwgb25s
eSByb3V0ZSBmb3IgYSBjZXJ0YWluIGFtb3VudCBvZiB0aW1lLCB0aGVuIHRoZSByb3V0ZSBiZXR3
ZWVuIEEgYW5kIEMgd2lsbCBvZiBjb3Vyc2UgYmUgYWZmZWN0ZWQuIElzIGl0IGJlc3QgdG8ga25v
dyBpbiBhZHZhbmNlIHRoYXQgdGhlcmUncyBhIHRpbWUgbGltaXQsIG9yIGp1c3QgZGVhbCB3aXRo
IFJFUlJzIHdoZW4gdGhleSBoYXBwZW4/DQoNCg0KDQpXaXRoIHJlZ2FyZCB0byB0aGUgYWNrbm93
bGVkZ2VtZW50cywgdGhlIHByb2JsZW0gKHdpdGggcmVnYXJkIHRvIHNlY3VyaXR5KSBjb21lcyBm
cm9tIHRyeWluZyB0byBkbyB0d28gam9icyB3aXRoIHRoZSBzYW1lIG1lc3NhZ2UgLSBlbmQgdG8g
ZW5kIHJvdXRlIGFkdmVydGlzZW1lbnQgYW5kIGhvcCBieSBob3AgYWNrbm93bGVkZ2VtZW50LiBJ
IHVuZGVyc3RhbmQgdGhlIHJlYXNvbnMgLSBzYXZpbmcgYnl0ZXMgYW5kIG1lc3NhZ2UgdHlwZXMu
IChJIHdvdWxkIGhhdmUgdG8gc3R1ZHkgdGhlIHByb3RvY29sIHJlYWxseSBoYXJkIHRvIGlkZW50
aWZ5IGlmIGFueSBtZXNzYWdlIHR5cGVzIGNhbiBiZSBmb2xkZWQgdG9nZXRoZXIgYW5kIHJlY29n
bmlzZWQgYnkgY29udGVudCByYXRoZXIgdGhhbiB0eXBlIGVmZmljaWVudGx5LiBUaGlzIEkgZG8g
bm90IGV4cGVjdCB0byBkby4pIEFnYWluIGEgdHJhZGVvZmYuIFRoaXMgb25lIGlzIGluIGRpc2N1
c3Npb24gc3BhY2UsIHRob3VnaCB0aGF0IG5lZWRzIHBlb3BsZSB3aG8gdW5kZXJzdGFuZCBib3Ro
IHNpZGVzIG9mIHRoZSBpc3N1ZSwgaW5jbHVkaW5nIHRoZSBkZXRhaWxzIG9mIHRoZSBiaWRpcmVj
dGlvbmFsaXR5IG1lY2hhbmlzbS4gT2YgY291cnNlLCBhcyBoYXMgYmVlbiBzYWlkLCB3ZSBuZWVk
IG9uZSBvZiB0aG9zZS4NCg0KSSBoYXZlbid0IGZpbmlzaGVkIG15IHJldmlldyBvZiB0aGUgbGF0
ZXN0IGRyYWZ0LCBhbmQgSSBkb24ndCBnZXQgdGhlIG5lY2Vzc2l0eSBvZiBBY2tSZXEgYW5kIHRo
ZSBjb3JyZXNwb25kaW5nIG11bHRpY2FzdCBSUkVQIHlldC4NCklmIHBvc3NpYmxlLCB0aGlzICJv
cHRpb25hbCIgZmllbGQgc2hvdWxkIGJlIGF2b2lkZWQuDQoNCg0KVG8gZ2l2ZSBhbiBvdmVydmll
dyBvZiBBY2tSZXEgYW5kIFJSRVA6DQpTaW5jZSBBT0RWdjIgcmVxdWlyZXMgYmlkaXJlY3Rpb25h
bCBsaW5rcywgdGhpcyBpcyB0aGUgd2F5IHRvIGRldGVybWluZSBpZiBhIGxpbmsgaXMgYmlkaXJl
Y3Rpb25hbC4NCkEtLS0tQi0tLS1DDQoNCjEpIEEgc2VuZHMgUlJFUSwgQiBmb3J3YXJkcyBpdCwg
QyByZWNlaXZlcyB0aGUgUlJFUS4gQiBhbmQgQyBib3RoIGluc3RhbGwgYSByb3V0ZSB0byBPcmln
QWRkciBidXQgdGhleSBkb250IHlldCBrbm93IGlmIGl0J3MgdmFsaWQgYmVjYXVzZSB0aGV5IGRv
bnQga25vdyBpZiB0aGUgbGluayB0byB0aGVpciBuZXh0IGhvcCBpcyBhdmFpbGFibGUgaW4gdGhl
IHJldmVyc2UgZGlyZWN0aW9uLg0KMikgQyBjcmVhdGVzIHRoZSBSUkVQLiBTaW5jZSBpdCBkb2Vz
bnQga25vdyBpZiB0aGUgbGluayB0byBCIGlzIGJpZGlyZWN0aW9uYWwsIGl0IGluY2x1ZGVzIHRo
ZSBBY2tSZXEgKGFuIGFkZHJlc3MgdG8gaW5kaWNhdGUgdGhhdCBpdCBleHBlY3RzIHRvIHJlY2Vp
dmUgYSBSUkVQX0FjayBmcm9tIEIpLg0KMykgQiByZWNlaXZlcyB0aGUgUlJFUCwgaW5zdGFsbHMg
YSByb3V0ZSB0byBUYXJnQWRkciBhbmQgbWFya3MgaXQgYXMgdmFsaWQsIHNpbmNlIGl0IGtub3dz
IHRoZSBsaW5rIHRvIEMgaXMgYmlkaXJlY3Rpb25hbCwgYmVjYXVzZSB0aGUgUlJFUSB3ZW50IGlu
IG9uZSBkaXJlY3Rpb24gYW5kIHRoZSBSUkVQIGNhbWUgaW4gdGhlIG90aGVyLiBCIGFsc28gc2Vu
ZHMgdGhlIFJSRVBfQWNrIHRvIEMgYW5kIGZvcndhcmRzIHRoZSBSUkVQIHRvIEEgKGFuZCBtaWdo
dCBjaGFuZ2UgdGhlIG1lc3NhZ2UgdG8gaW5kaWNhdGUgaXRzIG93biBBY2tSZXEgLSBpZSB0aGF0
IGl0IHJlcXVpcmVzIGFuIGFjayBmcm9tIEEpLg0KNCkgQyByZWNlaXZlcyB0aGUgUlJFUF9BY2sg
ZnJvbSBCLCBhbmQgdGhlcmVmb3JlIGtub3dzIHRoYXQgQiByZWNlaXZlZCB0aGUgUlJFUCwgdGhl
cmVmb3JlIHRoZSBsaW5rIGlzIGJpZGlyZWN0aW9uYWwuIEMgY2FuIHRoZW4gbWFyayBpdHMgcm91
dGUgdG8gT3JpZ0FkZHIgYXMgdmFsaWQuDQo1KSBTaW1pbGFybHksIEEgcmVjZWl2ZXMgdGhlIFJS
RVAsIGluc3RhbGxzIHRoZSByb3V0ZSB0byBUYXJnQWRkciBhbmQgc2VuZHMgYW4gUlJFUF9BY2sg
dG8gQi4NCjYpIEIgcmVjZWl2ZXMgdGhlIFJSRVBfQWNrIGFuZCBtYXJrcyBpdHMgcm91dGUgdG8g
T3JpZ0FkZHIgYXMgdmFsaWQuDQoNCkFsdGVybmF0aXZlbHksIGluIHN0ZXAgMiwgaWYgQyBrbm93
cyB0aGUgbGluayB0byBCIGlzIGJpZGlyZWN0aW9uYWwgKHBlcmhhcHMgZnJvbSBzb21lIGVhcmxp
ZXIgcm91dGUgZGlzY292ZXJ5KSwgaXQgZG9lc250IG5lZWQgdG8gcHV0IHRoZSBBY2tSZXEgaW4g
dGhlIFJSRVAuIFRoZW4gaW4gc3RlcCAzLCBzaW5jZSBCIGRvZXNudCBrbm93IGlmIHRoZSBsaW5r
IHRvIEEgaXMgYmlkaXJlY3Rpb25hbCwgaXQgY2hhbmdlcyB0aGUgbWVzc2FnZSB0byBhZGQgdGhl
IEFja1JlcSBhZGRyZXNzLCBpbiBvcmRlciB0byBnZXQgYW4gUlJFUF9BY2sgZnJvbSBBLg0KSWYg
d2Ugd2FudCB0byBhdm9pZCBjaGFuZ2luZyB0aGUgbWVzc2FnZSwgd2UnbGwgbmVlZCB0byBsb29r
IGF0IGZvcndhcmRpbmcgdGhlIFJSRVAgYXMtaXMsIGFuZCBjcmVhdGluZyBhIHNlY29uZCBtZXNz
YWdlIHRvIHNvbGljaXQgYW4gUlJFUF9BY2ssIGluIG9yZGVyIHRvIHZlcmlmeSB0aGF0IHRoZSBs
aW5rIGlzIGJpZGlyZWN0aW9uYWwgYmVmb3JlIG1hcmtpbmcgdGhlIHJvdXRlIHRvIE9yaWdBZGRy
IGFzIHZhbGlkLg0KS2luZCByZWdhcmRzLA0KVmljdG9yaWEuDQoNCg0KcmVnYXJkcw0KDQpKaWF6
aQ0KDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVl
cg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkx
MjQ1JTIwMjQyMTk0PiAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRv
OmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIElu
dGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hl
bG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3
LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGlt
aXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3Rl
cmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIg
N1lQDQoNCkZyb206IFZpY3RvcmlhIE1lcmNpZWNhIFttYWlsdG86dm1lcmNpZWNhMEBnbWFpbC5j
b208bWFpbHRvOnZtZXJjaWVjYTBAZ21haWwuY29tPl0NClNlbnQ6IDIzIEFwcmlsIDIwMTYgMTA6
NTUNClRvOiBDaHJpc3RvcGhlciBEZWFybG92ZQ0KQ2M6IGlldGZAdGhvbWFzY2xhdXNlbi5vcmc8
bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmc+OyBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVL
KTsgTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3QNCg0KU3ViamVjdDogUmU6IFtt
YW5ldF0gTWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2UgbXV0YWJpbGl0eSAod2FzIFJFOiBk
cmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0
IEl0ZW1zKQ0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJv
bSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRu
ZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3Vs
ZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9y
IGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZv
ciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5i
YWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVk
JTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVh
c2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29t
L2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUy
MFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCkhpIENocmlzLA0KDQpUaGVzZSBoYXZlIGJvdGgg
YmVlbiBpbiB0aGUgZHJhZnQgaW4gc29tZSBmb3JtIHNpbmNlIGJlZm9yZSBJIGdvdCBpbnZvbHZl
ZC4uLiBidXQgSSdsbCBkbyBteSBiZXN0IHRvIGV4cGxhaW4uDQoNCi0gRm9yIFZhbGlkaXR5IFRp
bWUsIGl0cyBhIHdheSB0byBhZHZlcnRpc2UgdGhhdCB5b3Ugd291bGQgb25seSBzdXBwb3J0IHRo
ZSByb3V0ZSBjb250YWluZWQgaW4gdGhlIG1lc3NhZ2UgZm9yIGEgY2VydGFpbiBwZXJpb2Qgb2Yg
dGltZS4gVGhlIG9yaWdpbmF0b3IgbWlnaHQgdXNlIHRoaXMsIGJ1dCB0aGUgZHJhZnQgd2FzIHdy
aXR0ZW4gdG8gYWxsb3cgYW55IGludGVybWVkaWF0ZSBub2RlIHRvIGJlIGFibGUgdG8gYWRkIGl0
IG9yIHVwZGF0ZSBpdCB0b28uIFRoZSByb3V0ZSBjcmVhdGVkIGluIHRoZSBMb2NhbCBSb3V0ZSBT
ZXQgaGFzIGFuIGV4cGlyYXRpb24gdGltZSBhc3NvY2lhdGVkIHdpdGggaXQsIGJhc2VkIG9uIHRo
ZSByZWNlaXZlZCB2YWxpZGl0eSB0aW1lLg0KLSBGb3IgdGhlIEFja1JlcSBhZGRyZXNzLCBpdHMg
c28gdGhhdCB5b3UgY2FuIGFkZCBpbnRvIGEgUlJFUCBhIHJlcXVlc3QgZm9yIGFuIGFja25vd2xl
ZGdlbWVudCwgc28gdGhhdCB5b3UgZG9uJ3QgaGF2ZSB0byBoYXZlIGEgZGlmZmVyZW50IG1lc3Nh
Z2UgdHlwZSBhbHRvZ2V0aGVyIGZvciB3b3JraW5nIG91dCB3aGV0aGVyIGxpbmtzIHRvIG5laWdo
Ym9ycyBhcmUgYmlkaXJlY3Rpb25hbCwgYW5kIGFsc28sIHNpbmNlIHlvdSBvbmx5IGNhcmUgYWJv
dXQgYmlkaXJlY3Rpb25hbGl0eSBvbiByb3V0ZXMgdGhhdCBhcmUgYmVpbmcgc2V0IHVwLCB5b3Ug
ZG9udCBuZWVkIHRvIGNvbnN0YW50bHkgbW9uaXRvciBhbGwgbmVpZ2hib3JzLg0KDQoNCkluIG9y
ZGVyIHRvIGF2b2lkIHRoZSBwb3RlbnRpYWwgQWNrUmVxLXJlbGF0ZWQgY2hhbmdlcyB0byBlYWNo
IG1lc3NhZ2UsIG1heWJlIHdlIGRvIG5lZWQgdG8gaW50cm9kdWNlIGEgZGlmZmVyZW50IG1lc3Nh
Z2Ugc3BlY2lmaWNhbGx5IGZvciB0aGlzLiBXZSBjb3VsZCBtYXliZSB1c2UgUlJFUF9BY2sgdG8g
Ym90aCByZXF1ZXN0IGFuZCBhY2tub3dsZWRnZT8gSXQgbWVhbnMgYW4gZXh0cmEgbWVzc2FnZSBv
ZiBjb250cm9sIHRyYWZmaWMgdGhhdCBuZWVkcyB0byBiZSBzZW50LCBtYXliZSBvbmUgZXh0cmEg
bWVzc2FnZSBwZXIgaG9wIG9uIHRoZSBwYXRoIG9mIGEgUlJFUCwgYnV0IGl0IGNvdWxkIHN0aWxs
IGJlIGxpbWl0ZWQgdG8gbmVpZ2hib3JzIHdoaWNoIGhhdmUgcGFydGljaXBhdGVkIGluIHRoZSBy
b3V0ZSBkaXNjb3ZlcnkgcmF0aGVyIHRoYW4gbW9uaXRvcmluZyBhbGwgbmVpZ2hib3JzIGF0IGFs
bCB0aW1lcy4NCg0KVGhpcyBtZXNzYWdlIGNvdWxkIG1heWJlIGFsc28gaW5jbHVkZSAiSSdtIGhh
cHB5IHRvIHJvdXRlIGFueXdoZXJlIGZvciBhIGNlcnRhaW4gYW1vdW50IG9mIHRpbWUiLCBzb3J0
IG9mIGxpa2Ugd2lsbGluZ25lc3MgaW4gT0xTUi9PTFNSdjIuIFNvIGluc3RlYWQgb2YgaGF2aW5n
IGEgdmFsaWRpdHkgdGltZSBwZXIgcm91dGUsIGl0cyBhIHZhbGlkaXR5IHRpbWUgcGVyIG5laWdo
Ym9yLiBUaGVuLCBmb3IgUlJFUSBhbmQgUlJFUCwgb25seSB0aGUgbWV0cmljIHZhbHVlIHdvdWxk
IGNoYW5nZSBpbiB0cmFuc2l0LCBhcyBkaXNjdXNzZWQuIEhvd2V2ZXIsIHRoYXQgbGVhZHMgdG8g
c29tZSBpc3N1ZXMgd2l0aCBkZWNpZGluZyB3aGF0IGEgcm91dGUncyBleHBpcmF0aW9uIHRpbWUg
aXMuIFlvdSBtaWdodCBrbm93IGhvdyBsb25nIHRoZSBuZXh0IGhvcCByb3V0ZXIgaXMgdmFsaWQg
Zm9yLCBidXQgd2hhdCBpZiBhIHJvdXRlciBiZXlvbmQgdGhhdCwgd2hpY2ggd2FzIGFsc28gcGFy
dCBvZiB0aGUgcm91dGUsIGhhZCBhIGxvd2VyIHZhbGlkaXR5IHRpbWU/IFlvdSBjb3VsZG4ndCBk
ZXRlcm1pbmUgdGhlIHJlYWwgdmFsaWRpdHkgdGltZS4gRG8gd2UgcmVtb3ZlIHRoZSByb3V0ZSBl
eHBpcmF0aW9uIHRpbWUgYWx0b2dldGhlciB0byBhdm9pZCB0aGlzIGlzc3VlPyBJbiB3aGljaCBj
YXNlLCB3ZSB3b3VsZCBoYXZlIHRvIHJlbHkgb24gUkVSUiBtZXNzYWdlcyBiZWluZyBzZW50IGZv
ciByb3V0ZXMgd2hpY2ggYmVjb21lIGludmFsaWQgd2hlbiB0aGUgbmVpZ2hib3IncyB2YWxpZGl0
eSB0aW1lIGhhcyBleHBpcmVkPyBTbyBuZWlnaGJvciB2YWxpZGl0eSB0aW1lIGV4cGlyYXRpb24g
aXMgdHJlYXRlZCB0aGUgc2FtZSBhcyBhIGxpbmsgYnJlYWsuDQoNCldoYXQgZG8geW91IHRoaW5r
Pw0KDQpLaW5kIHJlZ2FyZHMsDQpWaWN0b3JpYS4NCg0KDQoNCg0KDQoNCk9uIFNhdCwgQXByIDIz
LCAyMDE2IGF0IDE6MDkgQU0sIENocmlzdG9waGVyIERlYXJsb3ZlIDxjaHJpc0BtbmVtb3N5bmUu
ZGVtb24uY28udWs8bWFpbHRvOmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51az4+IHdyb3RlOg0K
UHJldHR5IG11Y2ggYWxsIG9mIHRoZSBkaXNjdXNzaW9uIGhhcyBiZWVuIGFzc3VtaW5nIG9ubHkg
YSBtZXRyaWMgdmFsdWUgY2hhbmdlLiBXaXRoIG11bHRpcGxlIHRoaW5ncyBjaGFuZ2luZyBtYW55
IG9mIHRoZSBpZGVhcyBnbyBvdXQgb2YgdGhlIHdpbmRvdy4gVGhhdCByZWluZm9yY2VzIHRoZSBw
b2ludCBhYm91dCBub3QgbWFraW5nIHNwZWNpZmljYXRpb25zIG5vdyB0aGF0IG1pZ2h0IHR1cm4g
b3V0IHRvIGJlIHdyb25nIGZvciBJQ1ZzLg0KDQpJZ25vcmluZyBob3cgdGhpcyBtaXN1bmRlcnN0
YW5kaW5nIGhhcHBlbmVkLCBJJ2xsIHN0YXJ0IGJ5IGFza2luZyB3aHkuIE1ldHJpYyBjaGFuZ2lu
ZyBJIHVuZGVyc3RhbmQuIFdoeSB0aGUgb3RoZXIgdHdvPyAodGhlcmUncyBhIHBhcnRpYWwgZXhw
bGFuYXRpb24gb2Ygb25lKS4gV2hhdCBhbHRlcm5hdGl2ZXMgaGF2ZSBwZW9wbGUgaW1wbGVtZW50
ZWQgaW4gY29tcGFyYWJsZSBwcm90b2NvbHM/DQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0K
Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tPG1haWx0bzpjaHJpc3RvcGhlci5kZWFybG92
ZUBnbWFpbC5jb20+IChpUGhvbmUpDQpjaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWs8bWFpbHRv
OmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51az4gKGhvbWUpDQoNCk9uIDIzIEFwciAyMDE2LCBh
dCAwMDoyNiwgVmljdG9yaWEgTWVyY2llY2EgPHZtZXJjaWVjYTBAZ21haWwuY29tPG1haWx0bzp2
bWVyY2llY2EwQGdtYWlsLmNvbT4+IHdyb3RlOg0KSGkgYWxsLA0KDQpDb250aW51ZWQgaW4gdGhp
cyB0aHJlYWQgYmVjYXVzZSB0aGUgb3RoZXIgb25lIHNlZW1zIHRvIGJlIG1vcmUgYWJvdXQgVExW
IHR5cGVzIGFuZCBtZXRyaWMgdHlwZSBudW1iZXJzLCB3aGVyZWFzIHRoaXMgaXMgYWJvdXQgcmVn
ZW5lcmF0aW9uL2ZvcndhcmRpbmcuDQoNClRvIHJlY2FwLCBpbiB0aGUgY3VycmVudCBkcmFmdCwg
dGhlcmUgYXJlIDMgdGhpbmdzIHRoYXQgbWlnaHQgY2hhbmdlIGF0IGVhY2ggaG9wOg0KLSB0aGUg
bWV0cmljIHZhbHVlIChoYXBwZW5zIGluIFJSRVEgYW5kIFJSRVApLA0KLSBhZGRpbmcvY2hhbmdp
bmcgVmFsaWRpdHkgVGltZSB1c2luZyB0aGUgVmFsaWRpdHkgVGltZSBUTFYgKGNhbiBoYXBwZW4g
aW4gUlJFUSBhbmQgUlJFUCksDQotIGFkZGluZyBhbiBhZGRyZXNzIChhbmQgY29ycmVzcG9uZGlu
ZyB2YWx1ZSBpbiB0aGUgQWRkcmVzc1R5cGUgVExWIHRvIGluZGljYXRlIGhvdyB0byBpbnRlcnBy
ZXQgdGhlIGFkZHJlc3MpIHRvIGluZGljYXRlIHRoZSBhZGRyZXNzIGZyb20gd2hpY2ggYW4gUlJF
UF9BY2sgaXMgZXhwZWN0ZWQsIHRvIGFjY29tcGxpc2ggdGhlIGJpZGlyZWN0aW9uYWxpdHkgY2hl
Y2sgKGNhbiBoYXBwZW4gaW4gUlJFUCkuDQoNCklmIHdlIGRlZmluZSBhIGNlcnRhaW4gcG9ydGlv
biBvZiB0aGUgbWVzc2FnZSBhcyBpbW11dGFibGUgYW5kIGluY2x1ZGUgdGhlIElDViB0byB2ZXJp
ZnkgdGhhdCBwYXJ0LCBlbmQgdG8gZW5kOg0KLSBUaGUgbWV0cmljIHZhbHVlIHdvdWxkIGJlIGV4
Y2x1ZGVkIGZyb20gdGhlIElDViBzaW5jZSBpdCBuZWVkcyBjaGFuZ2luZyBhdCBlYWNoIGhvcC4N
Ci0gV291bGQgYWRkaW5nIGEgVmFsaWRpdHkgVGltZSBUTFYgYXQgYW4gaW50ZXJtZWRpYXRlIGhv
cCBiZSBhY2NlcHRhYmxlPyBUaGUgd2hvbGUgVExWIGNvdWxkIGJlIHJlbW92ZWQgaW4gb3JkZXIg
dG8gY2FsY3VsYXRlIHRoZSBJQ1Y/DQotIFdvdWxkIGFkZGluZyBhbiBhZGRyZXNzIGNhdXNlIGlz
c3VlcyBmb3IgdGhlIElDViwgYmVjYXVzZSBpdCdzIGluIHRoZSBhZGRyZXNzIGJsb2NrPyBDb3Vs
ZCB0aGUgcnVsZSBiZSAiaWYgaXQgY29udGFpbnMgYW4gQWNrUmVxIGFkZHJlc3MsIHJlbW92ZSBp
dCAoYW5kIHRoZSBjb3JyZXNwb25kaW5nIHZhbHVlIGluIHRoZSBBZGRyZXNzVHlwZSBUTFYpLCBi
ZWZvcmUgY2hlY2tpbmcgdGhlIElDViIsIGlzIHRoYXQgT0s/IE9yIHdvdWxkIHdlIG5lZWQgdG8g
YXZvaWQgdG91Y2hpbmcgdGhlIElDVidlZCBwYXJ0IG9mIHRoZSBtZXNzYWdlIGFsdG9nZXRoZXIs
IG1heWJlIHB1dCB0aGUgQWNrUmVxIGFkZHJlc3MgaW4gYSBzZXBhcmF0ZSBBZGRyZXNzIEJsb2Nr
LCB3aXRoIGFuIGV4dHJhIEFkZHJlc3NUeXBlIFRMViBmb2xsb3dpbmcgdGhhdCBhZGRyZXNzIGJs
b2NrPyBJcyB0aGVyZSBhIHdheSB0byBhY2NvbXBsaXNoIHRoaXM/DQoNCkFsc28sIHRvIGJlIHRo
b3JvdWdoLCBkbyB3ZSBuZWVkIHRvIGNvbnNpZGVyIFJFUlIgbWVzc2FnZXMgd2hpbGUgd2UgZGlz
Y3VzcyByZWdlbmVyYXRpb24gdnMgZm9yd2FyZGluZz8NCi0gUkVSUiAoc2VudCB3aGVuIGEgbGlu
ayBicmVha3MpIGlzIGEgd2F5IG9mIHNheWluZyAiSSd2ZSBsb3N0IG15IHJvdXRlIHNvIEknbSB0
ZWxsaW5nIG90aGVycyIgYW5kICJ5b3Ugd2VyZSBteSBuZXh0IGhvcCwgc28gbm93IEkndmUgYWxz
byBsb3N0IG15IHJvdXRlLCBJJ2xsIHRlbGwgb3RoZXJzIiwgZXRjLiBJdCdzIGdvaW5nIHRvIGJl
IHRhaWxvcmVkIGF0IGVhY2ggc3RlcCB0byBpbmNsdWRlIHRoZSByZWxldmFudCByb3V0ZXMgdGhh
dCBnb3QgZGVsZXRlZCwgaXQncyBub3Qgb25lIG1lc3NhZ2UgYmVpbmcgc2VudCBlbmQtdG8tZW5k
IGxpa2UgUlJFUSBhbmQgUlJFUCBhcmUuDQotIEhvd2V2ZXIsIFJFUlIgKHNlbnQgd2hlbiBhIHNv
dXJjZSBvZiB0cmFmZmljIGlzIHNlbmRpbmcgZGF0YSBvbiBhIHJvdXRlIHdoaWNoIGNvbWVzIHRo
cm91Z2ggeW91LCBhbmQgeW91IHdhbnQgdG8gdGVsbCB0aGUgUGFja2V0IFNvdXJjZSdzIHJvdXRl
ciB0byBkZWxldGUgdGhlIHJvdXRlKSBjb3VsZCBiZSBzZWVuIGFzIGFuIGVuZC10by1lbmQgbWVz
c2FnZSB3aGljaCBhbGwgaW50ZXJtZWRpYXRlIHJvdXRlcnMgbGVhcm4gZnJvbSwgc2ltaWxhciB0
byBSUkVRIGFuZCBSUkVQLiBJdCByZXBvcnRzIG9uZSByb3V0ZSwgYW5kIGRvZXNuJ3QgbmVlZCBj
aGFuZ2luZyBhdCBpbnRlcm1lZGlhdGUgaG9wcywgc28gY291bGQgYmUgcHJvdGVjdGVkIHdpdGgg
SUNWLg0KLSBXb3VsZCBpdCBiZSBPSyB0byBvbmx5IHJlcXVpcmUgYSBtZXNzYWdlIElDViBpZiBh
IFBrdFNvdXJjZSBhZGRyZXNzIHdhcyBpbmNsdWRlZCwgaS5lLiB3aGVuIHRoZSBtZXNzYWdlIG5l
ZWRzIHRvIGdvIHZpYSBhIG51bWJlciBvZiBpbnRlcm1lZGlhdGUgaG9wcyB0byBQa3RTb3VyY2Un
cyByb3V0ZXI/IEFsbCBvdGhlciBSRVJScyBhcmUgaW50ZW5kZWQgdG8gYmUgb25lLWhvcCBtZXNz
YWdlcywgd2hpY2ggbWF5IGluIHR1cm4gcHJvbXB0IG90aGVyIG9uZS1ob3AgbWVzc2FnZXMsIGV0
Yy4uLiwgYW5kIGEgcGFja2V0IElDViBtaWdodCBiZSBtb3JlIGFwcHJvcHJpYXRlPw0KDQpLaW5k
IHJlZ2FyZHMsDQpWaWN0b3JpYS4NCg0KT24gVGh1LCBNYXIgMTcsIDIwMTYgYXQgNToyNiBQTSwg
PGlldGZAdGhvbWFzY2xhdXNlbi5vcmc8bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmc+PiB3
cm90ZToNCg0KT24gMTcgTWFyIDIwMTYsIGF0IDE4OjE3LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIg
KFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3Zl
QGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQoNClllcywgSSBtZWFudCBBT0RWdjIsIHRoYW5rcyBm
b3IgdGhlIGNhdGNoLg0KDQpTbyBpcyB5b3VyIChUaG9tYXMpIHByb3Bvc2VkIGJhc2Ugc3BlY2lm
aWNhdGlvbiBhIGhvcCBjb3VudCBvbmx5IG1ldHJpYz8NCg0KTm8sIHRoZSB3b3VsZCBiZSBzaWxs
eSBhcyBiYXNlIHNwZWNpZmljYXRpb24sIGdpdmVuIHRoYXQgaG9wIGNvdW50IG1vc3RseSBpcyB1
c2VsZXNzLg0KDQpBcyBiYXNlIHNwZWNpZmljYXRpb24gSSB3b3VsZCBzaW1wbHkgc2F5IOKAnElu
Y2x1ZGUgYSBNZXRyaWMgVHlwZSBNZXNzYWdlIFRMViB3aXRoIGEgdmFsdWUgZmllbGQsIGFuZCBh
IDcxODIgTWVzc2FnZSBUTFYgJiBUaW1lc3RhbXDigJ0gYXMgd2UgZG8gaW4gT0xTUnYyICh3aXRo
IHRoZSBhcHByb3ByaWF0ZSB2ZXJiaWFnZSBhcyB0byBnZW5lcmF0aW9uIGFuZCBwcm9jZXNzaW5n
KS4NCg0KV2l0aCB0aGUgbWVzc2FnZSBnZW5lcmF0ZWQgYnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhl
IFJSRVEvUlJFUCBhbmQgKm5vdCogZGVjb25zdHJ1Y3RlZC9yZWNvbnN0cnVjdGVkL3Jlb3JkZXJl
ZCAoYXMgaXMgdGhlIHJpc2sgd2l0aCDigJxyZWdlbmVyYXRpb24pIGFsbG93cyBrbm93aW5nIHRo
YXQgaXQgd291bGQgYmUgKm9ubHkqIHRoYXQgbWV0cmljIGZpZWxkIGJlaW5nIG1vZGlmaWVkIChv
dGhlciB0aGFuIGhvcCBjb3VudC9saW1pdCkgZm9yIHdoZW4gZXZlbnR1YWxseSB3cml0aW5nIHVw
IHRoZSBleHRlbnNpb24uDQoNCihBY3R1YWxseSBkb2VzbuKAmXQgdGhlIGN1cnJlbnQgc3BlY2lm
aWNhdGlvbiBvbmx5IGRlZmluZSBob3AgY291bnQsIG9yIGhhcyB0aGF0IGNoYW5nZWQgaW4gbGF0
ZXN0IGRyYWZ0PykNCg0KTm8uIFRoYXQgaXMgb25lIG9mIHRoZSBpc3N1ZXMgSSByYWlzZSBpbiBt
eSBvcmlnaW5hbC4gRm9yIHNvbWUgcmVhc29uLCBpdCBjaXRlcyBSRkM2NTUxLCB3aGljaCBpcyBh
IFJPTEwgZG9jdW1lbnQgYW5kIHdoaWNoIGhhcyBpbiBpdHMgYWJzdHJhY3QgdGhhdDoNCg0KDQog
ICBMb3ctUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzIChMTE5zKSBoYXZlIHVuaXF1ZSBjaGFyYWN0
ZXJpc3RpY3MNCg0KICAgY29tcGFyZWQgd2l0aCB0cmFkaXRpb25hbCB3aXJlZCBhbmQgYWQgaG9j
IG5ldHdvcmtzIHRoYXQgcmVxdWlyZSB0aGUNCg0KICAgc3BlY2lmaWNhdGlvbiBvZiBuZXcgcm91
dGluZyBtZXRyaWNzIGFuZCBjb25zdHJhaW50cy4NCg0KSS5lLiB0aGlzIGRvY3VtZW50IGNpdGVz
IGEgbWV0cmljIGRvY3VtZW50IHdoaWNoIGNsZWFybHkgY2xhaW1zIHRvIGJlIGluYXBwbGljYWJs
ZSBpbiBhZCBob2MgbmV0d29ya3MuIEkgbm90ZSB0aGF0IHRoaXMgaXMgYW5vdGhlciB0aGluZyBJ
4oCZdmUgcmFpc2VkIGZvciB5ZWFycyB3aXRob3V0IHNlZWluZyBpdCBhdHRlbXB0ZWQgcmVzb2x2
ZWQuDQoNCkJlc3QsDQoNClRob21hcw0KDQoNCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpT
ZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j
ZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIx
OTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92
ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoN
CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kg
UGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5
c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBB
cHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxl
cyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywg
R3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTogaWV0ZkB0aG9tYXNjbGF1c2VuLm9y
ZzxtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZz4gW21haWx0bzppZXRmQHRob21hc2NsYXVz
ZW4ub3JnXQ0KU2VudDogMTcgTWFyY2ggMjAxNiAxNzoxMA0KVG86IERlYXJsb3ZlLCBDaHJpc3Rv
cGhlciAoVUspDQpDYzogTG90dGUgU3RlZW5icmluazsgTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBt
YWlsaW5nIGxpc3QNClN1YmplY3Q6IFJlOiBbbWFuZXRdIE1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBt
ZXNzYWdlIG11dGFiaWxpdHkgKHdhcyBSRTogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2
aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcykNCg0KDQoqKiogV0FSTklORyAqKioN
ClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBl
aXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVy
IGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFu
eSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZs
YWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGlj
ayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3Vy
aXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0
aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDov
L2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0
cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQoN
Ck9uIDE3IE1hciAyMDE2LCBhdCAxODowNCwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgPGNo
cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0
ZW1zLmNvbT4+IHdyb3RlOg0KDQpPSywgc28gd2UgaGF2ZSBhIG1lc3NhZ2UgdGhhdCBtdXRhdGVz
IGJ5Og0KLSBNb2RpZnlpbmcgaG9wIGNvdW50L2xpbWl0Lg0KLSBNb2RpZnlpbmcgYSBtZXRyaWMg
dmFsdWUuDQpBbnl0aGluZyBlbHNlPw0KDQpBcyBtdXRhdGluZyAob3RoZXIgdGhhbiBob3AgY291
bnQvbGltaXQpIG1lc3NhZ2VzIGFyZW7igJl0IGNvdmVyZWQgYnkgNTQ0NCBvciBhbnkgZGVyaXZh
dGl2ZSBkb2N1bWVudCAoYnV0IG9ubHkgcmVjb21tZW5kZWQgYWdhaW5zdCwgbm90IGJhbm5lZCkg
dGhhdCB5b3UgbWF5IG5lZWQgdG8gbWFrZSB0aGUgbWVzc2FnZSBvdGhlcndpc2UgaW1tdXRhYmxl
IChubyBkZWNvbnN0cnVjdGlvbiBhbmQgcmVidWlsZGluZywgb3RoZXIgdGhhbiBndWFyYW50ZWVk
IHVuY2hhbmdpbmcpIHRoYXQgd291bGQgaGF2ZSB0byBiZSBzcGVjaWZpZWQgYnkgQU9EVnYyLiAo
RWFzeSB0byBzYXksIGJ1dCBuZWVkcyBzYXlpbmcuKQ0KDQpXaXRoIHlvdSBzbyBmYXIuDQoNClRo
ZW4gdGhhdCBpbmZvcm1hdGlvbiBpcyBub3QgaW4gYSBndWFyYW50ZWVkIGZpeGVkIGxvY2F0aW9u
IGdpdmVuIGJ5IGEgc2ltcGxlIG9mZnNldC4gU28gYW55IHNpZ25hdHVyZSBhbGdvcml0aG0gdGhh
dCBmaW5kcyBpdCBhbmQgaWdub3JlcyBpdCBvciBhZ2dyZWdhdGVzIG9uIGl0IGlzIHNwZWNpZmlj
IHRvIE9MU1J2Mi4NCg0KU3VyZWx5IHlvdSBtZWFuIEFPRFZ2Mg0KDQpTbyBzdGFuZGFyZCA3MTgy
IElDVnMgZG9u4oCZdCBkbyB0aGUgam9iLCB5b3Ugd291bGQgbmVlZCBhbiBBT0RWdjIgc3BlY2lh
bGlzZWQgdmFyaWFudC4gV2hpY2ggaXMgdGhlIHNvcnQgb2YgdGhpbmcgdGhhdCB0aGUgbWVzc2Fn
ZSBzcGVjaWZpYyBUTFYgc3BhY2UgaXMgdGhlcmUgZm9yLCBJ4oCZZCBiZSBzdHJvbmdseSBhZ2Fp
bnN0IGEg4oCcYnV0IGlnbm9yZSB0aGUgdmFsdWUgb2YgdGhpcyBzcGVjaWZpYyBUTFYgc2hvdWxk
IGl0IG9jY3Vy4oCdIGJlaW5nIGluIHRoZSBnZW5lcmFsIHNwYWNlLiBIb3dldmVyIGl0IGNhbiBl
YXNpbHkgYmUgZGVmaW5lZCBieSByZWZlcmVuY2UgdG8gNzE4MiAo4oCcdGhpcyBUTFYgaXMgbGlr
ZSB0aGF0IFRMViwgZXhjZXB0IGlmIGFuIFggVExWIGlzIHByZXNlbnQsIHNldCBpdHMgdmFsdWUg
ZmllbGQgdG8gemVyb+KAnSkuDQoNCk1lc3N5LCBidXQgY291bGQgd29yay4NCg0KTm90IHRoYXQg
bWVzc3ksIGFjdHVhbGx5LCBhbHRob3VnaCBjbGVhcmx5IG5vdCBhcyBuaWNlIGFzIOKAnGZpeGVk
IG9mZnNldOKAnS4NCg0KVGhhdCBzYWlkLCBJIGFtIGFyZ3VpbmcgZm9yIHRoZSBiYXNlIHNwZWMg
YmVpbmc6DQoNCiAgICAgICAgICAgIOKAnG1ha2UgdGhlIG1lc3NhZ2Ugb3RoZXJ3aXNlIGltbXV0
YWJsZSAobm8gZGVjb25zdHJ1Y3Rpb24gYW5kIHJlYnVpbGRpbmcsIG90aGVyDQogICAgICAgICAg
ICAgdGhhbiBndWFyYW50ZWVkIHVuY2hhbmdpbmcp4oCdIHdoaWNoIGlzIGFmZm9yZGVkIGJ5IGZv
cndhcmRpbmcNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKw0KDQogICAg
ICAgICAgICBSRkM3MTgyIFRpbWVzdGFtcHMgYW5kIElDVnMuDQoNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICsNCg0KICAgICAgICAgICAgUkZDNzE4MyBzdHlsZSB0ZXh0IGJy
aW5naW5nIGl0IGFsbCB0b2dldGhlci4NCg0KVGhlIOKAnGFnZ3JlZ2F0ZWQgc2lnbmF0dXJlcyBh
cm91bmQgbXV0YWJsZSBmaWVsZOKAnSB3b3VsZCB2ZXJ5IGJlIGFuIGV4cGVyaW1lbnRhbCBleHRl
bnNpb24uDQoNCldoYXQgSSBvYmplY3QgdG8gaXMsIGlmIHRoZSBiYXNlIHNwZWMgc3BlY2lmaWNh
bGx5IHJlbmRlcnMgc3VjaCBleHRlbnNpb25zIGltcG9zc2libGUNCg0KDQoNCi0tDQpDaHJpc3Rv
cGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBw
bGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUOiAg
KzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0PiAgfCAg
RTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh
ZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1z
Zm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00y
IDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2Fp
Pg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBp
biBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5
IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IExvdHRl
IFN0ZWVuYnJpbmsgW21haWx0bzpsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZV0NClNlbnQ6
IDE3IE1hcmNoIDIwMTYgMTY6NDgNClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6
IGlldGZAdGhvbWFzY2xhdXNlbi5vcmc8bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmc+OyBN
b2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdA0KU3ViamVjdDogUmU6IFttYW5ldF0g
TWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2UgbXV0YWJpbGl0eSAod2FzIFJFOiBkcmFmdC1p
ZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1z
KQ0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRz
aWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3Ig
dGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGlj
ayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9y
bWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBl
bWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0
ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxh
Z3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9s
bG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dl
d29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3Bp
Y2lvdXMlMjBFbWFpbHMucGRmPi4NCkhpIGFsbCwNCg0KQW0gMTcuMDMuMjAxNiB1bSAxNzo0NCBz
Y2hyaWViIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0
ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PjoNCg0KR29vZCBw
b2ludCBhYm91dCB3aGV0aGVyIHlvdSBqdXN0IHBhc3Mgb24gb25lIGNvc3Qgb3IgYSBzZXQgb2Yg
Y29zdHMuIEFzIEkgc2FpZCwgbm90IGxvb2tlZCBhdCBkZXRhaWxzIC0gSSB3aWxsLCB3aGVuIHRp
bWUgcGVybWl0cy4gT25lIGNvc3QgaXMgbXVjaCBlYXNpZXIsIGFuZCB5ZXMsIGl0IHJlZHVjZXMg
dGhlIGZpeGVkIHNpemUgYWdncmVnYXRlZCBzaWduYXR1cmVzIHByb2JsZW0gdG8g4oCcanVzdOKA
nSBvbmUgb2YgY29tcHV0YXRpb25hbCBsb2FkLg0KDQpGb3IgdGhlIHJlY29yZCwgVGhvbWFz4oCZ
IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdDsgdGhlIGNvc3QgaXMgb25lIGFnZ3JlZ2F0ZWQgdmFs
dWUuDQoNCkJlc3QgcmVnYXJkcywNCkxvdHRlIFN0ZWVucmJpbmsNCg0KDQotLQ0KQ2hyaXN0b3Bo
ZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxp
ZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0
NCAoMCkxMjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4gIHwgIEU6
IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVz
eXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2Zv
cmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4
SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4N
CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4g
RW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBS
ZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBpZXRmQHRo
b21hc2NsYXVzZW4ub3JnPG1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3JnPiBbbWFpbHRvOmll
dGZAdGhvbWFzY2xhdXNlbi5vcmddDQpTZW50OiAxNyBNYXJjaCAyMDE2IDE2OjM4DQpUbzogRGVh
cmxvdmUsIENocmlzdG9waGVyIChVSykNCkNjOiBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxp
bmcgbGlzdA0KU3ViamVjdDogUmU6IE1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBtZXNzYWdlIG11dGFi
aWxpdHkgKHdhcyBSRTogW21hbmV0XSBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcg
LSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKQ0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhp
cyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhl
ciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2Fy
ZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0
dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3Mg
dGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhl
cmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkv
c3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBl
bWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50
cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0Rv
Y3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCg0KT24g
MTcgTWFyIDIwMTYsIGF0IDE3OjMwLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMu
ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu
Y29tPj4gd3JvdGU6DQoNCkkgYXBwcmVjaWF0ZSBUaG9tYXPigJlzIGNvbW1lbnRzIGFib3V0IHRo
ZSBsaW1pdGF0aW9ucyBvZiBtZXNzYWdlIHJlZ2VuZXJhdGlvbiwgYnV0IEkgd291bGQgYmUgYSBi
aXQgbGVzcyBhYnNvbHV0ZS4NCg0KVGhlIGlzc3VlcyBvdmVyIGVuZCB0byBlbmQgYXV0aGVudGlj
YXRpb24gYW5kIG1vcmUgYWR2YW5jZWQgc2lnbmF0dXJlcyBhcmUgdmFsaWQuIEkgbmVlZCB0byBy
ZWFkIHRoZSBnaXZlbiByZWZlcmVuY2Ugb24gYWdncmVnYXRlIHNpZ25hdHVyZXMgdG8gaW5jcmVh
c2UgbXkga25vd2xlZGdlICh0aGFua3MgZm9yIGl0KSwgYnV0IG15IHVuZGVyc3RhbmRpbmcgb2Yg
dGhlIHBvc3NpYmlsaXRpZXMgaW4gdGhpcyBmaWVsZCBtYXkgb2ZmZXIgYSBzb2x1dGlvbiB0byB0
aGUgcHJvYmxlbSwgYnV0IHdpdGggc29tZSBvdGhlciBpc3N1ZXMgKHBvc3NpYmx5IGluY2x1ZGlu
ZyBhIG5ldyB0eXBlIG9mIFRMVikuDQoNCkJ1dCB0aGUgaG9wIGNvdW50L2xpbWl0IHBvaW50IEkg
ZG9u4oCZdCBmdWxseSBhZ3JlZSB3aXRoLCB5b3UgY2FuIHJlZ2VuZXJhdGUgd2l0aCBhbiBpbmNy
ZW1lbnRlZC9kZWNyZW1lbnRlZCBjb3VudC9saW1pdCwgd2hpY2ggbGVhdmVzIHRoZSBhYmlsaXR5
IHRvIHByZXZlbnQgbWVzc2FnZXMgcHJvcGFnYXRpbmcgaW5kZWZpbml0ZWx5LCBpbmNsdWRpbmcg
ZXhwYW5kaW5nIHJpbmcgc2VhcmNoZXMsIGFuZCByZXRhaW5zIHRoZSBhYmlsaXR5IHRvIHVzZSBS
RkMgNTQ5NyBpbnRlcnZhbCBhbmQgdmFsaWRpdHkgdGltZXMgdGhhdCBtaWdodCBiZSB1c2VmdWwg
d2l0aCBhbiBleHBhbmRpbmcgcmluZyBzZWFyY2ggKG9yIG1pZ2h0IG5vdCkuDQoNCkJ1dCB0aGUg
a2V5IGlzc3VlIGlzIHRoYXQgQU9EVnYyIHdhbnRzIHRvIGFjY3VtdWxhdGUgbWV0cmljcy4gSSBz
dGlsbCBoYXZlbuKAmXQgZ290IHRvIHRoZSBib3R0b20gb2YgbWFueSBkZXRhaWxzIGhlcmUsIGJ1
dCBsZXTigJlzIGZvciB0aGUgbW9tZW50IGp1c3QgY29uc2lkZXIgdGhhdCBjb25jZXB0dWFsbHku
DQoNCkl04oCZcyBoYXJkIHRvIGhhbmRsZSBlbmQgdG8gZW5kLiBDaGFybGll4oCZcyBkcmFmdCBh
dHRlbXB0cyB0byBkbyBhbiBlbmQgdG8gZW5kIG9mIHNvbWUgaW5mb3JtYXRpb24sIG5vdCB0aGlz
IGluZm9ybWF0aW9uLiBJ4oCZbSBub3Qgc3VyZSBpZiB0aGF04oCZcyB1c2VmdWwgKGFuZCB0aGUg
c3BlY2lhbGlzZWQgZm9ybWF0IGlzIGJldHRlciBhdm9pZGVkIGlmIHBvc3NpYmxlKS4gT3RoZXIg
YXBwcm9hY2hlcyBhcmUgaG9wIGJ5IGhvcCAobWlnaHQgYXMgd2VsbCB1c2UgcGFja2V0IHNpZ25h
dHVyZXMpIGFuZCBzaGFyZWQga2V5IChtaWdodCBhcyB3ZWxsIGdvIGhvcCBieSBob3ApLiBQYWly
d2lzZSBzaWduYXR1cmVzIGZvciBlYWNoIHBhaXIgb2Ygcm91dGVycyBJ4oCZbSBkaXNjb3VudGlu
ZyBhcyBzY2FsaW5nIHRlcnJpYmx5LiBJbiB0aGUgaW50ZXJlc3RzIG9mIGNvbXBsZXRlbmVzcyBs
ZXTigJlzIG1lbnRpb24gbm90IGFjY3VtdWxhdGluZyBtZXRyaWNzLCB3aGljaCBwdXRzIHVzIGJh
Y2sgdG8gaG9wIGNvdW50IGFuZCB0aGF04oCZcyBub3QgaWRlYWwgZWl0aGVyLg0KDQpJIGRvbuKA
mXQgdGhpbmsgdGhlcmUgaXMgYW4gaWRlYWwgc29sdXRpb24uIChJIGxpa2UgaWRlYXMgSeKAmXZl
IHNlZW4gYWJvdXQgYWdncmVnYXRpbmcsIGJ1dCB0aGF0IGhhcyBzb21lIGlzc3VlcyBvZiBpdHMg
b3duLCBldmVuIGFwYXJ0IGZyb20gY29tcHV0YXRpb25hbCBsb2FkLikgSeKAmWQgbG92ZSB0byBi
ZSBwcm92ZWQgd3JvbmcgLSBzb21lb25lIHdpdGggdGhlIHBlcmZlY3Qgc29sdXRpb24gdG8gY29t
ZSBhbG9uZy4NCg0KV2hpY2ggbWVhbnMgdGhhdCBlaXRoZXIgd2UgbWFrZSBhbiBhcmJpdHJhcnkg
Y2hvaWNlIC0gd2hpY2ggd2lsbCBiZSBkaXNhZ3JlZWQgd2l0aCwgYnV0IG5lZWRzIGRpc2N1c3Np
bmcgZmlyc3QgLSBvciBjcmVhdGUgc29tZXRoaW5nIGZsZXhpYmxlLiBVbmZvcnR1bmF0ZWx5IGZs
ZXhpYmxlIGluIHRoYXQgcmVnYXJkIGNvbnN0cmFpbnMgaW4gb3RoZXJzLCBlLmcuIHNvbWUgKG1h
bnk/IG1vc3Q/KSBhZ2dyZWdhdGluZyBzaWduYXR1cmVzIG5lZWQgZml4ZWQgZGF0YSBzaXplcyAo
d2hpY2ggd2UgY2FuIGRvIGJ5IGRlZmluaW5nIGEgVExWIHRoYXQg4oCcZmlsbHMgdXDigJ0gd2l0
aCBob3AgY291bnQsIGJ1dCB0aGF0IGhhcyBhIGNvc3QgdG9vKS4NCg0KSSBoYXZlIGJlZW4gdG9s
ZCBieSBwZW9wbGUgbXVjaCBtb3JlIHdlbGwgdmVyc2VkIGluIHRoaXMgdGhhbiBJIGluIGNyeXB0
b2xvZ3ksIHRoYXQgdGhlIGNvcnJlY3QgYW5zd2VyIGlzIOKAnHNvbWXigJ0uDQoNClRoYXQgc2Fp
ZCwgIkFPRFZ2MiB3YW50cyB0byBhY2N1bXVsYXRlIG1ldHJpY3PigJ0g4oCUIGRvZXMgdGhhdCBt
ZWFuIHRoYXQgdGhlIG1lc3NhZ2UgZ3Jvd3MgYXMgaXQgaXMgYmVpbmcgZm9yd2FyZGVkLCBhbmQg
dGhhdCB0aGUgcmVjaXBpZW50IG9mIGEgUlJFUS9SUkVQIHdpbGwga25vdyB0aGUgaW5kaXZpZHVh
bCBjb3N0cyBvZiBlYWNoIHBhdGggc2VnbWVudD8gTXkgdW5kZXJzdGFuZGluZyBpcywgdGhhdCB0
aGUgcmVjaXBpZW50IHdpbGwgZ2V0IOKAnHRoZSBzdW0gdGhlIGNvc3RzIG9mIGVhY2ggcGF0aCBz
ZWdtZW504oCdIHdoaWNoIHNob3VsZCBiZSBmaXR0aW5nIHdpdGhpbiBhIGZpeGVkIHNpemU/DQoN
ClRob21hcw0KDQoNCg0KU29ycnksIG5vIGFuc3dlcnMsIGp1c3QgY29tbWVudHMuIEFuZCBJ4oCZ
bSBub3QgYWRkcmVzc2luZyBUaG9tYXPigJlzIGxhdGVyIHBvaW50cyBoZXJlLg0KDQotLQ0KQ2hy
aXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1z
IEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K
VDogICs0NCAoMCkxMjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4g
IHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92
ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENo
ZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4
IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNv
bS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVy
ZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1
cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBt
YW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpZXRmQHRo
b21hc2NsYXVzZW4ub3JnPG1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3JnPg0KU2VudDogMTcg
TWFyY2ggMjAxNiAxNjowMA0KVG86IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0
DQpTdWJqZWN0OiBbbWFuZXRdIGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEg
Y291cGxlIG9mIGJpZyB0aWNrZXQgSXRlbXMNCg0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVz
c2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJv
bSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxs
eSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2ht
ZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQg
eW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0
dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3Rs
aWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwg
aXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0
LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVu
dHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQoqKiogV0FSTklO
RyAqKioNCkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0
c2lkZSBvdXIgb3JnYW5pemF0aW9uLg0KDQpEZWFyIGFsbCwNCg0KQXBvbG9naWVzIGZvciBub3Qg
aGF2aW5nIGdvdHRlbiB0aGlzIGRvbmUgc29vbmVyIC0gZGF5LWpvYiBsZWF2aW5nIGZldyBzcGFy
ZSBjeWNsZXMuDQoNCknigJl2ZSBwcmV2aW91c2x5IG9mZmVyZWQgcmV2aWV3cyBhbmQgY29tbWVu
dHMsIGFuZCBzb21lIG9mIHRob3NlIGhhdmUgYmVlbiBhZGRyZXNzZWQgaW4gdGhlIGxhdGVzdCBJ
LUQg4oCUIG90aGVycyBoYXZlIG5vdCwgYnV0IHNob3VsZCBiZS4gSSByZWNhbGwgdGhhdCB0aGVy
ZSB3YXMgc29tZSBtYWlsIGF0dGVtcHRpbmcgdG8gcmVidXQgcGFydHMgb2YgdGhlIHJldmlldywg
YW5kIEkgd2lsbCBkaWcgaXQgb3V0IGFuZCByZXBseSB0byB0aGF0Lg0KDQpXaXRoIHRoYXQgYmVp
bmcgc2FpZCwgSSBoYXZlIHJldmlld2VkIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgZG9jdW1l
bnQsIGFuZCBmdWxsIGRldGFpbHMgd2lsbCBiZSBmb3J0aGNvbWluZy4gVGhlcmXigJlyZSBhIGNv
dXBsZSBvZiBiaWctdGlja2V0L2FyY2hpdGVjdHVyYWwgaXRlbXMgdGhhdCBJIHdhbnQgdG8gYWRk
cmVzcyB1cCBmcm9udCwgYXMgSSBiZWxpZXZlIHRoYXQgYmVmb3JlIHdlIGhhdmUgdGhvc2UgaGFt
bWVyZWQgb3V0LCBpdCB3aWxsIGJlIHVzZWxlc3MgdG8gZ28gaW50byBkZXRhaWxzLiBOb3RlLCBJ
IGRvIG5vdCBjbGFpbSB0aGF0IHRoaXMgaXMgYW4gZXhoYXVzdGl2ZSBsaXN0IG9mIOKAnGJpZyB0
aWNrZXQgaXRlbXPigJ0sIGJ1dCB0aGF04oCZcyBhcyBmYXIgYXMgSSBoYXZlIGdvdHRlbiBpbiB0
aGlua2luZyB0aGlzIHRocm91Z2guDQoNCkkgYWxzbyBicmluZyB0aGVzZSB1cCBhcyB0aGV5IGFy
ZSBpdGVtcyB0aGF0IGhhdmUgYmVlbiBicm91Z2h0IHVwIHJlcGVhdGVkbHkgb3ZlciB0aGUgcGFz
dCB5ZWFycywgYnV0IG5vdCByZXNvbHZlZCBub3IgZGlzY3Vzc2VkLg0KDQpMb29wcw0KSnVzdCB0
byBicmluZyB0aGlzIG91dDogSSBzaGFyZSBDaHJpc+KAmSB3b3JyeSBhYm91dCBjb25mbGljdGlu
ZyBhbmQgY29uY3VycmVudCBzdGF0ZW1lbnRzIGZyb20gdGhlIGF1dGhvcnMgb24g4oCcVGhlcmUg
YXJlIG5vIGxvb3BzIHBvc3NpYmxl4oCdIGFuZCDigJxXZSBuZWVkIHRvIGZpeCB0d28gc2l0dWF0
aW9ucyB3aGVyZSBsb29wcyBjYW4gb2NjdXLigJ0gYW5kIOKAnHdlIGFyZSBzdGlsbCBpbnZlc3Rp
Z2F0aW5nIHNvbWUgbG9vcCBjb25kaXRpb25z4oCdDQoNCkkgcGFydGljdWxhcmx5IHdvcnJ5IHRo
YXQgdGhpcyBpcyBub3QgYSBkaXNjdXNzaW9uIGhhZCBpbiBwdWJsaWMsIGJ1dCBhcHBhcmVudGx5
IGluIHNvbWUgb3RoZXIgZm9ydW3igKYNCg0KDQpJbnRlcm1lZGlhdGUgUm91dGUgUmVwbGllcywg
YW5kIGFsbCBvZiBzZWN0aW9uIDEwDQpTZWN0aW9uIDEwIGNvbnRhaW5zIGEgc2V0IG9mIOKAnHZh
Z3VlbHkgc3BlY2lmaWVkIGV4dGVuc2lvbnPigJ0sIHdoaWNoIGlzIGluY29oZXJlbnQgd2l0aCB0
aGUgaW50ZW5kZWQgc3RhdHVzIGluZGljYXRlZCBmb3IgdGhpcyBkb2N1bWVudC4NCg0KU3BlY2lm
aWNhbGx5LCBhbmQgdGhpcyBpcyBub3QgdW5yZWxhdGVkIHRvIHRoZSBwb2ludCBhYm91dCBsb29w
cyBhYm92ZSwgaW50ZXJtZWRpYXRlIFJSRVBzIChzZWN0aW9uIDEwLjMpIGFyZSBhIHBvdGVudGlh
bCBzb3VyY2UgZm9yIGxvb3BzLg0KDQpFeHBhbmRpbmcgUmluZyBNdWx0aWNhc3QgKHNlY3Rpb24g
MTAuMSkgaXMgbm90IGRvY3VtZW50ZWQgaW4gYSB3YXkgdGhhdCBjYW4gYmUgaW1wbGVtZW50ZWQg
KGFuZCBhbHNvLCBzZWUg4oCcRm9yd2FyZGluZy12cy1yZWdlbmVyYXRpb27igJ0gYmVsb3csIGl0
IGlzIGluIHRoZSBwcmVzZW50IGZvcm0gb2YgdGhpcyBwcm90b2NvbCBpbXBvc3NpYmxlKSwgZXRj
Lg0KDQoNCkZvcndhcmRpbmctdnMtcmVnZW5lcmF0aW9uDQpSZWNlbnQgZXhjaGFuZ2VzIG9uIHRo
ZSBsaXN0IG1hZGUgbWUgdW5kZXJzdGFuZCB0aGF0IHByb3RvY29sIGNvbnRyb2wgbWVzc2FnZXMg
YXJlICpub3QqIGZvcndhcmRlZCwgYnV0IGFyZSBjb25zdW1lZCBhdCBlYWNoIGhvcCwgdGhlbiBh
IG5ldyBtZXNzYWdlIHdpdGggKGFsbW9zdC1idXQtbm90LXF1aXRlKSB0aGUgc2FtZSBjb250ZW50
IGlzIGdlbmVyYXRlZCBhbmQgdHJhbnNtaXR0ZWQuDQoNCkkgaGF2ZSB0aG91Z2h0IHNvbWUgbW9y
ZSBvbiB0aGlzICgmIHJlYWQgc29tZSBvZiB0aGUgZXhjaGFuZ2VzIG9uIHRoZSBsaXN0IG9uIHRo
aXMgdG9waWMgYnkgQ2hyaXMsIFVscmljaCwgYW5kIG90aGVycyksIGFuZCBJIGFtIGNvbnZpbmNl
ZCB0aGF0IHRoaXMgaXMgbm90IHRoZSByaWdodCB3YXkgdG8gZ28sIGF0IGxlYXN0IGZvciB0aGUg
Zm9sbG93aW5nIHJlYXNvbnM6DQoNCg0KICAgICAgICAgICAgbyAgICAgICAgICBJdCByZW5kZXJz
IHRoZSBob3AtbGltaXQvaG9wLWNvdW50IGZpZWxkcyBpbiB0aGUgUkZDNTQ0NCBtZXNzYWdlIGhl
YWRlciB1c2VsZXNzLg0KICAgICAgICAgICAgICAgICAgICAgICAgVGhpcyB3b3VsZCBub3QgYmUg
YmFkIGlmIHRoZSBmdW5jdGlvbmFsaXR5IG9mZmVyZWQgYnkgdGhvc2UgZmllbGRzIHdhcyBub3Qg
dXNlZnVsDQogICAgICAgICAgICAgICAgICAgICAgICDigJQgc2FkbHksIGl0IGlzLiBGb3IgZXhh
bXBsZSwgZm9yIHNjb3BlIGxpbWl0ZWQgZmxvb2RpbmcgKGV4cGFuZGluZyByaW5nIHNlYXJjaCwg
YW5kDQogICAgICAgICAgICAgICAgICAgICAgICBzdWNoKSB3aGljaCBtYXkgYmUgb2YgaW50ZXJl
c3QsIGFuZCB3aGljaCByZXF1aXJlIGhvcC1saW1pdC4NCiAgICAgICAgICAgICAgICAgICAgICAg
IEEgaG9wLWNvdW50IGZpZWxkIG1heSBhbHNvIHByb3ZpZGUgYSDigJxjaGVhcOKAnSAoaW4gdGVy
bXMgb2Ygb3ZlcmhlYWQpIGFkZGl0aW9uYWwgcGllY2UNCiAgICAgICAgICAgICAgICAgICAgICAg
IG9mIGluZm9ybWF0aW9uIHRvIHVzZSBjb25qdW5jdGl2ZWx5IHdpdGggYSDigJxyZWFs4oCdIG1l
dHJpYy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgVGhlIG9ubHkgcHJhY3RpY2FsIHNvbHV0
aW9uIHdvdWxkIGJlIHRvIHJlLWludHJvZHVjZSB0aGVzZSBmdW5jdGlvbnMgYnkgd2F5IG9mIGlu
c2VydGluZyBhDQogICAgICAgICAgICAgICAgICAgICAgICBNZXNzYWdlVExWIOKAlCB3aGljaCAo
aSkgaXMgbm90IHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50LCBhbmQgKGlpKSB3aGljaCB3b3Vs
ZCBqdXN0DQogICAgICAgICAgICAgICAgICAgICAgICBzZXJ2ZSB0byByZW5kZXIgbWVzc2FnZXMg
YmlnZ2VyIHRoYW4gc3RyaWN0bHkgbmVlZGVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICBT
Y29wZSBsaW1pdGVkIGZsb29kaW5nICBkb2VzIHNlZW0gdG8gYmUgYSBuZWNlc3NhcnkgcmVxdWly
ZW1lbnQsIGlmIGZvciBubw0KICAgICAgICAgICAgICAgICAgICAgICAgb3RoZXIgcmVhc29uIHRo
YW4gdG8gcHJldmVudCBpbmZvcm1hdGlvbiBmcm9tIOKAnGNpcmN1bGF0aW5nIGZvcmV2ZXIgaW4g
dGhlIG5ldHdvcmvigJ0uDQoNCiAgICAgICAgICAgIG8gICAgICAgICAgSXQgbWFrZXMgZW5kLXRv
LWVuZCBhdXRoZW50aWNhdGlvbiB1bm5lY2Vzc2FyaWx5IGhhcmQuDQogICAgICAgICAgICAgICAg
ICAgICAgICBJIHRoaW5rIENocmlzIGNhbGxlZCB0aGlzIG91dCBhbHJlYWR5LCBidXQgaXQgYmVh
cnMgcmVwZWF0aW5nOiBTIGdlbmVyYXRlcyBhIG1lc3NhZ2UNCiAgICAgICAgICAgICAgICAgICAg
ICAgIChzYXksIGEgUlJFUSksIGFuZCBpbmNsdWRlcyBhbiBJQ1YgY2FsY3VsYXRlZCBvdmVyIHRo
ZSBjb250ZW50IG9mIHRoZSBtZXNzYWdlLg0KICAgICAgICAgICAgICAgICAgICAgICAgRm9yIGFu
eSByZWNpcGllbnQgdG8gYmUgYWJsZSB0byB2YWxpZGF0ZSB0aGUgSUNWLCB0aGUgbWVzc2FnZSBo
YXMgdG8gYmUgZXhhY3RseQ0KICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHNhbWUg4oCUIG5v
dCBqdXN0IGluIGNvbnRlbnQsIGJ1dCBpbiBzdHJ1Y3R1cmUg4oCUIGFzIHdoYXQgd2FzIGdlbmVy
YXRlZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAg4oCcUmVnZW5lcmF0aW5n4oCdIHJhdGhl
ciB0aGFuIOKAnGZvcndhcmRpbmfigJ0gbWVzc2FnZXMgbWVhbnMsIHRoYXQgdGhlIGludGVybWVk
aWF0ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgcm91dGVyIOKAnHJlZ2VuZXJhdGluZ+KAnSB0
aGUgUlJFUSBtYXkgY2hvc2UgYSBkaWZmZXJlbnQgc3RydWN0dXJlIChlLmcuLCBpbmNsdWRlIFRM
VnMNCiAgICAgICAgICAgICAgICAgICAgICAgIGluIGEgZGlmZmVyZW50IG9yZGVyKS4NCg0KICAg
ICAgICAgICAgICAgICAgICAgICAgVGhlIHByb3Bvc2FsIGZyb20gaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LXBlcmtpbnMtbWFuZXQtYW9kdi1lMmVzZWMtMDANCiAgICAgICAgICAg
ICAgICAgICAgICAgIGlzIHRvIGFkZCBjb25zdHJhaW50cyBvbiAoaSkgdGhlIHNldCBvZiBlbGVt
ZW50cyB0byBpbmNsdWRlIGluIGEgc2lnbmF0dXJlIGFuZCAoaWkpIHRoZQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgb3JkZXIgb2YgdGhlc2UgZWxlbWVudHMuDQoNCiAgICAgICAgICAgICAgICAg
ICAgICAgIE9uZSBwcm9ibGVtIHdpdGggdGhhdCBhcHByb2FjaCBpcyAoaSk6IGlmIGFuIGV4dGVu
c2lvbiBhZGRzIGEgbWVzc2FnZSBUTFYsIG9yIGFuDQogICAgICAgICAgICAgICAgICAgICAgICBB
ZGRyZXNzIFRMViwgdG8gYSBtZXNzYWdlLCB0aGVuIHRoYXQgd2lsbCBub3QgYmUg4oCcY292ZXJl
ZOKAnSBieSB0aGUgcHJvcG9zZWQgZTJlc2VjIFRMVi4NCiAgICAgICAgICAgICAgICAgICAgICAg
IFJhdGhlciBmb3IgKmVhY2gqIGV4dGVuc2lvbiBkZXZlbG9wZWQsIGFuIOKAnHVwZGF0ZXMgZTJl
c2Vj4oCdIGNsYXVzZSBuZWVkcyB0byBiZSBkb25lLg0KDQogICAgICAgICAgICAgICAgICAgICAg
ICBJ4oCZZCBzYXkgdGhhdCB0aGlzIGFwcHJvYWNoIHdvdWxkIGJlIHByb25lIHRvIGVycm9ycyDi
gJQgYW5kIGFkZCBlbnRyb3B5IHRvIHRoZSBwcm9jZXNzDQogICAgICAgICAgICAgICAgICAgICAg
ICBvZiBkZXNpZ25pbmcgcHJvdG9jb2wgZXh0ZW5zaW9ucy4gVGhlIGFsdGVybmF0aXZlLCBhIG1l
c3NhZ2UgYmVpbmcgZ2VuZXJhdGVkIGJ5IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgc291
cmNlIGFuZCAqZm9yd2FyZGVkKiAoYXMgd2UgZG8gaW4gT0xTUnYyLCBmb3IgZXhhbXBsZSkgd291
bGQgYWxsb3cgSUNWIFRMVnMNCiAgICAgICAgICAgICAgICAgICAgICAgIChldmVuLCBhbGxvdyBy
ZXVzZSBvZiB0aG9zZSBzcGVjaWZpZWQgZm9yIE9MU1J2MikgZm9yIGNvdmVyaW5nIGEgbWVzc2Fn
ZSBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgIGV4dGVuc2lvbnMuDQoNCiAgICAgICAgICAg
ICAgICAgICAgICAgIOKAnEJ1dCB3aGF0IGFib3V0IHRoZSBtZXRyaWNzIHZhbHVlIHdoaWNoIHdp
bGwgY2hhbmdlIG9uIGVhY2ggaG9w4oCdLCB5b3UgbWF5IHNheT8NCiAgICAgICAgICAgICAgICAg
ICAgICAgIEZvcnR1bmF0ZWx5LCB0aGF0IGlzIHJlbGF0aXZlbHkgZWFzeSB0byBoYW5kbGU6IHNp
bXBseSB6ZXJvIG91dCB0aGUgdmFsdWUgb2YgdGhhdCBUTFYgd2hlbg0KICAgICAgICAgICAgICAg
ICAgICAgICAgZ2VuZXJhdGluZyBvciB2ZXJpZnlpbmcgdGhlIElDViBNZXNzYWdlVExWLiBBbmQg
dXNlIFBhY2tldC1UTFZzIGZvciBob3AtYnktaG9wDQogICAgICAgICAgICAgICAgICAgICAgICBh
dXRoZW50aWNhdGlvbiwgaWYgbmVlZGVkIChidXQsIHNlZSBiZWxvdykuDQoNCiAgICAgICAgICAg
IG8gICAgICAgICAgSXQgcHJldmVudHMgdGhlIHVzZSBvZiBtb3JlIGNsZXZlci9hZHZhbmNlZCBz
aWduYXR1cmUgc2NoZW1lcy9JQ1ZzDQogICAgICAgICAgICAgICAgICAgICAgICBBZ2dyZWdhdGUg
c2lnbmF0dXJlIGFsZ29yaXRobXMgKCBodHRwczovL2NyeXB0by5zdGFuZm9yZC5lZHUvfmRhYm8v
cGFwZXJzL2FnZ3N1cnZleS5wZGYpDQogICAgICAgICAgICAgICAgICAgICAgICBleGlzdCwgYW5k
IGFuIGludGVyZXN0aW5nIHVzZS1jYXNlIGNhbiBiZSBmb3VuZCBpbiBhbHNvIHJlYWN0aXZlIHBy
b3RvY29scywgYWxsb3dpbmcgdmVyaWZ5aW5nDQogICAgICAgICAgICAgICAgICAgICAgICBub3Qg
4oCcanVzdOKAnSB0aGUgZW5kIHBvaW50cywgYnV0IGFsc28gdGhlIGludGVybWVkaWFyaWVzIChh
Z2Fpbiwgd2l0aCB0aGUgYXBwcm9wcmlhdGUg4oCcemVybyBvdXTigJ0NCiAgICAgICAgICAgICAg
ICAgICAgICAgIGRpc2N1c3NlZCBhYm92ZSwgb3Igc29tZXRoaW5nIHNtYXJ0ZXIpLg0KICAgICAg
ICAgICAgICAgICAgICAgICAgUmVnZW5lcmF0aW9uIG9mIG1lc3NhZ2VzLCByYXRoZXIgdGhhbiBm
b3J3YXJkaW5nLCByZW5kZXJzIHRoYXQgaW1wb3NzaWJsZSAob3IsIGlmIHVzZWQsDQogICAgICAg
ICAgICAgICAgICAgICAgICB1cGRhdGluZyB0byAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LXBlcmtpbnMtbWFuZXQtYW9kdi1lMmVzZWMtMDApDQoNClRoZXJlIGFyZSBvdGhlciBy
ZWFzb25zLCBidXQgdGhlIGFib3ZlIGFyZSB0aG9zZSB0aGF0IGp1bXAgYXQgbWUgYXMgaW1tZWRp
YXRlIHNob3ctc3RvcHBlcnMuDQoNCkkgZG8gaG9uZXN0bHkgbm90IHNlZSB3aGF0IHBvc3NpYmxl
IGJlbmVmaXQgdGhlcmUgaXMgZnJvbSDigJxyZWdlbmVyYXRpb27igJ0g4oCUIGJ1dCBJIHNlZSB2
ZXJ5IGNsZWFyIGluY29udmVuaWVuY2VzLCBhbmQgc2VjdXJpdHkgaXMgbm90IHRoZSBsZWFzdCBv
ZiB0aGVzZS4gSW5zaXN0aW5nIG9uIOKAnHJlZ2VuZXJhdGlvbuKAnSByZXF1aXJlcyBkZXZlbG9w
bWVudCBvZiDigJxub24tZ2VuZXJhbCB3b3JrYXJvdW5kc+KAnSBhcyBwb2ludGVkIG91dCBhYm92
ZS4NCg0KU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNClRoaXMgaXMgYW4gYWx3YXlzIHRob3JueSBz
dWJqZWN0LiBXaGVuIE9MU1J2MiB3YXMgZ29pbmcgdGhyb3VnaCB0aGUgcHJvY2VzcyB3ZSBnb3Qg
YSB0aG9yb3VnaCBlZHVjYXRpb24gaW4gaG93IGxpdHRsZSB3ZSBrbmV3IGFib3V0IHNlY3VyaXR5
IGZyb20gdGhlIFNFQy1BRHMsIGFuZCBoYWQgdG8gc3BlbmQgYWJvdXQgYSB5ZWFyIG9yIHNvIGRl
dmVsb3BpbmcgUkZDNzE4My4gVGhlIGJvdHRvbSBsaW5lIGlzLCB0aGF0IHRoaXMgcHJvdG9jb2wg
bmVlZHMgaXRzIOKAnFJGQzcxODMgIGVxdWl2YWxlbnTigJ0sIGVpdGhlciBhcyBwYXJ0IG9mIHRo
ZSBtYWluIGRvY3VtZW50LCBvciBhcyBhbiBpbmRlcGVuZGVudCBkb2N1bWVudC4gY3VycmVudGx5
LCB0aGF0IGlzIG5vdCB0aGUgY2FzZS4NCg0KQSBtaW5pbWEsIGxvb2tpbmcgYXQgQkNQNzIgYW5k
IEJDUDEwNyDigJQgdGFraW5nIGluc3BpcmF0aW9uIGZyb20gUkZDNzE4MyBtaWdodCBiZSBhdyBn
b29kIGlkZWEsIGFzIHRoYXQgd2FzIHRoZSBtb3N0IHJlY2VudCB0aGF0IHdlbnQgdGhyb3VnaCB0
aGUgU0VDIEFELiBSZWdhcmRsZXNzIG9mIGhvdywgaG93ZXZlciwgYSDigJxtYW5kYXRvcnkgdG8g
aW1wbGVtZW504oCdIHNlY3VyaXR5IG1lY2hhbmlzbSBtb3N0IGJlIHNwZWNpZmllZCAoSSB0aGlu
ayB0aGUgcmlnaHQgdGVybSB3YXMg4oCcTVVTVCBpbXBsZW1lbnQsIFNIT1VMRCB1c2XigJ0pLCBp
biBzdWZmaWNpZW50IGRldGFpbCB0byBlbnN1cmUgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlv
bnMuDQoNCkFzIGFuIGV4YW1wbGUsIGJvdGggW1JGQzYxMzBdIGFuZCBbUkZDNzE4MV0gc2V0IG91
dCB0aGF0IHRoYXQ6DQoNCiAgICAgIE9uIHJlY2VpdmluZyBhIC4uLiBtZXNzYWdlLCBhIHJvdXRl
ciBNVVNUIGZpcnN0IGNoZWNrIGlmIHRoZQ0KICAgICAgbWVzc2FnZSBpcyBpbnZhbGlkIGZvciBw
cm9jZXNzaW5nIGJ5IHRoaXMgcm91dGVyDQoNCmFuZCB0aGVuIHByb2NlZWQgdG8gZ2l2ZSBhIG51
bWJlciBvZiBjb25kaXRpb25zIHRoYXQsIGVhY2gsIHdpbGwgbGVhZCB0byBhIHJlamVjdGlvbiBv
ZiB0aGUgbWVzc2FnZSBhcyAiYmFkbHkgZm9ybWVkIGFuZCB0aGVyZWZvcmUgaW52YWxpZCBmb3Ig
cHJvY2Vzc2luZ+KAnSDigJQgYSBsaXN0IHdoaWNoIFJGQzcxODMgdGhlbiBhbWVuZGVkLiBUaGF0
IGdhdmUgYSDigJxob29r4oCdIGZvciBSRkM3MTgzIGZvciBpbnNlcnRpbmcg4oCccmVqZWN0aW9u
4oCdLiBJZGVtIGZvciBtZXNzYWdlIGdlbmVyYXRpb24uDQoNCklmIEkgd2FzIHRvIGRvIFJGQzcx
ODEvUkZDNjEzMCB0b2RheSwgSSB3b3VsZCBpbmNsdWRlIHRoYXQgZGlyZWN0bHkgaW50byB0aGUg
cHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMuIEl0IHR1cm5lZCBvdXQgdG8gYmUgbW9yZSBvdmVyaGVh
ZCAoYW5kIHNsb3cgZG93biBwdWJsaWNhdGlvbiBhbnl3YXlzKSB0byBkbyBpdCBhcyBzZXBhcmF0
ZSBkb2N1bWVudHMuDQoNClNlY29uZGx5LCB3ZSBuZWVkIHRvIGJlIGEgbG90IG1vcmUgcmlnaWQg
aW4gdGVybXMgb2Ygd2hhdCBJQ1ZzLCBUaW1lc3RhbXBzLCBldGMuIGFyZSBhZGRlZC9yZW1vdmVk
LCBhbmQgd2hhdCB0aGF0IGJyaW5ncy4NCg0KRm9yIGV4YW1wbGUgKHdpdGggdGhlIGFzc3VtcHRp
b24gdGhhdCBtZXNzYWdlcyBhcmUgKmZvcndhcmRlZCogYW5kICpub3QqIHJlZ2VuZXJhdGVkKSwg
dGhpcyBjb3VsZCBiZSBvbmUgb3B0aW9uOg0KDQogICAgICAgICAgICAgICAgICAgICAgICBvICAg
ICAgICAgIFdoZW4gYSBSUkVRLCBSUkVQIG1lc3NhZ2UgaXMgZ2VuZXJhdGVkLCBhZGQgYW4gSUNW
IE1lc3NhZ2UgVExWLCB3aGljaCBpcyBjYWxjdWxhdGVkIDx0aGlzIHdheT4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICDigKYodGFrZSBpbnNwaXJhdGlvbiBmcm9tIFJGQzcx
ODMgaGVyZSkNCg0KLi4uDQoNCltNZXNzYWdlIGNsaXBwZWRdDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBp
ZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL21hbmV0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzpt
YW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFu
ZXQNCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBj
b25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkDQpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHBy
aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50IHBsZWFzZSBk
ZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuDQpZb3Ugc2hv
dWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9y
DQpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLg0KKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1h
bmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQoNCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcg
bGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1593GLKXM0002VGREEN_
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
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkni
gJltIGFmcmFpZCBJIGRpZG7igJl0IHVuZGVyc3RhbmQgeW91ciBmaXJzdCBwYXJhZ3JhcGgg4oCc
Zml44oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+V2l0aCByZWdhcmQgdG8gdGhlIGZsYWcvYWRkcmVzcywgSSBtdXN0
IGFkbWl0IG15IGFuYWx5c2lzIHdhcyBvbmUgc3RlcCBtaXNzaW5nLiBJIGdvdCBhcyBmYXIgYXMg
YXJndWluZyBpdCB3b3VsZCBiZSB0aGUgc2FtZSBldmVyeXdoZXJlIGluIHNwYWNlLiBJIGRpZG7i
gJl0IHRha2UNCiB0aGF0IHRoZSBleHRyYSBzdGVwICh3aGljaCBpcyBtdWNoIHRoZSBzYW1lIGFy
Z3VtZW50KSB0byB0aGUgc2FtZSBldmVyeXdoZXJlIGluIHRpbWUuIEF0IHdoaWNoIHBvaW50IHdl
IGRvbuKAmXQgbmVlZCB0aGUgZmxhZy0gKGFuZCwgSeKAmW0gc2F5aW5nLCB3ZSBkb27igJl0IG5l
ZWQgdGhlIGFkZHJlc3MgYmVjYXVzZSBpdOKAmXMgdGhlIElQIHNvdXJjZSBhZGRyZXNzLiAoVGhv
bWFzIHJhaXNlcyB0aGUgaXNzdWUgb2YgaW50ZXJmYWNlcy4gTG9jYWxseSB5b3UNCiBzaG91bGQg
a25vdyB3aGljaCBpbnRlcmZhY2UgeW91IHJlY2VpdmVkIG9uIC0gYW5kIDU0NDQgdXNhZ2UgbWFr
ZXMgdGhhdCBjbGVhcmVyLCBidXQgaXMgYWxyZWFkeSByZWxpZWQgb24gYnkgTkhEUC4pPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPG86cD48L286cD48L3NwYW4+
PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhl
ciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVt
cyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48
YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNw
OyYjNDM7NDQgKDApMTI0NSAyNDIxOTQgJm5ic3A7fCAmbmJzcDs8Yj5FOg0KPC9iPjxhIGhyZWY9
Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFl
c3lzdGVtcy5jb208L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz
QThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hu
b2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4N
CjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiPjxzcGFuIHN0eWxlPSJjb2xv
cjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJy
Pg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t
OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVy
ZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3
WVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij4gSnVzdGluIERlYW4gW21haWx0bzpiZWJlbWFzdGVyQGdtYWlsLmNvbV0N
Cjxicj4NCjxiPlNlbnQ6PC9iPiAyNSBBcHJpbCAyMDE2IDE1OjIwPGJyPg0KPGI+VG86PC9iPiBE
ZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4NCjxiPkNjOjwvYj4gVmljdG9yaWEgTWVyY2ll
Y2E7IEppYXppIFlJOyBDaHJpc3RvcGhlciBEZWFybG92ZTsgTW9iaWxlIEFkIEhvYyBOZXR3b3Jr
cyBtYWlsaW5nIGxpc3Q8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gTWVzc2FnZSBp
bnRlZ3JpdHkgYW5kIG1lc3NhZ2UgbXV0YWJpbGl0eSAod2FzIFJFOiBkcmFmdC1pZXRmLW1hbmV0
LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4w
cHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5
bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs
YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6
d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdB
Uk5JTkcgKioqPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20g
b3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVy
IG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdo
ZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRz
IG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9u
IHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48
ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2Fu
IGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0
cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxp
Z2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxp
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0K
PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2Vj
dXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIw
RW1haWxzLnBkZiI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgdGhvdWdo
dCByZWdhcmRpbmcgaW50ZWdyaXR5IGNoZWNraW5nLiZuYnNwOyBBIHBvc3NpYmxlIGZ1dHVyZSAm
cXVvdDtmaXgmcXVvdDsgZm9yIGludGVncml0eSBjb3VsZCBiZSBkb25lIG9uIGEgJnF1b3Q7dmly
dHVhbCZxdW90OyBwYWNrZXQgaW4gd2hpY2gga25vd24gVExWcy92YWx1ZXMgYWxvbmcgd2l0aCBv
cmRlcmVkIGFkZHJlc3NlcyBhcmUgdW5jb21wcmVzc2VkIGFuZCB0aGVuIHZlcmlmaWVkLiZuYnNw
OyBJdCBjb3VsZCBhbGxvdyBleHRyYSBUTFYgdGFnZ2luZw0KIHdpdGhvdXQgbW9kaWZ5aW5nIHRo
ZSB2YWxpZGl0eSBvZiB0aGF0IGRhdGEuJm5ic3A7IFRoZSB2ZXJ5IGJpZyBkcmF3YmFjayB3b3Vs
ZCBiZSB0aGUgb3ZlcmhlYWQgb2YgaGF2aW5nIHRvIHVuY29tcHJlc3NlZCBldmVyeXRoaW5nIHRv
IGNoZWNrIHRoZSB2YWxpZGl0eS4mbmJzcDsgSXQncyBmdW5jdGlvbmFsbHkgdGhlIHNhbWUgYXMg
emVyb2luZyBvdXQgbG9jYWwgKHRoaXMgaXMgbXkgc3R1ZmYpIFRMViBkYXRhIHZzIHJlbW90ZSAo
dGhpcyBpcyBub3QgbXkgc3R1ZmYpDQogVExWIGRhdGEuICZuYnNwOzxicj4NCjxicj4NCkFzIGZv
ciB0aGUgUlJFUC1BY2sgaGF2aW5nIGEgZmxhZyB2cyBhbiBhZGRyZXNzIGRvZXNuJ3QgbXVjaCBi
b3RoZXIgbWUgYXMgZWl0aGVyIHdvdWxkIGhhdmUgdG8gYmUgemVyb2VkIG91dCBmb3IgdGhpcyB0
eXBlIG9mIGZ1dHVyZSBpbnRlZ3JpdHkgY2hlY2tpbmcuPGJyPg0KPGJyPg0KSnVzdGluPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEFwciAyNSwg
MjAxNiBhdCA5OjI3IEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0i
bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hy
aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXNzdW1pbmcgZm9yIHRoZSBtb21lbnQgdGhhdCBldmVy
eW9uZSB3aWxsIG5lZWQgYW4gUlJFUC1BY2sgb3Igd29u4oCZdCAobGV04oCZcyBjb21lIGJhY2sg
dG8gdGhhdCkgd2h5DQogZG8gQyBhbmQgQiBuZWVkIHRvIHB1dCBhbiBhZGRyZXNzIGluIGFzIGFu
IFJSRVEtQWNrIHJlcXVlc3Q/IFdoeSBub3QgYSBmbGFnLCBiZWNhdXNlIHRoZSBhZGRyZXNzIHdp
bGwgYmUgaW5jbHVkZWQgYXMgdGhlIElQIHNlbmRpbmcgYWRkcmVzcyAtIGFuZCB3ZSBrbm93IDU0
NDQgaXMgcmVxdWlyZWQgdG8gcGFzcyB0aGF0IG9uLiAoSXTigJlzIHVzZWQgYnkgTkhEUCBhcyB3
ZWxsLikgVGhlbiB3ZSBkb27igJl0IG5lZWQgdG8gY2hhbmdlIHRoZSBSUkVQLA0KIGl0IHdpbGwg
aGF2ZSBhIGZsYWcgc2V0IG9yIG5vdCwgYW5kIHdvbuKAmXQgY2hhbmdlIChpbiB0aGlzIHJlZ2Fy
ZCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+Tm93IGxldOKAmXMgY29uc2lkZXIgZG8gd2Uga25vdyB3aGV0aGVy
IHdlIGNhbiBzZXQgYSBmaXhlZCBmbGFnLiBGaXJzdCBJ4oCZZCBzYXkgdGhlcmUgYXJlIHR3byBj
YXNlcw0KIC0geW914oCZdmUgZ290IGEgZmlybSBjb250cm9sIG9uIHdoYXTigJlzIGdvaW5nIG9u
IGluIHlvdXIgbmV0d29yaywgb3IgaXTigJlzIG9uZSBvZiB1bmtub3duIHBhcnRpZXMgYW5kIGJl
aGF2aW91ciAoY29uc2lzdGVudCB3aXRoIHNwZWNpZmljYXRpb24pLiBJbiB0aGUgZm9ybWVyIGNh
c2UgeW91IG9ubHkgd2FudCBvbmUgc2V0dGluZywgZm9yIGV4YW1wbGUgbm8tQWNrIGlmIHJ1bm5p
bmcgTkhEUCBvciB5b3VyIE1BQyBsYXllciB0ZWxscyB5b3UgYWJvdXQNCiBiaWRpcmVjdGlvbmFs
aXR5LCBBY2sgb3RoZXJ3aXNlLiBJbiB0aGUgbGF0dGVyIGNhc2UsIEkgdGhpbmsgeW91IGp1c3Qg
YWx3YXlzIHdhbnQgYW4gQWNrLiBTbyBib3RoIGNhc2VzIGdldCB5b3UgdG8gdGhlIHNhbWUgcGxh
Y2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+U2hvdWxkIHRoYXQgbm90IGJlIGFuIGFjY2VwdGFibGUgYXJndW1l
bnQgKHRob3VnaCBJIHRoaW5rIGl04oCZcyBnb29kIGZvciB3aGVyZSB3ZSBhcmUgLSBpbiBmYWN0
IGFsd2F5cw0KIEFjayBpcyBjbG9zZSkgdGhlbiBhdCBmbGFnIGlzIGEgc3RlcCBiZXR0ZXIsIGl0
4oCZcyBhIGZpeGVkIGxvY2F0aW9uIHRvIGNoYW5nZS4gSG93ZXZlciBpdCB3b3VsZCBiZSBiZXR0
ZXIgaW4gdGhhdCBjYXNlIGlmIHRoZSB0d28gdGhpbmdzIHRvIGNoYW5nZSAobWV0cmljIGFuZCBh
Y2sgZmxhZykgd2VyZSB0b2dldGhlci4gQnV0IHRoYXQgaGFzIGl0cyBvd24gaXNzdWVzLCBzbyBJ
IHdvbuKAmXQgZ28gdGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h
cmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw
MDdFN0UiPkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVl
cjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4N
Cjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiM3RDdEN0QiPjogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIx
OTQiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzQ0ICgwKTEyNDUgMjQyMTk0PC9hPg0KICZuYnNwO3wg
Jm5ic3A7PGI+RTogPC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z
LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxi
cj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0K
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVt
cyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0
IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8v
d3d3LmJhZXN5c3RlbXMuY29tL2FpIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y
OiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxi
cj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmss
IEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv
Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBWaWN0b3JpYQ0KIE1l
cmNpZWNhIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZtZXJjaWVjYTBAZ21haWwuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+dm1lcmNpZWNhMEBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+
IDI1IEFwcmlsIDIwMTYgMTQ6MTU8YnI+DQo8Yj5Ubzo8L2I+IEppYXppIFlJPGJyPg0KPGI+Q2M6
PC9iPiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgQ2hyaXN0b3BoZXIgRGVhcmxvdmU7IE1v
YmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl
OiBbbWFuZXRdIE1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBtZXNzYWdlIG11dGFiaWxpdHkgKHdhcyBS
RTogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRp
Y2tldCBJdGVtcyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEu
MHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0K
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50ZXI7
YmFja2dyb3VuZDp3aGl0ZSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz
MzM5NzIiPioqKiBXQVJOSU5HICoqKjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7
YmFja2dyb3VuZDp3aGl0ZSI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNh
dGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9z
cGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+
DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xp
Y2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9l
bT48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0K
PC9lbT48L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1h
aWxzIHlvdSByZWNlaXZlLA0KIGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFl
c3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUy
MEZsYWdzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0KaGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBo
cmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0
eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFp
bHMucGRmIiB0YXJnZXQ9Il9ibGFuayI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwv
c3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t
OjEyLjBwdCI+SGkgSmlhemksPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgQXByIDI1LCAyMDE2IGF0IDE6MDQgUE0sIEppYXppIFlJ
ICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBqaWF6aXlpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmll
dGZAamlheml5aS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPkhpLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5PbiBNb24sIEFwciAyNSwgMjAxNiBhdCAxMToyMCBBTSwgRGVhcmxvdmUs
IENocmlzdG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVz
eXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t
PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldp
dGggcmVnYXJkIHRvIHlvdXIgdmFsaWRpdHkgdGltZSBwb2ludCwgd2UgaGVyZSBoYXZlIGEgdHJh
ZGVvZmYuIElmIHlvdSBhbGxvdyB0aGF0IGZlYXR1cmUsIGl0IHNpZ25pZmljYW50bHkNCiBpbXBh
Y3RzIG9uIHRoZSBhcHByb2FjaCB0aGF0IHdhcyBjb21pbmcgdG9nZXRoZXIgb24gYXMgYmVzdCB5
b3UgY2FuIGVuZCB0byBlbmQgZW5jcnlwdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyB0aGUgcXVlc3Rp
b24gaXMsIGlzIHRoaXMgYSBmZWF0dXJlIHRoYXTigJlzIHJlYWxseSB3YW50ZWQ/IFVuZm9ydHVu
YXRlbHkgSSB0aGluayB3ZSBrbm93IHRoYXQgdGhlDQogYW5zd2VyIHRvIHRoYXQgaXMsIHdlIGRv
buKAmXQga25vdyBiZWNhdXNlIHdlIGRvbuKAmXQgaGF2ZSBhbnkgZXhwZXJpZW5jZS4gTXkgdmll
dyB3b3VsZCBiZSB0aGF0IGluIHRoZSB0cmFkZW9mZiBvZiBhbiB1bnRlc3RlZCBmZWF0dXJlICh1
bmxlc3MgSeKAmW0gd3JvbmcgYWJvdXQgdGhhdCkgYW5kIHRoZSBzZWN1cml0eSBjb21wbGljYXRp
b24sIHNlY3VyaXR5IHdpbnMgYW5kIGRyb3AgdGhlIGZlYXR1cmUuIElmIHRoZXJlIGlzIHNvbWUg
cmVhbCByZXF1aXJlbWVudCwNCiB0aGVuIHRoZXJl4oCZcyBhIGRpc2N1c3Npb24uIChRdWVzdGlv
bnMgbGlrZSBob3cgb2Z0ZW4gdGhlIGludGVybWVkaWF0ZSByb3V0ZXJzIGFjdHVhbGx5IGhhdmUg
YW55IGtub3dsZWRnZSAtIHR5cGljYWxseSBsaW5rcyBicmVhayBmb3IgdW5leHBlY3RlZCByYXRo
ZXIgdGhhbiBleHBlY3RlZCByZWFzb25zLiBBbmRhbiBpbnRlcm1lZGlhdGUgcm91dGVyIGNvdWxk
IHBvc3NpYmx5IHVzZSBhIHZhbGlkaXR5IHRpbWUgdG8gaW5mbHVlbmNlIGl0cyBiZWhhdmlvdXIu
KQ0KIE5vdGUgdGhhdCBkcm9wcGluZyB0aGUgYWJpbGl0eSBvZiBpbnRlcm1lZGlhdGUgcm91dGVy
cyB0byBtb2RpZnkvc2V0IHN0aWxsIGFsbG93cyB2YWxpZGl0eSB0aW1lcyBwZXIgcm91dGUgdG8g
YmUgc2V0IGF0IGVuZHBvaW50cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYWdyZWUgd2l0aCBDaHJpcycg
Y29uY2Vybi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+VGhlIFZhbGlkaXR5VGltZSBpcyBvcHRpb25hbCwgd2hpY2ggbWFrZXMgdGhlIGludGVn
cml0eSBwcm90ZWN0aW9uIGhhcmQuIEZ1cnRoZXJtb3JlLCBpdCBnaXZlcyBhIHBvdGVudGlhbCBh
dHRhY2sgdmVjdG9yOiBhcyBhbGwgdGhlIHJvdXRlcnMgaW4gYSBwYXRoIHdpbGwgdGFrZSB0aGUg
c2hvcnRlc3QgdmFsaWRpdHlUaW1lLA0KIGEgY29tcHJvbWlzZWQgcm91dGVyIGNhbiBzZXQgdGhl
IHRoZSB2YWxpZGl0eVRpbWUgdG8gYSB2ZXJ5IHNob3J0IHZhbHVlLCB3aGljaCB3aWxsIG1ha2Ug
dGhlIHJvdXRlIGluc3RhbGxlZCBhbG9uZyB0aGUgcGF0aCBiZWNhbWUgaW52YWxpZCAodmVyeSBz
b29uKS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPk9uIHRoZSBvdGhlciBoYW5kLCBJJ20gbm90IHN1cmUgdGhpcyBvcHRpb24g
d2lsbCBnaXZlIHVzIG11Y2ggaGVscC4gQ2hyaXMgbWVudGlvbmVkIG11Y2gga25vd2xlZGdlIGlu
dGVybWVkaWF0ZSByb3V0ZXIgd291bGQgaGF2ZSB0byBkZWNpZGUgdGhpcyB2YWx1ZSAoYW5kIGhv
dyBtdWNoIHNlbnNlIHRoZSB2YWx1ZQ0KIHdvdWxkIG1ha2UpLiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Bbm90aGVyIGlzc3VlIGlz
LCBhIHJvdXRlIHRvIGEgZGVzdGluYXRpb24gbWlnaHQgYmUgdXBkYXRlZCBieSBkaWZmZXJlbnQg
c291cmNlcy4gRm9yIGV4YW1wbGUsIGluIHRoZSBuZXR3b3JrIGJlbG93OjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BLS0tLUItLS0tLUM8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5BIGZpcnN0IGVzdGFibGlzaCBhIHJvdXRlIHRvIEIgd2l0aCBsb25nIHZhbGlkaXR5IHRpbWUu
IFRoZW4gQSBpbml0aWF0ZXMgYSByb3V0ZSBkaXNjb3ZlcnkgdG8gQy4gQyB0ZW5kcyB0byBzZXQg
YSBzaG9ydCB2YWxpZGl0eSB0aW1lLCB3aGljaCB3aWxsIG1ha2UgdGhlIHJvdXRlIGJldHdlZW4g
QiBhbmQgQQ0KIGV4cGlyZSBlYXJsaWVyIHRoYW4gZXhwZWN0ZWQuJm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklzIHRoaXMgYSBwcm9i
bGVtPyBNYXliZSB5ZXMsIG1heWJlIG5vIC0tIEknbSBub3Qgc3VyZSBpdCdzIGNvbnNpZGVyZWQg
b3Igbm90LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPk5vdCBzdXJlIEkgZm9sbG93IGhl
cmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkN1cnJl
bnRseSwgdGhlIHZhbGlkaXR5IHRpbWUgb2YgdGhlIHJvdXRlIGJldHdlZW4gQSBhbmQgQiB3b3Vs
ZCBub3QgYWZmZWN0ZWQgYnkgYSBzaG9ydCB2YWxpZGl0eSB0aW1lIG9mIGEgcm91dGUgYmV0d2Vl
biBBIGFuZCBDLiBWYWxpZGl0eSB0aW1lcyBhcmUgcGVyLXJvdXRlLCBhbmQgdGhlIHJvdXRlIEEt
QiBhbmQgdGhlDQogcm91dGUgQS1DIGFyZSBzZXBhcmF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgd2Ugc3dpdGNoZWQgdG8gYSB2YWxp
ZGl0eSB0aW1lIHBlciBuZWlnaGJvciAoc28gdGhhdCB3ZSBjYW4ga2VlcCB2YWxpZGl0eSB0aW1l
IHNlcGFyYXRlIGZyb20gcm91dGUgYWR2ZXJ0aXNlbWVudHMpIGFzIEkgbWVudGlvbmVkIGluIHRo
ZSBlbWFpbCBiZWxvdywgdGhlbiB0aGUgdmFsaWRpdHkgb2YgYSByb3V0ZQ0KIGJldHdlZW4gQSBh
bmQgQyB3b3VsZCBiZSBhZmZlY3RlZCBpZiB0aGVyZSB3YXMgYSBzaG9ydCB2YWxpZGl0eSB0aW1l
IGJldHdlZW4gQSBhbmQgQi4gQnV0LCBpZiBCIHdpbGwgb25seSByb3V0ZSBmb3IgYSBjZXJ0YWlu
IGFtb3VudCBvZiB0aW1lLCB0aGVuIHRoZSByb3V0ZSBiZXR3ZWVuIEEgYW5kIEMgd2lsbCBvZiBj
b3Vyc2UgYmUgYWZmZWN0ZWQuIElzIGl0IGJlc3QgdG8ga25vdyBpbiBhZHZhbmNlIHRoYXQgdGhl
cmUncyBhIHRpbWUgbGltaXQsDQogb3IganVzdCBkZWFsIHdpdGggUkVSUnMgd2hlbiB0aGV5IGhh
cHBlbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt
IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBj
bTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaXRoIHJlZ2FyZCB0
byB0aGUgYWNrbm93bGVkZ2VtZW50cywgdGhlIHByb2JsZW0gKHdpdGggcmVnYXJkIHRvIHNlY3Vy
aXR5KSBjb21lcyBmcm9tIHRyeWluZyB0byBkbw0KIHR3byBqb2JzIHdpdGggdGhlIHNhbWUgbWVz
c2FnZSAtIGVuZCB0byBlbmQgcm91dGUgYWR2ZXJ0aXNlbWVudCBhbmQgaG9wIGJ5IGhvcCBhY2tu
b3dsZWRnZW1lbnQuIEkgdW5kZXJzdGFuZCB0aGUgcmVhc29ucyAtIHNhdmluZyBieXRlcyBhbmQg
bWVzc2FnZSB0eXBlcy4gKEkgd291bGQgaGF2ZSB0byBzdHVkeSB0aGUgcHJvdG9jb2wgcmVhbGx5
IGhhcmQgdG8gaWRlbnRpZnkgaWYgYW55IG1lc3NhZ2UgdHlwZXMgY2FuIGJlIGZvbGRlZCB0b2dl
dGhlcg0KIGFuZCByZWNvZ25pc2VkIGJ5IGNvbnRlbnQgcmF0aGVyIHRoYW4gdHlwZSBlZmZpY2ll
bnRseS4gVGhpcyBJIGRvIG5vdCBleHBlY3QgdG8gZG8uKSBBZ2FpbiBhIHRyYWRlb2ZmLiBUaGlz
IG9uZSBpcyBpbiBkaXNjdXNzaW9uIHNwYWNlLCB0aG91Z2ggdGhhdCBuZWVkcyBwZW9wbGUgd2hv
IHVuZGVyc3RhbmQgYm90aCBzaWRlcyBvZiB0aGUgaXNzdWUsIGluY2x1ZGluZyB0aGUgZGV0YWls
cyBvZiB0aGUgYmlkaXJlY3Rpb25hbGl0eSBtZWNoYW5pc20uDQogT2YgY291cnNlLCBhcyBoYXMg
YmVlbiBzYWlkLCB3ZSBuZWVkIG9uZSBvZiB0aG9zZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPkkgaGF2ZW4ndCBmaW5pc2hlZCBteSByZXZpZXcgb2YgdGhlIGxhdGVzdCBkcmFmdCwg
YW5kIEkgZG9uJ3QgZ2V0IHRoZSBuZWNlc3NpdHkgb2YgQWNrUmVxIGFuZCB0aGUgY29ycmVzcG9u
ZGluZyBtdWx0aWNhc3QgUlJFUCB5ZXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHBvc3NpYmxlLCB0aGlzICZxdW90O29wdGlv
bmFsJnF1b3Q7IGZpZWxkIHNob3VsZCBiZSBhdm9pZGVkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn
aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KVG8gZ2l2ZSBhbiBvdmVydmlldyBvZiBBY2tSZXEgYW5k
IFJSRVA6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlNp
bmNlIEFPRFZ2MiByZXF1aXJlcyBiaWRpcmVjdGlvbmFsIGxpbmtzLCB0aGlzIGlzIHRoZSB3YXkg
dG8gZGV0ZXJtaW5lIGlmIGEgbGluayBpcyBiaWRpcmVjdGlvbmFsLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BLS0tLUItLS0tQzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQoxKSBB
IHNlbmRzIFJSRVEsIEIgZm9yd2FyZHMgaXQsIEMgcmVjZWl2ZXMgdGhlIFJSRVEuIEIgYW5kIEMg
Ym90aCBpbnN0YWxsIGEgcm91dGUgdG8gT3JpZ0FkZHIgYnV0IHRoZXkgZG9udCB5ZXQga25vdyBp
ZiBpdCdzIHZhbGlkIGJlY2F1c2UgdGhleSBkb250IGtub3cgaWYgdGhlIGxpbmsgdG8gdGhlaXIg
bmV4dCBob3AgaXMgYXZhaWxhYmxlIGluIHRoZSByZXZlcnNlIGRpcmVjdGlvbi48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MikgQyBjcmVhdGVz
IHRoZSBSUkVQLiBTaW5jZSBpdCBkb2VzbnQga25vdyBpZiB0aGUgbGluayB0byBCIGlzIGJpZGly
ZWN0aW9uYWwsIGl0IGluY2x1ZGVzIHRoZSBBY2tSZXEgKGFuIGFkZHJlc3MgdG8gaW5kaWNhdGUg
dGhhdCBpdCBleHBlY3RzIHRvIHJlY2VpdmUgYSBSUkVQX0FjayBmcm9tIEIpLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4zKSBCIHJlY2VpdmVz
IHRoZSBSUkVQLCBpbnN0YWxscyBhIHJvdXRlIHRvIFRhcmdBZGRyIGFuZCBtYXJrcyBpdCBhcyB2
YWxpZCwgc2luY2UgaXQga25vd3MgdGhlIGxpbmsgdG8gQyBpcyBiaWRpcmVjdGlvbmFsLCBiZWNh
dXNlIHRoZSBSUkVRIHdlbnQgaW4gb25lIGRpcmVjdGlvbiBhbmQgdGhlIFJSRVAgY2FtZQ0KIGlu
IHRoZSBvdGhlci4gQiBhbHNvIHNlbmRzIHRoZSBSUkVQX0FjayB0byBDIGFuZCBmb3J3YXJkcyB0
aGUgUlJFUCB0byBBIChhbmQgbWlnaHQgY2hhbmdlIHRoZSBtZXNzYWdlIHRvIGluZGljYXRlIGl0
cyBvd24gQWNrUmVxIC0gaWUgdGhhdCBpdCByZXF1aXJlcyBhbiBhY2sgZnJvbSBBKS48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+NCkgQyByZWNl
aXZlcyB0aGUgUlJFUF9BY2sgZnJvbSBCLCBhbmQgdGhlcmVmb3JlIGtub3dzIHRoYXQgQiByZWNl
aXZlZCB0aGUgUlJFUCwgdGhlcmVmb3JlIHRoZSBsaW5rIGlzIGJpZGlyZWN0aW9uYWwuIEMgY2Fu
IHRoZW4gbWFyayBpdHMgcm91dGUgdG8gT3JpZ0FkZHIgYXMgdmFsaWQuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjUpIFNpbWlsYXJseSwgQSBy
ZWNlaXZlcyB0aGUgUlJFUCwgaW5zdGFsbHMgdGhlIHJvdXRlIHRvIFRhcmdBZGRyIGFuZCBzZW5k
cyBhbiBSUkVQX0FjayB0byBCLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj42KSBCIHJlY2VpdmVzIHRoZSBSUkVQX0FjayBhbmQgbWFya3MgaXRz
IHJvdXRlIHRvIE9yaWdBZGRyIGFzIHZhbGlkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+QWx0ZXJuYXRpdmVseSwgaW4gc3RlcCAyLCBpZiBDIGtu
b3dzIHRoZSBsaW5rIHRvIEIgaXMgYmlkaXJlY3Rpb25hbCAocGVyaGFwcyBmcm9tIHNvbWUgZWFy
bGllciByb3V0ZSBkaXNjb3ZlcnkpLCBpdCBkb2VzbnQgbmVlZCB0byBwdXQgdGhlIEFja1JlcSBp
biB0aGUgUlJFUC4gVGhlbiBpbiBzdGVwIDMsIHNpbmNlIEINCiBkb2VzbnQga25vdyBpZiB0aGUg
bGluayB0byBBIGlzIGJpZGlyZWN0aW9uYWwsIGl0IGNoYW5nZXMgdGhlIG1lc3NhZ2UgdG8gYWRk
IHRoZSBBY2tSZXEgYWRkcmVzcywgaW4gb3JkZXIgdG8gZ2V0IGFuIFJSRVBfQWNrIGZyb20gQS48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SWYgd2Ugd2Fu
dCB0byBhdm9pZCBjaGFuZ2luZyB0aGUgbWVzc2FnZSwgd2UnbGwgbmVlZCB0byBsb29rIGF0IGZv
cndhcmRpbmcgdGhlIFJSRVAgYXMtaXMsIGFuZCBjcmVhdGluZyBhIHNlY29uZCBtZXNzYWdlIHRv
IHNvbGljaXQgYW4gUlJFUF9BY2ssIGluIG9yZGVyIHRvIHZlcmlmeSB0aGF0IHRoZSBsaW5rIGlz
IGJpZGlyZWN0aW9uYWwNCiBiZWZvcmUgbWFya2luZyB0aGUgcm91dGUgdG8gT3JpZ0FkZHIgYXMg
dmFsaWQuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5LaW5kIHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPlZpY3RvcmlhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp
bi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0
O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+cmVnYXJkczxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Smlhemk8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7
bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzAwN0U3RSI+LS0NCjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv
bToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hy
aXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFF
IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwv
Yj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAw
MDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3
RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+
OiAmbmJzcDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5NCIgdGFyZ2V0
PSJfYmxhbmsiPiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8L2E+DQogJm5ic3A7fCAmbmJzcDs8Yj5F
OiA8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+PGJyPg0KPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQg
SW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBD
aGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lz
dGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5MiI+
d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4
QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0
ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz
QThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3Jk
LCBTdXJyZXksIEdVMiA3WVA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFZpY3RvcmlhDQogTWVyY2llY2EgW21h
aWx0bzo8YSBocmVmPSJtYWlsdG86dm1lcmNpZWNhMEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r
Ij52bWVyY2llY2EwQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjMgQXByaWwg
MjAxNiAxMDo1NTxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQo8Yj5D
Yzo8L2I+IDxhIGhyZWY9Im1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3JnIiB0YXJnZXQ9Il9i
bGFuayI+aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzwvYT47IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAo
VUspOyBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdDwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj5TdWJq
ZWN0OjwvYj4gUmU6IFttYW5ldF0gTWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2UgbXV0YWJp
bGl0eSAod2FzIFJFOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBs
ZSBvZiBiaWcgdGlja2V0IEl0ZW1zKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0
IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0
LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
YWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8
L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp
bi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGk+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3Jp
Z2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0
ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPGJyPg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdo
ZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRz
IG9yIHJlcGx5Ljxicj4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPjwvaT48Yj48
aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwv
aT48L2I+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5
b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMNCiB5b3UgcmVjZWl2ZSwgY2xpY2sgPGEgaHJl
Zj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkv
c3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIiB0YXJnZXQ9Il9ibGFuayI+DQpo
ZXJlPC9hPi48YnI+DQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNl
IGZvbGxvdyA8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dl
d29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3Bp
Y2lvdXMlMjBFbWFpbHMucGRmIiB0YXJnZXQ9Il9ibGFuayI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwv
c3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+SGkgQ2hyaXMsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+VGhlc2UgaGF2ZSBib3RoIGJlZW4gaW4gdGhlIGRyYWZ0IGluIHNv
bWUgZm9ybSBzaW5jZSBiZWZvcmUgSSBnb3QgaW52b2x2ZWQuLi4gYnV0IEknbGwgZG8gbXkgYmVz
dCB0byBleHBsYWluLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPi0gRm9yIFZhbGlkaXR5IFRpbWUsIGl0cyBhIHdheSB0byBhZHZlcnRpc2UgdGhhdCB5
b3Ugd291bGQgb25seSBzdXBwb3J0IHRoZSByb3V0ZSBjb250YWluZWQgaW4gdGhlIG1lc3NhZ2Ug
Zm9yIGEgY2VydGFpbiBwZXJpb2Qgb2YgdGltZS4gVGhlIG9yaWdpbmF0b3IgbWlnaHQgdXNlIHRo
aXMsIGJ1dCB0aGUgZHJhZnQNCiB3YXMgd3JpdHRlbiB0byBhbGxvdyBhbnkgaW50ZXJtZWRpYXRl
IG5vZGUgdG8gYmUgYWJsZSB0byBhZGQgaXQgb3IgdXBkYXRlIGl0IHRvby4gVGhlIHJvdXRlIGNy
ZWF0ZWQgaW4gdGhlIExvY2FsIFJvdXRlIFNldCBoYXMgYW4gZXhwaXJhdGlvbiB0aW1lIGFzc29j
aWF0ZWQgd2l0aCBpdCwgYmFzZWQgb24gdGhlIHJlY2VpdmVkIHZhbGlkaXR5IHRpbWUuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gRm9yIHRo
ZSBBY2tSZXEgYWRkcmVzcywgaXRzIHNvIHRoYXQgeW91IGNhbiBhZGQgaW50byBhIFJSRVAgYSBy
ZXF1ZXN0IGZvciBhbiBhY2tub3dsZWRnZW1lbnQsIHNvIHRoYXQgeW91IGRvbid0IGhhdmUgdG8g
aGF2ZSBhIGRpZmZlcmVudCBtZXNzYWdlIHR5cGUgYWx0b2dldGhlciBmb3Igd29ya2luZyBvdXQN
CiB3aGV0aGVyIGxpbmtzIHRvIG5laWdoYm9ycyBhcmUgYmlkaXJlY3Rpb25hbCwgYW5kIGFsc28s
IHNpbmNlIHlvdSBvbmx5IGNhcmUgYWJvdXQgYmlkaXJlY3Rpb25hbGl0eSBvbiByb3V0ZXMgdGhh
dCBhcmUgYmVpbmcgc2V0IHVwLCB5b3UgZG9udCBuZWVkIHRvIGNvbnN0YW50bHkgbW9uaXRvciBh
bGwgbmVpZ2hib3JzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPkluIG9yZGVyIHRvIGF2b2lkIHRoZSBwb3RlbnRpYWwgQWNrUmVx
LXJlbGF0ZWQgY2hhbmdlcyB0byBlYWNoIG1lc3NhZ2UsIG1heWJlIHdlIGRvIG5lZWQgdG8gaW50
cm9kdWNlIGEgZGlmZmVyZW50IG1lc3NhZ2Ugc3BlY2lmaWNhbGx5IGZvciB0aGlzLiBXZSBjb3Vs
ZCBtYXliZSB1c2UgUlJFUF9BY2sgdG8gYm90aA0KIHJlcXVlc3QgYW5kIGFja25vd2xlZGdlPyBJ
dCBtZWFucyBhbiBleHRyYSBtZXNzYWdlIG9mIGNvbnRyb2wgdHJhZmZpYyB0aGF0IG5lZWRzIHRv
IGJlIHNlbnQsIG1heWJlIG9uZSBleHRyYSBtZXNzYWdlIHBlciBob3Agb24gdGhlIHBhdGggb2Yg
YSBSUkVQLCBidXQgaXQgY291bGQgc3RpbGwgYmUgbGltaXRlZCB0byBuZWlnaGJvcnMgd2hpY2gg
aGF2ZSBwYXJ0aWNpcGF0ZWQgaW4gdGhlIHJvdXRlIGRpc2NvdmVyeSByYXRoZXIgdGhhbiBtb25p
dG9yaW5nDQogYWxsIG5laWdoYm9ycyBhdCBhbGwgdGltZXMuJm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIG1lc3NhZ2Ug
Y291bGQgbWF5YmUgYWxzbyBpbmNsdWRlICZxdW90O0knbSBoYXBweSB0byByb3V0ZSBhbnl3aGVy
ZSBmb3IgYSBjZXJ0YWluIGFtb3VudCBvZiB0aW1lJnF1b3Q7LCBzb3J0IG9mIGxpa2Ugd2lsbGlu
Z25lc3MgaW4gT0xTUi9PTFNSdjIuIFNvIGluc3RlYWQgb2YgaGF2aW5nIGEgdmFsaWRpdHkgdGlt
ZSBwZXINCiByb3V0ZSwgaXRzIGEgdmFsaWRpdHkgdGltZSBwZXIgbmVpZ2hib3IuIFRoZW4sIGZv
ciBSUkVRIGFuZCBSUkVQLCBvbmx5IHRoZSBtZXRyaWMgdmFsdWUgd291bGQgY2hhbmdlIGluIHRy
YW5zaXQsIGFzIGRpc2N1c3NlZC4gSG93ZXZlciwgdGhhdCBsZWFkcyB0byBzb21lIGlzc3VlcyB3
aXRoIGRlY2lkaW5nIHdoYXQgYSByb3V0ZSdzIGV4cGlyYXRpb24gdGltZSBpcy4gWW91IG1pZ2h0
IGtub3cgaG93IGxvbmcgdGhlIG5leHQgaG9wIHJvdXRlciBpcw0KIHZhbGlkIGZvciwgYnV0IHdo
YXQgaWYgYSByb3V0ZXIgYmV5b25kIHRoYXQsIHdoaWNoIHdhcyBhbHNvIHBhcnQgb2YgdGhlIHJv
dXRlLCBoYWQgYSBsb3dlciB2YWxpZGl0eSB0aW1lPyBZb3UgY291bGRuJ3QgZGV0ZXJtaW5lIHRo
ZSByZWFsIHZhbGlkaXR5IHRpbWUuIERvIHdlIHJlbW92ZSB0aGUgcm91dGUgZXhwaXJhdGlvbiB0
aW1lIGFsdG9nZXRoZXIgdG8gYXZvaWQgdGhpcyBpc3N1ZT8gSW4gd2hpY2ggY2FzZSwgd2Ugd291
bGQgaGF2ZSB0bw0KIHJlbHkgb24gUkVSUiBtZXNzYWdlcyBiZWluZyBzZW50IGZvciByb3V0ZXMg
d2hpY2ggYmVjb21lIGludmFsaWQgd2hlbiB0aGUgbmVpZ2hib3IncyB2YWxpZGl0eSB0aW1lIGhh
cyBleHBpcmVkPyBTbyBuZWlnaGJvciB2YWxpZGl0eSB0aW1lIGV4cGlyYXRpb24gaXMgdHJlYXRl
ZCB0aGUgc2FtZSBhcyBhIGxpbmsgYnJlYWsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGF0IGRvIHlvdSB0aGluaz88bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPktpbmQgcmVn
YXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+VmljdG9yaWEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU2F0LCBBcHIgMjMsIDIwMTYgYXQg
MTowOSBBTSwgQ2hyaXN0b3BoZXIgRGVhcmxvdmUgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc0Bt
bmVtb3N5bmUuZGVtb24uY28udWsiIHRhcmdldD0iX2JsYW5rIj5jaHJpc0BtbmVtb3N5bmUuZGVt
b24uY28udWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5QcmV0dHkgbXVjaCBhbGwgb2YgdGhlIGRpc2N1c3Npb24gaGFz
IGJlZW4gYXNzdW1pbmcgb25seSBhIG1ldHJpYyB2YWx1ZSBjaGFuZ2UuIFdpdGggbXVsdGlwbGUg
dGhpbmdzIGNoYW5naW5nIG1hbnkgb2YgdGhlIGlkZWFzIGdvIG91dCBvZiB0aGUgd2luZG93LiBU
aGF0IHJlaW5mb3JjZXMgdGhlIHBvaW50IGFib3V0DQogbm90IG1ha2luZyBzcGVjaWZpY2F0aW9u
cyBub3cgdGhhdCBtaWdodCB0dXJuIG91dCB0byBiZSB3cm9uZyBmb3IgSUNWcy48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklnbm9yaW5n
IGhvdyB0aGlzIG1pc3VuZGVyc3RhbmRpbmcgaGFwcGVuZWQsIEknbGwgc3RhcnQgYnkgYXNraW5n
IHdoeS4gTWV0cmljIGNoYW5naW5nIEkgdW5kZXJzdGFuZC4gV2h5IHRoZSBvdGhlciB0d28/ICh0
aGVyZSdzIGEgcGFydGlhbCBleHBsYW5hdGlvbiBvZiBvbmUpLiBXaGF0IGFsdGVybmF0aXZlcw0K
IGhhdmUgcGVvcGxlIGltcGxlbWVudGVkIGluIGNvbXBhcmFibGUgcHJvdG9jb2xzPzxicj4NCjxi
cj4NCi0tICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0ibWFpbHRvOmNocmlzdG9waGVyLmRlYXJsb3Zl
QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdG9waGVyLmRlYXJsb3ZlQGdtYWlsLmNv
bTwvYT4gKGlQaG9uZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PGEgaHJlZj0ibWFpbHRvOmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51ayIg
dGFyZ2V0PSJfYmxhbmsiPmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51azwvYT4gKGhvbWUpPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy
Pg0KT24gMjMgQXByIDIwMTYsIGF0IDAwOjI2LCBWaWN0b3JpYSBNZXJjaWVjYSAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOnZtZXJjaWVjYTBAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dm1lcmNpZWNh
MEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkg
YWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Q29udGludWVkIGluIHRoaXMgdGhyZWFkIGJlY2F1c2UgdGhlIG90aGVyIG9uZSBzZWVt
cyB0byBiZSBtb3JlIGFib3V0IFRMViB0eXBlcyBhbmQgbWV0cmljIHR5cGUgbnVtYmVycywgd2hl
cmVhcyB0aGlzIGlzIGFib3V0IHJlZ2VuZXJhdGlvbi9mb3J3YXJkaW5nLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VG8gcmVjYXAsIGlu
IHRoZSBjdXJyZW50IGRyYWZ0LCB0aGVyZSBhcmUgMyB0aGluZ3MgdGhhdCBtaWdodCBjaGFuZ2Ug
YXQgZWFjaCBob3A6DQo8YnI+DQotIHRoZSBtZXRyaWMgdmFsdWUgKGhhcHBlbnMgaW4gUlJFUSBh
bmQgUlJFUCksIDxicj4NCi0gYWRkaW5nL2NoYW5naW5nIFZhbGlkaXR5IFRpbWUgdXNpbmcgdGhl
IFZhbGlkaXR5IFRpbWUgVExWIChjYW4gaGFwcGVuIGluIFJSRVEgYW5kIFJSRVApLA0KPGJyPg0K
LSBhZGRpbmcgYW4gYWRkcmVzcyAoYW5kIGNvcnJlc3BvbmRpbmcgdmFsdWUgaW4gdGhlIEFkZHJl
c3NUeXBlIFRMViB0byBpbmRpY2F0ZSBob3cgdG8gaW50ZXJwcmV0IHRoZSBhZGRyZXNzKSB0byBp
bmRpY2F0ZSB0aGUgYWRkcmVzcyBmcm9tIHdoaWNoIGFuIFJSRVBfQWNrIGlzIGV4cGVjdGVkLCB0
byBhY2NvbXBsaXNoIHRoZSBiaWRpcmVjdGlvbmFsaXR5IGNoZWNrIChjYW4gaGFwcGVuIGluIFJS
RVApLjxicj4NCjxicj4NCklmIHdlIGRlZmluZSZuYnNwO2EgY2VydGFpbiBwb3J0aW9uIG9mIHRo
ZSBtZXNzYWdlIGFzIGltbXV0YWJsZSBhbmQgaW5jbHVkZSB0aGUgSUNWIHRvIHZlcmlmeSB0aGF0
IHBhcnQsIGVuZCB0byBlbmQ6DQo8YnI+DQotIFRoZSBtZXRyaWMgdmFsdWUgd291bGQgYmUgZXhj
bHVkZWQgZnJvbSB0aGUgSUNWIHNpbmNlIGl0IG5lZWRzIGNoYW5naW5nIGF0IGVhY2ggaG9wLiZu
YnNwOzxicj4NCi0gV291bGQgYWRkaW5nIGEgVmFsaWRpdHkgVGltZSBUTFYgYXQgYW4gaW50ZXJt
ZWRpYXRlIGhvcCBiZSBhY2NlcHRhYmxlPyBUaGUgd2hvbGUgVExWIGNvdWxkIGJlIHJlbW92ZWQg
aW4gb3JkZXIgdG8gY2FsY3VsYXRlIHRoZSBJQ1Y/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+LSBXb3VsZCBhZGRpbmcgYW4gYWRkcmVzcyBjYXVzZSBpc3N1
ZXMgZm9yIHRoZSBJQ1YsIGJlY2F1c2UgaXQncyBpbiB0aGUgYWRkcmVzcyBibG9jaz8gQ291bGQg
dGhlIHJ1bGUgYmUgJnF1b3Q7aWYgaXQgY29udGFpbnMgYW4gQWNrUmVxIGFkZHJlc3MsIHJlbW92
ZSBpdCAoYW5kIHRoZSBjb3JyZXNwb25kaW5nIHZhbHVlDQogaW4gdGhlIEFkZHJlc3NUeXBlIFRM
ViksIGJlZm9yZSBjaGVja2luZyB0aGUgSUNWJnF1b3Q7LCBpcyB0aGF0IE9LPyBPciB3b3VsZCB3
ZSBuZWVkIHRvIGF2b2lkIHRvdWNoaW5nIHRoZSBJQ1YnZWQgcGFydCBvZiB0aGUgbWVzc2FnZSBh
bHRvZ2V0aGVyLCBtYXliZSBwdXQgdGhlIEFja1JlcSBhZGRyZXNzIGluIGEgc2VwYXJhdGUgQWRk
cmVzcyBCbG9jaywgd2l0aCBhbiBleHRyYSBBZGRyZXNzVHlwZSBUTFYgZm9sbG93aW5nIHRoYXQg
YWRkcmVzcyBibG9jaz8NCiBJcyB0aGVyZSBhIHdheSB0byBhY2NvbXBsaXNoIHRoaXM/PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbHNv
LCB0byBiZSB0aG9yb3VnaCwgZG8gd2UgbmVlZCB0byBjb25zaWRlciBSRVJSIG1lc3NhZ2VzIHdo
aWxlIHdlIGRpc2N1c3MgcmVnZW5lcmF0aW9uIHZzIGZvcndhcmRpbmc/Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gUkVSUiAoc2Vu
dCB3aGVuIGEgbGluayBicmVha3MpIGlzIGEgd2F5IG9mIHNheWluZyAmcXVvdDtJJ3ZlIGxvc3Qg
bXkgcm91dGUgc28gSSdtIHRlbGxpbmcgb3RoZXJzJnF1b3Q7IGFuZCAmcXVvdDt5b3Ugd2VyZSBt
eSBuZXh0IGhvcCwgc28mbmJzcDtub3cmbmJzcDtJJ3ZlIGFsc28gbG9zdCBteSByb3V0ZSwgSSds
bCB0ZWxsIG90aGVycyZxdW90OywgZXRjLg0KIEl0J3MgZ29pbmcgdG8gYmUgdGFpbG9yZWQgYXQg
ZWFjaCBzdGVwIHRvIGluY2x1ZGUgdGhlIHJlbGV2YW50IHJvdXRlcyB0aGF0IGdvdCBkZWxldGVk
LCBpdCdzIG5vdCBvbmUgbWVzc2FnZSBiZWluZyBzZW50IGVuZC10by1lbmQgbGlrZSBSUkVRIGFu
ZCBSUkVQIGFyZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+LSBIb3dldmVyLCBSRVJSIChzZW50IHdoZW4gYSBzb3VyY2Ugb2YgdHJh
ZmZpYyBpcyBzZW5kaW5nIGRhdGEgb24gYSByb3V0ZSB3aGljaCBjb21lcyB0aHJvdWdoIHlvdSwg
YW5kIHlvdSB3YW50IHRvIHRlbGwgdGhlIFBhY2tldCBTb3VyY2UncyByb3V0ZXIgdG8gZGVsZXRl
IHRoZSByb3V0ZSkgY291bGQgYmUNCiBzZWVuIGFzIGFuIGVuZC10by1lbmQgbWVzc2FnZSB3aGlj
aCBhbGwgaW50ZXJtZWRpYXRlIHJvdXRlcnMgbGVhcm4gZnJvbSwgc2ltaWxhciB0byBSUkVRIGFu
ZCBSUkVQLiBJdCByZXBvcnRzIG9uZSByb3V0ZSwgYW5kIGRvZXNuJ3QgbmVlZCBjaGFuZ2luZyBh
dCBpbnRlcm1lZGlhdGUgaG9wcywgc28gY291bGQgYmUgcHJvdGVjdGVkIHdpdGggSUNWLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIFdvdWxk
IGl0IGJlIE9LIHRvIG9ubHkgcmVxdWlyZSBhIG1lc3NhZ2UgSUNWIGlmIGEgUGt0U291cmNlIGFk
ZHJlc3Mgd2FzIGluY2x1ZGVkLCBpLmUuIHdoZW4gdGhlIG1lc3NhZ2UgbmVlZHMgdG8gZ28gdmlh
IGEgbnVtYmVyIG9mIGludGVybWVkaWF0ZSBob3BzIHRvIFBrdFNvdXJjZSdzIHJvdXRlcj8gQWxs
DQogb3RoZXIgUkVSUnMgYXJlIGludGVuZGVkIHRvIGJlIG9uZS1ob3AgbWVzc2FnZXMsIHdoaWNo
IG1heSBpbiB0dXJuIHByb21wdCBvdGhlciBvbmUtaG9wIG1lc3NhZ2VzLCBldGMuLi4sIGFuZCBh
IHBhY2tldCBJQ1YgbWlnaHQgYmUgbW9yZSBhcHByb3ByaWF0ZT88bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+S2luZCByZWdhcmRzLDxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlZpY3RvcmlhLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgTWFyIDE3LCAy
MDE2IGF0IDU6MjYgUE0sICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAdGhvbWFzY2xhdXNlbi5vcmc8L2E+Jmd0OyB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gMTcg
TWFyIDIwMTYsIGF0IDE4OjE3LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+
Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywgSSBtZWFudCBBT0RWdjIsIHRoYW5r
cyBmb3IgdGhlIGNhdGNoLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPlNvIGlzIHlvdXIgKFRob21hcykgcHJvcG9zZWQgYmFzZSBzcGVjaWZpY2F0aW9uIGEgaG9w
IGNvdW50IG9ubHkgbWV0cmljPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vLCB0
aGUgd291bGQgYmUgc2lsbHkgYXMgYmFzZSBzcGVjaWZpY2F0aW9uLCBnaXZlbiB0aGF0IGhvcCBj
b3VudCBtb3N0bHkgaXMgdXNlbGVzcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFzIGJhc2Ugc3BlY2lmaWNhdGlvbiBJIHdvdWxkIHNp
bXBseSBzYXkg4oCcSW5jbHVkZSBhIE1ldHJpYyBUeXBlIE1lc3NhZ2UgVExWIHdpdGggYSB2YWx1
ZSBmaWVsZCwgYW5kIGEgNzE4MiBNZXNzYWdlIFRMViAmYW1wOyBUaW1lc3RhbXDigJ0gYXMgd2Ug
ZG8gaW4gT0xTUnYyICh3aXRoIHRoZSBhcHByb3ByaWF0ZSB2ZXJiaWFnZQ0KIGFzIHRvIGdlbmVy
YXRpb24gYW5kIHByb2Nlc3NpbmcpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2l0aCB0aGUgbWVzc2FnZSBnZW5lcmF0ZWQg
YnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIFJSRVEvUlJFUCBhbmQgKm5vdCogZGVjb25zdHJ1Y3Rl
ZC9yZWNvbnN0cnVjdGVkL3Jlb3JkZXJlZCAoYXMgaXMgdGhlIHJpc2sgd2l0aCDigJxyZWdlbmVy
YXRpb24pIGFsbG93cyBrbm93aW5nIHRoYXQgaXQgd291bGQgYmUNCiAqb25seSogdGhhdCBtZXRy
aWMgZmllbGQgYmVpbmcgbW9kaWZpZWQgKG90aGVyIHRoYW4gaG9wIGNvdW50L2xpbWl0KSBmb3Ig
d2hlbiBldmVudHVhbGx5IHdyaXRpbmcgdXAgdGhlIGV4dGVuc2lvbi48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oQWN0dWFsbHkgZG9lc27igJl0
IHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gb25seSBkZWZpbmUgaG9wIGNvdW50LCBvciBoYXMg
dGhhdCBjaGFuZ2VkIGluIGxhdGVzdA0KIGRyYWZ0Pyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Tm8uIFRoYXQgaXMgb25lIG9mIHRoZSBpc3N1ZXMgSSByYWlzZSBpbiBteSBvcmlnaW5hbC4gRm9y
IHNvbWUgcmVhc29uLCBpdCBjaXRlcyBSRkM2NTUxLCB3aGljaCBpcyBhIFJPTEwgZG9jdW1lbnQg
YW5kIHdoaWNoIGhhcyBpbiBpdHMgYWJzdHJhY3QgdGhhdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cHJlPiZuYnNwOyZuYnNwOyBMb3ctUG93ZXIgYW5kIExvc3N5IE5ldHdv
cmtzIChMTE5zKSBoYXZlIHVuaXF1ZSBjaGFyYWN0ZXJpc3RpY3M8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDsmbmJzcDsgY29tcGFyZWQgd2l0aCB0cmFkaXRpb25hbCB3aXJlZCBhbmQgYWQg
aG9jIG5ldHdvcmtzIHRoYXQgcmVxdWlyZSB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDsmbmJzcDsgc3BlY2lmaWNhdGlvbiBvZiBuZXcgcm91dGluZyBtZXRyaWNzIGFuZCBjb25zdHJh
aW50cy4gPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5JLmUuIHRoaXMgZG9jdW1lbnQgY2l0ZXMgYSBtZXRyaWMgZG9jdW1lbnQgd2hpY2ggY2xlYXJs
eSBjbGFpbXMgdG8gYmUgaW5hcHBsaWNhYmxlIGluIGFkIGhvYyBuZXR3b3Jrcy4gSSBub3RlIHRo
YXQgdGhpcyBpcyBhbm90aGVyIHRoaW5nIEnigJl2ZSByYWlzZWQgZm9yIHllYXJzIHdpdGhvdXQg
c2VlaW5nIGl0DQogYXR0ZW1wdGVkIHJlc29sdmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRob21hczxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS08L3NwYW4+PC9iPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBh
bCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRv
cmllczxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
QkVCRUJFIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEy
NDUlMjAyNDIxOTQiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzQ0ICgwKTEyNDUgMjQyMTk0PC9hPg0K
ICZuYnNwO3wgJm5ic3A7PGI+RTombmJzcDs8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJs
b3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1
cnBsZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPjxicj4NCjwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVk
IEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywg
Q2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5
c3RlbXMuY29tL2FpIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTIi
Pnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+
DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNo
IFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5k
b3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY207Ym9yZGVyLWNvbG9yOi1tb3ot
dXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvciI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy
b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu
YnNwOzxhIGhyZWY9Im1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3JnIiB0YXJnZXQ9Il9ibGFu
ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzwvc3Bh
bj48L2E+Jm5ic3A7WzxhIGhyZWY9Im1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOmlldGZAdGhvbWFz
Y2xhdXNlbi5vcmc8L3NwYW4+PC9hPl0mbmJzcDs8YnI+DQo8Yj5TZW50OjwvYj4mbmJzcDsxNyBN
YXJjaCAyMDE2IDE3OjEwPGJyPg0KPGI+VG86PC9iPiZuYnNwO0RlYXJsb3ZlLCBDaHJpc3RvcGhl
ciAoVUspPGJyPg0KPGI+Q2M6PC9iPiZuYnNwO0xvdHRlIFN0ZWVuYnJpbms7IE1vYmlsZSBBZCBI
b2MgTmV0d29ya3MgbWFpbGluZyBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+Jm5ic3A7UmU6IFtt
YW5ldF0gTWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2UgbXV0YWJpbGl0eSAod2FzIFJFOiBk
cmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0
IEl0ZW1zKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBw
dCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4
dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50
ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPC9zcGFuPjwvYj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu
PSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy
LjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxpPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJv
bSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRu
ZXIgb3IgdGhlIGludGVybmV0Ljxicj4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBz
aG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48
YnI+DQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nJm5ic3A7PC9zcGFuPjwvaT48Yj48aT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L2I+
PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4mbmJzcDt0aGF0IHlv
dSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscw0KIHlvdSByZWNlaXZlLCBjbGljayZuYnNwOzxh
IGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3Vy
aXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiIgdGFyZ2V0PSJfYmxhbmsi
PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmhlcmU8L3NwYW4+PC9hPi48YnI+DQpJZiB5b3Ug
ZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyZuYnNwOzxhIGhyZWY9
Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nw
b3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5w
ZGYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50aGlzIHByb2Nl
c3M8L3NwYW4+PC9hPi48L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gMTcg
TWFyIDIwMTYsIGF0IDE4OjA0LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+
PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208
L3NwYW4+PC9hPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T0ssIHNvIHdlIGhhdmUgYSBtZXNzYWdl
IHRoYXQgbXV0YXRlcyBieTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tIE1vZGlmeWluZyBob3AgY291bnQvbGltaXQuPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
LSBNb2RpZnlpbmcgYSBtZXRyaWMgdmFsdWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW55dGhpbmcgZWxzZT88L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj5BcyBtdXRhdGluZyAob3RoZXIgdGhhbiBob3AgY291bnQvbGltaXQpIG1lc3NhZ2Vz
IGFyZW7igJl0IGNvdmVyZWQgYnkgNTQ0NCBvciBhbnkgZGVyaXZhdGl2ZSBkb2N1bWVudA0KIChi
dXQgb25seSByZWNvbW1lbmRlZCBhZ2FpbnN0LCBub3QgYmFubmVkKSB0aGF0IHlvdSBtYXkgbmVl
ZCB0byBtYWtlIHRoZSBtZXNzYWdlIG90aGVyd2lzZSBpbW11dGFibGUgKG5vIGRlY29uc3RydWN0
aW9uIGFuZCByZWJ1aWxkaW5nLCBvdGhlciB0aGFuIGd1YXJhbnRlZWQgdW5jaGFuZ2luZykgdGhh
dCB3b3VsZCBoYXZlIHRvIGJlIHNwZWNpZmllZCBieSBBT0RWdjIuIChFYXN5IHRvIHNheSwgYnV0
IG5lZWRzIHNheWluZy4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPldpdGggeW91IHNvIGZhci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlbiB0aGF0IGluZm9ybWF0aW9uIGlz
IG5vdCBpbiBhIGd1YXJhbnRlZWQgZml4ZWQgbG9jYXRpb24gZ2l2ZW4gYnkgYSBzaW1wbGUgb2Zm
c2V0LiBTbyBhbnkgc2lnbmF0dXJlDQogYWxnb3JpdGhtIHRoYXQgZmluZHMgaXQgYW5kIGlnbm9y
ZXMgaXQgb3IgYWdncmVnYXRlcyBvbiBpdCBpcyBzcGVjaWZpYyB0byBPTFNSdjIuPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj5TdXJlbHkgeW91IG1lYW4gQU9EVnYyPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIHN0YW5k
YXJkIDcxODIgSUNWcyBkb27igJl0IGRvIHRoZSBqb2IsIHlvdSB3b3VsZCBuZWVkIGFuIEFPRFZ2
MiBzcGVjaWFsaXNlZCB2YXJpYW50LiBXaGljaCBpcyB0aGUNCiBzb3J0IG9mIHRoaW5nIHRoYXQg
dGhlIG1lc3NhZ2Ugc3BlY2lmaWMgVExWIHNwYWNlIGlzIHRoZXJlIGZvciwgSeKAmWQgYmUgc3Ry
b25nbHkgYWdhaW5zdCBhIOKAnGJ1dCBpZ25vcmUgdGhlIHZhbHVlIG9mIHRoaXMgc3BlY2lmaWMg
VExWIHNob3VsZCBpdCBvY2N1cuKAnSBiZWluZyBpbiB0aGUgZ2VuZXJhbCBzcGFjZS4gSG93ZXZl
ciBpdCBjYW4gZWFzaWx5IGJlIGRlZmluZWQgYnkgcmVmZXJlbmNlIHRvIDcxODIgKOKAnHRoaXMg
VExWIGlzIGxpa2UgdGhhdA0KIFRMViwgZXhjZXB0IGlmIGFuIFggVExWIGlzIHByZXNlbnQsIHNl
dCBpdHMgdmFsdWUgZmllbGQgdG8gemVyb+KAnSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWVzc3ksIGJ1
dCBjb3VsZCB3b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm90IHRoYXQgbWVz
c3ksIGFjdHVhbGx5LCBhbHRob3VnaCBjbGVhcmx5IG5vdCBhcyBuaWNlIGFzIOKAnGZpeGVkIG9m
ZnNldOKAnS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYXQgc2FpZCwgSSBhbSBh
cmd1aW5nIGZvciB0aGUgYmFzZSBzcGVjIGJlaW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A74oCcbWFrZSB0aGUgbWVzc2FnZSBvdGhlcndpc2UgaW1tdXRh
YmxlIChubyBkZWNvbnN0cnVjdGlvbiBhbmQgcmVidWlsZGluZywgb3RoZXImbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhhbiBndWFyYW50ZWVkIHVuY2hhbmdpbmcp4oCd
IHdoaWNoIGlzIGFmZm9yZGVkIGJ5IGZvcndhcmRpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtSRkM3MTgyIFRp
bWVzdGFtcHMgYW5kIElDVnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UkZDNzE4MyBzdHlsZSB0ZXh0IGJyaW5n
aW5nIGl0IGFsbCB0b2dldGhlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSDi
gJxhZ2dyZWdhdGVkIHNpZ25hdHVyZXMgYXJvdW5kIG11dGFibGUgZmllbGTigJ0gd291bGQgdmVy
eSBiZSBhbiBleHBlcmltZW50YWwgZXh0ZW5zaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+V2hhdCBJIG9iamVjdCB0byBpcywgaWYgdGhlIGJhc2Ugc3BlYyBzcGVjaWZpY2FsbHkg
cmVuZGVycyBzdWNoIGV4dGVuc2lvbnMgaW1wb3NzaWJsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw
dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv
dHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+
LS08L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVyIERlYXJsb3ZlPGJy
Pg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50
ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7PGEgaHJlZj0idGVs
OiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzQ0ICgw
KTEyNDUgMjQyMTk0PC9hPg0KICZuYnNwO3wgJm5ic3A7PGI+RTombmJzcDs8L2I+PGEgaHJlZj0i
bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw
YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3Nw
YW4+PC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3
RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5C
QUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBh
cmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVm
PSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVk
IEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdh
bGVzIE5vOiAwMTMzNzQ1MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu
LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5S
ZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5
LCBHVTIgN1lQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEu
MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY207Ym9yZGVyLWNvbG9yOi1tb3otdXNlLXRleHQt
Y29sb3IgLW1vei11c2UtdGV4dC1jb2xvciI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t
Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz
cDtMb3R0ZQ0KIFN0ZWVuYnJpbmsgWzxhIGhyZWY9Im1haWx0bzpsb3R0ZS5zdGVlbmJyaW5rQGZ1
LWJlcmxpbi5kZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1h
aWx0bzpsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZTwvc3Bhbj48L2E+XSZuYnNwOzxicj4N
CjxiPlNlbnQ6PC9iPiZuYnNwOzE3IE1hcmNoIDIwMTYgMTY6NDg8YnI+DQo8Yj5Ubzo8L2I+Jm5i
c3A7RGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk8YnI+DQo8Yj5DYzo8L2I+Jm5ic3A7PGEgaHJl
Zj0ibWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz
dHlsZT0iY29sb3I6cHVycGxlIj5pZXRmQHRob21hc2NsYXVzZW4ub3JnPC9zcGFuPjwvYT47IE1v
YmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+Jm5i
c3A7UmU6IFttYW5ldF0gTWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2UgbXV0YWJpbGl0eSAo
d2FzIFJFOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBi
aWcgdGlja2V0IEl0ZW1zKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xp
ZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5k
OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyO2Jh
Y2tncm91bmQ6d2hpdGUiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMz
OTcyIj4qKiogV0FSTklORyAqKio8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2Jh
Y2tncm91bmQ6d2hpdGUiPg0KPGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMz
OTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlv
biwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPGJyPg0K
Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3Ms
IG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljxicj4NCkZvciBpbmZvcm1hdGlvbiByZWdh
cmRpbmcmbmJzcDs8L3NwYW4+PC9pPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvYj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMzMzM5NzIiPiZuYnNwO3RoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1h
aWxzDQogeW91IHJlY2VpdmUsIGNsaWNrJm5ic3A7PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVu
dC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMv
UmVkJTIwRmxhZ3MucGRmIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs
ZSI+aGVyZTwvc3Bhbj48L2E+Ljxicj4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNp
b3VzLCBwbGVhc2UgZm9sbG93Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVz
eXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGlu
ZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu
IHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRoaXMgcHJvY2Vzczwvc3Bhbj48L2E+Ljwvc3Bhbj48L2k+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+QW0gMTcuMDMuMjAxNiB1bSAxNzo0NCBzY2hyaWViIERlYXJsb3Zl
LCBDaHJpc3RvcGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFl
c3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5j
aHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvc3Bhbj48L2E+Jmd0Ozo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R29vZCBwb2ludCBhYm91dCB3aGV0aGVyIHlvdSBq
dXN0IHBhc3Mgb24gb25lIGNvc3Qgb3IgYSBzZXQgb2YgY29zdHMuIEFzIEkgc2FpZCwgbm90IGxv
b2tlZCBhdCBkZXRhaWxzDQogLSBJIHdpbGwsIHdoZW4gdGltZSBwZXJtaXRzLiBPbmUgY29zdCBp
cyBtdWNoIGVhc2llciwgYW5kIHllcywgaXQgcmVkdWNlcyB0aGUgZml4ZWQgc2l6ZSBhZ2dyZWdh
dGVkIHNpZ25hdHVyZXMgcHJvYmxlbSB0byDigJxqdXN04oCdIG9uZSBvZiBjb21wdXRhdGlvbmFs
IGxvYWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3IgdGhlIHJlY29yZCwg
VGhvbWFz4oCZIHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdDsgdGhlIGNvc3QgaXMgb25lIGFnZ3Jl
Z2F0ZWQgdmFsdWUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj5CZXN0IHJlZ2FyZHMsJm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPkxvdHRlIFN0ZWVucmJpbms8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMDA3RTdFIj4tLTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w
cHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3Bo
ZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3Rl
bXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+
PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5U
PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJz
cDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5NCIgdGFyZ2V0PSJfYmxh
bmsiPiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8L2E+DQogJm5ic3A7fCAmbmJzcDs8Yj5FOiZuYnNw
OzwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdl
dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5jaHJpcy5kZWFybG92ZUBiYWVz
eXN0ZW1zLmNvbTwvc3Bhbj48L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3Jk
IFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhO
Ljxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2Js
YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9z
cGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4Qjky
Ij5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJl
ZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVz
ZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzoz
LjBwdCAwY20gMGNtIDBjbTtib3JkZXItY29sb3I6LW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVz
ZS10ZXh0LWNvbG9yIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh
bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8YSBo
cmVmPSJtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu
IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlldGZAdGhvbWFzY2xhdXNlbi5vcmc8L3NwYW4+PC9hPiZu
YnNwO1s8YSBocmVmPSJtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzppZXRmQHRob21hc2NsYXVzZW4u
b3JnPC9zcGFuPjwvYT5dJm5ic3A7PGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7MTcgTWFyY2ggMjAx
NiAxNjozODxicj4NCjxiPlRvOjwvYj4mbmJzcDtEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTxi
cj4NCjxiPkNjOjwvYj4mbmJzcDtNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdDxi
cj4NCjxiPlN1YmplY3Q6PC9iPiZuYnNwO1JlOiBNZXNzYWdlIGludGVncml0eSBhbmQgbWVzc2Fn
ZSBtdXRhYmlsaXR5ICh3YXMgUkU6IFttYW5ldF0gZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMg
cmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcyk8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBw
dDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hp
dGUiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FS
TklORyAqKio8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hp
dGUiPg0KPGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1l
c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZy
b20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPGJyPg0KQ29uc2lkZXIgY2Fy
ZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0
dGFjaG1lbnRzIG9yIHJlcGx5Ljxicj4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcmbmJzcDs8
L3NwYW4+PC9pPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQg
RmxhZ3M8L3NwYW4+PC9pPjwvYj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz
MzM5NzIiPiZuYnNwO3RoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzDQogeW91IHJl
Y2VpdmUsIGNsaWNrJm5ic3A7PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1z
LmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3Mu
cGRmIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aGVyZTwvc3Bh
bj48L2E+Ljxicj4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2Ug
Zm9sbG93Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9o
b3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBT
dXNwaWNpb3VzJTIwRW1haWxzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPnRoaXMgcHJvY2Vzczwvc3Bhbj48L2E+Ljwvc3Bhbj48L2k+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
Pk9uIDE3IE1hciAyMDE2LCBhdCAxNzozMCwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgJmx0
OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl
bXMuY29tPC9zcGFuPjwvYT4mZ3Q7DQogd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYXBwcmVjaWF0ZSBU
aG9tYXPigJlzIGNvbW1lbnRzIGFib3V0IHRoZSBsaW1pdGF0aW9ucyBvZiBtZXNzYWdlIHJlZ2Vu
ZXJhdGlvbiwgYnV0IEkgd291bGQgYmUgYSBiaXQNCiBsZXNzIGFic29sdXRlLjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPlRoZSBpc3N1ZXMgb3ZlciBlbmQgdG8gZW5kIGF1dGhlbnRpY2F0aW9uIGFuZCBt
b3JlIGFkdmFuY2VkIHNpZ25hdHVyZXMgYXJlIHZhbGlkLiBJIG5lZWQgdG8gcmVhZA0KIHRoZSBn
aXZlbiByZWZlcmVuY2Ugb24gYWdncmVnYXRlIHNpZ25hdHVyZXMgdG8gaW5jcmVhc2UgbXkga25v
d2xlZGdlICh0aGFua3MgZm9yIGl0KSwgYnV0IG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHBvc3Np
YmlsaXRpZXMgaW4gdGhpcyBmaWVsZCBtYXkgb2ZmZXIgYSBzb2x1dGlvbiB0byB0aGUgcHJvYmxl
bSwgYnV0IHdpdGggc29tZSBvdGhlciBpc3N1ZXMgKHBvc3NpYmx5IGluY2x1ZGluZyBhIG5ldyB0
eXBlIG9mIFRMVikuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0IHRoZSBob3AgY291bnQvbGltaXQg
cG9pbnQgSSBkb27igJl0IGZ1bGx5IGFncmVlIHdpdGgsIHlvdSBjYW4gcmVnZW5lcmF0ZSB3aXRo
IGFuIGluY3JlbWVudGVkL2RlY3JlbWVudGVkDQogY291bnQvbGltaXQsIHdoaWNoIGxlYXZlcyB0
aGUgYWJpbGl0eSB0byBwcmV2ZW50IG1lc3NhZ2VzIHByb3BhZ2F0aW5nIGluZGVmaW5pdGVseSwg
aW5jbHVkaW5nIGV4cGFuZGluZyByaW5nIHNlYXJjaGVzLCBhbmQgcmV0YWlucyB0aGUgYWJpbGl0
eSB0byB1c2UgUkZDIDU0OTcgaW50ZXJ2YWwgYW5kIHZhbGlkaXR5IHRpbWVzIHRoYXQgbWlnaHQg
YmUgdXNlZnVsIHdpdGggYW4gZXhwYW5kaW5nIHJpbmcgc2VhcmNoIChvciBtaWdodCBub3QpLjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCB0aGUga2V5IGlzc3VlIGlzIHRoYXQgQU9EVnYyIHdhbnRz
IHRvIGFjY3VtdWxhdGUgbWV0cmljcy4gSSBzdGlsbCBoYXZlbuKAmXQgZ290IHRvIHRoZSBib3R0
b20gb2YNCiBtYW55IGRldGFpbHMgaGVyZSwgYnV0IGxldOKAmXMgZm9yIHRoZSBtb21lbnQganVz
dCBjb25zaWRlciB0aGF0IGNvbmNlcHR1YWxseS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdOKAmXMg
aGFyZCB0byBoYW5kbGUgZW5kIHRvIGVuZC4gQ2hhcmxpZeKAmXMgZHJhZnQgYXR0ZW1wdHMgdG8g
ZG8gYW4gZW5kIHRvIGVuZCBvZiBzb21lIGluZm9ybWF0aW9uLA0KIG5vdCB0aGlzIGluZm9ybWF0
aW9uLiBJ4oCZbSBub3Qgc3VyZSBpZiB0aGF04oCZcyB1c2VmdWwgKGFuZCB0aGUgc3BlY2lhbGlz
ZWQgZm9ybWF0IGlzIGJldHRlciBhdm9pZGVkIGlmIHBvc3NpYmxlKS4gT3RoZXIgYXBwcm9hY2hl
cyBhcmUgaG9wIGJ5IGhvcCAobWlnaHQgYXMgd2VsbCB1c2UgcGFja2V0IHNpZ25hdHVyZXMpIGFu
ZCBzaGFyZWQga2V5IChtaWdodCBhcyB3ZWxsIGdvIGhvcCBieSBob3ApLiBQYWlyd2lzZSBzaWdu
YXR1cmVzIGZvciBlYWNoDQogcGFpciBvZiByb3V0ZXJzIEnigJltIGRpc2NvdW50aW5nIGFzIHNj
YWxpbmcgdGVycmlibHkuIEluIHRoZSBpbnRlcmVzdHMgb2YgY29tcGxldGVuZXNzIGxldOKAmXMg
bWVudGlvbiBub3QgYWNjdW11bGF0aW5nIG1ldHJpY3MsIHdoaWNoIHB1dHMgdXMgYmFjayB0byBo
b3AgY291bnQgYW5kIHRoYXTigJlzIG5vdCBpZGVhbCBlaXRoZXIuPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+SSBkb27igJl0IHRoaW5rIHRoZXJlIGlzIGFuIGlkZWFsIHNvbHV0aW9uLiAoSSBsaWtlIGlk
ZWFzIEnigJl2ZSBzZWVuIGFib3V0IGFnZ3JlZ2F0aW5nLCBidXQgdGhhdCBoYXMNCiBzb21lIGlz
c3VlcyBvZiBpdHMgb3duLCBldmVuIGFwYXJ0IGZyb20gY29tcHV0YXRpb25hbCBsb2FkLikgSeKA
mWQgbG92ZSB0byBiZSBwcm92ZWQgd3JvbmcgLSBzb21lb25lIHdpdGggdGhlIHBlcmZlY3Qgc29s
dXRpb24gdG8gY29tZSBhbG9uZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGljaCBtZWFucyB0aGF0
IGVpdGhlciB3ZSBtYWtlIGFuIGFyYml0cmFyeSBjaG9pY2UgLSB3aGljaCB3aWxsIGJlIGRpc2Fn
cmVlZCB3aXRoLCBidXQgbmVlZHMgZGlzY3Vzc2luZw0KIGZpcnN0IC0gb3IgY3JlYXRlIHNvbWV0
aGluZyBmbGV4aWJsZS4gVW5mb3J0dW5hdGVseSBmbGV4aWJsZSBpbiB0aGF0IHJlZ2FyZCBjb25z
dHJhaW5zIGluIG90aGVycywgZS5nLiBzb21lIChtYW55PyBtb3N0PykgYWdncmVnYXRpbmcgc2ln
bmF0dXJlcyBuZWVkIGZpeGVkIGRhdGEgc2l6ZXMgKHdoaWNoIHdlIGNhbiBkbyBieSBkZWZpbmlu
ZyBhIFRMViB0aGF0IOKAnGZpbGxzIHVw4oCdIHdpdGggaG9wIGNvdW50LCBidXQgdGhhdCBoYXMg
YSBjb3N0IHRvbykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPkkgaGF2ZSBiZWVuIHRvbGQgYnkgcGVvcGxlIG11Y2ggbW9yZSB3ZWxsIHZl
cnNlZCBpbiB0aGlzIHRoYW4gSSBpbiBjcnlwdG9sb2d5LCB0aGF0IHRoZSBjb3JyZWN0IGFuc3dl
ciBpcyDigJxzb21l4oCdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhdCBz
YWlkLCAmcXVvdDtBT0RWdjIgd2FudHMgdG8gYWNjdW11bGF0ZSBtZXRyaWNz4oCdIOKAlCBkb2Vz
IHRoYXQgbWVhbiB0aGF0IHRoZSBtZXNzYWdlIGdyb3dzIGFzIGl0IGlzIGJlaW5nIGZvcndhcmRl
ZCwgYW5kIHRoYXQgdGhlIHJlY2lwaWVudCBvZiBhIFJSRVEvUlJFUCB3aWxsIGtub3cgdGhlIGlu
ZGl2aWR1YWwNCiBjb3N0cyBvZiBlYWNoIHBhdGggc2VnbWVudD8gTXkgdW5kZXJzdGFuZGluZyBp
cywgdGhhdCB0aGUgcmVjaXBpZW50IHdpbGwgZ2V0IOKAnHRoZSBzdW0gdGhlIGNvc3RzIG9mIGVh
Y2ggcGF0aCBzZWdtZW504oCdIHdoaWNoIHNob3VsZCBiZSBmaXR0aW5nIHdpdGhpbiBhIGZpeGVk
IHNpemU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaG9tYXM8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy
Z2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tb3JyeSwgbm8gYW5zd2Vycywg
anVzdCBjb21tZW50cy4gQW5kIEnigJltIG5vdCBhZGRyZXNzaW5nIFRob21hc+KAmXMgbGF0ZXIg
cG9pbnRzIGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h
cmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw
MDdFN0UiPi0tPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFy
bG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBs
aWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8
L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOzxhIGhy
ZWY9InRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0IiB0YXJnZXQ9Il9ibGFuayI+JiM0
Mzs0NCAoMCkxMjQ1IDI0MjE5NDwvYT4NCiAmbmJzcDt8ICZuYnNwOzxiPkU6Jm5ic3A7PC9iPjxh
IGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxh
bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu
Y29tPC9zcGFuPjwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNB
OEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5v
bG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0K
PGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxhbmsiPjxz
cGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9h
Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4Qjky
Ij5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJl
ZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1
cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2lu
ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtO2JvcmRlci1jb2xvcjotbW96
LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3IiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDttYW5ldA0KIFs8YSBocmVmPSJtYWlsdG86bWFuZXQt
Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw
bGUiPm1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dJm5ic3A7PGI+T24g
QmVoYWxmIE9mJm5ic3A7PC9iPjxhIGhyZWY9Im1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWV0ZkB0aG9tYXNj
bGF1c2VuLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7MTcgTWFyY2ggMjAx
NiAxNjowMDxicj4NCjxiPlRvOjwvYj4mbmJzcDtNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxp
bmcgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiZuYnNwO1ttYW5ldF0gZHJhZnQtaWV0Zi1tYW5l
dC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtczwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAy
LjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1h
bGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPC9zcGFuPjwvYj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj
ZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw
dDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxpPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBv
dXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIg
b3IgdGhlIGludGVybmV0Ljxicj4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91
bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48YnI+
DQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nJm5ic3A7PC9zcGFuPjwvaT48Yj48aT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L2I+PGk+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4mbmJzcDt0aGF0IHlvdSBj
YW4gbG9vayBvdXQgZm9yIGluIGVtYWlscw0KIHlvdSByZWNlaXZlLCBjbGljayZuYnNwOzxhIGhy
ZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5
L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxz
cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmhlcmU8L3NwYW4+PC9hPi48YnI+DQpJZiB5b3UgZmVl
bCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyZuYnNwOzxhIGhyZWY9Imh0
dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3Rs
aWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYi
IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50aGlzIHByb2Nlc3M8
L3NwYW4+PC9hPi48L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjEu
MHB0IDQuMHB0IDEuMHB0IDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50
ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bzt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KjxiPioqJm5ic3A7PC9iPjwvc3Bh
bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XQVJOSU5HJm5ic3A7PC9zcGFuPjwvYj48
Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+KioqPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4N
Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5FWFRFUk5BTCBFTUFJTCAtLSBUaGlz
IG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbjwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRlYXIg
YWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPkFwb2xvZ2llcyBmb3Igbm90IGhhdmluZyBnb3R0ZW4gdGhpcyBkb25lIHNvb25lciAtIGRh
eS1qb2IgbGVhdmluZyBmZXcgc3BhcmUgY3ljbGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SeKAmXZlIHByZXZpb3VzbHkg
b2ZmZXJlZCByZXZpZXdzIGFuZCBjb21tZW50cywgYW5kIHNvbWUgb2YgdGhvc2UgaGF2ZSBiZWVu
IGFkZHJlc3NlZCBpbiB0aGUgbGF0ZXN0IEktRCDigJQgb3RoZXJzIGhhdmUgbm90LCBidXQgc2hv
dWxkIGJlLiBJIHJlY2FsbCB0aGF0IHRoZXJlIHdhcyBzb21lIG1haWwgYXR0ZW1wdGluZw0KIHRv
IHJlYnV0IHBhcnRzIG9mIHRoZSByZXZpZXcsIGFuZCBJIHdpbGwgZGlnIGl0IG91dCBhbmQgcmVw
bHkgdG8gdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPldpdGggdGhhdCBiZWluZyBzYWlkLCBJIGhhdmUgcmV2aWV3ZWQg
dGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCwgYW5kIGZ1bGwgZGV0YWlscyB3aWxs
IGJlIGZvcnRoY29taW5nLiBUaGVyZeKAmXJlIGEgY291cGxlIG9mIGJpZy10aWNrZXQvYXJjaGl0
ZWN0dXJhbCBpdGVtcyB0aGF0IEkgd2FudCB0bw0KIGFkZHJlc3MgdXAgZnJvbnQsIGFzIEkgYmVs
aWV2ZSB0aGF0IGJlZm9yZSB3ZSBoYXZlIHRob3NlIGhhbW1lcmVkIG91dCwgaXQgd2lsbCBiZSB1
c2VsZXNzIHRvIGdvIGludG8gZGV0YWlscy4gTm90ZSwgSSBkbyBub3QgY2xhaW0gdGhhdCB0aGlz
IGlzIGFuIGV4aGF1c3RpdmUgbGlzdCBvZiDigJxiaWcgdGlja2V0IGl0ZW1z4oCdLCBidXQgdGhh
dOKAmXMgYXMgZmFyIGFzIEkgaGF2ZSBnb3R0ZW4gaW4gdGhpbmtpbmcgdGhpcyB0aHJvdWdoLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+SSBhbHNvIGJyaW5nIHRoZXNlIHVwIGFzIHRoZXkgYXJlIGl0ZW1zIHRoYXQgaGF2ZSBi
ZWVuIGJyb3VnaHQgdXAgcmVwZWF0ZWRseSBvdmVyIHRoZSBwYXN0IHllYXJzLCBidXQgbm90IHJl
c29sdmVkIG5vciBkaXNjdXNzZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48dT5Mb29wczwvdT48L2I+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkp1c3QgdG8g
YnJpbmcgdGhpcyBvdXQ6IEkgc2hhcmUgQ2hyaXPigJkgd29ycnkgYWJvdXQgY29uZmxpY3Rpbmcg
YW5kIGNvbmN1cnJlbnQgc3RhdGVtZW50cyBmcm9tIHRoZSBhdXRob3JzIG9uIOKAnFRoZXJlIGFy
ZSBubyBsb29wcyBwb3NzaWJsZeKAnSBhbmQg4oCcV2UgbmVlZCB0byBmaXggdHdvIHNpdHVhdGlv
bnMgd2hlcmUNCiBsb29wcyBjYW4gb2NjdXLigJ0gYW5kIOKAnHdlIGFyZSBzdGlsbCBpbnZlc3Rp
Z2F0aW5nIHNvbWUgbG9vcCBjb25kaXRpb25z4oCdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHBhcnRpY3VsYXJseSB3b3Jy
eSB0aGF0IHRoaXMgaXMgbm90IGEgZGlzY3Vzc2lvbiBoYWQgaW4gcHVibGljLCBidXQgYXBwYXJl
bnRseSBpbiBzb21lIG90aGVyIGZvcnVt4oCmPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjx1Pklu
dGVybWVkaWF0ZSBSb3V0ZSBSZXBsaWVzLCBhbmQgYWxsIG9mIHNlY3Rpb24gMTA8L3U+PC9iPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5T
ZWN0aW9uIDEwIGNvbnRhaW5zIGEgc2V0IG9mIOKAnHZhZ3VlbHkgc3BlY2lmaWVkIGV4dGVuc2lv
bnPigJ0sIHdoaWNoIGlzIGluY29oZXJlbnQgd2l0aCB0aGUgaW50ZW5kZWQgc3RhdHVzIGluZGlj
YXRlZCBmb3IgdGhpcyBkb2N1bWVudC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNwZWNpZmljYWxseSwgYW5kIHRo
aXMgaXMgbm90IHVucmVsYXRlZCB0byB0aGUgcG9pbnQgYWJvdXQgbG9vcHMgYWJvdmUsIGludGVy
bWVkaWF0ZSBSUkVQcyAoc2VjdGlvbiAxMC4zKSBhcmUgYSBwb3RlbnRpYWwgc291cmNlIGZvciBs
b29wcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPkV4cGFuZGluZyBSaW5nIE11bHRpY2FzdCAoc2VjdGlvbiAxMC4xKSBpcyBu
b3QgZG9jdW1lbnRlZCBpbiBhIHdheSB0aGF0IGNhbiBiZSBpbXBsZW1lbnRlZCAoYW5kIGFsc28s
IHNlZSDigJxGb3J3YXJkaW5nLXZzLXJlZ2VuZXJhdGlvbuKAnSBiZWxvdywgaXQgaXMgaW4gdGhl
IHByZXNlbnQgZm9ybSBvZiB0aGlzIHByb3RvY29sDQogaW1wb3NzaWJsZSksIGV0Yy48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxiPjx1PkZvcndhcmRpbmctdnMtcmVnZW5lcmF0aW9uPC91PjwvYj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
UmVjZW50IGV4Y2hhbmdlcyBvbiB0aGUgbGlzdCBtYWRlIG1lIHVuZGVyc3RhbmQgdGhhdCBwcm90
b2NvbCBjb250cm9sIG1lc3NhZ2VzIGFyZSAqbm90KiBmb3J3YXJkZWQsIGJ1dCBhcmUgY29uc3Vt
ZWQgYXQgZWFjaCBob3AsIHRoZW4gYSBuZXcgbWVzc2FnZSB3aXRoIChhbG1vc3QtYnV0LW5vdC1x
dWl0ZSkNCiB0aGUgc2FtZSBjb250ZW50IGlzIGdlbmVyYXRlZCBhbmQgdHJhbnNtaXR0ZWQuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5JIGhhdmUgdGhvdWdodCBzb21lIG1vcmUgb24gdGhpcyAoJmFtcDsgcmVhZCBzb21lIG9m
IHRoZSBleGNoYW5nZXMgb24gdGhlIGxpc3Qgb24gdGhpcyB0b3BpYyBieSBDaHJpcywgVWxyaWNo
LCBhbmQgb3RoZXJzKSwgYW5kIEkgYW0gY29udmluY2VkIHRoYXQgdGhpcyBpcyBub3QgdGhlIHJp
Z2h0IHdheSB0byBnbywmbmJzcDs8Yj5hdA0KIGxlYXN0PC9iPiZuYnNwO2ZvciB0aGUgZm9sbG93
aW5nIHJlYXNvbnM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7byZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxiPkl0IHJlbmRl
cnMgdGhlIGhvcC1saW1pdC9ob3AtY291bnQgZmllbGRzIGluIHRoZSBSRkM1NDQ0IG1lc3NhZ2Ug
aGVhZGVyIHVzZWxlc3MuPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGlzIHdv
dWxkIG5vdCBiZSBiYWQgaWYgdGhlIGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBieSB0aG9zZSBmaWVs
ZHMgd2FzIG5vdCB1c2VmdWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A74oCUIHNhZGx5
LCBpdCBpcy4gRm9yIGV4YW1wbGUsIGZvciBzY29wZSBsaW1pdGVkIGZsb29kaW5nIChleHBhbmRp
bmcgcmluZyBzZWFyY2gsIGFuZCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtz
dWNoKSB3aGljaCBtYXkgYmUgb2YgaW50ZXJlc3QsIGFuZCB3aGljaCByZXF1aXJlIGhvcC1saW1p
dC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QSBob3AtY291bnQgZmllbGQg
bWF5IGFsc28gcHJvdmlkZSBhIOKAnGNoZWFw4oCdIChpbiB0ZXJtcyBvZiBvdmVyaGVhZCkgYWRk
aXRpb25hbCBwaWVjZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvZiBpbmZvcm1hdGlv
biB0byB1c2UgY29uanVuY3RpdmVseSB3aXRoIGEg4oCccmVhbOKAnSBtZXRyaWMuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgb25seSBwcmFjdGljYWwgc29sdXRpb24g
d291bGQgYmUgdG8gcmUtaW50cm9kdWNlIHRoZXNlIGZ1bmN0aW9ucyBieSB3YXkgb2YgaW5zZXJ0
aW5nIGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TWVzc2FnZVRMViDigJQgd2hpY2gg
KGkpIGlzIG5vdCBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCwgYW5kIChpaSkgd2hpY2ggd291
bGQganVzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzZXJ2ZSB0byByZW5kZXIgbWVz
c2FnZXMgYmlnZ2VyIHRoYW4gc3RyaWN0bHkgbmVlZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7U2NvcGUgbGltaXRlZCBmbG9vZGluZyAmbmJzcDtkb2VzIHNlZW0gdG8g
YmUgYSBuZWNlc3NhcnkgcmVxdWlyZW1lbnQsIGlmIGZvciBubzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDtvdGhlciByZWFzb24gdGhhbiB0byBwcmV2ZW50IGluZm9ybWF0aW9uIGZyb20g
4oCcY2lyY3VsYXRpbmcgZm9yZXZlciBpbiB0aGUgbmV0d29ya+KAnS48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO28mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDs8Yj48dT5JdCBtYWtlcyBlbmQtdG8tZW5kIGF1dGhlbnRpY2F0aW9uIHVubmVj
ZXNzYXJpbHkgaGFyZC48L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJIHRo
aW5rIENocmlzIGNhbGxlZCB0aGlzIG91dCBhbHJlYWR5LCBidXQgaXQgYmVhcnMgcmVwZWF0aW5n
OiBTIGdlbmVyYXRlcyBhIG1lc3NhZ2UmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7KHNheSwgYSBSUkVRKSwgYW5kIGluY2x1ZGVzIGFuIElDViBjYWxjdWxhdGVkIG92ZXIgdGhl
IGNvbnRlbnQgb2YgdGhlIG1lc3NhZ2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0Zv
ciBhbnkgcmVjaXBpZW50IHRvIGJlIGFibGUgdG8gdmFsaWRhdGUgdGhlIElDViwgdGhlIG1lc3Nh
Z2UgaGFzIHRvIGJlIGV4YWN0bHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIHNh
bWUg4oCUIG5vdCBqdXN0IGluIGNvbnRlbnQsIGJ1dCBpbiBzdHJ1Y3R1cmUg4oCUIGFzIHdoYXQg
d2FzIGdlbmVyYXRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO+KAnFJl
Z2VuZXJhdGluZ+KAnSByYXRoZXIgdGhhbiDigJxmb3J3YXJkaW5n4oCdIG1lc3NhZ2VzIG1lYW5z
LCB0aGF0IHRoZSBpbnRlcm1lZGlhdGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cm91
dGVyIOKAnHJlZ2VuZXJhdGluZ+KAnSB0aGUgUlJFUSBtYXkgY2hvc2UgYSBkaWZmZXJlbnQgc3Ry
dWN0dXJlIChlLmcuLCBpbmNsdWRlIFRMVnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
aW4gYSBkaWZmZXJlbnQgb3JkZXIpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7VGhlIHByb3Bvc2FsIGZyb20mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMCIgdGFyZ2V0PSJfYmxhbmsi
PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1wZXJraW5zLW1hbmV0LWFvZHYtZTJlc2VjLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7aXMgdG8gYWRkIGNvbnN0cmFpbnRzIG9uIChpKSB0aGUgc2V0IG9m
IGVsZW1lbnRzIHRvIGluY2x1ZGUgaW4gYSBzaWduYXR1cmUgYW5kIChpaSkgdGhlPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwO29yZGVyIG9mIHRoZXNlIGVsZW1lbnRzLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7T25lJm5ic3A7cHJvYmxlbSB3aXRoIHRoYXQgYXBw
cm9hY2ggaXMgKGkpOiBpZiBhbiBleHRlbnNpb24gYWRkcyBhIG1lc3NhZ2UgVExWLCBvciBhbiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBZGRyZXNzIFRMViwgdG8gYSBtZXNz
YWdlLCB0aGVuIHRoYXQgd2lsbCBub3QgYmUg4oCcY292ZXJlZOKAnSBieSB0aGUgcHJvcG9zZWQg
ZTJlc2VjIFRMVi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UmF0aGVyIGZvciAqZWFj
aCogZXh0ZW5zaW9uIGRldmVsb3BlZCwgYW4g4oCcdXBkYXRlcyBlMmVzZWPigJ0gY2xhdXNlIG5l
ZWRzIHRvIGJlIGRvbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJ4oCZ
ZCBzYXkgdGhhdCB0aGlzIGFwcHJvYWNoIHdvdWxkIGJlIHByb25lIHRvIGVycm9ycyDigJQgYW5k
IGFkZCBlbnRyb3B5IHRvIHRoZSBwcm9jZXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
O29mIGRlc2lnbmluZyBwcm90b2NvbCBleHRlbnNpb25zLiBUaGUgYWx0ZXJuYXRpdmUsIGEgbWVz
c2FnZSBiZWluZyBnZW5lcmF0ZWQgYnkgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
O3NvdXJjZSBhbmQgKmZvcndhcmRlZCogKGFzIHdlIGRvIGluIE9MU1J2MiwgZm9yIGV4YW1wbGUp
IHdvdWxkIGFsbG93IElDViBUTFZzJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyhldmVuLCBhbGxvdyByZXVzZSBvZiB0aG9zZSBzcGVjaWZpZWQgZm9yIE9MU1J2MikgZm9yIGNv
dmVyaW5nIGEgbWVzc2FnZSBhbmQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
ZXh0ZW5zaW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO+KAnEJ1dCB3
aGF0IGFib3V0IHRoZSBtZXRyaWNzIHZhbHVlIHdoaWNoIHdpbGwgY2hhbmdlIG9uIGVhY2ggaG9w
4oCdLCB5b3UgbWF5IHNheT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Rm9ydHVuYXRl
bHksIHRoYXQgaXMgcmVsYXRpdmVseSBlYXN5IHRvIGhhbmRsZTogc2ltcGx5IHplcm8gb3V0IHRo
ZSB2YWx1ZSBvZiB0aGF0IFRMViB3aGVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2dl
bmVyYXRpbmcgb3IgdmVyaWZ5aW5nIHRoZSBJQ1YgTWVzc2FnZVRMVi4gQW5kIHVzZSBQYWNrZXQt
VExWcyBmb3IgaG9wLWJ5LWhvcCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDth
dXRoZW50aWNhdGlvbiwgaWYgbmVlZGVkIChidXQsIHNlZSBiZWxvdykuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDtvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7PGI+PHU+SXQgcHJldmVudHMgdGhlIHVzZSBvZiBtb3JlIGNsZXZlci9hZHZh
bmNlZCBzaWduYXR1cmUgc2NoZW1lcy9JQ1ZzPC91PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7QWdncmVnYXRlIHNpZ25hdHVyZSBhbGdvcml0aG1zICgmbmJzcDs8YSBocmVmPSJo
dHRwczovL2NyeXB0by5zdGFuZm9yZC5lZHUvfmRhYm8vcGFwZXJzL2FnZ3N1cnZleS5wZGYiIHRh
cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2NyeXB0by5z
dGFuZm9yZC5lZHUvfmRhYm8vcGFwZXJzL2FnZ3N1cnZleS5wZGY8L3NwYW4+PC9hPik8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZXhpc3QsIGFuZCBhbiBpbnRlcmVzdGluZyB1c2UtY2Fz
ZSBjYW4gYmUgZm91bmQgaW4gYWxzbyByZWFjdGl2ZSBwcm90b2NvbHMsIGFsbG93aW5nIHZlcmlm
eWluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtub3Qg4oCcanVzdOKAnSB0aGUgZW5k
IHBvaW50cywgYnV0IGFsc28gdGhlIGludGVybWVkaWFyaWVzIChhZ2Fpbiwgd2l0aCB0aGUgYXBw
cm9wcmlhdGUg4oCcemVybyBvdXTigJ08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZGlz
Y3Vzc2VkIGFib3ZlLCBvciBzb21ldGhpbmcgc21hcnRlcikuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwO1JlZ2VuZXJhdGlvbiBvZiBtZXNzYWdlcywgcmF0aGVyIHRoYW4gZm9yd2FyZGlu
ZywgcmVuZGVycyB0aGF0IGltcG9zc2libGUgKG9yLCBpZiB1c2VkLDxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDt1cGRhdGluZyB0byAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMCIgdGFyZ2V0PSJf
YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1wZXJraW5zLW1hbmV0LWFvZHYtZTJlc2VjLTAwPC9zcGFuPjwvYT4pPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5UaGVyZSBhcmUgb3RoZXIgcmVhc29ucywgYnV0IHRoZSBhYm92ZSBhcmUgdGhvc2UgdGhhdCBq
dW1wIGF0IG1lIGFzIGltbWVkaWF0ZSBzaG93LXN0b3BwZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBkbyBob25lc3Rs
eSBub3Qgc2VlIHdoYXQgcG9zc2libGUgYmVuZWZpdCB0aGVyZSBpcyBmcm9tIOKAnHJlZ2VuZXJh
dGlvbuKAnSDigJQgYnV0IEkgc2VlIHZlcnkgY2xlYXIgaW5jb252ZW5pZW5jZXMsIGFuZCBzZWN1
cml0eSBpcyBub3QgdGhlIGxlYXN0IG9mIHRoZXNlLiBJbnNpc3Rpbmcgb24g4oCccmVnZW5lcmF0
aW9u4oCdDQogcmVxdWlyZXMgZGV2ZWxvcG1lbnQgb2Yg4oCcbm9uLWdlbmVyYWwgd29ya2Fyb3Vu
ZHPigJ0gYXMgcG9pbnRlZCBvdXQgYWJvdmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48dT5TZWN1cml0eSBDb25zaWRl
cmF0aW9uczwvdT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPlRoaXMgaXMgYW4gYWx3YXlzIHRob3JueSBzdWJqZWN0LiBXaGVuIE9M
U1J2MiB3YXMgZ29pbmcgdGhyb3VnaCB0aGUgcHJvY2VzcyB3ZSBnb3QgYSB0aG9yb3VnaCBlZHVj
YXRpb24gaW4gaG93IGxpdHRsZSB3ZSBrbmV3IGFib3V0IHNlY3VyaXR5IGZyb20gdGhlIFNFQy1B
RHMsIGFuZCBoYWQgdG8gc3BlbmQgYWJvdXQNCiBhIHllYXIgb3Igc28gZGV2ZWxvcGluZyBSRkM3
MTgzLiBUaGUgYm90dG9tIGxpbmUgaXMsIHRoYXQgdGhpcyBwcm90b2NvbCBuZWVkcyBpdHMg4oCc
UkZDNzE4MyAmbmJzcDtlcXVpdmFsZW504oCdLCBlaXRoZXIgYXMgcGFydCBvZiB0aGUgbWFpbiBk
b2N1bWVudCwgb3IgYXMgYW4gaW5kZXBlbmRlbnQgZG9jdW1lbnQuIGN1cnJlbnRseSwgdGhhdCBp
cyBub3QgdGhlIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj5BIG1pbmltYSwgbG9va2luZyBhdCBCQ1A3MiBhbmQgQkNQ
MTA3IOKAlCB0YWtpbmcgaW5zcGlyYXRpb24gZnJvbSBSRkM3MTgzIG1pZ2h0IGJlIGF3IGdvb2Qg
aWRlYSwgYXMgdGhhdCB3YXMgdGhlIG1vc3QgcmVjZW50IHRoYXQgd2VudCB0aHJvdWdoIHRoZSBT
RUMgQUQuIFJlZ2FyZGxlc3Mgb2YgaG93LCBob3dldmVyLA0KIGEg4oCcbWFuZGF0b3J5IHRvIGlt
cGxlbWVudOKAnSBzZWN1cml0eSBtZWNoYW5pc20gbW9zdCBiZSBzcGVjaWZpZWQgKEkgdGhpbmsg
dGhlIHJpZ2h0IHRlcm0gd2FzIOKAnE1VU1QgaW1wbGVtZW50LCBTSE9VTEQgdXNl4oCdKSwgaW4g
c3VmZmljaWVudCBkZXRhaWwgdG8gZW5zdXJlIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25z
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+QXMgYW4gZXhhbXBsZSwgYm90aCBbUkZDNjEzMF0gYW5kIFtSRkM3MTgxXSBzZXQg
b3V0IHRoYXQgdGhhdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBPbiByZWNl
aXZpbmcgYSAuLi4gbWVzc2FnZSwgYSByb3V0ZXIgTVVTVCBmaXJzdCBjaGVjayBpZiB0aGU8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7ICZuYnNwOyAmbmJzcDsgbWVzc2FnZSBpcyBpbnZhbGlkIGZvciBwcm9jZXNzaW5nIGJ5IHRo
aXMgcm91dGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5hbmQgdGhlbiBwcm9jZWVkIHRvIGdpdmUgYSBudW1iZXIgb2YgY29u
ZGl0aW9ucyB0aGF0LCBlYWNoLCB3aWxsIGxlYWQgdG8gYSByZWplY3Rpb24gb2YgdGhlIG1lc3Nh
Z2UgYXMgJnF1b3Q7YmFkbHkgZm9ybWVkIGFuZCB0aGVyZWZvcmUgaW52YWxpZCBmb3IgcHJvY2Vz
c2luZ+KAnSDigJQgYSBsaXN0IHdoaWNoIFJGQzcxODMNCiB0aGVuIGFtZW5kZWQuIFRoYXQgZ2F2
ZSBhIOKAnGhvb2vigJ0gZm9yIFJGQzcxODMgZm9yIGluc2VydGluZyDigJxyZWplY3Rpb27igJ0u
IElkZW0gZm9yIG1lc3NhZ2UgZ2VuZXJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIEkgd2FzIHRvIGRvIFJGQzcx
ODEvUkZDNjEzMCB0b2RheSwgSSB3b3VsZCBpbmNsdWRlIHRoYXQgZGlyZWN0bHkgaW50byB0aGUg
cHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMuIEl0IHR1cm5lZCBvdXQgdG8gYmUgbW9yZSBvdmVyaGVh
ZCAoYW5kIHNsb3cgZG93biBwdWJsaWNhdGlvbiBhbnl3YXlzKSB0byBkbw0KIGl0IGFzIHNlcGFy
YXRlIGRvY3VtZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2Vjb25kbHksIHdlIG5lZWQgdG8gYmUgYSBs
b3QgbW9yZSByaWdpZCBpbiB0ZXJtcyBvZiB3aGF0IElDVnMsIFRpbWVzdGFtcHMsIGV0Yy4gYXJl
IGFkZGVkL3JlbW92ZWQsIGFuZCB3aGF0IHRoYXQgYnJpbmdzLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rm9yIGV4YW1wbGUg
KHdpdGggdGhlIGFzc3VtcHRpb24gdGhhdCBtZXNzYWdlcyBhcmUgKmZvcndhcmRlZCogYW5kICpu
b3QqIHJlZ2VuZXJhdGVkKSwgdGhpcyBjb3VsZCBiZSBvbmUgb3B0aW9uOjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7byZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1doZW4gYSBSUkVRLCBSUkVQIG1lc3NhZ2UgaXMg
Z2VuZXJhdGVkLCBhZGQgYW4gSUNWIE1lc3NhZ2UgVExWLCB3aGljaCBpcyBjYWxjdWxhdGVkICZs
dDt0aGlzIHdheSZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A74oCmKHRha2UgaW5zcGlyYXRpb24gZnJvbSBSRkM3MTgzIGhlcmUpPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Li4uPGJyPg0KPGJy
Pg0KW01lc3NhZ2UgY2xpcHBlZF0mbmJzcDsmbmJzcDs8YnI+DQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4N
CjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0QGll
dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL21hbmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+
DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBp
ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxwPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqPGJyPg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz
IGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPg0KcmVjaXBpZW50IGFuZCBtYXkg
YWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNp
cGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNl
bmRlci48YnI+DQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBv
c2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPg0KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90
aGVyIHBlcnNvbi48YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv
dHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1h
bmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg
aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+
PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl
Zj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1593GLKXM0002VGREEN_--


From nobody Mon Apr 25 07:29: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 B06A112D5F8 for ; Mon, 25 Apr 2016 07:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.415
X-Spam-Level: 
X-Spam-Status: No, score=-1.415 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, TRACKER_ID=1.306] autolearn=no 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 2iIDaEy1Muej for ; Mon, 25 Apr 2016 07:28:57 -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 7B8AA12B014 for ; Mon, 25 Apr 2016 07:28:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 184E392085E; Mon, 25 Apr 2016 07:28:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461594537; bh=5yUz++N5bMa27uIqpLtJ6aVnbNN0fOha4tPbuafz6fc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=YWHXSpQxKelEcwbIymRw1O8SaLcE10J9+j0qeQrCrIc578FLyg4yza/wlzE/oLiPF 7ScVo9dT+JOuTRhSrgdWpK5eOg2rxEDx3E8rbdChg0vicvvjlxhMYf9+dxGLb4h+V9 bfJ6OLMGiIN0JIwSkmzfV6kW+W4iwbLyF/dA+rlk=
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 913BD1C08B8; Mon, 25 Apr 2016 07:28:54 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_47C95A5E-4CFB-456F-98EB-A78611384D3B"
From: ietf@thomasclausen.org
In-Reply-To: 
Date: Mon, 25 Apr 2016 16:28:52 +0200
Sendlaterdate: Mon, 25 Apr 2016 16:28:52 +0200
Message-Id: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        
To: Justin Dean 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Christopher Dearlove , Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 14:29:02 -0000

--Apple-Mail=_47C95A5E-4CFB-456F-98EB-A78611384D3B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 25 Apr 2016, at 16:20, Justin Dean  wrote:
>=20
> A thought regarding integrity checking.  A possible future "fix" for =
integrity could be done on a "virtual" packet in which known TLVs/values =
along with ordered addresses are uncompressed and then verified.  It =
could allow extra TLV tagging without modifying the validity of that =
data.  The very big drawback would be the overhead of having to =
uncompressed everything to check the validity.  It's functionally the =
same as zeroing out local (this is my stuff) TLV data vs remote (this is =
not my stuff) TLV data. =20

That requires an imposed ordering of addresses, address TLVs, Message =
TLVs, etc., even if only =E2=80=9Cin memory=E2=80=9D, it is something =
that everybody should be aware of, and doing the same way

	o	That ordering would have to be specified in this =
document (no, it would not be a =E2=80=9Cfuture fix=E2=80=9D, this is=20
		a requirement to the base spec, since *not* doing that =
would mean that this =E2=80=9Cfuture fix=E2=80=9D could render
		current implementations non-compliant!)

	o	While this would be *hard* for the current =
messages/TLVs, I=E2=80=99d imagine that it=E2=80=99d make extensions
		impossible (in an interoperable fashion).

	o	It=E2=80=99d be *exceptionally* heavy for all =
intermediate routers, wanting to verify the integrity of a=20
		message: to be able to force everybody in a network to =
=E2=80=9Cunwrap=E2=80=9D the message into an=20
		uncompressed form *before* validating its origins is =
opening up for DoS attacks.=20

		I want to do a *minimum* number of operations with a =
message, *before* deciding=20
		to discard a message as harmful.


> As for the RREP-Ack having a flag vs an address doesn't much bother me =
as either would have to be zeroed out for this type of future integrity =
checking.

This is not a question of future integrity checking, but a requirement =
for the base specification to be able to support.=20

Thomas


> Justin
>=20
> On Mon, Apr 25, 2016 at 9:27 AM, Dearlove, Christopher (UK) =
> =
wrote:
> Assuming for the moment that everyone will need an RREP-Ack or won=E2=80=
=99t (let=E2=80=99s come back to that) why do C and B need to put an =
address in as an RREQ-Ack request? Why not a flag, because the address =
will be included as the IP sending address - and we know 5444 is =
required to pass that on. (It=E2=80=99s used by NHDP as well.) Then we =
don=E2=80=99t need to change the RREP, it will have a flag set or not, =
and won=E2=80=99t change (in this regard).
>=20
> =20
>=20
> Now let=E2=80=99s consider do we know whether we can set a fixed flag. =
First I=E2=80=99d say there are two cases - you=E2=80=99ve got a firm =
control on what=E2=80=99s going on in your network, or it=E2=80=99s one =
of unknown parties and behaviour (consistent with specification). In the =
former case you only want one setting, for example no-Ack if running =
NHDP or your MAC layer tells you about bidirectionality, Ack otherwise. =
In the latter case, I think you just always want an Ack. So both cases =
get you to the same place.
>=20
> =20
>=20
> Should that not be an acceptable argument (though I think it=E2=80=99s =
good for where we are - in fact always Ack is close) then at flag is a =
step better, it=E2=80=99s a fixed location to change. However it would =
be better in that case if the two things to change (metric and ack flag) =
were together. But that has its own issues, so I won=E2=80=99t go there.
>=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 =
Baddow, Chelmsford, Essex CM2 8HN.
> www.baesystems.com/ai 
> 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: Victoria Mercieca [mailto:vmercieca0@gmail.com =
]=20
> Sent: 25 April 2016 14:15
> To: Jiazi YI
> Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc =
Networks mailing list
> Subject: Re: [manet] Message integrity and message mutability (was RE: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>=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
> Hi Jiazi,
>=20
>=20
>=20
> =20
>=20
> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI > wrote:
>=20
> Hi,=20
>=20
> =20
>=20
> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) =
> =
wrote:
>=20
> With regard to your validity time point, we here have a tradeoff. If =
you allow that feature, it significantly impacts on the approach that =
was coming together on as best you can end to end encryption.
>=20
> =20
>=20
> So the question is, is this a feature that=E2=80=99s really wanted? =
Unfortunately I think we know that the answer to that is, we don=E2=80=99t=
 know because we don=E2=80=99t have any experience. My view would be =
that in the tradeoff of an untested feature (unless I=E2=80=99m wrong =
about that) and the security complication, security wins and drop the =
feature. If there is some real requirement, then there=E2=80=99s a =
discussion. (Questions like how often the intermediate routers actually =
have any knowledge - typically links break for unexpected rather than =
expected reasons. Andan intermediate router could possibly use a =
validity time to influence its behaviour.) Note that dropping the =
ability of intermediate routers to modify/set still allows validity =
times per route to be set at endpoints.
>=20
> =20
>=20
> I agree with Chris' concern.
>=20
> The ValidityTime is optional, which makes the integrity protection =
hard. Furthermore, it gives a potential attack vector: as all the =
routers in a path will take the shortest validityTime, a compromised =
router can set the the validityTime to a very short value, which will =
make the route installed along the path became invalid (very soon).=20
>=20
> =20
>=20
> On the other hand, I'm not sure this option will give us much help. =
Chris mentioned much knowledge intermediate router would have to decide =
this value (and how much sense the value would make).=20
>=20
> Another issue is, a route to a destination might be updated by =
different sources. For example, in the network below:
>=20
> =20
>=20
> A----B-----C
>=20
> =20
>=20
> A first establish a route to B with long validity time. Then A =
initiates a route discovery to C. C tends to set a short validity time, =
which will make the route between B and A expire earlier than expected.=20=

>=20
> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered =
or not.=20
>=20
> =20
>=20
> =20
>=20
> Not sure I follow here.
>=20
> Currently, the validity time of the route between A and B would not =
affected by a short validity time of a route between A and C. Validity =
times are per-route, and the route A-B and the route A-C are separate.
>=20
> If we switched to a validity time per neighbor (so that we can keep =
validity time separate from route advertisements) as I mentioned in the =
email below, then the validity of a route between A and C would be =
affected if there was a short validity time between A and B. But, if B =
will only route for a certain amount of time, then the route between A =
and C will of course be affected. Is it best to know in advance that =
there's a time limit, or just deal with RERRs when they happen?
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> With regard to the acknowledgements, the problem (with regard to =
security) comes from trying to do two jobs with the same message - end =
to end route advertisement and hop by hop acknowledgement. I understand =
the reasons - saving bytes and message types. (I would have to study the =
protocol really hard to identify if any message types can be folded =
together and recognised by content rather than type efficiently. This I =
do not expect to do.) Again a tradeoff. This one is in discussion space, =
though that needs people who understand both sides of the issue, =
including the details of the bidirectionality mechanism. Of course, as =
has been said, we need one of those.
>=20
> =20
>=20
> I haven't finished my review of the latest draft, and I don't get the =
necessity of AckReq and the corresponding multicast RREP yet.=20
>=20
> If possible, this "optional" field should be avoided.=20
>=20
> =20
>=20
>=20
> To give an overview of AckReq and RREP:
>=20
> Since AODVv2 requires bidirectional links, this is the way to =
determine if a link is bidirectional.
>=20
> A----B----C
>=20
>=20
> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both =
install a route to OrigAddr but they dont yet know if it's valid because =
they dont know if the link to their next hop is available in the reverse =
direction.
>=20
> 2) C creates the RREP. Since it doesnt know if the link to B is =
bidirectional, it includes the AckReq (an address to indicate that it =
expects to receive a RREP_Ack from B).
>=20
> 3) B receives the RREP, installs a route to TargAddr and marks it as =
valid, since it knows the link to C is bidirectional, because the RREQ =
went in one direction and the RREP came in the other. B also sends the =
RREP_Ack to C and forwards the RREP to A (and might change the message =
to indicate its own AckReq - ie that it requires an ack from A).
>=20
> 4) C receives the RREP_Ack from B, and therefore knows that B received =
the RREP, therefore the link is bidirectional. C can then mark its route =
to OrigAddr as valid.
>=20
> 5) Similarly, A receives the RREP, installs the route to TargAddr and =
sends an RREP_Ack to B.
>=20
> 6) B receives the RREP_Ack and marks its route to OrigAddr as valid.
>=20
> =20
>=20
> Alternatively, in step 2, if C knows the link to B is bidirectional =
(perhaps from some earlier route discovery), it doesnt need to put the =
AckReq in the RREP. Then in step 3, since B doesnt know if the link to A =
is bidirectional, it changes the message to add the AckReq address, in =
order to get an RREP_Ack from A.
>=20
> If we want to avoid changing the message, we'll need to look at =
forwarding the RREP as-is, and creating a second message to solicit an =
RREP_Ack, in order to verify that the link is bidirectional before =
marking the route to OrigAddr as valid.
>=20
> Kind regards,
>=20
> Victoria.
>=20
> =20
>=20
> =20
>=20
> regards
>=20
> =20
>=20
> Jiazi
>=20
> =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 =
Baddow, Chelmsford, Essex CM2 8HN.
> www.baesystems.com/ai 
> 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: Victoria Mercieca [mailto:vmercieca0@gmail.com =
]=20
> Sent: 23 April 2016 10:55
> To: Christopher Dearlove
> Cc: ietf@thomasclausen.org ; Dearlove, =
Christopher (UK); Mobile Ad Hoc Networks mailing list
>=20
>=20
> Subject: Re: [manet] Message integrity and message mutability (was RE: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>=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
> Hi Chris,
>=20
> =20
>=20
> These have both been in the draft in some form since before I got =
involved... but I'll do my best to explain.
>=20
> =20
>=20
> - For Validity Time, its a way to advertise that you would only =
support the route contained in the message for a certain period of time. =
The originator might use this, but the draft was written to allow any =
intermediate node to be able to add it or update it too. The route =
created in the Local Route Set has an expiration time associated with =
it, based on the received validity time.
>=20
> - For the AckReq address, its so that you can add into a RREP a =
request for an acknowledgement, so that you don't have to have a =
different message type altogether for working out whether links to =
neighbors are bidirectional, and also, since you only care about =
bidirectionality on routes that are being set up, you dont need to =
constantly monitor all neighbors.
>=20
> =20
>=20
> =20
>=20
> In order to avoid the potential AckReq-related changes to each =
message, maybe we do need to introduce a different message specifically =
for this. We could maybe use RREP_Ack to both request and acknowledge? =
It means an extra message of control traffic that needs to be sent, =
maybe one extra message per hop on the path of a RREP, but it could =
still be limited to neighbors which have participated in the route =
discovery rather than monitoring all neighbors at all times.=20
>=20
> =20
>=20
> This message could maybe also include "I'm happy to route anywhere for =
a certain amount of time", sort of like willingness in OLSR/OLSRv2. So =
instead of having a validity time per route, its a validity time per =
neighbor. Then, for RREQ and RREP, only the metric value would change in =
transit, as discussed. However, that leads to some issues with deciding =
what a route's expiration time is. You might know how long the next hop =
router is valid for, but what if a router beyond that, which was also =
part of the route, had a lower validity time? You couldn't determine the =
real validity time. Do we remove the route expiration time altogether to =
avoid this issue? In which case, we would have to rely on RERR messages =
being sent for routes which become invalid when the neighbor's validity =
time has expired? So neighbor validity time expiration is treated the =
same as a link break.
>=20
> =20
>=20
> What do you think?
>=20
> =20
>=20
> Kind regards,
>=20
> Victoria.
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove =
> =
wrote:
>=20
> Pretty much all of the discussion has been assuming only a metric =
value change. With multiple things changing many of the ideas go out of =
the window. That reinforces the point about not making specifications =
now that might turn out to be wrong for ICVs.
>=20
> =20
>=20
> Ignoring how this misunderstanding happened, I'll start by asking why. =
Metric changing I understand. Why the other two? (there's a partial =
explanation of one). What alternatives have people implemented in =
comparable protocols?
>=20
> -- =20
>=20
> Christopher Dearlove
>=20
> christopher.dearlove@gmail.com  =
(iPhone)
>=20
> chris@mnemosyne.demon.co.uk  =
(home)
>=20
>=20
> On 23 Apr 2016, at 00:26, Victoria Mercieca > wrote:
>=20
> Hi all,
>=20
> =20
>=20
> Continued in this thread because the other one seems to be more about =
TLV types and metric type numbers, whereas this is about =
regeneration/forwarding.
>=20
> =20
>=20
> To recap, in the current draft, there are 3 things that might change =
at each hop:=20
> - the metric value (happens in RREQ and RREP),=20
> - adding/changing Validity Time using the Validity Time TLV (can =
happen in RREQ and RREP),=20
> - adding an address (and corresponding value in the AddressType TLV to =
indicate how to interpret the address) to indicate the address from =
which an RREP_Ack is expected, to accomplish the bidirectionality check =
(can happen in RREP).
>=20
> If we define a certain portion of the message as immutable and include =
the ICV to verify that part, end to end:=20
> - The metric value would be excluded from the ICV since it needs =
changing at each hop.=20
> - Would adding a Validity Time TLV at an intermediate hop be =
acceptable? The whole TLV could be removed in order to calculate the =
ICV?
>=20
> - Would adding an address cause issues for the ICV, because it's in =
the address block? Could the rule be "if it contains an AckReq address, =
remove it (and the corresponding value in the AddressType TLV), before =
checking the ICV", is that OK? Or would we need to avoid touching the =
ICV'ed part of the message altogether, maybe put the AckReq address in a =
separate Address Block, with an extra AddressType TLV following that =
address block? Is there a way to accomplish this?
>=20
> =20
>=20
> Also, to be thorough, do we need to consider RERR messages while we =
discuss regeneration vs forwarding?=20
>=20
> - RERR (sent when a link breaks) is a way of saying "I've lost my =
route so I'm telling others" and "you were my next hop, so now I've also =
lost my route, I'll tell others", etc. It's going to be tailored at each =
step to include the relevant routes that got deleted, it's not one =
message being sent end-to-end like RREQ and RREP are.=20
>=20
> - However, RERR (sent when a source of traffic is sending data on a =
route which comes through you, and you want to tell the Packet Source's =
router to delete the route) could be seen as an end-to-end message which =
all intermediate routers learn from, similar to RREQ and RREP. It =
reports one route, and doesn't need changing at intermediate hops, so =
could be protected with ICV.
>=20
> - Would it be OK to only require a message ICV if a PktSource address =
was included, i.e. when the message needs to go via a number of =
intermediate hops to PktSource's router? All other RERRs are intended to =
be one-hop messages, which may in turn prompt other one-hop messages, =
etc..., and a packet ICV might be more appropriate?
>=20
> =20
>=20
> Kind regards,
>=20
> Victoria.
>=20
> =20
>=20
> On Thu, Mar 17, 2016 at 5:26 PM, > wrote:
>=20
> =20
>=20
> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) =
> =
wrote:
>=20
> =20
>=20
> Yes, I meant AODVv2, thanks for the catch.
>=20
> =20
>=20
> So is your (Thomas) proposed base specification a hop count only =
metric?
>=20
> =20
>=20
> No, the would be silly as base specification, given that hop count =
mostly is useless.
>=20
> =20
>=20
> As base specification I would simply say =E2=80=9CInclude a Metric =
Type Message TLV with a value field, and a 7182 Message TLV & =
Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage as =
to generation and processing).=20
>=20
> =20
>=20
> With the message generated by the originator of the RREQ/RREP and =
*not* deconstructed/reconstructed/reordered (as is the risk with =
=E2=80=9Cregeneration) allows knowing that it would be *only* that =
metric field being modified (other than hop count/limit) for when =
eventually writing up the extension.
>=20
> =20
>=20
> (Actually doesn=E2=80=99t the current specification only define hop =
count, or has that changed in latest draft?)
>=20
> =20
>=20
> No. That is one of the issues I raise in my original. For some reason, =
it cites RFC6551, which is a ROLL document and which has in its abstract =
that:
>=20
> =20
>=20
>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>    compared with traditional wired and ad hoc networks that require =
the
>    specification of new routing metrics and constraints.=20
> =20
>=20
> I.e. this document cites a metric document which clearly claims to be =
inapplicable in ad hoc networks. I note that this is another thing =
I=E2=80=99ve raised for years without seeing it attempted resolved.
>=20
> =20
>=20
> Best,
>=20
> =20
>=20
> Thomas
>=20
> =20
>=20
> =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 =
Baddow, Chelmsford, Essex CM2 8HN.
> www.baesystems.com/ai 
> 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: ietf@thomasclausen.org  =
[mailto:ietf@thomasclausen.org ]=20
> Sent: 17 March 2016 17:10
> To: Dearlove, Christopher (UK)
> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
> Subject: Re: [manet] Message integrity and message mutability (was RE: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>=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
> On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) =
> =
wrote:
>=20
> =20
>=20
> OK, so we have a message that mutates by:
>=20
> - Modifying hop count/limit.
>=20
> - Modifying a metric value.
>=20
> Anything else?
>=20
> =20
>=20
> As mutating (other than hop count/limit) messages aren=E2=80=99t =
covered by 5444 or any derivative document (but only recommended =
against, not banned) that you may need to make the message otherwise =
immutable (no deconstruction and rebuilding, other than guaranteed =
unchanging) that would have to be specified by AODVv2. (Easy to say, but =
needs saying.)
>=20
> =20
>=20
> With you so far.
>=20
> =20
>=20
> Then that information is not in a guaranteed fixed location given by a =
simple offset. So any signature algorithm that finds it and ignores it =
or aggregates on it is specific to OLSRv2.
>=20
> =20
>=20
> Surely you mean AODVv2
>=20
> =20
>=20
> So standard 7182 ICVs don=E2=80=99t do the job, you would need an =
AODVv2 specialised variant. Which is the sort of thing that the message =
specific TLV space is there for, I=E2=80=99d be strongly against a =
=E2=80=9Cbut ignore the value of this specific TLV should it occur=E2=80=9D=
 being in the general space. However it can easily be defined by =
reference to 7182 (=E2=80=9Cthis TLV is like that TLV, except if an X =
TLV is present, set its value field to zero=E2=80=9D).
>=20
> =20
>=20
> Messy, but could work.
>=20
> =20
>=20
> Not that messy, actually, although clearly not as nice as =E2=80=9Cfixed=
 offset=E2=80=9D.
>=20
> =20
>=20
> That said, I am arguing for the base spec being:
>=20
> =20
>=20
>             =E2=80=9Cmake the message otherwise immutable (no =
deconstruction and rebuilding, other=20
>=20
>              than guaranteed unchanging)=E2=80=9D which is afforded by =
forwarding
>=20
> =20
>=20
>                                     +
>=20
> =20
>=20
>             RFC7182 Timestamps and ICVs.
>=20
> =20
>=20
>                                     +
>=20
> =20
>=20
>             RFC7183 style text bringing it all together.
>=20
> =20
>=20
> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would =
very be an experimental extension.
>=20
> =20
>=20
> What I object to is, if the base spec specifically renders such =
extensions impossible
>=20
> =20
>=20
> =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 =
Baddow, Chelmsford, Essex CM2 8HN.
> www.baesystems.com/ai 
> 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: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de =
]=20
> Sent: 17 March 2016 16:48
> To: Dearlove, Christopher (UK)
> Cc: ietf@thomasclausen.org ; Mobile Ad =
Hoc Networks mailing list
> Subject: Re: [manet] Message integrity and message mutability (was RE: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>=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
> Hi all,
>=20
> =20
>=20
> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) =
>:
>=20
> =20
>=20
> Good point about whether you just pass on one cost or a set of costs. =
As I said, not looked at details - I will, when time permits. One cost =
is much easier, and yes, it reduces the fixed size aggregated signatures =
problem to =E2=80=9Cjust=E2=80=9D one of computational load.
>=20
> =20
>=20
> For the record, Thomas=E2=80=99 understanding is correct; the cost is =
one aggregated value.=20
>=20
> =20
>=20
> Best regards,=20
>=20
> Lotte Steenrbink
>=20
> =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 =
Baddow, Chelmsford, Essex CM2 8HN.
> www.baesystems.com/ai 
> 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: ietf@thomasclausen.org  =
[mailto:ietf@thomasclausen.org ]=20
> Sent: 17 March 2016 16:38
> To: Dearlove, Christopher (UK)
> Cc: Mobile Ad Hoc Networks mailing list
> Subject: Re: Message integrity and message mutability (was RE: [manet] =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>=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
> On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) =
> =
wrote:
>=20
> =20
>=20
> I appreciate Thomas=E2=80=99s comments about the limitations of =
message regeneration, but I would be a bit less absolute.
>=20
> =20
>=20
> The issues over end to end authentication and more advanced signatures =
are valid. I need to read the given reference on aggregate signatures to =
increase my knowledge (thanks for it), but my understanding of the =
possibilities in this field may offer a solution to the problem, but =
with some other issues (possibly including a new type of TLV).
>=20
> =20
>=20
> But the hop count/limit point I don=E2=80=99t fully agree with, you =
can regenerate with an incremented/decremented count/limit, which leaves =
the ability to prevent messages propagating indefinitely, including =
expanding ring searches, and retains the ability to use RFC 5497 =
interval and validity times that might be useful with an expanding ring =
search (or might not).
>=20
> =20
>=20
> But the key issue is that AODVv2 wants to accumulate metrics. I still =
haven=E2=80=99t got to the bottom of many details here, but let=E2=80=99s =
for the moment just consider that conceptually.
>=20
> =20
>=20
> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft =
attempts to do an end to end of some information, not this information. =
I=E2=80=99m not sure if that=E2=80=99s useful (and the specialised =
format is better avoided if possible). Other approaches are hop by hop =
(might as well use packet signatures) and shared key (might as well go =
hop by hop). Pairwise signatures for each pair of routers I=E2=80=99m =
discounting as scaling terribly. In the interests of completeness =
let=E2=80=99s mention not accumulating metrics, which puts us back to =
hop count and that=E2=80=99s not ideal either.
>=20
> =20
>=20
> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=80=99=
ve seen about aggregating, but that has some issues of its own, even =
apart from computational load.) I=E2=80=99d love to be proved wrong - =
someone with the perfect solution to come along.
>=20
> =20
>=20
> Which means that either we make an arbitrary choice - which will be =
disagreed with, but needs discussing first - or create something =
flexible. Unfortunately flexible in that regard constrains in others, =
e.g. some (many? most?) aggregating signatures need fixed data sizes =
(which we can do by defining a TLV that =E2=80=9Cfills up=E2=80=9D with =
hop count, but that has a cost too).
>=20
> =20
>=20
> I have been told by people much more well versed in this than I in =
cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>=20
> =20
>=20
> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does =
that mean that the message grows as it is being forwarded, and that the =
recipient of a RREQ/RREP will know the individual costs of each path =
segment? My understanding is, that the recipient will get =E2=80=9Cthe =
sum the costs of each path segment=E2=80=9D which should be fitting =
within a fixed size?
>=20
> =20
>=20
> Thomas
>=20
> =20
>=20
>=20
>=20
>=20
> =20
>=20
> Sorry, no answers, just comments. And I=E2=80=99m not addressing =
Thomas=E2=80=99s later points here.
>=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 =
Baddow, Chelmsford, Essex CM2 8HN.
> www.baesystems.com/ai 
> 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 ietf@thomasclausen.org =

> Sent: 17 March 2016 16:00
> To: Mobile Ad Hoc Networks mailing list
> Subject: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big =
ticket Items
>=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
> Dear all,
>=20
> =20
>=20
> Apologies for not having gotten this done sooner - day-job leaving few =
spare cycles.
>=20
> =20
>=20
> I=E2=80=99ve previously offered reviews and comments, and some of =
those have been addressed in the latest I-D =E2=80=94 others have not, =
but should be. I recall that there was some mail attempting to rebut =
parts of the review, and I will dig it out and reply to that.
>=20
> =20
>=20
> With that being said, I have reviewed the latest version of the =
document, and full details will be forthcoming. There=E2=80=99re a =
couple of big-ticket/architectural items that I want to address up =
front, as I believe that before we have those hammered out, it will be =
useless to go into details. Note, I do not claim that this is an =
exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D, but that=E2=80=99s =
as far as I have gotten in thinking this through.
>=20
> =20
>=20
> I also bring these up as they are items that have been brought up =
repeatedly over the past years, but not resolved nor discussed.
>=20
> =20
>=20
> Loops
>=20
> Just to bring this out: I share Chris=E2=80=99 worry about conflicting =
and concurrent statements from the authors on =E2=80=9CThere are no =
loops possible=E2=80=9D and =E2=80=9CWe need to fix two situations where =
loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating some =
loop conditions=E2=80=9D
>=20
> =20
>=20
> I particularly worry that this is not a discussion had in public, but =
apparently in some other forum=E2=80=A6
>=20
> =20
>=20
> =20
>=20
> Intermediate Route Replies, and all of section 10
>=20
> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=80=
=9D, which is incoherent with the intended status indicated for this =
document.=20
>=20
> =20
>=20
> Specifically, and this is not unrelated to the point about loops =
above, intermediate RREPs (section 10.3) are a potential source for =
loops.
>=20
> =20
>=20
> Expanding Ring Multicast (section 10.1) is not documented in a way =
that can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=
=E2=80=9D below, it is in the present form of this protocol impossible), =
etc.
>=20
> =20
>=20
> =20
>=20
> Forwarding-vs-regeneration
>=20
> Recent exchanges on the list made me understand that protocol control =
messages are *not* forwarded, but are consumed at each hop, then a new =
message with (almost-but-not-quite) the same content is generated and =
transmitted.
>=20
> =20
>=20
> I have thought some more on this (& read some of the exchanges on the =
list on this topic by Chris, Ulrich, and others), and I am convinced =
that this is not the right way to go, at least for the following =
reasons:
>=20
> =20
>=20
> =20
>=20
>             o          It renders the hop-limit/hop-count fields in =
the RFC5444 message header useless.
>=20
>                         This would not be bad if the functionality =
offered by those fields was not useful
>=20
>                         =E2=80=94 sadly, it is. For example, for scope =
limited flooding (expanding ring search, and=20
>=20
>                         such) which may be of interest, and which =
require hop-limit.=20
>=20
>                         A hop-count field may also provide a =
=E2=80=9Ccheap=E2=80=9D (in terms of overhead) additional piece
>=20
>                         of information to use conjunctively with a =
=E2=80=9Creal=E2=80=9D metric.
>=20
> =20
>=20
>                         The only practical solution would be to =
re-introduce these functions by way of inserting a
>=20
>                         MessageTLV =E2=80=94 which (i) is not =
specified in this document, and (ii) which would just
>=20
>                         serve to render messages bigger than strictly =
needed.
>=20
> =20
>=20
>                         Scope limited flooding  does seem to be a =
necessary requirement, if for no
>=20
>                         other reason than to prevent information from =
=E2=80=9Ccirculating forever in the network=E2=80=9D.
>=20
> =20
>=20
>             o          It makes end-to-end authentication =
unnecessarily hard.
>=20
>                         I think Chris called this out already, but it =
bears repeating: S generates a message=20
>=20
>                         (say, a RREQ), and includes an ICV calculated =
over the content of the message.
>=20
>                         For any recipient to be able to validate the =
ICV, the message has to be exactly
>=20
>                         the same =E2=80=94 not just in content, but in =
structure =E2=80=94 as what was generated.
>=20
> =20
>=20
>                         =E2=80=9CRegenerating=E2=80=9D rather than =
=E2=80=9Cforwarding=E2=80=9D messages means, that the intermediate
>=20
>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ =
may chose a different structure (e.g., include TLVs
>=20
>                         in a different order).
>=20
> =20
>=20
>                         The proposal from =
https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00 =

>                         is to add constraints on (i) the set of =
elements to include in a signature and (ii) the
>=20
>                         order of these elements.
>=20
> =20
>=20
>                         One problem with that approach is (i): if an =
extension adds a message TLV, or an=20
>=20
>                         Address TLV, to a message, then that will not =
be =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>=20
>                         Rather for *each* extension developed, an =
=E2=80=9Cupdates e2esec=E2=80=9D clause needs to be done.
>=20
> =20
>=20
>                         I=E2=80=99d say that this approach would be =
prone to errors =E2=80=94 and add entropy to the process
>=20
>                         of designing protocol extensions. The =
alternative, a message being generated by the
>=20
>                         source and *forwarded* (as we do in OLSRv2, =
for example) would allow ICV TLVs=20
>=20
>                         (even, allow reuse of those specified for =
OLSRv2) for covering a message and=20
>=20
>                         extensions.
>=20
> =20
>=20
>                         =E2=80=9CBut what about the metrics value =
which will change on each hop=E2=80=9D, you may say?
>=20
>                         Fortunately, that is relatively easy to =
handle: simply zero out the value of that TLV when
>=20
>                         generating or verifying the ICV MessageTLV. =
And use Packet-TLVs for hop-by-hop=20
>=20
>                         authentication, if needed (but, see below).
>=20
> =20
>=20
>             o          It prevents the use of more clever/advanced =
signature schemes/ICVs
>=20
>                         Aggregate signature algorithms ( =
https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf =
)
>=20
>                         exist, and an interesting use-case can be =
found in also reactive protocols, allowing verifying
>=20
>                         not =E2=80=9Cjust=E2=80=9D the end points, but =
also the intermediaries (again, with the appropriate =E2=80=9Czero =
out=E2=80=9D
>=20
>                         discussed above, or something smarter).
>=20
>                         Regeneration of messages, rather than =
forwarding, renders that impossible (or, if used,
>=20
>                         updating to  =
https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00 =
)
>=20
> =20
>=20
> There are other reasons, but the above are those that jump at me as =
immediate show-stoppers.
>=20
> =20
>=20
> I do honestly not see what possible benefit there is from =
=E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear =
inconveniences, and security is not the least of these. Insisting on =
=E2=80=9Cregeneration=E2=80=9D requires development of =E2=80=9Cnon-genera=
l workarounds=E2=80=9D as pointed out above.
>=20
> =20
>=20
> Security Considerations
>=20
> This is an always thorny subject. When OLSRv2 was going through the =
process we got a thorough education in how little we knew about security =
from the SEC-ADs, and had to spend about a year or so developing =
RFC7183. The bottom line is, that this protocol needs its =E2=80=9CRFC7183=
  equivalent=E2=80=9D, either as part of the main document, or as an =
independent document. currently, that is not the case.
>=20
> =20
>=20
> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration =
from RFC7183 might be aw good idea, as that was the most recent that =
went through the SEC AD. Regardless of how, however, a =E2=80=9Cmandatory =
to implement=E2=80=9D security mechanism most be specified (I think the =
right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D), in =
sufficient detail to ensure interoperable implementations.
>=20
> =20
>=20
> As an example, both [RFC6130] and [RFC7181] set out that that:
>=20
> =20
>=20
>       On receiving a ... message, a router MUST first check if the
>=20
>       message is invalid for processing by this router
>=20
> =20
>=20
> and then proceed to give a number of conditions that, each, will lead =
to a rejection of the message as "badly formed and therefore invalid for =
processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That =
gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting =E2=80=9Crejection=
=E2=80=9D. Idem for message generation.
>=20
> =20
>=20
> If I was to do RFC7181/RFC6130 today, I would include that directly =
into the protocol specifications. It turned out to be more overhead (and =
slow down publication anyways) to do it as separate documents.
>=20
> =20
>=20
> Secondly, we need to be a lot more rigid in terms of what ICVs, =
Timestamps, etc. are added/removed, and what that brings.
>=20
> =20
>=20
> For example (with the assumption that messages are *forwarded* and =
*not* regenerated), this could be one option:
>=20
> =20
>=20
>                         o          When a RREQ, RREP message is =
generated, add an ICV Message TLV, which is calculated 
>=20
>                                      =E2=80=A6(take inspiration from =
RFC7183 here)
>=20
> =20
>=20
> ...
>=20
> [Message clipped] =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
> ********************************************************************
> 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
> _______________________________________________
> 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


--Apple-Mail=_47C95A5E-4CFB-456F-98EB-A78611384D3B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On 25 Apr 2016, at 16:20, Justin Dean <bebemaster@gmail.com> wrote:

A thought regarding integrity checking.  A possible =
future "fix" for integrity could be done on a "virtual" packet in which =
known TLVs/values along with ordered addresses are uncompressed and then =
verified.  It could allow extra TLV tagging without modifying the =
validity of that data.  The very big drawback would be the overhead =
of having to uncompressed everything to check the validity.  It's =
functionally the same as zeroing out local (this is my stuff) TLV data =
vs remote (this is not my stuff) TLV data.  

That =
requires an imposed ordering of addresses, address TLVs, Message TLVs, =
etc., even if only =E2=80=9Cin memory=E2=80=9D, it is something that =
everybody should be aware of, and doing the same way

	o	That ordering would have to be =
specified in this document (no, it would not be a =E2=80=9Cfuture =
fix=E2=80=9D, this is 
		a requirement to the base =
spec, since *not* doing that would mean that this =E2=80=9Cfuture fix=E2=80=
=9D could render
		current implementations =
non-compliant!)

	o	While =
this would be *hard* for the current messages/TLVs, I=E2=80=99d imagine =
that it=E2=80=99d make extensions
		impossible (in an =
interoperable fashion).

	o	It=E2=80=99=
d be *exceptionally* heavy for all intermediate routers, wanting to =
verify the integrity of a 
		message: to be able to =
force everybody in a network to =E2=80=9Cunwrap=E2=80=9D the message =
into an 
		uncompressed form =
*before* validating its origins is opening up for DoS =
attacks. 

		I =
want to do a *minimum* number of operations with a message, *before* =
deciding 
		to discard a message as =
harmful.


As =
for the RREP-Ack having a flag vs an address doesn't much bother me as =
either would have to be zeroed out for this type of future integrity =
checking.

This is not a question of future integrity checking, =
but a requirement for the base specification to be able to =
support. 

Thomas


Justin

On Mon, =
Apr 25, 2016 at 9:27 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> =
wrote:









Assuming for the moment that everyone =
will need an RREP-Ack or won=E2=80=99t (let=E2=80=99s come back to that) =
why do C and B need to put an address in as an RREQ-Ack request?
 Why not a flag, because the address will be included as the IP sending =
address - and we know 5444 is required to pass that on. (It=E2=80=99s =
used by NHDP as well.) Then we don=E2=80=99t need to change the RREP, it =
will have a flag set or not, and won=E2=80=99t change (in this =
regard).
 
Now let=E2=80=99s consider do we know =
whether we can set a fixed flag. First I=E2=80=99d say there are two =
cases - you=E2=80=99ve got a firm control on what=E2=80=99s going on in =
your network,
 or it=E2=80=99s one of unknown parties and behaviour (consistent with =
specification). In the former case you only want one setting, for =
example no-Ack if running NHDP or your MAC layer tells you about =
bidirectionality, Ack otherwise. In the latter case, I think you
 just always want an Ack. So both cases get you to the same place.
 
Should that not be an acceptable =
argument (though I think it=E2=80=99s good for where we are - in fact =
always Ack is close) then at flag is a step better, it=E2=80=99s a fixed
 location to change. However it would be better in that case if the two =
things to change (metric and ack flag) were together. But that has its =
own issues, so I won=E2=80=99t go there.
 
--

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: Victoria Mercieca [mailto:vmercieca0@gmail.com]


Sent: 25 April 2016 14:15

To: Jiazi YI

Cc: Dearlove, Christopher (UK); Christopher Dearlove; =
Mobile Ad Hoc Networks mailing list

Subject: Re: [manet] Message integrity and message =
mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big =
ticket Items)
 


 


*** 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.






Hi =
Jiazi,








 


On Mon, Apr 25, 2016 at 1:04 PM, =
Jiazi YI <ietf@jiaziyi.com> wrote:


Hi, 


 


On Mon, Apr 25, 2016 at 11:20 AM, =
Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:




With regard to your validity time =
point, we here have a tradeoff. If you allow that feature, it =
significantly
 impacts on the approach that was coming together on as best you can end =
to end encryption.
 
So the question is, is this a feature =
that=E2=80=99s really wanted? Unfortunately I think we know that the
 answer to that is, we don=E2=80=99t know because we don=E2=80=99t have =
any experience. My view would be that in the tradeoff of an untested =
feature (unless I=E2=80=99m wrong about that) and the security =
complication, security wins and drop the feature. If there is some real =
requirement,
 then there=E2=80=99s a discussion. (Questions like how often the =
intermediate routers actually have any knowledge - typically links break =
for unexpected rather than expected reasons. Andan intermediate router =
could possibly use a validity time to influence its behaviour.)
 Note that dropping the ability of intermediate routers to modify/set =
still allows validity times per route to be set at endpoints.






 




I agree with Chris' concern.




The ValidityTime is optional, =
which makes the integrity protection hard. Furthermore, it gives a =
potential attack vector: as all the routers in a path will take the =
shortest validityTime, a compromised router can set the the validityTime
 to a very short value, which will make the route installed along the =
path became invalid (very soon). 




 




On the other hand, I'm not sure =
this option will give us much help. Chris mentioned much knowledge =
intermediate router would have to decide this value (and how much sense =
the value would make). 




Another issue is, a route to a =
destination might be updated by different sources. For example, in the =
network below:




 




A----B-----C




 




A first establish a route to B =
with long validity time. Then A initiates a route discovery to C. C =
tends to set a short validity time, which will make the route between B =
and A expire earlier than expected. 




Is this a problem? Maybe yes, =
maybe no -- I'm not sure it's considered or not. 




 










 




Not =
sure I follow here.




Currently, the validity time of the route =
between A and B would not affected by a short validity time of a route =
between A and C. Validity times are per-route, and the route A-B and the =
route A-C are separate.




If we switched to a validity time =
per neighbor (so that we can keep validity time separate from route =
advertisements) as I mentioned in the email below, then the validity of =
a route between A and C would be affected if there was a short
 validity time between A and B. But, if B will only route for a certain =
amount of time, then the route between A and C will of course be =
affected. Is it best to know in advance that there's a time limit, or =
just deal with RERRs when they happen?




 




 
















 
With regard to the acknowledgements, =
the problem (with regard to security) comes from trying to do
 two jobs with the same message - end to end route advertisement and hop =
by hop acknowledgement. I understand the reasons - saving bytes and =
message types. (I would have to study the protocol really hard to =
identify if any message types can be folded together
 and recognised by content rather than type efficiently. This I do not =
expect to do.) Again a tradeoff. This one is in discussion space, though =
that needs people who understand both sides of the issue, including the =
details of the bidirectionality mechanism.
 Of course, as has been said, we need one of those.








 




I haven't finished my review of =
the latest draft, and I don't get the necessity of AckReq and the =
corresponding multicast RREP yet. 




If possible, this "optional" =
field should be avoided. 




 














To give an overview of AckReq and RREP:




Since AODVv2 requires bidirectional =
links, this is the way to determine if a link is bidirectional.




A----B----C






1) A sends RREQ, B forwards it, C receives the RREQ. B and C both =
install a route to OrigAddr but they dont yet know if it's valid because =
they dont know if the link to their next hop is available in the reverse =
direction.




2) C creates the RREP. Since it =
doesnt know if the link to B is bidirectional, it includes the AckReq =
(an address to indicate that it expects to receive a RREP_Ack from B).




3) B receives the RREP, installs =
a route to TargAddr and marks it as valid, since it knows the link to C =
is bidirectional, because the RREQ went in one direction and the RREP =
came in the other. B also sends the RREP_Ack to C and forwards
 the RREP to A (and might change the message to indicate its own AckReq =
- ie that it requires an ack from A).




4) C receives the RREP_Ack from =
B, and therefore knows that B received the RREP, therefore the link is =
bidirectional. C can then mark its route to OrigAddr as valid.




5) Similarly, A receives the =
RREP, installs the route to TargAddr and sends an RREP_Ack to B.




6) B receives the RREP_Ack and =
marks its route to OrigAddr as valid.




 




Alternatively, in step 2, if C knows the =
link to B is bidirectional (perhaps from some earlier route discovery), =
it doesnt need to put the AckReq in the RREP. Then in step 3, since B =
doesnt know if the link
 to A is bidirectional, it changes the message to add the AckReq =
address, in order to get an RREP_Ack from A.




If =
we want to avoid changing the message, we'll need to look at forwarding =
the RREP as-is, and creating a second message to solicit an RREP_Ack, in =
order to verify that the link is bidirectional before marking
 the route to OrigAddr as valid. 




Kind regards,




Victoria.




 




 












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
 
From: Victoria
 Mercieca [mailto:vmercieca0@gmail.com]


Sent: 23 April 2016 10:55

To: Christopher Dearlove

Cc: ietf@thomasclausen.org; Dearlove, =
Christopher (UK); Mobile Ad Hoc Networks mailing list






Subject: Re: [manet] Message integrity and message =
mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big =
ticket Items)








 



 



*** 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.






Hi Chris,


 




These have both been in the draft =
in some form since before I got involved... but I'll do my best to =
explain.


 




- For Validity Time, its a way to =
advertise that you would only support the route contained in the message =
for a certain period of time. The originator might use this, but the =
draft
 was written to allow any intermediate node to be able to add it or =
update it too. The route created in the Local Route Set has an =
expiration time associated with it, based on the received validity =
time.




- For the AckReq address, its so =
that you can add into a RREP a request for an acknowledgement, so that =
you don't have to have a different message type altogether for working =
out
 whether links to neighbors are bidirectional, and also, since you only =
care about bidirectionality on routes that are being set up, you dont =
need to constantly monitor all neighbors.




 




 




In order to avoid the potential =
AckReq-related changes to each message, maybe we do need to introduce a =
different message specifically for this. We could maybe use RREP_Ack to =
both
 request and acknowledge? It means an extra message of control traffic =
that needs to be sent, maybe one extra message per hop on the path of a =
RREP, but it could still be limited to neighbors which have participated =
in the route discovery rather than monitoring
 all neighbors at all times. 
=




 




This message could maybe also =
include "I'm happy to route anywhere for a certain amount of time", sort =
of like willingness in OLSR/OLSRv2. So instead of having a validity time =
per
 route, its a validity time per neighbor. Then, for RREQ and RREP, only =
the metric value would change in transit, as discussed. However, that =
leads to some issues with deciding what a route's expiration time is. =
You might know how long the next hop router is
 valid for, but what if a router beyond that, which was also part of the =
route, had a lower validity time? You couldn't determine the real =
validity time. Do we remove the route expiration time altogether to =
avoid this issue? In which case, we would have to
 rely on RERR messages being sent for routes which become invalid when =
the neighbor's validity time has expired? So neighbor validity time =
expiration is treated the same as a link break.




 




What do you think?




 




Kind regards,




Victoria.




 




 




 




 




 






 


On Sat, Apr 23, 2016 at 1:09 AM, =
Christopher Dearlove <chris@mnemosyne.demon.co.uk> =
wrote:




Pretty much all of the discussion =
has been assuming only a metric value change. With multiple things =
changing many of the ideas go out of the window. That reinforces the =
point about
 not making specifications now that might turn out to be wrong for =
ICVs.




 




Ignoring how this =
misunderstanding happened, I'll start by asking why. Metric changing I =
understand. Why the other two? (there's a partial explanation of one). =
What alternatives
 have people implemented in comparable protocols?



--  


Christopher Dearlove




christopher.dearlove@gmail.com (iPhone)




chris@mnemosyne.demon.co.uk (home)








On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmail.com> wrote:














Hi all,




 




Continued in this thread because =
the other one seems to be more about TLV types and metric type numbers, =
whereas this is about regeneration/forwarding.




 




To recap, in the current draft, =
there are 3 things that might change at each hop:


- the metric value (happens in RREQ and RREP), 

- adding/changing Validity Time using the Validity Time TLV (can happen =
in RREQ and RREP),


- adding an address (and corresponding value in the AddressType TLV to =
indicate how to interpret the address) to indicate the address from =
which an RREP_Ack is expected, to accomplish the bidirectionality check =
(can happen in RREP).



If we define a certain portion of the message as immutable and =
include the ICV to verify that part, end to end:


- The metric value would be excluded from the ICV since it needs =
changing at each hop. 

- Would adding a Validity Time TLV at an intermediate hop be acceptable? =
The whole TLV could be removed in order to calculate the ICV?


- Would adding an address cause issues for =
the ICV, because it's in the address block? Could the rule be "if it =
contains an AckReq address, remove it (and the corresponding value
 in the AddressType TLV), before checking the ICV", is that OK? Or would =
we need to avoid touching the ICV'ed part of the message altogether, =
maybe put the AckReq address in a separate Address Block, with an extra =
AddressType TLV following that address block?
 Is there a way to accomplish this?




 




Also, to be thorough, do we need =
to consider RERR messages while we discuss regeneration vs =
forwarding? 




- RERR (sent when a link breaks) =
is a way of saying "I've lost my route so I'm telling others" and "you =
were my next hop, so now I've also lost my route, I'll tell =
others", etc.
 It's going to be tailored at each step to include the relevant routes =
that got deleted, it's not one message being sent end-to-end like RREQ =
and RREP are. 




- However, RERR (sent when a =
source of traffic is sending data on a route which comes through you, =
and you want to tell the Packet Source's router to delete the route) =
could be
 seen as an end-to-end message which all intermediate routers learn =
from, similar to RREQ and RREP. It reports one route, and doesn't need =
changing at intermediate hops, so could be protected with ICV.




- Would it be OK to only require =
a message ICV if a PktSource address was included, i.e. when the message =
needs to go via a number of intermediate hops to PktSource's router? All
 other RERRs are intended to be one-hop messages, which may in turn =
prompt other one-hop messages, etc..., and a packet ICV might be more =
appropriate?




 


Kind regards,


Victoria.




 


On Thu, Mar 17, 2016 at 5:26 PM, =
<ietf@thomasclausen.org> wrote:


 






On 17 Mar 2016, at 18:17, =
Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:


 






Yes, I meant AODVv2, thanks for the =
catch.




 




So is your (Thomas) proposed base =
specification a hop count only metric?










 


No, the would be silly as base =
specification, given that hop count mostly is useless.




 




As base specification I would =
simply say =E2=80=9CInclude a Metric Type Message TLV with a value =
field, and a 7182 Message TLV & Timestamp=E2=80=9D as we do in =
OLSRv2 (with the appropriate verbiage
 as to generation and processing). 




 




With the message generated by the =
originator of the RREQ/RREP and *not* =
deconstructed/reconstructed/reordered (as is the risk with =
=E2=80=9Cregeneration) allows knowing that it would be
 *only* that metric field being modified (other than hop count/limit) =
for when eventually writing up the extension.




 










(Actually doesn=E2=80=99t the current =
specification only define hop count, or has that changed in latest
 draft?)








 


No. That is one of the issues I raise in my =
original. For some reason, it cites RFC6551, which is a ROLL document =
and which has in its abstract that:




 






   Low-Power and Lossy Networks (LLNs) have =
unique characteristics


   compared with traditional wired and ad hoc =
networks that require the


   specification of new routing metrics and =
constraints. 


 




I.e. this document cites a metric =
document which clearly claims to be inapplicable in ad hoc networks. I =
note that this is another thing I=E2=80=99ve raised for years without =
seeing it
 attempted resolved.




 




Best,




 




Thomas




 




 








 




--
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: ietf@thomasclausen.org [mailto:ietf@thomasclausen.org] 

Sent: 17 March 2016 17:10

To: Dearlove, Christopher (UK)

Cc: Lotte Steenbrink; Mobile Ad Hoc Networks =
mailing list

Subject: Re: [manet] Message integrity and =
message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple =
of big ticket Items)








 





 



*** 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 17 Mar 2016, at 18:04, =
Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>
 wrote:






 








OK, so we have a message that mutates =
by:








- Modifying hop count/limit.








- Modifying a metric value.








Anything else?








 








As mutating (other than hop =
count/limit) messages aren=E2=80=99t covered by 5444 or any derivative =
document
 (but only recommended against, not banned) that you may need to make =
the message otherwise immutable (no deconstruction and rebuilding, other =
than guaranteed unchanging) that would have to be specified by AODVv2. =
(Easy to say, but needs saying.)












 






With you so far.








 






Then that information is not in a =
guaranteed fixed location given by a simple offset. So any signature
 algorithm that finds it and ignores it or aggregates on it is specific =
to OLSRv2.








 






Surely you mean AODVv2








 






So standard 7182 ICVs don=E2=80=99t do =
the job, you would need an AODVv2 specialised variant. Which is the
 sort of thing that the message specific TLV space is there for, I=E2=80=99=
d be strongly against a =E2=80=9Cbut ignore the value of this specific =
TLV should it occur=E2=80=9D being in the general space. However it can =
easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like that
 TLV, except if an X TLV is present, set its value field to =
zero=E2=80=9D).








 








Messy, but could work.








 






Not that messy, actually, =
although clearly not as nice as =E2=80=9Cfixed offset=E2=80=9D.








 








That said, I am arguing for the =
base spec being:








 








         =
   =E2=80=9Cmake the message otherwise immutable (no =
deconstruction and rebuilding, other 








         =
    than guaranteed unchanging)=E2=80=9D which is =
afforded by forwarding








 








         =
            &n=
bsp;           &nbs=
p;  +








 








         =
   RFC7182 Timestamps and ICVs.








 








         =
            &n=
bsp;           &nbs=
p;  +








 








         =
   RFC7183 style text bringing it all together.








 








The =E2=80=9Caggregated =
signatures around mutable field=E2=80=9D would very be an experimental =
extension.








 








What I object to is, if the base =
spec specifically renders such extensions impossible








 








 






 






--
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: Lotte
 Steenbrink [mailto:lotte.steenbrink@fu-berlin.de] 

Sent: 17 March 2016 16:48

To: Dearlove, Christopher (UK)

Cc: ietf@thomasclausen.org; Mobile Ad Hoc Networks =
mailing list

Subject: Re: [manet] Message integrity and =
message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple =
of big ticket Items)












 







 



*** 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.








Hi all,










 














Am 17.03.2016 um 17:44 schrieb =
Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>:










 












Good point about whether you just pass =
on one cost or a set of costs. As I said, not looked at details
 - I will, when time permits. One cost is much easier, and yes, it =
reduces the fixed size aggregated signatures problem to =E2=80=9Cjust=E2=80=
=9D one of computational load.
















 












For the record, Thomas=E2=80=99 =
understanding is correct; the cost is one aggregated value. 












 












Best regards, 












Lotte Steenrbink










 












 








--
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: ietf@thomasclausen.org [mailto:ietf@thomasclausen.org] 

Sent: 17 March 2016 16:38

To: Dearlove, Christopher (UK)

Cc: Mobile Ad Hoc Networks mailing list

Subject: Re: Message integrity and message =
mutability (was RE: [manet] draft-ietf-manet-aodvv2-13 review - a couple =
of big ticket Items)
















 









 



*** 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 17 Mar 2016, at 17:30, =
Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>
 wrote:














 
















I appreciate Thomas=E2=80=99s comments =
about the limitations of message regeneration, but I would be a bit
 less absolute.
















 
















The issues over end to end =
authentication and more advanced signatures are valid. I need to read
 the given reference on aggregate signatures to increase my knowledge =
(thanks for it), but my understanding of the possibilities in this field =
may offer a solution to the problem, but with some other issues =
(possibly including a new type of TLV).
















 
















But the hop count/limit point I don=E2=80=
=99t fully agree with, you can regenerate with an =
incremented/decremented
 count/limit, which leaves the ability to prevent messages propagating =
indefinitely, including expanding ring searches, and retains the ability =
to use RFC 5497 interval and validity times that might be useful with an =
expanding ring search (or might not).
















 
















But the key issue is that AODVv2 wants =
to accumulate metrics. I still haven=E2=80=99t got to the bottom of
 many details here, but let=E2=80=99s for the moment just consider that =
conceptually.
















 
















It=E2=80=99s hard to handle end to end. =
Charlie=E2=80=99s draft attempts to do an end to end of some =
information,
 not this information. I=E2=80=99m not sure if that=E2=80=99s useful =
(and the specialised format is better avoided if possible). Other =
approaches are hop by hop (might as well use packet signatures) and =
shared key (might as well go hop by hop). Pairwise signatures for each
 pair of routers I=E2=80=99m discounting as scaling terribly. In the =
interests of completeness let=E2=80=99s mention not accumulating =
metrics, which puts us back to hop count and that=E2=80=99s not ideal =
either.
















 
















I don=E2=80=99t think there is an ideal =
solution. (I like ideas I=E2=80=99ve seen about aggregating, but that =
has
 some issues of its own, even apart from computational load.) I=E2=80=99d =
love to be proved wrong - someone with the perfect solution to come =
along.
















 
















Which means that either we make an =
arbitrary choice - which will be disagreed with, but needs discussing
 first - or create something flexible. Unfortunately flexible in that =
regard constrains in others, e.g. some (many? most?) aggregating =
signatures need fixed data sizes (which we can do by defining a TLV that =
=E2=80=9Cfills up=E2=80=9D with hop count, but that has a cost =
too).




















 














I have been told by people much =
more well versed in this than I in cryptology, that the correct answer =
is =E2=80=9Csome=E2=80=9D.
















 
















That said, "AODVv2 wants to =
accumulate metrics=E2=80=9D =E2=80=94 does that mean that the message =
grows as it is being forwarded, and that the recipient of a RREQ/RREP =
will know the individual
 costs of each path segment? My understanding is, that the recipient =
will get =E2=80=9Cthe sum the costs of each path segment=E2=80=9D which =
should be fitting within a fixed size?
















 
















Thomas
















 





































 
















Sorry, no answers, just comments. And =
I=E2=80=99m not addressing Thomas=E2=80=99s later points here.
















 










--
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 ietf@thomasclausen.org

Sent: 17 March 2016 16:00

To: Mobile Ad Hoc Networks mailing list

Subject: [manet] draft-ietf-manet-aodvv2-13 =
review - a couple of big ticket Items




















 











 



*** 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.










 


















Dear all,


















 




















Apologies for not having gotten =
this done sooner - day-job leaving few spare cycles.




















 




















I=E2=80=99ve previously offered =
reviews and comments, and some of those have been addressed in the =
latest I-D =E2=80=94 others have not, but should be. I recall that there =
was some mail attempting
 to rebut parts of the review, and I will dig it out and reply to =
that.




















 




















With that being said, I have =
reviewed the latest version of the document, and full details will be =
forthcoming. There=E2=80=99re a couple of big-ticket/architectural items =
that I want to
 address up front, as I believe that before we have those hammered out, =
it will be useless to go into details. Note, I do not claim that this is =
an exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D, but that=E2=80=99=
s as far as I have gotten in thinking this through.




















 




















I also bring these up as they are =
items that have been brought up repeatedly over the past years, but not =
resolved nor discussed.




















 




















Loops




















Just to bring this out: I share =
Chris=E2=80=99 worry about conflicting and concurrent statements from =
the authors on =E2=80=9CThere are no loops possible=E2=80=9D and =E2=80=9C=
We need to fix two situations where
 loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating some =
loop conditions=E2=80=9D




















 




















I particularly worry that this is =
not a discussion had in public, but apparently in some other forum=E2=80=A6=





















 




















 






















Intermediate Route Replies, and all of section 10




















Section 10 contains a set of =
=E2=80=9Cvaguely specified extensions=E2=80=9D, which is incoherent with =
the intended status indicated for this document. 




















 




















Specifically, and this is not =
unrelated to the point about loops above, intermediate RREPs (section =
10.3) are a potential source for loops.




















 




















Expanding Ring Multicast (section =
10.1) is not documented in a way that can be implemented (and also, see =
=E2=80=9CForwarding-vs-regeneration=E2=80=9D below, it is in the present =
form of this protocol
 impossible), etc.






















 




















 




















Forwarding-vs-regeneration




















Recent exchanges on the list made =
me understand that protocol control messages are *not* forwarded, but =
are consumed at each hop, then a new message with (almost-but-not-quite)
 the same content is generated and transmitted.




















 




















I have thought some more on this =
(& read some of the exchanges on the list on this topic by Chris, =
Ulrich, and others), and I am convinced that this is not the right way =
to go, at
 least for the following reasons:




















 




















 




















         =
   o         &=
nbsp;It renders the hop-limit/hop-count fields in the =
RFC5444 message header useless.




















         =
            &n=
bsp;  This would not be bad if the functionality offered by =
those fields was not useful




















         =
            &n=
bsp;  =E2=80=94 sadly, it is. For example, for scope limited =
flooding (expanding ring search, and 




















         =
            &n=
bsp;  such) which may be of interest, and which require =
hop-limit. 




















         =
            &n=
bsp;  A hop-count field may also provide a =E2=80=9Ccheap=E2=80=9D=
 (in terms of overhead) additional piece




















         =
            &n=
bsp;  of information to use conjunctively with a =E2=80=9Creal=E2=
=80=9D metric.




















 




















         =
            &n=
bsp;  The only practical solution would be to re-introduce =
these functions by way of inserting a




















         =
            &n=
bsp;  MessageTLV =E2=80=94 which (i) is not specified in this =
document, and (ii) which would just




















         =
            &n=
bsp;  serve to render messages bigger than strictly needed.




















 




















         =
            &n=
bsp;  Scope limited flooding  does seem to be a necessary =
requirement, if for no




















         =
            &n=
bsp;  other reason than to prevent information from =
=E2=80=9Ccirculating forever in the network=E2=80=9D.




















 




















         =
   o         &=
nbsp;It makes end-to-end authentication =
unnecessarily hard.




















         =
            &n=
bsp;  I think Chris called this out already, but it bears =
repeating: S generates a message 




















         =
            &n=
bsp;  (say, a RREQ), and includes an ICV calculated over the =
content of the message.




















         =
            &n=
bsp;  For any recipient to be able to validate the ICV, the =
message has to be exactly




















         =
            &n=
bsp;  the same =E2=80=94 not just in content, but in structure =
=E2=80=94 as what was generated.




















 




















         =
            &n=
bsp;  =E2=80=9CRegenerating=E2=80=9D rather than =
=E2=80=9Cforwarding=E2=80=9D messages means, that the intermediate




















         =
            &n=
bsp;  router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose =
a different structure (e.g., include TLVs




















         =
            &n=
bsp;  in a different order).




















 




















         =
            &n=
bsp;  The proposal from https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00<=
/span>




















         =
            &n=
bsp;  is to add constraints on (i) the set of elements to =
include in a signature and (ii) the




















         =
            &n=
bsp;  order of these elements.




















 




















         =
            &n=
bsp;  One problem with that approach is (i): if an =
extension adds a message TLV, or an 




















         =
            &n=
bsp;  Address TLV, to a message, then that will not be =
=E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.




















         =
            &n=
bsp;  Rather for *each* extension developed, an =E2=80=9Cupdates=
 e2esec=E2=80=9D clause needs to be done.




















 




















         =
            &n=
bsp;  I=E2=80=99d say that this approach would be prone to =
errors =E2=80=94 and add entropy to the process




















         =
            &n=
bsp;  of designing protocol extensions. The alternative, a =
message being generated by the




















         =
            &n=
bsp;  source and *forwarded* (as we do in OLSRv2, for example) =
would allow ICV TLVs 




















         =
            &n=
bsp;  (even, allow reuse of those specified for OLSRv2) for =
covering a message and 




















         =
            &n=
bsp;  extensions.




















 




















         =
            &n=
bsp;  =E2=80=9CBut what about the metrics value which will =
change on each hop=E2=80=9D, you may say?




















         =
            &n=
bsp;  Fortunately, that is relatively easy to handle: simply =
zero out the value of that TLV when




















         =
            &n=
bsp;  generating or verifying the ICV MessageTLV. And use =
Packet-TLVs for hop-by-hop 




















         =
            &n=
bsp;  authentication, if needed (but, see below).




















 




















         =
   o         &=
nbsp;It prevents the use of more =
clever/advanced signature schemes/ICVs




















         =
            &n=
bsp;  Aggregate signature algorithms ( https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)




















         =
            &n=
bsp;  exist, and an interesting use-case can be found in also =
reactive protocols, allowing verifying




















         =
            &n=
bsp;  not =E2=80=9Cjust=E2=80=9D the end points, but also the =
intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D




















         =
            &n=
bsp;  discussed above, or something smarter).




















         =
            &n=
bsp;  Regeneration of messages, rather than forwarding, =
renders that impossible (or, if used,




















         =
            &n=
bsp;  updating to  https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00<=
/span>)




















 




















There are other reasons, but the =
above are those that jump at me as immediate show-stoppers.




















 




















I do honestly not see what =
possible benefit there is from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 =
but I see very clear inconveniences, and security is not the least of =
these. Insisting on =E2=80=9Cregeneration=E2=80=9D
 requires development of =E2=80=9Cnon-general workarounds=E2=80=9D as =
pointed out above.




















 




















Security Considerations




















This is an always thorny subject. =
When OLSRv2 was going through the process we got a thorough education in =
how little we knew about security from the SEC-ADs, and had to spend =
about
 a year or so developing RFC7183. The bottom line is, that this protocol =
needs its =E2=80=9CRFC7183  equivalent=E2=80=9D, either as part of =
the main document, or as an independent document. currently, that is not =
the case.




















 




















A minima, looking at BCP72 and =
BCP107 =E2=80=94 taking inspiration from RFC7183 might be aw good idea, =
as that was the most recent that went through the SEC AD. Regardless of =
how, however,
 a =E2=80=9Cmandatory to implement=E2=80=9D security mechanism most be =
specified (I think the right term was =E2=80=9CMUST implement, SHOULD =
use=E2=80=9D), in sufficient detail to ensure interoperable =
implementations.




















 




















As an example, both [RFC6130] and =
[RFC7181] set out that that:






















 




















      On receiving =
a ... message, a router MUST first check if the




















      message is =
invalid for processing by this router




















 




















and then proceed to give a number =
of conditions that, each, will lead to a rejection of the message as =
"badly formed and therefore invalid for processing=E2=80=9D =E2=80=94 a =
list which RFC7183
 then amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for =
inserting =E2=80=9Crejection=E2=80=9D. Idem for message generation.




















 




















If I was to do RFC7181/RFC6130 =
today, I would include that directly into the protocol specifications. =
It turned out to be more overhead (and slow down publication anyways) to =
do
 it as separate documents.






















 




















Secondly, we need to be a lot =
more rigid in terms of what ICVs, Timestamps, etc. are added/removed, =
and what that brings.




















 




















For example (with the assumption =
that messages are *forwarded* and *not* regenerated), this could be one =
option:




















 




















         =
            &n=
bsp;  o         &nb=
sp;When a RREQ, RREP message is generated, add an ICV Message TLV, which =
is calculated <this way>




















         =
            &n=
bsp;           &nbs=
p;   =E2=80=A6(take inspiration from RFC7183 here)




















 






























...



[Message clipped]  

_______________________________________________

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








 














***************************************************************=
*****

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

=

--Apple-Mail=_47C95A5E-4CFB-456F-98EB-A78611384D3B--


From nobody Mon Apr 25 07:33:09 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 31E9312D0EF for ; Mon, 25 Apr 2016 07:33:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.393
X-Spam-Level: 
X-Spam-Status: No, score=-1.393 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, TRACKER_ID=1.306] 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 U78GueQjShRO for ; Mon, 25 Apr 2016 07:32:58 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 E191D12D5D3 for ; Mon, 25 Apr 2016 07:32:57 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id t10so214758753ywa.0 for ; Mon, 25 Apr 2016 07:32:57 -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=ZDF6JbEo3unLdEU9UrJANYFyYDZydr3Hhrh1q7Z6rbA=; b=JTpin3mWRVJVe9NlRVbzYVjL4vp7Pf/Io431AYzx8upALS6w1nIj8Kt/KyRgr7jlvF 4DseF14dFuNwxihr/iIZCFJELeQJlIrobcsRir2Z9rhIlRqLUU3iTBgtHMqHt1frw2V3 VR4reT6zYwWlmVqhC/vrKoe1r8CQTsclk3vSDWOU7j40/t/9cyaQVptFFtCpenleC+T8 zdxYlYUhE/zIbcu1jaX1WOel1n211zXlY+8mY1oJCphR4kJF6Bih8oaoSuYyCWUhHVrf IZdYJrKYqi27X0Rgq62Ad48lDTpyHCt/a4INSR2WJASVyT9i8Dj6iaWZwJumT+ps3xX/ zoCQ==
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=ZDF6JbEo3unLdEU9UrJANYFyYDZydr3Hhrh1q7Z6rbA=; b=LI+y7ssmy3y1GWUSSO5G+C6Nq4uSs4lTapFJZKZ6JWAmbwgDDmOWk7FuWugxHOCAl/ pjJFmG4APb0Z879zaAsMtiObIkImfjqw/we95Wx8sQSus5NE+rhZ5kRsCj/ZlG6YUYLk q5qH7mK8xHXIjW+xoE2XQX0C2yIGrHqqr6XuePUFN5ccuvLyl3fuiJvmO7ajqTDDb2oJ A9vJv2mofBJVMBkWwWkZebKfyZSEEnfbEw8p5N08o93cPSWq6rZzVavWeAoHSN3+nt0r dpnfWQM6zThRg6UQFW0OGSG9XcIK/R2Hd9oPyC50zudcd5vIfVOaYiDL2EAHpCHrtkWE U+fg==
X-Gm-Message-State: AOPr4FVhCQnxhIm9N+i3biF4SpR7zsflzUKw8sokf8rUbY8mX2eyY/22qZR6YFrypJCoUxIHV9oia83KSzLRNQ==
MIME-Version: 1.0
X-Received: by 10.176.6.38 with SMTP id f35mr15627729uaf.36.1461594776950; Mon, 25 Apr 2016 07:32:56 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Mon, 25 Apr 2016 07:32:56 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>         
Date: Mon, 25 Apr 2016 10:32:56 -0400
Message-ID: 
From: Justin Dean 
To: Thomas Heide Clausen 
Content-Type: multipart/alternative; boundary=94eb2c04796e7c6de20531500d37
Archived-At: 
Cc: Christopher Dearlove , Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 14:33:08 -0000

--94eb2c04796e7c6de20531500d37
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 25, 2016 at 10:28 AM,  wrote:

>
> On 25 Apr 2016, at 16:20, Justin Dean  wrote:
>
> A thought regarding integrity checking.  A possible future "fix" for
> integrity could be done on a "virtual" packet in which known TLVs/values
> along with ordered addresses are uncompressed and then verified.  It coul=
d
> allow extra TLV tagging without modifying the validity of that data.  The
> very big drawback would be the overhead of having to uncompressed
> everything to check the validity.  It's functionally the same as zeroing
> out local (this is my stuff) TLV data vs remote (this is not my stuff) TL=
V
> data.
>
>
> That requires an imposed ordering of addresses, address TLVs, Message
> TLVs, etc., even if only =E2=80=9Cin memory=E2=80=9D, it is something tha=
t everybody should
> be aware of, and doing the same way
>
> o That ordering would have to be specified in this document (no, it would
> not be a =E2=80=9Cfuture fix=E2=80=9D, this is
> a requirement to the base spec, since *not* doing that would mean that
> this =E2=80=9Cfuture fix=E2=80=9D could render
> current implementations non-compliant!)
>
> If you're building the virutal packet you could specify the order there,
the on the wire packet doesn't need to be in that order.


> o While this would be *hard* for the current messages/TLVs, I=E2=80=99d i=
magine
> that it=E2=80=99d make extensions
> impossible (in an interoperable fashion).
>
> Not at all if the integrity check in question only used well known
registred TLVs (i.e. don't change the value of these!) types for building
the virutal packet then you could add whatever other TLV info you wanted.


> o It=E2=80=99d be *exceptionally* heavy for all intermediate routers, wan=
ting to
> verify the integrity of a
> message: to be able to force everybody in a network to =E2=80=9Cunwrap=E2=
=80=9D the
> message into an
> uncompressed form *before* validating its origins is opening up for DoS
> attacks.
>
> I want to do a *minimum* number of operations with a message, *before*
> deciding
> to discard a message as harmful.
>
> This is true enough it'd be hell on processing.

>
> As for the RREP-Ack having a flag vs an address doesn't much bother me as
> either would have to be zeroed out for this type of future integrity
> checking.
>
>
> This is not a question of future integrity checking, but a requirement fo=
r
> the base specification to be able to support.
>
> Thomas
>
>
> Justin
>
> On Mon, Apr 25, 2016 at 9:27 AM, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>> Assuming for the moment that everyone will need an RREP-Ack or won=E2=80=
=99t
>> (let=E2=80=99s come back to that) why do C and B need to put an address =
in as an
>> RREQ-Ack request? Why not a flag, because the address will be included a=
s
>> the IP sending address - and we know 5444 is required to pass that on.
>> (It=E2=80=99s used by NHDP as well.) Then we don=E2=80=99t need to chang=
e the RREP, it will
>> have a flag set or not, and won=E2=80=99t change (in this regard).
>>
>>
>>
>> Now let=E2=80=99s consider do we know whether we can set a fixed flag. F=
irst I=E2=80=99d
>> say there are two cases - you=E2=80=99ve got a firm control on what=E2=
=80=99s going on in
>> your network, or it=E2=80=99s one of unknown parties and behaviour (cons=
istent with
>> specification). In the former case you only want one setting, for exampl=
e
>> no-Ack if running NHDP or your MAC layer tells you about bidirectionalit=
y,
>> Ack otherwise. In the latter case, I think you just always want an Ack. =
So
>> both cases get you to the same place.
>>
>>
>>
>> Should that not be an acceptable argument (though I think it=E2=80=99s g=
ood for
>> where we are - in fact always Ack is close) then at flag is a step bette=
r,
>> it=E2=80=99s a fixed location to change. However it would be better in t=
hat case if
>> the two things to change (metric and ack flag) were together. But that h=
as
>> its own issues, so I won=E2=80=99t go there.
>>
>>
>>
>> *-- *
>>
>>
>>
>>
>> *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
>> *Sent:* 25 April 2016 14:15
>> *To:* Jiazi YI
>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
>> Networks mailing list
>> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>>
>>
>>
>> **** 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
>> .*
>>
>> Hi Jiazi,
>>
>>
>>
>>
>> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI  wrote:
>>
>> Hi,
>>
>>
>>
>> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>> With regard to your validity time point, we here have a tradeoff. If you
>> allow that feature, it significantly impacts on the approach that was
>> coming together on as best you can end to end encryption.
>>
>>
>>
>> So the question is, is this a feature that=E2=80=99s really wanted? Unfo=
rtunately
>> I think we know that the answer to that is, we don=E2=80=99t know becaus=
e we don=E2=80=99t
>> have any experience. My view would be that in the tradeoff of an unteste=
d
>> feature (unless I=E2=80=99m wrong about that) and the security complicat=
ion,
>> security wins and drop the feature. If there is some real requirement, t=
hen
>> there=E2=80=99s a discussion. (Questions like how often the intermediate=
 routers
>> actually have any knowledge - typically links break for unexpected rathe=
r
>> than expected reasons. Andan intermediate router could possibly use a
>> validity time to influence its behaviour.) Note that dropping the abilit=
y
>> of intermediate routers to modify/set still allows validity times per ro=
ute
>> to be set at endpoints.
>>
>>
>>
>> I agree with Chris' concern.
>>
>> The ValidityTime is optional, which makes the integrity protection hard.
>> Furthermore, it gives a potential attack vector: as all the routers in a
>> path will take the shortest validityTime, a compromised router can set t=
he
>> the validityTime to a very short value, which will make the route instal=
led
>> along the path became invalid (very soon).
>>
>>
>>
>> On the other hand, I'm not sure this option will give us much help. Chri=
s
>> mentioned much knowledge intermediate router would have to decide this
>> value (and how much sense the value would make).
>>
>> Another issue is, a route to a destination might be updated by different
>> sources. For example, in the network below:
>>
>>
>>
>> A----B-----C
>>
>>
>>
>> A first establish a route to B with long validity time. Then A initiates
>> a route discovery to C. C tends to set a short validity time, which will
>> make the route between B and A expire earlier than expected.
>>
>> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered o=
r
>> not.
>>
>>
>>
>>
>>
>> Not sure I follow here.
>>
>> Currently, the validity time of the route between A and B would not
>> affected by a short validity time of a route between A and C. Validity
>> times are per-route, and the route A-B and the route A-C are separate.
>>
>> If we switched to a validity time per neighbor (so that we can keep
>> validity time separate from route advertisements) as I mentioned in the
>> email below, then the validity of a route between A and C would be affec=
ted
>> if there was a short validity time between A and B. But, if B will only
>> route for a certain amount of time, then the route between A and C will =
of
>> course be affected. Is it best to know in advance that there's a time
>> limit, or just deal with RERRs when they happen?
>>
>>
>>
>>
>>
>>
>>
>> With regard to the acknowledgements, the problem (with regard to
>> security) comes from trying to do two jobs with the same message - end t=
o
>> end route advertisement and hop by hop acknowledgement. I understand the
>> reasons - saving bytes and message types. (I would have to study the
>> protocol really hard to identify if any message types can be folded
>> together and recognised by content rather than type efficiently. This I =
do
>> not expect to do.) Again a tradeoff. This one is in discussion space,
>> though that needs people who understand both sides of the issue, includi=
ng
>> the details of the bidirectionality mechanism. Of course, as has been sa=
id,
>> we need one of those.
>>
>>
>>
>> I haven't finished my review of the latest draft, and I don't get the
>> necessity of AckReq and the corresponding multicast RREP yet.
>>
>> If possible, this "optional" field should be avoided.
>>
>>
>>
>>
>> To give an overview of AckReq and RREP:
>>
>> Since AODVv2 requires bidirectional links, this is the way to determine
>> if a link is bidirectional.
>>
>> A----B----C
>>
>>
>> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both instal=
l
>> a route to OrigAddr but they dont yet know if it's valid because they do=
nt
>> know if the link to their next hop is available in the reverse direction=
.
>>
>> 2) C creates the RREP. Since it doesnt know if the link to B is
>> bidirectional, it includes the AckReq (an address to indicate that it
>> expects to receive a RREP_Ack from B).
>>
>> 3) B receives the RREP, installs a route to TargAddr and marks it as
>> valid, since it knows the link to C is bidirectional, because the RREQ w=
ent
>> in one direction and the RREP came in the other. B also sends the RREP_A=
ck
>> to C and forwards the RREP to A (and might change the message to indicat=
e
>> its own AckReq - ie that it requires an ack from A).
>>
>> 4) C receives the RREP_Ack from B, and therefore knows that B received
>> the RREP, therefore the link is bidirectional. C can then mark its route=
 to
>> OrigAddr as valid.
>>
>> 5) Similarly, A receives the RREP, installs the route to TargAddr and
>> sends an RREP_Ack to B.
>>
>> 6) B receives the RREP_Ack and marks its route to OrigAddr as valid.
>>
>>
>>
>> Alternatively, in step 2, if C knows the link to B is bidirectional
>> (perhaps from some earlier route discovery), it doesnt need to put the
>> AckReq in the RREP. Then in step 3, since B doesnt know if the link to A=
 is
>> bidirectional, it changes the message to add the AckReq address, in orde=
r
>> to get an RREP_Ack from A.
>>
>> If we want to avoid changing the message, we'll need to look at
>> forwarding the RREP as-is, and creating a second message to solicit an
>> RREP_Ack, in order to verify that the link is bidirectional before marki=
ng
>> the route to OrigAddr as valid.
>>
>> Kind regards,
>>
>> Victoria.
>>
>>
>>
>>
>>
>> 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
>>
>>
>>
>> *From:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
>> *Sent:* 23 April 2016 10:55
>> *To:* Christopher Dearlove
>> *Cc:* ietf@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc
>> Networks mailing list
>>
>>
>> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>>
>>
>>
>> **** 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
>> .*
>>
>> Hi Chris,
>>
>>
>>
>> These have both been in the draft in some form since before I got
>> involved... but I'll do my best to explain.
>>
>>
>>
>> - For Validity Time, its a way to advertise that you would only support
>> the route contained in the message for a certain period of time. The
>> originator might use this, but the draft was written to allow any
>> intermediate node to be able to add it or update it too. The route creat=
ed
>> in the Local Route Set has an expiration time associated with it, based =
on
>> the received validity time.
>>
>> - For the AckReq address, its so that you can add into a RREP a request
>> for an acknowledgement, so that you don't have to have a different messa=
ge
>> type altogether for working out whether links to neighbors are
>> bidirectional, and also, since you only care about bidirectionality on
>> routes that are being set up, you dont need to constantly monitor all
>> neighbors.
>>
>>
>>
>>
>>
>> In order to avoid the potential AckReq-related changes to each message,
>> maybe we do need to introduce a different message specifically for this.=
 We
>> could maybe use RREP_Ack to both request and acknowledge? It means an ex=
tra
>> message of control traffic that needs to be sent, maybe one extra messag=
e
>> per hop on the path of a RREP, but it could still be limited to neighbor=
s
>> which have participated in the route discovery rather than monitoring al=
l
>> neighbors at all times.
>>
>>
>>
>> This message could maybe also include "I'm happy to route anywhere for a
>> certain amount of time", sort of like willingness in OLSR/OLSRv2. So
>> instead of having a validity time per route, its a validity time per
>> neighbor. Then, for RREQ and RREP, only the metric value would change in
>> transit, as discussed. However, that leads to some issues with deciding
>> what a route's expiration time is. You might know how long the next hop
>> router is valid for, but what if a router beyond that, which was also pa=
rt
>> of the route, had a lower validity time? You couldn't determine the real
>> validity time. Do we remove the route expiration time altogether to avoi=
d
>> this issue? In which case, we would have to rely on RERR messages being
>> sent for routes which become invalid when the neighbor's validity time h=
as
>> expired? So neighbor validity time expiration is treated the same as a l=
ink
>> break.
>>
>>
>>
>> What do you think?
>>
>>
>>
>> Kind regards,
>>
>> Victoria.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
>> chris@mnemosyne.demon.co.uk> wrote:
>>
>> Pretty much all of the discussion has been assuming only a metric value
>> change. With multiple things changing many of the ideas go out of the
>> window. That reinforces the point about not making specifications now th=
at
>> might turn out to be wrong for ICVs.
>>
>>
>>
>> Ignoring how this misunderstanding happened, I'll start by asking why.
>> Metric changing I understand. Why the other two? (there's a partial
>> explanation of one). What alternatives have people implemented in
>> comparable protocols?
>>
>> --
>>
>> Christopher Dearlove
>>
>> christopher.dearlove@gmail.com (iPhone)
>>
>> chris@mnemosyne.demon.co.uk (home)
>>
>>
>> On 23 Apr 2016, at 00:26, Victoria Mercieca  wrote=
:
>>
>> Hi all,
>>
>>
>>
>> Continued in this thread because the other one seems to be more about TL=
V
>> types and metric type numbers, whereas this is about
>> regeneration/forwarding.
>>
>>
>>
>> To recap, in the current draft, there are 3 things that might change at
>> each hop:
>> - the metric value (happens in RREQ and RREP),
>> - adding/changing Validity Time using the Validity Time TLV (can happen
>> in RREQ and RREP),
>> - adding an address (and corresponding value in the AddressType TLV to
>> indicate how to interpret the address) to indicate the address from whic=
h
>> an RREP_Ack is expected, to accomplish the bidirectionality check (can
>> happen in RREP).
>>
>> If we define a certain portion of the message as immutable and include
>> the ICV to verify that part, end to end:
>> - The metric value would be excluded from the ICV since it needs changin=
g
>> at each hop.
>> - Would adding a Validity Time TLV at an intermediate hop be acceptable?
>> The whole TLV could be removed in order to calculate the ICV?
>>
>> - Would adding an address cause issues for the ICV, because it's in the
>> address block? Could the rule be "if it contains an AckReq address, remo=
ve
>> it (and the corresponding value in the AddressType TLV), before checking
>> the ICV", is that OK? Or would we need to avoid touching the ICV'ed part=
 of
>> the message altogether, maybe put the AckReq address in a separate Addre=
ss
>> Block, with an extra AddressType TLV following that address block? Is th=
ere
>> a way to accomplish this?
>>
>>
>>
>> Also, to be thorough, do we need to consider RERR messages while we
>> discuss regeneration vs forwarding?
>>
>> - RERR (sent when a link breaks) is a way of saying "I've lost my route
>> so I'm telling others" and "you were my next hop, so now I've also lost =
my
>> route, I'll tell others", etc. It's going to be tailored at each step to
>> include the relevant routes that got deleted, it's not one message being
>> sent end-to-end like RREQ and RREP are.
>>
>> - However, RERR (sent when a source of traffic is sending data on a rout=
e
>> which comes through you, and you want to tell the Packet Source's router=
 to
>> delete the route) could be seen as an end-to-end message which all
>> intermediate routers learn from, similar to RREQ and RREP. It reports on=
e
>> route, and doesn't need changing at intermediate hops, so could be
>> protected with ICV.
>>
>> - Would it be OK to only require a message ICV if a PktSource address wa=
s
>> included, i.e. when the message needs to go via a number of intermediate
>> hops to PktSource's router? All other RERRs are intended to be one-hop
>> messages, which may in turn prompt other one-hop messages, etc..., and a
>> packet ICV might be more appropriate?
>>
>>
>>
>> Kind regards,
>>
>> Victoria.
>>
>>
>>
>> On Thu, Mar 17, 2016 at 5:26 PM,  wrote:
>>
>>
>>
>> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>>
>>
>> Yes, I meant AODVv2, thanks for the catch.
>>
>>
>>
>> So is your (Thomas) proposed base specification a hop count only metric?
>>
>>
>>
>> No, the would be silly as base specification, given that hop count mostl=
y
>> is useless.
>>
>>
>>
>> As base specification I would simply say =E2=80=9CInclude a Metric Type =
Message
>> TLV with a value field, and a 7182 Message TLV & Timestamp=E2=80=9D as w=
e do in
>> OLSRv2 (with the appropriate verbiage as to generation and processing).
>>
>>
>>
>> With the message generated by the originator of the RREQ/RREP and *not*
>> deconstructed/reconstructed/reordered (as is the risk with =E2=80=9Crege=
neration)
>> allows knowing that it would be *only* that metric field being modified
>> (other than hop count/limit) for when eventually writing up the extensio=
n.
>>
>>
>>
>> (Actually doesn=E2=80=99t the current specification only define hop coun=
t, or has
>> that changed in latest draft?)
>>
>>
>>
>> No. That is one of the issues I raise in my original. For some reason, i=
t
>> cites RFC6551, which is a ROLL document and which has in its abstract th=
at:
>>
>>
>>
>>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>>
>>    compared with traditional wired and ad hoc networks that require the
>>
>>    specification of new routing metrics and constraints.
>>
>>
>>
>> I.e. this document cites a metric document which clearly claims to be
>> inapplicable in ad hoc networks. I note that this is another thing I=E2=
=80=99ve
>> raised for years without seeing it attempted resolved.
>>
>>
>>
>> Best,
>>
>>
>>
>> Thomas
>>
>>
>>
>>
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>> ]
>> *Sent:* 17 March 2016 17:10
>> *To:* Dearlove, Christopher (UK)
>> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>>
>>
>>
>> **** 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 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>>
>>
>> OK, so we have a message that mutates by:
>>
>> - Modifying hop count/limit.
>>
>> - Modifying a metric value.
>>
>> Anything else?
>>
>>
>>
>> As mutating (other than hop count/limit) messages aren=E2=80=99t covered=
 by 5444
>> or any derivative document (but only recommended against, not banned) th=
at
>> you may need to make the message otherwise immutable (no deconstruction =
and
>> rebuilding, other than guaranteed unchanging) that would have to be
>> specified by AODVv2. (Easy to say, but needs saying.)
>>
>>
>>
>> With you so far.
>>
>>
>>
>> Then that information is not in a guaranteed fixed location given by a
>> simple offset. So any signature algorithm that finds it and ignores it o=
r
>> aggregates on it is specific to OLSRv2.
>>
>>
>>
>> Surely you mean AODVv2
>>
>>
>>
>> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AODVv2
>> specialised variant. Which is the sort of thing that the message specifi=
c
>> TLV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cbut i=
gnore the value of
>> this specific TLV should it occur=E2=80=9D being in the general space. H=
owever it
>> can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like th=
at TLV,
>> except if an X TLV is present, set its value field to zero=E2=80=9D).
>>
>>
>>
>> Messy, but could work.
>>
>>
>>
>> Not that messy, actually, although clearly not as nice as =E2=80=9Cfixed=
 offset=E2=80=9D.
>>
>>
>>
>> That said, I am arguing for the base spec being:
>>
>>
>>
>>             =E2=80=9Cmake the message otherwise immutable (no deconstruc=
tion and
>> rebuilding, other
>>
>>              than guaranteed unchanging)=E2=80=9D which is afforded by f=
orwarding
>>
>>
>>
>>                                     +
>>
>>
>>
>>             RFC7182 Timestamps and ICVs.
>>
>>
>>
>>                                     +
>>
>>
>>
>>             RFC7183 style text bringing it all together.
>>
>>
>>
>> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would v=
ery be an
>> experimental extension.
>>
>>
>>
>> What I object to is, if the base spec specifically renders such
>> extensions impossible
>>
>>
>>
>>
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *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:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
>> ]
>> *Sent:* 17 March 2016 16:48
>> *To:* Dearlove, Christopher (UK)
>> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
>> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>>
>>
>>
>> **** 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
>> .*
>>
>> Hi all,
>>
>>
>>
>> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com>:
>>
>>
>>
>> Good point about whether you just pass on one cost or a set of costs. As
>> I said, not looked at details - I will, when time permits. One cost is m=
uch
>> easier, and yes, it reduces the fixed size aggregated signatures problem=
 to
>> =E2=80=9Cjust=E2=80=9D one of computational load.
>>
>>
>>
>> For the record, Thomas=E2=80=99 understanding is correct; the cost is on=
e
>> aggregated value.
>>
>>
>>
>> Best regards,
>>
>> Lotte Steenrbink
>>
>>
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>> ]
>> *Sent:* 17 March 2016 16:38
>> *To:* Dearlove, Christopher (UK)
>> *Cc:* Mobile Ad Hoc Networks mailing list
>> *Subject:* Re: Message integrity and message mutability (was RE: [manet]
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>>
>>
>>
>> **** 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 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>>
>>
>> I appreciate Thomas=E2=80=99s comments about the limitations of message
>> regeneration, but I would be a bit less absolute.
>>
>>
>>
>> The issues over end to end authentication and more advanced signatures
>> are valid. I need to read the given reference on aggregate signatures to
>> increase my knowledge (thanks for it), but my understanding of the
>> possibilities in this field may offer a solution to the problem, but wit=
h
>> some other issues (possibly including a new type of TLV).
>>
>>
>>
>> But the hop count/limit point I don=E2=80=99t fully agree with, you can
>> regenerate with an incremented/decremented count/limit, which leaves the
>> ability to prevent messages propagating indefinitely, including expandin=
g
>> ring searches, and retains the ability to use RFC 5497 interval and
>> validity times that might be useful with an expanding ring search (or mi=
ght
>> not).
>>
>>
>>
>> But the key issue is that AODVv2 wants to accumulate metrics. I still
>> haven=E2=80=99t got to the bottom of many details here, but let=E2=80=99=
s for the moment
>> just consider that conceptually.
>>
>>
>>
>> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft attempts=
 to do an end to
>> end of some information, not this information. I=E2=80=99m not sure if t=
hat=E2=80=99s
>> useful (and the specialised format is better avoided if possible). Other
>> approaches are hop by hop (might as well use packet signatures) and shar=
ed
>> key (might as well go hop by hop). Pairwise signatures for each pair of
>> routers I=E2=80=99m discounting as scaling terribly. In the interests of
>> completeness let=E2=80=99s mention not accumulating metrics, which puts =
us back to
>> hop count and that=E2=80=99s not ideal either.
>>
>>
>>
>> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=80=
=99ve seen about
>> aggregating, but that has some issues of its own, even apart from
>> computational load.) I=E2=80=99d love to be proved wrong - someone with =
the perfect
>> solution to come along.
>>
>>
>>
>> Which means that either we make an arbitrary choice - which will be
>> disagreed with, but needs discussing first - or create something flexibl=
e.
>> Unfortunately flexible in that regard constrains in others, e.g. some
>> (many? most?) aggregating signatures need fixed data sizes (which we can=
 do
>> by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but th=
at has a cost too).
>>
>>
>>
>> I have been told by people much more well versed in this than I in
>> cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>>
>>
>>
>> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does t=
hat mean that the
>> message grows as it is being forwarded, and that the recipient of a
>> RREQ/RREP will know the individual costs of each path segment? My
>> understanding is, that the recipient will get =E2=80=9Cthe sum the costs=
 of each
>> path segment=E2=80=9D which should be fitting within a fixed size?
>>
>>
>>
>> Thomas
>>
>>
>>
>>
>>
>>
>>
>> Sorry, no answers, just comments. And I=E2=80=99m not addressing Thomas=
=E2=80=99s later
>> points here.
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *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 *ietf@thomasclausen.org
>> *Sent:* 17 March 2016 16:00
>> *To:* Mobile Ad Hoc Networks mailing list
>> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of big
>> ticket Items
>>
>>
>>
>>
>>
>> **** 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.
>>
>>
>>
>> Dear all,
>>
>>
>>
>> Apologies for not having gotten this done sooner - day-job leaving few
>> spare cycles.
>>
>>
>>
>> I=E2=80=99ve previously offered reviews and comments, and some of those =
have been
>> addressed in the latest I-D =E2=80=94 others have not, but should be. I =
recall that
>> there was some mail attempting to rebut parts of the review, and I will =
dig
>> it out and reply to that.
>>
>>
>>
>> With that being said, I have reviewed the latest version of the document=
,
>> and full details will be forthcoming. There=E2=80=99re a couple of
>> big-ticket/architectural items that I want to address up front, as I
>> believe that before we have those hammered out, it will be useless to go
>> into details. Note, I do not claim that this is an exhaustive list of =
=E2=80=9Cbig
>> ticket items=E2=80=9D, but that=E2=80=99s as far as I have gotten in thi=
nking this through.
>>
>>
>>
>> I also bring these up as they are items that have been brought up
>> repeatedly over the past years, but not resolved nor discussed.
>>
>>
>>
>> *Loops*
>>
>> Just to bring this out: I share Chris=E2=80=99 worry about conflicting a=
nd
>> concurrent statements from the authors on =E2=80=9CThere are no loops po=
ssible=E2=80=9D and
>> =E2=80=9CWe need to fix two situations where loops can occur=E2=80=9D an=
d =E2=80=9Cwe are still
>> investigating some loop conditions=E2=80=9D
>>
>>
>>
>> I particularly worry that this is not a discussion had in public, but
>> apparently in some other forum=E2=80=A6
>>
>>
>>
>>
>>
>> *Intermediate Route Replies, and all of section 10*
>>
>> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=80=
=9D, which is
>> incoherent with the intended status indicated for this document.
>>
>>
>>
>> Specifically, and this is not unrelated to the point about loops above,
>> intermediate RREPs (section 10.3) are a potential source for loops.
>>
>>
>>
>> Expanding Ring Multicast (section 10.1) is not documented in a way that
>> can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=E2=
=80=9D below, it is
>> in the present form of this protocol impossible), etc.
>>
>>
>>
>>
>>
>> *Forwarding-vs-regeneration*
>>
>> Recent exchanges on the list made me understand that protocol control
>> messages are *not* forwarded, but are consumed at each hop, then a new
>> message with (almost-but-not-quite) the same content is generated and
>> transmitted.
>>
>>
>>
>> I have thought some more on this (& read some of the exchanges on the
>> list on this topic by Chris, Ulrich, and others), and I am convinced tha=
t
>> this is not the right way to go, *at least* for the following reasons:
>>
>>
>>
>>
>>
>>             o          *It renders the hop-limit/hop-count fields in the
>> RFC5444 message header useless.*
>>
>>                         This would not be bad if the functionality
>> offered by those fields was not useful
>>
>>                         =E2=80=94 sadly, it is. For example, for scope l=
imited
>> flooding (expanding ring search, and
>>
>>                         such) which may be of interest, and which requir=
e
>> hop-limit.
>>
>>                         A hop-count field may also provide a =E2=80=9Cch=
eap=E2=80=9D (in
>> terms of overhead) additional piece
>>
>>                         of information to use conjunctively with a =E2=
=80=9Creal=E2=80=9D
>> metric.
>>
>>
>>
>>                         The only practical solution would be to
>> re-introduce these functions by way of inserting a
>>
>>                         MessageTLV =E2=80=94 which (i) is not specified =
in this
>> document, and (ii) which would just
>>
>>                         serve to render messages bigger than strictly
>> needed.
>>
>>
>>
>>                         Scope limited flooding  does seem to be a
>> necessary requirement, if for no
>>
>>                         other reason than to prevent information from
>> =E2=80=9Ccirculating forever in the network=E2=80=9D.
>>
>>
>>
>>             o          *It makes end-to-end authentication unnecessarily
>> hard.*
>>
>>                         I think Chris called this out already, but it
>> bears repeating: S generates a message
>>
>>                         (say, a RREQ), and includes an ICV calculated
>> over the content of the message.
>>
>>                         For any recipient to be able to validate the ICV=
,
>> the message has to be exactly
>>
>>                         the same =E2=80=94 not just in content, but in s=
tructure
>> =E2=80=94 as what was generated.
>>
>>
>>
>>                         =E2=80=9CRegenerating=E2=80=9D rather than =E2=
=80=9Cforwarding=E2=80=9D messages
>> means, that the intermediate
>>
>>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ m=
ay chose a
>> different structure (e.g., include TLVs
>>
>>                         in a different order).
>>
>>
>>
>>                         The proposal from
>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>>
>>                         is to add constraints on (i) the set of elements
>> to include in a signature and (ii) the
>>
>>                         order of these elements.
>>
>>
>>
>>                         One problem with that approach is (i): if an
>> extension adds a message TLV, or an
>>
>>                         Address TLV, to a message, then that will not be
>> =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>>
>>                         Rather for *each* extension developed, an
>> =E2=80=9Cupdates e2esec=E2=80=9D clause needs to be done.
>>
>>
>>
>>                         I=E2=80=99d say that this approach would be pron=
e to
>> errors =E2=80=94 and add entropy to the process
>>
>>                         of designing protocol extensions. The
>> alternative, a message being generated by the
>>
>>                         source and *forwarded* (as we do in OLSRv2, for
>> example) would allow ICV TLVs
>>
>>                         (even, allow reuse of those specified for OLSRv2=
)
>> for covering a message and
>>
>>                         extensions.
>>
>>
>>
>>                         =E2=80=9CBut what about the metrics value which =
will
>> change on each hop=E2=80=9D, you may say?
>>
>>                         Fortunately, that is relatively easy to handle:
>> simply zero out the value of that TLV when
>>
>>                         generating or verifying the ICV MessageTLV. And
>> use Packet-TLVs for hop-by-hop
>>
>>                         authentication, if needed (but, see below).
>>
>>
>>
>>             o          *It prevents the use of more clever/advanced
>> signature schemes/ICVs*
>>
>>                         Aggregate signature algorithms (
>> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>>
>>                         exist, and an interesting use-case can be found
>> in also reactive protocols, allowing verifying
>>
>>                         not =E2=80=9Cjust=E2=80=9D the end points, but a=
lso the
>> intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D
>>
>>                         discussed above, or something smarter).
>>
>>                         Regeneration of messages, rather than forwarding=
,
>> renders that impossible (or, if used,
>>
>>                         updating to
>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>>
>>
>>
>> There are other reasons, but the above are those that jump at me as
>> immediate show-stoppers.
>>
>>
>>
>> I do honestly not see what possible benefit there is from =E2=80=9Cregen=
eration=E2=80=9D
>> =E2=80=94 but I see very clear inconveniences, and security is not the l=
east of
>> these. Insisting on =E2=80=9Cregeneration=E2=80=9D requires development =
of =E2=80=9Cnon-general
>> workarounds=E2=80=9D as pointed out above.
>>
>>
>>
>> *Security Considerations*
>>
>> This is an always thorny subject. When OLSRv2 was going through the
>> process we got a thorough education in how little we knew about security
>> from the SEC-ADs, and had to spend about a year or so developing RFC7183=
.
>> The bottom line is, that this protocol needs its =E2=80=9CRFC7183  equiv=
alent=E2=80=9D,
>> either as part of the main document, or as an independent document.
>> currently, that is not the case.
>>
>>
>>
>> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration from =
RFC7183
>> might be aw good idea, as that was the most recent that went through the
>> SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to implement=E2=
=80=9D security
>> mechanism most be specified (I think the right term was =E2=80=9CMUST im=
plement,
>> SHOULD use=E2=80=9D), in sufficient detail to ensure interoperable imple=
mentations.
>>
>>
>>
>> As an example, both [RFC6130] and [RFC7181] set out that that:
>>
>>
>>
>>       On receiving a ... message, a router MUST first check if the
>>
>>       message is invalid for processing by this router
>>
>>
>>
>> and then proceed to give a number of conditions that, each, will lead to
>> a rejection of the message as "badly formed and therefore invalid for
>> processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That ga=
ve a =E2=80=9Chook=E2=80=9D for
>> RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message gene=
ration.
>>
>>
>>
>> If I was to do RFC7181/RFC6130 today, I would include that directly into
>> the protocol specifications. It turned out to be more overhead (and slow
>> down publication anyways) to do it as separate documents.
>>
>>
>>
>> Secondly, we need to be a lot more rigid in terms of what ICVs,
>> Timestamps, etc. are added/removed, and what that brings.
>>
>>
>>
>> For example (with the assumption that messages are *forwarded* and *not*
>> regenerated), this could be one option:
>>
>>
>>
>>                         o          When a RREQ, RREP message is
>> generated, add an ICV Message TLV, which is calculated 
>>
>>                                      =E2=80=A6(take inspiration from RFC=
7183 here)
>>
>>
>>
>> ...
>>
>> [Message clipped]
>> _______________________________________________
>> 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
>>
>>
>>
>> ********************************************************************
>> 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
>
>
>

--94eb2c04796e7c6de20531500d37
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Apr 25, 2016 at 10:28 AM,  <ietf@thomasclausen.org>=
; wrote:

On 25 Apr 2016, at 16:20=
, Justin Dean <bebemaster@gmail.com> wrote:

A thoug=
ht regarding integrity checking.=C2=A0 A possible future "fix" fo=
r integrity could be done on a "virtual" packet in which known TL=
Vs/values along with ordered addresses are uncompressed and then verified.=
=C2=A0 It could allow extra TLV tagging without modifying the validity of t=
hat data.=C2=A0 The very big drawback would be the overhead of having to un=
compressed everything to check the validity.=C2=A0 It's functionally th=
e same as zeroing out local (this is my stuff) TLV data vs remote (this is =
not my stuff) TLV data. =C2=A0

T=
hat requires an imposed ordering of addresses, address TLVs, Message TLVs, =
etc., even if only =E2=80=9Cin memory=E2=80=9D, it is something that everyb=
ody should be aware of, and doing the same way

	o	That ordering would have to be specified in this document (no,=
 it would not be a =E2=80=9Cfuture fix=E2=80=9D, this is=C2=A0
		a requirement to the base spec,=
 since *not* doing that would mean that this =E2=80=9Cfuture fix=E2=80=9D c=
ould render
		current=
 implementations non-compliant!)

If you're building the virutal packet you could specify the order the=
re, the on the wire packet doesn't need to be in that order.
=
=C2=A0
	o	While this would be *hard* for the curr=
ent messages/TLVs, I=E2=80=99d imagine that it=E2=80=99d make extensions
		impossible (in an int=
eroperable fashion).

Not at all=
 if the integrity check in question only used well known registred TLVs (i.=
e. don't change the value of these!) types for building the virutal pac=
ket then you could add whatever other TLV info you wanted.
=C2=A0=

	o	It=E2=80=99d be *exceptionally* heavy for all=
 intermediate routers, wanting to verify the integrity of a=C2=A0
		message: to be able to force=
 everybody in a network to =E2=80=9Cunwrap=E2=80=9D the message into an=C2=
=A0
		uncompressed fo=
rm *before* validating its origins is opening up for DoS attacks.=C2=A0

		I want =
to do a *minimum* number of operations with a message, *before* deciding=C2=
=A0
		to discard a me=
ssage as harmful.

This is true =
enough it'd be hell on processing.=C2=A0

As for the RREP-Ack having a flag vs an =
address doesn't much bother me as either would have to be zeroed out fo=
r this type of future integrity checking.
=

This is not a question of future integrity checking, but a requir=
ement for the base specification to be able to support.=C2=A0
Thomas


<=
div>
Justin

On Mon, Apr 25, 2016 at 9:27 AM, Dearlove, Christopher (UK=
) <chris.dearlove@baesystems.com> wrote:









Assuming for the mom=
ent that everyone will need an RREP-Ack or won=E2=80=99t (let=E2=80=99s com=
e back to that) why do C and B need to put an address in as an RREQ-Ack req=
uest?
 Why not a flag, because the address will be included as the IP sending add=
ress - and we know 5444 is required to pass that on. (It=E2=80=99s used by =
NHDP as well.) Then we don=E2=80=99t need to change the RREP, it will have =
a flag set or not, and won=E2=80=99t change (in this regard).=

=C2=A0<=
u>
Now let=
=E2=80=99s consider do we know whether we can set a fixed flag. First I=E2=
=80=99d say there are two cases - you=E2=80=99ve got a firm control on what=
=E2=80=99s going on in your network,
 or it=E2=80=99s one of unknown parties and behaviour (consistent with spec=
ification). In the former case you only want one setting, for example no-Ac=
k if running NHDP or your MAC layer tells you about bidirectionality, Ack o=
therwise. In the latter case, I think you
 just always want an Ack. So both cases get you to the same place.
=
=C2=A0
S=
hould that not be an acceptable argument (though I think it=E2=80=99s good =
for where we are - in fact always Ack is close) then at flag is a step bett=
er, it=E2=80=99s a fixed
 location to change. However it would be better in that case if the two thi=
ngs to change (metric and ack flag) were together. But that has its own iss=
ues, so I won=E2=80=99t go there.
=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 Intelligence=
 Limited

Registered in England & Wales No: 01337451
R=
egistered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
=
=C2=A0
From: Victoria Mercieca [mailto:vmercieca0@gmail.com=
]


Sent: 25 April 2016 14:15

To: Jiazi YI

Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc =
Networks mailing list

Subject: Re: [manet] Message integrity and message mutability (was R=
E: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)=

=C2=A0


=C2=A0


*** WARNING ***





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.=







Hi Jiazi,








=C2=A0


On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <<=
a href=3D"mailto:ietf@jiaziyi.com" target=3D"_blank">ietf@jiaziyi.com&g=
t; wrote:


Hi,=C2=A0


=C2=A0


On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Chr=
istopher (UK) <chris.dearlove@baesystems.com> wrote:




With regard to your =
validity time point, we here have a tradeoff. If you allow that feature, it=
 significantly
 impacts on the approach that was coming together on as best you can end to=
 end encryption.
=C2=A0
So the question is, is this a feature that=E2=80=99s =
really wanted? Unfortunately I think we know that the
 answer to that is, we don=E2=80=99t know because we don=E2=80=99t have any=
 experience. My view would be that in the tradeoff of an untested feature (=
unless I=E2=80=99m wrong about that) and the security complication, securit=
y wins and drop the feature. If there is some real requirement,
 then there=E2=80=99s a discussion. (Questions like how often the intermedi=
ate routers actually have any knowledge - typically links break for unexpec=
ted rather than expected reasons. Andan intermediate router could possibly =
use a validity time to influence its behaviour.)
 Note that dropping the ability of intermediate routers to modify/set still=
 allows validity times per route to be set at endpoints.






=C2=A0




I agree with Chris' concern.<=
/p>



The ValidityTime is optional, which makes the i=
ntegrity protection hard. Furthermore, it gives a potential attack vector: =
as all the routers in a path will take the shortest validityTime, a comprom=
ised router can set the the validityTime
 to a very short value, which will make the route installed along the path =
became invalid (very soon).=C2=A0




=C2=A0




On the other hand, I'm not sure this option=
 will give us much help. Chris mentioned much knowledge intermediate router=
 would have to decide this value (and how much sense the value would make).=
=C2=A0




Another issue is, a route to a destination migh=
t be updated by different sources. For example, in the network below:




=C2=A0




A----B-----C




=C2=A0




A first establish a route to B with long validi=
ty time. Then A initiates a route discovery to C. C tends to set a short va=
lidity time, which will make the route between B and A expire earlier than =
expected.=C2=A0




Is this a problem? Maybe yes, maybe no -- I'=
;m not sure it's considered or not.=C2=A0




=C2=A0










=C2=A0




Not sure I follo=
w here.




Currently, the v=
alidity time of the route between A and B would not affected by a short val=
idity time of a route between A and C. Validity times are per-route, and th=
e route A-B and the route A-C are separate.




If we switched to a validity time per neighbor =
(so that we can keep validity time separate from route advertisements) as I=
 mentioned in the email below, then the validity of a route between A and C=
 would be affected if there was a short
 validity time between A and B. But, if B will only route for a certain amo=
unt of time, then the route between A and C will of course be affected. Is =
it best to know in advance that there's a time limit, or just deal with=
 RERRs when they happen?




=C2=A0=





=C2=A0
















=C2=A0=

With regard to=
 the acknowledgements, the problem (with regard to security) comes from try=
ing to do
 two jobs with the same message - end to end route advertisement and hop by=
 hop acknowledgement. I understand the reasons - saving bytes and message t=
ypes. (I would have to study the protocol really hard to identify if any me=
ssage types can be folded together
 and recognised by content rather than type efficiently. This I do not expe=
ct to do.) Again a tradeoff. This one is in discussion space, though that n=
eeds people who understand both sides of the issue, including the details o=
f the bidirectionality mechanism.
 Of course, as has been said, we need one of those.







=C2=A0




I haven't finished my review of the latest =
draft, and I don't get the necessity of AckReq and the corresponding mu=
lticast RREP yet.=C2=A0




If possible, this "optional" field sh=
ould be avoided.=C2=A0




=C2=A0














To give an overview of AckReq and RREP:




Since AODVv2 req=
uires bidirectional links, this is the way to determine if a link is bidire=
ctional.




A----B----C






1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install a=
 route to OrigAddr but they dont yet know if it's valid because they do=
nt know if the link to their next hop is available in the reverse direction=
.




2) C creates the RREP. Since it doesnt know if =
the link to B is bidirectional, it includes the AckReq (an address to indic=
ate that it expects to receive a RREP_Ack from B).




3) B receives the RREP, installs a route to Tar=
gAddr and marks it as valid, since it knows the link to C is bidirectional,=
 because the RREQ went in one direction and the RREP came in the other. B a=
lso sends the RREP_Ack to C and forwards
 the RREP to A (and might change the message to indicate its own AckReq - i=
e that it requires an ack from A).




4) C receives the RREP_Ack from B, and therefor=
e knows that B received the RREP, therefore the link is bidirectional. C ca=
n then mark its route to OrigAddr as valid.




5) Similarly, A receives the RREP, installs the=
 route to TargAddr and sends an RREP_Ack to B.




6) B receives the RREP_Ack and marks its route =
to OrigAddr as valid.




=C2=A0




Alternatively, i=
n step 2, if C knows the link to B is bidirectional (perhaps from some earl=
ier route discovery), it doesnt need to put the AckReq in the RREP. Then in=
 step 3, since B doesnt know if the link
 to A is bidirectional, it changes the message to add the AckReq address, i=
n order to get an RREP_Ack from A.




If we want to av=
oid changing the message, we'll need to look at forwarding the RREP as-=
is, and creating a second message to solicit an RREP_Ack, in order to verif=
y that the link is bidirectional before marking
 the route to OrigAddr as valid. 




Kind regards,




Victoria.




=C2=A0=





=C2=A0












regards




=C2=A0




Jiazi




=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 Intelligence=
 Limited

Registered in England & Wales No: 01337451
R=
egistered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
=C2=A0
From: Victoria
 Mercieca [mailto:vmercieca0@gmail.com]


Sent: 23 April 2016 10:55

To: Christopher Dearlove

Cc: ietf=
@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc Networks =
mailing list






Subject: Re: [manet] Message integrity and message mutability (was R=
E: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)=









=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.






Hi Chris,


=C2=A0




These have both been in the draft in some form =
since before I got involved... but I'll do my best to explain.


=C2=A0




- For Validity Time, its a way to advertise tha=
t you would only support the route contained in the message for a certain p=
eriod of time. The originator might use this, but the draft
 was written to allow any intermediate node to be able to add it or update =
it too. The route created in the Local Route Set has an expiration time ass=
ociated with it, based on the received validity time.




- For the AckReq address, its so that you can a=
dd into a RREP a request for an acknowledgement, so that you don't have=
 to have a different message type altogether for working out
 whether links to neighbors are bidirectional, and also, since you only car=
e about bidirectionality on routes that are being set up, you dont need to =
constantly monitor all neighbors.




=C2=A0




=C2=A0




In order to avoid the potential AckReq-related =
changes to each message, maybe we do need to introduce a different message =
specifically for this. We could maybe use RREP_Ack to both
 request and acknowledge? It means an extra message of control traffic that=
 needs to be sent, maybe one extra message per hop on the path of a RREP, b=
ut it could still be limited to neighbors which have participated in the ro=
ute discovery rather than monitoring
 all neighbors at all times.=C2=A0




=C2=A0




This message could maybe also include "I&#=
39;m happy to route anywhere for a certain amount of time", sort of li=
ke willingness in OLSR/OLSRv2. So instead of having a validity time per
 route, its a validity time per neighbor. Then, for RREQ and RREP, only the=
 metric value would change in transit, as discussed. However, that leads to=
 some issues with deciding what a route's expiration time is. You might=
 know how long the next hop router is
 valid for, but what if a router beyond that, which was also part of the ro=
ute, had a lower validity time? You couldn't determine the real validit=
y time. Do we remove the route expiration time altogether to avoid this iss=
ue? In which case, we would have to
 rely on RERR messages being sent for routes which become invalid when the =
neighbor's validity time has expired? So neighbor validity time expirat=
ion is treated the same as a link break.




=C2=A0




What do you think?




=C2=A0




Kind regards,




Victoria.




=C2=A0




=C2=A0




=C2=A0




=C2=A0




=C2=A0






=C2=A0


On Sat, Apr 23, 2016 at 1:09 AM, Christopher De=
arlove <chris@mnemosyne.demon.co.uk> wrote:




Pretty much all of the discussion has been assu=
ming only a metric value change. With multiple things changing many of the =
ideas go out of the window. That reinforces the point about
 not making specifications now that might turn out to be wrong for ICVs.=





=C2=A0




Ignoring how this misunderstanding happened, I&=
#39;ll start by asking why. Metric changing I understand. Why the other two=
? (there's a partial explanation of one). What alternatives
 have people implemented in comparable protocols?



-- =C2=A0


Christopher Dearlove










On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmail.com> wrote:














Hi all,




=C2=A0




Continued in this thread because the other one =
seems to be more about TLV types and metric type numbers, whereas this is a=
bout regeneration/forwarding.




=C2=A0




To recap, in the current draft, there are 3 thi=
ngs that might change at each hop:


- the metric value (happens in RREQ and RREP), 

- adding/changing Validity Time using the Validity Time TLV (can happen in =
RREQ and RREP),


- adding an address (and corresponding value in the AddressType TLV to indi=
cate how to interpret the address) to indicate the address from which an RR=
EP_Ack is expected, to accomplish the bidirectionality check (can happen in=
 RREP).



If we define=C2=A0a certain portion of the message as immutable and include=
 the ICV to verify that part, end to end:


- The metric value would be excluded from the ICV since it needs changing a=
t each hop.=C2=A0

- Would adding a Validity Time TLV at an intermediate hop be acceptable? Th=
e whole TLV could be removed in order to calculate the ICV?

- Would adding an address cause issues for the=
 ICV, because it's in the address block? Could the rule be "if it =
contains an AckReq address, remove it (and the corresponding value
 in the AddressType TLV), before checking the ICV", is that OK? Or wou=
ld we need to avoid touching the ICV'ed part of the message altogether,=
 maybe put the AckReq address in a separate Address Block, with an extra Ad=
dressType TLV following that address block?
 Is there a way to accomplish this?




=C2=A0




Also, to be thorough, do we need to consider RE=
RR messages while we discuss regeneration vs forwarding?=C2=A0




- RERR (sent when a link breaks) is a way of sa=
ying "I've lost my route so I'm telling others" and "=
;you were my next hop, so=C2=A0now=C2=A0I've also lost my route, I'=
ll tell others", etc.
 It's going to be tailored at each step to include the relevant routes =
that got deleted, it's not one message being sent end-to-end like RREQ =
and RREP are.=C2=A0




- However, RERR (sent when a source of traffic =
is sending data on a route which comes through you, and you want to tell th=
e Packet Source's router to delete the route) could be
 seen as an end-to-end message which all intermediate routers learn from, s=
imilar to RREQ and RREP. It reports one route, and doesn't need changin=
g at intermediate hops, so could be protected with ICV.




- Would it be OK to only require a message ICV =
if a PktSource address was included, i.e. when the message needs to go via =
a number of intermediate hops to PktSource's router? All
 other RERRs are intended to be one-hop messages, which may in turn prompt =
other one-hop messages, etc..., and a packet ICV might be more appropriate?=





=C2=A0


Kind regards,


Victoria.




=C2=A0


On Thu, Mar 17, 2016 at 5:26 PM, <ietf@thomasclausen.org> wrote:


=C2=A0






=C2=A0






Yes, I meant AODVv2,=
 thanks for the catch.




=C2=A0=





So is your (Thomas) =
proposed base specification a hop count only metric?









=C2=A0


No, the would be silly as base specification, =
given that hop count mostly is useless.




=C2=A0




As base specification I would simply say =E2=80=
=9CInclude a Metric Type Message TLV with a value field, and a 7182 Message=
 TLV & Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verb=
iage
 as to generation and processing).=C2=A0




=C2=A0




With the message generated by the originator of=
 the RREQ/RREP and *not* deconstructed/reconstructed/reordered (as is the r=
isk with =E2=80=9Cregeneration) allows knowing that it would be
 *only* that metric field being modified (other than hop count/limit) for w=
hen eventually writing up the extension.




=C2=A0=











(Actually doesn=E2=
=80=99t the current specification only define hop count, or has that change=
d in latest
 draft?)








=C2=A0


No. That is one of the issues I raise in my or=
iginal. For some reason, it cites RFC6551, which is a ROLL document and whi=
ch has in its abstract that:




=C2=A0






=C2=A0=C2=A0 Low-Power and Lossy Networks (LLNs) have unique character=
istics


=C2=A0=C2=A0 compared with traditional wired and ad hoc networks that =
require the


=C2=A0=C2=A0 specification of new routing metrics and constraints. =



=C2=A0




I.e. this document cites a metric document whic=
h clearly claims to be inapplicable in ad hoc networks. I note that this is=
 another thing I=E2=80=99ve raised for years without seeing it
 attempted resolved.




=C2=A0




Best,




=C2=A0




Thomas




=C2=A0




=C2=A0








=C2=A0=





--
Christopher Dearlove<=
br>
Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44 (0)12=
45 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.com



BAE Systems Applied Intelligence, Chelmsford=
 Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.

www.baesystems.com/ai


BAE Systems Applied Int=
elligence Limited

Registered in England & Wales No: 01337451


Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7Y=
P




=C2=A0=









From:<=
span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"=
;,"sans-serif"">=C2=A0ietf@thomasclausen.org=
=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0
Sent:=C2=A017 March 2016 17:10

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Lotte Steenbrink; Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)








=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.






=C2=A0










On 17 Mar 2016, at 18:04, Dearlove, Christopher=
 (UK) <chris.dearlove@baesystems.com>
 wrote:






=C2=A0








OK, so we have a mes=
sage that mutates by:








- Modifying hop coun=
t/limit.








- Modifying a metric=
 value.








Anything else?








=C2=A0=









As mutating (other t=
han hop count/limit) messages aren=E2=80=99t covered by 5444 or any derivat=
ive document
 (but only recommended against, not banned) that you may need to make the m=
essage otherwise immutable (no deconstruction and rebuilding, other than gu=
aranteed unchanging) that would have to be specified by AODVv2. (Easy to sa=
y, but needs saying.)












=C2=A0






With you so far.








=C2=A0=







Then that informatio=
n is not in a guaranteed fixed location given by a simple offset. So any si=
gnature
 algorithm that finds it and ignores it or aggregates on it is specific to =
OLSRv2.








=C2=A0






Surely you mean AODVv2








=C2=A0=







So standard 7182 ICV=
s don=E2=80=99t do the job, you would need an AODVv2 specialised variant. W=
hich is the
 sort of thing that the message specific TLV space is there for, I=E2=80=99=
d be strongly against a =E2=80=9Cbut ignore the value of this specific TLV =
should it occur=E2=80=9D being in the general space. However it can easily =
be defined by reference to 7182 (=E2=80=9Cthis TLV is like that
 TLV, except if an X TLV is present, set its value field to zero=E2=80=9D).=









=C2=A0=









Messy, but could wor=
k.








=C2=A0






Not that messy, actually, although clearly not =
as nice as =E2=80=9Cfixed offset=E2=80=9D.








=C2=A0








That said, I am arguing for the base spec being=
:








=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=E2=80=9Cmake the message otherwise immutable (n=
o deconstruction and rebuilding, other=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=A0than guaranteed unchanging)=E2=80=9D which=
 is afforded by forwarding








=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0RFC7182 Timestamps and ICVs.








=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0RFC7183 style text bringing it all together.<=
/u>








=C2=A0








The =E2=80=9Caggregated signatures around mutab=
le field=E2=80=9D would very be an experimental extension.







=C2=A0








What I object to is, if the base spec specifica=
lly renders such extensions impossible








=C2=A0








=C2=A0=







=C2=A0=







--
Christopher Dearlove<=
br>
Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44 (0)12=
45 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.com



BAE Systems Applied Intelligence, Chelmsford=
 Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.

www.baesystems.com/ai




BAE Systems Applied Int=
elligence Limited

Registered in England & Wales No: 01337451




Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7Y=
P






=C2=A0=













From:<=
span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"=
;,"sans-serif"">=C2=A0Lotte
 Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]=C2=A0

Sent:=C2=A017 March 2016 16:48

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0ietf@thomasclausen.org; Mobile Ad =
Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)












=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.








Hi all,










=C2=A0














Am 17.03.2016 um 17:44 schrieb Dearlove, Christ=
opher (UK) <chris.dearlove@baesystems.com>:










=C2=A0












Good point about whe=
ther you just pass on one cost or a set of costs. As I said, not looked at =
details
 - I will, when time permits. One cost is much easier, and yes, it reduces =
the fixed size aggregated signatures problem to =E2=80=9Cjust=E2=80=9D one =
of computational load.
















=C2=A0












For the record, Thomas=E2=80=99 understanding i=
s correct; the cost is one aggregated value.=C2=A0












=C2=A0












Best regards,=C2=A0












Lotte Steenrbink










=C2=A0=













=C2=A0=









--
Christopher Dearlove<=
br>
Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44 (0)12=
45 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.com



BAE Systems Applied Intelligence, Chelmsford=
 Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.

www.baesystems.com/ai






BAE Systems Applied Int=
elligence Limited

Registered in England & Wales No: 01337451






Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7Y=
P








=C2=A0=

















From:<=
span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"=
;,"sans-serif"">=C2=A0ietf@thomasclausen.org=
=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0
Sent:=C2=A017 March 2016 16:38

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: Message integrity and message mutability (was RE: =
[manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
















=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.










=C2=A0


















On 17 Mar 2016, at 17:30, Dearlove, Christopher=
 (UK) <chris.dearlove@baesystems.com>
 wrote:














=C2=A0
















I appreciate Thomas=
=E2=80=99s comments about the limitations of message regeneration, but I wo=
uld be a bit
 less absolute.
















=C2=A0=

















The issues over end =
to end authentication and more advanced signatures are valid. I need to rea=
d
 the given reference on aggregate signatures to increase my knowledge (than=
ks for it), but my understanding of the possibilities in this field may off=
er a solution to the problem, but with some other issues (possibly includin=
g a new type of TLV).
















=C2=A0=

















But the hop count/li=
mit point I don=E2=80=99t fully agree with, you can regenerate with an incr=
emented/decremented
 count/limit, which leaves the ability to prevent messages propagating inde=
finitely, including expanding ring searches, and retains the ability to use=
 RFC 5497 interval and validity times that might be useful with an expandin=
g ring search (or might not).
















=C2=A0=

















But the key issue is=
 that AODVv2 wants to accumulate metrics. I still haven=E2=80=99t got to th=
e bottom of
 many details here, but let=E2=80=99s for the moment just consider that con=
ceptually.
















=C2=A0=

















It=E2=80=99s hard to=
 handle end to end. Charlie=E2=80=99s draft attempts to do an end to end of=
 some information,
 not this information. I=E2=80=99m not sure if that=E2=80=99s useful (and t=
he specialised format is better avoided if possible). Other approaches are =
hop by hop (might as well use packet signatures) and shared key (might as w=
ell go hop by hop). Pairwise signatures for each
 pair of routers I=E2=80=99m discounting as scaling terribly. In the intere=
sts of completeness let=E2=80=99s mention not accumulating metrics, which p=
uts us back to hop count and that=E2=80=99s not ideal either.=

















=C2=A0=

















I don=E2=80=99t thin=
k there is an ideal solution. (I like ideas I=E2=80=99ve seen about aggrega=
ting, but that has
 some issues of its own, even apart from computational load.) I=E2=80=99d l=
ove to be proved wrong - someone with the perfect solution to come along.
















=C2=A0=

















Which means that eit=
her we make an arbitrary choice - which will be disagreed with, but needs d=
iscussing
 first - or create something flexible. Unfortunately flexible in that regar=
d constrains in others, e.g. some (many? most?) aggregating signatures need=
 fixed data sizes (which we can do by defining a TLV that =E2=80=9Cfills up=
=E2=80=9D with hop count, but that has a cost too).



















=C2=A0














I have been told by people much more well verse=
d in this than I in cryptology, that the correct answer is =E2=80=9Csome=E2=
=80=9D.
















=C2=A0
















That said, "AODVv2 wants to accumulate met=
rics=E2=80=9D =E2=80=94 does that mean that the message grows as it is bein=
g forwarded, and that the recipient of a RREQ/RREP will know the individual
 costs of each path segment? My understanding is, that the recipient will g=
et =E2=80=9Cthe sum the costs of each path segment=E2=80=9D which should be=
 fitting within a fixed size?
















=C2=A0
















Thomas
















=C2=A0





































=C2=A0=

















Sorry, no answers, j=
ust comments. And I=E2=80=99m not addressing Thomas=E2=80=99s later points =
here.
















=C2=A0=











--
Christopher Dearlove<=
br>
Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44 (0)12=
45 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.com



BAE Systems Applied Intelligence, Chelmsford=
 Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.

www.baesystems.com/ai








BAE Systems Applied Int=
elligence Limited

Registered in England & Wales No: 01337451








Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7Y=
P










=C2=A0=





















From:<=
span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"=
;,"sans-serif"">=C2=A0manet
 [mailto:manet-bounces@ietf.org]=C2=A0On Beha=
lf Of=C2=A0=
ietf@thomasclausen.org

Sent:=C2=A017 March 2016 16:00

To:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0[manet] draft-ietf-manet-aodvv2-13 review - a couple o=
f big ticket Items




















=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.









***=
=C2=A0WARNING=C2=A0***

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










=C2=A0


















Dear all,


















=C2=A0




















Apologies for not having gotten this done soone=
r - day-job leaving few spare cycles.




















=C2=A0




















I=E2=80=99ve previously offered reviews and com=
ments, and some of those have been addressed in the latest I-D =E2=80=94 ot=
hers have not, but should be. I recall that there was some mail attempting
 to rebut parts of the review, and I will dig it out and reply to that.<=
/u>




















=C2=A0




















With that being said, I have reviewed the lates=
t version of the document, and full details will be forthcoming. There=E2=
=80=99re a couple of big-ticket/architectural items that I want to
 address up front, as I believe that before we have those hammered out, it =
will be useless to go into details. Note, I do not claim that this is an ex=
haustive list of =E2=80=9Cbig ticket items=E2=80=9D, but that=E2=80=99s as =
far as I have gotten in thinking this through.




















=C2=A0




















I also bring these up as they are items that ha=
ve been brought up repeatedly over the past years, but not resolved nor dis=
cussed.




















=C2=A0




















Loops




















Just to bring this out: I share Chris=E2=80=99 =
worry about conflicting and concurrent statements from the authors on =E2=
=80=9CThere are no loops possible=E2=80=9D and =E2=80=9CWe need to fix two =
situations where
 loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating some loop=
 conditions=E2=80=9D




















=C2=A0




















I particularly worry that this is not a discuss=
ion had in public, but apparently in some other forum=E2=80=A6




















=C2=A0




















=C2=A0






















Intermediate Route Replies, and all of se=
ction 10




















Section 10 contains a set of =E2=80=9Cvaguely s=
pecified extensions=E2=80=9D, which is incoherent with the intended status =
indicated for this document.=C2=A0




















=C2=A0




















Specifically, and this is not unrelated to the =
point about loops above, intermediate RREPs (section 10.3) are a potential =
source for loops.




















=C2=A0




















Expanding Ring Multicast (section 10.1) is not =
documented in a way that can be implemented (and also, see =E2=80=9CForward=
ing-vs-regeneration=E2=80=9D below, it is in the present form of this proto=
col
 impossible), etc.






















=C2=A0




















=C2=A0




















Forwarding-vs-regeneration=





















Recent exchanges on the list made me understand=
 that protocol control messages are *not* forwarded, but are consumed at ea=
ch hop, then a new message with (almost-but-not-quite)
 the same content is generated and transmitted.




















=C2=A0




















I have thought some more on this (& read so=
me of the exchanges on the list on this topic by Chris, Ulrich, and others)=
, and I am convinced that this is not the right way to go,=C2=A0at
 least=C2=A0for the following reasons:




















=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0It renders the hop-limit/hop-count fields in the RFC5444 =
message header useless.




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0This would not be bad if the functionality offered =
by those fields was not useful




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=94 sadly, it is. For example, for scope limi=
ted flooding (expanding ring search, and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0such) which may be of interest, and which require h=
op-limit.=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0A hop-count field may also provide a =E2=80=9Ccheap=
=E2=80=9D (in terms of overhead) additional piece




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0of information to use conjunctively with a =E2=80=
=9Creal=E2=80=9D metric.




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0The only practical solution would be to re-introduc=
e these functions by way of inserting a




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0MessageTLV =E2=80=94 which (i) is not specified in =
this document, and (ii) which would just




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0serve to render messages bigger than strictly neede=
d.




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0Scope limited flooding =C2=A0does seem to be a nece=
ssary requirement, if for no




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0other reason than to prevent information from =E2=
=80=9Ccirculating forever in the network=E2=80=9D.




















=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0It makes end-to-end authentication unnecessarily hard.=





















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0I think Chris called this out already, but it bears=
 repeating: S generates a message=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0(say, a RREQ), and includes an ICV calculated over =
the content of the message.




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0For any recipient to be able to validate the ICV, t=
he message has to be exactly




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0the same =E2=80=94 not just in content, but in stru=
cture =E2=80=94 as what was generated.




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9CRegenerating=E2=80=9D rather than =E2=80=
=9Cforwarding=E2=80=9D messages means, that the intermediate<=
/p>



















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0router =E2=80=9Cregenerating=E2=80=9D the RREQ may =
chose a different structure (e.g., include TLVs




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0in a different order).




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0The proposal from=C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2e=
sec-00




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0is to add constraints on (i) the set of elements to=
 include in a signature and (ii) the




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0order of these elements.




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0One=C2=A0problem with that approach is (i): if an e=
xtension adds a message TLV, or an=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0Address TLV, to a message, then that will not be =
=E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0Rather for *each* extension developed, an =E2=80=9C=
updates e2esec=E2=80=9D clause needs to be done.




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0I=E2=80=99d say that this approach would be prone t=
o errors =E2=80=94 and add entropy to the process




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0of designing protocol extensions. The alternative, =
a message being generated by the




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0source and *forwarded* (as we do in OLSRv2, for exa=
mple) would allow ICV TLVs=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0(even, allow reuse of those specified for OLSRv2) f=
or covering a message and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0extensions.




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9CBut what about the metrics value which wil=
l change on each hop=E2=80=9D, you may say?




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0Fortunately, that is relatively easy to handle: sim=
ply zero out the value of that TLV when




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0generating or verifying the ICV MessageTLV. And use=
 Packet-TLVs for hop-by-hop=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0authentication, if needed (but, see below).<=
u>




















=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0It prevents the use of more clever/advanced signature =
schemes/ICVs




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0Aggregate signature algorithms (=C2=A0https://crypto.stanford.edu/~dabo/papers/aggsurve=
y.pdf)




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0exist, and an interesting use-case can be found in =
also reactive protocols, allowing verifying




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0not =E2=80=9Cjust=E2=80=9D the end points, but also=
 the intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D=





















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0discussed above, or something smarter).




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0Regeneration of messages, rather than forwarding, r=
enders that impossible (or, if used,




















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0updating to =C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-0=
0)




















=C2=A0




















There are other reasons, but the above are thos=
e that jump at me as immediate show-stoppers.




















=C2=A0




















I do honestly not see what possible benefit the=
re is from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear in=
conveniences, and security is not the least of these. Insisting on =E2=80=
=9Cregeneration=E2=80=9D
 requires development of =E2=80=9Cnon-general workarounds=E2=80=9D as point=
ed out above.




















=C2=A0




















Security Considerations=





















This is an always thorny subject. When OLSRv2 w=
as going through the process we got a thorough education in how little we k=
new about security from the SEC-ADs, and had to spend about
 a year or so developing RFC7183. The bottom line is, that this protocol ne=
eds its =E2=80=9CRFC7183 =C2=A0equivalent=E2=80=9D, either as part of the m=
ain document, or as an independent document. currently, that is not the cas=
e.




















=C2=A0




















A minima, looking at BCP72 and BCP107 =E2=80=94=
 taking inspiration from RFC7183 might be aw good idea, as that was the mos=
t recent that went through the SEC AD. Regardless of how, however,
 a =E2=80=9Cmandatory to implement=E2=80=9D security mechanism most be spec=
ified (I think the right term was =E2=80=9CMUST implement, SHOULD use=E2=80=
=9D), in sufficient detail to ensure interoperable implementations.<=
u>




















=C2=A0




















As an example, both [RFC6130] and [RFC7181] set=
 out that that:






















=C2=A0




















=C2=A0 =C2=A0 =C2=A0 On receiving a ... message=
, a router MUST first check if the




















=C2=A0 =C2=A0 =C2=A0 message is invalid for pro=
cessing by this router




















=C2=A0




















and then proceed to give a number of conditions=
 that, each, will lead to a rejection of the message as "badly formed =
and therefore invalid for processing=E2=80=9D =E2=80=94 a list which RFC718=
3
 then amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting=
 =E2=80=9Crejection=E2=80=9D. Idem for message generation.



















=C2=A0




















If I was to do RFC7181/RFC6130 today, I would i=
nclude that directly into the protocol specifications. It turned out to be =
more overhead (and slow down publication anyways) to do
 it as separate documents.






















=C2=A0




















Secondly, we need to be a lot more rigid in ter=
ms of what ICVs, Timestamps, etc. are added/removed, and what that brings.<=
u>




















=C2=A0




















For example (with the assumption that messages =
are *forwarded* and *not* regenerated), this could be one option:=





















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0When a RREQ, RREP message is generated, add an ICV Message TLV,=
 which is calculated <this way>




















=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=A6(take inspiration from RFC7183 here)=





















=C2=A0






























...



[Message clipped]=C2=A0=C2=A0

_______________________________________________

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








=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








=C2=A0











_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet




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



--94eb2c04796e7c6de20531500d37--


From nobody Mon Apr 25 07:34: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 BAE3B12D5ED for ; Mon, 25 Apr 2016 07:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.82
X-Spam-Level: 
X-Spam-Status: No, score=-4.82 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, TRACKER_ID=1.306] 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 rg-zUh7W8DDb for ; Mon, 25 Apr 2016 07:33:55 -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 0EA3212D513 for ; Mon, 25 Apr 2016 07:33:53 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,533,1454976000"; d="scan'208,217"; a="34189913"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 25 Apr 2016 15:33:51 +0100
X-IronPort-AV: E=Sophos;i="5.24,533,1454976000";  d="scan'208,217";a="115382381"
Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 25 Apr 2016 15:32:56 +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; Mon, 25 Apr 2016 15:32:56 +0100
From: "Dearlove, Christopher (UK)" 
To: "ietf@thomasclausen.org" , Justin Dean 
Thread-Topic: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
Thread-Index: AQHRgGzYnQ0jbgFSiUepI05etGsIBJ9d2vAQgAAD6gCAAAGt4IAAAs+AgDjn+gCAAAvpAIAAo5QAgAMoSiCAACB6gIAAE7kAgAARySCAAACAgIAAAmMAgAARLkA=
Date: Mon, 25 Apr 2016 14:32:55 +0000
Message-ID: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>         
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B15B0GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: 
Cc: Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 14:34:02 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B15B0GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2UgYWN0dWFsbHkgdG9vayB3aGF0IGJlY2FtZSBSRkMgNTQ0NCB0byB0aGUgSUVTRyB3aXRoIGEg
VExWIG9yZGVyaW5nIHJlcXVpcmVtZW50LiBJdCB3YXNu4oCZdCBhY2NlcHRhYmxlLg0KDQpBbmQg
eWVzLCB0aGV5IHNhdmVkIHVzIGZyb20gYW4gZXJyb3Igd2Ugd291bGQgaGF2ZSBtYWRlLg0KDQot
LQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBT
eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lz
dGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lz
dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdy
ZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNv
bS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJ
bnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAx
MzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9y
ZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IGlldGZAdGhvbWFzY2xhdXNlbi5vcmcgW21haWx0
bzppZXRmQHRob21hc2NsYXVzZW4ub3JnXQ0KU2VudDogMjUgQXByaWwgMjAxNiAxNToyOQ0KVG86
IEp1c3RpbiBEZWFuDQpDYzogRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk7IENocmlzdG9waGVy
IERlYXJsb3ZlOyBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdDsgVmljdG9yaWEg
TWVyY2llY2ENClN1YmplY3Q6IFJlOiBbbWFuZXRdIE1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBtZXNz
YWdlIG11dGFiaWxpdHkgKHdhcyBSRTogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3
IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcykNCg0KDQoqKiogV0FSTklORyAqKioNClRo
aXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRo
ZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNh
cmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBh
dHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdz
IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBo
ZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5
L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUg
ZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2lu
dHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9E
b2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQoNCk9u
IDI1IEFwciAyMDE2LCBhdCAxNjoyMCwgSnVzdGluIERlYW4gPGJlYmVtYXN0ZXJAZ21haWwuY29t
PG1haWx0bzpiZWJlbWFzdGVyQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpBIHRob3VnaHQgcmVnYXJk
aW5nIGludGVncml0eSBjaGVja2luZy4gIEEgcG9zc2libGUgZnV0dXJlICJmaXgiIGZvciBpbnRl
Z3JpdHkgY291bGQgYmUgZG9uZSBvbiBhICJ2aXJ0dWFsIiBwYWNrZXQgaW4gd2hpY2gga25vd24g
VExWcy92YWx1ZXMgYWxvbmcgd2l0aCBvcmRlcmVkIGFkZHJlc3NlcyBhcmUgdW5jb21wcmVzc2Vk
IGFuZCB0aGVuIHZlcmlmaWVkLiAgSXQgY291bGQgYWxsb3cgZXh0cmEgVExWIHRhZ2dpbmcgd2l0
aG91dCBtb2RpZnlpbmcgdGhlIHZhbGlkaXR5IG9mIHRoYXQgZGF0YS4gIFRoZSB2ZXJ5IGJpZyBk
cmF3YmFjayB3b3VsZCBiZSB0aGUgb3ZlcmhlYWQgb2YgaGF2aW5nIHRvIHVuY29tcHJlc3NlZCBl
dmVyeXRoaW5nIHRvIGNoZWNrIHRoZSB2YWxpZGl0eS4gIEl0J3MgZnVuY3Rpb25hbGx5IHRoZSBz
YW1lIGFzIHplcm9pbmcgb3V0IGxvY2FsICh0aGlzIGlzIG15IHN0dWZmKSBUTFYgZGF0YSB2cyBy
ZW1vdGUgKHRoaXMgaXMgbm90IG15IHN0dWZmKSBUTFYgZGF0YS4NCg0KVGhhdCByZXF1aXJlcyBh
biBpbXBvc2VkIG9yZGVyaW5nIG9mIGFkZHJlc3NlcywgYWRkcmVzcyBUTFZzLCBNZXNzYWdlIFRM
VnMsIGV0Yy4sIGV2ZW4gaWYgb25seSDigJxpbiBtZW1vcnnigJ0sIGl0IGlzIHNvbWV0aGluZyB0
aGF0IGV2ZXJ5Ym9keSBzaG91bGQgYmUgYXdhcmUgb2YsIGFuZCBkb2luZyB0aGUgc2FtZSB3YXkN
Cg0KICAgICAgICAgICAgbyAgICAgICAgICBUaGF0IG9yZGVyaW5nIHdvdWxkIGhhdmUgdG8gYmUg
c3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQgKG5vLCBpdCB3b3VsZCBub3QgYmUgYSDigJxmdXR1
cmUgZml44oCdLCB0aGlzIGlzDQogICAgICAgICAgICAgICAgICAgICAgICBhIHJlcXVpcmVtZW50
IHRvIHRoZSBiYXNlIHNwZWMsIHNpbmNlICpub3QqIGRvaW5nIHRoYXQgd291bGQgbWVhbiB0aGF0
IHRoaXMg4oCcZnV0dXJlIGZpeOKAnSBjb3VsZCByZW5kZXINCiAgICAgICAgICAgICAgICAgICAg
ICAgIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIG5vbi1jb21wbGlhbnQhKQ0KDQogICAgICAgICAg
ICBvICAgICAgICAgIFdoaWxlIHRoaXMgd291bGQgYmUgKmhhcmQqIGZvciB0aGUgY3VycmVudCBt
ZXNzYWdlcy9UTFZzLCBJ4oCZZCBpbWFnaW5lIHRoYXQgaXTigJlkIG1ha2UgZXh0ZW5zaW9ucw0K
ICAgICAgICAgICAgICAgICAgICAgICAgaW1wb3NzaWJsZSAoaW4gYW4gaW50ZXJvcGVyYWJsZSBm
YXNoaW9uKS4NCg0KICAgICAgICAgICAgbyAgICAgICAgICBJdOKAmWQgYmUgKmV4Y2VwdGlvbmFs
bHkqIGhlYXZ5IGZvciBhbGwgaW50ZXJtZWRpYXRlIHJvdXRlcnMsIHdhbnRpbmcgdG8gdmVyaWZ5
IHRoZSBpbnRlZ3JpdHkgb2YgYQ0KICAgICAgICAgICAgICAgICAgICAgICAgbWVzc2FnZTogdG8g
YmUgYWJsZSB0byBmb3JjZSBldmVyeWJvZHkgaW4gYSBuZXR3b3JrIHRvIOKAnHVud3JhcOKAnSB0
aGUgbWVzc2FnZSBpbnRvIGFuDQogICAgICAgICAgICAgICAgICAgICAgICB1bmNvbXByZXNzZWQg
Zm9ybSAqYmVmb3JlKiB2YWxpZGF0aW5nIGl0cyBvcmlnaW5zIGlzIG9wZW5pbmcgdXAgZm9yIERv
UyBhdHRhY2tzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICBJIHdhbnQgdG8gZG8gYSAqbWlu
aW11bSogbnVtYmVyIG9mIG9wZXJhdGlvbnMgd2l0aCBhIG1lc3NhZ2UsICpiZWZvcmUqIGRlY2lk
aW5nDQogICAgICAgICAgICAgICAgICAgICAgICB0byBkaXNjYXJkIGEgbWVzc2FnZSBhcyBoYXJt
ZnVsLg0KDQoNCg0KQXMgZm9yIHRoZSBSUkVQLUFjayBoYXZpbmcgYSBmbGFnIHZzIGFuIGFkZHJl
c3MgZG9lc24ndCBtdWNoIGJvdGhlciBtZSBhcyBlaXRoZXIgd291bGQgaGF2ZSB0byBiZSB6ZXJv
ZWQgb3V0IGZvciB0aGlzIHR5cGUgb2YgZnV0dXJlIGludGVncml0eSBjaGVja2luZy4NCg0KVGhp
cyBpcyBub3QgYSBxdWVzdGlvbiBvZiBmdXR1cmUgaW50ZWdyaXR5IGNoZWNraW5nLCBidXQgYSBy
ZXF1aXJlbWVudCBmb3IgdGhlIGJhc2Ugc3BlY2lmaWNhdGlvbiB0byBiZSBhYmxlIHRvIHN1cHBv
cnQuDQoNClRob21hcw0KDQoNCg0KSnVzdGluDQoNCk9uIE1vbiwgQXByIDI1LCAyMDE2IGF0IDk6
MjcgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0
ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PiB3cm90ZToNCkFz
c3VtaW5nIGZvciB0aGUgbW9tZW50IHRoYXQgZXZlcnlvbmUgd2lsbCBuZWVkIGFuIFJSRVAtQWNr
IG9yIHdvbuKAmXQgKGxldOKAmXMgY29tZSBiYWNrIHRvIHRoYXQpIHdoeSBkbyBDIGFuZCBCIG5l
ZWQgdG8gcHV0IGFuIGFkZHJlc3MgaW4gYXMgYW4gUlJFUS1BY2sgcmVxdWVzdD8gV2h5IG5vdCBh
IGZsYWcsIGJlY2F1c2UgdGhlIGFkZHJlc3Mgd2lsbCBiZSBpbmNsdWRlZCBhcyB0aGUgSVAgc2Vu
ZGluZyBhZGRyZXNzIC0gYW5kIHdlIGtub3cgNTQ0NCBpcyByZXF1aXJlZCB0byBwYXNzIHRoYXQg
b24uIChJdOKAmXMgdXNlZCBieSBOSERQIGFzIHdlbGwuKSBUaGVuIHdlIGRvbuKAmXQgbmVlZCB0
byBjaGFuZ2UgdGhlIFJSRVAsIGl0IHdpbGwgaGF2ZSBhIGZsYWcgc2V0IG9yIG5vdCwgYW5kIHdv
buKAmXQgY2hhbmdlIChpbiB0aGlzIHJlZ2FyZCkuDQoNCk5vdyBsZXTigJlzIGNvbnNpZGVyIGRv
IHdlIGtub3cgd2hldGhlciB3ZSBjYW4gc2V0IGEgZml4ZWQgZmxhZy4gRmlyc3QgSeKAmWQgc2F5
IHRoZXJlIGFyZSB0d28gY2FzZXMgLSB5b3XigJl2ZSBnb3QgYSBmaXJtIGNvbnRyb2wgb24gd2hh
dOKAmXMgZ29pbmcgb24gaW4geW91ciBuZXR3b3JrLCBvciBpdOKAmXMgb25lIG9mIHVua25vd24g
cGFydGllcyBhbmQgYmVoYXZpb3VyIChjb25zaXN0ZW50IHdpdGggc3BlY2lmaWNhdGlvbikuIElu
IHRoZSBmb3JtZXIgY2FzZSB5b3Ugb25seSB3YW50IG9uZSBzZXR0aW5nLCBmb3IgZXhhbXBsZSBu
by1BY2sgaWYgcnVubmluZyBOSERQIG9yIHlvdXIgTUFDIGxheWVyIHRlbGxzIHlvdSBhYm91dCBi
aWRpcmVjdGlvbmFsaXR5LCBBY2sgb3RoZXJ3aXNlLiBJbiB0aGUgbGF0dGVyIGNhc2UsIEkgdGhp
bmsgeW91IGp1c3QgYWx3YXlzIHdhbnQgYW4gQWNrLiBTbyBib3RoIGNhc2VzIGdldCB5b3UgdG8g
dGhlIHNhbWUgcGxhY2UuDQoNClNob3VsZCB0aGF0IG5vdCBiZSBhbiBhY2NlcHRhYmxlIGFyZ3Vt
ZW50ICh0aG91Z2ggSSB0aGluayBpdOKAmXMgZ29vZCBmb3Igd2hlcmUgd2UgYXJlIC0gaW4gZmFj
dCBhbHdheXMgQWNrIGlzIGNsb3NlKSB0aGVuIGF0IGZsYWcgaXMgYSBzdGVwIGJldHRlciwgaXTi
gJlzIGEgZml4ZWQgbG9jYXRpb24gdG8gY2hhbmdlLiBIb3dldmVyIGl0IHdvdWxkIGJlIGJldHRl
ciBpbiB0aGF0IGNhc2UgaWYgdGhlIHR3byB0aGluZ3MgdG8gY2hhbmdlIChtZXRyaWMgYW5kIGFj
ayBmbGFnKSB3ZXJlIHRvZ2V0aGVyLiBCdXQgdGhhdCBoYXMgaXRzIG93biBpc3N1ZXMsIHNvIEkg
d29u4oCZdCBnbyB0aGVyZS4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJp
bmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0
b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVsOiUy
QjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0
ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0
ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3Jl
YXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29t
L2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIElu
dGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEz
Mzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3Jk
LCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTogVmljdG9yaWEgTWVyY2llY2EgW21haWx0bzp2bWVy
Y2llY2EwQGdtYWlsLmNvbTxtYWlsdG86dm1lcmNpZWNhMEBnbWFpbC5jb20+XQ0KU2VudDogMjUg
QXByaWwgMjAxNiAxNDoxNQ0KVG86IEppYXppIFlJDQpDYzogRGVhcmxvdmUsIENocmlzdG9waGVy
IChVSyk7IENocmlzdG9waGVyIERlYXJsb3ZlOyBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxp
bmcgbGlzdA0KU3ViamVjdDogUmU6IFttYW5ldF0gTWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3Nh
Z2UgbXV0YWJpbGl0eSAod2FzIFJFOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcg
LSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKQ0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhp
cyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhl
ciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2Fy
ZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0
dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3Mg
dGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhl
cmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkv
c3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBl
bWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50
cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0Rv
Y3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCkhpIEpp
YXppLA0KDQoNCk9uIE1vbiwgQXByIDI1LCAyMDE2IGF0IDE6MDQgUE0sIEppYXppIFlJIDxpZXRm
QGppYXppeWkuY29tPG1haWx0bzppZXRmQGppYXppeWkuY29tPj4gd3JvdGU6DQpIaSwNCg0KT24g
TW9uLCBBcHIgMjUsIDIwMTYgYXQgMTE6MjAgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp
IDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFl
c3lzdGVtcy5jb20+PiB3cm90ZToNCldpdGggcmVnYXJkIHRvIHlvdXIgdmFsaWRpdHkgdGltZSBw
b2ludCwgd2UgaGVyZSBoYXZlIGEgdHJhZGVvZmYuIElmIHlvdSBhbGxvdyB0aGF0IGZlYXR1cmUs
IGl0IHNpZ25pZmljYW50bHkgaW1wYWN0cyBvbiB0aGUgYXBwcm9hY2ggdGhhdCB3YXMgY29taW5n
IHRvZ2V0aGVyIG9uIGFzIGJlc3QgeW91IGNhbiBlbmQgdG8gZW5kIGVuY3J5cHRpb24uDQoNClNv
IHRoZSBxdWVzdGlvbiBpcywgaXMgdGhpcyBhIGZlYXR1cmUgdGhhdOKAmXMgcmVhbGx5IHdhbnRl
ZD8gVW5mb3J0dW5hdGVseSBJIHRoaW5rIHdlIGtub3cgdGhhdCB0aGUgYW5zd2VyIHRvIHRoYXQg
aXMsIHdlIGRvbuKAmXQga25vdyBiZWNhdXNlIHdlIGRvbuKAmXQgaGF2ZSBhbnkgZXhwZXJpZW5j
ZS4gTXkgdmlldyB3b3VsZCBiZSB0aGF0IGluIHRoZSB0cmFkZW9mZiBvZiBhbiB1bnRlc3RlZCBm
ZWF0dXJlICh1bmxlc3MgSeKAmW0gd3JvbmcgYWJvdXQgdGhhdCkgYW5kIHRoZSBzZWN1cml0eSBj
b21wbGljYXRpb24sIHNlY3VyaXR5IHdpbnMgYW5kIGRyb3AgdGhlIGZlYXR1cmUuIElmIHRoZXJl
IGlzIHNvbWUgcmVhbCByZXF1aXJlbWVudCwgdGhlbiB0aGVyZeKAmXMgYSBkaXNjdXNzaW9uLiAo
UXVlc3Rpb25zIGxpa2UgaG93IG9mdGVuIHRoZSBpbnRlcm1lZGlhdGUgcm91dGVycyBhY3R1YWxs
eSBoYXZlIGFueSBrbm93bGVkZ2UgLSB0eXBpY2FsbHkgbGlua3MgYnJlYWsgZm9yIHVuZXhwZWN0
ZWQgcmF0aGVyIHRoYW4gZXhwZWN0ZWQgcmVhc29ucy4gQW5kYW4gaW50ZXJtZWRpYXRlIHJvdXRl
ciBjb3VsZCBwb3NzaWJseSB1c2UgYSB2YWxpZGl0eSB0aW1lIHRvIGluZmx1ZW5jZSBpdHMgYmVo
YXZpb3VyLikgTm90ZSB0aGF0IGRyb3BwaW5nIHRoZSBhYmlsaXR5IG9mIGludGVybWVkaWF0ZSBy
b3V0ZXJzIHRvIG1vZGlmeS9zZXQgc3RpbGwgYWxsb3dzIHZhbGlkaXR5IHRpbWVzIHBlciByb3V0
ZSB0byBiZSBzZXQgYXQgZW5kcG9pbnRzLg0KDQpJIGFncmVlIHdpdGggQ2hyaXMnIGNvbmNlcm4u
DQpUaGUgVmFsaWRpdHlUaW1lIGlzIG9wdGlvbmFsLCB3aGljaCBtYWtlcyB0aGUgaW50ZWdyaXR5
IHByb3RlY3Rpb24gaGFyZC4gRnVydGhlcm1vcmUsIGl0IGdpdmVzIGEgcG90ZW50aWFsIGF0dGFj
ayB2ZWN0b3I6IGFzIGFsbCB0aGUgcm91dGVycyBpbiBhIHBhdGggd2lsbCB0YWtlIHRoZSBzaG9y
dGVzdCB2YWxpZGl0eVRpbWUsIGEgY29tcHJvbWlzZWQgcm91dGVyIGNhbiBzZXQgdGhlIHRoZSB2
YWxpZGl0eVRpbWUgdG8gYSB2ZXJ5IHNob3J0IHZhbHVlLCB3aGljaCB3aWxsIG1ha2UgdGhlIHJv
dXRlIGluc3RhbGxlZCBhbG9uZyB0aGUgcGF0aCBiZWNhbWUgaW52YWxpZCAodmVyeSBzb29uKS4N
Cg0KT24gdGhlIG90aGVyIGhhbmQsIEknbSBub3Qgc3VyZSB0aGlzIG9wdGlvbiB3aWxsIGdpdmUg
dXMgbXVjaCBoZWxwLiBDaHJpcyBtZW50aW9uZWQgbXVjaCBrbm93bGVkZ2UgaW50ZXJtZWRpYXRl
IHJvdXRlciB3b3VsZCBoYXZlIHRvIGRlY2lkZSB0aGlzIHZhbHVlIChhbmQgaG93IG11Y2ggc2Vu
c2UgdGhlIHZhbHVlIHdvdWxkIG1ha2UpLg0KQW5vdGhlciBpc3N1ZSBpcywgYSByb3V0ZSB0byBh
IGRlc3RpbmF0aW9uIG1pZ2h0IGJlIHVwZGF0ZWQgYnkgZGlmZmVyZW50IHNvdXJjZXMuIEZvciBl
eGFtcGxlLCBpbiB0aGUgbmV0d29yayBiZWxvdzoNCg0KQS0tLS1CLS0tLS1DDQoNCkEgZmlyc3Qg
ZXN0YWJsaXNoIGEgcm91dGUgdG8gQiB3aXRoIGxvbmcgdmFsaWRpdHkgdGltZS4gVGhlbiBBIGlu
aXRpYXRlcyBhIHJvdXRlIGRpc2NvdmVyeSB0byBDLiBDIHRlbmRzIHRvIHNldCBhIHNob3J0IHZh
bGlkaXR5IHRpbWUsIHdoaWNoIHdpbGwgbWFrZSB0aGUgcm91dGUgYmV0d2VlbiBCIGFuZCBBIGV4
cGlyZSBlYXJsaWVyIHRoYW4gZXhwZWN0ZWQuDQpJcyB0aGlzIGEgcHJvYmxlbT8gTWF5YmUgeWVz
LCBtYXliZSBubyAtLSBJJ20gbm90IHN1cmUgaXQncyBjb25zaWRlcmVkIG9yIG5vdC4NCg0KDQpO
b3Qgc3VyZSBJIGZvbGxvdyBoZXJlLg0KQ3VycmVudGx5LCB0aGUgdmFsaWRpdHkgdGltZSBvZiB0
aGUgcm91dGUgYmV0d2VlbiBBIGFuZCBCIHdvdWxkIG5vdCBhZmZlY3RlZCBieSBhIHNob3J0IHZh
bGlkaXR5IHRpbWUgb2YgYSByb3V0ZSBiZXR3ZWVuIEEgYW5kIEMuIFZhbGlkaXR5IHRpbWVzIGFy
ZSBwZXItcm91dGUsIGFuZCB0aGUgcm91dGUgQS1CIGFuZCB0aGUgcm91dGUgQS1DIGFyZSBzZXBh
cmF0ZS4NCklmIHdlIHN3aXRjaGVkIHRvIGEgdmFsaWRpdHkgdGltZSBwZXIgbmVpZ2hib3IgKHNv
IHRoYXQgd2UgY2FuIGtlZXAgdmFsaWRpdHkgdGltZSBzZXBhcmF0ZSBmcm9tIHJvdXRlIGFkdmVy
dGlzZW1lbnRzKSBhcyBJIG1lbnRpb25lZCBpbiB0aGUgZW1haWwgYmVsb3csIHRoZW4gdGhlIHZh
bGlkaXR5IG9mIGEgcm91dGUgYmV0d2VlbiBBIGFuZCBDIHdvdWxkIGJlIGFmZmVjdGVkIGlmIHRo
ZXJlIHdhcyBhIHNob3J0IHZhbGlkaXR5IHRpbWUgYmV0d2VlbiBBIGFuZCBCLiBCdXQsIGlmIEIg
d2lsbCBvbmx5IHJvdXRlIGZvciBhIGNlcnRhaW4gYW1vdW50IG9mIHRpbWUsIHRoZW4gdGhlIHJv
dXRlIGJldHdlZW4gQSBhbmQgQyB3aWxsIG9mIGNvdXJzZSBiZSBhZmZlY3RlZC4gSXMgaXQgYmVz
dCB0byBrbm93IGluIGFkdmFuY2UgdGhhdCB0aGVyZSdzIGEgdGltZSBsaW1pdCwgb3IganVzdCBk
ZWFsIHdpdGggUkVSUnMgd2hlbiB0aGV5IGhhcHBlbj8NCg0KDQoNCldpdGggcmVnYXJkIHRvIHRo
ZSBhY2tub3dsZWRnZW1lbnRzLCB0aGUgcHJvYmxlbSAod2l0aCByZWdhcmQgdG8gc2VjdXJpdHkp
IGNvbWVzIGZyb20gdHJ5aW5nIHRvIGRvIHR3byBqb2JzIHdpdGggdGhlIHNhbWUgbWVzc2FnZSAt
IGVuZCB0byBlbmQgcm91dGUgYWR2ZXJ0aXNlbWVudCBhbmQgaG9wIGJ5IGhvcCBhY2tub3dsZWRn
ZW1lbnQuIEkgdW5kZXJzdGFuZCB0aGUgcmVhc29ucyAtIHNhdmluZyBieXRlcyBhbmQgbWVzc2Fn
ZSB0eXBlcy4gKEkgd291bGQgaGF2ZSB0byBzdHVkeSB0aGUgcHJvdG9jb2wgcmVhbGx5IGhhcmQg
dG8gaWRlbnRpZnkgaWYgYW55IG1lc3NhZ2UgdHlwZXMgY2FuIGJlIGZvbGRlZCB0b2dldGhlciBh
bmQgcmVjb2duaXNlZCBieSBjb250ZW50IHJhdGhlciB0aGFuIHR5cGUgZWZmaWNpZW50bHkuIFRo
aXMgSSBkbyBub3QgZXhwZWN0IHRvIGRvLikgQWdhaW4gYSB0cmFkZW9mZi4gVGhpcyBvbmUgaXMg
aW4gZGlzY3Vzc2lvbiBzcGFjZSwgdGhvdWdoIHRoYXQgbmVlZHMgcGVvcGxlIHdobyB1bmRlcnN0
YW5kIGJvdGggc2lkZXMgb2YgdGhlIGlzc3VlLCBpbmNsdWRpbmcgdGhlIGRldGFpbHMgb2YgdGhl
IGJpZGlyZWN0aW9uYWxpdHkgbWVjaGFuaXNtLiBPZiBjb3Vyc2UsIGFzIGhhcyBiZWVuIHNhaWQs
IHdlIG5lZWQgb25lIG9mIHRob3NlLg0KDQpJIGhhdmVuJ3QgZmluaXNoZWQgbXkgcmV2aWV3IG9m
IHRoZSBsYXRlc3QgZHJhZnQsIGFuZCBJIGRvbid0IGdldCB0aGUgbmVjZXNzaXR5IG9mIEFja1Jl
cSBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgbXVsdGljYXN0IFJSRVAgeWV0Lg0KSWYgcG9zc2libGUs
IHRoaXMgIm9wdGlvbmFsIiBmaWVsZCBzaG91bGQgYmUgYXZvaWRlZC4NCg0KDQpUbyBnaXZlIGFu
IG92ZXJ2aWV3IG9mIEFja1JlcSBhbmQgUlJFUDoNClNpbmNlIEFPRFZ2MiByZXF1aXJlcyBiaWRp
cmVjdGlvbmFsIGxpbmtzLCB0aGlzIGlzIHRoZSB3YXkgdG8gZGV0ZXJtaW5lIGlmIGEgbGluayBp
cyBiaWRpcmVjdGlvbmFsLg0KQS0tLS1CLS0tLUMNCg0KMSkgQSBzZW5kcyBSUkVRLCBCIGZvcndh
cmRzIGl0LCBDIHJlY2VpdmVzIHRoZSBSUkVRLiBCIGFuZCBDIGJvdGggaW5zdGFsbCBhIHJvdXRl
IHRvIE9yaWdBZGRyIGJ1dCB0aGV5IGRvbnQgeWV0IGtub3cgaWYgaXQncyB2YWxpZCBiZWNhdXNl
IHRoZXkgZG9udCBrbm93IGlmIHRoZSBsaW5rIHRvIHRoZWlyIG5leHQgaG9wIGlzIGF2YWlsYWJs
ZSBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24uDQoyKSBDIGNyZWF0ZXMgdGhlIFJSRVAuIFNpbmNl
IGl0IGRvZXNudCBrbm93IGlmIHRoZSBsaW5rIHRvIEIgaXMgYmlkaXJlY3Rpb25hbCwgaXQgaW5j
bHVkZXMgdGhlIEFja1JlcSAoYW4gYWRkcmVzcyB0byBpbmRpY2F0ZSB0aGF0IGl0IGV4cGVjdHMg
dG8gcmVjZWl2ZSBhIFJSRVBfQWNrIGZyb20gQikuDQozKSBCIHJlY2VpdmVzIHRoZSBSUkVQLCBp
bnN0YWxscyBhIHJvdXRlIHRvIFRhcmdBZGRyIGFuZCBtYXJrcyBpdCBhcyB2YWxpZCwgc2luY2Ug
aXQga25vd3MgdGhlIGxpbmsgdG8gQyBpcyBiaWRpcmVjdGlvbmFsLCBiZWNhdXNlIHRoZSBSUkVR
IHdlbnQgaW4gb25lIGRpcmVjdGlvbiBhbmQgdGhlIFJSRVAgY2FtZSBpbiB0aGUgb3RoZXIuIEIg
YWxzbyBzZW5kcyB0aGUgUlJFUF9BY2sgdG8gQyBhbmQgZm9yd2FyZHMgdGhlIFJSRVAgdG8gQSAo
YW5kIG1pZ2h0IGNoYW5nZSB0aGUgbWVzc2FnZSB0byBpbmRpY2F0ZSBpdHMgb3duIEFja1JlcSAt
IGllIHRoYXQgaXQgcmVxdWlyZXMgYW4gYWNrIGZyb20gQSkuDQo0KSBDIHJlY2VpdmVzIHRoZSBS
UkVQX0FjayBmcm9tIEIsIGFuZCB0aGVyZWZvcmUga25vd3MgdGhhdCBCIHJlY2VpdmVkIHRoZSBS
UkVQLCB0aGVyZWZvcmUgdGhlIGxpbmsgaXMgYmlkaXJlY3Rpb25hbC4gQyBjYW4gdGhlbiBtYXJr
IGl0cyByb3V0ZSB0byBPcmlnQWRkciBhcyB2YWxpZC4NCjUpIFNpbWlsYXJseSwgQSByZWNlaXZl
cyB0aGUgUlJFUCwgaW5zdGFsbHMgdGhlIHJvdXRlIHRvIFRhcmdBZGRyIGFuZCBzZW5kcyBhbiBS
UkVQX0FjayB0byBCLg0KNikgQiByZWNlaXZlcyB0aGUgUlJFUF9BY2sgYW5kIG1hcmtzIGl0cyBy
b3V0ZSB0byBPcmlnQWRkciBhcyB2YWxpZC4NCg0KQWx0ZXJuYXRpdmVseSwgaW4gc3RlcCAyLCBp
ZiBDIGtub3dzIHRoZSBsaW5rIHRvIEIgaXMgYmlkaXJlY3Rpb25hbCAocGVyaGFwcyBmcm9tIHNv
bWUgZWFybGllciByb3V0ZSBkaXNjb3ZlcnkpLCBpdCBkb2VzbnQgbmVlZCB0byBwdXQgdGhlIEFj
a1JlcSBpbiB0aGUgUlJFUC4gVGhlbiBpbiBzdGVwIDMsIHNpbmNlIEIgZG9lc250IGtub3cgaWYg
dGhlIGxpbmsgdG8gQSBpcyBiaWRpcmVjdGlvbmFsLCBpdCBjaGFuZ2VzIHRoZSBtZXNzYWdlIHRv
IGFkZCB0aGUgQWNrUmVxIGFkZHJlc3MsIGluIG9yZGVyIHRvIGdldCBhbiBSUkVQX0FjayBmcm9t
IEEuDQpJZiB3ZSB3YW50IHRvIGF2b2lkIGNoYW5naW5nIHRoZSBtZXNzYWdlLCB3ZSdsbCBuZWVk
IHRvIGxvb2sgYXQgZm9yd2FyZGluZyB0aGUgUlJFUCBhcy1pcywgYW5kIGNyZWF0aW5nIGEgc2Vj
b25kIG1lc3NhZ2UgdG8gc29saWNpdCBhbiBSUkVQX0FjaywgaW4gb3JkZXIgdG8gdmVyaWZ5IHRo
YXQgdGhlIGxpbmsgaXMgYmlkaXJlY3Rpb25hbCBiZWZvcmUgbWFya2luZyB0aGUgcm91dGUgdG8g
T3JpZ0FkZHIgYXMgdmFsaWQuDQpLaW5kIHJlZ2FyZHMsDQpWaWN0b3JpYS4NCg0KDQpyZWdhcmRz
DQoNCkppYXppDQoNCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFs
IEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVsOiUyQjQ0JTIw
JTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNv
bTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFw
cGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFk
ZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0
dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln
ZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTEN
ClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJy
ZXksIEdVMiA3WVANCg0KRnJvbTogVmljdG9yaWEgTWVyY2llY2EgW21haWx0bzp2bWVyY2llY2Ew
QGdtYWlsLmNvbTxtYWlsdG86dm1lcmNpZWNhMEBnbWFpbC5jb20+XQ0KU2VudDogMjMgQXByaWwg
MjAxNiAxMDo1NQ0KVG86IENocmlzdG9waGVyIERlYXJsb3ZlDQpDYzogaWV0ZkB0aG9tYXNjbGF1
c2VuLm9yZzxtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZz47IERlYXJsb3ZlLCBDaHJpc3Rv
cGhlciAoVUspOyBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdA0KDQpTdWJqZWN0
OiBSZTogW21hbmV0XSBNZXNzYWdlIGludGVncml0eSBhbmQgbWVzc2FnZSBtdXRhYmlsaXR5ICh3
YXMgUkU6IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEgY291cGxlIG9mIGJp
ZyB0aWNrZXQgSXRlbXMpDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2lu
YXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJu
YWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5
b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVw
bHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9v
ayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFu
ZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3Vt
ZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lv
dXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lz
dGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmcl
MjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KSGkgQ2hyaXMsDQoNClRoZXNlIGhh
dmUgYm90aCBiZWVuIGluIHRoZSBkcmFmdCBpbiBzb21lIGZvcm0gc2luY2UgYmVmb3JlIEkgZ290
IGludm9sdmVkLi4uIGJ1dCBJJ2xsIGRvIG15IGJlc3QgdG8gZXhwbGFpbi4NCg0KLSBGb3IgVmFs
aWRpdHkgVGltZSwgaXRzIGEgd2F5IHRvIGFkdmVydGlzZSB0aGF0IHlvdSB3b3VsZCBvbmx5IHN1
cHBvcnQgdGhlIHJvdXRlIGNvbnRhaW5lZCBpbiB0aGUgbWVzc2FnZSBmb3IgYSBjZXJ0YWluIHBl
cmlvZCBvZiB0aW1lLiBUaGUgb3JpZ2luYXRvciBtaWdodCB1c2UgdGhpcywgYnV0IHRoZSBkcmFm
dCB3YXMgd3JpdHRlbiB0byBhbGxvdyBhbnkgaW50ZXJtZWRpYXRlIG5vZGUgdG8gYmUgYWJsZSB0
byBhZGQgaXQgb3IgdXBkYXRlIGl0IHRvby4gVGhlIHJvdXRlIGNyZWF0ZWQgaW4gdGhlIExvY2Fs
IFJvdXRlIFNldCBoYXMgYW4gZXhwaXJhdGlvbiB0aW1lIGFzc29jaWF0ZWQgd2l0aCBpdCwgYmFz
ZWQgb24gdGhlIHJlY2VpdmVkIHZhbGlkaXR5IHRpbWUuDQotIEZvciB0aGUgQWNrUmVxIGFkZHJl
c3MsIGl0cyBzbyB0aGF0IHlvdSBjYW4gYWRkIGludG8gYSBSUkVQIGEgcmVxdWVzdCBmb3IgYW4g
YWNrbm93bGVkZ2VtZW50LCBzbyB0aGF0IHlvdSBkb24ndCBoYXZlIHRvIGhhdmUgYSBkaWZmZXJl
bnQgbWVzc2FnZSB0eXBlIGFsdG9nZXRoZXIgZm9yIHdvcmtpbmcgb3V0IHdoZXRoZXIgbGlua3Mg
dG8gbmVpZ2hib3JzIGFyZSBiaWRpcmVjdGlvbmFsLCBhbmQgYWxzbywgc2luY2UgeW91IG9ubHkg
Y2FyZSBhYm91dCBiaWRpcmVjdGlvbmFsaXR5IG9uIHJvdXRlcyB0aGF0IGFyZSBiZWluZyBzZXQg
dXAsIHlvdSBkb250IG5lZWQgdG8gY29uc3RhbnRseSBtb25pdG9yIGFsbCBuZWlnaGJvcnMuDQoN
Cg0KSW4gb3JkZXIgdG8gYXZvaWQgdGhlIHBvdGVudGlhbCBBY2tSZXEtcmVsYXRlZCBjaGFuZ2Vz
IHRvIGVhY2ggbWVzc2FnZSwgbWF5YmUgd2UgZG8gbmVlZCB0byBpbnRyb2R1Y2UgYSBkaWZmZXJl
bnQgbWVzc2FnZSBzcGVjaWZpY2FsbHkgZm9yIHRoaXMuIFdlIGNvdWxkIG1heWJlIHVzZSBSUkVQ
X0FjayB0byBib3RoIHJlcXVlc3QgYW5kIGFja25vd2xlZGdlPyBJdCBtZWFucyBhbiBleHRyYSBt
ZXNzYWdlIG9mIGNvbnRyb2wgdHJhZmZpYyB0aGF0IG5lZWRzIHRvIGJlIHNlbnQsIG1heWJlIG9u
ZSBleHRyYSBtZXNzYWdlIHBlciBob3Agb24gdGhlIHBhdGggb2YgYSBSUkVQLCBidXQgaXQgY291
bGQgc3RpbGwgYmUgbGltaXRlZCB0byBuZWlnaGJvcnMgd2hpY2ggaGF2ZSBwYXJ0aWNpcGF0ZWQg
aW4gdGhlIHJvdXRlIGRpc2NvdmVyeSByYXRoZXIgdGhhbiBtb25pdG9yaW5nIGFsbCBuZWlnaGJv
cnMgYXQgYWxsIHRpbWVzLg0KDQpUaGlzIG1lc3NhZ2UgY291bGQgbWF5YmUgYWxzbyBpbmNsdWRl
ICJJJ20gaGFwcHkgdG8gcm91dGUgYW55d2hlcmUgZm9yIGEgY2VydGFpbiBhbW91bnQgb2YgdGlt
ZSIsIHNvcnQgb2YgbGlrZSB3aWxsaW5nbmVzcyBpbiBPTFNSL09MU1J2Mi4gU28gaW5zdGVhZCBv
ZiBoYXZpbmcgYSB2YWxpZGl0eSB0aW1lIHBlciByb3V0ZSwgaXRzIGEgdmFsaWRpdHkgdGltZSBw
ZXIgbmVpZ2hib3IuIFRoZW4sIGZvciBSUkVRIGFuZCBSUkVQLCBvbmx5IHRoZSBtZXRyaWMgdmFs
dWUgd291bGQgY2hhbmdlIGluIHRyYW5zaXQsIGFzIGRpc2N1c3NlZC4gSG93ZXZlciwgdGhhdCBs
ZWFkcyB0byBzb21lIGlzc3VlcyB3aXRoIGRlY2lkaW5nIHdoYXQgYSByb3V0ZSdzIGV4cGlyYXRp
b24gdGltZSBpcy4gWW91IG1pZ2h0IGtub3cgaG93IGxvbmcgdGhlIG5leHQgaG9wIHJvdXRlciBp
cyB2YWxpZCBmb3IsIGJ1dCB3aGF0IGlmIGEgcm91dGVyIGJleW9uZCB0aGF0LCB3aGljaCB3YXMg
YWxzbyBwYXJ0IG9mIHRoZSByb3V0ZSwgaGFkIGEgbG93ZXIgdmFsaWRpdHkgdGltZT8gWW91IGNv
dWxkbid0IGRldGVybWluZSB0aGUgcmVhbCB2YWxpZGl0eSB0aW1lLiBEbyB3ZSByZW1vdmUgdGhl
IHJvdXRlIGV4cGlyYXRpb24gdGltZSBhbHRvZ2V0aGVyIHRvIGF2b2lkIHRoaXMgaXNzdWU/IElu
IHdoaWNoIGNhc2UsIHdlIHdvdWxkIGhhdmUgdG8gcmVseSBvbiBSRVJSIG1lc3NhZ2VzIGJlaW5n
IHNlbnQgZm9yIHJvdXRlcyB3aGljaCBiZWNvbWUgaW52YWxpZCB3aGVuIHRoZSBuZWlnaGJvcidz
IHZhbGlkaXR5IHRpbWUgaGFzIGV4cGlyZWQ/IFNvIG5laWdoYm9yIHZhbGlkaXR5IHRpbWUgZXhw
aXJhdGlvbiBpcyB0cmVhdGVkIHRoZSBzYW1lIGFzIGEgbGluayBicmVhay4NCg0KV2hhdCBkbyB5
b3UgdGhpbms/DQoNCktpbmQgcmVnYXJkcywNClZpY3RvcmlhLg0KDQoNCg0KDQoNCg0KT24gU2F0
LCBBcHIgMjMsIDIwMTYgYXQgMTowOSBBTSwgQ2hyaXN0b3BoZXIgRGVhcmxvdmUgPGNocmlzQG1u
ZW1vc3luZS5kZW1vbi5jby51azxtYWlsdG86Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrPj4g
d3JvdGU6DQpQcmV0dHkgbXVjaCBhbGwgb2YgdGhlIGRpc2N1c3Npb24gaGFzIGJlZW4gYXNzdW1p
bmcgb25seSBhIG1ldHJpYyB2YWx1ZSBjaGFuZ2UuIFdpdGggbXVsdGlwbGUgdGhpbmdzIGNoYW5n
aW5nIG1hbnkgb2YgdGhlIGlkZWFzIGdvIG91dCBvZiB0aGUgd2luZG93LiBUaGF0IHJlaW5mb3Jj
ZXMgdGhlIHBvaW50IGFib3V0IG5vdCBtYWtpbmcgc3BlY2lmaWNhdGlvbnMgbm93IHRoYXQgbWln
aHQgdHVybiBvdXQgdG8gYmUgd3JvbmcgZm9yIElDVnMuDQoNCklnbm9yaW5nIGhvdyB0aGlzIG1p
c3VuZGVyc3RhbmRpbmcgaGFwcGVuZWQsIEknbGwgc3RhcnQgYnkgYXNraW5nIHdoeS4gTWV0cmlj
IGNoYW5naW5nIEkgdW5kZXJzdGFuZC4gV2h5IHRoZSBvdGhlciB0d28/ICh0aGVyZSdzIGEgcGFy
dGlhbCBleHBsYW5hdGlvbiBvZiBvbmUpLiBXaGF0IGFsdGVybmF0aXZlcyBoYXZlIHBlb3BsZSBp
bXBsZW1lbnRlZCBpbiBjb21wYXJhYmxlIHByb3RvY29scz8NCg0KLS0NCkNocmlzdG9waGVyIERl
YXJsb3ZlDQpjaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb208bWFpbHRvOmNocmlzdG9waGVy
LmRlYXJsb3ZlQGdtYWlsLmNvbT4gKGlQaG9uZSkNCmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51
azxtYWlsdG86Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrPiAoaG9tZSkNCg0KT24gMjMgQXBy
IDIwMTYsIGF0IDAwOjI2LCBWaWN0b3JpYSBNZXJjaWVjYSA8dm1lcmNpZWNhMEBnbWFpbC5jb208
bWFpbHRvOnZtZXJjaWVjYTBAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBhbGwsDQoNCkNvbnRpbnVl
ZCBpbiB0aGlzIHRocmVhZCBiZWNhdXNlIHRoZSBvdGhlciBvbmUgc2VlbXMgdG8gYmUgbW9yZSBh
Ym91dCBUTFYgdHlwZXMgYW5kIG1ldHJpYyB0eXBlIG51bWJlcnMsIHdoZXJlYXMgdGhpcyBpcyBh
Ym91dCByZWdlbmVyYXRpb24vZm9yd2FyZGluZy4NCg0KVG8gcmVjYXAsIGluIHRoZSBjdXJyZW50
IGRyYWZ0LCB0aGVyZSBhcmUgMyB0aGluZ3MgdGhhdCBtaWdodCBjaGFuZ2UgYXQgZWFjaCBob3A6
DQotIHRoZSBtZXRyaWMgdmFsdWUgKGhhcHBlbnMgaW4gUlJFUSBhbmQgUlJFUCksDQotIGFkZGlu
Zy9jaGFuZ2luZyBWYWxpZGl0eSBUaW1lIHVzaW5nIHRoZSBWYWxpZGl0eSBUaW1lIFRMViAoY2Fu
IGhhcHBlbiBpbiBSUkVRIGFuZCBSUkVQKSwNCi0gYWRkaW5nIGFuIGFkZHJlc3MgKGFuZCBjb3Jy
ZXNwb25kaW5nIHZhbHVlIGluIHRoZSBBZGRyZXNzVHlwZSBUTFYgdG8gaW5kaWNhdGUgaG93IHRv
IGludGVycHJldCB0aGUgYWRkcmVzcykgdG8gaW5kaWNhdGUgdGhlIGFkZHJlc3MgZnJvbSB3aGlj
aCBhbiBSUkVQX0FjayBpcyBleHBlY3RlZCwgdG8gYWNjb21wbGlzaCB0aGUgYmlkaXJlY3Rpb25h
bGl0eSBjaGVjayAoY2FuIGhhcHBlbiBpbiBSUkVQKS4NCg0KSWYgd2UgZGVmaW5lIGEgY2VydGFp
biBwb3J0aW9uIG9mIHRoZSBtZXNzYWdlIGFzIGltbXV0YWJsZSBhbmQgaW5jbHVkZSB0aGUgSUNW
IHRvIHZlcmlmeSB0aGF0IHBhcnQsIGVuZCB0byBlbmQ6DQotIFRoZSBtZXRyaWMgdmFsdWUgd291
bGQgYmUgZXhjbHVkZWQgZnJvbSB0aGUgSUNWIHNpbmNlIGl0IG5lZWRzIGNoYW5naW5nIGF0IGVh
Y2ggaG9wLg0KLSBXb3VsZCBhZGRpbmcgYSBWYWxpZGl0eSBUaW1lIFRMViBhdCBhbiBpbnRlcm1l
ZGlhdGUgaG9wIGJlIGFjY2VwdGFibGU/IFRoZSB3aG9sZSBUTFYgY291bGQgYmUgcmVtb3ZlZCBp
biBvcmRlciB0byBjYWxjdWxhdGUgdGhlIElDVj8NCi0gV291bGQgYWRkaW5nIGFuIGFkZHJlc3Mg
Y2F1c2UgaXNzdWVzIGZvciB0aGUgSUNWLCBiZWNhdXNlIGl0J3MgaW4gdGhlIGFkZHJlc3MgYmxv
Y2s/IENvdWxkIHRoZSBydWxlIGJlICJpZiBpdCBjb250YWlucyBhbiBBY2tSZXEgYWRkcmVzcywg
cmVtb3ZlIGl0IChhbmQgdGhlIGNvcnJlc3BvbmRpbmcgdmFsdWUgaW4gdGhlIEFkZHJlc3NUeXBl
IFRMViksIGJlZm9yZSBjaGVja2luZyB0aGUgSUNWIiwgaXMgdGhhdCBPSz8gT3Igd291bGQgd2Ug
bmVlZCB0byBhdm9pZCB0b3VjaGluZyB0aGUgSUNWJ2VkIHBhcnQgb2YgdGhlIG1lc3NhZ2UgYWx0
b2dldGhlciwgbWF5YmUgcHV0IHRoZSBBY2tSZXEgYWRkcmVzcyBpbiBhIHNlcGFyYXRlIEFkZHJl
c3MgQmxvY2ssIHdpdGggYW4gZXh0cmEgQWRkcmVzc1R5cGUgVExWIGZvbGxvd2luZyB0aGF0IGFk
ZHJlc3MgYmxvY2s/IElzIHRoZXJlIGEgd2F5IHRvIGFjY29tcGxpc2ggdGhpcz8NCg0KQWxzbywg
dG8gYmUgdGhvcm91Z2gsIGRvIHdlIG5lZWQgdG8gY29uc2lkZXIgUkVSUiBtZXNzYWdlcyB3aGls
ZSB3ZSBkaXNjdXNzIHJlZ2VuZXJhdGlvbiB2cyBmb3J3YXJkaW5nPw0KLSBSRVJSIChzZW50IHdo
ZW4gYSBsaW5rIGJyZWFrcykgaXMgYSB3YXkgb2Ygc2F5aW5nICJJJ3ZlIGxvc3QgbXkgcm91dGUg
c28gSSdtIHRlbGxpbmcgb3RoZXJzIiBhbmQgInlvdSB3ZXJlIG15IG5leHQgaG9wLCBzbyBub3cg
SSd2ZSBhbHNvIGxvc3QgbXkgcm91dGUsIEknbGwgdGVsbCBvdGhlcnMiLCBldGMuIEl0J3MgZ29p
bmcgdG8gYmUgdGFpbG9yZWQgYXQgZWFjaCBzdGVwIHRvIGluY2x1ZGUgdGhlIHJlbGV2YW50IHJv
dXRlcyB0aGF0IGdvdCBkZWxldGVkLCBpdCdzIG5vdCBvbmUgbWVzc2FnZSBiZWluZyBzZW50IGVu
ZC10by1lbmQgbGlrZSBSUkVRIGFuZCBSUkVQIGFyZS4NCi0gSG93ZXZlciwgUkVSUiAoc2VudCB3
aGVuIGEgc291cmNlIG9mIHRyYWZmaWMgaXMgc2VuZGluZyBkYXRhIG9uIGEgcm91dGUgd2hpY2gg
Y29tZXMgdGhyb3VnaCB5b3UsIGFuZCB5b3Ugd2FudCB0byB0ZWxsIHRoZSBQYWNrZXQgU291cmNl
J3Mgcm91dGVyIHRvIGRlbGV0ZSB0aGUgcm91dGUpIGNvdWxkIGJlIHNlZW4gYXMgYW4gZW5kLXRv
LWVuZCBtZXNzYWdlIHdoaWNoIGFsbCBpbnRlcm1lZGlhdGUgcm91dGVycyBsZWFybiBmcm9tLCBz
aW1pbGFyIHRvIFJSRVEgYW5kIFJSRVAuIEl0IHJlcG9ydHMgb25lIHJvdXRlLCBhbmQgZG9lc24n
dCBuZWVkIGNoYW5naW5nIGF0IGludGVybWVkaWF0ZSBob3BzLCBzbyBjb3VsZCBiZSBwcm90ZWN0
ZWQgd2l0aCBJQ1YuDQotIFdvdWxkIGl0IGJlIE9LIHRvIG9ubHkgcmVxdWlyZSBhIG1lc3NhZ2Ug
SUNWIGlmIGEgUGt0U291cmNlIGFkZHJlc3Mgd2FzIGluY2x1ZGVkLCBpLmUuIHdoZW4gdGhlIG1l
c3NhZ2UgbmVlZHMgdG8gZ28gdmlhIGEgbnVtYmVyIG9mIGludGVybWVkaWF0ZSBob3BzIHRvIFBr
dFNvdXJjZSdzIHJvdXRlcj8gQWxsIG90aGVyIFJFUlJzIGFyZSBpbnRlbmRlZCB0byBiZSBvbmUt
aG9wIG1lc3NhZ2VzLCB3aGljaCBtYXkgaW4gdHVybiBwcm9tcHQgb3RoZXIgb25lLWhvcCBtZXNz
YWdlcywgZXRjLi4uLCBhbmQgYSBwYWNrZXQgSUNWIG1pZ2h0IGJlIG1vcmUgYXBwcm9wcmlhdGU/
DQoNCktpbmQgcmVnYXJkcywNClZpY3RvcmlhLg0KDQpPbiBUaHUsIE1hciAxNywgMjAxNiBhdCA1
OjI2IFBNLCA8aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzxtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2Vu
Lm9yZz4+IHdyb3RlOg0KDQpPbiAxNyBNYXIgMjAxNiwgYXQgMTg6MTcsIERlYXJsb3ZlLCBDaHJp
c3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMu
ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PiB3cm90ZToNCg0KWWVzLCBJIG1lYW50IEFPRFZ2Miwg
dGhhbmtzIGZvciB0aGUgY2F0Y2guDQoNClNvIGlzIHlvdXIgKFRob21hcykgcHJvcG9zZWQgYmFz
ZSBzcGVjaWZpY2F0aW9uIGEgaG9wIGNvdW50IG9ubHkgbWV0cmljPw0KDQpObywgdGhlIHdvdWxk
IGJlIHNpbGx5IGFzIGJhc2Ugc3BlY2lmaWNhdGlvbiwgZ2l2ZW4gdGhhdCBob3AgY291bnQgbW9z
dGx5IGlzIHVzZWxlc3MuDQoNCkFzIGJhc2Ugc3BlY2lmaWNhdGlvbiBJIHdvdWxkIHNpbXBseSBz
YXkg4oCcSW5jbHVkZSBhIE1ldHJpYyBUeXBlIE1lc3NhZ2UgVExWIHdpdGggYSB2YWx1ZSBmaWVs
ZCwgYW5kIGEgNzE4MiBNZXNzYWdlIFRMViAmIFRpbWVzdGFtcOKAnSBhcyB3ZSBkbyBpbiBPTFNS
djIgKHdpdGggdGhlIGFwcHJvcHJpYXRlIHZlcmJpYWdlIGFzIHRvIGdlbmVyYXRpb24gYW5kIHBy
b2Nlc3NpbmcpLg0KDQpXaXRoIHRoZSBtZXNzYWdlIGdlbmVyYXRlZCBieSB0aGUgb3JpZ2luYXRv
ciBvZiB0aGUgUlJFUS9SUkVQIGFuZCAqbm90KiBkZWNvbnN0cnVjdGVkL3JlY29uc3RydWN0ZWQv
cmVvcmRlcmVkIChhcyBpcyB0aGUgcmlzayB3aXRoIOKAnHJlZ2VuZXJhdGlvbikgYWxsb3dzIGtu
b3dpbmcgdGhhdCBpdCB3b3VsZCBiZSAqb25seSogdGhhdCBtZXRyaWMgZmllbGQgYmVpbmcgbW9k
aWZpZWQgKG90aGVyIHRoYW4gaG9wIGNvdW50L2xpbWl0KSBmb3Igd2hlbiBldmVudHVhbGx5IHdy
aXRpbmcgdXAgdGhlIGV4dGVuc2lvbi4NCg0KKEFjdHVhbGx5IGRvZXNu4oCZdCB0aGUgY3VycmVu
dCBzcGVjaWZpY2F0aW9uIG9ubHkgZGVmaW5lIGhvcCBjb3VudCwgb3IgaGFzIHRoYXQgY2hhbmdl
ZCBpbiBsYXRlc3QgZHJhZnQ/KQ0KDQpOby4gVGhhdCBpcyBvbmUgb2YgdGhlIGlzc3VlcyBJIHJh
aXNlIGluIG15IG9yaWdpbmFsLiBGb3Igc29tZSByZWFzb24sIGl0IGNpdGVzIFJGQzY1NTEsIHdo
aWNoIGlzIGEgUk9MTCBkb2N1bWVudCBhbmQgd2hpY2ggaGFzIGluIGl0cyBhYnN0cmFjdCB0aGF0
Og0KDQoNCiAgIExvdy1Qb3dlciBhbmQgTG9zc3kgTmV0d29ya3MgKExMTnMpIGhhdmUgdW5pcXVl
IGNoYXJhY3RlcmlzdGljcw0KDQogICBjb21wYXJlZCB3aXRoIHRyYWRpdGlvbmFsIHdpcmVkIGFu
ZCBhZCBob2MgbmV0d29ya3MgdGhhdCByZXF1aXJlIHRoZQ0KDQogICBzcGVjaWZpY2F0aW9uIG9m
IG5ldyByb3V0aW5nIG1ldHJpY3MgYW5kIGNvbnN0cmFpbnRzLg0KDQpJLmUuIHRoaXMgZG9jdW1l
bnQgY2l0ZXMgYSBtZXRyaWMgZG9jdW1lbnQgd2hpY2ggY2xlYXJseSBjbGFpbXMgdG8gYmUgaW5h
cHBsaWNhYmxlIGluIGFkIGhvYyBuZXR3b3Jrcy4gSSBub3RlIHRoYXQgdGhpcyBpcyBhbm90aGVy
IHRoaW5nIEnigJl2ZSByYWlzZWQgZm9yIHllYXJzIHdpdGhvdXQgc2VlaW5nIGl0IGF0dGVtcHRl
ZCByZXNvbHZlZC4NCg0KQmVzdCwNCg0KVGhvbWFzDQoNCg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVh
cmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50
ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkx
MjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4gIHwgIEU6IGNocmlz
LmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z
LmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVj
aG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3
d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBT
eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFu
ZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJj
aCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBpZXRmQHRob21hc2Ns
YXVzZW4ub3JnPG1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3JnPiBbbWFpbHRvOmlldGZAdGhv
bWFzY2xhdXNlbi5vcmddDQpTZW50OiAxNyBNYXJjaCAyMDE2IDE3OjEwDQpUbzogRGVhcmxvdmUs
IENocmlzdG9waGVyIChVSykNCkNjOiBMb3R0ZSBTdGVlbmJyaW5rOyBNb2JpbGUgQWQgSG9jIE5l
dHdvcmtzIG1haWxpbmcgbGlzdA0KU3ViamVjdDogUmU6IFttYW5ldF0gTWVzc2FnZSBpbnRlZ3Jp
dHkgYW5kIG1lc3NhZ2UgbXV0YWJpbGl0eSAod2FzIFJFOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2
Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKQ0KDQoNCioqKiBXQVJO
SU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlz
YXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0K
Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3Ms
IG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGlu
ZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2Vp
dmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdv
cmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlv
dSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2Vz
czxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9z
cG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMu
cGRmPi4NCg0KT24gMTcgTWFyIDIwMTYsIGF0IDE4OjA0LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIg
KFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3Zl
QGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQoNCk9LLCBzbyB3ZSBoYXZlIGEgbWVzc2FnZSB0aGF0
IG11dGF0ZXMgYnk6DQotIE1vZGlmeWluZyBob3AgY291bnQvbGltaXQuDQotIE1vZGlmeWluZyBh
IG1ldHJpYyB2YWx1ZS4NCkFueXRoaW5nIGVsc2U/DQoNCkFzIG11dGF0aW5nIChvdGhlciB0aGFu
IGhvcCBjb3VudC9saW1pdCkgbWVzc2FnZXMgYXJlbuKAmXQgY292ZXJlZCBieSA1NDQ0IG9yIGFu
eSBkZXJpdmF0aXZlIGRvY3VtZW50IChidXQgb25seSByZWNvbW1lbmRlZCBhZ2FpbnN0LCBub3Qg
YmFubmVkKSB0aGF0IHlvdSBtYXkgbmVlZCB0byBtYWtlIHRoZSBtZXNzYWdlIG90aGVyd2lzZSBp
bW11dGFibGUgKG5vIGRlY29uc3RydWN0aW9uIGFuZCByZWJ1aWxkaW5nLCBvdGhlciB0aGFuIGd1
YXJhbnRlZWQgdW5jaGFuZ2luZykgdGhhdCB3b3VsZCBoYXZlIHRvIGJlIHNwZWNpZmllZCBieSBB
T0RWdjIuIChFYXN5IHRvIHNheSwgYnV0IG5lZWRzIHNheWluZy4pDQoNCldpdGggeW91IHNvIGZh
ci4NCg0KVGhlbiB0aGF0IGluZm9ybWF0aW9uIGlzIG5vdCBpbiBhIGd1YXJhbnRlZWQgZml4ZWQg
bG9jYXRpb24gZ2l2ZW4gYnkgYSBzaW1wbGUgb2Zmc2V0LiBTbyBhbnkgc2lnbmF0dXJlIGFsZ29y
aXRobSB0aGF0IGZpbmRzIGl0IGFuZCBpZ25vcmVzIGl0IG9yIGFnZ3JlZ2F0ZXMgb24gaXQgaXMg
c3BlY2lmaWMgdG8gT0xTUnYyLg0KDQpTdXJlbHkgeW91IG1lYW4gQU9EVnYyDQoNClNvIHN0YW5k
YXJkIDcxODIgSUNWcyBkb27igJl0IGRvIHRoZSBqb2IsIHlvdSB3b3VsZCBuZWVkIGFuIEFPRFZ2
MiBzcGVjaWFsaXNlZCB2YXJpYW50LiBXaGljaCBpcyB0aGUgc29ydCBvZiB0aGluZyB0aGF0IHRo
ZSBtZXNzYWdlIHNwZWNpZmljIFRMViBzcGFjZSBpcyB0aGVyZSBmb3IsIEnigJlkIGJlIHN0cm9u
Z2x5IGFnYWluc3QgYSDigJxidXQgaWdub3JlIHRoZSB2YWx1ZSBvZiB0aGlzIHNwZWNpZmljIFRM
ViBzaG91bGQgaXQgb2NjdXLigJ0gYmVpbmcgaW4gdGhlIGdlbmVyYWwgc3BhY2UuIEhvd2V2ZXIg
aXQgY2FuIGVhc2lseSBiZSBkZWZpbmVkIGJ5IHJlZmVyZW5jZSB0byA3MTgyICjigJx0aGlzIFRM
ViBpcyBsaWtlIHRoYXQgVExWLCBleGNlcHQgaWYgYW4gWCBUTFYgaXMgcHJlc2VudCwgc2V0IGl0
cyB2YWx1ZSBmaWVsZCB0byB6ZXJv4oCdKS4NCg0KTWVzc3ksIGJ1dCBjb3VsZCB3b3JrLg0KDQpO
b3QgdGhhdCBtZXNzeSwgYWN0dWFsbHksIGFsdGhvdWdoIGNsZWFybHkgbm90IGFzIG5pY2UgYXMg
4oCcZml4ZWQgb2Zmc2V04oCdLg0KDQpUaGF0IHNhaWQsIEkgYW0gYXJndWluZyBmb3IgdGhlIGJh
c2Ugc3BlYyBiZWluZzoNCg0KICAgICAgICAgICAg4oCcbWFrZSB0aGUgbWVzc2FnZSBvdGhlcndp
c2UgaW1tdXRhYmxlIChubyBkZWNvbnN0cnVjdGlvbiBhbmQgcmVidWlsZGluZywgb3RoZXINCiAg
ICAgICAgICAgICB0aGFuIGd1YXJhbnRlZWQgdW5jaGFuZ2luZynigJ0gd2hpY2ggaXMgYWZmb3Jk
ZWQgYnkgZm9yd2FyZGluZw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr
DQoNCiAgICAgICAgICAgIFJGQzcxODIgVGltZXN0YW1wcyBhbmQgSUNWcy4NCg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgKw0KDQogICAgICAgICAgICBSRkM3MTgzIHN0eWxl
IHRleHQgYnJpbmdpbmcgaXQgYWxsIHRvZ2V0aGVyLg0KDQpUaGUg4oCcYWdncmVnYXRlZCBzaWdu
YXR1cmVzIGFyb3VuZCBtdXRhYmxlIGZpZWxk4oCdIHdvdWxkIHZlcnkgYmUgYW4gZXhwZXJpbWVu
dGFsIGV4dGVuc2lvbi4NCg0KV2hhdCBJIG9iamVjdCB0byBpcywgaWYgdGhlIGJhc2Ugc3BlYyBz
cGVjaWZpY2FsbHkgcmVuZGVycyBzdWNoIGV4dGVuc2lvbnMgaW1wb3NzaWJsZQ0KDQoNCg0KLS0N
CkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lz
dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIx
OTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVh
cmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl
LCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBF
c3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVt
cy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdp
c3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNl
OiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJv
bTogTG90dGUgU3RlZW5icmluayBbbWFpbHRvOmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRl
XQ0KU2VudDogMTcgTWFyY2ggMjAxNiAxNjo0OA0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAo
VUspDQpDYzogaWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzxtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2Vu
Lm9yZz47IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0DQpTdWJqZWN0OiBSZTog
W21hbmV0XSBNZXNzYWdlIGludGVncml0eSBhbmQgbWVzc2FnZSBtdXRhYmlsaXR5ICh3YXMgUkU6
IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEgY291cGxlIG9mIGJpZyB0aWNr
ZXQgSXRlbXMpDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBm
cm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFy
dG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hv
dWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpG
b3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQg
Zm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50
LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9S
ZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBs
ZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5j
b20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRo
JTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KSGkgYWxsLA0KDQpBbSAxNy4wMy4yMDE2IHVt
IDE3OjQ0IHNjaHJpZWIgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgPGNocmlzLmRlYXJsb3Zl
QGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4+Og0K
DQpHb29kIHBvaW50IGFib3V0IHdoZXRoZXIgeW91IGp1c3QgcGFzcyBvbiBvbmUgY29zdCBvciBh
IHNldCBvZiBjb3N0cy4gQXMgSSBzYWlkLCBub3QgbG9va2VkIGF0IGRldGFpbHMgLSBJIHdpbGws
IHdoZW4gdGltZSBwZXJtaXRzLiBPbmUgY29zdCBpcyBtdWNoIGVhc2llciwgYW5kIHllcywgaXQg
cmVkdWNlcyB0aGUgZml4ZWQgc2l6ZSBhZ2dyZWdhdGVkIHNpZ25hdHVyZXMgcHJvYmxlbSB0byDi
gJxqdXN04oCdIG9uZSBvZiBjb21wdXRhdGlvbmFsIGxvYWQuDQoNCkZvciB0aGUgcmVjb3JkLCBU
aG9tYXPigJkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0OyB0aGUgY29zdCBpcyBvbmUgYWdncmVn
YXRlZCB2YWx1ZS4NCg0KQmVzdCByZWdhcmRzLA0KTG90dGUgU3RlZW5yYmluaw0KDQoNCi0tDQpD
aHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3Rl
bXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
DQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0
PiAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJs
b3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwg
Q2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNz
ZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMu
Y29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0
ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTog
U3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206
IGlldGZAdGhvbWFzY2xhdXNlbi5vcmc8bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmc+IFtt
YWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZ10NClNlbnQ6IDE3IE1hcmNoIDIwMTYgMTY6MzgN
ClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IE1vYmlsZSBBZCBIb2MgTmV0d29y
a3MgbWFpbGluZyBsaXN0DQpTdWJqZWN0OiBSZTogTWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3Nh
Z2UgbXV0YWJpbGl0eSAod2FzIFJFOiBbbWFuZXRdIGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEz
IHJldmlldyAtIGEgY291cGxlIG9mIGJpZyB0aWNrZXQgSXRlbXMpDQoNCg0KKioqIFdBUk5JTkcg
KioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlv
biwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25z
aWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3Bl
biBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJl
ZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwg
Y2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9z
ZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZl
ZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0
dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3Rs
aWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+
Lg0KDQpPbiAxNyBNYXIgMjAxNiwgYXQgMTc6MzAsIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp
IDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFl
c3lzdGVtcy5jb20+PiB3cm90ZToNCg0KSSBhcHByZWNpYXRlIFRob21hc+KAmXMgY29tbWVudHMg
YWJvdXQgdGhlIGxpbWl0YXRpb25zIG9mIG1lc3NhZ2UgcmVnZW5lcmF0aW9uLCBidXQgSSB3b3Vs
ZCBiZSBhIGJpdCBsZXNzIGFic29sdXRlLg0KDQpUaGUgaXNzdWVzIG92ZXIgZW5kIHRvIGVuZCBh
dXRoZW50aWNhdGlvbiBhbmQgbW9yZSBhZHZhbmNlZCBzaWduYXR1cmVzIGFyZSB2YWxpZC4gSSBu
ZWVkIHRvIHJlYWQgdGhlIGdpdmVuIHJlZmVyZW5jZSBvbiBhZ2dyZWdhdGUgc2lnbmF0dXJlcyB0
byBpbmNyZWFzZSBteSBrbm93bGVkZ2UgKHRoYW5rcyBmb3IgaXQpLCBidXQgbXkgdW5kZXJzdGFu
ZGluZyBvZiB0aGUgcG9zc2liaWxpdGllcyBpbiB0aGlzIGZpZWxkIG1heSBvZmZlciBhIHNvbHV0
aW9uIHRvIHRoZSBwcm9ibGVtLCBidXQgd2l0aCBzb21lIG90aGVyIGlzc3VlcyAocG9zc2libHkg
aW5jbHVkaW5nIGEgbmV3IHR5cGUgb2YgVExWKS4NCg0KQnV0IHRoZSBob3AgY291bnQvbGltaXQg
cG9pbnQgSSBkb27igJl0IGZ1bGx5IGFncmVlIHdpdGgsIHlvdSBjYW4gcmVnZW5lcmF0ZSB3aXRo
IGFuIGluY3JlbWVudGVkL2RlY3JlbWVudGVkIGNvdW50L2xpbWl0LCB3aGljaCBsZWF2ZXMgdGhl
IGFiaWxpdHkgdG8gcHJldmVudCBtZXNzYWdlcyBwcm9wYWdhdGluZyBpbmRlZmluaXRlbHksIGlu
Y2x1ZGluZyBleHBhbmRpbmcgcmluZyBzZWFyY2hlcywgYW5kIHJldGFpbnMgdGhlIGFiaWxpdHkg
dG8gdXNlIFJGQyA1NDk3IGludGVydmFsIGFuZCB2YWxpZGl0eSB0aW1lcyB0aGF0IG1pZ2h0IGJl
IHVzZWZ1bCB3aXRoIGFuIGV4cGFuZGluZyByaW5nIHNlYXJjaCAob3IgbWlnaHQgbm90KS4NCg0K
QnV0IHRoZSBrZXkgaXNzdWUgaXMgdGhhdCBBT0RWdjIgd2FudHMgdG8gYWNjdW11bGF0ZSBtZXRy
aWNzLiBJIHN0aWxsIGhhdmVu4oCZdCBnb3QgdG8gdGhlIGJvdHRvbSBvZiBtYW55IGRldGFpbHMg
aGVyZSwgYnV0IGxldOKAmXMgZm9yIHRoZSBtb21lbnQganVzdCBjb25zaWRlciB0aGF0IGNvbmNl
cHR1YWxseS4NCg0KSXTigJlzIGhhcmQgdG8gaGFuZGxlIGVuZCB0byBlbmQuIENoYXJsaWXigJlz
IGRyYWZ0IGF0dGVtcHRzIHRvIGRvIGFuIGVuZCB0byBlbmQgb2Ygc29tZSBpbmZvcm1hdGlvbiwg
bm90IHRoaXMgaW5mb3JtYXRpb24uIEnigJltIG5vdCBzdXJlIGlmIHRoYXTigJlzIHVzZWZ1bCAo
YW5kIHRoZSBzcGVjaWFsaXNlZCBmb3JtYXQgaXMgYmV0dGVyIGF2b2lkZWQgaWYgcG9zc2libGUp
LiBPdGhlciBhcHByb2FjaGVzIGFyZSBob3AgYnkgaG9wIChtaWdodCBhcyB3ZWxsIHVzZSBwYWNr
ZXQgc2lnbmF0dXJlcykgYW5kIHNoYXJlZCBrZXkgKG1pZ2h0IGFzIHdlbGwgZ28gaG9wIGJ5IGhv
cCkuIFBhaXJ3aXNlIHNpZ25hdHVyZXMgZm9yIGVhY2ggcGFpciBvZiByb3V0ZXJzIEnigJltIGRp
c2NvdW50aW5nIGFzIHNjYWxpbmcgdGVycmlibHkuIEluIHRoZSBpbnRlcmVzdHMgb2YgY29tcGxl
dGVuZXNzIGxldOKAmXMgbWVudGlvbiBub3QgYWNjdW11bGF0aW5nIG1ldHJpY3MsIHdoaWNoIHB1
dHMgdXMgYmFjayB0byBob3AgY291bnQgYW5kIHRoYXTigJlzIG5vdCBpZGVhbCBlaXRoZXIuDQoN
CkkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhbiBpZGVhbCBzb2x1dGlvbi4gKEkgbGlrZSBpZGVh
cyBJ4oCZdmUgc2VlbiBhYm91dCBhZ2dyZWdhdGluZywgYnV0IHRoYXQgaGFzIHNvbWUgaXNzdWVz
IG9mIGl0cyBvd24sIGV2ZW4gYXBhcnQgZnJvbSBjb21wdXRhdGlvbmFsIGxvYWQuKSBJ4oCZZCBs
b3ZlIHRvIGJlIHByb3ZlZCB3cm9uZyAtIHNvbWVvbmUgd2l0aCB0aGUgcGVyZmVjdCBzb2x1dGlv
biB0byBjb21lIGFsb25nLg0KDQpXaGljaCBtZWFucyB0aGF0IGVpdGhlciB3ZSBtYWtlIGFuIGFy
Yml0cmFyeSBjaG9pY2UgLSB3aGljaCB3aWxsIGJlIGRpc2FncmVlZCB3aXRoLCBidXQgbmVlZHMg
ZGlzY3Vzc2luZyBmaXJzdCAtIG9yIGNyZWF0ZSBzb21ldGhpbmcgZmxleGlibGUuIFVuZm9ydHVu
YXRlbHkgZmxleGlibGUgaW4gdGhhdCByZWdhcmQgY29uc3RyYWlucyBpbiBvdGhlcnMsIGUuZy4g
c29tZSAobWFueT8gbW9zdD8pIGFnZ3JlZ2F0aW5nIHNpZ25hdHVyZXMgbmVlZCBmaXhlZCBkYXRh
IHNpemVzICh3aGljaCB3ZSBjYW4gZG8gYnkgZGVmaW5pbmcgYSBUTFYgdGhhdCDigJxmaWxscyB1
cOKAnSB3aXRoIGhvcCBjb3VudCwgYnV0IHRoYXQgaGFzIGEgY29zdCB0b28pLg0KDQpJIGhhdmUg
YmVlbiB0b2xkIGJ5IHBlb3BsZSBtdWNoIG1vcmUgd2VsbCB2ZXJzZWQgaW4gdGhpcyB0aGFuIEkg
aW4gY3J5cHRvbG9neSwgdGhhdCB0aGUgY29ycmVjdCBhbnN3ZXIgaXMg4oCcc29tZeKAnS4NCg0K
VGhhdCBzYWlkLCAiQU9EVnYyIHdhbnRzIHRvIGFjY3VtdWxhdGUgbWV0cmljc+KAnSDigJQgZG9l
cyB0aGF0IG1lYW4gdGhhdCB0aGUgbWVzc2FnZSBncm93cyBhcyBpdCBpcyBiZWluZyBmb3J3YXJk
ZWQsIGFuZCB0aGF0IHRoZSByZWNpcGllbnQgb2YgYSBSUkVRL1JSRVAgd2lsbCBrbm93IHRoZSBp
bmRpdmlkdWFsIGNvc3RzIG9mIGVhY2ggcGF0aCBzZWdtZW50PyBNeSB1bmRlcnN0YW5kaW5nIGlz
LCB0aGF0IHRoZSByZWNpcGllbnQgd2lsbCBnZXQg4oCcdGhlIHN1bSB0aGUgY29zdHMgb2YgZWFj
aCBwYXRoIHNlZ21lbnTigJ0gd2hpY2ggc2hvdWxkIGJlIGZpdHRpbmcgd2l0aGluIGEgZml4ZWQg
c2l6ZT8NCg0KVGhvbWFzDQoNCg0KDQpTb3JyeSwgbm8gYW5zd2VycywganVzdCBjb21tZW50cy4g
QW5kIEnigJltIG5vdCBhZGRyZXNzaW5nIFRob21hc+KAmXMgbGF0ZXIgcG9pbnRzIGhlcmUuDQoN
Ci0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFF
IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIw
MjQyMTk0PiAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlz
LmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln
ZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9y
ZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5
c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0K
UmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9m
ZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoN
CkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IGlldGZAdGhvbWFzY2xhdXNlbi5vcmc8bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmc+DQpT
ZW50OiAxNyBNYXJjaCAyMDE2IDE2OjAwDQpUbzogTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWls
aW5nIGxpc3QNClN1YmplY3Q6IFttYW5ldF0gZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2
aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcw0KDQoNCioqKiBXQVJOSU5HICoqKg0K
VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVp
dGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIg
Y2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55
IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxh
Z3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNr
IGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJp
dHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRo
ZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8v
aW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRz
L0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCioq
KiBXQVJOSU5HICoqKg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMg
ZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb24uDQoNCkRlYXIgYWxsLA0KDQpBcG9sb2dpZXMg
Zm9yIG5vdCBoYXZpbmcgZ290dGVuIHRoaXMgZG9uZSBzb29uZXIgLSBkYXktam9iIGxlYXZpbmcg
ZmV3IHNwYXJlIGN5Y2xlcy4NCg0KSeKAmXZlIHByZXZpb3VzbHkgb2ZmZXJlZCByZXZpZXdzIGFu
ZCBjb21tZW50cywgYW5kIHNvbWUgb2YgdGhvc2UgaGF2ZSBiZWVuIGFkZHJlc3NlZCBpbiB0aGUg
bGF0ZXN0IEktRCDigJQgb3RoZXJzIGhhdmUgbm90LCBidXQgc2hvdWxkIGJlLiBJIHJlY2FsbCB0
aGF0IHRoZXJlIHdhcyBzb21lIG1haWwgYXR0ZW1wdGluZyB0byByZWJ1dCBwYXJ0cyBvZiB0aGUg
cmV2aWV3LCBhbmQgSSB3aWxsIGRpZyBpdCBvdXQgYW5kIHJlcGx5IHRvIHRoYXQuDQoNCldpdGgg
dGhhdCBiZWluZyBzYWlkLCBJIGhhdmUgcmV2aWV3ZWQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRo
ZSBkb2N1bWVudCwgYW5kIGZ1bGwgZGV0YWlscyB3aWxsIGJlIGZvcnRoY29taW5nLiBUaGVyZeKA
mXJlIGEgY291cGxlIG9mIGJpZy10aWNrZXQvYXJjaGl0ZWN0dXJhbCBpdGVtcyB0aGF0IEkgd2Fu
dCB0byBhZGRyZXNzIHVwIGZyb250LCBhcyBJIGJlbGlldmUgdGhhdCBiZWZvcmUgd2UgaGF2ZSB0
aG9zZSBoYW1tZXJlZCBvdXQsIGl0IHdpbGwgYmUgdXNlbGVzcyB0byBnbyBpbnRvIGRldGFpbHMu
IE5vdGUsIEkgZG8gbm90IGNsYWltIHRoYXQgdGhpcyBpcyBhbiBleGhhdXN0aXZlIGxpc3Qgb2Yg
4oCcYmlnIHRpY2tldCBpdGVtc+KAnSwgYnV0IHRoYXTigJlzIGFzIGZhciBhcyBJIGhhdmUgZ290
dGVuIGluIHRoaW5raW5nIHRoaXMgdGhyb3VnaC4NCg0KSSBhbHNvIGJyaW5nIHRoZXNlIHVwIGFz
IHRoZXkgYXJlIGl0ZW1zIHRoYXQgaGF2ZSBiZWVuIGJyb3VnaHQgdXAgcmVwZWF0ZWRseSBvdmVy
IHRoZSBwYXN0IHllYXJzLCBidXQgbm90IHJlc29sdmVkIG5vciBkaXNjdXNzZWQuDQoNCkxvb3Bz
DQpKdXN0IHRvIGJyaW5nIHRoaXMgb3V0OiBJIHNoYXJlIENocmlz4oCZIHdvcnJ5IGFib3V0IGNv
bmZsaWN0aW5nIGFuZCBjb25jdXJyZW50IHN0YXRlbWVudHMgZnJvbSB0aGUgYXV0aG9ycyBvbiDi
gJxUaGVyZSBhcmUgbm8gbG9vcHMgcG9zc2libGXigJ0gYW5kIOKAnFdlIG5lZWQgdG8gZml4IHR3
byBzaXR1YXRpb25zIHdoZXJlIGxvb3BzIGNhbiBvY2N1cuKAnSBhbmQg4oCcd2UgYXJlIHN0aWxs
IGludmVzdGlnYXRpbmcgc29tZSBsb29wIGNvbmRpdGlvbnPigJ0NCg0KSSBwYXJ0aWN1bGFybHkg
d29ycnkgdGhhdCB0aGlzIGlzIG5vdCBhIGRpc2N1c3Npb24gaGFkIGluIHB1YmxpYywgYnV0IGFw
cGFyZW50bHkgaW4gc29tZSBvdGhlciBmb3J1beKApg0KDQoNCkludGVybWVkaWF0ZSBSb3V0ZSBS
ZXBsaWVzLCBhbmQgYWxsIG9mIHNlY3Rpb24gMTANClNlY3Rpb24gMTAgY29udGFpbnMgYSBzZXQg
b2Yg4oCcdmFndWVseSBzcGVjaWZpZWQgZXh0ZW5zaW9uc+KAnSwgd2hpY2ggaXMgaW5jb2hlcmVu
dCB3aXRoIHRoZSBpbnRlbmRlZCBzdGF0dXMgaW5kaWNhdGVkIGZvciB0aGlzIGRvY3VtZW50Lg0K
DQpTcGVjaWZpY2FsbHksIGFuZCB0aGlzIGlzIG5vdCB1bnJlbGF0ZWQgdG8gdGhlIHBvaW50IGFi
b3V0IGxvb3BzIGFib3ZlLCBpbnRlcm1lZGlhdGUgUlJFUHMgKHNlY3Rpb24gMTAuMykgYXJlIGEg
cG90ZW50aWFsIHNvdXJjZSBmb3IgbG9vcHMuDQoNCkV4cGFuZGluZyBSaW5nIE11bHRpY2FzdCAo
c2VjdGlvbiAxMC4xKSBpcyBub3QgZG9jdW1lbnRlZCBpbiBhIHdheSB0aGF0IGNhbiBiZSBpbXBs
ZW1lbnRlZCAoYW5kIGFsc28sIHNlZSDigJxGb3J3YXJkaW5nLXZzLXJlZ2VuZXJhdGlvbuKAnSBi
ZWxvdywgaXQgaXMgaW4gdGhlIHByZXNlbnQgZm9ybSBvZiB0aGlzIHByb3RvY29sIGltcG9zc2li
bGUpLCBldGMuDQoNCg0KRm9yd2FyZGluZy12cy1yZWdlbmVyYXRpb24NClJlY2VudCBleGNoYW5n
ZXMgb24gdGhlIGxpc3QgbWFkZSBtZSB1bmRlcnN0YW5kIHRoYXQgcHJvdG9jb2wgY29udHJvbCBt
ZXNzYWdlcyBhcmUgKm5vdCogZm9yd2FyZGVkLCBidXQgYXJlIGNvbnN1bWVkIGF0IGVhY2ggaG9w
LCB0aGVuIGEgbmV3IG1lc3NhZ2Ugd2l0aCAoYWxtb3N0LWJ1dC1ub3QtcXVpdGUpIHRoZSBzYW1l
IGNvbnRlbnQgaXMgZ2VuZXJhdGVkIGFuZCB0cmFuc21pdHRlZC4NCg0KSSBoYXZlIHRob3VnaHQg
c29tZSBtb3JlIG9uIHRoaXMgKCYgcmVhZCBzb21lIG9mIHRoZSBleGNoYW5nZXMgb24gdGhlIGxp
c3Qgb24gdGhpcyB0b3BpYyBieSBDaHJpcywgVWxyaWNoLCBhbmQgb3RoZXJzKSwgYW5kIEkgYW0g
Y29udmluY2VkIHRoYXQgdGhpcyBpcyBub3QgdGhlIHJpZ2h0IHdheSB0byBnbywgYXQgbGVhc3Qg
Zm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczoNCg0KDQogICAgICAgICAgICBvICAgICAgICAgIEl0
IHJlbmRlcnMgdGhlIGhvcC1saW1pdC9ob3AtY291bnQgZmllbGRzIGluIHRoZSBSRkM1NDQ0IG1l
c3NhZ2UgaGVhZGVyIHVzZWxlc3MuDQogICAgICAgICAgICAgICAgICAgICAgICBUaGlzIHdvdWxk
IG5vdCBiZSBiYWQgaWYgdGhlIGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBieSB0aG9zZSBmaWVsZHMg
d2FzIG5vdCB1c2VmdWwNCiAgICAgICAgICAgICAgICAgICAgICAgIOKAlCBzYWRseSwgaXQgaXMu
IEZvciBleGFtcGxlLCBmb3Igc2NvcGUgbGltaXRlZCBmbG9vZGluZyAoZXhwYW5kaW5nIHJpbmcg
c2VhcmNoLCBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgIHN1Y2gpIHdoaWNoIG1heSBiZSBv
ZiBpbnRlcmVzdCwgYW5kIHdoaWNoIHJlcXVpcmUgaG9wLWxpbWl0Lg0KICAgICAgICAgICAgICAg
ICAgICAgICAgQSBob3AtY291bnQgZmllbGQgbWF5IGFsc28gcHJvdmlkZSBhIOKAnGNoZWFw4oCd
IChpbiB0ZXJtcyBvZiBvdmVyaGVhZCkgYWRkaXRpb25hbCBwaWVjZQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgb2YgaW5mb3JtYXRpb24gdG8gdXNlIGNvbmp1bmN0aXZlbHkgd2l0aCBhIOKAnHJl
YWzigJ0gbWV0cmljLg0KDQogICAgICAgICAgICAgICAgICAgICAgICBUaGUgb25seSBwcmFjdGlj
YWwgc29sdXRpb24gd291bGQgYmUgdG8gcmUtaW50cm9kdWNlIHRoZXNlIGZ1bmN0aW9ucyBieSB3
YXkgb2YgaW5zZXJ0aW5nIGENCiAgICAgICAgICAgICAgICAgICAgICAgIE1lc3NhZ2VUTFYg4oCU
IHdoaWNoIChpKSBpcyBub3Qgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQsIGFuZCAoaWkpIHdo
aWNoIHdvdWxkIGp1c3QNCiAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZlIHRvIHJlbmRlciBt
ZXNzYWdlcyBiaWdnZXIgdGhhbiBzdHJpY3RseSBuZWVkZWQuDQoNCiAgICAgICAgICAgICAgICAg
ICAgICAgIFNjb3BlIGxpbWl0ZWQgZmxvb2RpbmcgIGRvZXMgc2VlbSB0byBiZSBhIG5lY2Vzc2Fy
eSByZXF1aXJlbWVudCwgaWYgZm9yIG5vDQogICAgICAgICAgICAgICAgICAgICAgICBvdGhlciBy
ZWFzb24gdGhhbiB0byBwcmV2ZW50IGluZm9ybWF0aW9uIGZyb20g4oCcY2lyY3VsYXRpbmcgZm9y
ZXZlciBpbiB0aGUgbmV0d29ya+KAnS4NCg0KICAgICAgICAgICAgbyAgICAgICAgICBJdCBtYWtl
cyBlbmQtdG8tZW5kIGF1dGhlbnRpY2F0aW9uIHVubmVjZXNzYXJpbHkgaGFyZC4NCiAgICAgICAg
ICAgICAgICAgICAgICAgIEkgdGhpbmsgQ2hyaXMgY2FsbGVkIHRoaXMgb3V0IGFscmVhZHksIGJ1
dCBpdCBiZWFycyByZXBlYXRpbmc6IFMgZ2VuZXJhdGVzIGEgbWVzc2FnZQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgKHNheSwgYSBSUkVRKSwgYW5kIGluY2x1ZGVzIGFuIElDViBjYWxjdWxhdGVk
IG92ZXIgdGhlIGNvbnRlbnQgb2YgdGhlIG1lc3NhZ2UuDQogICAgICAgICAgICAgICAgICAgICAg
ICBGb3IgYW55IHJlY2lwaWVudCB0byBiZSBhYmxlIHRvIHZhbGlkYXRlIHRoZSBJQ1YsIHRoZSBt
ZXNzYWdlIGhhcyB0byBiZSBleGFjdGx5DQogICAgICAgICAgICAgICAgICAgICAgICB0aGUgc2Ft
ZSDigJQgbm90IGp1c3QgaW4gY29udGVudCwgYnV0IGluIHN0cnVjdHVyZSDigJQgYXMgd2hhdCB3
YXMgZ2VuZXJhdGVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICDigJxSZWdlbmVyYXRpbmfi
gJ0gcmF0aGVyIHRoYW4g4oCcZm9yd2FyZGluZ+KAnSBtZXNzYWdlcyBtZWFucywgdGhhdCB0aGUg
aW50ZXJtZWRpYXRlDQogICAgICAgICAgICAgICAgICAgICAgICByb3V0ZXIg4oCccmVnZW5lcmF0
aW5n4oCdIHRoZSBSUkVRIG1heSBjaG9zZSBhIGRpZmZlcmVudCBzdHJ1Y3R1cmUgKGUuZy4sIGlu
Y2x1ZGUgVExWcw0KICAgICAgICAgICAgICAgICAgICAgICAgaW4gYSBkaWZmZXJlbnQgb3JkZXIp
Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICBUaGUgcHJvcG9zYWwgZnJvbSBodHRwczovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMA0KICAg
ICAgICAgICAgICAgICAgICAgICAgaXMgdG8gYWRkIGNvbnN0cmFpbnRzIG9uIChpKSB0aGUgc2V0
IG9mIGVsZW1lbnRzIHRvIGluY2x1ZGUgaW4gYSBzaWduYXR1cmUgYW5kIChpaSkgdGhlDQogICAg
ICAgICAgICAgICAgICAgICAgICBvcmRlciBvZiB0aGVzZSBlbGVtZW50cy4NCg0KICAgICAgICAg
ICAgICAgICAgICAgICAgT25lIHByb2JsZW0gd2l0aCB0aGF0IGFwcHJvYWNoIGlzIChpKTogaWYg
YW4gZXh0ZW5zaW9uIGFkZHMgYSBtZXNzYWdlIFRMViwgb3IgYW4NCiAgICAgICAgICAgICAgICAg
ICAgICAgIEFkZHJlc3MgVExWLCB0byBhIG1lc3NhZ2UsIHRoZW4gdGhhdCB3aWxsIG5vdCBiZSDi
gJxjb3ZlcmVk4oCdIGJ5IHRoZSBwcm9wb3NlZCBlMmVzZWMgVExWLg0KICAgICAgICAgICAgICAg
ICAgICAgICAgUmF0aGVyIGZvciAqZWFjaCogZXh0ZW5zaW9uIGRldmVsb3BlZCwgYW4g4oCcdXBk
YXRlcyBlMmVzZWPigJ0gY2xhdXNlIG5lZWRzIHRvIGJlIGRvbmUuDQoNCiAgICAgICAgICAgICAg
ICAgICAgICAgIEnigJlkIHNheSB0aGF0IHRoaXMgYXBwcm9hY2ggd291bGQgYmUgcHJvbmUgdG8g
ZXJyb3JzIOKAlCBhbmQgYWRkIGVudHJvcHkgdG8gdGhlIHByb2Nlc3MNCiAgICAgICAgICAgICAg
ICAgICAgICAgIG9mIGRlc2lnbmluZyBwcm90b2NvbCBleHRlbnNpb25zLiBUaGUgYWx0ZXJuYXRp
dmUsIGEgbWVzc2FnZSBiZWluZyBnZW5lcmF0ZWQgYnkgdGhlDQogICAgICAgICAgICAgICAgICAg
ICAgICBzb3VyY2UgYW5kICpmb3J3YXJkZWQqIChhcyB3ZSBkbyBpbiBPTFNSdjIsIGZvciBleGFt
cGxlKSB3b3VsZCBhbGxvdyBJQ1YgVExWcw0KICAgICAgICAgICAgICAgICAgICAgICAgKGV2ZW4s
IGFsbG93IHJldXNlIG9mIHRob3NlIHNwZWNpZmllZCBmb3IgT0xTUnYyKSBmb3IgY292ZXJpbmcg
YSBtZXNzYWdlIGFuZA0KICAgICAgICAgICAgICAgICAgICAgICAgZXh0ZW5zaW9ucy4NCg0KICAg
ICAgICAgICAgICAgICAgICAgICAg4oCcQnV0IHdoYXQgYWJvdXQgdGhlIG1ldHJpY3MgdmFsdWUg
d2hpY2ggd2lsbCBjaGFuZ2Ugb24gZWFjaCBob3DigJ0sIHlvdSBtYXkgc2F5Pw0KICAgICAgICAg
ICAgICAgICAgICAgICAgRm9ydHVuYXRlbHksIHRoYXQgaXMgcmVsYXRpdmVseSBlYXN5IHRvIGhh
bmRsZTogc2ltcGx5IHplcm8gb3V0IHRoZSB2YWx1ZSBvZiB0aGF0IFRMViB3aGVuDQogICAgICAg
ICAgICAgICAgICAgICAgICBnZW5lcmF0aW5nIG9yIHZlcmlmeWluZyB0aGUgSUNWIE1lc3NhZ2VU
TFYuIEFuZCB1c2UgUGFja2V0LVRMVnMgZm9yIGhvcC1ieS1ob3ANCiAgICAgICAgICAgICAgICAg
ICAgICAgIGF1dGhlbnRpY2F0aW9uLCBpZiBuZWVkZWQgKGJ1dCwgc2VlIGJlbG93KS4NCg0KICAg
ICAgICAgICAgbyAgICAgICAgICBJdCBwcmV2ZW50cyB0aGUgdXNlIG9mIG1vcmUgY2xldmVyL2Fk
dmFuY2VkIHNpZ25hdHVyZSBzY2hlbWVzL0lDVnMNCiAgICAgICAgICAgICAgICAgICAgICAgIEFn
Z3JlZ2F0ZSBzaWduYXR1cmUgYWxnb3JpdGhtcyAoIGh0dHBzOi8vY3J5cHRvLnN0YW5mb3JkLmVk
dS9+ZGFiby9wYXBlcnMvYWdnc3VydmV5LnBkZikNCiAgICAgICAgICAgICAgICAgICAgICAgIGV4
aXN0LCBhbmQgYW4gaW50ZXJlc3RpbmcgdXNlLWNhc2UgY2FuIGJlIGZvdW5kIGluIGFsc28gcmVh
Y3RpdmUgcHJvdG9jb2xzLCBhbGxvd2luZyB2ZXJpZnlpbmcNCiAgICAgICAgICAgICAgICAgICAg
ICAgIG5vdCDigJxqdXN04oCdIHRoZSBlbmQgcG9pbnRzLCBidXQgYWxzbyB0aGUgaW50ZXJtZWRp
YXJpZXMgKGFnYWluLCB3aXRoIHRoZSBhcHByb3ByaWF0ZSDigJx6ZXJvIG91dOKAnQ0KICAgICAg
ICAgICAgICAgICAgICAgICAgZGlzY3Vzc2VkIGFib3ZlLCBvciBzb21ldGhpbmcgc21hcnRlciku
DQogICAgICAgICAgICAgICAgICAgICAgICBSZWdlbmVyYXRpb24gb2YgbWVzc2FnZXMsIHJhdGhl
ciB0aGFuIGZvcndhcmRpbmcsIHJlbmRlcnMgdGhhdCBpbXBvc3NpYmxlIChvciwgaWYgdXNlZCwN
CiAgICAgICAgICAgICAgICAgICAgICAgIHVwZGF0aW5nIHRvICBodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMCkNCg0KVGhlcmUgYXJl
IG90aGVyIHJlYXNvbnMsIGJ1dCB0aGUgYWJvdmUgYXJlIHRob3NlIHRoYXQganVtcCBhdCBtZSBh
cyBpbW1lZGlhdGUgc2hvdy1zdG9wcGVycy4NCg0KSSBkbyBob25lc3RseSBub3Qgc2VlIHdoYXQg
cG9zc2libGUgYmVuZWZpdCB0aGVyZSBpcyBmcm9tIOKAnHJlZ2VuZXJhdGlvbuKAnSDigJQgYnV0
IEkgc2VlIHZlcnkgY2xlYXIgaW5jb252ZW5pZW5jZXMsIGFuZCBzZWN1cml0eSBpcyBub3QgdGhl
IGxlYXN0IG9mIHRoZXNlLiBJbnNpc3Rpbmcgb24g4oCccmVnZW5lcmF0aW9u4oCdIHJlcXVpcmVz
IGRldmVsb3BtZW50IG9mIOKAnG5vbi1nZW5lcmFsIHdvcmthcm91bmRz4oCdIGFzIHBvaW50ZWQg
b3V0IGFib3ZlLg0KDQpTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KVGhpcyBpcyBhbiBhbHdheXMg
dGhvcm55IHN1YmplY3QuIFdoZW4gT0xTUnYyIHdhcyBnb2luZyB0aHJvdWdoIHRoZSBwcm9jZXNz
IHdlIGdvdCBhIHRob3JvdWdoIGVkdWNhdGlvbiBpbiBob3cgbGl0dGxlIHdlIGtuZXcgYWJvdXQg
c2VjdXJpdHkgZnJvbSB0aGUgU0VDLUFEcywgYW5kIGhhZCB0byBzcGVuZCBhYm91dCBhIHllYXIg
b3Igc28gZGV2ZWxvcGluZyBSRkM3MTgzLiBUaGUgYm90dG9tIGxpbmUgaXMsIHRoYXQgdGhpcyBw
cm90b2NvbCBuZWVkcyBpdHMg4oCcUkZDNzE4MyAgZXF1aXZhbGVudOKAnSwgZWl0aGVyIGFzIHBh
cnQgb2YgdGhlIG1haW4gZG9jdW1lbnQsIG9yIGFzIGFuIGluZGVwZW5kZW50IGRvY3VtZW50LiBj
dXJyZW50bHksIHRoYXQgaXMgbm90IHRoZSBjYXNlLg0KDQpBIG1pbmltYSwgbG9va2luZyBhdCBC
Q1A3MiBhbmQgQkNQMTA3IOKAlCB0YWtpbmcgaW5zcGlyYXRpb24gZnJvbSBSRkM3MTgzIG1pZ2h0
IGJlIGF3IGdvb2QgaWRlYSwgYXMgdGhhdCB3YXMgdGhlIG1vc3QgcmVjZW50IHRoYXQgd2VudCB0
aHJvdWdoIHRoZSBTRUMgQUQuIFJlZ2FyZGxlc3Mgb2YgaG93LCBob3dldmVyLCBhIOKAnG1hbmRh
dG9yeSB0byBpbXBsZW1lbnTigJ0gc2VjdXJpdHkgbWVjaGFuaXNtIG1vc3QgYmUgc3BlY2lmaWVk
IChJIHRoaW5rIHRoZSByaWdodCB0ZXJtIHdhcyDigJxNVVNUIGltcGxlbWVudCwgU0hPVUxEIHVz
ZeKAnSksIGluIHN1ZmZpY2llbnQgZGV0YWlsIHRvIGVuc3VyZSBpbnRlcm9wZXJhYmxlIGltcGxl
bWVudGF0aW9ucy4NCg0KQXMgYW4gZXhhbXBsZSwgYm90aCBbUkZDNjEzMF0gYW5kIFtSRkM3MTgx
XSBzZXQgb3V0IHRoYXQgdGhhdDoNCg0KICAgICAgT24gcmVjZWl2aW5nIGEgLi4uIG1lc3NhZ2Us
IGEgcm91dGVyIE1VU1QgZmlyc3QgY2hlY2sgaWYgdGhlDQogICAgICBtZXNzYWdlIGlzIGludmFs
aWQgZm9yIHByb2Nlc3NpbmcgYnkgdGhpcyByb3V0ZXINCg0KYW5kIHRoZW4gcHJvY2VlZCB0byBn
aXZlIGEgbnVtYmVyIG9mIGNvbmRpdGlvbnMgdGhhdCwgZWFjaCwgd2lsbCBsZWFkIHRvIGEgcmVq
ZWN0aW9uIG9mIHRoZSBtZXNzYWdlIGFzICJiYWRseSBmb3JtZWQgYW5kIHRoZXJlZm9yZSBpbnZh
bGlkIGZvciBwcm9jZXNzaW5n4oCdIOKAlCBhIGxpc3Qgd2hpY2ggUkZDNzE4MyB0aGVuIGFtZW5k
ZWQuIFRoYXQgZ2F2ZSBhIOKAnGhvb2vigJ0gZm9yIFJGQzcxODMgZm9yIGluc2VydGluZyDigJxy
ZWplY3Rpb27igJ0uIElkZW0gZm9yIG1lc3NhZ2UgZ2VuZXJhdGlvbi4NCg0KSWYgSSB3YXMgdG8g
ZG8gUkZDNzE4MS9SRkM2MTMwIHRvZGF5LCBJIHdvdWxkIGluY2x1ZGUgdGhhdCBkaXJlY3RseSBp
bnRvIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucy4gSXQgdHVybmVkIG91dCB0byBiZSBtb3Jl
IG92ZXJoZWFkIChhbmQgc2xvdyBkb3duIHB1YmxpY2F0aW9uIGFueXdheXMpIHRvIGRvIGl0IGFz
IHNlcGFyYXRlIGRvY3VtZW50cy4NCg0KU2Vjb25kbHksIHdlIG5lZWQgdG8gYmUgYSBsb3QgbW9y
ZSByaWdpZCBpbiB0ZXJtcyBvZiB3aGF0IElDVnMsIFRpbWVzdGFtcHMsIGV0Yy4gYXJlIGFkZGVk
L3JlbW92ZWQsIGFuZCB3aGF0IHRoYXQgYnJpbmdzLg0KDQpGb3IgZXhhbXBsZSAod2l0aCB0aGUg
YXNzdW1wdGlvbiB0aGF0IG1lc3NhZ2VzIGFyZSAqZm9yd2FyZGVkKiBhbmQgKm5vdCogcmVnZW5l
cmF0ZWQpLCB0aGlzIGNvdWxkIGJlIG9uZSBvcHRpb246DQoNCiAgICAgICAgICAgICAgICAgICAg
ICAgIG8gICAgICAgICAgV2hlbiBhIFJSRVEsIFJSRVAgbWVzc2FnZSBpcyBnZW5lcmF0ZWQsIGFk
ZCBhbiBJQ1YgTWVzc2FnZSBUTFYsIHdoaWNoIGlzIGNhbGN1bGF0ZWQgPHRoaXMgd2F5Pg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIOKApih0YWtlIGluc3BpcmF0aW9uIGZy
b20gUkZDNzE4MyBoZXJlKQ0KDQouLi4NCg0KW01lc3NhZ2UgY2xpcHBlZF0NCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QN
Cm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8
bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9tYW5ldA0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz
IGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkDQpyZWNpcGllbnQgYW5kIG1heSBhbHNv
IGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50IHBs
ZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuDQpZ
b3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Ns
b3NlIG9yDQpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLg0KKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYu
b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQoNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1h
aWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5l
dEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCg==

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B15B0GLKXM0002VGREEN_
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
Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD
aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N
c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs
InNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBw
bGUtdGFiLXNwYW47fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt
ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z
by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7
fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBD
aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g
VGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT
dHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K
CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl
IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy
LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv
bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs
dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk
bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu
ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJw
dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBhY3R1YWxseSB0
b29rIHdoYXQgYmVjYW1lIFJGQyA1NDQ0IHRvIHRoZSBJRVNHIHdpdGggYSBUTFYgb3JkZXJpbmcg
cmVxdWlyZW1lbnQuIEl0IHdhc27igJl0IGFjY2VwdGFibGUuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmQgeWVzLCB0
aGV5IHNhdmVkIHVzIGZyb20gYW4gZXJyb3Igd2Ugd291bGQgaGF2ZSBtYWRlLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8bzpwPjwvbzpwPjwvc3Bh
bj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu
MHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9w
aGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0
ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0Ui
Pjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+
VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5i
c3A7JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8ICZuYnNwOzxiPkU6DQo8L2I+PGEgaHJl
Zj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5kZWFybG92ZUBi
YWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVj
aG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJy
Pg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8
YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0
b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0
ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1Uy
IDdZUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w
OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PiBpZXRmQHRob21hc2NsYXVzZW4ub3JnIFttYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZ10N
Cjxicj4NCjxiPlNlbnQ6PC9iPiAyNSBBcHJpbCAyMDE2IDE1OjI5PGJyPg0KPGI+VG86PC9iPiBK
dXN0aW4gRGVhbjxicj4NCjxiPkNjOjwvYj4gRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk7IENo
cmlzdG9waGVyIERlYXJsb3ZlOyBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdDsg
VmljdG9yaWEgTWVyY2llY2E8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gTWVzc2Fn
ZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2UgbXV0YWJpbGl0eSAod2FzIFJFOiBkcmFmdC1pZXRmLW1h
bmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKTxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBw
dDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu
OmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i
bWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+
DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3Nh
Z2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20g
YW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNv
bnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBv
cGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48L3NwYW4+PC9pPjxz
dHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwv
c3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMz
Mzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLA0K
IGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3
b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiI+DQpoZXJl
PC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5
NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lv
dXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVt
cy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBX
aXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3NwYW4+
PC9lbT48L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPk9uIDI1IEFwciAyMDE2LCBhdCAxNjoyMCwgSnVzdGluIERlYW4gJmx0OzxhIGhyZWY9
Im1haWx0bzpiZWJlbWFzdGVyQGdtYWlsLmNvbSI+YmViZW1hc3RlckBnbWFpbC5jb208L2E+Jmd0
OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEg
dGhvdWdodCByZWdhcmRpbmcgaW50ZWdyaXR5IGNoZWNraW5nLiZuYnNwOyBBIHBvc3NpYmxlIGZ1
dHVyZSAmcXVvdDtmaXgmcXVvdDsgZm9yIGludGVncml0eSBjb3VsZCBiZSBkb25lIG9uIGEgJnF1
b3Q7dmlydHVhbCZxdW90OyBwYWNrZXQgaW4gd2hpY2gga25vd24gVExWcy92YWx1ZXMgYWxvbmcg
d2l0aCBvcmRlcmVkIGFkZHJlc3NlcyBhcmUgdW5jb21wcmVzc2VkIGFuZCB0aGVuIHZlcmlmaWVk
LiZuYnNwOyBJdCBjb3VsZCBhbGxvdyBleHRyYSBUTFYgdGFnZ2luZw0KIHdpdGhvdXQgbW9kaWZ5
aW5nIHRoZSB2YWxpZGl0eSBvZiB0aGF0IGRhdGEuJm5ic3A7IFRoZSB2ZXJ5IGJpZyBkcmF3YmFj
ayB3b3VsZCBiZSB0aGUgb3ZlcmhlYWQgb2YgaGF2aW5nIHRvIHVuY29tcHJlc3NlZCBldmVyeXRo
aW5nIHRvIGNoZWNrIHRoZSB2YWxpZGl0eS4mbmJzcDsgSXQncyBmdW5jdGlvbmFsbHkgdGhlIHNh
bWUgYXMgemVyb2luZyBvdXQgbG9jYWwgKHRoaXMgaXMgbXkgc3R1ZmYpIFRMViBkYXRhIHZzIHJl
bW90ZSAodGhpcyBpcyBub3QgbXkgc3R1ZmYpDQogVExWIGRhdGEuICZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+VGhhdCByZXF1aXJlcyBhbiBpbXBvc2VkIG9yZGVyaW5nIG9mIGFkZHJlc3NlcywgYWRkcmVz
cyBUTFZzLCBNZXNzYWdlIFRMVnMsIGV0Yy4sIGV2ZW4gaWYgb25seSDigJxpbiBtZW1vcnnigJ0s
IGl0IGlzIHNvbWV0aGluZyB0aGF0IGV2ZXJ5Ym9keSBzaG91bGQgYmUgYXdhcmUgb2YsIGFuZCBk
b2luZyB0aGUgc2FtZSB3YXk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9z
cGFuPm88c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPlRoYXQgb3JkZXJpbmcgd291
bGQgaGF2ZSB0byBiZSBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCAobm8sIGl0IHdvdWxkIG5v
dCBiZSBhIOKAnGZ1dHVyZSBmaXjigJ0sIHRoaXMgaXMmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWIt
c3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCmEgcmVxdWlyZW1lbnQgdG8g
dGhlIGJhc2Ugc3BlYywgc2luY2UgKm5vdCogZG9pbmcgdGhhdCB3b3VsZCBtZWFuIHRoYXQgdGhp
cyDigJxmdXR1cmUgZml44oCdIGNvdWxkIHJlbmRlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KY3VycmVudCBpbXBsZW1lbnRhdGlvbnMg
bm9uLWNvbXBsaWFudCEpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bh
bj5vPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5XaGlsZSB0aGlzIHdvdWxkIGJl
ICpoYXJkKiBmb3IgdGhlIGN1cnJlbnQgbWVzc2FnZXMvVExWcywgSeKAmWQgaW1hZ2luZSB0aGF0
IGl04oCZZCBtYWtlIGV4dGVuc2lvbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCmltcG9zc2libGUgKGluIGFuIGludGVyb3BlcmFibGUg
ZmFzaGlvbikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5vPHNw
YW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5JdOKAmWQgYmUgKmV4Y2VwdGlvbmFsbHkq
IGhlYXZ5IGZvciBhbGwgaW50ZXJtZWRpYXRlIHJvdXRlcnMsIHdhbnRpbmcgdG8gdmVyaWZ5IHRo
ZSBpbnRlZ3JpdHkgb2YgYSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KbWVzc2FnZTogdG8gYmUgYWJsZSB0byBmb3JjZSBldmVy
eWJvZHkgaW4gYSBuZXR3b3JrIHRvIOKAnHVud3JhcOKAnSB0aGUgbWVzc2FnZSBpbnRvIGFuJm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw
YW4+DQp1bmNvbXByZXNzZWQgZm9ybSAqYmVmb3JlKiB2YWxpZGF0aW5nIGl0cyBvcmlnaW5zIGlz
IG9wZW5pbmcgdXAgZm9yIERvUyBhdHRhY2tzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw
YW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQpJIHdhbnQgdG8gZG8gYSAqbWlu
aW11bSogbnVtYmVyIG9mIG9wZXJhdGlvbnMgd2l0aCBhIG1lc3NhZ2UsICpiZWZvcmUqIGRlY2lk
aW5nJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyA8L3NwYW4+DQp0byBkaXNjYXJkIGEgbWVzc2FnZSBhcyBoYXJtZnVsLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgZm9yIHRo
ZSBSUkVQLUFjayBoYXZpbmcgYSBmbGFnIHZzIGFuIGFkZHJlc3MgZG9lc24ndCBtdWNoIGJvdGhl
ciBtZSBhcyBlaXRoZXIgd291bGQgaGF2ZSB0byBiZSB6ZXJvZWQgb3V0IGZvciB0aGlzIHR5cGUg
b2YgZnV0dXJlIGludGVncml0eSBjaGVja2luZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgbm90IGEgcXVlc3Rpb24gb2YgZnV0
dXJlIGludGVncml0eSBjaGVja2luZywgYnV0IGEgcmVxdWlyZW1lbnQgZm9yIHRoZSBiYXNlIHNw
ZWNpZmljYXRpb24gdG8gYmUgYWJsZSB0byBzdXBwb3J0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaG9tYXM8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86
cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3Rpbjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBcHIg
MjUsIDIwMTYgYXQgOToyNyBBTSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgJmx0OzxhIGhy
ZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
PmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzc3VtaW5nIGZvciB0aGUgbW9tZW50IHRoYXQg
ZXZlcnlvbmUgd2lsbCBuZWVkIGFuIFJSRVAtQWNrIG9yIHdvbuKAmXQgKGxldOKAmXMgY29tZSBi
YWNrIHRvIHRoYXQpIHdoeQ0KIGRvIEMgYW5kIEIgbmVlZCB0byBwdXQgYW4gYWRkcmVzcyBpbiBh
cyBhbiBSUkVRLUFjayByZXF1ZXN0PyBXaHkgbm90IGEgZmxhZywgYmVjYXVzZSB0aGUgYWRkcmVz
cyB3aWxsIGJlIGluY2x1ZGVkIGFzIHRoZSBJUCBzZW5kaW5nIGFkZHJlc3MgLSBhbmQgd2Uga25v
dyA1NDQ0IGlzIHJlcXVpcmVkIHRvIHBhc3MgdGhhdCBvbi4gKEl04oCZcyB1c2VkIGJ5IE5IRFAg
YXMgd2VsbC4pIFRoZW4gd2UgZG9u4oCZdCBuZWVkIHRvIGNoYW5nZSB0aGUgUlJFUCwNCiBpdCB3
aWxsIGhhdmUgYSBmbGFnIHNldCBvciBub3QsIGFuZCB3b27igJl0IGNoYW5nZSAoaW4gdGhpcyBy
ZWdhcmQpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vdyBsZXTigJlzIGNvbnNpZGVyIGRvIHdlIGtub3cgd2hl
dGhlciB3ZSBjYW4gc2V0IGEgZml4ZWQgZmxhZy4gRmlyc3QgSeKAmWQgc2F5IHRoZXJlIGFyZSB0
d28gY2FzZXMNCiAtIHlvdeKAmXZlIGdvdCBhIGZpcm0gY29udHJvbCBvbiB3aGF04oCZcyBnb2lu
ZyBvbiBpbiB5b3VyIG5ldHdvcmssIG9yIGl04oCZcyBvbmUgb2YgdW5rbm93biBwYXJ0aWVzIGFu
ZCBiZWhhdmlvdXIgKGNvbnNpc3RlbnQgd2l0aCBzcGVjaWZpY2F0aW9uKS4gSW4gdGhlIGZvcm1l
ciBjYXNlIHlvdSBvbmx5IHdhbnQgb25lIHNldHRpbmcsIGZvciBleGFtcGxlIG5vLUFjayBpZiBy
dW5uaW5nIE5IRFAgb3IgeW91ciBNQUMgbGF5ZXIgdGVsbHMgeW91IGFib3V0DQogYmlkaXJlY3Rp
b25hbGl0eSwgQWNrIG90aGVyd2lzZS4gSW4gdGhlIGxhdHRlciBjYXNlLCBJIHRoaW5rIHlvdSBq
dXN0IGFsd2F5cyB3YW50IGFuIEFjay4gU28gYm90aCBjYXNlcyBnZXQgeW91IHRvIHRoZSBzYW1l
IHBsYWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNob3VsZCB0aGF0IG5vdCBiZSBhbiBhY2NlcHRhYmxlIGFy
Z3VtZW50ICh0aG91Z2ggSSB0aGluayBpdOKAmXMgZ29vZCBmb3Igd2hlcmUgd2UgYXJlIC0gaW4g
ZmFjdCBhbHdheXMNCiBBY2sgaXMgY2xvc2UpIHRoZW4gYXQgZmxhZyBpcyBhIHN0ZXAgYmV0dGVy
LCBpdOKAmXMgYSBmaXhlZCBsb2NhdGlvbiB0byBjaGFuZ2UuIEhvd2V2ZXIgaXQgd291bGQgYmUg
YmV0dGVyIGluIHRoYXQgY2FzZSBpZiB0aGUgdHdvIHRoaW5ncyB0byBjaGFuZ2UgKG1ldHJpYyBh
bmQgYWNrIGZsYWcpIHdlcmUgdG9nZXRoZXIuIEJ1dCB0aGF0IGhhcyBpdHMgb3duIGlzc3Vlcywg
c28gSSB3b27igJl0IGdvIHRoZXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPC9zcGFuPjwvYj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5n
aW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8
YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVC
RSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojN0Q3RDdEIj46ICZuYnNwOzxhIGhyZWY9InRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIw
MjQyMTk0IiB0YXJnZXQ9Il9ibGFuayI+JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NDwvYT4NCiAmbmJz
cDt8ICZuYnNwOzxiPkU6IDwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lz
dGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwv
YT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxi
cj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5
c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBH
cmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0
cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj
b2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0
ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQ
YXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh
bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVmljdG9yaWEN
CiBNZXJjaWVjYSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2bWVyY2llY2EwQGdtYWlsLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPnZtZXJjaWVjYTBAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6
PC9iPiAyNSBBcHJpbCAyMDE2IDE0OjE1PGJyPg0KPGI+VG86PC9iPiBKaWF6aSBZSTxicj4NCjxi
PkNjOjwvYj4gRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk7IENocmlzdG9waGVyIERlYXJsb3Zl
OyBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9i
PiBSZTogW21hbmV0XSBNZXNzYWdlIGludGVncml0eSBhbmQgbWVzc2FnZSBtdXRhYmlsaXR5ICh3
YXMgUkU6IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEgY291cGxlIG9mIGJp
ZyB0aWNrZXQgSXRlbXMpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFj
ayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl
Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91
bmQ6d2hpdGUiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4q
KiogV0FSTklORyAqKio8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91
bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+
VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVp
dGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2Vt
PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFu
eSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0K
PGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9z
cGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5S
ZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3Ug
cmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMu
Y29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5w
ZGYiIHRhcmdldD0iX2JsYW5rIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3Ug
ZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0
cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxp
Z2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiIg
dGFyZ2V0PSJfYmxhbmsiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3NwYW4+PC9lbT48L3NwYW4+PC9p
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi
PkhpIEppYXppLDxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5PbiBNb24sIEFwciAyNSwgMjAxNiBhdCAxOjA0IFBNLCBKaWF6aSBZSSAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmlldGZAamlheml5aS5jb20iIHRhcmdldD0iX2JsYW5rIj5pZXRmQGppYXpp
eWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj5IaSwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+T24gTW9uLCBBcHIgMjUsIDIwMTYgYXQgMTE6MjAgQU0sIERlYXJsb3ZlLCBDaHJpc3Rv
cGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j
b20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaXRoIHJlZ2Fy
ZCB0byB5b3VyIHZhbGlkaXR5IHRpbWUgcG9pbnQsIHdlIGhlcmUgaGF2ZSBhIHRyYWRlb2ZmLiBJ
ZiB5b3UgYWxsb3cgdGhhdCBmZWF0dXJlLCBpdCBzaWduaWZpY2FudGx5DQogaW1wYWN0cyBvbiB0
aGUgYXBwcm9hY2ggdGhhdCB3YXMgY29taW5nIHRvZ2V0aGVyIG9uIGFzIGJlc3QgeW91IGNhbiBl
bmQgdG8gZW5kIGVuY3J5cHRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28gdGhlIHF1ZXN0aW9uIGlzLCBp
cyB0aGlzIGEgZmVhdHVyZSB0aGF04oCZcyByZWFsbHkgd2FudGVkPyBVbmZvcnR1bmF0ZWx5IEkg
dGhpbmsgd2Uga25vdyB0aGF0IHRoZQ0KIGFuc3dlciB0byB0aGF0IGlzLCB3ZSBkb27igJl0IGtu
b3cgYmVjYXVzZSB3ZSBkb27igJl0IGhhdmUgYW55IGV4cGVyaWVuY2UuIE15IHZpZXcgd291bGQg
YmUgdGhhdCBpbiB0aGUgdHJhZGVvZmYgb2YgYW4gdW50ZXN0ZWQgZmVhdHVyZSAodW5sZXNzIEni
gJltIHdyb25nIGFib3V0IHRoYXQpIGFuZCB0aGUgc2VjdXJpdHkgY29tcGxpY2F0aW9uLCBzZWN1
cml0eSB3aW5zIGFuZCBkcm9wIHRoZSBmZWF0dXJlLiBJZiB0aGVyZSBpcyBzb21lIHJlYWwgcmVx
dWlyZW1lbnQsDQogdGhlbiB0aGVyZeKAmXMgYSBkaXNjdXNzaW9uLiAoUXVlc3Rpb25zIGxpa2Ug
aG93IG9mdGVuIHRoZSBpbnRlcm1lZGlhdGUgcm91dGVycyBhY3R1YWxseSBoYXZlIGFueSBrbm93
bGVkZ2UgLSB0eXBpY2FsbHkgbGlua3MgYnJlYWsgZm9yIHVuZXhwZWN0ZWQgcmF0aGVyIHRoYW4g
ZXhwZWN0ZWQgcmVhc29ucy4gQW5kYW4gaW50ZXJtZWRpYXRlIHJvdXRlciBjb3VsZCBwb3NzaWJs
eSB1c2UgYSB2YWxpZGl0eSB0aW1lIHRvIGluZmx1ZW5jZSBpdHMgYmVoYXZpb3VyLikNCiBOb3Rl
IHRoYXQgZHJvcHBpbmcgdGhlIGFiaWxpdHkgb2YgaW50ZXJtZWRpYXRlIHJvdXRlcnMgdG8gbW9k
aWZ5L3NldCBzdGlsbCBhbGxvd3MgdmFsaWRpdHkgdGltZXMgcGVyIHJvdXRlIHRvIGJlIHNldCBh
dCBlbmRwb2ludHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGFncmVlIHdpdGggQ2hyaXMnIGNvbmNlcm4u
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRo
ZSBWYWxpZGl0eVRpbWUgaXMgb3B0aW9uYWwsIHdoaWNoIG1ha2VzIHRoZSBpbnRlZ3JpdHkgcHJv
dGVjdGlvbiBoYXJkLiBGdXJ0aGVybW9yZSwgaXQgZ2l2ZXMgYSBwb3RlbnRpYWwgYXR0YWNrIHZl
Y3RvcjogYXMgYWxsIHRoZSByb3V0ZXJzIGluIGEgcGF0aCB3aWxsIHRha2UgdGhlIHNob3J0ZXN0
IHZhbGlkaXR5VGltZSwNCiBhIGNvbXByb21pc2VkIHJvdXRlciBjYW4gc2V0IHRoZSB0aGUgdmFs
aWRpdHlUaW1lIHRvIGEgdmVyeSBzaG9ydCB2YWx1ZSwgd2hpY2ggd2lsbCBtYWtlIHRoZSByb3V0
ZSBpbnN0YWxsZWQgYWxvbmcgdGhlIHBhdGggYmVjYW1lIGludmFsaWQgKHZlcnkgc29vbikuJm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5PbiB0aGUgb3RoZXIgaGFuZCwgSSdtIG5vdCBzdXJlIHRoaXMgb3B0aW9uIHdpbGwgZ2l2
ZSB1cyBtdWNoIGhlbHAuIENocmlzIG1lbnRpb25lZCBtdWNoIGtub3dsZWRnZSBpbnRlcm1lZGlh
dGUgcm91dGVyIHdvdWxkIGhhdmUgdG8gZGVjaWRlIHRoaXMgdmFsdWUgKGFuZCBob3cgbXVjaCBz
ZW5zZSB0aGUgdmFsdWUNCiB3b3VsZCBtYWtlKS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5vdGhlciBpc3N1ZSBpcywgYSByb3V0
ZSB0byBhIGRlc3RpbmF0aW9uIG1pZ2h0IGJlIHVwZGF0ZWQgYnkgZGlmZmVyZW50IHNvdXJjZXMu
IEZvciBleGFtcGxlLCBpbiB0aGUgbmV0d29yayBiZWxvdzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QS0tLS1CLS0tLS1DPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QSBmaXJz
dCBlc3RhYmxpc2ggYSByb3V0ZSB0byBCIHdpdGggbG9uZyB2YWxpZGl0eSB0aW1lLiBUaGVuIEEg
aW5pdGlhdGVzIGEgcm91dGUgZGlzY292ZXJ5IHRvIEMuIEMgdGVuZHMgdG8gc2V0IGEgc2hvcnQg
dmFsaWRpdHkgdGltZSwgd2hpY2ggd2lsbCBtYWtlIHRoZSByb3V0ZSBiZXR3ZWVuIEIgYW5kIEEN
CiBleHBpcmUgZWFybGllciB0aGFuIGV4cGVjdGVkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JcyB0aGlzIGEgcHJvYmxlbT8gTWF5
YmUgeWVzLCBtYXliZSBubyAtLSBJJ20gbm90IHN1cmUgaXQncyBjb25zaWRlcmVkIG9yIG5vdC4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5Ob3Qgc3VyZSBJIGZvbGxvdyBoZXJlLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5DdXJyZW50bHksIHRo
ZSB2YWxpZGl0eSB0aW1lIG9mIHRoZSByb3V0ZSBiZXR3ZWVuIEEgYW5kIEIgd291bGQgbm90IGFm
ZmVjdGVkIGJ5IGEgc2hvcnQgdmFsaWRpdHkgdGltZSBvZiBhIHJvdXRlIGJldHdlZW4gQSBhbmQg
Qy4gVmFsaWRpdHkgdGltZXMgYXJlIHBlci1yb3V0ZSwgYW5kIHRoZSByb3V0ZSBBLUIgYW5kIHRo
ZQ0KIHJvdXRlIEEtQyBhcmUgc2VwYXJhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHdlIHN3aXRjaGVkIHRvIGEgdmFsaWRpdHkgdGlt
ZSBwZXIgbmVpZ2hib3IgKHNvIHRoYXQgd2UgY2FuIGtlZXAgdmFsaWRpdHkgdGltZSBzZXBhcmF0
ZSBmcm9tIHJvdXRlIGFkdmVydGlzZW1lbnRzKSBhcyBJIG1lbnRpb25lZCBpbiB0aGUgZW1haWwg
YmVsb3csIHRoZW4gdGhlIHZhbGlkaXR5IG9mIGEgcm91dGUNCiBiZXR3ZWVuIEEgYW5kIEMgd291
bGQgYmUgYWZmZWN0ZWQgaWYgdGhlcmUgd2FzIGEgc2hvcnQgdmFsaWRpdHkgdGltZSBiZXR3ZWVu
IEEgYW5kIEIuIEJ1dCwgaWYgQiB3aWxsIG9ubHkgcm91dGUgZm9yIGEgY2VydGFpbiBhbW91bnQg
b2YgdGltZSwgdGhlbiB0aGUgcm91dGUgYmV0d2VlbiBBIGFuZCBDIHdpbGwgb2YgY291cnNlIGJl
IGFmZmVjdGVkLiBJcyBpdCBiZXN0IHRvIGtub3cgaW4gYWR2YW5jZSB0aGF0IHRoZXJlJ3MgYSB0
aW1lIGxpbWl0LA0KIG9yIGp1c3QgZGVhbCB3aXRoIFJFUlJzIHdoZW4gdGhleSBoYXBwZW4/PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt
YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw
Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp
Z2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2l0aCByZWdhcmQgdG8gdGhlIGFj
a25vd2xlZGdlbWVudHMsIHRoZSBwcm9ibGVtICh3aXRoIHJlZ2FyZCB0byBzZWN1cml0eSkgY29t
ZXMgZnJvbSB0cnlpbmcgdG8gZG8NCiB0d28gam9icyB3aXRoIHRoZSBzYW1lIG1lc3NhZ2UgLSBl
bmQgdG8gZW5kIHJvdXRlIGFkdmVydGlzZW1lbnQgYW5kIGhvcCBieSBob3AgYWNrbm93bGVkZ2Vt
ZW50LiBJIHVuZGVyc3RhbmQgdGhlIHJlYXNvbnMgLSBzYXZpbmcgYnl0ZXMgYW5kIG1lc3NhZ2Ug
dHlwZXMuIChJIHdvdWxkIGhhdmUgdG8gc3R1ZHkgdGhlIHByb3RvY29sIHJlYWxseSBoYXJkIHRv
IGlkZW50aWZ5IGlmIGFueSBtZXNzYWdlIHR5cGVzIGNhbiBiZSBmb2xkZWQgdG9nZXRoZXINCiBh
bmQgcmVjb2duaXNlZCBieSBjb250ZW50IHJhdGhlciB0aGFuIHR5cGUgZWZmaWNpZW50bHkuIFRo
aXMgSSBkbyBub3QgZXhwZWN0IHRvIGRvLikgQWdhaW4gYSB0cmFkZW9mZi4gVGhpcyBvbmUgaXMg
aW4gZGlzY3Vzc2lvbiBzcGFjZSwgdGhvdWdoIHRoYXQgbmVlZHMgcGVvcGxlIHdobyB1bmRlcnN0
YW5kIGJvdGggc2lkZXMgb2YgdGhlIGlzc3VlLCBpbmNsdWRpbmcgdGhlIGRldGFpbHMgb2YgdGhl
IGJpZGlyZWN0aW9uYWxpdHkgbWVjaGFuaXNtLg0KIE9mIGNvdXJzZSwgYXMgaGFzIGJlZW4gc2Fp
ZCwgd2UgbmVlZCBvbmUgb2YgdGhvc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J
IGhhdmVuJ3QgZmluaXNoZWQgbXkgcmV2aWV3IG9mIHRoZSBsYXRlc3QgZHJhZnQsIGFuZCBJIGRv
bid0IGdldCB0aGUgbmVjZXNzaXR5IG9mIEFja1JlcSBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgbXVs
dGljYXN0IFJSRVAgeWV0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5JZiBwb3NzaWJsZSwgdGhpcyAmcXVvdDtvcHRpb25hbCZxdW90
OyBmaWVsZCBzaG91bGQgYmUgYXZvaWRlZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv
bToxMi4wcHQiPjxicj4NClRvIGdpdmUgYW4gb3ZlcnZpZXcgb2YgQWNrUmVxIGFuZCBSUkVQOjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5TaW5jZSBBT0RW
djIgcmVxdWlyZXMgYmlkaXJlY3Rpb25hbCBsaW5rcywgdGhpcyBpcyB0aGUgd2F5IHRvIGRldGVy
bWluZSBpZiBhIGxpbmsgaXMgYmlkaXJlY3Rpb25hbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QS0tLS1CLS0tLUM8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KMSkgQSBzZW5kcyBS
UkVRLCBCIGZvcndhcmRzIGl0LCBDIHJlY2VpdmVzIHRoZSBSUkVRLiBCIGFuZCBDIGJvdGggaW5z
dGFsbCBhIHJvdXRlIHRvIE9yaWdBZGRyIGJ1dCB0aGV5IGRvbnQgeWV0IGtub3cgaWYgaXQncyB2
YWxpZCBiZWNhdXNlIHRoZXkgZG9udCBrbm93IGlmIHRoZSBsaW5rIHRvIHRoZWlyIG5leHQgaG9w
IGlzIGF2YWlsYWJsZSBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24uPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIpIEMgY3JlYXRlcyB0aGUgUlJF
UC4gU2luY2UgaXQgZG9lc250IGtub3cgaWYgdGhlIGxpbmsgdG8gQiBpcyBiaWRpcmVjdGlvbmFs
LCBpdCBpbmNsdWRlcyB0aGUgQWNrUmVxIChhbiBhZGRyZXNzIHRvIGluZGljYXRlIHRoYXQgaXQg
ZXhwZWN0cyB0byByZWNlaXZlIGEgUlJFUF9BY2sgZnJvbSBCKS48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MykgQiByZWNlaXZlcyB0aGUgUlJF
UCwgaW5zdGFsbHMgYSByb3V0ZSB0byBUYXJnQWRkciBhbmQgbWFya3MgaXQgYXMgdmFsaWQsIHNp
bmNlIGl0IGtub3dzIHRoZSBsaW5rIHRvIEMgaXMgYmlkaXJlY3Rpb25hbCwgYmVjYXVzZSB0aGUg
UlJFUSB3ZW50IGluIG9uZSBkaXJlY3Rpb24gYW5kIHRoZSBSUkVQIGNhbWUNCiBpbiB0aGUgb3Ro
ZXIuIEIgYWxzbyBzZW5kcyB0aGUgUlJFUF9BY2sgdG8gQyBhbmQgZm9yd2FyZHMgdGhlIFJSRVAg
dG8gQSAoYW5kIG1pZ2h0IGNoYW5nZSB0aGUgbWVzc2FnZSB0byBpbmRpY2F0ZSBpdHMgb3duIEFj
a1JlcSAtIGllIHRoYXQgaXQgcmVxdWlyZXMgYW4gYWNrIGZyb20gQSkuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjQpIEMgcmVjZWl2ZXMgdGhl
IFJSRVBfQWNrIGZyb20gQiwgYW5kIHRoZXJlZm9yZSBrbm93cyB0aGF0IEIgcmVjZWl2ZWQgdGhl
IFJSRVAsIHRoZXJlZm9yZSB0aGUgbGluayBpcyBiaWRpcmVjdGlvbmFsLiBDIGNhbiB0aGVuIG1h
cmsgaXRzIHJvdXRlIHRvIE9yaWdBZGRyIGFzIHZhbGlkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj41KSBTaW1pbGFybHksIEEgcmVjZWl2ZXMg
dGhlIFJSRVAsIGluc3RhbGxzIHRoZSByb3V0ZSB0byBUYXJnQWRkciBhbmQgc2VuZHMgYW4gUlJF
UF9BY2sgdG8gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+NikgQiByZWNlaXZlcyB0aGUgUlJFUF9BY2sgYW5kIG1hcmtzIGl0cyByb3V0ZSB0
byBPcmlnQWRkciBhcyB2YWxpZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu
LWJvdHRvbToxMi4wcHQiPkFsdGVybmF0aXZlbHksIGluIHN0ZXAgMiwgaWYgQyBrbm93cyB0aGUg
bGluayB0byBCIGlzIGJpZGlyZWN0aW9uYWwgKHBlcmhhcHMgZnJvbSBzb21lIGVhcmxpZXIgcm91
dGUgZGlzY292ZXJ5KSwgaXQgZG9lc250IG5lZWQgdG8gcHV0IHRoZSBBY2tSZXEgaW4gdGhlIFJS
RVAuIFRoZW4gaW4gc3RlcCAzLCBzaW5jZSBCDQogZG9lc250IGtub3cgaWYgdGhlIGxpbmsgdG8g
QSBpcyBiaWRpcmVjdGlvbmFsLCBpdCBjaGFuZ2VzIHRoZSBtZXNzYWdlIHRvIGFkZCB0aGUgQWNr
UmVxIGFkZHJlc3MsIGluIG9yZGVyIHRvIGdldCBhbiBSUkVQX0FjayBmcm9tIEEuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPklmIHdlIHdhbnQgdG8gYXZv
aWQgY2hhbmdpbmcgdGhlIG1lc3NhZ2UsIHdlJ2xsIG5lZWQgdG8gbG9vayBhdCBmb3J3YXJkaW5n
IHRoZSBSUkVQIGFzLWlzLCBhbmQgY3JlYXRpbmcgYSBzZWNvbmQgbWVzc2FnZSB0byBzb2xpY2l0
IGFuIFJSRVBfQWNrLCBpbiBvcmRlciB0byB2ZXJpZnkgdGhhdCB0aGUgbGluayBpcyBiaWRpcmVj
dGlvbmFsDQogYmVmb3JlIG1hcmtpbmcgdGhlIHJvdXRlIHRvIE9yaWdBZGRyIGFzIHZhbGlkLiA8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+S2lu
ZCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5WaWN0b3JpYS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t
OjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n
OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkppYXppPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s
ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMwMDdFN0UiPi0tDQo8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVy
IERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1z
IEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi
cj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxi
cj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7
PGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQiIHRhcmdldD0iX2JsYW5r
Ij4mIzQzOzQ0ICgwKTEyNDUgMjQyMTk0PC9hPg0KICZuYnNwO3wgJm5ic3A7PGI+RTogPC9iPjxh
IGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxh
bmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln
ZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9y
ZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29t
L2FpIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVz
eXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFF
IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4g
RW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu
LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5S
ZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5
LCBHVTIgN1lQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBWaWN0b3JpYQ0KIE1lcmNpZWNhIFttYWlsdG86PGEg
aHJlZj0ibWFpbHRvOnZtZXJjaWVjYTBAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dm1lcmNp
ZWNhMEBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDIzIEFwcmlsIDIwMTYgMTA6
NTU8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KPGI+Q2M6PC9iPiA8
YSBocmVmPSJtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmll
dGZAdGhvbWFzY2xhdXNlbi5vcmc8L2E+OyBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgTW9i
aWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+U3ViamVjdDo8L2I+
IFJlOiBbbWFuZXRdIE1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBtZXNzYWdlIG11dGFiaWxpdHkgKHdh
cyBSRTogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmln
IHRpY2tldCBJdGVtcyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAy
LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpj
ZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0
LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPC9zcGFuPjwvYj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0
LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxpPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRl
IG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhl
IGludGVybmV0Ljxicj4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xp
Y2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48YnI+DQpGb3Ig
aW5mb3JtYXRpb24gcmVnYXJkaW5nIDwvc3Bhbj48L2k+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9iPjxpPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3Ig
aW4gZW1haWxzDQogeW91IHJlY2VpdmUsIGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5l
bnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRz
L1JlZCUyMEZsYWdzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0KaGVyZTwvYT4uPGJyPg0KSWYgeW91
IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgPGEgaHJlZj0iaHR0
cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxp
Z2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiIg
dGFyZ2V0PSJfYmxhbmsiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3NwYW4+PC9pPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIENo
cmlzLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRo
ZXNlIGhhdmUgYm90aCBiZWVuIGluIHRoZSBkcmFmdCBpbiBzb21lIGZvcm0gc2luY2UgYmVmb3Jl
IEkgZ290IGludm9sdmVkLi4uIGJ1dCBJJ2xsIGRvIG15IGJlc3QgdG8gZXhwbGFpbi48bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIEZvciBWYWxpZGl0
eSBUaW1lLCBpdHMgYSB3YXkgdG8gYWR2ZXJ0aXNlIHRoYXQgeW91IHdvdWxkIG9ubHkgc3VwcG9y
dCB0aGUgcm91dGUgY29udGFpbmVkIGluIHRoZSBtZXNzYWdlIGZvciBhIGNlcnRhaW4gcGVyaW9k
IG9mIHRpbWUuIFRoZSBvcmlnaW5hdG9yIG1pZ2h0IHVzZSB0aGlzLCBidXQgdGhlIGRyYWZ0DQog
d2FzIHdyaXR0ZW4gdG8gYWxsb3cgYW55IGludGVybWVkaWF0ZSBub2RlIHRvIGJlIGFibGUgdG8g
YWRkIGl0IG9yIHVwZGF0ZSBpdCB0b28uIFRoZSByb3V0ZSBjcmVhdGVkIGluIHRoZSBMb2NhbCBS
b3V0ZSBTZXQgaGFzIGFuIGV4cGlyYXRpb24gdGltZSBhc3NvY2lhdGVkIHdpdGggaXQsIGJhc2Vk
IG9uIHRoZSByZWNlaXZlZCB2YWxpZGl0eSB0aW1lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIEZvciB0aGUgQWNrUmVxIGFkZHJlc3MsIGl0
cyBzbyB0aGF0IHlvdSBjYW4gYWRkIGludG8gYSBSUkVQIGEgcmVxdWVzdCBmb3IgYW4gYWNrbm93
bGVkZ2VtZW50LCBzbyB0aGF0IHlvdSBkb24ndCBoYXZlIHRvIGhhdmUgYSBkaWZmZXJlbnQgbWVz
c2FnZSB0eXBlIGFsdG9nZXRoZXIgZm9yIHdvcmtpbmcgb3V0DQogd2hldGhlciBsaW5rcyB0byBu
ZWlnaGJvcnMgYXJlIGJpZGlyZWN0aW9uYWwsIGFuZCBhbHNvLCBzaW5jZSB5b3Ugb25seSBjYXJl
IGFib3V0IGJpZGlyZWN0aW9uYWxpdHkgb24gcm91dGVzIHRoYXQgYXJlIGJlaW5nIHNldCB1cCwg
eW91IGRvbnQgbmVlZCB0byBjb25zdGFudGx5IG1vbml0b3IgYWxsIG5laWdoYm9ycy48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J
biBvcmRlciB0byBhdm9pZCB0aGUgcG90ZW50aWFsIEFja1JlcS1yZWxhdGVkIGNoYW5nZXMgdG8g
ZWFjaCBtZXNzYWdlLCBtYXliZSB3ZSBkbyBuZWVkIHRvIGludHJvZHVjZSBhIGRpZmZlcmVudCBt
ZXNzYWdlIHNwZWNpZmljYWxseSBmb3IgdGhpcy4gV2UgY291bGQgbWF5YmUgdXNlIFJSRVBfQWNr
IHRvIGJvdGgNCiByZXF1ZXN0IGFuZCBhY2tub3dsZWRnZT8gSXQgbWVhbnMgYW4gZXh0cmEgbWVz
c2FnZSBvZiBjb250cm9sIHRyYWZmaWMgdGhhdCBuZWVkcyB0byBiZSBzZW50LCBtYXliZSBvbmUg
ZXh0cmEgbWVzc2FnZSBwZXIgaG9wIG9uIHRoZSBwYXRoIG9mIGEgUlJFUCwgYnV0IGl0IGNvdWxk
IHN0aWxsIGJlIGxpbWl0ZWQgdG8gbmVpZ2hib3JzIHdoaWNoIGhhdmUgcGFydGljaXBhdGVkIGlu
IHRoZSByb3V0ZSBkaXNjb3ZlcnkgcmF0aGVyIHRoYW4gbW9uaXRvcmluZw0KIGFsbCBuZWlnaGJv
cnMgYXQgYWxsIHRpbWVzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBtZXNzYWdlIGNvdWxkIG1heWJlIGFsc28gaW5j
bHVkZSAmcXVvdDtJJ20gaGFwcHkgdG8gcm91dGUgYW55d2hlcmUgZm9yIGEgY2VydGFpbiBhbW91
bnQgb2YgdGltZSZxdW90Oywgc29ydCBvZiBsaWtlIHdpbGxpbmduZXNzIGluIE9MU1IvT0xTUnYy
LiBTbyBpbnN0ZWFkIG9mIGhhdmluZyBhIHZhbGlkaXR5IHRpbWUgcGVyDQogcm91dGUsIGl0cyBh
IHZhbGlkaXR5IHRpbWUgcGVyIG5laWdoYm9yLiBUaGVuLCBmb3IgUlJFUSBhbmQgUlJFUCwgb25s
eSB0aGUgbWV0cmljIHZhbHVlIHdvdWxkIGNoYW5nZSBpbiB0cmFuc2l0LCBhcyBkaXNjdXNzZWQu
IEhvd2V2ZXIsIHRoYXQgbGVhZHMgdG8gc29tZSBpc3N1ZXMgd2l0aCBkZWNpZGluZyB3aGF0IGEg
cm91dGUncyBleHBpcmF0aW9uIHRpbWUgaXMuIFlvdSBtaWdodCBrbm93IGhvdyBsb25nIHRoZSBu
ZXh0IGhvcCByb3V0ZXIgaXMNCiB2YWxpZCBmb3IsIGJ1dCB3aGF0IGlmIGEgcm91dGVyIGJleW9u
ZCB0aGF0LCB3aGljaCB3YXMgYWxzbyBwYXJ0IG9mIHRoZSByb3V0ZSwgaGFkIGEgbG93ZXIgdmFs
aWRpdHkgdGltZT8gWW91IGNvdWxkbid0IGRldGVybWluZSB0aGUgcmVhbCB2YWxpZGl0eSB0aW1l
LiBEbyB3ZSByZW1vdmUgdGhlIHJvdXRlIGV4cGlyYXRpb24gdGltZSBhbHRvZ2V0aGVyIHRvIGF2
b2lkIHRoaXMgaXNzdWU/IEluIHdoaWNoIGNhc2UsIHdlIHdvdWxkIGhhdmUgdG8NCiByZWx5IG9u
IFJFUlIgbWVzc2FnZXMgYmVpbmcgc2VudCBmb3Igcm91dGVzIHdoaWNoIGJlY29tZSBpbnZhbGlk
IHdoZW4gdGhlIG5laWdoYm9yJ3MgdmFsaWRpdHkgdGltZSBoYXMgZXhwaXJlZD8gU28gbmVpZ2hi
b3IgdmFsaWRpdHkgdGltZSBleHBpcmF0aW9uIGlzIHRyZWF0ZWQgdGhlIHNhbWUgYXMgYSBsaW5r
IGJyZWFrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+V2hhdCBkbyB5b3UgdGhpbms/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5LaW5kIHJlZ2FyZHMsPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlZpY3RvcmlhLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPk9uIFNhdCwgQXByIDIzLCAyMDE2IGF0IDE6MDkgQU0sIENocmlzdG9waGVy
IERlYXJsb3ZlICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVr
IiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrPC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
UHJldHR5IG11Y2ggYWxsIG9mIHRoZSBkaXNjdXNzaW9uIGhhcyBiZWVuIGFzc3VtaW5nIG9ubHkg
YSBtZXRyaWMgdmFsdWUgY2hhbmdlLiBXaXRoIG11bHRpcGxlIHRoaW5ncyBjaGFuZ2luZyBtYW55
IG9mIHRoZSBpZGVhcyBnbyBvdXQgb2YgdGhlIHdpbmRvdy4gVGhhdCByZWluZm9yY2VzIHRoZSBw
b2ludCBhYm91dA0KIG5vdCBtYWtpbmcgc3BlY2lmaWNhdGlvbnMgbm93IHRoYXQgbWlnaHQgdHVy
biBvdXQgdG8gYmUgd3JvbmcgZm9yIElDVnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZ25vcmluZyBob3cgdGhpcyBtaXN1bmRlcnN0
YW5kaW5nIGhhcHBlbmVkLCBJJ2xsIHN0YXJ0IGJ5IGFza2luZyB3aHkuIE1ldHJpYyBjaGFuZ2lu
ZyBJIHVuZGVyc3RhbmQuIFdoeSB0aGUgb3RoZXIgdHdvPyAodGhlcmUncyBhIHBhcnRpYWwgZXhw
bGFuYXRpb24gb2Ygb25lKS4gV2hhdCBhbHRlcm5hdGl2ZXMNCiBoYXZlIHBlb3BsZSBpbXBsZW1l
bnRlZCBpbiBjb21wYXJhYmxlIHByb3RvY29scz88YnI+DQo8YnI+DQotLSAmbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNocmlzdG9waGVyIERlYXJs
b3ZlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxhIGhyZWY9Im1haWx0bzpjaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb20iIHRhcmdldD0i
X2JsYW5rIj5jaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb208L2E+IChpUGhvbmUpPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9
Im1haWx0bzpjaHJpc0BtbmVtb3N5bmUuZGVtb24uY28udWsiIHRhcmdldD0iX2JsYW5rIj5jaHJp
c0BtbmVtb3N5bmUuZGVtb24uY28udWs8L2E+IChob21lKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDIzIEFwciAyMDE2LCBh
dCAwMDoyNiwgVmljdG9yaWEgTWVyY2llY2EgJmx0OzxhIGhyZWY9Im1haWx0bzp2bWVyY2llY2Ew
QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZtZXJjaWVjYTBAZ21haWwuY29tPC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbnRpbnVlZCBpbiB0
aGlzIHRocmVhZCBiZWNhdXNlIHRoZSBvdGhlciBvbmUgc2VlbXMgdG8gYmUgbW9yZSBhYm91dCBU
TFYgdHlwZXMgYW5kIG1ldHJpYyB0eXBlIG51bWJlcnMsIHdoZXJlYXMgdGhpcyBpcyBhYm91dCBy
ZWdlbmVyYXRpb24vZm9yd2FyZGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvIHJlY2FwLCBpbiB0aGUgY3VycmVudCBkcmFmdCwg
dGhlcmUgYXJlIDMgdGhpbmdzIHRoYXQgbWlnaHQgY2hhbmdlIGF0IGVhY2ggaG9wOg0KPGJyPg0K
LSB0aGUgbWV0cmljIHZhbHVlIChoYXBwZW5zIGluIFJSRVEgYW5kIFJSRVApLCA8YnI+DQotIGFk
ZGluZy9jaGFuZ2luZyBWYWxpZGl0eSBUaW1lIHVzaW5nIHRoZSBWYWxpZGl0eSBUaW1lIFRMViAo
Y2FuIGhhcHBlbiBpbiBSUkVRIGFuZCBSUkVQKSwNCjxicj4NCi0gYWRkaW5nIGFuIGFkZHJlc3Mg
KGFuZCBjb3JyZXNwb25kaW5nIHZhbHVlIGluIHRoZSBBZGRyZXNzVHlwZSBUTFYgdG8gaW5kaWNh
dGUgaG93IHRvIGludGVycHJldCB0aGUgYWRkcmVzcykgdG8gaW5kaWNhdGUgdGhlIGFkZHJlc3Mg
ZnJvbSB3aGljaCBhbiBSUkVQX0FjayBpcyBleHBlY3RlZCwgdG8gYWNjb21wbGlzaCB0aGUgYmlk
aXJlY3Rpb25hbGl0eSBjaGVjayAoY2FuIGhhcHBlbiBpbiBSUkVQKS48YnI+DQo8YnI+DQpJZiB3
ZSBkZWZpbmUmbmJzcDthIGNlcnRhaW4gcG9ydGlvbiBvZiB0aGUgbWVzc2FnZSBhcyBpbW11dGFi
bGUgYW5kIGluY2x1ZGUgdGhlIElDViB0byB2ZXJpZnkgdGhhdCBwYXJ0LCBlbmQgdG8gZW5kOg0K
PGJyPg0KLSBUaGUgbWV0cmljIHZhbHVlIHdvdWxkIGJlIGV4Y2x1ZGVkIGZyb20gdGhlIElDViBz
aW5jZSBpdCBuZWVkcyBjaGFuZ2luZyBhdCBlYWNoIGhvcC4mbmJzcDs8YnI+DQotIFdvdWxkIGFk
ZGluZyBhIFZhbGlkaXR5IFRpbWUgVExWIGF0IGFuIGludGVybWVkaWF0ZSBob3AgYmUgYWNjZXB0
YWJsZT8gVGhlIHdob2xlIFRMViBjb3VsZCBiZSByZW1vdmVkIGluIG9yZGVyIHRvIGNhbGN1bGF0
ZSB0aGUgSUNWPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
Pi0gV291bGQgYWRkaW5nIGFuIGFkZHJlc3MgY2F1c2UgaXNzdWVzIGZvciB0aGUgSUNWLCBiZWNh
dXNlIGl0J3MgaW4gdGhlIGFkZHJlc3MgYmxvY2s/IENvdWxkIHRoZSBydWxlIGJlICZxdW90O2lm
IGl0IGNvbnRhaW5zIGFuIEFja1JlcSBhZGRyZXNzLCByZW1vdmUgaXQgKGFuZCB0aGUgY29ycmVz
cG9uZGluZyB2YWx1ZQ0KIGluIHRoZSBBZGRyZXNzVHlwZSBUTFYpLCBiZWZvcmUgY2hlY2tpbmcg
dGhlIElDViZxdW90OywgaXMgdGhhdCBPSz8gT3Igd291bGQgd2UgbmVlZCB0byBhdm9pZCB0b3Vj
aGluZyB0aGUgSUNWJ2VkIHBhcnQgb2YgdGhlIG1lc3NhZ2UgYWx0b2dldGhlciwgbWF5YmUgcHV0
IHRoZSBBY2tSZXEgYWRkcmVzcyBpbiBhIHNlcGFyYXRlIEFkZHJlc3MgQmxvY2ssIHdpdGggYW4g
ZXh0cmEgQWRkcmVzc1R5cGUgVExWIGZvbGxvd2luZyB0aGF0IGFkZHJlc3MgYmxvY2s/DQogSXMg
dGhlcmUgYSB3YXkgdG8gYWNjb21wbGlzaCB0aGlzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWxzbywgdG8gYmUgdGhvcm91Z2gsIGRv
IHdlIG5lZWQgdG8gY29uc2lkZXIgUkVSUiBtZXNzYWdlcyB3aGlsZSB3ZSBkaXNjdXNzIHJlZ2Vu
ZXJhdGlvbiB2cyBmb3J3YXJkaW5nPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIFJFUlIgKHNlbnQgd2hlbiBhIGxpbmsgYnJlYWtz
KSBpcyBhIHdheSBvZiBzYXlpbmcgJnF1b3Q7SSd2ZSBsb3N0IG15IHJvdXRlIHNvIEknbSB0ZWxs
aW5nIG90aGVycyZxdW90OyBhbmQgJnF1b3Q7eW91IHdlcmUgbXkgbmV4dCBob3AsIHNvJm5ic3A7
bm93Jm5ic3A7SSd2ZSBhbHNvIGxvc3QgbXkgcm91dGUsIEknbGwgdGVsbCBvdGhlcnMmcXVvdDss
IGV0Yy4NCiBJdCdzIGdvaW5nIHRvIGJlIHRhaWxvcmVkIGF0IGVhY2ggc3RlcCB0byBpbmNsdWRl
IHRoZSByZWxldmFudCByb3V0ZXMgdGhhdCBnb3QgZGVsZXRlZCwgaXQncyBub3Qgb25lIG1lc3Nh
Z2UgYmVpbmcgc2VudCBlbmQtdG8tZW5kIGxpa2UgUlJFUSBhbmQgUlJFUCBhcmUuJm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gSG93
ZXZlciwgUkVSUiAoc2VudCB3aGVuIGEgc291cmNlIG9mIHRyYWZmaWMgaXMgc2VuZGluZyBkYXRh
IG9uIGEgcm91dGUgd2hpY2ggY29tZXMgdGhyb3VnaCB5b3UsIGFuZCB5b3Ugd2FudCB0byB0ZWxs
IHRoZSBQYWNrZXQgU291cmNlJ3Mgcm91dGVyIHRvIGRlbGV0ZSB0aGUgcm91dGUpIGNvdWxkIGJl
DQogc2VlbiBhcyBhbiBlbmQtdG8tZW5kIG1lc3NhZ2Ugd2hpY2ggYWxsIGludGVybWVkaWF0ZSBy
b3V0ZXJzIGxlYXJuIGZyb20sIHNpbWlsYXIgdG8gUlJFUSBhbmQgUlJFUC4gSXQgcmVwb3J0cyBv
bmUgcm91dGUsIGFuZCBkb2Vzbid0IG5lZWQgY2hhbmdpbmcgYXQgaW50ZXJtZWRpYXRlIGhvcHMs
IHNvIGNvdWxkIGJlIHByb3RlY3RlZCB3aXRoIElDVi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBXb3VsZCBpdCBiZSBPSyB0byBvbmx5IHJl
cXVpcmUgYSBtZXNzYWdlIElDViBpZiBhIFBrdFNvdXJjZSBhZGRyZXNzIHdhcyBpbmNsdWRlZCwg
aS5lLiB3aGVuIHRoZSBtZXNzYWdlIG5lZWRzIHRvIGdvIHZpYSBhIG51bWJlciBvZiBpbnRlcm1l
ZGlhdGUgaG9wcyB0byBQa3RTb3VyY2UncyByb3V0ZXI/IEFsbA0KIG90aGVyIFJFUlJzIGFyZSBp
bnRlbmRlZCB0byBiZSBvbmUtaG9wIG1lc3NhZ2VzLCB3aGljaCBtYXkgaW4gdHVybiBwcm9tcHQg
b3RoZXIgb25lLWhvcCBtZXNzYWdlcywgZXRjLi4uLCBhbmQgYSBwYWNrZXQgSUNWIG1pZ2h0IGJl
IG1vcmUgYXBwcm9wcmlhdGU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPktpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5WaWN0b3JpYS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIE1hciAxNywgMjAxNiBhdCA1OjI2IFBNLCAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmciIHRhcmdldD0iX2JsYW5rIj5p
ZXRmQHRob21hc2NsYXVzZW4ub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDE3IE1hciAyMDE2LCBhdCAxODoxNywg
RGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFy
bG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5
c3RlbXMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5ZZXMsIEkgbWVhbnQgQU9EVnYyLCB0aGFua3MgZm9yIHRoZSBjYXRjaC48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBpcyB5b3VyIChUaG9t
YXMpIHByb3Bvc2VkIGJhc2Ugc3BlY2lmaWNhdGlvbiBhIGhvcCBjb3VudCBvbmx5IG1ldHJpYz88
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv
dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ObywgdGhlIHdvdWxkIGJlIHNpbGx5IGFz
IGJhc2Ugc3BlY2lmaWNhdGlvbiwgZ2l2ZW4gdGhhdCBob3AgY291bnQgbW9zdGx5IGlzIHVzZWxl
c3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5BcyBiYXNlIHNwZWNpZmljYXRpb24gSSB3b3VsZCBzaW1wbHkgc2F5IOKAnEluY2x1ZGUg
YSBNZXRyaWMgVHlwZSBNZXNzYWdlIFRMViB3aXRoIGEgdmFsdWUgZmllbGQsIGFuZCBhIDcxODIg
TWVzc2FnZSBUTFYgJmFtcDsgVGltZXN0YW1w4oCdIGFzIHdlIGRvIGluIE9MU1J2MiAod2l0aCB0
aGUgYXBwcm9wcmlhdGUgdmVyYmlhZ2UNCiBhcyB0byBnZW5lcmF0aW9uIGFuZCBwcm9jZXNzaW5n
KS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPldpdGggdGhlIG1lc3NhZ2UgZ2VuZXJhdGVkIGJ5IHRoZSBvcmlnaW5hdG9yIG9m
IHRoZSBSUkVRL1JSRVAgYW5kICpub3QqIGRlY29uc3RydWN0ZWQvcmVjb25zdHJ1Y3RlZC9yZW9y
ZGVyZWQgKGFzIGlzIHRoZSByaXNrIHdpdGgg4oCccmVnZW5lcmF0aW9uKSBhbGxvd3Mga25vd2lu
ZyB0aGF0IGl0IHdvdWxkIGJlDQogKm9ubHkqIHRoYXQgbWV0cmljIGZpZWxkIGJlaW5nIG1vZGlm
aWVkIChvdGhlciB0aGFuIGhvcCBjb3VudC9saW1pdCkgZm9yIHdoZW4gZXZlbnR1YWxseSB3cml0
aW5nIHVwIHRoZSBleHRlbnNpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+KEFjdHVhbGx5IGRvZXNu4oCZdCB0aGUgY3VycmVudCBzcGVjaWZp
Y2F0aW9uIG9ubHkgZGVmaW5lIGhvcCBjb3VudCwgb3IgaGFzIHRoYXQgY2hhbmdlZCBpbiBsYXRl
c3QNCiBkcmFmdD8pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vLiBUaGF0IGlzIG9uZSBvZiB0
aGUgaXNzdWVzIEkgcmFpc2UgaW4gbXkgb3JpZ2luYWwuIEZvciBzb21lIHJlYXNvbiwgaXQgY2l0
ZXMgUkZDNjU1MSwgd2hpY2ggaXMgYSBST0xMIGRvY3VtZW50IGFuZCB3aGljaCBoYXMgaW4gaXRz
IGFic3RyYWN0IHRoYXQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4m
bmJzcDsmbmJzcDsgTG93LVBvd2VyIGFuZCBMb3NzeSBOZXR3b3JrcyAoTExOcykgaGF2ZSB1bmlx
dWUgY2hhcmFjdGVyaXN0aWNzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGNv
bXBhcmVkIHdpdGggdHJhZGl0aW9uYWwgd2lyZWQgYW5kIGFkIGhvYyBuZXR3b3JrcyB0aGF0IHJl
cXVpcmUgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHNwZWNpZmljYXRp
b24gb2YgbmV3IHJvdXRpbmcgbWV0cmljcyBhbmQgY29uc3RyYWludHMuIDxvOnA+PC9vOnA+PC9w
cmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SS5lLiB0aGlzIGRvY3VtZW50
IGNpdGVzIGEgbWV0cmljIGRvY3VtZW50IHdoaWNoIGNsZWFybHkgY2xhaW1zIHRvIGJlIGluYXBw
bGljYWJsZSBpbiBhZCBob2MgbmV0d29ya3MuIEkgbm90ZSB0aGF0IHRoaXMgaXMgYW5vdGhlciB0
aGluZyBJ4oCZdmUgcmFpc2VkIGZvciB5ZWFycyB3aXRob3V0IHNlZWluZyBpdA0KIGF0dGVtcHRl
ZCByZXNvbHZlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPkJlc3QsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5UaG9tYXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMwMDdFN0UiPi0tPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t
OjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJp
c3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUg
U3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9i
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAw
MDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdE
N0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46
ICZuYnNwOzxhIGhyZWY9InRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0IiB0YXJnZXQ9
Il9ibGFuayI+JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NDwvYT4NCiAmbmJzcDt8ICZuYnNwOzxiPkU6
Jm5ic3A7PC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNocmlzLmRlYXJsb3Zl
QGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxt
c2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENN
MiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0
PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20v
YWk8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lz
dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmds
YW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h
cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5
MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1
cnJleSwgR1UyIDdZUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n
OjMuMHB0IDBjbSAwY20gMGNtO2JvcmRlci1jb2xvcjotbW96LXVzZS10ZXh0LWNvbG9yIC1tb3ot
dXNlLXRleHQtY29sb3IiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8YSBocmVmPSJtYWlsdG86
aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPmlldGZAdGhvbWFzY2xhdXNlbi5vcmc8L3NwYW4+PC9hPiZuYnNwO1s8YSBocmVm
PSJtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0
eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3JnPC9zcGFuPjwv
YT5dJm5ic3A7PGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7MTcgTWFyY2ggMjAxNiAxNzoxMDxicj4N
CjxiPlRvOjwvYj4mbmJzcDtEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4NCjxiPkNjOjwv
Yj4mbmJzcDtMb3R0ZSBTdGVlbmJyaW5rOyBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcg
bGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiZuYnNwO1JlOiBbbWFuZXRdIE1lc3NhZ2UgaW50ZWdy
aXR5IGFuZCBtZXNzYWdlIG11dGFiaWxpdHkgKHdhcyBSRTogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2
djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcyk8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy
OnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyO2JhY2tn
cm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50
ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50
ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5p
c2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48
YnI+DQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBs
aW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPGJyPg0KRm9yIGluZm9ybWF0aW9u
IHJlZ2FyZGluZyZuYnNwOzwvc3Bhbj48L2k+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9iPjxpPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+Jm5ic3A7dGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBp
biBlbWFpbHMNCiB5b3UgcmVjZWl2ZSwgY2xpY2smbmJzcDs8YSBocmVmPSJodHRwOi8vaW50cmFu
ZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3Vt
ZW50cy9SZWQlMjBGbGFncy5wZGYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6
cHVycGxlIj5oZXJlPC9zcGFuPjwvYT4uPGJyPg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1
c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cmbmJzcDs8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50
LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9E
ZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIiB0YXJnZXQ9Il9ibGFuayI+
PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dGhpcyBwcm9jZXNzPC9zcGFuPjwvYT4uPC9zcGFu
PjwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDE3IE1hciAyMDE2LCBhdCAxODowNCwg
RGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFy
bG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw
dXJwbGUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT4mZ3Q7DQogd3Jv
dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPk9LLCBzbyB3ZSBoYXZlIGEgbWVzc2FnZSB0aGF0IG11dGF0ZXMgYnk6PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+LSBNb2RpZnlpbmcgaG9wIGNvdW50L2xpbWl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0gTW9kaWZ5aW5nIGEgbWV0cmlj
IHZhbHVlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPkFueXRoaW5nIGVsc2U/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgbXV0YXRpbmcg
KG90aGVyIHRoYW4gaG9wIGNvdW50L2xpbWl0KSBtZXNzYWdlcyBhcmVu4oCZdCBjb3ZlcmVkIGJ5
IDU0NDQgb3IgYW55IGRlcml2YXRpdmUgZG9jdW1lbnQNCiAoYnV0IG9ubHkgcmVjb21tZW5kZWQg
YWdhaW5zdCwgbm90IGJhbm5lZCkgdGhhdCB5b3UgbWF5IG5lZWQgdG8gbWFrZSB0aGUgbWVzc2Fn
ZSBvdGhlcndpc2UgaW1tdXRhYmxlIChubyBkZWNvbnN0cnVjdGlvbiBhbmQgcmVidWlsZGluZywg
b3RoZXIgdGhhbiBndWFyYW50ZWVkIHVuY2hhbmdpbmcpIHRoYXQgd291bGQgaGF2ZSB0byBiZSBz
cGVjaWZpZWQgYnkgQU9EVnYyLiAoRWFzeSB0byBzYXksIGJ1dCBuZWVkcyBzYXlpbmcuKTwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaXRoIHlv
dSBzbyBmYXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu
LWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPlRoZW4gdGhhdCBpbmZvcm1hdGlvbiBpcyBub3QgaW4gYSBndWFyYW50ZWVk
IGZpeGVkIGxvY2F0aW9uIGdpdmVuIGJ5IGEgc2ltcGxlIG9mZnNldC4gU28gYW55IHNpZ25hdHVy
ZQ0KIGFsZ29yaXRobSB0aGF0IGZpbmRzIGl0IGFuZCBpZ25vcmVzIGl0IG9yIGFnZ3JlZ2F0ZXMg
b24gaXQgaXMgc3BlY2lmaWMgdG8gT0xTUnYyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+U3VyZWx5IHlvdSBtZWFuIEFPRFZ2MjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBzdGFuZGFyZCA3MTgyIElDVnMgZG9u4oCZ
dCBkbyB0aGUgam9iLCB5b3Ugd291bGQgbmVlZCBhbiBBT0RWdjIgc3BlY2lhbGlzZWQgdmFyaWFu
dC4gV2hpY2ggaXMgdGhlDQogc29ydCBvZiB0aGluZyB0aGF0IHRoZSBtZXNzYWdlIHNwZWNpZmlj
IFRMViBzcGFjZSBpcyB0aGVyZSBmb3IsIEnigJlkIGJlIHN0cm9uZ2x5IGFnYWluc3QgYSDigJxi
dXQgaWdub3JlIHRoZSB2YWx1ZSBvZiB0aGlzIHNwZWNpZmljIFRMViBzaG91bGQgaXQgb2NjdXLi
gJ0gYmVpbmcgaW4gdGhlIGdlbmVyYWwgc3BhY2UuIEhvd2V2ZXIgaXQgY2FuIGVhc2lseSBiZSBk
ZWZpbmVkIGJ5IHJlZmVyZW5jZSB0byA3MTgyICjigJx0aGlzIFRMViBpcyBsaWtlIHRoYXQNCiBU
TFYsIGV4Y2VwdCBpZiBhbiBYIFRMViBpcyBwcmVzZW50LCBzZXQgaXRzIHZhbHVlIGZpZWxkIHRv
IHplcm/igJ0pLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1lc3N5LCBidXQgY291bGQgd29yay48L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vdCB0aGF0IG1lc3N5LCBhY3R1YWxseSwgYWx0aG91
Z2ggY2xlYXJseSBub3QgYXMgbmljZSBhcyDigJxmaXhlZCBvZmZzZXTigJ0uPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5UaGF0IHNhaWQsIEkgYW0gYXJndWluZyBmb3IgdGhlIGJhc2Ug
c3BlYyBiZWluZzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
O+KAnG1ha2UgdGhlIG1lc3NhZ2Ugb3RoZXJ3aXNlIGltbXV0YWJsZSAobm8gZGVjb25zdHJ1Y3Rp
b24gYW5kIHJlYnVpbGRpbmcsIG90aGVyJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO3RoYW4gZ3VhcmFudGVlZCB1bmNoYW5naW5nKeKAnSB3aGljaCBpcyBhZmZvcmRlZCBi
eSBmb3J3YXJkaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UkZDNzE4MiBUaW1lc3RhbXBzIGFuZCBJQ1ZzLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwO1JGQzcxODMgc3R5bGUgdGV4dCBicmluZ2luZyBpdCBhbGwgdG9nZXRoZXIu
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUg4oCcYWdncmVnYXRlZCBzaWduYXR1
cmVzIGFyb3VuZCBtdXRhYmxlIGZpZWxk4oCdIHdvdWxkIHZlcnkgYmUgYW4gZXhwZXJpbWVudGFs
IGV4dGVuc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldoYXQgSSBvYmplY3Qg
dG8gaXMsIGlmIHRoZSBiYXNlIHNwZWMgc3BlY2lmaWNhbGx5IHJlbmRlcnMgc3VjaCBleHRlbnNp
b25zIGltcG9zc2libGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tPC9zcGFuPjwvYj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwg
RW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3Jp
ZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JF
QkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOzxhIGhyZWY9InRlbDolMkI0NCUyMCUyODAlMjkxMjQ1
JTIwMjQyMTk0IiB0YXJnZXQ9Il9ibGFuayI+JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NDwvYT4NCiAm
bmJzcDt8ICZuYnNwOzxiPkU6Jm5ic3A7PC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92
ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw
bGUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT48YnI+DQo8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJ
bnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENo
ZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0
ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53
d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRl
ZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1
cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj
bSAwY20gMGNtO2JvcmRlci1jb2xvcjotbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQt
Y29sb3IiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7TG90dGUNCiBTdGVlbmJyaW5r
IFs8YSBocmVmPSJtYWlsdG86bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4uZGUiIHRhcmdldD0i
X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86bG90dGUuc3RlZW5icmlu
a0BmdS1iZXJsaW4uZGU8L3NwYW4+PC9hPl0mbmJzcDs8YnI+DQo8Yj5TZW50OjwvYj4mbmJzcDsx
NyBNYXJjaCAyMDE2IDE2OjQ4PGJyPg0KPGI+VG86PC9iPiZuYnNwO0RlYXJsb3ZlLCBDaHJpc3Rv
cGhlciAoVUspPGJyPg0KPGI+Q2M6PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzppZXRmQHRob21h
c2NsYXVzZW4ub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+
aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzwvc3Bhbj48L2E+OyBNb2JpbGUgQWQgSG9jIE5ldHdvcmtz
IG1haWxpbmcgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiZuYnNwO1JlOiBbbWFuZXRdIE1lc3Nh
Z2UgaW50ZWdyaXR5IGFuZCBtZXNzYWdlIG11dGFiaWxpdHkgKHdhcyBSRTogZHJhZnQtaWV0Zi1t
YW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcyk8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGlu
ZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i
Y2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG87dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioq
PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn
aW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxp
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9y
aWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4
dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljxicj4NCkNvbnNpZGVyIGNhcmVmdWxseSB3
aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50
cyBvciByZXBseS48YnI+DQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nJm5ic3A7PC9zcGFuPjwv
aT48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9z
cGFuPjwvaT48L2I+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4m
bmJzcDt0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscw0KIHlvdSByZWNlaXZlLCBj
bGljayZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93
d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiIgdGFy
Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmhlcmU8L3NwYW4+PC9hPi48
YnI+DQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyZu
YnNwOzxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3Jr
L3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91
cyUyMEVtYWlscy5wZGYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl
Ij50aGlzIHByb2Nlc3M8L3NwYW4+PC9hPi48L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBhbGws
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFt
IDE3LjAzLjIwMTYgdW0gMTc6NDQgc2NocmllYiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAm
bHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9
Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lz
dGVtcy5jb208L3NwYW4+PC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPkdvb2QgcG9pbnQgYWJvdXQgd2hldGhlciB5b3UganVzdCBwYXNzIG9uIG9uZSBjb3N0
IG9yIGEgc2V0IG9mIGNvc3RzLiBBcyBJIHNhaWQsIG5vdCBsb29rZWQgYXQgZGV0YWlscw0KIC0g
SSB3aWxsLCB3aGVuIHRpbWUgcGVybWl0cy4gT25lIGNvc3QgaXMgbXVjaCBlYXNpZXIsIGFuZCB5
ZXMsIGl0IHJlZHVjZXMgdGhlIGZpeGVkIHNpemUgYWdncmVnYXRlZCBzaWduYXR1cmVzIHByb2Js
ZW0gdG8g4oCcanVzdOKAnSBvbmUgb2YgY29tcHV0YXRpb25hbCBsb2FkLjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Rm9yIHRoZSByZWNvcmQsIFRob21hc+KAmSB1bmRlcnN0YW5k
aW5nIGlzIGNvcnJlY3Q7IHRoZSBjb3N0IGlzIG9uZSBhZ2dyZWdhdGVkIHZhbHVlLiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+QmVzdCByZWdhcmRzLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Mb3R0ZSBT
dGVlbnJiaW5rPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox
Mi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS08L3Nw
YW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2Vu
aW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdl
bmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ0
JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzQ0ICgwKTEyNDUg
MjQyMTk0PC9hPg0KICZuYnNwO3wgJm5ic3A7PGI+RTombmJzcDs8L2I+PGEgaHJlZj0ibWFpbHRv
OmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5
bGU9ImNvbG9yOnB1cnBsZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9h
Pjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJy
Pg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lz
dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdy
ZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRw
Oi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGll
ZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBX
YWxlcyBObzogMDEzMzc0NTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
M0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9y
ZCwgU3VycmV5LCBHVTIgN1lQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY207Ym9y
ZGVyLWNvbG9yOi1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvciI+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmlldGZAdGhv
bWFzY2xhdXNlbi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl
Ij5pZXRmQHRob21hc2NsYXVzZW4ub3JnPC9zcGFuPjwvYT4mbmJzcDtbPGEgaHJlZj0ibWFpbHRv
OmlldGZAdGhvbWFzY2xhdXNlbi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s
b3I6cHVycGxlIj5tYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzwvc3Bhbj48L2E+XSZuYnNw
Ozxicj4NCjxiPlNlbnQ6PC9iPiZuYnNwOzE3IE1hcmNoIDIwMTYgMTY6Mzg8YnI+DQo8Yj5Ubzo8
L2I+Jm5ic3A7RGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk8YnI+DQo8Yj5DYzo8L2I+Jm5ic3A7
TW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3Q8YnI+DQo8Yj5TdWJqZWN0OjwvYj4m
bmJzcDtSZTogTWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2UgbXV0YWJpbGl0eSAod2FzIFJF
OiBbbWFuZXRdIGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEgY291cGxlIG9m
IGJpZyB0aWNrZXQgSXRlbXMpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBw
dCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4
dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50
ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPC9zcGFuPjwvYj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu
PSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy
LjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxpPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJv
bSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRu
ZXIgb3IgdGhlIGludGVybmV0Ljxicj4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBz
aG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48
YnI+DQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nJm5ic3A7PC9zcGFuPjwvaT48Yj48aT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L2I+
PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4mbmJzcDt0aGF0IHlv
dSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscw0KIHlvdSByZWNlaXZlLCBjbGljayZuYnNwOzxh
IGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3Vy
aXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiIgdGFyZ2V0PSJfYmxhbmsi
PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmhlcmU8L3NwYW4+PC9hPi48YnI+DQpJZiB5b3Ug
ZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyZuYnNwOzxhIGhyZWY9
Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nw
b3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5w
ZGYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50aGlzIHByb2Nl
c3M8L3NwYW4+PC9hPi48L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiAxNyBNYXIgMjAxNiwgYXQg
MTc6MzAsIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hy
aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i
Y29sb3I6cHVycGxlIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvc3Bhbj48L2E+Jmd0
Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFwcHJlY2lhdGUgVGhvbWFz4oCZcyBjb21tZW50cyBh
Ym91dCB0aGUgbGltaXRhdGlvbnMgb2YgbWVzc2FnZSByZWdlbmVyYXRpb24sIGJ1dCBJIHdvdWxk
IGJlIGEgYml0DQogbGVzcyBhYnNvbHV0ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgaXNzdWVz
IG92ZXIgZW5kIHRvIGVuZCBhdXRoZW50aWNhdGlvbiBhbmQgbW9yZSBhZHZhbmNlZCBzaWduYXR1
cmVzIGFyZSB2YWxpZC4gSSBuZWVkIHRvIHJlYWQNCiB0aGUgZ2l2ZW4gcmVmZXJlbmNlIG9uIGFn
Z3JlZ2F0ZSBzaWduYXR1cmVzIHRvIGluY3JlYXNlIG15IGtub3dsZWRnZSAodGhhbmtzIGZvciBp
dCksIGJ1dCBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBwb3NzaWJpbGl0aWVzIGluIHRoaXMgZmll
bGQgbWF5IG9mZmVyIGEgc29sdXRpb24gdG8gdGhlIHByb2JsZW0sIGJ1dCB3aXRoIHNvbWUgb3Ro
ZXIgaXNzdWVzIChwb3NzaWJseSBpbmNsdWRpbmcgYSBuZXcgdHlwZSBvZiBUTFYpLjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPkJ1dCB0aGUgaG9wIGNvdW50L2xpbWl0IHBvaW50IEkgZG9u4oCZdCBmdWxs
eSBhZ3JlZSB3aXRoLCB5b3UgY2FuIHJlZ2VuZXJhdGUgd2l0aCBhbiBpbmNyZW1lbnRlZC9kZWNy
ZW1lbnRlZA0KIGNvdW50L2xpbWl0LCB3aGljaCBsZWF2ZXMgdGhlIGFiaWxpdHkgdG8gcHJldmVu
dCBtZXNzYWdlcyBwcm9wYWdhdGluZyBpbmRlZmluaXRlbHksIGluY2x1ZGluZyBleHBhbmRpbmcg
cmluZyBzZWFyY2hlcywgYW5kIHJldGFpbnMgdGhlIGFiaWxpdHkgdG8gdXNlIFJGQyA1NDk3IGlu
dGVydmFsIGFuZCB2YWxpZGl0eSB0aW1lcyB0aGF0IG1pZ2h0IGJlIHVzZWZ1bCB3aXRoIGFuIGV4
cGFuZGluZyByaW5nIHNlYXJjaCAob3IgbWlnaHQgbm90KS48L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5C
dXQgdGhlIGtleSBpc3N1ZSBpcyB0aGF0IEFPRFZ2MiB3YW50cyB0byBhY2N1bXVsYXRlIG1ldHJp
Y3MuIEkgc3RpbGwgaGF2ZW7igJl0IGdvdCB0byB0aGUgYm90dG9tIG9mDQogbWFueSBkZXRhaWxz
IGhlcmUsIGJ1dCBsZXTigJlzIGZvciB0aGUgbW9tZW50IGp1c3QgY29uc2lkZXIgdGhhdCBjb25j
ZXB0dWFsbHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXTigJlzIGhhcmQgdG8gaGFuZGxlIGVuZCB0
byBlbmQuIENoYXJsaWXigJlzIGRyYWZ0IGF0dGVtcHRzIHRvIGRvIGFuIGVuZCB0byBlbmQgb2Yg
c29tZSBpbmZvcm1hdGlvbiwNCiBub3QgdGhpcyBpbmZvcm1hdGlvbi4gSeKAmW0gbm90IHN1cmUg
aWYgdGhhdOKAmXMgdXNlZnVsIChhbmQgdGhlIHNwZWNpYWxpc2VkIGZvcm1hdCBpcyBiZXR0ZXIg
YXZvaWRlZCBpZiBwb3NzaWJsZSkuIE90aGVyIGFwcHJvYWNoZXMgYXJlIGhvcCBieSBob3AgKG1p
Z2h0IGFzIHdlbGwgdXNlIHBhY2tldCBzaWduYXR1cmVzKSBhbmQgc2hhcmVkIGtleSAobWlnaHQg
YXMgd2VsbCBnbyBob3AgYnkgaG9wKS4gUGFpcndpc2Ugc2lnbmF0dXJlcyBmb3IgZWFjaA0KIHBh
aXIgb2Ygcm91dGVycyBJ4oCZbSBkaXNjb3VudGluZyBhcyBzY2FsaW5nIHRlcnJpYmx5LiBJbiB0
aGUgaW50ZXJlc3RzIG9mIGNvbXBsZXRlbmVzcyBsZXTigJlzIG1lbnRpb24gbm90IGFjY3VtdWxh
dGluZyBtZXRyaWNzLCB3aGljaCBwdXRzIHVzIGJhY2sgdG8gaG9wIGNvdW50IGFuZCB0aGF04oCZ
cyBub3QgaWRlYWwgZWl0aGVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB0aGluayB0
aGVyZSBpcyBhbiBpZGVhbCBzb2x1dGlvbi4gKEkgbGlrZSBpZGVhcyBJ4oCZdmUgc2VlbiBhYm91
dCBhZ2dyZWdhdGluZywgYnV0IHRoYXQgaGFzDQogc29tZSBpc3N1ZXMgb2YgaXRzIG93biwgZXZl
biBhcGFydCBmcm9tIGNvbXB1dGF0aW9uYWwgbG9hZC4pIEnigJlkIGxvdmUgdG8gYmUgcHJvdmVk
IHdyb25nIC0gc29tZW9uZSB3aXRoIHRoZSBwZXJmZWN0IHNvbHV0aW9uIHRvIGNvbWUgYWxvbmcu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hpY2ggbWVhbnMgdGhhdCBlaXRoZXIgd2UgbWFrZSBhbiBh
cmJpdHJhcnkgY2hvaWNlIC0gd2hpY2ggd2lsbCBiZSBkaXNhZ3JlZWQgd2l0aCwgYnV0IG5lZWRz
IGRpc2N1c3NpbmcNCiBmaXJzdCAtIG9yIGNyZWF0ZSBzb21ldGhpbmcgZmxleGlibGUuIFVuZm9y
dHVuYXRlbHkgZmxleGlibGUgaW4gdGhhdCByZWdhcmQgY29uc3RyYWlucyBpbiBvdGhlcnMsIGUu
Zy4gc29tZSAobWFueT8gbW9zdD8pIGFnZ3JlZ2F0aW5nIHNpZ25hdHVyZXMgbmVlZCBmaXhlZCBk
YXRhIHNpemVzICh3aGljaCB3ZSBjYW4gZG8gYnkgZGVmaW5pbmcgYSBUTFYgdGhhdCDigJxmaWxs
cyB1cOKAnSB3aXRoIGhvcCBjb3VudCwgYnV0IHRoYXQgaGFzIGEgY29zdCB0b28pLjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGhhdmUg
YmVlbiB0b2xkIGJ5IHBlb3BsZSBtdWNoIG1vcmUgd2VsbCB2ZXJzZWQgaW4gdGhpcyB0aGFuIEkg
aW4gY3J5cHRvbG9neSwgdGhhdCB0aGUgY29ycmVjdCBhbnN3ZXIgaXMg4oCcc29tZeKAnS48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYXQgc2FpZCwgJnF1b3Q7QU9EVnYyIHdh
bnRzIHRvIGFjY3VtdWxhdGUgbWV0cmljc+KAnSDigJQgZG9lcyB0aGF0IG1lYW4gdGhhdCB0aGUg
bWVzc2FnZSBncm93cyBhcyBpdCBpcyBiZWluZyBmb3J3YXJkZWQsIGFuZCB0aGF0IHRoZSByZWNp
cGllbnQgb2YgYSBSUkVRL1JSRVAgd2lsbCBrbm93IHRoZSBpbmRpdmlkdWFsDQogY29zdHMgb2Yg
ZWFjaCBwYXRoIHNlZ21lbnQ/IE15IHVuZGVyc3RhbmRpbmcgaXMsIHRoYXQgdGhlIHJlY2lwaWVu
dCB3aWxsIGdldCDigJx0aGUgc3VtIHRoZSBjb3N0cyBvZiBlYWNoIHBhdGggc2VnbWVudOKAnSB3
aGljaCBzaG91bGQgYmUgZml0dGluZyB3aXRoaW4gYSBmaXhlZCBzaXplPzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+VGhvbWFzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+U29ycnksIG5vIGFuc3dlcnMsIGp1c3QgY29tbWVudHMuIEFuZCBJ
4oCZbSBub3QgYWRkcmVzc2luZyBUaG9tYXPigJlzIGxhdGVyIHBvaW50cyBoZXJlLjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLTwvc3Bhbj48L2I+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJp
bmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFi
b3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgw
JTI5MTI0NSUyMDI0MjE5NCIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8
L2E+DQogJm5ic3A7fCAmbmJzcDs8Yj5FOiZuYnNwOzwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMu
ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s
b3I6cHVycGxlIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvc3Bhbj48L2E+PGJyPg0K
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFw
cGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFk
ZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cu
YmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzNB
OEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGll
ZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBX
YWxlcyBObzogMDEzMzc0NTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywg
R3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGlu
ZzozLjBwdCAwY20gMGNtIDBjbTtib3JkZXItY29sb3I6LW1vei11c2UtdGV4dC1jb2xvciAtbW96
LXVzZS10ZXh0LWNvbG9yIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
Jm5ic3A7bWFuZXQNCiBbPGEgaHJlZj0ibWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmciIHRh
cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86bWFuZXQtYm91
bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XSZuYnNwOzxiPk9uIEJlaGFsZiBPZiZuYnNwOzwvYj48
YSBocmVmPSJtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxz
cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlldGZAdGhvbWFzY2xhdXNlbi5vcmc8L3NwYW4+PC9h
Pjxicj4NCjxiPlNlbnQ6PC9iPiZuYnNwOzE3IE1hcmNoIDIwMTYgMTY6MDA8YnI+DQo8Yj5Ubzo8
L2I+Jm5ic3A7TW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3Q8YnI+DQo8Yj5TdWJq
ZWN0OjwvYj4mbmJzcDtbbWFuZXRdIGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAt
IGEgY291cGxlIG9mIGJpZyB0aWNrZXQgSXRlbXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNv
bGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91
bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50ZXI7
YmFja2dyb3VuZDp3aGl0ZSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz
MzM5NzIiPioqKiBXQVJOSU5HICoqKjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7
YmFja2dyb3VuZDp3aGl0ZSI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz
MzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0
aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48YnI+
DQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5r
cywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPGJyPg0KRm9yIGluZm9ybWF0aW9uIHJl
Z2FyZGluZyZuYnNwOzwvc3Bhbj48L2k+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9iPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzMzMzk3MiI+Jm5ic3A7dGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBl
bWFpbHMNCiB5b3UgcmVjZWl2ZSwgY2xpY2smbmJzcDs8YSBocmVmPSJodHRwOi8vaW50cmFuZXQu
ZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50
cy9SZWQlMjBGbGFncy5wZGYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy
cGxlIj5oZXJlPC9zcGFuPjwvYT4uPGJyPg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3Bp
Y2lvdXMsIHBsZWFzZSBmb2xsb3cmbmJzcDs8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJh
ZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFs
aW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIiB0YXJnZXQ9Il9ibGFuayI+PHNw
YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dGhpcyBwcm9jZXNzPC9zcGFuPjwvYT4uPC9zcGFuPjwv
aT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzoxLjBwdCA0LjBwdCAxLjBwdCA0LjBw
dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50
ZXIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPio8Yj4qKiZuYnNwOzwvYj48L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+V0FSTklORyZuYnNwOzwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPioqKjwvc3Bh
bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+RVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMg
ZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5EZWFyIGFsbCw8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcG9sb2dpZXMgZm9yIG5v
dCBoYXZpbmcgZ290dGVuIHRoaXMgZG9uZSBzb29uZXIgLSBkYXktam9iIGxlYXZpbmcgZmV3IHNw
YXJlIGN5Y2xlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPknigJl2ZSBwcmV2aW91c2x5IG9mZmVyZWQgcmV2aWV3cyBhbmQg
Y29tbWVudHMsIGFuZCBzb21lIG9mIHRob3NlIGhhdmUgYmVlbiBhZGRyZXNzZWQgaW4gdGhlIGxh
dGVzdCBJLUQg4oCUIG90aGVycyBoYXZlIG5vdCwgYnV0IHNob3VsZCBiZS4gSSByZWNhbGwgdGhh
dCB0aGVyZSB3YXMgc29tZSBtYWlsIGF0dGVtcHRpbmcNCiB0byByZWJ1dCBwYXJ0cyBvZiB0aGUg
cmV2aWV3LCBhbmQgSSB3aWxsIGRpZyBpdCBvdXQgYW5kIHJlcGx5IHRvIHRoYXQuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5X
aXRoIHRoYXQgYmVpbmcgc2FpZCwgSSBoYXZlIHJldmlld2VkIHRoZSBsYXRlc3QgdmVyc2lvbiBv
ZiB0aGUgZG9jdW1lbnQsIGFuZCBmdWxsIGRldGFpbHMgd2lsbCBiZSBmb3J0aGNvbWluZy4gVGhl
cmXigJlyZSBhIGNvdXBsZSBvZiBiaWctdGlja2V0L2FyY2hpdGVjdHVyYWwgaXRlbXMgdGhhdCBJ
IHdhbnQgdG8NCiBhZGRyZXNzIHVwIGZyb250LCBhcyBJIGJlbGlldmUgdGhhdCBiZWZvcmUgd2Ug
aGF2ZSB0aG9zZSBoYW1tZXJlZCBvdXQsIGl0IHdpbGwgYmUgdXNlbGVzcyB0byBnbyBpbnRvIGRl
dGFpbHMuIE5vdGUsIEkgZG8gbm90IGNsYWltIHRoYXQgdGhpcyBpcyBhbiBleGhhdXN0aXZlIGxp
c3Qgb2Yg4oCcYmlnIHRpY2tldCBpdGVtc+KAnSwgYnV0IHRoYXTigJlzIGFzIGZhciBhcyBJIGhh
dmUgZ290dGVuIGluIHRoaW5raW5nIHRoaXMgdGhyb3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYWxzbyBicmluZyB0
aGVzZSB1cCBhcyB0aGV5IGFyZSBpdGVtcyB0aGF0IGhhdmUgYmVlbiBicm91Z2h0IHVwIHJlcGVh
dGVkbHkgb3ZlciB0aGUgcGFzdCB5ZWFycywgYnV0IG5vdCByZXNvbHZlZCBub3IgZGlzY3Vzc2Vk
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PGI+PHU+TG9vcHM8L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5KdXN0IHRvIGJyaW5nIHRoaXMgb3V0OiBJIHNo
YXJlIENocmlz4oCZIHdvcnJ5IGFib3V0IGNvbmZsaWN0aW5nIGFuZCBjb25jdXJyZW50IHN0YXRl
bWVudHMgZnJvbSB0aGUgYXV0aG9ycyBvbiDigJxUaGVyZSBhcmUgbm8gbG9vcHMgcG9zc2libGXi
gJ0gYW5kIOKAnFdlIG5lZWQgdG8gZml4IHR3byBzaXR1YXRpb25zIHdoZXJlDQogbG9vcHMgY2Fu
IG9jY3Vy4oCdIGFuZCDigJx3ZSBhcmUgc3RpbGwgaW52ZXN0aWdhdGluZyBzb21lIGxvb3AgY29u
ZGl0aW9uc+KAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+SSBwYXJ0aWN1bGFybHkgd29ycnkgdGhhdCB0aGlzIGlzIG5vdCBh
IGRpc2N1c3Npb24gaGFkIGluIHB1YmxpYywgYnV0IGFwcGFyZW50bHkgaW4gc29tZSBvdGhlciBm
b3J1beKApjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48dT5JbnRlcm1lZGlhdGUgUm91dGUgUmVw
bGllcywgYW5kIGFsbCBvZiBzZWN0aW9uIDEwPC91PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2VjdGlvbiAxMCBjb250YWlucyBh
IHNldCBvZiDigJx2YWd1ZWx5IHNwZWNpZmllZCBleHRlbnNpb25z4oCdLCB3aGljaCBpcyBpbmNv
aGVyZW50IHdpdGggdGhlIGludGVuZGVkIHN0YXR1cyBpbmRpY2F0ZWQgZm9yIHRoaXMgZG9jdW1l
bnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5TcGVjaWZpY2FsbHksIGFuZCB0aGlzIGlzIG5vdCB1bnJlbGF0ZWQg
dG8gdGhlIHBvaW50IGFib3V0IGxvb3BzIGFib3ZlLCBpbnRlcm1lZGlhdGUgUlJFUHMgKHNlY3Rp
b24gMTAuMykgYXJlIGEgcG90ZW50aWFsIHNvdXJjZSBmb3IgbG9vcHMuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5FeHBhbmRp
bmcgUmluZyBNdWx0aWNhc3QgKHNlY3Rpb24gMTAuMSkgaXMgbm90IGRvY3VtZW50ZWQgaW4gYSB3
YXkgdGhhdCBjYW4gYmUgaW1wbGVtZW50ZWQgKGFuZCBhbHNvLCBzZWUg4oCcRm9yd2FyZGluZy12
cy1yZWdlbmVyYXRpb27igJ0gYmVsb3csIGl0IGlzIGluIHRoZSBwcmVzZW50IGZvcm0gb2YgdGhp
cyBwcm90b2NvbA0KIGltcG9zc2libGUpLCBldGMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48
dT5Gb3J3YXJkaW5nLXZzLXJlZ2VuZXJhdGlvbjwvdT48L2I+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlY2VudCBleGNoYW5nZXMgb24g
dGhlIGxpc3QgbWFkZSBtZSB1bmRlcnN0YW5kIHRoYXQgcHJvdG9jb2wgY29udHJvbCBtZXNzYWdl
cyBhcmUgKm5vdCogZm9yd2FyZGVkLCBidXQgYXJlIGNvbnN1bWVkIGF0IGVhY2ggaG9wLCB0aGVu
IGEgbmV3IG1lc3NhZ2Ugd2l0aCAoYWxtb3N0LWJ1dC1ub3QtcXVpdGUpDQogdGhlIHNhbWUgY29u
dGVudCBpcyBnZW5lcmF0ZWQgYW5kIHRyYW5zbWl0dGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBoYXZlIHRob3VnaHQg
c29tZSBtb3JlIG9uIHRoaXMgKCZhbXA7IHJlYWQgc29tZSBvZiB0aGUgZXhjaGFuZ2VzIG9uIHRo
ZSBsaXN0IG9uIHRoaXMgdG9waWMgYnkgQ2hyaXMsIFVscmljaCwgYW5kIG90aGVycyksIGFuZCBJ
IGFtIGNvbnZpbmNlZCB0aGF0IHRoaXMgaXMgbm90IHRoZSByaWdodCB3YXkgdG8gZ28sJm5ic3A7
PGI+YXQNCiBsZWFzdDwvYj4mbmJzcDtmb3IgdGhlIGZvbGxvd2luZyByZWFzb25zOjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwO28mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8Yj5JdCByZW5kZXJzIHRoZSBob3AtbGltaXQvaG9w
LWNvdW50IGZpZWxkcyBpbiB0aGUgUkZDNTQ0NCBtZXNzYWdlIGhlYWRlciB1c2VsZXNzLjwvYj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyB3b3VsZCBub3QgYmUgYmFkIGlmIHRo
ZSBmdW5jdGlvbmFsaXR5IG9mZmVyZWQgYnkgdGhvc2UgZmllbGRzIHdhcyBub3QgdXNlZnVsPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO+KAlCBzYWRseSwgaXQgaXMuIEZvciBleGFtcGxl
LCBmb3Igc2NvcGUgbGltaXRlZCBmbG9vZGluZyAoZXhwYW5kaW5nIHJpbmcgc2VhcmNoLCBhbmQm
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c3VjaCkgd2hpY2ggbWF5IGJlIG9m
IGludGVyZXN0LCBhbmQgd2hpY2ggcmVxdWlyZSBob3AtbGltaXQuJm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwO0EgaG9wLWNvdW50IGZpZWxkIG1heSBhbHNvIHByb3ZpZGUgYSDi
gJxjaGVhcOKAnSAoaW4gdGVybXMgb2Ygb3ZlcmhlYWQpIGFkZGl0aW9uYWwgcGllY2U8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7b2YgaW5mb3JtYXRpb24gdG8gdXNlIGNvbmp1bmN0aXZl
bHkgd2l0aCBhIOKAnHJlYWzigJ0gbWV0cmljLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7VGhlIG9ubHkgcHJhY3RpY2FsIHNvbHV0aW9uIHdvdWxkIGJlIHRvIHJlLWludHJv
ZHVjZSB0aGVzZSBmdW5jdGlvbnMgYnkgd2F5IG9mIGluc2VydGluZyBhPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO01lc3NhZ2VUTFYg4oCUIHdoaWNoIChpKSBpcyBub3Qgc3BlY2lmaWVk
IGluIHRoaXMgZG9jdW1lbnQsIGFuZCAoaWkpIHdoaWNoIHdvdWxkIGp1c3Q8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7c2VydmUgdG8gcmVuZGVyIG1lc3NhZ2VzIGJpZ2dlciB0aGFuIHN0
cmljdGx5IG5lZWRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1Njb3Bl
IGxpbWl0ZWQgZmxvb2RpbmcgJm5ic3A7ZG9lcyBzZWVtIHRvIGJlIGEgbmVjZXNzYXJ5IHJlcXVp
cmVtZW50LCBpZiBmb3Igbm88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7b3RoZXIgcmVh
c29uIHRoYW4gdG8gcHJldmVudCBpbmZvcm1hdGlvbiBmcm9tIOKAnGNpcmN1bGF0aW5nIGZvcmV2
ZXIgaW4gdGhlIG5ldHdvcmvigJ0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvJm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGI+PHU+SXQg
bWFrZXMgZW5kLXRvLWVuZCBhdXRoZW50aWNhdGlvbiB1bm5lY2Vzc2FyaWx5IGhhcmQuPC91Pjwv
Yj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SSB0aGluayBDaHJpcyBjYWxsZWQgdGhp
cyBvdXQgYWxyZWFkeSwgYnV0IGl0IGJlYXJzIHJlcGVhdGluZzogUyBnZW5lcmF0ZXMgYSBtZXNz
YWdlJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyhzYXksIGEgUlJFUSksIGFu
ZCBpbmNsdWRlcyBhbiBJQ1YgY2FsY3VsYXRlZCBvdmVyIHRoZSBjb250ZW50IG9mIHRoZSBtZXNz
YWdlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtGb3IgYW55IHJlY2lwaWVudCB0byBi
ZSBhYmxlIHRvIHZhbGlkYXRlIHRoZSBJQ1YsIHRoZSBtZXNzYWdlIGhhcyB0byBiZSBleGFjdGx5
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoZSBzYW1lIOKAlCBub3QganVzdCBpbiBj
b250ZW50LCBidXQgaW4gc3RydWN0dXJlIOKAlCBhcyB3aGF0IHdhcyBnZW5lcmF0ZWQuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvigJxSZWdlbmVyYXRpbmfigJ0gcmF0aGVy
IHRoYW4g4oCcZm9yd2FyZGluZ+KAnSBtZXNzYWdlcyBtZWFucywgdGhhdCB0aGUgaW50ZXJtZWRp
YXRlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JvdXRlciDigJxyZWdlbmVyYXRpbmfi
gJ0gdGhlIFJSRVEgbWF5IGNob3NlIGEgZGlmZmVyZW50IHN0cnVjdHVyZSAoZS5nLiwgaW5jbHVk
ZSBUTFZzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2luIGEgZGlmZmVyZW50IG9yZGVy
KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSBwcm9wb3NhbCBmcm9t
Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlcmtpbnMt
bWFuZXQtYW9kdi1lMmVzZWMtMDAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6
cHVycGxlIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1h
b2R2LWUyZXNlYy0wMDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2lz
IHRvIGFkZCBjb25zdHJhaW50cyBvbiAoaSkgdGhlIHNldCBvZiBlbGVtZW50cyB0byBpbmNsdWRl
IGluIGEgc2lnbmF0dXJlIGFuZCAoaWkpIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDtvcmRlciBvZiB0aGVzZSBlbGVtZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO09uZSZuYnNwO3Byb2JsZW0gd2l0aCB0aGF0IGFwcHJvYWNoIGlzIChpKTogaWYgYW4g
ZXh0ZW5zaW9uIGFkZHMgYSBtZXNzYWdlIFRMViwgb3IgYW4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7QWRkcmVzcyBUTFYsIHRvIGEgbWVzc2FnZSwgdGhlbiB0aGF0IHdpbGwg
bm90IGJlIOKAnGNvdmVyZWTigJ0gYnkgdGhlIHByb3Bvc2VkIGUyZXNlYyBUTFYuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwO1JhdGhlciBmb3IgKmVhY2gqIGV4dGVuc2lvbiBkZXZlbG9w
ZWQsIGFuIOKAnHVwZGF0ZXMgZTJlc2Vj4oCdIGNsYXVzZSBuZWVkcyB0byBiZSBkb25lLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SeKAmWQgc2F5IHRoYXQgdGhpcyBhcHBy
b2FjaCB3b3VsZCBiZSBwcm9uZSB0byBlcnJvcnMg4oCUIGFuZCBhZGQgZW50cm9weSB0byB0aGUg
cHJvY2VzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvZiBkZXNpZ25pbmcgcHJvdG9j
b2wgZXh0ZW5zaW9ucy4gVGhlIGFsdGVybmF0aXZlLCBhIG1lc3NhZ2UgYmVpbmcgZ2VuZXJhdGVk
IGJ5IHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzb3VyY2UgYW5kICpmb3J3YXJk
ZWQqIChhcyB3ZSBkbyBpbiBPTFNSdjIsIGZvciBleGFtcGxlKSB3b3VsZCBhbGxvdyBJQ1YgVExW
cyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsoZXZlbiwgYWxsb3cgcmV1c2Ug
b2YgdGhvc2Ugc3BlY2lmaWVkIGZvciBPTFNSdjIpIGZvciBjb3ZlcmluZyBhIG1lc3NhZ2UgYW5k
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2V4dGVuc2lvbnMuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvigJxCdXQgd2hhdCBhYm91dCB0aGUgbWV0cmlj
cyB2YWx1ZSB3aGljaCB3aWxsIGNoYW5nZSBvbiBlYWNoIGhvcOKAnSwgeW91IG1heSBzYXk/PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0ZvcnR1bmF0ZWx5LCB0aGF0IGlzIHJlbGF0aXZl
bHkgZWFzeSB0byBoYW5kbGU6IHNpbXBseSB6ZXJvIG91dCB0aGUgdmFsdWUgb2YgdGhhdCBUTFYg
d2hlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtnZW5lcmF0aW5nIG9yIHZlcmlmeWlu
ZyB0aGUgSUNWIE1lc3NhZ2VUTFYuIEFuZCB1c2UgUGFja2V0LVRMVnMgZm9yIGhvcC1ieS1ob3Am
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YXV0aGVudGljYXRpb24sIGlmIG5l
ZWRlZCAoYnV0LCBzZWUgYmVsb3cpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7byZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxiPjx1Pkl0
IHByZXZlbnRzIHRoZSB1c2Ugb2YgbW9yZSBjbGV2ZXIvYWR2YW5jZWQgc2lnbmF0dXJlIHNjaGVt
ZXMvSUNWczwvdT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0FnZ3JlZ2F0ZSBz
aWduYXR1cmUgYWxnb3JpdGhtcyAoJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9jcnlwdG8uc3RhbmZv
cmQuZWR1L35kYWJvL3BhcGVycy9hZ2dzdXJ2ZXkucGRmIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g
c3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9jcnlwdG8uc3RhbmZvcmQuZWR1L35kYWJvL3Bh
cGVycy9hZ2dzdXJ2ZXkucGRmPC9zcGFuPjwvYT4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwO2V4aXN0LCBhbmQgYW4gaW50ZXJlc3RpbmcgdXNlLWNhc2UgY2FuIGJlIGZvdW5kIGluIGFs
c28gcmVhY3RpdmUgcHJvdG9jb2xzLCBhbGxvd2luZyB2ZXJpZnlpbmc8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7bm90IOKAnGp1c3TigJ0gdGhlIGVuZCBwb2ludHMsIGJ1dCBhbHNvIHRo
ZSBpbnRlcm1lZGlhcmllcyAoYWdhaW4sIHdpdGggdGhlIGFwcHJvcHJpYXRlIOKAnHplcm8gb3V0
4oCdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Rpc2N1c3NlZCBhYm92ZSwgb3Igc29t
ZXRoaW5nIHNtYXJ0ZXIpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtSZWdlbmVyYXRp
b24gb2YgbWVzc2FnZXMsIHJhdGhlciB0aGFuIGZvcndhcmRpbmcsIHJlbmRlcnMgdGhhdCBpbXBv
c3NpYmxlIChvciwgaWYgdXNlZCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dXBkYXRp
bmcgdG8gJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBl
cmtpbnMtbWFuZXQtYW9kdi1lMmVzZWMtMDAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i
Y29sb3I6cHVycGxlIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVya2lucy1t
YW5ldC1hb2R2LWUyZXNlYy0wMDwvc3Bhbj48L2E+KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlcmUgYXJlIG90aGVyIHJl
YXNvbnMsIGJ1dCB0aGUgYWJvdmUgYXJlIHRob3NlIHRoYXQganVtcCBhdCBtZSBhcyBpbW1lZGlh
dGUgc2hvdy1zdG9wcGVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZG8gaG9uZXN0bHkgbm90IHNlZSB3aGF0IHBvc3Np
YmxlIGJlbmVmaXQgdGhlcmUgaXMgZnJvbSDigJxyZWdlbmVyYXRpb27igJ0g4oCUIGJ1dCBJIHNl
ZSB2ZXJ5IGNsZWFyIGluY29udmVuaWVuY2VzLCBhbmQgc2VjdXJpdHkgaXMgbm90IHRoZSBsZWFz
dCBvZiB0aGVzZS4gSW5zaXN0aW5nIG9uIOKAnHJlZ2VuZXJhdGlvbuKAnQ0KIHJlcXVpcmVzIGRl
dmVsb3BtZW50IG9mIOKAnG5vbi1nZW5lcmFsIHdvcmthcm91bmRz4oCdIGFzIHBvaW50ZWQgb3V0
IGFib3ZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PGI+PHU+U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3U+PC9iPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlz
IGlzIGFuIGFsd2F5cyB0aG9ybnkgc3ViamVjdC4gV2hlbiBPTFNSdjIgd2FzIGdvaW5nIHRocm91
Z2ggdGhlIHByb2Nlc3Mgd2UgZ290IGEgdGhvcm91Z2ggZWR1Y2F0aW9uIGluIGhvdyBsaXR0bGUg
d2Uga25ldyBhYm91dCBzZWN1cml0eSBmcm9tIHRoZSBTRUMtQURzLCBhbmQgaGFkIHRvIHNwZW5k
IGFib3V0DQogYSB5ZWFyIG9yIHNvIGRldmVsb3BpbmcgUkZDNzE4My4gVGhlIGJvdHRvbSBsaW5l
IGlzLCB0aGF0IHRoaXMgcHJvdG9jb2wgbmVlZHMgaXRzIOKAnFJGQzcxODMgJm5ic3A7ZXF1aXZh
bGVudOKAnSwgZWl0aGVyIGFzIHBhcnQgb2YgdGhlIG1haW4gZG9jdW1lbnQsIG9yIGFzIGFuIGlu
ZGVwZW5kZW50IGRvY3VtZW50LiBjdXJyZW50bHksIHRoYXQgaXMgbm90IHRoZSBjYXNlLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+QSBtaW5pbWEsIGxvb2tpbmcgYXQgQkNQNzIgYW5kIEJDUDEwNyDigJQgdGFraW5nIGluc3Bp
cmF0aW9uIGZyb20gUkZDNzE4MyBtaWdodCBiZSBhdyBnb29kIGlkZWEsIGFzIHRoYXQgd2FzIHRo
ZSBtb3N0IHJlY2VudCB0aGF0IHdlbnQgdGhyb3VnaCB0aGUgU0VDIEFELiBSZWdhcmRsZXNzIG9m
IGhvdywgaG93ZXZlciwNCiBhIOKAnG1hbmRhdG9yeSB0byBpbXBsZW1lbnTigJ0gc2VjdXJpdHkg
bWVjaGFuaXNtIG1vc3QgYmUgc3BlY2lmaWVkIChJIHRoaW5rIHRoZSByaWdodCB0ZXJtIHdhcyDi
gJxNVVNUIGltcGxlbWVudCwgU0hPVUxEIHVzZeKAnSksIGluIHN1ZmZpY2llbnQgZGV0YWlsIHRv
IGVuc3VyZSBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFzIGFuIGV4YW1w
bGUsIGJvdGggW1JGQzYxMzBdIGFuZCBbUkZDNzE4MV0gc2V0IG91dCB0aGF0IHRoYXQ6PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgT24gcmVjZWl2aW5nIGEgLi4uIG1lc3NhZ2Us
IGEgcm91dGVyIE1VU1QgZmlyc3QgY2hlY2sgaWYgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7IG1l
c3NhZ2UgaXMgaW52YWxpZCBmb3IgcHJvY2Vzc2luZyBieSB0aGlzIHJvdXRlcjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YW5k
IHRoZW4gcHJvY2VlZCB0byBnaXZlIGEgbnVtYmVyIG9mIGNvbmRpdGlvbnMgdGhhdCwgZWFjaCwg
d2lsbCBsZWFkIHRvIGEgcmVqZWN0aW9uIG9mIHRoZSBtZXNzYWdlIGFzICZxdW90O2JhZGx5IGZv
cm1lZCBhbmQgdGhlcmVmb3JlIGludmFsaWQgZm9yIHByb2Nlc3NpbmfigJ0g4oCUIGEgbGlzdCB3
aGljaCBSRkM3MTgzDQogdGhlbiBhbWVuZGVkLiBUaGF0IGdhdmUgYSDigJxob29r4oCdIGZvciBS
RkM3MTgzIGZvciBpbnNlcnRpbmcg4oCccmVqZWN0aW9u4oCdLiBJZGVtIGZvciBtZXNzYWdlIGdl
bmVyYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5JZiBJIHdhcyB0byBkbyBSRkM3MTgxL1JGQzYxMzAgdG9kYXksIEkg
d291bGQgaW5jbHVkZSB0aGF0IGRpcmVjdGx5IGludG8gdGhlIHByb3RvY29sIHNwZWNpZmljYXRp
b25zLiBJdCB0dXJuZWQgb3V0IHRvIGJlIG1vcmUgb3ZlcmhlYWQgKGFuZCBzbG93IGRvd24gcHVi
bGljYXRpb24gYW55d2F5cykgdG8gZG8NCiBpdCBhcyBzZXBhcmF0ZSBkb2N1bWVudHMuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPlNlY29uZGx5LCB3ZSBuZWVkIHRvIGJlIGEgbG90IG1vcmUgcmlnaWQgaW4gdGVy
bXMgb2Ygd2hhdCBJQ1ZzLCBUaW1lc3RhbXBzLCBldGMuIGFyZSBhZGRlZC9yZW1vdmVkLCBhbmQg
d2hhdCB0aGF0IGJyaW5ncy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvciBleGFtcGxlICh3aXRoIHRoZSBhc3N1bXB0aW9u
IHRoYXQgbWVzc2FnZXMgYXJlICpmb3J3YXJkZWQqIGFuZCAqbm90KiByZWdlbmVyYXRlZCksIHRo
aXMgY291bGQgYmUgb25lIG9wdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwO28mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDtXaGVuIGEgUlJFUSwgUlJFUCBtZXNzYWdlIGlzIGdlbmVyYXRlZCwgYWRkIGFuIElD
ViBNZXNzYWdlIFRMViwgd2hpY2ggaXMgY2FsY3VsYXRlZCAmbHQ7dGhpcyB3YXkmZ3Q7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO+KApih0YWtlIGlu
c3BpcmF0aW9uIGZyb20gUkZDNzE4MyBoZXJlKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPi4uLjxicj4NCjxicj4NCltNZXNzYWdlIGNsaXBwZWRd
Jm5ic3A7Jm5ic3A7PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFu
ZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBo
cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9
Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1h
bmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg
aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqPGJyPg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz
IGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPg0KcmVjaXBpZW50IGFuZCBtYXkg
YWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNp
cGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNl
bmRlci48YnI+DQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBv
c2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPg0KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90
aGVyIHBlcnNvbi48YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv
dHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1h
bmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg
aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+
PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl
Zj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0K
PGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8
YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0Ij5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B15B0GLKXM0002VGREEN_--


From nobody Mon Apr 25 07:38:24 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 9A07312B066 for ; Mon, 25 Apr 2016 07:38:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.414
X-Spam-Level: 
X-Spam-Status: No, score=-1.414 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, TRACKER_ID=1.306] autolearn=no 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 8evg6r-WTwDD for ; Mon, 25 Apr 2016 07:38:14 -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 1A71712D534 for ; Mon, 25 Apr 2016 07:38:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C48451C0297; Mon, 25 Apr 2016 07:38:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461595093; bh=WELfQMMlqVaZust1SpUIhsAwxb/2vBE0elBA1X6np3c=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=pcj4VRjYZVPKXKHYtXpooNBPP7twDAHUkpTqWNUANiiJQoaJi4LqG954+Fr8NMDDb g4Isg2I5LsfS/ozZaCglzp1XlMoKd+iVDjOJJbnYeZPqY2wi44JPwFpjQziEjrwv30 ewJ5dPdJvkM20c0LEEfW6pSK1TwC6C2cQV6cZRrM=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [10.108.12.117] (unknown [37.161.24.118]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 574DF92087C; Mon, 25 Apr 2016 07:37:57 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-F906FF87-B060-47EA-9861-AC0E44371E23
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPhone Mail (13E238)
In-Reply-To: 
Date: Mon, 25 Apr 2016 16:37:53 +0200
Content-Transfer-Encoding: 7bit
Message-Id: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>          
To: Justin Dean 
Archived-At: 
Cc: Christopher Dearlove , Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 14:38:22 -0000

--Apple-Mail-F906FF87-B060-47EA-9861-AC0E44371E23
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> On 25 avr. 2016, at 16:32, Justin Dean  wrote:
>=20
>=20
>=20
>> On Mon, Apr 25, 2016 at 10:28 AM,  wrote:
>>=20
>>> On 25 Apr 2016, at 16:20, Justin Dean  wrote:
>>>=20
>>> A thought regarding integrity checking.  A possible future "fix" for int=
egrity could be done on a "virtual" packet in which known TLVs/values along w=
ith ordered addresses are uncompressed and then verified.  It could allow ex=
tra TLV tagging without modifying the validity of that data.  The very big d=
rawback would be the overhead of having to uncompressed everything to check t=
he validity.  It's functionally the same as zeroing out local (this is my st=
uff) TLV data vs remote (this is not my stuff) TLV data. =20
>>=20
>> That requires an imposed ordering of addresses, address TLVs, Message TLV=
s, etc., even if only =E2=80=9Cin memory=E2=80=9D, it is something that ever=
ybody should be aware of, and doing the same way
>>=20
>> 	o	That ordering would have to be specified in this document (=
no, it would not be a =E2=80=9Cfuture fix=E2=80=9D, this is=20
>> 		a requirement to the base spec, since *not* doing that woul=
d mean that this =E2=80=9Cfuture fix=E2=80=9D could render
>> 		current implementations non-compliant!)
>>=20
> If you're building the virutal packet you could specify the order there, t=
he on the wire packet doesn't need to be in that order.
> =20

No idea what a virtual packet is.=20

But imposing a point of universal agreement on how *any* packet - now or in t=
he future - uncompresses  is not a trivial task.=20

>> 	o	While this would be *hard* for the current messages/TLVs, I=
=E2=80=99d imagine that it=E2=80=99d make extensions
>> 		impossible (in an interoperable fashion).
>>=20
> Not at all if the integrity check in question only used well known registr=
ed TLVs (i.e. don't change the value of these!) types for building the virut=
al packet then you could add whatever other TLV info you wanted.

If I understand you correctly, then you would do the ICV only over some of t=
he packet content? In other words, any extensions would be unprotected, OR w=
ould require an update to whatever records the "known TLVs" list? =20

That to me is a showstopper, similar to M. Perkins' E2E draft, to be designi=
ng an extensible protocol specifically so that extensions are "unsecured". W=
e can and must. do better than that.=20

> =20
>> 	o	It=E2=80=99d be *exceptionally* heavy for all intermediate r=
outers, wanting to verify the integrity of a=20
>> 		message: to be able to force everybody in a network to =E2=80=
=9Cunwrap=E2=80=9D the message into an=20
>> 		uncompressed form *before* validating its origins is openin=
g up for DoS attacks.=20
>>=20
>> 		I want to do a *minimum* number of operations with a messag=
e, *before* deciding=20
>> 		to discard a message as harmful.
>>=20
> This is true enough it'd be hell on processing.=20

Indeed. There are many reasons why this is a bad idea.=20

Thomas.=20

>>=20
>>> As for the RREP-Ack having a flag vs an address doesn't much bother me a=
s either would have to be zeroed out for this type of future integrity check=
ing.
>>=20
>> This is not a question of future integrity checking, but a requirement fo=
r the base specification to be able to support.=20
>>=20
>> Thomas
>>=20
>>=20
>>> Justin
>>>=20
>>>> On Mon, Apr 25, 2016 at 9:27 AM, Dearlove, Christopher (UK)  wrote:
>>>> Assuming for the moment that everyone will need an RREP-Ack or won=E2=80=
=99t (let=E2=80=99s come back to that) why do C and B need to put an address=
 in as an RREQ-Ack request? Why not a flag, because the address will be incl=
uded as the IP sending address - and we know 5444 is required to pass that o=
n. (It=E2=80=99s used by NHDP as well.) Then we don=E2=80=99t need to change=
 the RREP, it will have a flag set or not, and won=E2=80=99t change (in this=
 regard).
>>>>=20
>>>> =20
>>>>=20
>>>> Now let=E2=80=99s consider do we know whether we can set a fixed flag. =
First I=E2=80=99d say there are two cases - you=E2=80=99ve got a firm contro=
l on what=E2=80=99s going on in your network, or it=E2=80=99s one of unknown=
 parties and behaviour (consistent with specification). In the former case y=
ou only want one setting, for example no-Ack if running NHDP or your MAC lay=
er tells you about bidirectionality, Ack otherwise. In the latter case, I th=
ink you just always want an Ack. So both cases get you to the same place.
>>>>=20
>>>> =20
>>>>=20
>>>> Should that not be an acceptable argument (though I think it=E2=80=99s g=
ood for where we are - in fact always Ack is close) then at flag is a step b=
etter, it=E2=80=99s a fixed location to change. However it would be better i=
n that case if the two things to change (metric and ack flag) were together.=
 But that has its own issues, so I won=E2=80=99t go there.
>>>>=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 Bad=
dow, 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: Victoria Mercieca [mailto:vmercieca0@gmail.com]=20
>>>> Sent: 25 April 2016 14:15
>>>> To: Jiazi YI
>>>> Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc Net=
works mailing list
>>>> Subject: Re: [manet] Message integrity and message mutability (was RE: d=
raft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> *** WARNING ***
>>>>=20
>>>> This message originates from outside our organisation, either from an e=
xternal partner or the internet.
>>>> Consider carefully whether you should click on any links, open any atta=
chments 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
>>>> Hi Jiazi,
>>>>=20
>>>>=20
>>>>=20
>>>> =20
>>>>=20
>>>> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI  wrote:
>>>>=20
>>>> Hi,=20
>>>>=20
>>>> =20
>>>>=20
>>>> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK)  wrote:
>>>>=20
>>>> With regard to your validity time point, we here have a tradeoff. If yo=
u allow that feature, it significantly impacts on the approach that was comi=
ng together on as best you can end to end encryption.
>>>>=20
>>>> =20
>>>>=20
>>>> So the question is, is this a feature that=E2=80=99s really wanted? Unf=
ortunately I think we know that the answer to that is, we don=E2=80=99t know=
 because we don=E2=80=99t have any experience. My view would be that in the t=
radeoff of an untested feature (unless I=E2=80=99m wrong about that) and the=
 security complication, security wins and drop the feature. If there is some=
 real requirement, then there=E2=80=99s a discussion. (Questions like how of=
ten the intermediate routers actually have any knowledge - typically links b=
reak for unexpected rather than expected reasons. Andan intermediate router c=
ould possibly use a validity time to influence its behaviour.) Note that dro=
pping the ability of intermediate routers to modify/set still allows validit=
y times per route to be set at endpoints.
>>>>=20
>>>> =20
>>>>=20
>>>> I agree with Chris' concern.
>>>>=20
>>>> The ValidityTime is optional, which makes the integrity protection hard=
. Furthermore, it gives a potential attack vector: as all the routers in a p=
ath will take the shortest validityTime, a compromised router can set the th=
e validityTime to a very short value, which will make the route installed al=
ong the path became invalid (very soon).=20
>>>>=20
>>>> =20
>>>>=20
>>>> On the other hand, I'm not sure this option will give us much help. Chr=
is mentioned much knowledge intermediate router would have to decide this va=
lue (and how much sense the value would make).=20
>>>>=20
>>>> Another issue is, a route to a destination might be updated by differen=
t sources. For example, in the network below:
>>>>=20
>>>> =20
>>>>=20
>>>> A----B-----C
>>>>=20
>>>> =20
>>>>=20
>>>> A first establish a route to B with long validity time. Then A initiate=
s a route discovery to C. C tends to set a short validity time, which will m=
ake the route between B and A expire earlier than expected.=20
>>>>=20
>>>> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered o=
r not.=20
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> Not sure I follow here.
>>>>=20
>>>> Currently, the validity time of the route between A and B would not aff=
ected by a short validity time of a route between A and C. Validity times ar=
e per-route, and the route A-B and the route A-C are separate.
>>>>=20
>>>> If we switched to a validity time per neighbor (so that we can keep val=
idity time separate from route advertisements) as I mentioned in the email b=
elow, then the validity of a route between A and C would be affected if ther=
e was a short validity time between A and B. But, if B will only route for a=
 certain amount of time, then the route between A and C will of course be af=
fected. Is it best to know in advance that there's a time limit, or just dea=
l with RERRs when they happen?
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> With regard to the acknowledgements, the problem (with regard to securi=
ty) comes from trying to do two jobs with the same message - end to end rout=
e advertisement and hop by hop acknowledgement. I understand the reasons - s=
aving bytes and message types. (I would have to study the protocol really ha=
rd to identify if any message types can be folded together and recognised by=
 content rather than type efficiently. This I do not expect to do.) Again a t=
radeoff. This one is in discussion space, though that needs people who under=
stand both sides of the issue, including the details of the bidirectionality=
 mechanism. Of course, as has been said, we need one of those.
>>>>=20
>>>> =20
>>>>=20
>>>> I haven't finished my review of the latest draft, and I don't get the n=
ecessity of AckReq and the corresponding multicast RREP yet.=20
>>>>=20
>>>> If possible, this "optional" field should be avoided.=20
>>>>=20
>>>> =20
>>>>=20
>>>>=20
>>>> To give an overview of AckReq and RREP:
>>>>=20
>>>> Since AODVv2 requires bidirectional links, this is the way to determine=
 if a link is bidirectional.
>>>>=20
>>>> A----B----C
>>>>=20
>>>>=20
>>>> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both insta=
ll a route to OrigAddr but they dont yet know if it's valid because they don=
t know if the link to their next hop is available in the reverse direction.
>>>>=20
>>>> 2) C creates the RREP. Since it doesnt know if the link to B is bidirec=
tional, it includes the AckReq (an address to indicate that it expects to re=
ceive a RREP_Ack from B).
>>>>=20
>>>> 3) B receives the RREP, installs a route to TargAddr and marks it as va=
lid, since it knows the link to C is bidirectional, because the RREQ went in=
 one direction and the RREP came in the other. B also sends the RREP_Ack to C=
 and forwards the RREP to A (and might change the message to indicate its ow=
n AckReq - ie that it requires an ack from A).
>>>>=20
>>>> 4) C receives the RREP_Ack from B, and therefore knows that B received t=
he RREP, therefore the link is bidirectional. C can then mark its route to O=
rigAddr as valid.
>>>>=20
>>>> 5) Similarly, A receives the RREP, installs the route to TargAddr and s=
ends an RREP_Ack to B.
>>>>=20
>>>> 6) B receives the RREP_Ack and marks its route to OrigAddr as valid.
>>>>=20
>>>> =20
>>>>=20
>>>> Alternatively, in step 2, if C knows the link to B is bidirectional (pe=
rhaps from some earlier route discovery), it doesnt need to put the AckReq i=
n the RREP. Then in step 3, since B doesnt know if the link to A is bidirect=
ional, it changes the message to add the AckReq address, in order to get an R=
REP_Ack from A.
>>>>=20
>>>> If we want to avoid changing the message, we'll need to look at forward=
ing the RREP as-is, and creating a second message to solicit an RREP_Ack, in=
 order to verify that the link is bidirectional before marking the route to O=
rigAddr as valid.
>>>>=20
>>>> Kind regards,
>>>>=20
>>>> Victoria.
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> regards
>>>>=20
>>>> =20
>>>>=20
>>>> Jiazi
>>>>=20
>>>> =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 Bad=
dow, 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: Victoria Mercieca [mailto:vmercieca0@gmail.com]=20
>>>> Sent: 23 April 2016 10:55
>>>> To: Christopher Dearlove
>>>> Cc: ietf@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc N=
etworks mailing list
>>>>=20
>>>>=20
>>>> Subject: Re: [manet] Message integrity and message mutability (was RE: d=
raft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> *** WARNING ***
>>>>=20
>>>> This message originates from outside our organisation, either from an e=
xternal partner or the internet.
>>>> Consider carefully whether you should click on any links, open any atta=
chments 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
>>>> Hi Chris,
>>>>=20
>>>> =20
>>>>=20
>>>> These have both been in the draft in some form since before I got invol=
ved... but I'll do my best to explain.
>>>>=20
>>>> =20
>>>>=20
>>>> - For Validity Time, its a way to advertise that you would only support=
 the route contained in the message for a certain period of time. The origin=
ator might use this, but the draft was written to allow any intermediate nod=
e to be able to add it or update it too. The route created in the Local Rout=
e Set has an expiration time associated with it, based on the received valid=
ity time.
>>>>=20
>>>> - For the AckReq address, its so that you can add into a RREP a request=
 for an acknowledgement, so that you don't have to have a different message t=
ype altogether for working out whether links to neighbors are bidirectional,=
 and also, since you only care about bidirectionality on routes that are bei=
ng set up, you dont need to constantly monitor all neighbors.
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> In order to avoid the potential AckReq-related changes to each message,=
 maybe we do need to introduce a different message specifically for this. We=
 could maybe use RREP_Ack to both request and acknowledge? It means an extra=
 message of control traffic that needs to be sent, maybe one extra message p=
er hop on the path of a RREP, but it could still be limited to neighbors whi=
ch have participated in the route discovery rather than monitoring all neigh=
bors at all times.=20
>>>>=20
>>>> =20
>>>>=20
>>>> This message could maybe also include "I'm happy to route anywhere for a=
 certain amount of time", sort of like willingness in OLSR/OLSRv2. So instea=
d of having a validity time per route, its a validity time per neighbor. The=
n, for RREQ and RREP, only the metric value would change in transit, as disc=
ussed. However, that leads to some issues with deciding what a route's expir=
ation time is. You might know how long the next hop router is valid for, but=
 what if a router beyond that, which was also part of the route, had a lower=
 validity time? You couldn't determine the real validity time. Do we remove t=
he route expiration time altogether to avoid this issue? In which case, we w=
ould have to rely on RERR messages being sent for routes which become invali=
d when the neighbor's validity time has expired? So neighbor validity time e=
xpiration is treated the same as a link break.
>>>>=20
>>>> =20
>>>>=20
>>>> What do you think?
>>>>=20
>>>> =20
>>>>=20
>>>> Kind regards,
>>>>=20
>>>> Victoria.
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove  wrote:
>>>>=20
>>>> Pretty much all of the discussion has been assuming only a metric value=
 change. With multiple things changing many of the ideas go out of the windo=
w. That reinforces the point about not making specifications now that might t=
urn out to be wrong for ICVs.
>>>>=20
>>>> =20
>>>>=20
>>>> Ignoring how this misunderstanding happened, I'll start by asking why. M=
etric changing I understand. Why the other two? (there's a partial explanati=
on of one). What alternatives have people implemented in comparable protocol=
s?
>>>>=20
>>>> -- =20
>>>>=20
>>>> Christopher Dearlove
>>>>=20
>>>> christopher.dearlove@gmail.com (iPhone)
>>>>=20
>>>> chris@mnemosyne.demon.co.uk (home)
>>>>=20
>>>>=20
>>>> On 23 Apr 2016, at 00:26, Victoria Mercieca  wrot=
e:
>>>>=20
>>>> Hi all,
>>>>=20
>>>> =20
>>>>=20
>>>> Continued in this thread because the other one seems to be more about T=
LV types and metric type numbers, whereas this is about regeneration/forward=
ing.
>>>>=20
>>>> =20
>>>>=20
>>>> To recap, in the current draft, there are 3 things that might change at=
 each hop:=20
>>>> - the metric value (happens in RREQ and RREP),=20
>>>> - adding/changing Validity Time using the Validity Time TLV (can happen=
 in RREQ and RREP),=20
>>>> - adding an address (and corresponding value in the AddressType TLV to i=
ndicate how to interpret the address) to indicate the address from which an R=
REP_Ack is expected, to accomplish the bidirectionality check (can happen in=
 RREP).
>>>>=20
>>>> If we define a certain portion of the message as immutable and include t=
he ICV to verify that part, end to end:=20
>>>> - The metric value would be excluded from the ICV since it needs changi=
ng at each hop.=20
>>>> - Would adding a Validity Time TLV at an intermediate hop be acceptable=
? The whole TLV could be removed in order to calculate the ICV?
>>>>=20
>>>> - Would adding an address cause issues for the ICV, because it's in the=
 address block? Could the rule be "if it contains an AckReq address, remove i=
t (and the corresponding value in the AddressType TLV), before checking the I=
CV", is that OK? Or would we need to avoid touching the ICV'ed part of the m=
essage altogether, maybe put the AckReq address in a separate Address Block,=
 with an extra AddressType TLV following that address block? Is there a way t=
o accomplish this?
>>>>=20
>>>> =20
>>>>=20
>>>> Also, to be thorough, do we need to consider RERR messages while we dis=
cuss regeneration vs forwarding?=20
>>>>=20
>>>> - RERR (sent when a link breaks) is a way of saying "I've lost my route=
 so I'm telling others" and "you were my next hop, so now I've also lost my r=
oute, I'll tell others", etc. It's going to be tailored at each step to incl=
ude the relevant routes that got deleted, it's not one message being sent en=
d-to-end like RREQ and RREP are.=20
>>>>=20
>>>> - However, RERR (sent when a source of traffic is sending data on a rou=
te which comes through you, and you want to tell the Packet Source's router t=
o delete the route) could be seen as an end-to-end message which all interme=
diate routers learn from, similar to RREQ and RREP. It reports one route, an=
d doesn't need changing at intermediate hops, so could be protected with ICV=
.
>>>>=20
>>>> - Would it be OK to only require a message ICV if a PktSource address w=
as included, i.e. when the message needs to go via a number of intermediate h=
ops to PktSource's router? All other RERRs are intended to be one-hop messag=
es, which may in turn prompt other one-hop messages, etc..., and a packet IC=
V might be more appropriate?
>>>>=20
>>>> =20
>>>>=20
>>>> Kind regards,
>>>>=20
>>>> Victoria.
>>>>=20
>>>> =20
>>>>=20
>>>> On Thu, Mar 17, 2016 at 5:26 PM,  wrote:
>>>>=20
>>>> =20
>>>>=20
>>>> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK)  wrote:
>>>>=20
>>>> =20
>>>>=20
>>>> Yes, I meant AODVv2, thanks for the catch.
>>>>=20
>>>> =20
>>>>=20
>>>> So is your (Thomas) proposed base specification a hop count only metric=
?
>>>>=20
>>>> =20
>>>>=20
>>>> No, the would be silly as base specification, given that hop count most=
ly is useless.
>>>>=20
>>>> =20
>>>>=20
>>>> As base specification I would simply say =E2=80=9CInclude a Metric Type=
 Message TLV with a value field, and a 7182 Message TLV & Timestamp=E2=80=9D=
 as we do in OLSRv2 (with the appropriate verbiage as to generation and proc=
essing).=20
>>>>=20
>>>> =20
>>>>=20
>>>> With the message generated by the originator of the RREQ/RREP and *not*=
 deconstructed/reconstructed/reordered (as is the risk with =E2=80=9Cregener=
ation) allows knowing that it would be *only* that metric field being modifi=
ed (other than hop count/limit) for when eventually writing up the extension=
.
>>>>=20
>>>> =20
>>>>=20
>>>> (Actually doesn=E2=80=99t the current specification only define hop cou=
nt, or has that changed in latest draft?)
>>>>=20
>>>> =20
>>>>=20
>>>> No. That is one of the issues I raise in my original. For some reason, i=
t cites RFC6551, which is a ROLL document and which has in its abstract that=
:
>>>>=20
>>>> =20
>>>>=20
>>>>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>>>>    compared with traditional wired and ad hoc networks that require the=

>>>>    specification of new routing metrics and constraints.=20
>>>> =20
>>>>=20
>>>> I.e. this document cites a metric document which clearly claims to be i=
napplicable in ad hoc networks. I note that this is another thing I=E2=80=99=
ve raised for years without seeing it attempted resolved.
>>>>=20
>>>> =20
>>>>=20
>>>> Best,
>>>>=20
>>>> =20
>>>>=20
>>>> Thomas
>>>>=20
>>>> =20
>>>>=20
>>>> =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 Bad=
dow, 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: ietf@thomasclausen.org [mailto:ietf@thomasclausen.org]=20
>>>> Sent: 17 March 2016 17:10
>>>> To: Dearlove, Christopher (UK)
>>>> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>>>> Subject: Re: [manet] Message integrity and message mutability (was RE: d=
raft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> *** WARNING ***
>>>>=20
>>>> This message originates from outside our organisation, either from an e=
xternal partner or the internet.
>>>> Consider carefully whether you should click on any links, open any atta=
chments 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
>>>> On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK)  wrote:
>>>>=20
>>>> =20
>>>>=20
>>>> OK, so we have a message that mutates by:
>>>>=20
>>>> - Modifying hop count/limit.
>>>>=20
>>>> - Modifying a metric value.
>>>>=20
>>>> Anything else?
>>>>=20
>>>> =20
>>>>=20
>>>> As mutating (other than hop count/limit) messages aren=E2=80=99t covere=
d by 5444 or any derivative document (but only recommended against, not bann=
ed) that you may need to make the message otherwise immutable (no deconstruc=
tion and rebuilding, other than guaranteed unchanging) that would have to be=
 specified by AODVv2. (Easy to say, but needs saying.)
>>>>=20
>>>> =20
>>>>=20
>>>> With you so far.
>>>>=20
>>>> =20
>>>>=20
>>>> Then that information is not in a guaranteed fixed location given by a s=
imple offset. So any signature algorithm that finds it and ignores it or agg=
regates on it is specific to OLSRv2.
>>>>=20
>>>> =20
>>>>=20
>>>> Surely you mean AODVv2
>>>>=20
>>>> =20
>>>>=20
>>>> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AODVv=
2 specialised variant. Which is the sort of thing that the message specific T=
LV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cbut ignore=
 the value of this specific TLV should it occur=E2=80=9D being in the genera=
l space. However it can easily be defined by reference to 7182 (=E2=80=9Cthi=
s TLV is like that TLV, except if an X TLV is present, set its value field t=
o zero=E2=80=9D).
>>>>=20
>>>> =20
>>>>=20
>>>> Messy, but could work.
>>>>=20
>>>> =20
>>>>=20
>>>> Not that messy, actually, although clearly not as nice as =E2=80=9Cfixe=
d offset=E2=80=9D.
>>>>=20
>>>> =20
>>>>=20
>>>> That said, I am arguing for the base spec being:
>>>>=20
>>>> =20
>>>>=20
>>>>             =E2=80=9Cmake the message otherwise immutable (no deconstru=
ction and rebuilding, other=20
>>>>=20
>>>>              than guaranteed unchanging)=E2=80=9D which is afforded by f=
orwarding
>>>>=20
>>>> =20
>>>>=20
>>>>                                     +
>>>>=20
>>>> =20
>>>>=20
>>>>             RFC7182 Timestamps and ICVs.
>>>>=20
>>>> =20
>>>>=20
>>>>                                     +
>>>>=20
>>>> =20
>>>>=20
>>>>             RFC7183 style text bringing it all together.
>>>>=20
>>>> =20
>>>>=20
>>>> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would v=
ery be an experimental extension.
>>>>=20
>>>> =20
>>>>=20
>>>> What I object to is, if the base spec specifically renders such extensi=
ons impossible
>>>>=20
>>>> =20
>>>>=20
>>>> =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 Bad=
dow, 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: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]=20
>>>> Sent: 17 March 2016 16:48
>>>> To: Dearlove, Christopher (UK)
>>>> Cc: ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
>>>> Subject: Re: [manet] Message integrity and message mutability (was RE: d=
raft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> *** WARNING ***
>>>>=20
>>>> This message originates from outside our organisation, either from an e=
xternal partner or the internet.
>>>> Consider carefully whether you should click on any links, open any atta=
chments 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
>>>> Hi all,
>>>>=20
>>>> =20
>>>>=20
>>>> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) :
>>>>=20
>>>> =20
>>>>=20
>>>> Good point about whether you just pass on one cost or a set of costs. A=
s I said, not looked at details - I will, when time permits. One cost is muc=
h easier, and yes, it reduces the fixed size aggregated signatures problem t=
o =E2=80=9Cjust=E2=80=9D one of computational load.
>>>>=20
>>>> =20
>>>>=20
>>>> For the record, Thomas=E2=80=99 understanding is correct; the cost is o=
ne aggregated value.=20
>>>>=20
>>>> =20
>>>>=20
>>>> Best regards,=20
>>>>=20
>>>> Lotte Steenrbink
>>>>=20
>>>> =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 Bad=
dow, 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: ietf@thomasclausen.org [mailto:ietf@thomasclausen.org]=20
>>>> Sent: 17 March 2016 16:38
>>>> To: Dearlove, Christopher (UK)
>>>> Cc: Mobile Ad Hoc Networks mailing list
>>>> Subject: Re: Message integrity and message mutability (was RE: [manet] d=
raft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> *** WARNING ***
>>>>=20
>>>> This message originates from outside our organisation, either from an e=
xternal partner or the internet.
>>>> Consider carefully whether you should click on any links, open any atta=
chments 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
>>>> On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK)  wrote:
>>>>=20
>>>> =20
>>>>=20
>>>> I appreciate Thomas=E2=80=99s comments about the limitations of message=
 regeneration, but I would be a bit less absolute.
>>>>=20
>>>> =20
>>>>=20
>>>> The issues over end to end authentication and more advanced signatures a=
re valid. I need to read the given reference on aggregate signatures to incr=
ease my knowledge (thanks for it), but my understanding of the possibilities=
 in this field may offer a solution to the problem, but with some other issu=
es (possibly including a new type of TLV).
>>>>=20
>>>> =20
>>>>=20
>>>> But the hop count/limit point I don=E2=80=99t fully agree with, you can=
 regenerate with an incremented/decremented count/limit, which leaves the ab=
ility to prevent messages propagating indefinitely, including expanding ring=
 searches, and retains the ability to use RFC 5497 interval and validity tim=
es that might be useful with an expanding ring search (or might not).
>>>>=20
>>>> =20
>>>>=20
>>>> But the key issue is that AODVv2 wants to accumulate metrics. I still h=
aven=E2=80=99t got to the bottom of many details here, but let=E2=80=99s for=
 the moment just consider that conceptually.
>>>>=20
>>>> =20
>>>>=20
>>>> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft attempt=
s to do an end to end of some information, not this information. I=E2=80=99m=
 not sure if that=E2=80=99s useful (and the specialised format is better avo=
ided if possible). Other approaches are hop by hop (might as well use packet=
 signatures) and shared key (might as well go hop by hop). Pairwise signatur=
es for each pair of routers I=E2=80=99m discounting as scaling terribly. In t=
he interests of completeness let=E2=80=99s mention not accumulating metrics,=
 which puts us back to hop count and that=E2=80=99s not ideal either.
>>>>=20
>>>> =20
>>>>=20
>>>> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=80=
=99ve seen about aggregating, but that has some issues of its own, even apar=
t from computational load.) I=E2=80=99d love to be proved wrong - someone wi=
th the perfect solution to come along.
>>>>=20
>>>> =20
>>>>=20
>>>> Which means that either we make an arbitrary choice - which will be dis=
agreed with, but needs discussing first - or create something flexible. Unfo=
rtunately flexible in that regard constrains in others, e.g. some (many? mos=
t?) aggregating signatures need fixed data sizes (which we can do by definin=
g a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but that has a cost t=
oo).
>>>>=20
>>>> =20
>>>>=20
>>>> I have been told by people much more well versed in this than I in cryp=
tology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>>>>=20
>>>> =20
>>>>=20
>>>> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does t=
hat mean that the message grows as it is being forwarded, and that the recip=
ient of a RREQ/RREP will know the individual costs of each path segment? My u=
nderstanding is, that the recipient will get =E2=80=9Cthe sum the costs of e=
ach path segment=E2=80=9D which should be fitting within a fixed size?
>>>>=20
>>>> =20
>>>>=20
>>>> Thomas
>>>>=20
>>>> =20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> =20
>>>>=20
>>>> Sorry, no answers, just comments. And I=E2=80=99m not addressing Thomas=
=E2=80=99s later points here.
>>>>=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 Bad=
dow, 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 ietf@thomascla=
usen.org
>>>> Sent: 17 March 2016 16:00
>>>> To: Mobile Ad Hoc Networks mailing list
>>>> Subject: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ti=
cket Items
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> *** WARNING ***
>>>>=20
>>>> This message originates from outside our organisation, either from an e=
xternal partner or the internet.
>>>> Consider carefully whether you should click on any links, open any atta=
chments 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
>>>> Dear all,
>>>>=20
>>>> =20
>>>>=20
>>>> Apologies for not having gotten this done sooner - day-job leaving few s=
pare cycles.
>>>>=20
>>>> =20
>>>>=20
>>>> I=E2=80=99ve previously offered reviews and comments, and some of those=
 have been addressed in the latest I-D =E2=80=94 others have not, but should=
 be. I recall that there was some mail attempting to rebut parts of the revi=
ew, and I will dig it out and reply to that.
>>>>=20
>>>> =20
>>>>=20
>>>> With that being said, I have reviewed the latest version of the documen=
t, and full details will be forthcoming. There=E2=80=99re a couple of big-ti=
cket/architectural items that I want to address up front, as I believe that b=
efore we have those hammered out, it will be useless to go into details. Not=
e, I do not claim that this is an exhaustive list of =E2=80=9Cbig ticket ite=
ms=E2=80=9D, but that=E2=80=99s as far as I have gotten in thinking this thr=
ough.
>>>>=20
>>>> =20
>>>>=20
>>>> I also bring these up as they are items that have been brought up repea=
tedly over the past years, but not resolved nor discussed.
>>>>=20
>>>> =20
>>>>=20
>>>> Loops
>>>>=20
>>>> Just to bring this out: I share Chris=E2=80=99 worry about conflicting a=
nd concurrent statements from the authors on =E2=80=9CThere are no loops pos=
sible=E2=80=9D and =E2=80=9CWe need to fix two situations where loops can oc=
cur=E2=80=9D and =E2=80=9Cwe are still investigating some loop conditions=E2=
=80=9D
>>>>=20
>>>> =20
>>>>=20
>>>> I particularly worry that this is not a discussion had in public, but a=
pparently in some other forum=E2=80=A6
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> Intermediate Route Replies, and all of section 10
>>>>=20
>>>> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=80=
=9D, which is incoherent with the intended status indicated for this documen=
t.=20
>>>>=20
>>>> =20
>>>>=20
>>>> Specifically, and this is not unrelated to the point about loops above,=
 intermediate RREPs (section 10.3) are a potential source for loops.
>>>>=20
>>>> =20
>>>>=20
>>>> Expanding Ring Multicast (section 10.1) is not documented in a way that=
 can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=E2=80=
=9D below, it is in the present form of this protocol impossible), etc.
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>> Forwarding-vs-regeneration
>>>>=20
>>>> Recent exchanges on the list made me understand that protocol control m=
essages are *not* forwarded, but are consumed at each hop, then a new messag=
e with (almost-but-not-quite) the same content is generated and transmitted.=

>>>>=20
>>>> =20
>>>>=20
>>>> I have thought some more on this (& read some of the exchanges on the l=
ist on this topic by Chris, Ulrich, and others), and I am convinced that thi=
s is not the right way to go, at least for the following reasons:
>>>>=20
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>>             o          It renders the hop-limit/hop-count fields in the=
 RFC5444 message header useless.
>>>>=20
>>>>                         This would not be bad if the functionality offe=
red by those fields was not useful
>>>>=20
>>>>                         =E2=80=94 sadly, it is. For example, for scope l=
imited flooding (expanding ring search, and=20
>>>>=20
>>>>                         such) which may be of interest, and which requi=
re hop-limit.=20
>>>>=20
>>>>                         A hop-count field may also provide a =E2=80=9Cc=
heap=E2=80=9D (in terms of overhead) additional piece
>>>>=20
>>>>                         of information to use conjunctively with a =E2=80=
=9Creal=E2=80=9D metric.
>>>>=20
>>>> =20
>>>>=20
>>>>                         The only practical solution would be to re-intr=
oduce these functions by way of inserting a
>>>>=20
>>>>                         MessageTLV =E2=80=94 which (i) is not specified=
 in this document, and (ii) which would just
>>>>=20
>>>>                         serve to render messages bigger than strictly n=
eeded.
>>>>=20
>>>> =20
>>>>=20
>>>>                         Scope limited flooding  does seem to be a neces=
sary requirement, if for no
>>>>=20
>>>>                         other reason than to prevent information from =E2=
=80=9Ccirculating forever in the network=E2=80=9D.
>>>>=20
>>>> =20
>>>>=20
>>>>             o          It makes end-to-end authentication unnecessarily=
 hard.
>>>>=20
>>>>                         I think Chris called this out already, but it b=
ears repeating: S generates a message=20
>>>>=20
>>>>                         (say, a RREQ), and includes an ICV calculated o=
ver the content of the message.
>>>>=20
>>>>                         For any recipient to be able to validate the IC=
V, the message has to be exactly
>>>>=20
>>>>                         the same =E2=80=94 not just in content, but in s=
tructure =E2=80=94 as what was generated.
>>>>=20
>>>> =20
>>>>=20
>>>>                         =E2=80=9CRegenerating=E2=80=9D rather than =E2=80=
=9Cforwarding=E2=80=9D messages means, that the intermediate
>>>>=20
>>>>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ m=
ay chose a different structure (e.g., include TLVs
>>>>=20
>>>>                         in a different order).
>>>>=20
>>>> =20
>>>>=20
>>>>                         The proposal from https://tools.ietf.org/html/d=
raft-perkins-manet-aodv-e2esec-00
>>>>=20
>>>>                         is to add constraints on (i) the set of element=
s to include in a signature and (ii) the
>>>>=20
>>>>                         order of these elements.
>>>>=20
>>>> =20
>>>>=20
>>>>                         One problem with that approach is (i): if an ex=
tension adds a message TLV, or an=20
>>>>=20
>>>>                         Address TLV, to a message, then that will not b=
e =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>>>>=20
>>>>                         Rather for *each* extension developed, an =E2=80=
=9Cupdates e2esec=E2=80=9D clause needs to be done.
>>>>=20
>>>> =20
>>>>=20
>>>>                         I=E2=80=99d say that this approach would be pro=
ne to errors =E2=80=94 and add entropy to the process
>>>>=20
>>>>                         of designing protocol extensions. The alternati=
ve, a message being generated by the
>>>>=20
>>>>                         source and *forwarded* (as we do in OLSRv2, for=
 example) would allow ICV TLVs=20
>>>>=20
>>>>                         (even, allow reuse of those specified for OLSRv=
2) for covering a message and=20
>>>>=20
>>>>                         extensions.
>>>>=20
>>>> =20
>>>>=20
>>>>                         =E2=80=9CBut what about the metrics value which=
 will change on each hop=E2=80=9D, you may say?
>>>>=20
>>>>                         Fortunately, that is relatively easy to handle:=
 simply zero out the value of that TLV when
>>>>=20
>>>>                         generating or verifying the ICV MessageTLV. And=
 use Packet-TLVs for hop-by-hop=20
>>>>=20
>>>>                         authentication, if needed (but, see below).
>>>>=20
>>>> =20
>>>>=20
>>>>             o          It prevents the use of more clever/advanced sign=
ature schemes/ICVs
>>>>=20
>>>>                         Aggregate signature algorithms ( https://crypto=
.stanford.edu/~dabo/papers/aggsurvey.pdf)
>>>>=20
>>>>                         exist, and an interesting use-case can be found=
 in also reactive protocols, allowing verifying
>>>>=20
>>>>                         not =E2=80=9Cjust=E2=80=9D the end points, but a=
lso the intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D=

>>>>=20
>>>>                         discussed above, or something smarter).
>>>>=20
>>>>                         Regeneration of messages, rather than forwardin=
g, renders that impossible (or, if used,
>>>>=20
>>>>                         updating to  https://tools.ietf.org/html/draft-=
perkins-manet-aodv-e2esec-00)
>>>>=20
>>>> =20
>>>>=20
>>>> There are other reasons, but the above are those that jump at me as imm=
ediate show-stoppers.
>>>>=20
>>>> =20
>>>>=20
>>>> I do honestly not see what possible benefit there is from =E2=80=9Crege=
neration=E2=80=9D =E2=80=94 but I see very clear inconveniences, and securit=
y is not the least of these. Insisting on =E2=80=9Cregeneration=E2=80=9D req=
uires development of =E2=80=9Cnon-general workarounds=E2=80=9D as pointed ou=
t above.
>>>>=20
>>>> =20
>>>>=20
>>>> Security Considerations
>>>>=20
>>>> This is an always thorny subject. When OLSRv2 was going through the pro=
cess we got a thorough education in how little we knew about security from t=
he SEC-ADs, and had to spend about a year or so developing RFC7183. The bott=
om line is, that this protocol needs its =E2=80=9CRFC7183  equivalent=E2=80=9D=
, either as part of the main document, or as an independent document. curren=
tly, that is not the case.
>>>>=20
>>>> =20
>>>>=20
>>>> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration from=
 RFC7183 might be aw good idea, as that was the most recent that went throug=
h the SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to implement=E2=
=80=9D security mechanism most be specified (I think the right term was =E2=80=
=9CMUST implement, SHOULD use=E2=80=9D), in sufficient detail to ensure inte=
roperable implementations.
>>>>=20
>>>> =20
>>>>=20
>>>> As an example, both [RFC6130] and [RFC7181] set out that that:
>>>>=20
>>>> =20
>>>>=20
>>>>       On receiving a ... message, a router MUST first check if the
>>>>=20
>>>>       message is invalid for processing by this router
>>>>=20
>>>> =20
>>>>=20
>>>> and then proceed to give a number of conditions that, each, will lead t=
o a rejection of the message as "badly formed and therefore invalid for proc=
essing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That gave a =E2=
=80=9Chook=E2=80=9D for RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. I=
dem for message generation.
>>>>=20
>>>> =20
>>>>=20
>>>> If I was to do RFC7181/RFC6130 today, I would include that directly int=
o the protocol specifications. It turned out to be more overhead (and slow d=
own publication anyways) to do it as separate documents.
>>>>=20
>>>> =20
>>>>=20
>>>> Secondly, we need to be a lot more rigid in terms of what ICVs, Timesta=
mps, etc. are added/removed, and what that brings.
>>>>=20
>>>> =20
>>>>=20
>>>> For example (with the assumption that messages are *forwarded* and *not=
* regenerated), this could be one option:
>>>>=20
>>>> =20
>>>>=20
>>>>                         o          When a RREQ, RREP message is generat=
ed, add an ICV Message TLV, which is calculated 
>>>>=20
>>>>                                      =E2=80=A6(take inspiration from RFC=
7183 here)
>>>>=20
>>>> =20
>>>>=20
>>>> ...
>>>>=20
>>>> [Message clipped] =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
>>>>=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
>>>>=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
>=20

--Apple-Mail-F906FF87-B060-47EA-9861-AC0E44371E23
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable




On 25 avr. 2016, at=
 16:32, Justin Dean <bebemaster@g=
mail.com> wrote:



On Mo=
n, Apr 25, 2016 at 10:28 AM,  <ietf@thomasclausen.org> wr=
ote:
On 25 Apr 2016, at 16:20, Justin Dean &=
lt;bebemaster@gmai=
l.com> wrote:

A thought regarding inte=
grity checking.  A possible future "fix" for integrity could be done on=
 a "virtual" packet in which known TLVs/values along with ordered addresses a=
re uncompressed and then verified.  It could allow extra TLV tagging wi=
thout modifying the validity of that data.  The very big drawback would=
 be the overhead of having to uncompressed everything to check the validity.=
  It's functionally the same as zeroing out local (this is my stuff) TL=
V data vs remote (this is not my stuff) TLV data.  

That requires an imposed ordering of addresses, addr=
ess TLVs, Message TLVs, etc., even if only =E2=80=9Cin memory=E2=80=9D, it i=
s something that everybody should be aware of, and doing the same way
<=
div>
	o	That ordering would have to b=
e specified in this document (no, it would not be a =E2=80=9Cfuture fix=E2=80=
=9D, this is 
	=
	a requirement to the base spec, since *not* doing that would mean th=
at this =E2=80=9Cfuture fix=E2=80=9D could render
		current implementations non-complian=
t!)

If you're building the virut=
al packet you could specify the order there, the on the wire packet doesn't n=
eed to be in that order.
 

No idea what a virtual packet is. 

But imposing a point of universal agreement on how *any* packet - now o=
r in the future - uncompresses  is not a trivial task. 
=

=
	o	While this would be *=
hard* for the current messages/TLVs, I=E2=80=99d imagine that it=E2=80=99d m=
ake extensions
		impossible (in an interoperable fashion).

Not at all if the integrity check in question only used well k=
nown registred TLVs (i.e. don't change the value of these!) types for buildi=
ng the virutal packet then you could add whatever other TLV info you wanted.=


If I understand yo=
u correctly, then you would do the ICV only over some of the packet content?=
 In other words, any extensions would be unprotected, OR would require an up=
date to whatever records the "known TLVs" list?  

<=
div>That to me is a showstopper, similar to M. Perkins' E2E draft, to be des=
igning an extensible protocol specifically so that extensions are "unsecured=
". We can and must. do better than that. 

 
	o	It=E2=80=99d be *exc=
eptionally* heavy for all intermediate routers, wanting to verify the integr=
ity of a 
		message: to be able to force everybody in a network to =E2=80=9Cunwrap=E2=
=80=9D the message into an 
		uncompressed form *before* validating its origins is=
 opening up for DoS attacks. 

		I want to do a *minimum* number of o=
perations with a message, *before* deciding 
		to discard a message as harmful.

This is true enough it'd be hell on=
 processing. 

=
Indeed. There are many reasons why this is a bad idea. 

<=
/div>
Thomas. 


As for the RREP-Ack having a fl=
ag vs an address doesn't much bother me as either would have to be zeroed ou=
t for this type of future integrity checking.

This is not a question of future integrity checking, but a requ=
irement for the base specification to be able to support. 
Thomas


<=
div>
Justin

On Mon, Apr 25, 2016 at 9:27 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:









Assuming for the momen=
t that everyone will need an RREP-Ack or won=E2=80=99t (let=E2=80=99s come b=
ack to that) why do C and B need to put an address in as an RREQ-Ack request=
?
 Why not a flag, because the address will be included as the IP sending addr=
ess - and we know 5444 is required to pass that on. (It=E2=80=99s used by NH=
DP as well.) Then we don=E2=80=99t need to change the RREP, it will have a f=
lag set or not, and won=E2=80=99t change (in this regard).
 =

Now let=E2=80=99=
s consider do we know whether we can set a fixed flag. First I=E2=80=99d say=
 there are two cases - you=E2=80=99ve got a firm control on what=E2=80=99s g=
oing on in your network,
 or it=E2=80=99s one of unknown parties and behaviour (consistent with speci=
fication). In the former case you only want one setting, for example no-Ack i=
f running NHDP or your MAC layer tells you about bidirectionality, Ack other=
wise. In the latter case, I think you
 just always want an Ack. So both cases get you to the same place.=

 =
;
Should t=
hat not be an acceptable argument (though I think it=E2=80=99s good for wher=
e we are - in fact always Ack is close) then at flag is a step better, it=E2=
=80=99s a fixed
 location to change. However it would be better in that case if the two thin=
gs to change (metric and ack flag) were together. But that has its own issue=
s, so I won=E2=80=99t go there.
 
--

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 Intelligence Lim=
ited

Registered in England & Wales No: 01337451
Regi=
stered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
 
From: Victoria Mercieca [mailto:vmercieca0@gmail.com]


Sent: 25 April 2016 14:15

To: Jiazi YI

Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc N=
etworks mailing list

Subject: Re: [manet] Message integrity and message mutability (was RE=
: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
 


 


*** WARNING ***





This message originates from outside our organis=
ation, either from an external partner or the internet.

Con=
sider carefully whether you should click on any links, open any attachments o=
r reply.

For=
 information 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.






Hi Jiazi,








 


On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <ietf@jiaziyi.com>=
 wrote:


Hi, 


 


On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Chri=
stopher (UK) <chris.dearlove@baesystems.com> wrote:




With regard to your va=
lidity time point, we here have a tradeoff. If you allow that feature, it si=
gnificantly
 impacts on the approach that was coming together on as best you can end to e=
nd encryption.
 
So the question is, is this a feature that=E2=80=99s really w=
anted? Unfortunately I think we know that the
 answer to that is, we don=E2=80=99t know because we don=E2=80=99t have any e=
xperience. My view would be that in the tradeoff of an untested feature (unl=
ess I=E2=80=99m wrong about that) and the security complication, security wi=
ns and drop the feature. If there is some real requirement,
 then there=E2=80=99s a discussion. (Questions like how often the intermedia=
te routers actually have any knowledge - typically links break for unexpecte=
d rather than expected reasons. Andan intermediate router could possibly use=
 a validity time to influence its behaviour.)
 Note that dropping the ability of intermediate routers to modify/set still a=
llows validity times per route to be set at endpoints.<=
/p>





 




I agree with Chris' concern.




The ValidityTime is optional, which makes the in=
tegrity protection hard. Furthermore, it gives a potential attack vector: as=
 all the routers in a path will take the shortest validityTime, a compromise=
d router can set the the validityTime
 to a very short value, which will make the route installed along the path b=
ecame invalid (very soon). 




 




On the other hand, I'm not sure this option will=
 give us much help. Chris mentioned much knowledge intermediate router would=
 have to decide this value (and how much sense the value would make). <=
u>




Another issue is, a route to a destination might=
 be updated by different sources. For example, in the network below:<=
u>




 




A----B-----C




 




A first establish a route to B with long validit=
y time. Then A initiates a route discovery to C. C tends to set a short vali=
dity time, which will make the route between B and A expire earlier than exp=
ected. 




Is this a problem? Maybe yes, maybe no -- I'm no=
t sure it's considered or not. 




 










 




Not sure I follow=
 here.




Currently, the va=
lidity time of the route between A and B would not affected by a short valid=
ity time of a route between A and C. Validity times are per-route, and the r=
oute A-B and the route A-C are separate.




If we switched to a validity time per neighbor (=
so that we can keep validity time separate from route advertisements) as I m=
entioned in the email below, then the validity of a route between A and C wo=
uld be affected if there was a short
 validity time between A and B. But, if B will only route for a certain amou=
nt of time, then the route between A and C will of course be affected. Is it=
 best to know in advance that there's a time limit, or just deal with RERRs w=
hen they happen?




 <=
/u>




 
















 
With regard to the=
 acknowledgements, the problem (with regard to security) comes from trying t=
o do
 two jobs with the same message - end to end route advertisement and hop by h=
op acknowledgement. I understand the reasons - saving bytes and message type=
s. (I would have to study the protocol really hard to identify if any messag=
e types can be folded together
 and recognised by content rather than type efficiently. This I do not expec=
t to do.) Again a tradeoff. This one is in discussion space, though that nee=
ds people who understand both sides of the issue, including the details of t=
he bidirectionality mechanism.
 Of course, as has been said, we need one of those.
=








 




I haven't finished my review of the latest draft=
, and I don't get the necessity of AckReq and the corresponding multicast RR=
EP yet. 




If possible, this "optional" field should be avo=
ided. 




 














To give an overview of AckReq and RREP:




Since AODVv2 requ=
ires bidirectional links, this is the way to determine if a link is bidirect=
ional.




A----B----C






1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install a r=
oute to OrigAddr but they dont yet know if it's valid because they dont know=
 if the link to their next hop is available in the reverse direction.=





2) C creates the RREP. Since it doesnt know if t=
he link to B is bidirectional, it includes the AckReq (an address to indicat=
e that it expects to receive a RREP_Ack from B).




3) B receives the RREP, installs a route to Targ=
Addr and marks it as valid, since it knows the link to C is bidirectional, b=
ecause the RREQ went in one direction and the RREP came in the other. B also=
 sends the RREP_Ack to C and forwards
 the RREP to A (and might change the message to indicate its own AckReq - ie=
 that it requires an ack from A).




4) C receives the RREP_Ack from B, and therefore=
 knows that B received the RREP, therefore the link is bidirectional. C can t=
hen mark its route to OrigAddr as valid.




5) Similarly, A receives the RREP, installs the r=
oute to TargAddr and sends an RREP_Ack to B.




6) B receives the RREP_Ack and marks its route t=
o OrigAddr as valid.




 




Alternatively, in=
 step 2, if C knows the link to B is bidirectional (perhaps from some earlie=
r route discovery), it doesnt need to put the AckReq in the RREP. Then in st=
ep 3, since B doesnt know if the link
 to A is bidirectional, it changes the message to add the AckReq address, in=
 order to get an RREP_Ack from A.




If we want to avo=
id changing the message, we'll need to look at forwarding the RREP as-is, an=
d creating a second message to solicit an RREP_Ack, in order to verify that t=
he link is bidirectional before marking
 the route to OrigAddr as valid. 




Kind regards,




Victoria.




 <=
/u>




 












regards




 




Jiazi




 








 
--

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 Intelligence Lim=
ited

Registered in England & Wales No: 01337451
Regi=
stered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
 
From: Victoria
 Mercieca [mailto:=
vmercieca0@gmail.com]


Sent: 23 April 2016 10:55

To: Christopher Dearlove

Cc: ietf@=
thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc Networks ma=
iling list






Subject: Re: [manet] Message integrity and message mutability (was RE=
: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)








 



 
=



*** 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.






Hi Chris,


 




These have both been in the draft in some form s=
ince before I got involved... but I'll do my best to explain.<=
/p>

 




- For Validity Time, its a way to advertise that=
 you would only support the route contained in the message for a certain per=
iod of time. The originator might use this, but the draft
 was written to allow any intermediate node to be able to add it or update i=
t too. The route created in the Local Route Set has an expiration time assoc=
iated with it, based on the received validity time.




- For the AckReq address, its so that you can ad=
d into a RREP a request for an acknowledgement, so that you don't have to ha=
ve a different message type altogether for working out
 whether links to neighbors are bidirectional, and also, since you only care=
 about bidirectionality on routes that are being set up, you dont need to co=
nstantly monitor all neighbors.




 




 




In order to avoid the potential AckReq-related c=
hanges to each message, maybe we do need to introduce a different message sp=
ecifically for this. We could maybe use RREP_Ack to both
 request and acknowledge? It means an extra message of control traffic that n=
eeds to be sent, maybe one extra message per hop on the path of a RREP, but i=
t could still be limited to neighbors which have participated in the route d=
iscovery rather than monitoring
 all neighbors at all times. 




 




This message could maybe also include "I'm happy=
 to route anywhere for a certain amount of time", sort of like willingness i=
n OLSR/OLSRv2. So instead of having a validity time per
 route, its a validity time per neighbor. Then, for RREQ and RREP, only the m=
etric value would change in transit, as discussed. However, that leads to so=
me issues with deciding what a route's expiration time is. You might know ho=
w long the next hop router is
 valid for, but what if a router beyond that, which was also part of the rou=
te, had a lower validity time? You couldn't determine the real validity time=
. Do we remove the route expiration time altogether to avoid this issue? In w=
hich case, we would have to
 rely on RERR messages being sent for routes which become invalid when the n=
eighbor's validity time has expired? So neighbor validity time expiration is=
 treated the same as a link break.




 




What do you think?




 




Kind regards,




Victoria.




 




 




 




 




 






 


On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dea=
rlove <c=
hris@mnemosyne.demon.co.uk> wrote:




Pretty much all of the discussion has been assum=
ing only a metric value change. With multiple things changing many of the id=
eas go out of the window. That reinforces the point about
 not making specifications now that might turn out to be wrong for ICVs.<=
/u>




 




Ignoring how this misunderstanding happened, I'l=
l start by asking why. Metric changing I understand. Why the other two? (the=
re's a partial explanation of one). What alternatives
 have people implemented in comparable protocols?



--  


Christopher Dearlove










On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmail.com> wrote:<=
/u>














Hi all,




 




Continued in this thread because the other one s=
eems to be more about TLV types and metric type numbers, whereas this is abo=
ut regeneration/forwarding.




 




To recap, in the current draft, there are 3 thin=
gs that might change at each hop:


- the metric value (happens in RREQ and RREP), 

- adding/changing Validity Time using the Validity Time TLV (can happen in R=
REQ and RREP),


- adding an address (and corresponding value in the AddressType TLV to indic=
ate how to interpret the address) to indicate the address from which an RREP=
_Ack is expected, to accomplish the bidirectionality check (can happen in RR=
EP).



If we define a certain portion of the message as immutable and include t=
he ICV to verify that part, end to end:


- The metric value would be excluded from the ICV since it needs changing at=
 each hop. 

- Would adding a Validity Time TLV at an intermediate hop be acceptable? The=
 whole TLV could be removed in order to calculate the ICV?
=


- Would adding an address cause issues for the I=
CV, because it's in the address block? Could the rule be "if it contains an A=
ckReq address, remove it (and the corresponding value
 in the AddressType TLV), before checking the ICV", is that OK? Or would we n=
eed to avoid touching the ICV'ed part of the message altogether, maybe put t=
he AckReq address in a separate Address Block, with an extra AddressType TLV=
 following that address block?
 Is there a way to accomplish this?




 




Also, to be thorough, do we need to consider RER=
R messages while we discuss regeneration vs forwarding? <=
/p>



- RERR (sent when a link breaks) is a way of say=
ing "I've lost my route so I'm telling others" and "you were my next hop, so=
 now I've also lost my route, I'll tell others", etc.
 It's going to be tailored at each step to include the relevant routes that g=
ot deleted, it's not one message being sent end-to-end like RREQ and RREP ar=
e. 




- However, RERR (sent when a source of traffic i=
s sending data on a route which comes through you, and you want to tell the P=
acket Source's router to delete the route) could be
 seen as an end-to-end message which all intermediate routers learn from, si=
milar to RREQ and RREP. It reports one route, and doesn't need changing at i=
ntermediate hops, so could be protected with ICV.




- Would it be OK to only require a message ICV i=
f a PktSource address was included, i.e. when the message needs to go via a n=
umber of intermediate hops to PktSource's router? All
 other RERRs are intended to be one-hop messages, which may in turn prompt o=
ther one-hop messages, etc..., and a packet ICV might be more appropriate?




 


Kind regards,


Victoria.




 


On Thu, Mar 17, 2016 at 5:26 PM, <ietf@thomasclausen.org&=
gt; wrote:


 






On 17 Mar 2016, at 18:17, Dearlove, Christopher (=
UK) <c=
hris.dearlove@baesystems.com> wrote:


 






Yes, I meant AODVv2, t=
hanks for the catch.




 




So is your (Thomas) pr=
oposed base specification a hop count only metric?










 


No, the would be silly as base specification, g=
iven that hop count mostly is useless.




 




As base specification I would simply say =E2=80=9C=
Include a Metric Type Message TLV with a value field, and a 7182 Message TLV=
 & Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage
 as to generation and processing). 




 




With the message generated by the originator of t=
he RREQ/RREP and *not* deconstructed/reconstructed/reordered (as is the risk=
 with =E2=80=9Cregeneration) allows knowing that it would be
 *only* that metric field being modified (other than hop count/limit) for wh=
en eventually writing up the extension.




 










(Actually doesn=E2=80=99=
t the current specification only define hop count, or has that changed in la=
test
 draft?)








 


No. That is one of the issues I raise in my ori=
ginal. For some reason, it cites RFC6551, which is a ROLL document and which=
 has in its abstract that:




 






   Low-Power and Lossy Networks (LLNs) have unique characteri=
stics


   compared with traditional wired and ad hoc networks that r=
equire the


   specification of new routing metrics and constraints. <=
/u>


 




I.e. this document cites a metric document which=
 clearly claims to be inapplicable in ad hoc networks. I note that this is a=
nother thing I=E2=80=99ve raised for years without seeing it
 attempted resolved.




 




Best,




 




Thomas




 




 








 




--
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 Intel=
ligence Limited

Registered in England & Wales No: 01337451


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




 








From: ietf@thomasclausen.org&=
nbsp;[mailto:ietf@thomasclausen.org] 

Sent: 17 March 2016 17:10

To: Dearlove, Christopher (UK)

Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list

Subject: Re: [manet] Message integrity and message mutability (w=
as RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)








 





 <=
/span>



*** 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 Flag=
s that you can look out for i=
n emails
 you receive, click here.

If you feel the email is suspicious, please follow this process.






 










On 17 Mar 2016, at 18:04, Dearlove, Christopher (=
UK) <<=
span style=3D"color:purple">chris.dearlove@baesystems.com>
 wrote:






 








OK, so we have a messa=
ge that mutates by:








- Modifying hop count/=
limit.








- Modifying a metric v=
alue.








Anything else?<=
u>








 








As mutating (other tha=
n hop count/limit) messages aren=E2=80=99t covered by 5444 or any derivative=
 document
 (but only recommended against, not banned) that you may need to make the me=
ssage otherwise immutable (no deconstruction and rebuilding, other than guar=
anteed unchanging) that would have to be specified by AODVv2. (Easy to say, b=
ut needs saying.)












 






With you so far.








 <=
/u>






Then that information i=
s not in a guaranteed fixed location given by a simple offset. So any signat=
ure
 algorithm that finds it and ignores it or aggregates on it is specific to O=
LSRv2.








 






Surely you mean AODVv2








 <=
/u>






So standard 7182 ICVs d=
on=E2=80=99t do the job, you would need an AODVv2 specialised variant. Which=
 is the
 sort of thing that the message specific TLV space is there for, I=E2=80=99d=
 be strongly against a =E2=80=9Cbut ignore the value of this specific TLV sh=
ould it occur=E2=80=9D being in the general space. However it can easily be d=
efined by reference to 7182 (=E2=80=9Cthis TLV is like that
 TLV, except if an X TLV is present, set its value field to zero=E2=80=9D).<=
/span>








 








Messy, but could work.=









 






Not that messy, actually, although clearly not a=
s nice as =E2=80=9Cfixed offset=E2=80=9D.








 








That said, I am arguing for the base spec being:=









 








        =
    =E2=80=9Cmake the message otherwise immutable (no de=
construction and rebuilding, other 








        =
     than guaranteed unchanging)=E2=80=9D which is a=
fforded by forwarding








 








        =
            &nbs=
p;            &n=
bsp;  +








 








        =
    RFC7182 Timestamps and ICVs.








 








        =
            &nbs=
p;            &n=
bsp;  +








 








        =
    RFC7183 style text bringing it all together.<=
u>








 








The =E2=80=9Caggregated signatures around mutabl=
e field=E2=80=9D would very be an experimental extension.








 








What I object to is, if the base spec specifical=
ly renders such extensions impossible








 








 <=
/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 Intel=
ligence Limited

Registered in England & Wales No: 01337451




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






 












From: Lotte
 Steenbrink [mailto:lotte.steenbrink@fu-berlin.de=
] 

Sent: 17 March 2016 16:48

To: Dearlove, Christopher (UK)

Cc: =
ietf@thomasclausen.org; Mobile Ad Ho=
c Networks mailing list

Subject: Re: [manet] Message integrity and message mutability (w=
as RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)












 







 <=
/span>



*** 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 Flag=
s that you can look out for i=
n emails
 you receive, click here.

If you feel the email is suspicious, please follow this process.








Hi all,










 














Am 17.03.2016 um 17:44 schrieb Dearlove, Christo=
pher (UK) <chris.dearlove@baesystems.com&g=
t;:










 












Good point about wheth=
er you just pass on one cost or a set of costs. As I said, not looked at det=
ails
 - I will, when time permits. One cost is much easier, and yes, it reduces t=
he fixed size aggregated signatures problem to =E2=80=9Cjust=E2=80=9D one of=
 computational load.
















 












For the record, Thomas=E2=80=99 understanding is=
 correct; the cost is one aggregated value. 












 












Best regards, 












Lotte Steenrbink










 <=
/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 Intel=
ligence Limited

Registered in England & Wales No: 01337451






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








 
















From: ietf@thomasclausen.org&=
nbsp;[mailto:ietf@thomasclausen.org] 

Sent: 17 March 2016 16:38

To: Dearlove, Christopher (UK)

Cc: Mobile Ad Hoc Networks mailing list

Subject: Re: Message integrity and message mutability (was RE: [=
manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
















 









 <=
/span>



*** 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 Flag=
s that you can look out for i=
n emails
 you receive, click here.

If you feel the email is suspicious, please follow this process.










 


















On 17 Mar 2016, at 17:30, Dearlove, Christopher (=
UK) <<=
span style=3D"color:purple">chris.dearlove@baesystems.com>
 wrote:














 
















I appreciate Thomas=E2=
=80=99s comments about the limitations of message regeneration, but I would b=
e a bit
 less absolute.
















 
















The issues over end to=
 end authentication and more advanced signatures are valid. I need to read
 the given reference on aggregate signatures to increase my knowledge (thank=
s for it), but my understanding of the possibilities in this field may offer=
 a solution to the problem, but with some other issues (possibly including a=
 new type of TLV).
















 
















But the hop count/limi=
t point I don=E2=80=99t fully agree with, you can regenerate with an increme=
nted/decremented
 count/limit, which leaves the ability to prevent messages propagating indef=
initely, including expanding ring searches, and retains the ability to use R=
FC 5497 interval and validity times that might be useful with an expanding r=
ing search (or might not).
















 
















But the key issue is t=
hat AODVv2 wants to accumulate metrics. I still haven=E2=80=99t got to the b=
ottom of
 many details here, but let=E2=80=99s for the moment just consider that conc=
eptually.
















 
















It=E2=80=99s hard to h=
andle end to end. Charlie=E2=80=99s draft attempts to do an end to end of so=
me information,
 not this information. I=E2=80=99m not sure if that=E2=80=99s useful (and th=
e specialised format is better avoided if possible). Other approaches are ho=
p by hop (might as well use packet signatures) and shared key (might as well=
 go hop by hop). Pairwise signatures for each
 pair of routers I=E2=80=99m discounting as scaling terribly. In the interes=
ts of completeness let=E2=80=99s mention not accumulating metrics, which put=
s us back to hop count and that=E2=80=99s not ideal either.=

















 
















I don=E2=80=99t think t=
here is an ideal solution. (I like ideas I=E2=80=99ve seen about aggregating=
, but that has
 some issues of its own, even apart from computational load.) I=E2=80=99d lo=
ve to be proved wrong - someone with the perfect solution to come along.
















 
















Which means that eithe=
r we make an arbitrary choice - which will be disagreed with, but needs disc=
ussing
 first - or create something flexible. Unfortunately flexible in that regard=
 constrains in others, e.g. some (many? most?) aggregating signatures need f=
ixed data sizes (which we can do by defining a TLV that =E2=80=9Cfills up=E2=
=80=9D with hop count, but that has a cost too).




















 














I have been told by people much more well versed=
 in this than I in cryptology, that the correct answer is =E2=80=9Csome=E2=80=
=9D.
















 
















That said, "AODVv2 wants to accumulate metrics=E2=
=80=9D =E2=80=94 does that mean that the message grows as it is being forwar=
ded, and that the recipient of a RREQ/RREP will know the individual
 costs of each path segment? My understanding is, that the recipient will ge=
t =E2=80=9Cthe sum the costs of each path segment=E2=80=9D which should be f=
itting within a fixed size?
















 
















Thomas
















 





































 
















Sorry, no answers, jus=
t comments. And I=E2=80=99m not addressing Thomas=E2=80=99s later points her=
e.
















 










--
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 Intel=
ligence 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 O=
f ietf@thomasclausen.org

Sent: 17 March 2016 16:00

To: Mobile Ad Hoc Networks mailing list

Subject: [manet] draft-ietf-manet-aodvv2-13 review - a couple of=
 big ticket Items




















 











 <=
/span>



*** 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 Flag=
s that you can look out for i=
n emails
 you receive, click here.

If you feel the email is suspicious, please follow this process.









***&=
nbsp;WARNING ***

EXTERNAL EMAIL -- This message originates from outside our o=
rganization.










 


















Dear all,


















 




















Apologies for not having gotten this done sooner=
 - day-job leaving few spare cycles.




















 




















I=E2=80=99ve previously offered reviews and comm=
ents, and some of those have been addressed in the latest I-D =E2=80=94 othe=
rs have not, but should be. I recall that there was some mail attempting
 to rebut parts of the review, and I will dig it out and reply to that.




















 




















With that being said, I have reviewed the latest=
 version of the document, and full details will be forthcoming. There=E2=80=99=
re a couple of big-ticket/architectural items that I want to
 address up front, as I believe that before we have those hammered out, it w=
ill be useless to go into details. Note, I do not claim that this is an exha=
ustive list of =E2=80=9Cbig ticket items=E2=80=9D, but that=E2=80=99s as far=
 as I have gotten in thinking this through.




















 




















I also bring these up as they are items that hav=
e been brought up repeatedly over the past years, but not resolved nor discu=
ssed.




















 




















Loops




















Just to bring this out: I share Chris=E2=80=99 w=
orry about conflicting and concurrent statements from the authors on =E2=80=9C=
There are no loops possible=E2=80=9D and =E2=80=9CWe need to fix two situati=
ons where
 loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating some loop c=
onditions=E2=80=9D




















 




















I particularly worry that this is not a discussi=
on had in public, but apparently in some other forum=E2=80=A6<=
/p>



















 




















 






















Intermediate Route Replies, and all of sec=
tion 10




















Section 10 contains a set of =E2=80=9Cvaguely sp=
ecified extensions=E2=80=9D, which is incoherent with the intended status in=
dicated for this document. 




















 




















Specifically, and this is not unrelated to the p=
oint about loops above, intermediate RREPs (section 10.3) are a potential so=
urce for loops.




















 




















Expanding Ring Multicast (section 10.1) is not d=
ocumented in a way that can be implemented (and also, see =E2=80=9CForwardin=
g-vs-regeneration=E2=80=9D below, it is in the present form of this protocol=

 impossible), etc.






















 




















 




















Forwarding-vs-regeneration<=
u>




















Recent exchanges on the list made me understand t=
hat protocol control messages are *not* forwarded, but are consumed at each h=
op, then a new message with (almost-but-not-quite)
 the same content is generated and transmitted.




















 




















I have thought some more on this (& read som=
e of the exchanges on the list on this topic by Chris, Ulrich, and others), a=
nd I am convinced that this is not the right way to go, at
 least for the following reasons:




















 




















 




















        =
    o        &nb=
sp; It renders the hop-limit/hop-count fields in the RFC5444 message=
 header useless.




















        =
            &nbs=
p;   This would not be bad if the functionality offered by th=
ose fields was not useful




















        =
            &nbs=
p;   =E2=80=94 sadly, it is. For example, for scope limited f=
looding (expanding ring search, and 




















        =
            &nbs=
p;   such) which may be of interest, and which require hop-li=
mit. 




















        =
            &nbs=
p;   A hop-count field may also provide a =E2=80=9Ccheap=E2=80=
=9D (in terms of overhead) additional piece




















        =
            &nbs=
p;   of information to use conjunctively with a =E2=80=9Creal=
=E2=80=9D metric.




















 




















        =
            &nbs=
p;   The only practical solution would be to re-introduce the=
se functions by way of inserting a




















        =
            &nbs=
p;   MessageTLV =E2=80=94 which (i) is not specified in this d=
ocument, and (ii) which would just




















        =
            &nbs=
p;   serve to render messages bigger than strictly needed.=





















 




















        =
            &nbs=
p;   Scope limited flooding  does seem to be a necessary=
 requirement, if for no




















        =
            &nbs=
p;   other reason than to prevent information from =E2=80=9Cc=
irculating forever in the network=E2=80=9D.




















 




















        =
    o        &nb=
sp; It makes end-to-end authentication unnecessarily hard.




















        =
            &nbs=
p;   I think Chris called this out already, but it bears repe=
ating: S generates a message 




















        =
            &nbs=
p;   (say, a RREQ), and includes an ICV calculated over the c=
ontent of the message.




















        =
            &nbs=
p;   For any recipient to be able to validate the ICV, the me=
ssage has to be exactly




















        =
            &nbs=
p;   the same =E2=80=94 not just in content, but in structure=
 =E2=80=94 as what was generated.




















 




















        =
            &nbs=
p;   =E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforw=
arding=E2=80=9D messages means, that the intermediate




















        =
            &nbs=
p;   router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose=
 a different structure (e.g., include TLVs




















        =
            &nbs=
p;   in a different order).




















 




















        =
            &nbs=
p;   The proposal from https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00<=
/span>




















        =
            &nbs=
p;   is to add constraints on (i) the set of elements to incl=
ude in a signature and (ii) the




















        =
            &nbs=
p;   order of these elements.




















 




















        =
            &nbs=
p;   One problem with that approach is (i): if an extens=
ion adds a message TLV, or an 




















        =
            &nbs=
p;   Address TLV, to a message, then that will not be =E2=80=9C=
covered=E2=80=9D by the proposed e2esec TLV.




















        =
            &nbs=
p;   Rather for *each* extension developed, an =E2=80=9Cupdat=
es e2esec=E2=80=9D clause needs to be done.




















 




















        =
            &nbs=
p;   I=E2=80=99d say that this approach would be prone to err=
ors =E2=80=94 and add entropy to the process




















        =
            &nbs=
p;   of designing protocol extensions. The alternative, a mes=
sage being generated by the




















        =
            &nbs=
p;   source and *forwarded* (as we do in OLSRv2, for example)=
 would allow ICV TLVs 




















        =
            &nbs=
p;   (even, allow reuse of those specified for OLSRv2) for co=
vering a message and 




















        =
            &nbs=
p;   extensions.




















 




















        =
            &nbs=
p;   =E2=80=9CBut what about the metrics value which will cha=
nge on each hop=E2=80=9D, you may say?




















        =
            &nbs=
p;   Fortunately, that is relatively easy to handle: simply z=
ero out the value of that TLV when




















        =
            &nbs=
p;   generating or verifying the ICV MessageTLV. And use Pack=
et-TLVs for hop-by-hop 




















        =
            &nbs=
p;   authentication, if needed (but, see below).




















 




















        =
    o        &nb=
sp; It prevents the use of more clever/advanced signature schemes=
/ICVs




















        =
            &nbs=
p;   Aggregate signature algorithms ( https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)




















        =
            &nbs=
p;   exist, and an interesting use-case can be found in also r=
eactive protocols, allowing verifying




















        =
            &nbs=
p;   not =E2=80=9Cjust=E2=80=9D the end points, but also the i=
ntermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D=





















        =
            &nbs=
p;   discussed above, or something smarter).



















        =
            &nbs=
p;   Regeneration of messages, rather than forwarding, render=
s that impossible (or, if used,




















        =
            &nbs=
p;   updating to  https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)




















 




















There are other reasons, but the above are those=
 that jump at me as immediate show-stoppers.




















 




















I do honestly not see what possible benefit ther=
e is from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inco=
nveniences, and security is not the least of these. Insisting on =E2=80=9Cre=
generation=E2=80=9D
 requires development of =E2=80=9Cnon-general workarounds=E2=80=9D as pointe=
d out above.




















 




















Security Considerations<=
/u>




















This is an always thorny subject. When OLSRv2 wa=
s going through the process we got a thorough education in how little we kne=
w about security from the SEC-ADs, and had to spend about
 a year or so developing RFC7183. The bottom line is, that this protocol nee=
ds its =E2=80=9CRFC7183  equivalent=E2=80=9D, either as part of the mai=
n document, or as an independent document. currently, that is not the case.<=
u>




















 




















A minima, looking at BCP72 and BCP107 =E2=80=94 t=
aking inspiration from RFC7183 might be aw good idea, as that was the most r=
ecent that went through the SEC AD. Regardless of how, however,
 a =E2=80=9Cmandatory to implement=E2=80=9D security mechanism most be speci=
fied (I think the right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D=
), in sufficient detail to ensure interoperable implementations.




















 




















As an example, both [RFC6130] and [RFC7181] set o=
ut that that:






















 




















      On receiving a ... message,=
 a router MUST first check if the




















      message is invalid for proc=
essing by this router




















 




















and then proceed to give a number of conditions t=
hat, each, will lead to a rejection of the message as "badly formed and ther=
efore invalid for processing=E2=80=9D =E2=80=94 a list which RFC7183
 then amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting =E2=
=80=9Crejection=E2=80=9D. Idem for message generation.




















 




















If I was to do RFC7181/RFC6130 today, I would in=
clude that directly into the protocol specifications. It turned out to be mo=
re overhead (and slow down publication anyways) to do
 it as separate documents.






















 




















Secondly, we need to be a lot more rigid in term=
s of what ICVs, Timestamps, etc. are added/removed, and what that brings.=





















 




















For example (with the assumption that messages a=
re *forwarded* and *not* regenerated), this could be one option:




















 




















        =
            &nbs=
p;   o         &=
nbsp;When a RREQ, RREP message is generated, add an ICV Message TLV, which i=
s calculated <this way>




















        =
            &nbs=
p;            &n=
bsp;   =E2=80=A6(take inspiration from RFC7183 here)




















 






























...



[Message clipped]  

_______________________________________________

manet mailing list

manet@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/manet


 










_______________________________________________<=
br>
manet mailing list

manet@ietf.org

ht=
tps://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.

********************************************************************<=
u>




_______________________________________________

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




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



=

--Apple-Mail-F906FF87-B060-47EA-9861-AC0E44371E23--


From nobody Mon Apr 25 07:42: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 E29F712D156 for ; Mon, 25 Apr 2016 07:42:37 -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 yBRhovXmPZqU for ; Mon, 25 Apr 2016 07:42:36 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 7ECDE12D5D3 for ; Mon, 25 Apr 2016 07:42:36 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id t10so215459459ywa.0 for ; Mon, 25 Apr 2016 07:42:36 -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=HSkWknpeKZEacA8O6kanbsxgVuzHcue2kqcUVIr279c=; b=fIeDYqopxo0oW8GpCY31jJGWu2iatCNCW6gor+MlYhJaZ6mfSEatuF4KfNt3h2IkGQ yl/HmSI6w5ohQw45xTijKBkrHMTA05uVCRvBMlMtADCKx4x64Axh86B1n1MiD0vkk+40 s9kWwI4nNuR/cFJ2da7JawQBS0hqo090FS7SXzip3ktUfjkPvXGjO46rnPDv2wd5jnU/ L481M1OvPsK2cR2+79xIRaUtvUDqKKlLZtD3varBd0Hb124sSF+lOgGApeAvAwT4Bojw csjqZ3ON35speS/fOJQsDJhruCPmrXcPDeKeC4WKvgFVOW6RF86xfyP88Oh1RaiBekLe mtGg==
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=HSkWknpeKZEacA8O6kanbsxgVuzHcue2kqcUVIr279c=; b=iNhDlSA7Cy3nzQyS/OON/rMhtQISX6Aff5ZcLZjvbHLHgbIG4dPdPKTSotL8sgD3lU wleV55+zaqpuOKFODE+IX/tZpvsqNUihxrPgzOwQB3eMREMk3gTHAhiNgdCLvNUcFk6T Pcsz3W1zUuxV9bOQFpklZSduPro4wNEmYJY62VoQUYVZWOguTfdOEJ5PjmbrrOnhkDYG vzbYfiP8QfFbKLpEpfWOSCr4LFy4HuzirdaLhlWpEPwbVLzQxHCxVFDLO218nTpt7NuN qN2I9S9N0zdVlMkRufhcPHmmNd3CLXoeCLUMK/5c2ZwYqhWS0m0jr40nhfKMFuYFUSbL f7Fg==
X-Gm-Message-State: AOPr4FXHccCcel8MwdC0buLEr70Jmrw3nekc1KSL4nlk4qLK6L70L9zQMi9ANWg50r43Wtkepf6fdkemcltCvg==
MIME-Version: 1.0
X-Received: by 10.176.2.236 with SMTP id 99mr5963038uah.79.1461595355745; Mon, 25 Apr 2016 07:42:35 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Mon, 25 Apr 2016 07:42:35 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org> 
Date: Mon, 25 Apr 2016 10:42:35 -0400
Message-ID: 
From: Justin Dean 
To: Thomas Heide Clausen 
Content-Type: multipart/alternative; boundary=001a113d19a8fc15390531502ff2
Archived-At: 
Cc: Christopher Dearlove , Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 14:42:38 -0000

--001a113d19a8fc15390531502ff2
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 25, 2016 at 10:26 AM, Justin Dean  wrote:

> The address in the RREP_Ack may be required due to the RREP_Ack being
> multicast as there is not yet a verified unicast route installed yet.
> Going to double check if I'm remembering correctly.
>
> From section 7.2.3

This AODVv2 (RREP) message is used to create a corresponding [RFC5444
]
   message (see Section 8
)
which is handed to the RFC5444 
multiplexer
   for further processing.  If the Neighbor Set contains an entry for
   the neighbor stored as LocalRoute[OrigAddr].NextHop, with
   Neighbor.State set to Confirmed, the multiplexer is instructed to
   unicast the RREP to LocalRoute[OrigAddr].NextHop.  Otherwise, it
   multicasts the RREP to LL-MANET-Routers.  The RREP MUST be sent over

   LocalRoute[OrigAddr].NextHopInterface.

--001a113d19a8fc15390531502ff2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Apr 25, 2016 at 10:26 AM, Justin Dean <bebemaster@gmail.com>=
 wrote:
The address in the RREP=
_Ack may be required due to the RREP_Ack being multicast as there is not ye=
t a verified unicast route installed yet.=C2=A0 Going to double check if I&=
#39;m remembering correctly.=C2=A0

From sect=
ion 7.2.3
This AODVv2 (RREP) message is used to cre=
ate a corresponding [RFC5444]
   message (see Section 8) which is handed to the RFC5444 multiplexer
   for further processing.  If the Neighbor Set contains an entry for
   the neighbor stored as LocalRoute[OrigAddr].NextHop, with
   Neighbor.State set to Confirmed, the multiplexer is instructed to
   unicast the RREP to LocalRoute[OrigAddr].NextHop.  Otherwise, it
   multicasts the RREP to LL-MANET-Routers.  The RREP MUST be sent over=C2=
=A0
=C2=A0 =C2=A0=
LocalRoute[OrigAddr].NextHopInterface.=C2=A0



--001a113d19a8fc15390531502ff2--


From nobody Mon Apr 25 07:53: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 9F69B12D1E2 for ; Mon, 25 Apr 2016 07:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.82
X-Spam-Level: 
X-Spam-Status: No, score=-4.82 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, TRACKER_ID=1.306] 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 CEIOErN4-GjN for ; Mon, 25 Apr 2016 07:52:58 -0700 (PDT)
Received: from ukmta1.baesystems.com (unknown [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 82CDA12D156 for ; Mon, 25 Apr 2016 07:52:57 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,533,1454976000"; d="scan'208,217"; a="63977467"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 25 Apr 2016 15:52:56 +0100
X-IronPort-AV: E=Sophos;i="5.24,533,1454976000";  d="scan'208,217";a="115386725"
Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 25 Apr 2016 15:51:39 +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; Mon, 25 Apr 2016 15:51:39 +0100
From: "Dearlove, Christopher (UK)" 
To: Justin Dean , Thomas Heide Clausen 
Thread-Topic: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
Thread-Index: AQHRgGzYnQ0jbgFSiUepI05etGsIBJ9d2vAQgAAD6gCAAAGt4IAAAs+AgDjn+gCAAAvpAIAAo5QAgAMoSiCAACB6gIAAE7kAgAARySCAAAAGgIAAAjOAgAARHhA=
Date: Mon, 25 Apr 2016 14:51:38 +0000
Message-ID: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org> 
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B15E3GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: 
Cc: Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 14:53:04 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B15E3GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBoYXMgdG8gZ28gYmFjayB0byBWaWN0b3JpYeKAmXMgc3VtbWFyeSBoZXJlLiBJdCBzYXlzOg0K
DQoyKSBDIGNyZWF0ZXMgdGhlIFJSRVAuIFNpbmNlIGl0IGRvZXNudCBrbm93IGlmIHRoZSBsaW5r
IHRvIEIgaXMgYmlkaXJlY3Rpb25hbCwgaXQgaW5jbHVkZXMgdGhlIEFja1JlcSAoYW4gYWRkcmVz
cyB0byBpbmRpY2F0ZSB0aGF0IGl0IGV4cGVjdHMgdG8gcmVjZWl2ZSBhIFJSRVBfQWNrIGZyb20g
QikuDQoNClRoYXQgZG9lc27igJl0IGFjdHVhbGx5IGluZGljYXRlIGlmIHRoYXTigJlzIEPigJlz
IGFkZHJlc3Mgb3IgQuKAmXMgYWRkcmVzcyBiZWluZyBpbmNsdWRlZC4gSeKAmWQgYXNzdW1lZCBp
dCB3YXMgQ+KAmXMgYWRkcmVzcy4gWW91ciBjb21tZW50IG1ha2VzIHNlbnNlIGlmIGl04oCZcyBC
4oCZcyBhZGRyZXNzLiBSZWFkaW5nIGFnYWluLCBJIHRoaW5rIHlvdeKAmXJlIHByb2JhYmx5IHJp
Z2h0LiBCdXQgb25seSBwcm9iYWJseS4gQ2FuIHdlIGNvbmZpcm0gdGhhdC4NCg0KSSBhc3N1bWUg
eW91IG1lYW50IHRoYXQgdGhlIFJSRVAgKG5vdCBSUkVQX0FjaykgaXMgbXVsdGljYXN0LiBUaGVy
ZeKAmXMgYSBiaXQgb2YgYSBjaGlja2VuIGFuZCBlZ2cgcHJvYmxlbSBoZXJlLiBXZSBkbyBrbm93
IGhvdyB3ZSB3YW50IHRvIHVuaWNhc3QuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2Vu
aW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2Ug
TGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0
ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxv
dmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBD
aGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3Nl
eCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5j
b20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3Rl
cmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBT
dXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTog
SnVzdGluIERlYW4gW21haWx0bzpiZWJlbWFzdGVyQGdtYWlsLmNvbV0NClNlbnQ6IDI1IEFwcmls
IDIwMTYgMTU6MjYNClRvOiBUaG9tYXMgSGVpZGUgQ2xhdXNlbg0KQ2M6IERlYXJsb3ZlLCBDaHJp
c3RvcGhlciAoVUspOyBDaHJpc3RvcGhlciBEZWFybG92ZTsgTW9iaWxlIEFkIEhvYyBOZXR3b3Jr
cyBtYWlsaW5nIGxpc3Q7IFZpY3RvcmlhIE1lcmNpZWNhDQpTdWJqZWN0OiBSZTogW21hbmV0XSBN
ZXNzYWdlIGludGVncml0eSBhbmQgbWVzc2FnZSBtdXRhYmlsaXR5ICh3YXMgUkU6IGRyYWZ0LWll
dGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEgY291cGxlIG9mIGJpZyB0aWNrZXQgSXRlbXMp
DQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNp
ZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0
aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNr
IG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3Jt
YXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVt
YWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3Rl
bXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFn
cy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xs
b3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3
b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGlj
aW91cyUyMEVtYWlscy5wZGY+Lg0KVGhlIGFkZHJlc3MgaW4gdGhlIFJSRVBfQWNrIG1heSBiZSBy
ZXF1aXJlZCBkdWUgdG8gdGhlIFJSRVBfQWNrIGJlaW5nIG11bHRpY2FzdCBhcyB0aGVyZSBpcyBu
b3QgeWV0IGEgdmVyaWZpZWQgdW5pY2FzdCByb3V0ZSBpbnN0YWxsZWQgeWV0LiAgR29pbmcgdG8g
ZG91YmxlIGNoZWNrIGlmIEknbSByZW1lbWJlcmluZyBjb3JyZWN0bHkuDQoNCkp1c3Rpbg0KDQpP
biBNb24sIEFwciAyNSwgMjAxNiBhdCAxMDoxOCBBTSwgPGlldGZAdGhvbWFzY2xhdXNlbi5vcmc8
bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmc+PiB3cm90ZToNCkhpLA0KDQpJIG11c3QgYWRt
aXQgdGhhdCB3aGlsZSBJIGhhdmUgcmV2aWV3ZWQgdGhlIHByb3RvY29sIHNldmVyYWwgdGltZXMs
IEnigJl2ZSBub3QgYmVlbiBkaWdnaW5nIHRoYXQgZGVlcCBpbnRvIHRoZSBwcm90b2NvbCBmdW5j
dGlvbmluZyB0byBjYXRjaCB0aGlzIGlzc3VlIG9mIGhvdyBpbnZhc2l2ZSB0aGUgcHJvdG9jb2wg
b3BlcmF0aW9ucyBhcmUgd2hlbiBmb3J3YXJkaW5nIGEgbWVzc2FnZTogdGhlcmUgd2VyZSBvdGhl
ciDigJxtYWpvcuKAnSBpc3N1ZXMgdG8gYWRkcmVzcyAoYW5kIHdoaWNoIG9ic2N1cmVkIHRoZSBk
ZXRhaWxzKSwgc28gYXMgYSBmaXJzdCBvcmRlcjogdGhhbmsgeW91IFZpY3RvcmlhLCBmb3IgaGF2
aW5nIGNhbGxlZCBhdHRlbnRpb24gdG8gdGhpcy4NCg0KVG8gdGhlIHN1YnN0YW5jZSBvZiB0aGVz
ZSBlbWFpbHMuDQoNCkkgYW0gYWZyYWlkIHRoYXQgSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgdXNl
IG9mIGluc2VydGluZyB2YWxpZGl0eSBUTFZzIHdoaWxlIGluLWZsaWdodCwgaW50byBhIG1lc3Nh
Z2UuIEFjdHVhbGx5LCBJIGFtIGR1YmlvdXMgZm9yIGJvdGggdGhlIG9yaWdpbmF0b3IgaW5zZXJ0
aW5nIHRoaXMgKGhvdyBjYW4gdGhlIG9yaWdpbmF0b3Igb2YgYSBtZXNzYWdlIGtub3cgaG93IOKA
nGxhdHRlciBwYXJ0cyBvZiB0aGUgcGF0aOKAnSB3aWxsIGJlIGhhdmXigJ0pIGV4Y2VwdCBpZiB3
ZSBhcmUgdGFsa2luZyBkdXR5LWN5Y2xpbmcgb2YgZGV2aWNlcyBhbmQgaW5zZXJ0aW5nIOKAnHRo
ZSByZW1haW5pbmcgdGltZSB0aGF0IEkgYW0gZ29pbmcgdG8gYmUgdXAgYmVmb3JlIEkgc3VzcGVu
ZOKAnS4gSW50dWl0aXZlbHksIHRoYXQgd291bGQgYWxzbyBhc3N1bWUgZmFpcmx5IGxvbmcgZHV0
eSBjeWNsZXMg4oCcSSBhbSB1cCBmb3IgdGVucyBvZiBzZWNvbmRz4oCdLCB3aGljaCBJIGFtIG5v
dCBzdXJlIGFyZSBhY3R1YWxseSByZWFsaXN0aWMuIEFuZCwgYXMgQ2hyaXMgc2F5cyBpbiBhbm90
aGVyIGVtYWlsLCB0aGlzIGlzIHRyYWRpbmcgb2ZmIOKAnHRoZSBhYmlsaXR5IHRvIGRvIHNlY3Vy
aXR54oCdIGZvciBhbiB1bmtub3duL3VudGVzdGVkIGZlYXR1cmUg4oCUIHdoaWNoIEkgdGhpbmsg
aXMgdGhlIHdyb25nIHRyYWRlLW9mZi4NCg0KT24gaGUgdG9waWMgb2Yg4oCcbmVlZGluZyB0byBw
dXQgYW4gYWRkcmVzcyBpbuKAnSBmb3IgUlJFUC1BQ0ssIEkgbXVzdCBhZG1pdCB0aGF0IHRoaXMg
c2VlbXMgcm91bmRhYm91dC4gSSBjYW4gc2VlIHRocmVlIGlzc3VlcyBoZXJlOg0KDQpvIEkgYW0g
bm90IHN1cmUgdGhhdCBhZGRpbmcgYW4gYWRkcmVzcyB2cy4gYSBmbGFnIG1heSBub3QgaGF2ZSB0
byBkbyB3aXRoIHRoZSDigJxtdWx0aXBsZSBpbnRlcmZhY2VzLw0KbXVsdGlwbGUgYWRkcmVzc2Vz
4oCdIGRpc2NyaW1pbmF0aW9uIG1lY2hhbmljcyBvZiB0aGUgcHJvdG9jb2w/IEkgaGF2ZW7igJl0
IHdvcmtlZCBpdCB0aHJvdWdoLCB0aG91Z2gsDQpidXQgdGhhdCB3b3VsZCBiZSBhIGd1ZXNzLg0K
DQpvIFRoZSBlbmQtdG8tZW5kIHRvcG9sb2d5IGRpZmZ1c2lvbiBtZWNoYW5pc20gc2hvdWxkIG5v
dCBuZWVkIHRvIGJlIGNvbmNlcm5lZCB3aXRoIHRoZQ0K4oCcYmlkaXJlY3Rpb25hbGx5IGNoZWNr
4oCdIG9mIGEgbG9jYWwgbGluayAoaW4gcGFydCwgYXMgaXQgZW5jdW1iZXJzIHNlY3VyaXR5LCBi
dXQgbm90IG9ubHkpLiAgSW4gc2hvcnQsIGENCmZsYWcgb3IgYW4gYWRkcmVzcywgYm90aCBhcmUg
KGVxdWFsbHkpIGJhZC4NCg0KbyBBIGNsZWFuZXIgbWVjaGFuaXNtIHdvdWxkIGJlIGEg4oCcaGVs
bG8gbWVjaGFuaXNt4oCdLCBub3QgbmVjZXNzYXJpbHkgYXMgTkhEUCwgYnV0IGEg4oCcd2hlbg0K
Zm9yd2FyZGluZyBhIFJSRVEvUlJFUCwgdHJpZ2dlciBhIDMtd2F5IGhlbGxvIGV4Y2hhbmdlLCBp
ZiB0aGUgbGluayBpcyBlc3RpbWF0ZWQgdG8gYmUgb2YgYQ0KdHlwZSB3aGljaCBwb3RlbnRpYWxs
eSBjYW4gYmUgdW5pZGlyZWN0aW9uYWzigJ0uIFRoZXJlIGlzIGFub3RoZXIgYmVuZWZpdCB0byBk
b2luZyB0aGF0LCBzZWUgdGhlIGVuZA0Kb2YgdGhpcyBlbWFpbC4NCg0KRWl0aGVyIHdheSwgSSBk
byBub3QgbGlrZSB0aGUgbm90aW9uIG9mIGZ1c2luZyBtZXRyaWNzLWFuZC1saW5rLWJpZGlyZWN0
aW9uYWxpdHktZGV0ZWN0aW9uIGFueSBtb3JlIHRoYW4gSSBsaWtlIGZ1c2luZyBnbG9iYWwtdG9w
b2xvZ3ktZGlmZnVzaW9uLWFuZC1saW5rLWJpZGlyZWN0aW9uYWxpdHktZGV0ZWN0aW9uLg0KDQpU
aGUgc29sdXRpb24gYWxsIHRoaXMgaXMsIHRvIG1lLCB0aHJlZWZvbGQNCg0KMSkgRmFjdG9yIG91
dCB0aGUgYmlkaXJlY3Rpb25hbGx5IGNoZWNrIGluIGEgKHRyaWdnZXJlZCkgbmVpZ2hib3VyIGRl
dGVjdGlvbiBtZWNoYW5pc20NCih0cmlnZ2VyZWQgSEVMTE8gbWVzc2FnZSkNCg0KMikgUmVtb3Zl
IHRoZSDigJx2YWxpZGl0eSB0aW1lIFRMVnPigJ0sIHNpbmNlIHRoZXkgYWRkIGNvbXBsZXhpdHkg
Zm9yIG5vIHBlcmNlaXZhYmxlIGJlbmVmaXRzDQoNCjMpIFVzZSB0aGUgc2VjdXJpdHkgbW9kZWwg
dGhhdCB3ZeKAmXZlIGRpc2N1c3NlZCBwcmV2aW91c2x5LCB3aGVyZSAob25seSkgdGhlIG1ldHJp
Y3MgY2hhbmdlIHBlciBob3AuDQoNClNpbmNlIHdl4oCZcmUgZGlzY3Vzc2luZyBiaS1kaXJlY3Rp
b25hbGl0eSBvZiBsaW5rcyBoZXJlLCBhbmQgdGhlIG5lY2Vzc2l0eSBvZiBhIG1lY2hhbmlzbSBm
b3IgaGFuZGxpbmcgdGhlc2UsIEkgd2FudCB0byBjYWxsIGF0dGVudGlvbiB0byBhIHJlbGF0ZWQg
aXNzdWUsIGFzIEkgaGludGVkIHByZXZpb3VzbHkuDQoNCg0KVGhlIGFic3RyYWN0IHN0YXRlcyB0
aGF0IHRoZSBwcm90b2NvbDoNCg0KDQoNCiAgIC4uLmlzIGludGVuZGVkIGZvciB1c2UgYnkgbW9i
aWxlIHJvdXRlcnMgaW4gd2lyZWxlc3MsIG11bHRpaG9wDQoNCiAgIG5ldHdvcmtzLg0KDQoNCg0K
U2VjdGlvbiA1IHBhcmFncmFwaCA0ICBvZiB0aGUgZG9jdW1lbnQsIGhvd2V2ZXIsIHJlYWRzOg0K
DQoNCg0KICAgQXNzdW1pbmcgbGluayBtZXRyaWNzIGFyZSBzeW1tZXRyaWMsIHRoZSBjb3N0IG9m
IHRoZSByb3V0ZXMgaW5zdGFsbGVkDQoNCiAgIGluIHRoZSBMb2NhbCBSb3V0ZSBTZXQgYXQgZWFj
aCByb3V0ZXIgd2lsbCBiZSBjb3JyZWN0LiAgV2hpbGUgdGhpcw0KDQogICBhc3N1bXB0aW9uIGlz
IG5vdCBhbHdheXMgY29ycmVjdCwgY2FsY3VsYXRpbmcgaW5jb21pbmcvb3V0Z29pbmcNCg0KICAg
bWV0cmljIGRhdGEgaXMgb3V0c2lkZSBvZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQpJIGRv
IG5vdCBrbm93IG9mIGFueSB3aXJlbGVzcyBzeXN0ZW1zLCB3aGVyZSB0aGUgYXNzdW1wdGlvbiB0
aGF0IOKAnGxpbmsgbWV0cmljcyBhcmUgc3ltbWV0cmlj4oCdIGFjdHVhbGx5IGhvbGRzLiBDb25z
ZXF1ZW50bHksIHRoZSBjb25jbHVzaW9uIGluIHRoZSBxdW90ZWQgcGFyYWdyYXBoOg0KDQoNCg0K
ICAgY2FsY3VsYXRpbmcgaW5jb21pbmcvb3V0Z29pbmcNCg0KICAgbWV0cmljIGRhdGEgaXMgb3V0
c2lkZSBvZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQpJcyBub3QgYW4gYWNjZXB0YWJsZSBk
ZXNpZ24gY2hvaWNlLg0KDQpXaGlsZSB0aGlzIHByb3RvY29sIG1heSBub3Qgd2FudCB0byDigJxj
YWxjdWxhdGUgaWYgZm9yIHRoaXMgbGluayB0aGUgbWV0cmljcyBpcyA0IG9yIDXigJ0sIHRoZSBw
cm90b2NvbCBtdXN0IGJlIGFibGUgdG8gY29udmV5IGFuZCBkaXN0aW5ndWlzaCB0aGF0IOKAnHRo
ZSBtZXRyaWMgZnJvbSBBIHRvIEIgaXMgNCwgYW5kIHRoZSBtZXRyaWMgZnJvbSBCIHRvIEEgaXMg
MTnigJ0uDQoNClRoaXMgaXMgYSDigJxyZWxhdGVkIGlzc3Vl4oCdIHNpbmNlIHRoZSBzb2x1dGlv
biBtYXkgKGFzIHdpdGggdGhlIGJpLWRpcmVjdGlvbmFsaXR5IGNoZWNrKSBiZSBpbiB0aGUgdHJp
Z2dlcmVkIG5laWdoYm91ciBkZXRlY3Rpb24gbWVjaGFuaXNtOiB0aGF0IGV4Y2hhbmdlIGNvdWxk
LCBpZiBkZXNpZ25lZCBjYXJlZnVsbHksIGJlIHVzZWQgdG8gcHJvYmUgZm9yIGFuZCBjb252ZXkg
bWV0cmljcyBpbmZvcm1hdGlvbiwgYWxzby4NCg0KSG9wZSB0aGlzIGhlbHBzLA0KDQoNClRob21h
cw0KDQpPbiAyNSBBcHIgMjAxNiwgYXQgMTU6MjcsIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp
IDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFl
c3lzdGVtcy5jb20+PiB3cm90ZToNCg0KQXNzdW1pbmcgZm9yIHRoZSBtb21lbnQgdGhhdCBldmVy
eW9uZSB3aWxsIG5lZWQgYW4gUlJFUC1BY2sgb3Igd29u4oCZdCAobGV04oCZcyBjb21lIGJhY2sg
dG8gdGhhdCkgd2h5IGRvIEMgYW5kIEIgbmVlZCB0byBwdXQgYW4gYWRkcmVzcyBpbiBhcyBhbiBS
UkVRLUFjayByZXF1ZXN0PyBXaHkgbm90IGEgZmxhZywgYmVjYXVzZSB0aGUgYWRkcmVzcyB3aWxs
IGJlIGluY2x1ZGVkIGFzIHRoZSBJUCBzZW5kaW5nIGFkZHJlc3MgLSBhbmQgd2Uga25vdyA1NDQ0
IGlzIHJlcXVpcmVkIHRvIHBhc3MgdGhhdCBvbi4gKEl04oCZcyB1c2VkIGJ5IE5IRFAgYXMgd2Vs
bC4pIFRoZW4gd2UgZG9u4oCZdCBuZWVkIHRvIGNoYW5nZSB0aGUgUlJFUCwgaXQgd2lsbCBoYXZl
IGEgZmxhZyBzZXQgb3Igbm90LCBhbmQgd29u4oCZdCBjaGFuZ2UgKGluIHRoaXMgcmVnYXJkKS4N
Cg0KTm93IGxldOKAmXMgY29uc2lkZXIgZG8gd2Uga25vdyB3aGV0aGVyIHdlIGNhbiBzZXQgYSBm
aXhlZCBmbGFnLiBGaXJzdCBJ4oCZZCBzYXkgdGhlcmUgYXJlIHR3byBjYXNlcyAtIHlvdeKAmXZl
IGdvdCBhIGZpcm0gY29udHJvbCBvbiB3aGF04oCZcyBnb2luZyBvbiBpbiB5b3VyIG5ldHdvcmss
IG9yIGl04oCZcyBvbmUgb2YgdW5rbm93biBwYXJ0aWVzIGFuZCBiZWhhdmlvdXIgKGNvbnNpc3Rl
bnQgd2l0aCBzcGVjaWZpY2F0aW9uKS4gSW4gdGhlIGZvcm1lciBjYXNlIHlvdSBvbmx5IHdhbnQg
b25lIHNldHRpbmcsIGZvciBleGFtcGxlIG5vLUFjayBpZiBydW5uaW5nIE5IRFAgb3IgeW91ciBN
QUMgbGF5ZXIgdGVsbHMgeW91IGFib3V0IGJpZGlyZWN0aW9uYWxpdHksIEFjayBvdGhlcndpc2Uu
IEluIHRoZSBsYXR0ZXIgY2FzZSwgSSB0aGluayB5b3UganVzdCBhbHdheXMgd2FudCBhbiBBY2su
IFNvIGJvdGggY2FzZXMgZ2V0IHlvdSB0byB0aGUgc2FtZSBwbGFjZS4NCg0KU2hvdWxkIHRoYXQg
bm90IGJlIGFuIGFjY2VwdGFibGUgYXJndW1lbnQgKHRob3VnaCBJIHRoaW5rIGl04oCZcyBnb29k
IGZvciB3aGVyZSB3ZSBhcmUgLSBpbiBmYWN0IGFsd2F5cyBBY2sgaXMgY2xvc2UpIHRoZW4gYXQg
ZmxhZyBpcyBhIHN0ZXAgYmV0dGVyLCBpdOKAmXMgYSBmaXhlZCBsb2NhdGlvbiB0byBjaGFuZ2Uu
IEhvd2V2ZXIgaXQgd291bGQgYmUgYmV0dGVyIGluIHRoYXQgY2FzZSBpZiB0aGUgdHdvIHRoaW5n
cyB0byBjaGFuZ2UgKG1ldHJpYyBhbmQgYWNrIGZsYWcpIHdlcmUgdG9nZXRoZXIuIEJ1dCB0aGF0
IGhhcyBpdHMgb3duIGlzc3Vlcywgc28gSSB3b27igJl0IGdvIHRoZXJlLg0KDQotLQ0KQ2hyaXN0
b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFw
cGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDog
ICs0NCAoMCkxMjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4gIHwg
IEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBi
YWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxt
c2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENN
MiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9h
aT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQg
aW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJl
eSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBWaWN0
b3JpYSBNZXJjaWVjYSBbbWFpbHRvOnZtZXJjaWVjYTBAZ21haWwuY29tXQ0KU2VudDogMjUgQXBy
aWwgMjAxNiAxNDoxNQ0KVG86IEppYXppIFlJDQpDYzogRGVhcmxvdmUsIENocmlzdG9waGVyIChV
Syk7IENocmlzdG9waGVyIERlYXJsb3ZlOyBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcg
bGlzdA0KU3ViamVjdDogUmU6IFttYW5ldF0gTWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2Ug
bXV0YWJpbGl0eSAod2FzIFJFOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBh
IGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKQ0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBt
ZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBm
cm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1
bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFj
aG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhh
dCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8
aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3Bv
dGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFp
bCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFu
ZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3Vt
ZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCkhpIEppYXpp
LA0KDQoNCk9uIE1vbiwgQXByIDI1LCAyMDE2IGF0IDE6MDQgUE0sIEppYXppIFlJIDxpZXRmQGpp
YXppeWkuY29tPG1haWx0bzppZXRmQGppYXppeWkuY29tPj4gd3JvdGU6DQpIaSwNCg0KT24gTW9u
LCBBcHIgMjUsIDIwMTYgYXQgMTE6MjAgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxj
aHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lz
dGVtcy5jb20+PiB3cm90ZToNCldpdGggcmVnYXJkIHRvIHlvdXIgdmFsaWRpdHkgdGltZSBwb2lu
dCwgd2UgaGVyZSBoYXZlIGEgdHJhZGVvZmYuIElmIHlvdSBhbGxvdyB0aGF0IGZlYXR1cmUsIGl0
IHNpZ25pZmljYW50bHkgaW1wYWN0cyBvbiB0aGUgYXBwcm9hY2ggdGhhdCB3YXMgY29taW5nIHRv
Z2V0aGVyIG9uIGFzIGJlc3QgeW91IGNhbiBlbmQgdG8gZW5kIGVuY3J5cHRpb24uDQoNClNvIHRo
ZSBxdWVzdGlvbiBpcywgaXMgdGhpcyBhIGZlYXR1cmUgdGhhdOKAmXMgcmVhbGx5IHdhbnRlZD8g
VW5mb3J0dW5hdGVseSBJIHRoaW5rIHdlIGtub3cgdGhhdCB0aGUgYW5zd2VyIHRvIHRoYXQgaXMs
IHdlIGRvbuKAmXQga25vdyBiZWNhdXNlIHdlIGRvbuKAmXQgaGF2ZSBhbnkgZXhwZXJpZW5jZS4g
TXkgdmlldyB3b3VsZCBiZSB0aGF0IGluIHRoZSB0cmFkZW9mZiBvZiBhbiB1bnRlc3RlZCBmZWF0
dXJlICh1bmxlc3MgSeKAmW0gd3JvbmcgYWJvdXQgdGhhdCkgYW5kIHRoZSBzZWN1cml0eSBjb21w
bGljYXRpb24sIHNlY3VyaXR5IHdpbnMgYW5kIGRyb3AgdGhlIGZlYXR1cmUuIElmIHRoZXJlIGlz
IHNvbWUgcmVhbCByZXF1aXJlbWVudCwgdGhlbiB0aGVyZeKAmXMgYSBkaXNjdXNzaW9uLiAoUXVl
c3Rpb25zIGxpa2UgaG93IG9mdGVuIHRoZSBpbnRlcm1lZGlhdGUgcm91dGVycyBhY3R1YWxseSBo
YXZlIGFueSBrbm93bGVkZ2UgLSB0eXBpY2FsbHkgbGlua3MgYnJlYWsgZm9yIHVuZXhwZWN0ZWQg
cmF0aGVyIHRoYW4gZXhwZWN0ZWQgcmVhc29ucy4gQW5kYW4gaW50ZXJtZWRpYXRlIHJvdXRlciBj
b3VsZCBwb3NzaWJseSB1c2UgYSB2YWxpZGl0eSB0aW1lIHRvIGluZmx1ZW5jZSBpdHMgYmVoYXZp
b3VyLikgTm90ZSB0aGF0IGRyb3BwaW5nIHRoZSBhYmlsaXR5IG9mIGludGVybWVkaWF0ZSByb3V0
ZXJzIHRvIG1vZGlmeS9zZXQgc3RpbGwgYWxsb3dzIHZhbGlkaXR5IHRpbWVzIHBlciByb3V0ZSB0
byBiZSBzZXQgYXQgZW5kcG9pbnRzLg0KDQpJIGFncmVlIHdpdGggQ2hyaXMnIGNvbmNlcm4uDQpU
aGUgVmFsaWRpdHlUaW1lIGlzIG9wdGlvbmFsLCB3aGljaCBtYWtlcyB0aGUgaW50ZWdyaXR5IHBy
b3RlY3Rpb24gaGFyZC4gRnVydGhlcm1vcmUsIGl0IGdpdmVzIGEgcG90ZW50aWFsIGF0dGFjayB2
ZWN0b3I6IGFzIGFsbCB0aGUgcm91dGVycyBpbiBhIHBhdGggd2lsbCB0YWtlIHRoZSBzaG9ydGVz
dCB2YWxpZGl0eVRpbWUsIGEgY29tcHJvbWlzZWQgcm91dGVyIGNhbiBzZXQgdGhlIHRoZSB2YWxp
ZGl0eVRpbWUgdG8gYSB2ZXJ5IHNob3J0IHZhbHVlLCB3aGljaCB3aWxsIG1ha2UgdGhlIHJvdXRl
IGluc3RhbGxlZCBhbG9uZyB0aGUgcGF0aCBiZWNhbWUgaW52YWxpZCAodmVyeSBzb29uKS4NCg0K
T24gdGhlIG90aGVyIGhhbmQsIEknbSBub3Qgc3VyZSB0aGlzIG9wdGlvbiB3aWxsIGdpdmUgdXMg
bXVjaCBoZWxwLiBDaHJpcyBtZW50aW9uZWQgbXVjaCBrbm93bGVkZ2UgaW50ZXJtZWRpYXRlIHJv
dXRlciB3b3VsZCBoYXZlIHRvIGRlY2lkZSB0aGlzIHZhbHVlIChhbmQgaG93IG11Y2ggc2Vuc2Ug
dGhlIHZhbHVlIHdvdWxkIG1ha2UpLg0KQW5vdGhlciBpc3N1ZSBpcywgYSByb3V0ZSB0byBhIGRl
c3RpbmF0aW9uIG1pZ2h0IGJlIHVwZGF0ZWQgYnkgZGlmZmVyZW50IHNvdXJjZXMuIEZvciBleGFt
cGxlLCBpbiB0aGUgbmV0d29yayBiZWxvdzoNCg0KQS0tLS1CLS0tLS1DDQoNCkEgZmlyc3QgZXN0
YWJsaXNoIGEgcm91dGUgdG8gQiB3aXRoIGxvbmcgdmFsaWRpdHkgdGltZS4gVGhlbiBBIGluaXRp
YXRlcyBhIHJvdXRlIGRpc2NvdmVyeSB0byBDLiBDIHRlbmRzIHRvIHNldCBhIHNob3J0IHZhbGlk
aXR5IHRpbWUsIHdoaWNoIHdpbGwgbWFrZSB0aGUgcm91dGUgYmV0d2VlbiBCIGFuZCBBIGV4cGly
ZSBlYXJsaWVyIHRoYW4gZXhwZWN0ZWQuDQpJcyB0aGlzIGEgcHJvYmxlbT8gTWF5YmUgeWVzLCBt
YXliZSBubyAtLSBJJ20gbm90IHN1cmUgaXQncyBjb25zaWRlcmVkIG9yIG5vdC4NCg0KDQpOb3Qg
c3VyZSBJIGZvbGxvdyBoZXJlLg0KQ3VycmVudGx5LCB0aGUgdmFsaWRpdHkgdGltZSBvZiB0aGUg
cm91dGUgYmV0d2VlbiBBIGFuZCBCIHdvdWxkIG5vdCBhZmZlY3RlZCBieSBhIHNob3J0IHZhbGlk
aXR5IHRpbWUgb2YgYSByb3V0ZSBiZXR3ZWVuIEEgYW5kIEMuIFZhbGlkaXR5IHRpbWVzIGFyZSBw
ZXItcm91dGUsIGFuZCB0aGUgcm91dGUgQS1CIGFuZCB0aGUgcm91dGUgQS1DIGFyZSBzZXBhcmF0
ZS4NCklmIHdlIHN3aXRjaGVkIHRvIGEgdmFsaWRpdHkgdGltZSBwZXIgbmVpZ2hib3IgKHNvIHRo
YXQgd2UgY2FuIGtlZXAgdmFsaWRpdHkgdGltZSBzZXBhcmF0ZSBmcm9tIHJvdXRlIGFkdmVydGlz
ZW1lbnRzKSBhcyBJIG1lbnRpb25lZCBpbiB0aGUgZW1haWwgYmVsb3csIHRoZW4gdGhlIHZhbGlk
aXR5IG9mIGEgcm91dGUgYmV0d2VlbiBBIGFuZCBDIHdvdWxkIGJlIGFmZmVjdGVkIGlmIHRoZXJl
IHdhcyBhIHNob3J0IHZhbGlkaXR5IHRpbWUgYmV0d2VlbiBBIGFuZCBCLiBCdXQsIGlmIEIgd2ls
bCBvbmx5IHJvdXRlIGZvciBhIGNlcnRhaW4gYW1vdW50IG9mIHRpbWUsIHRoZW4gdGhlIHJvdXRl
IGJldHdlZW4gQSBhbmQgQyB3aWxsIG9mIGNvdXJzZSBiZSBhZmZlY3RlZC4gSXMgaXQgYmVzdCB0
byBrbm93IGluIGFkdmFuY2UgdGhhdCB0aGVyZSdzIGEgdGltZSBsaW1pdCwgb3IganVzdCBkZWFs
IHdpdGggUkVSUnMgd2hlbiB0aGV5IGhhcHBlbj8NCg0KDQoNCldpdGggcmVnYXJkIHRvIHRoZSBh
Y2tub3dsZWRnZW1lbnRzLCB0aGUgcHJvYmxlbSAod2l0aCByZWdhcmQgdG8gc2VjdXJpdHkpIGNv
bWVzIGZyb20gdHJ5aW5nIHRvIGRvIHR3byBqb2JzIHdpdGggdGhlIHNhbWUgbWVzc2FnZSAtIGVu
ZCB0byBlbmQgcm91dGUgYWR2ZXJ0aXNlbWVudCBhbmQgaG9wIGJ5IGhvcCBhY2tub3dsZWRnZW1l
bnQuIEkgdW5kZXJzdGFuZCB0aGUgcmVhc29ucyAtIHNhdmluZyBieXRlcyBhbmQgbWVzc2FnZSB0
eXBlcy4gKEkgd291bGQgaGF2ZSB0byBzdHVkeSB0aGUgcHJvdG9jb2wgcmVhbGx5IGhhcmQgdG8g
aWRlbnRpZnkgaWYgYW55IG1lc3NhZ2UgdHlwZXMgY2FuIGJlIGZvbGRlZCB0b2dldGhlciBhbmQg
cmVjb2duaXNlZCBieSBjb250ZW50IHJhdGhlciB0aGFuIHR5cGUgZWZmaWNpZW50bHkuIFRoaXMg
SSBkbyBub3QgZXhwZWN0IHRvIGRvLikgQWdhaW4gYSB0cmFkZW9mZi4gVGhpcyBvbmUgaXMgaW4g
ZGlzY3Vzc2lvbiBzcGFjZSwgdGhvdWdoIHRoYXQgbmVlZHMgcGVvcGxlIHdobyB1bmRlcnN0YW5k
IGJvdGggc2lkZXMgb2YgdGhlIGlzc3VlLCBpbmNsdWRpbmcgdGhlIGRldGFpbHMgb2YgdGhlIGJp
ZGlyZWN0aW9uYWxpdHkgbWVjaGFuaXNtLiBPZiBjb3Vyc2UsIGFzIGhhcyBiZWVuIHNhaWQsIHdl
IG5lZWQgb25lIG9mIHRob3NlLg0KDQpJIGhhdmVuJ3QgZmluaXNoZWQgbXkgcmV2aWV3IG9mIHRo
ZSBsYXRlc3QgZHJhZnQsIGFuZCBJIGRvbid0IGdldCB0aGUgbmVjZXNzaXR5IG9mIEFja1JlcSBh
bmQgdGhlIGNvcnJlc3BvbmRpbmcgbXVsdGljYXN0IFJSRVAgeWV0Lg0KSWYgcG9zc2libGUsIHRo
aXMgIm9wdGlvbmFsIiBmaWVsZCBzaG91bGQgYmUgYXZvaWRlZC4NCg0KDQpUbyBnaXZlIGFuIG92
ZXJ2aWV3IG9mIEFja1JlcSBhbmQgUlJFUDoNClNpbmNlIEFPRFZ2MiByZXF1aXJlcyBiaWRpcmVj
dGlvbmFsIGxpbmtzLCB0aGlzIGlzIHRoZSB3YXkgdG8gZGV0ZXJtaW5lIGlmIGEgbGluayBpcyBi
aWRpcmVjdGlvbmFsLg0KQS0tLS1CLS0tLUMNCg0KMSkgQSBzZW5kcyBSUkVRLCBCIGZvcndhcmRz
IGl0LCBDIHJlY2VpdmVzIHRoZSBSUkVRLiBCIGFuZCBDIGJvdGggaW5zdGFsbCBhIHJvdXRlIHRv
IE9yaWdBZGRyIGJ1dCB0aGV5IGRvbnQgeWV0IGtub3cgaWYgaXQncyB2YWxpZCBiZWNhdXNlIHRo
ZXkgZG9udCBrbm93IGlmIHRoZSBsaW5rIHRvIHRoZWlyIG5leHQgaG9wIGlzIGF2YWlsYWJsZSBp
biB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24uDQoyKSBDIGNyZWF0ZXMgdGhlIFJSRVAuIFNpbmNlIGl0
IGRvZXNudCBrbm93IGlmIHRoZSBsaW5rIHRvIEIgaXMgYmlkaXJlY3Rpb25hbCwgaXQgaW5jbHVk
ZXMgdGhlIEFja1JlcSAoYW4gYWRkcmVzcyB0byBpbmRpY2F0ZSB0aGF0IGl0IGV4cGVjdHMgdG8g
cmVjZWl2ZSBhIFJSRVBfQWNrIGZyb20gQikuDQozKSBCIHJlY2VpdmVzIHRoZSBSUkVQLCBpbnN0
YWxscyBhIHJvdXRlIHRvIFRhcmdBZGRyIGFuZCBtYXJrcyBpdCBhcyB2YWxpZCwgc2luY2UgaXQg
a25vd3MgdGhlIGxpbmsgdG8gQyBpcyBiaWRpcmVjdGlvbmFsLCBiZWNhdXNlIHRoZSBSUkVRIHdl
bnQgaW4gb25lIGRpcmVjdGlvbiBhbmQgdGhlIFJSRVAgY2FtZSBpbiB0aGUgb3RoZXIuIEIgYWxz
byBzZW5kcyB0aGUgUlJFUF9BY2sgdG8gQyBhbmQgZm9yd2FyZHMgdGhlIFJSRVAgdG8gQSAoYW5k
IG1pZ2h0IGNoYW5nZSB0aGUgbWVzc2FnZSB0byBpbmRpY2F0ZSBpdHMgb3duIEFja1JlcSAtIGll
IHRoYXQgaXQgcmVxdWlyZXMgYW4gYWNrIGZyb20gQSkuDQo0KSBDIHJlY2VpdmVzIHRoZSBSUkVQ
X0FjayBmcm9tIEIsIGFuZCB0aGVyZWZvcmUga25vd3MgdGhhdCBCIHJlY2VpdmVkIHRoZSBSUkVQ
LCB0aGVyZWZvcmUgdGhlIGxpbmsgaXMgYmlkaXJlY3Rpb25hbC4gQyBjYW4gdGhlbiBtYXJrIGl0
cyByb3V0ZSB0byBPcmlnQWRkciBhcyB2YWxpZC4NCjUpIFNpbWlsYXJseSwgQSByZWNlaXZlcyB0
aGUgUlJFUCwgaW5zdGFsbHMgdGhlIHJvdXRlIHRvIFRhcmdBZGRyIGFuZCBzZW5kcyBhbiBSUkVQ
X0FjayB0byBCLg0KNikgQiByZWNlaXZlcyB0aGUgUlJFUF9BY2sgYW5kIG1hcmtzIGl0cyByb3V0
ZSB0byBPcmlnQWRkciBhcyB2YWxpZC4NCg0KQWx0ZXJuYXRpdmVseSwgaW4gc3RlcCAyLCBpZiBD
IGtub3dzIHRoZSBsaW5rIHRvIEIgaXMgYmlkaXJlY3Rpb25hbCAocGVyaGFwcyBmcm9tIHNvbWUg
ZWFybGllciByb3V0ZSBkaXNjb3ZlcnkpLCBpdCBkb2VzbnQgbmVlZCB0byBwdXQgdGhlIEFja1Jl
cSBpbiB0aGUgUlJFUC4gVGhlbiBpbiBzdGVwIDMsIHNpbmNlIEIgZG9lc250IGtub3cgaWYgdGhl
IGxpbmsgdG8gQSBpcyBiaWRpcmVjdGlvbmFsLCBpdCBjaGFuZ2VzIHRoZSBtZXNzYWdlIHRvIGFk
ZCB0aGUgQWNrUmVxIGFkZHJlc3MsIGluIG9yZGVyIHRvIGdldCBhbiBSUkVQX0FjayBmcm9tIEEu
DQpJZiB3ZSB3YW50IHRvIGF2b2lkIGNoYW5naW5nIHRoZSBtZXNzYWdlLCB3ZSdsbCBuZWVkIHRv
IGxvb2sgYXQgZm9yd2FyZGluZyB0aGUgUlJFUCBhcy1pcywgYW5kIGNyZWF0aW5nIGEgc2Vjb25k
IG1lc3NhZ2UgdG8gc29saWNpdCBhbiBSUkVQX0FjaywgaW4gb3JkZXIgdG8gdmVyaWZ5IHRoYXQg
dGhlIGxpbmsgaXMgYmlkaXJlY3Rpb25hbCBiZWZvcmUgbWFya2luZyB0aGUgcm91dGUgdG8gT3Jp
Z0FkZHIgYXMgdmFsaWQuDQpLaW5kIHJlZ2FyZHMsDQpWaWN0b3JpYS4NCg0KDQpyZWdhcmRzDQoN
CkppYXppDQoNCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVu
Z2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVsOiUyQjQ0JTIwJTI4
MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxt
YWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxp
ZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93
LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6
Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j
ZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJl
Z2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXks
IEdVMiA3WVANCg0KRnJvbTogVmljdG9yaWEgTWVyY2llY2EgW21haWx0bzp2bWVyY2llY2EwQGdt
YWlsLmNvbTxtYWlsdG86dm1lcmNpZWNhMEBnbWFpbC5jb20+XQ0KU2VudDogMjMgQXByaWwgMjAx
NiAxMDo1NQ0KVG86IENocmlzdG9waGVyIERlYXJsb3ZlDQpDYzogaWV0ZkB0aG9tYXNjbGF1c2Vu
Lm9yZzxtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZz47IERlYXJsb3ZlLCBDaHJpc3RvcGhl
ciAoVUspOyBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdA0KDQpTdWJqZWN0OiBS
ZTogW21hbmV0XSBNZXNzYWdlIGludGVncml0eSBhbmQgbWVzc2FnZSBtdXRhYmlsaXR5ICh3YXMg
UkU6IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEgY291cGxlIG9mIGJpZyB0
aWNrZXQgSXRlbXMpDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRl
cyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwg
cGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ug
c2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHku
DQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBv
dXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQu
ZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50
cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMs
IHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVt
cy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBX
aXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KSGkgQ2hyaXMsDQoNClRoZXNlIGhhdmUg
Ym90aCBiZWVuIGluIHRoZSBkcmFmdCBpbiBzb21lIGZvcm0gc2luY2UgYmVmb3JlIEkgZ290IGlu
dm9sdmVkLi4uIGJ1dCBJJ2xsIGRvIG15IGJlc3QgdG8gZXhwbGFpbi4NCg0KLSBGb3IgVmFsaWRp
dHkgVGltZSwgaXRzIGEgd2F5IHRvIGFkdmVydGlzZSB0aGF0IHlvdSB3b3VsZCBvbmx5IHN1cHBv
cnQgdGhlIHJvdXRlIGNvbnRhaW5lZCBpbiB0aGUgbWVzc2FnZSBmb3IgYSBjZXJ0YWluIHBlcmlv
ZCBvZiB0aW1lLiBUaGUgb3JpZ2luYXRvciBtaWdodCB1c2UgdGhpcywgYnV0IHRoZSBkcmFmdCB3
YXMgd3JpdHRlbiB0byBhbGxvdyBhbnkgaW50ZXJtZWRpYXRlIG5vZGUgdG8gYmUgYWJsZSB0byBh
ZGQgaXQgb3IgdXBkYXRlIGl0IHRvby4gVGhlIHJvdXRlIGNyZWF0ZWQgaW4gdGhlIExvY2FsIFJv
dXRlIFNldCBoYXMgYW4gZXhwaXJhdGlvbiB0aW1lIGFzc29jaWF0ZWQgd2l0aCBpdCwgYmFzZWQg
b24gdGhlIHJlY2VpdmVkIHZhbGlkaXR5IHRpbWUuDQotIEZvciB0aGUgQWNrUmVxIGFkZHJlc3Ms
IGl0cyBzbyB0aGF0IHlvdSBjYW4gYWRkIGludG8gYSBSUkVQIGEgcmVxdWVzdCBmb3IgYW4gYWNr
bm93bGVkZ2VtZW50LCBzbyB0aGF0IHlvdSBkb24ndCBoYXZlIHRvIGhhdmUgYSBkaWZmZXJlbnQg
bWVzc2FnZSB0eXBlIGFsdG9nZXRoZXIgZm9yIHdvcmtpbmcgb3V0IHdoZXRoZXIgbGlua3MgdG8g
bmVpZ2hib3JzIGFyZSBiaWRpcmVjdGlvbmFsLCBhbmQgYWxzbywgc2luY2UgeW91IG9ubHkgY2Fy
ZSBhYm91dCBiaWRpcmVjdGlvbmFsaXR5IG9uIHJvdXRlcyB0aGF0IGFyZSBiZWluZyBzZXQgdXAs
IHlvdSBkb250IG5lZWQgdG8gY29uc3RhbnRseSBtb25pdG9yIGFsbCBuZWlnaGJvcnMuDQoNCg0K
SW4gb3JkZXIgdG8gYXZvaWQgdGhlIHBvdGVudGlhbCBBY2tSZXEtcmVsYXRlZCBjaGFuZ2VzIHRv
IGVhY2ggbWVzc2FnZSwgbWF5YmUgd2UgZG8gbmVlZCB0byBpbnRyb2R1Y2UgYSBkaWZmZXJlbnQg
bWVzc2FnZSBzcGVjaWZpY2FsbHkgZm9yIHRoaXMuIFdlIGNvdWxkIG1heWJlIHVzZSBSUkVQX0Fj
ayB0byBib3RoIHJlcXVlc3QgYW5kIGFja25vd2xlZGdlPyBJdCBtZWFucyBhbiBleHRyYSBtZXNz
YWdlIG9mIGNvbnRyb2wgdHJhZmZpYyB0aGF0IG5lZWRzIHRvIGJlIHNlbnQsIG1heWJlIG9uZSBl
eHRyYSBtZXNzYWdlIHBlciBob3Agb24gdGhlIHBhdGggb2YgYSBSUkVQLCBidXQgaXQgY291bGQg
c3RpbGwgYmUgbGltaXRlZCB0byBuZWlnaGJvcnMgd2hpY2ggaGF2ZSBwYXJ0aWNpcGF0ZWQgaW4g
dGhlIHJvdXRlIGRpc2NvdmVyeSByYXRoZXIgdGhhbiBtb25pdG9yaW5nIGFsbCBuZWlnaGJvcnMg
YXQgYWxsIHRpbWVzLg0KDQpUaGlzIG1lc3NhZ2UgY291bGQgbWF5YmUgYWxzbyBpbmNsdWRlICJJ
J20gaGFwcHkgdG8gcm91dGUgYW55d2hlcmUgZm9yIGEgY2VydGFpbiBhbW91bnQgb2YgdGltZSIs
IHNvcnQgb2YgbGlrZSB3aWxsaW5nbmVzcyBpbiBPTFNSL09MU1J2Mi4gU28gaW5zdGVhZCBvZiBo
YXZpbmcgYSB2YWxpZGl0eSB0aW1lIHBlciByb3V0ZSwgaXRzIGEgdmFsaWRpdHkgdGltZSBwZXIg
bmVpZ2hib3IuIFRoZW4sIGZvciBSUkVRIGFuZCBSUkVQLCBvbmx5IHRoZSBtZXRyaWMgdmFsdWUg
d291bGQgY2hhbmdlIGluIHRyYW5zaXQsIGFzIGRpc2N1c3NlZC4gSG93ZXZlciwgdGhhdCBsZWFk
cyB0byBzb21lIGlzc3VlcyB3aXRoIGRlY2lkaW5nIHdoYXQgYSByb3V0ZSdzIGV4cGlyYXRpb24g
dGltZSBpcy4gWW91IG1pZ2h0IGtub3cgaG93IGxvbmcgdGhlIG5leHQgaG9wIHJvdXRlciBpcyB2
YWxpZCBmb3IsIGJ1dCB3aGF0IGlmIGEgcm91dGVyIGJleW9uZCB0aGF0LCB3aGljaCB3YXMgYWxz
byBwYXJ0IG9mIHRoZSByb3V0ZSwgaGFkIGEgbG93ZXIgdmFsaWRpdHkgdGltZT8gWW91IGNvdWxk
bid0IGRldGVybWluZSB0aGUgcmVhbCB2YWxpZGl0eSB0aW1lLiBEbyB3ZSByZW1vdmUgdGhlIHJv
dXRlIGV4cGlyYXRpb24gdGltZSBhbHRvZ2V0aGVyIHRvIGF2b2lkIHRoaXMgaXNzdWU/IEluIHdo
aWNoIGNhc2UsIHdlIHdvdWxkIGhhdmUgdG8gcmVseSBvbiBSRVJSIG1lc3NhZ2VzIGJlaW5nIHNl
bnQgZm9yIHJvdXRlcyB3aGljaCBiZWNvbWUgaW52YWxpZCB3aGVuIHRoZSBuZWlnaGJvcidzIHZh
bGlkaXR5IHRpbWUgaGFzIGV4cGlyZWQ/IFNvIG5laWdoYm9yIHZhbGlkaXR5IHRpbWUgZXhwaXJh
dGlvbiBpcyB0cmVhdGVkIHRoZSBzYW1lIGFzIGEgbGluayBicmVhay4NCg0KV2hhdCBkbyB5b3Ug
dGhpbms/DQoNCktpbmQgcmVnYXJkcywNClZpY3RvcmlhLg0KDQoNCg0KDQoNCg0KT24gU2F0LCBB
cHIgMjMsIDIwMTYgYXQgMTowOSBBTSwgQ2hyaXN0b3BoZXIgRGVhcmxvdmUgPGNocmlzQG1uZW1v
c3luZS5kZW1vbi5jby51azxtYWlsdG86Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrPj4gd3Jv
dGU6DQpQcmV0dHkgbXVjaCBhbGwgb2YgdGhlIGRpc2N1c3Npb24gaGFzIGJlZW4gYXNzdW1pbmcg
b25seSBhIG1ldHJpYyB2YWx1ZSBjaGFuZ2UuIFdpdGggbXVsdGlwbGUgdGhpbmdzIGNoYW5naW5n
IG1hbnkgb2YgdGhlIGlkZWFzIGdvIG91dCBvZiB0aGUgd2luZG93LiBUaGF0IHJlaW5mb3JjZXMg
dGhlIHBvaW50IGFib3V0IG5vdCBtYWtpbmcgc3BlY2lmaWNhdGlvbnMgbm93IHRoYXQgbWlnaHQg
dHVybiBvdXQgdG8gYmUgd3JvbmcgZm9yIElDVnMuDQoNCklnbm9yaW5nIGhvdyB0aGlzIG1pc3Vu
ZGVyc3RhbmRpbmcgaGFwcGVuZWQsIEknbGwgc3RhcnQgYnkgYXNraW5nIHdoeS4gTWV0cmljIGNo
YW5naW5nIEkgdW5kZXJzdGFuZC4gV2h5IHRoZSBvdGhlciB0d28/ICh0aGVyZSdzIGEgcGFydGlh
bCBleHBsYW5hdGlvbiBvZiBvbmUpLiBXaGF0IGFsdGVybmF0aXZlcyBoYXZlIHBlb3BsZSBpbXBs
ZW1lbnRlZCBpbiBjb21wYXJhYmxlIHByb3RvY29scz8NCg0KLS0NCkNocmlzdG9waGVyIERlYXJs
b3ZlDQpjaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb208bWFpbHRvOmNocmlzdG9waGVyLmRl
YXJsb3ZlQGdtYWlsLmNvbT4gKGlQaG9uZSkNCmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51azxt
YWlsdG86Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrPiAoaG9tZSkNCg0KT24gMjMgQXByIDIw
MTYsIGF0IDAwOjI2LCBWaWN0b3JpYSBNZXJjaWVjYSA8dm1lcmNpZWNhMEBnbWFpbC5jb208bWFp
bHRvOnZtZXJjaWVjYTBAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBhbGwsDQoNCkNvbnRpbnVlZCBp
biB0aGlzIHRocmVhZCBiZWNhdXNlIHRoZSBvdGhlciBvbmUgc2VlbXMgdG8gYmUgbW9yZSBhYm91
dCBUTFYgdHlwZXMgYW5kIG1ldHJpYyB0eXBlIG51bWJlcnMsIHdoZXJlYXMgdGhpcyBpcyBhYm91
dCByZWdlbmVyYXRpb24vZm9yd2FyZGluZy4NCg0KVG8gcmVjYXAsIGluIHRoZSBjdXJyZW50IGRy
YWZ0LCB0aGVyZSBhcmUgMyB0aGluZ3MgdGhhdCBtaWdodCBjaGFuZ2UgYXQgZWFjaCBob3A6DQot
IHRoZSBtZXRyaWMgdmFsdWUgKGhhcHBlbnMgaW4gUlJFUSBhbmQgUlJFUCksDQotIGFkZGluZy9j
aGFuZ2luZyBWYWxpZGl0eSBUaW1lIHVzaW5nIHRoZSBWYWxpZGl0eSBUaW1lIFRMViAoY2FuIGhh
cHBlbiBpbiBSUkVRIGFuZCBSUkVQKSwNCi0gYWRkaW5nIGFuIGFkZHJlc3MgKGFuZCBjb3JyZXNw
b25kaW5nIHZhbHVlIGluIHRoZSBBZGRyZXNzVHlwZSBUTFYgdG8gaW5kaWNhdGUgaG93IHRvIGlu
dGVycHJldCB0aGUgYWRkcmVzcykgdG8gaW5kaWNhdGUgdGhlIGFkZHJlc3MgZnJvbSB3aGljaCBh
biBSUkVQX0FjayBpcyBleHBlY3RlZCwgdG8gYWNjb21wbGlzaCB0aGUgYmlkaXJlY3Rpb25hbGl0
eSBjaGVjayAoY2FuIGhhcHBlbiBpbiBSUkVQKS4NCg0KSWYgd2UgZGVmaW5lIGEgY2VydGFpbiBw
b3J0aW9uIG9mIHRoZSBtZXNzYWdlIGFzIGltbXV0YWJsZSBhbmQgaW5jbHVkZSB0aGUgSUNWIHRv
IHZlcmlmeSB0aGF0IHBhcnQsIGVuZCB0byBlbmQ6DQotIFRoZSBtZXRyaWMgdmFsdWUgd291bGQg
YmUgZXhjbHVkZWQgZnJvbSB0aGUgSUNWIHNpbmNlIGl0IG5lZWRzIGNoYW5naW5nIGF0IGVhY2gg
aG9wLg0KLSBXb3VsZCBhZGRpbmcgYSBWYWxpZGl0eSBUaW1lIFRMViBhdCBhbiBpbnRlcm1lZGlh
dGUgaG9wIGJlIGFjY2VwdGFibGU/IFRoZSB3aG9sZSBUTFYgY291bGQgYmUgcmVtb3ZlZCBpbiBv
cmRlciB0byBjYWxjdWxhdGUgdGhlIElDVj8NCi0gV291bGQgYWRkaW5nIGFuIGFkZHJlc3MgY2F1
c2UgaXNzdWVzIGZvciB0aGUgSUNWLCBiZWNhdXNlIGl0J3MgaW4gdGhlIGFkZHJlc3MgYmxvY2s/
IENvdWxkIHRoZSBydWxlIGJlICJpZiBpdCBjb250YWlucyBhbiBBY2tSZXEgYWRkcmVzcywgcmVt
b3ZlIGl0IChhbmQgdGhlIGNvcnJlc3BvbmRpbmcgdmFsdWUgaW4gdGhlIEFkZHJlc3NUeXBlIFRM
ViksIGJlZm9yZSBjaGVja2luZyB0aGUgSUNWIiwgaXMgdGhhdCBPSz8gT3Igd291bGQgd2UgbmVl
ZCB0byBhdm9pZCB0b3VjaGluZyB0aGUgSUNWJ2VkIHBhcnQgb2YgdGhlIG1lc3NhZ2UgYWx0b2dl
dGhlciwgbWF5YmUgcHV0IHRoZSBBY2tSZXEgYWRkcmVzcyBpbiBhIHNlcGFyYXRlIEFkZHJlc3Mg
QmxvY2ssIHdpdGggYW4gZXh0cmEgQWRkcmVzc1R5cGUgVExWIGZvbGxvd2luZyB0aGF0IGFkZHJl
c3MgYmxvY2s/IElzIHRoZXJlIGEgd2F5IHRvIGFjY29tcGxpc2ggdGhpcz8NCg0KQWxzbywgdG8g
YmUgdGhvcm91Z2gsIGRvIHdlIG5lZWQgdG8gY29uc2lkZXIgUkVSUiBtZXNzYWdlcyB3aGlsZSB3
ZSBkaXNjdXNzIHJlZ2VuZXJhdGlvbiB2cyBmb3J3YXJkaW5nPw0KLSBSRVJSIChzZW50IHdoZW4g
YSBsaW5rIGJyZWFrcykgaXMgYSB3YXkgb2Ygc2F5aW5nICJJJ3ZlIGxvc3QgbXkgcm91dGUgc28g
SSdtIHRlbGxpbmcgb3RoZXJzIiBhbmQgInlvdSB3ZXJlIG15IG5leHQgaG9wLCBzbyBub3cgSSd2
ZSBhbHNvIGxvc3QgbXkgcm91dGUsIEknbGwgdGVsbCBvdGhlcnMiLCBldGMuIEl0J3MgZ29pbmcg
dG8gYmUgdGFpbG9yZWQgYXQgZWFjaCBzdGVwIHRvIGluY2x1ZGUgdGhlIHJlbGV2YW50IHJvdXRl
cyB0aGF0IGdvdCBkZWxldGVkLCBpdCdzIG5vdCBvbmUgbWVzc2FnZSBiZWluZyBzZW50IGVuZC10
by1lbmQgbGlrZSBSUkVRIGFuZCBSUkVQIGFyZS4NCi0gSG93ZXZlciwgUkVSUiAoc2VudCB3aGVu
IGEgc291cmNlIG9mIHRyYWZmaWMgaXMgc2VuZGluZyBkYXRhIG9uIGEgcm91dGUgd2hpY2ggY29t
ZXMgdGhyb3VnaCB5b3UsIGFuZCB5b3Ugd2FudCB0byB0ZWxsIHRoZSBQYWNrZXQgU291cmNlJ3Mg
cm91dGVyIHRvIGRlbGV0ZSB0aGUgcm91dGUpIGNvdWxkIGJlIHNlZW4gYXMgYW4gZW5kLXRvLWVu
ZCBtZXNzYWdlIHdoaWNoIGFsbCBpbnRlcm1lZGlhdGUgcm91dGVycyBsZWFybiBmcm9tLCBzaW1p
bGFyIHRvIFJSRVEgYW5kIFJSRVAuIEl0IHJlcG9ydHMgb25lIHJvdXRlLCBhbmQgZG9lc24ndCBu
ZWVkIGNoYW5naW5nIGF0IGludGVybWVkaWF0ZSBob3BzLCBzbyBjb3VsZCBiZSBwcm90ZWN0ZWQg
d2l0aCBJQ1YuDQotIFdvdWxkIGl0IGJlIE9LIHRvIG9ubHkgcmVxdWlyZSBhIG1lc3NhZ2UgSUNW
IGlmIGEgUGt0U291cmNlIGFkZHJlc3Mgd2FzIGluY2x1ZGVkLCBpLmUuIHdoZW4gdGhlIG1lc3Nh
Z2UgbmVlZHMgdG8gZ28gdmlhIGEgbnVtYmVyIG9mIGludGVybWVkaWF0ZSBob3BzIHRvIFBrdFNv
dXJjZSdzIHJvdXRlcj8gQWxsIG90aGVyIFJFUlJzIGFyZSBpbnRlbmRlZCB0byBiZSBvbmUtaG9w
IG1lc3NhZ2VzLCB3aGljaCBtYXkgaW4gdHVybiBwcm9tcHQgb3RoZXIgb25lLWhvcCBtZXNzYWdl
cywgZXRjLi4uLCBhbmQgYSBwYWNrZXQgSUNWIG1pZ2h0IGJlIG1vcmUgYXBwcm9wcmlhdGU/DQoN
CktpbmQgcmVnYXJkcywNClZpY3RvcmlhLg0KDQpPbiBUaHUsIE1hciAxNywgMjAxNiBhdCA1OjI2
IFBNLCA8aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzxtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9y
Zz4+IHdyb3RlOg0KDQpPbiAxNyBNYXIgMjAxNiwgYXQgMTg6MTcsIERlYXJsb3ZlLCBDaHJpc3Rv
cGhlciAoVUspIDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVh
cmxvdmVAYmFlc3lzdGVtcy5jb20+PiB3cm90ZToNCg0KWWVzLCBJIG1lYW50IEFPRFZ2MiwgdGhh
bmtzIGZvciB0aGUgY2F0Y2guDQoNClNvIGlzIHlvdXIgKFRob21hcykgcHJvcG9zZWQgYmFzZSBz
cGVjaWZpY2F0aW9uIGEgaG9wIGNvdW50IG9ubHkgbWV0cmljPw0KDQpObywgdGhlIHdvdWxkIGJl
IHNpbGx5IGFzIGJhc2Ugc3BlY2lmaWNhdGlvbiwgZ2l2ZW4gdGhhdCBob3AgY291bnQgbW9zdGx5
IGlzIHVzZWxlc3MuDQoNCkFzIGJhc2Ugc3BlY2lmaWNhdGlvbiBJIHdvdWxkIHNpbXBseSBzYXkg
4oCcSW5jbHVkZSBhIE1ldHJpYyBUeXBlIE1lc3NhZ2UgVExWIHdpdGggYSB2YWx1ZSBmaWVsZCwg
YW5kIGEgNzE4MiBNZXNzYWdlIFRMViAmIFRpbWVzdGFtcOKAnSBhcyB3ZSBkbyBpbiBPTFNSdjIg
KHdpdGggdGhlIGFwcHJvcHJpYXRlIHZlcmJpYWdlIGFzIHRvIGdlbmVyYXRpb24gYW5kIHByb2Nl
c3NpbmcpLg0KDQpXaXRoIHRoZSBtZXNzYWdlIGdlbmVyYXRlZCBieSB0aGUgb3JpZ2luYXRvciBv
ZiB0aGUgUlJFUS9SUkVQIGFuZCAqbm90KiBkZWNvbnN0cnVjdGVkL3JlY29uc3RydWN0ZWQvcmVv
cmRlcmVkIChhcyBpcyB0aGUgcmlzayB3aXRoIOKAnHJlZ2VuZXJhdGlvbikgYWxsb3dzIGtub3dp
bmcgdGhhdCBpdCB3b3VsZCBiZSAqb25seSogdGhhdCBtZXRyaWMgZmllbGQgYmVpbmcgbW9kaWZp
ZWQgKG90aGVyIHRoYW4gaG9wIGNvdW50L2xpbWl0KSBmb3Igd2hlbiBldmVudHVhbGx5IHdyaXRp
bmcgdXAgdGhlIGV4dGVuc2lvbi4NCg0KKEFjdHVhbGx5IGRvZXNu4oCZdCB0aGUgY3VycmVudCBz
cGVjaWZpY2F0aW9uIG9ubHkgZGVmaW5lIGhvcCBjb3VudCwgb3IgaGFzIHRoYXQgY2hhbmdlZCBp
biBsYXRlc3QgZHJhZnQ/KQ0KDQpOby4gVGhhdCBpcyBvbmUgb2YgdGhlIGlzc3VlcyBJIHJhaXNl
IGluIG15IG9yaWdpbmFsLiBGb3Igc29tZSByZWFzb24sIGl0IGNpdGVzIFJGQzY1NTEsIHdoaWNo
IGlzIGEgUk9MTCBkb2N1bWVudCBhbmQgd2hpY2ggaGFzIGluIGl0cyBhYnN0cmFjdCB0aGF0Og0K
DQoNCiAgIExvdy1Qb3dlciBhbmQgTG9zc3kgTmV0d29ya3MgKExMTnMpIGhhdmUgdW5pcXVlIGNo
YXJhY3RlcmlzdGljcw0KDQogICBjb21wYXJlZCB3aXRoIHRyYWRpdGlvbmFsIHdpcmVkIGFuZCBh
ZCBob2MgbmV0d29ya3MgdGhhdCByZXF1aXJlIHRoZQ0KDQogICBzcGVjaWZpY2F0aW9uIG9mIG5l
dyByb3V0aW5nIG1ldHJpY3MgYW5kIGNvbnN0cmFpbnRzLg0KDQpJLmUuIHRoaXMgZG9jdW1lbnQg
Y2l0ZXMgYSBtZXRyaWMgZG9jdW1lbnQgd2hpY2ggY2xlYXJseSBjbGFpbXMgdG8gYmUgaW5hcHBs
aWNhYmxlIGluIGFkIGhvYyBuZXR3b3Jrcy4gSSBub3RlIHRoYXQgdGhpcyBpcyBhbm90aGVyIHRo
aW5nIEnigJl2ZSByYWlzZWQgZm9yIHllYXJzIHdpdGhvdXQgc2VlaW5nIGl0IGF0dGVtcHRlZCBy
ZXNvbHZlZC4NCg0KQmVzdCwNCg0KVGhvbWFzDQoNCg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxv
dmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxs
aWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1
IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4gIHwgIEU6IGNocmlzLmRl
YXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNv
bT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5v
bG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cu
YmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0
ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAm
IFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQ
YXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBpZXRmQHRob21hc2NsYXVz
ZW4ub3JnPG1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3JnPiBbbWFpbHRvOmlldGZAdGhvbWFz
Y2xhdXNlbi5vcmddDQpTZW50OiAxNyBNYXJjaCAyMDE2IDE3OjEwDQpUbzogRGVhcmxvdmUsIENo
cmlzdG9waGVyIChVSykNCkNjOiBMb3R0ZSBTdGVlbmJyaW5rOyBNb2JpbGUgQWQgSG9jIE5ldHdv
cmtzIG1haWxpbmcgbGlzdA0KU3ViamVjdDogUmU6IFttYW5ldF0gTWVzc2FnZSBpbnRlZ3JpdHkg
YW5kIG1lc3NhZ2UgbXV0YWJpbGl0eSAod2FzIFJFOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0x
MyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKQ0KDQoNCioqKiBXQVJOSU5H
ICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRp
b24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29u
c2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9w
ZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBS
ZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUs
IGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsv
c2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBm
ZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2Vzczxo
dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90
bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRm
Pi4NCg0KT24gMTcgTWFyIDIwMTYsIGF0IDE4OjA0LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVL
KSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh
ZXN5c3RlbXMuY29tPj4gd3JvdGU6DQoNCk9LLCBzbyB3ZSBoYXZlIGEgbWVzc2FnZSB0aGF0IG11
dGF0ZXMgYnk6DQotIE1vZGlmeWluZyBob3AgY291bnQvbGltaXQuDQotIE1vZGlmeWluZyBhIG1l
dHJpYyB2YWx1ZS4NCkFueXRoaW5nIGVsc2U/DQoNCkFzIG11dGF0aW5nIChvdGhlciB0aGFuIGhv
cCBjb3VudC9saW1pdCkgbWVzc2FnZXMgYXJlbuKAmXQgY292ZXJlZCBieSA1NDQ0IG9yIGFueSBk
ZXJpdmF0aXZlIGRvY3VtZW50IChidXQgb25seSByZWNvbW1lbmRlZCBhZ2FpbnN0LCBub3QgYmFu
bmVkKSB0aGF0IHlvdSBtYXkgbmVlZCB0byBtYWtlIHRoZSBtZXNzYWdlIG90aGVyd2lzZSBpbW11
dGFibGUgKG5vIGRlY29uc3RydWN0aW9uIGFuZCByZWJ1aWxkaW5nLCBvdGhlciB0aGFuIGd1YXJh
bnRlZWQgdW5jaGFuZ2luZykgdGhhdCB3b3VsZCBoYXZlIHRvIGJlIHNwZWNpZmllZCBieSBBT0RW
djIuIChFYXN5IHRvIHNheSwgYnV0IG5lZWRzIHNheWluZy4pDQoNCldpdGggeW91IHNvIGZhci4N
Cg0KVGhlbiB0aGF0IGluZm9ybWF0aW9uIGlzIG5vdCBpbiBhIGd1YXJhbnRlZWQgZml4ZWQgbG9j
YXRpb24gZ2l2ZW4gYnkgYSBzaW1wbGUgb2Zmc2V0LiBTbyBhbnkgc2lnbmF0dXJlIGFsZ29yaXRo
bSB0aGF0IGZpbmRzIGl0IGFuZCBpZ25vcmVzIGl0IG9yIGFnZ3JlZ2F0ZXMgb24gaXQgaXMgc3Bl
Y2lmaWMgdG8gT0xTUnYyLg0KDQpTdXJlbHkgeW91IG1lYW4gQU9EVnYyDQoNClNvIHN0YW5kYXJk
IDcxODIgSUNWcyBkb27igJl0IGRvIHRoZSBqb2IsIHlvdSB3b3VsZCBuZWVkIGFuIEFPRFZ2MiBz
cGVjaWFsaXNlZCB2YXJpYW50LiBXaGljaCBpcyB0aGUgc29ydCBvZiB0aGluZyB0aGF0IHRoZSBt
ZXNzYWdlIHNwZWNpZmljIFRMViBzcGFjZSBpcyB0aGVyZSBmb3IsIEnigJlkIGJlIHN0cm9uZ2x5
IGFnYWluc3QgYSDigJxidXQgaWdub3JlIHRoZSB2YWx1ZSBvZiB0aGlzIHNwZWNpZmljIFRMViBz
aG91bGQgaXQgb2NjdXLigJ0gYmVpbmcgaW4gdGhlIGdlbmVyYWwgc3BhY2UuIEhvd2V2ZXIgaXQg
Y2FuIGVhc2lseSBiZSBkZWZpbmVkIGJ5IHJlZmVyZW5jZSB0byA3MTgyICjigJx0aGlzIFRMViBp
cyBsaWtlIHRoYXQgVExWLCBleGNlcHQgaWYgYW4gWCBUTFYgaXMgcHJlc2VudCwgc2V0IGl0cyB2
YWx1ZSBmaWVsZCB0byB6ZXJv4oCdKS4NCg0KTWVzc3ksIGJ1dCBjb3VsZCB3b3JrLg0KDQpOb3Qg
dGhhdCBtZXNzeSwgYWN0dWFsbHksIGFsdGhvdWdoIGNsZWFybHkgbm90IGFzIG5pY2UgYXMg4oCc
Zml4ZWQgb2Zmc2V04oCdLg0KDQpUaGF0IHNhaWQsIEkgYW0gYXJndWluZyBmb3IgdGhlIGJhc2Ug
c3BlYyBiZWluZzoNCg0KICAgICAgICAgICAg4oCcbWFrZSB0aGUgbWVzc2FnZSBvdGhlcndpc2Ug
aW1tdXRhYmxlIChubyBkZWNvbnN0cnVjdGlvbiBhbmQgcmVidWlsZGluZywgb3RoZXINCiAgICAg
ICAgICAgICB0aGFuIGd1YXJhbnRlZWQgdW5jaGFuZ2luZynigJ0gd2hpY2ggaXMgYWZmb3JkZWQg
YnkgZm9yd2FyZGluZw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArDQoN
CiAgICAgICAgICAgIFJGQzcxODIgVGltZXN0YW1wcyBhbmQgSUNWcy4NCg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgKw0KDQogICAgICAgICAgICBSRkM3MTgzIHN0eWxlIHRl
eHQgYnJpbmdpbmcgaXQgYWxsIHRvZ2V0aGVyLg0KDQpUaGUg4oCcYWdncmVnYXRlZCBzaWduYXR1
cmVzIGFyb3VuZCBtdXRhYmxlIGZpZWxk4oCdIHdvdWxkIHZlcnkgYmUgYW4gZXhwZXJpbWVudGFs
IGV4dGVuc2lvbi4NCg0KV2hhdCBJIG9iamVjdCB0byBpcywgaWYgdGhlIGJhc2Ugc3BlYyBzcGVj
aWZpY2FsbHkgcmVuZGVycyBzdWNoIGV4dGVuc2lvbnMgaW1wb3NzaWJsZQ0KDQoNCg0KLS0NCkNo
cmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVt
cyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN
ClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+
ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxv
dmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBD
aGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3Nl
eCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5j
b20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3Rl
cmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBT
dXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTog
TG90dGUgU3RlZW5icmluayBbbWFpbHRvOmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRlXQ0K
U2VudDogMTcgTWFyY2ggMjAxNiAxNjo0OA0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp
DQpDYzogaWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzxtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9y
Zz47IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0DQpTdWJqZWN0OiBSZTogW21h
bmV0XSBNZXNzYWdlIGludGVncml0eSBhbmQgbWVzc2FnZSBtdXRhYmlsaXR5ICh3YXMgUkU6IGRy
YWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEgY291cGxlIG9mIGJpZyB0aWNrZXQg
SXRlbXMpDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9t
IG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5l
ciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxk
IGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3Ig
aW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9y
IGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJh
ZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQl
MjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFz
ZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20v
aG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIw
U3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KSGkgYWxsLA0KDQpBbSAxNy4wMy4yMDE2IHVtIDE3
OjQ0IHNjaHJpZWIgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgPGNocmlzLmRlYXJsb3ZlQGJh
ZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4+Og0KDQpH
b29kIHBvaW50IGFib3V0IHdoZXRoZXIgeW91IGp1c3QgcGFzcyBvbiBvbmUgY29zdCBvciBhIHNl
dCBvZiBjb3N0cy4gQXMgSSBzYWlkLCBub3QgbG9va2VkIGF0IGRldGFpbHMgLSBJIHdpbGwsIHdo
ZW4gdGltZSBwZXJtaXRzLiBPbmUgY29zdCBpcyBtdWNoIGVhc2llciwgYW5kIHllcywgaXQgcmVk
dWNlcyB0aGUgZml4ZWQgc2l6ZSBhZ2dyZWdhdGVkIHNpZ25hdHVyZXMgcHJvYmxlbSB0byDigJxq
dXN04oCdIG9uZSBvZiBjb21wdXRhdGlvbmFsIGxvYWQuDQoNCkZvciB0aGUgcmVjb3JkLCBUaG9t
YXPigJkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0OyB0aGUgY29zdCBpcyBvbmUgYWdncmVnYXRl
ZCB2YWx1ZS4NCg0KQmVzdCByZWdhcmRzLA0KTG90dGUgU3RlZW5yYmluaw0KDQoNCi0tDQpDaHJp
c3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMg
QXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpU
OiAgKzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0PiAg
fCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3Zl
QGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hl
bG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXgg
Q00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29t
L2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJl
ZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3Vy
cmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IGll
dGZAdGhvbWFzY2xhdXNlbi5vcmc8bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmc+IFttYWls
dG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZ10NClNlbnQ6IDE3IE1hcmNoIDIwMTYgMTY6MzgNClRv
OiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IE1vYmlsZSBBZCBIb2MgTmV0d29ya3Mg
bWFpbGluZyBsaXN0DQpTdWJqZWN0OiBSZTogTWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2Ug
bXV0YWJpbGl0eSAod2FzIFJFOiBbbWFuZXRdIGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJl
dmlldyAtIGEgY291cGxlIG9mIGJpZyB0aWNrZXQgSXRlbXMpDQoNCg0KKioqIFdBUk5JTkcgKioq
DQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwg
ZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRl
ciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBh
bnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBG
bGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xp
Y2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1
cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwg
dGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6
Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdo
dHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0K
DQpPbiAxNyBNYXIgMjAxNiwgYXQgMTc6MzAsIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxj
aHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lz
dGVtcy5jb20+PiB3cm90ZToNCg0KSSBhcHByZWNpYXRlIFRob21hc+KAmXMgY29tbWVudHMgYWJv
dXQgdGhlIGxpbWl0YXRpb25zIG9mIG1lc3NhZ2UgcmVnZW5lcmF0aW9uLCBidXQgSSB3b3VsZCBi
ZSBhIGJpdCBsZXNzIGFic29sdXRlLg0KDQpUaGUgaXNzdWVzIG92ZXIgZW5kIHRvIGVuZCBhdXRo
ZW50aWNhdGlvbiBhbmQgbW9yZSBhZHZhbmNlZCBzaWduYXR1cmVzIGFyZSB2YWxpZC4gSSBuZWVk
IHRvIHJlYWQgdGhlIGdpdmVuIHJlZmVyZW5jZSBvbiBhZ2dyZWdhdGUgc2lnbmF0dXJlcyB0byBp
bmNyZWFzZSBteSBrbm93bGVkZ2UgKHRoYW5rcyBmb3IgaXQpLCBidXQgbXkgdW5kZXJzdGFuZGlu
ZyBvZiB0aGUgcG9zc2liaWxpdGllcyBpbiB0aGlzIGZpZWxkIG1heSBvZmZlciBhIHNvbHV0aW9u
IHRvIHRoZSBwcm9ibGVtLCBidXQgd2l0aCBzb21lIG90aGVyIGlzc3VlcyAocG9zc2libHkgaW5j
bHVkaW5nIGEgbmV3IHR5cGUgb2YgVExWKS4NCg0KQnV0IHRoZSBob3AgY291bnQvbGltaXQgcG9p
bnQgSSBkb27igJl0IGZ1bGx5IGFncmVlIHdpdGgsIHlvdSBjYW4gcmVnZW5lcmF0ZSB3aXRoIGFu
IGluY3JlbWVudGVkL2RlY3JlbWVudGVkIGNvdW50L2xpbWl0LCB3aGljaCBsZWF2ZXMgdGhlIGFi
aWxpdHkgdG8gcHJldmVudCBtZXNzYWdlcyBwcm9wYWdhdGluZyBpbmRlZmluaXRlbHksIGluY2x1
ZGluZyBleHBhbmRpbmcgcmluZyBzZWFyY2hlcywgYW5kIHJldGFpbnMgdGhlIGFiaWxpdHkgdG8g
dXNlIFJGQyA1NDk3IGludGVydmFsIGFuZCB2YWxpZGl0eSB0aW1lcyB0aGF0IG1pZ2h0IGJlIHVz
ZWZ1bCB3aXRoIGFuIGV4cGFuZGluZyByaW5nIHNlYXJjaCAob3IgbWlnaHQgbm90KS4NCg0KQnV0
IHRoZSBrZXkgaXNzdWUgaXMgdGhhdCBBT0RWdjIgd2FudHMgdG8gYWNjdW11bGF0ZSBtZXRyaWNz
LiBJIHN0aWxsIGhhdmVu4oCZdCBnb3QgdG8gdGhlIGJvdHRvbSBvZiBtYW55IGRldGFpbHMgaGVy
ZSwgYnV0IGxldOKAmXMgZm9yIHRoZSBtb21lbnQganVzdCBjb25zaWRlciB0aGF0IGNvbmNlcHR1
YWxseS4NCg0KSXTigJlzIGhhcmQgdG8gaGFuZGxlIGVuZCB0byBlbmQuIENoYXJsaWXigJlzIGRy
YWZ0IGF0dGVtcHRzIHRvIGRvIGFuIGVuZCB0byBlbmQgb2Ygc29tZSBpbmZvcm1hdGlvbiwgbm90
IHRoaXMgaW5mb3JtYXRpb24uIEnigJltIG5vdCBzdXJlIGlmIHRoYXTigJlzIHVzZWZ1bCAoYW5k
IHRoZSBzcGVjaWFsaXNlZCBmb3JtYXQgaXMgYmV0dGVyIGF2b2lkZWQgaWYgcG9zc2libGUpLiBP
dGhlciBhcHByb2FjaGVzIGFyZSBob3AgYnkgaG9wIChtaWdodCBhcyB3ZWxsIHVzZSBwYWNrZXQg
c2lnbmF0dXJlcykgYW5kIHNoYXJlZCBrZXkgKG1pZ2h0IGFzIHdlbGwgZ28gaG9wIGJ5IGhvcCku
IFBhaXJ3aXNlIHNpZ25hdHVyZXMgZm9yIGVhY2ggcGFpciBvZiByb3V0ZXJzIEnigJltIGRpc2Nv
dW50aW5nIGFzIHNjYWxpbmcgdGVycmlibHkuIEluIHRoZSBpbnRlcmVzdHMgb2YgY29tcGxldGVu
ZXNzIGxldOKAmXMgbWVudGlvbiBub3QgYWNjdW11bGF0aW5nIG1ldHJpY3MsIHdoaWNoIHB1dHMg
dXMgYmFjayB0byBob3AgY291bnQgYW5kIHRoYXTigJlzIG5vdCBpZGVhbCBlaXRoZXIuDQoNCkkg
ZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhbiBpZGVhbCBzb2x1dGlvbi4gKEkgbGlrZSBpZGVhcyBJ
4oCZdmUgc2VlbiBhYm91dCBhZ2dyZWdhdGluZywgYnV0IHRoYXQgaGFzIHNvbWUgaXNzdWVzIG9m
IGl0cyBvd24sIGV2ZW4gYXBhcnQgZnJvbSBjb21wdXRhdGlvbmFsIGxvYWQuKSBJ4oCZZCBsb3Zl
IHRvIGJlIHByb3ZlZCB3cm9uZyAtIHNvbWVvbmUgd2l0aCB0aGUgcGVyZmVjdCBzb2x1dGlvbiB0
byBjb21lIGFsb25nLg0KDQpXaGljaCBtZWFucyB0aGF0IGVpdGhlciB3ZSBtYWtlIGFuIGFyYml0
cmFyeSBjaG9pY2UgLSB3aGljaCB3aWxsIGJlIGRpc2FncmVlZCB3aXRoLCBidXQgbmVlZHMgZGlz
Y3Vzc2luZyBmaXJzdCAtIG9yIGNyZWF0ZSBzb21ldGhpbmcgZmxleGlibGUuIFVuZm9ydHVuYXRl
bHkgZmxleGlibGUgaW4gdGhhdCByZWdhcmQgY29uc3RyYWlucyBpbiBvdGhlcnMsIGUuZy4gc29t
ZSAobWFueT8gbW9zdD8pIGFnZ3JlZ2F0aW5nIHNpZ25hdHVyZXMgbmVlZCBmaXhlZCBkYXRhIHNp
emVzICh3aGljaCB3ZSBjYW4gZG8gYnkgZGVmaW5pbmcgYSBUTFYgdGhhdCDigJxmaWxscyB1cOKA
nSB3aXRoIGhvcCBjb3VudCwgYnV0IHRoYXQgaGFzIGEgY29zdCB0b28pLg0KDQpJIGhhdmUgYmVl
biB0b2xkIGJ5IHBlb3BsZSBtdWNoIG1vcmUgd2VsbCB2ZXJzZWQgaW4gdGhpcyB0aGFuIEkgaW4g
Y3J5cHRvbG9neSwgdGhhdCB0aGUgY29ycmVjdCBhbnN3ZXIgaXMg4oCcc29tZeKAnS4NCg0KVGhh
dCBzYWlkLCAiQU9EVnYyIHdhbnRzIHRvIGFjY3VtdWxhdGUgbWV0cmljc+KAnSDigJQgZG9lcyB0
aGF0IG1lYW4gdGhhdCB0aGUgbWVzc2FnZSBncm93cyBhcyBpdCBpcyBiZWluZyBmb3J3YXJkZWQs
IGFuZCB0aGF0IHRoZSByZWNpcGllbnQgb2YgYSBSUkVRL1JSRVAgd2lsbCBrbm93IHRoZSBpbmRp
dmlkdWFsIGNvc3RzIG9mIGVhY2ggcGF0aCBzZWdtZW50PyBNeSB1bmRlcnN0YW5kaW5nIGlzLCB0
aGF0IHRoZSByZWNpcGllbnQgd2lsbCBnZXQg4oCcdGhlIHN1bSB0aGUgY29zdHMgb2YgZWFjaCBw
YXRoIHNlZ21lbnTigJ0gd2hpY2ggc2hvdWxkIGJlIGZpdHRpbmcgd2l0aGluIGEgZml4ZWQgc2l6
ZT8NCg0KVGhvbWFzDQoNCg0KDQpTb3JyeSwgbm8gYW5zd2VycywganVzdCBjb21tZW50cy4gQW5k
IEnigJltIG5vdCBhZGRyZXNzaW5nIFRob21hc+KAmXMgbGF0ZXIgcG9pbnRzIGhlcmUuDQoNCi0t
DQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5
c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQy
MTk0PiAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRl
YXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j
ZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwg
RXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3Rl
bXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVn
aXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmlj
ZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZy
b206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGll
dGZAdGhvbWFzY2xhdXNlbi5vcmc8bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmc+DQpTZW50
OiAxNyBNYXJjaCAyMDE2IDE2OjAwDQpUbzogTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5n
IGxpc3QNClN1YmplY3Q6IFttYW5ldF0gZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3
IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcw0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhp
cyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhl
ciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2Fy
ZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0
dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3Mg
dGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhl
cmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkv
c3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBl
bWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50
cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0Rv
Y3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCioqKiBX
QVJOSU5HICoqKg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJv
bSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb24uDQoNCkRlYXIgYWxsLA0KDQpBcG9sb2dpZXMgZm9y
IG5vdCBoYXZpbmcgZ290dGVuIHRoaXMgZG9uZSBzb29uZXIgLSBkYXktam9iIGxlYXZpbmcgZmV3
IHNwYXJlIGN5Y2xlcy4NCg0KSeKAmXZlIHByZXZpb3VzbHkgb2ZmZXJlZCByZXZpZXdzIGFuZCBj
b21tZW50cywgYW5kIHNvbWUgb2YgdGhvc2UgaGF2ZSBiZWVuIGFkZHJlc3NlZCBpbiB0aGUgbGF0
ZXN0IEktRCDigJQgb3RoZXJzIGhhdmUgbm90LCBidXQgc2hvdWxkIGJlLiBJIHJlY2FsbCB0aGF0
IHRoZXJlIHdhcyBzb21lIG1haWwgYXR0ZW1wdGluZyB0byByZWJ1dCBwYXJ0cyBvZiB0aGUgcmV2
aWV3LCBhbmQgSSB3aWxsIGRpZyBpdCBvdXQgYW5kIHJlcGx5IHRvIHRoYXQuDQoNCldpdGggdGhh
dCBiZWluZyBzYWlkLCBJIGhhdmUgcmV2aWV3ZWQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBk
b2N1bWVudCwgYW5kIGZ1bGwgZGV0YWlscyB3aWxsIGJlIGZvcnRoY29taW5nLiBUaGVyZeKAmXJl
IGEgY291cGxlIG9mIGJpZy10aWNrZXQvYXJjaGl0ZWN0dXJhbCBpdGVtcyB0aGF0IEkgd2FudCB0
byBhZGRyZXNzIHVwIGZyb250LCBhcyBJIGJlbGlldmUgdGhhdCBiZWZvcmUgd2UgaGF2ZSB0aG9z
ZSBoYW1tZXJlZCBvdXQsIGl0IHdpbGwgYmUgdXNlbGVzcyB0byBnbyBpbnRvIGRldGFpbHMuIE5v
dGUsIEkgZG8gbm90IGNsYWltIHRoYXQgdGhpcyBpcyBhbiBleGhhdXN0aXZlIGxpc3Qgb2Yg4oCc
YmlnIHRpY2tldCBpdGVtc+KAnSwgYnV0IHRoYXTigJlzIGFzIGZhciBhcyBJIGhhdmUgZ290dGVu
IGluIHRoaW5raW5nIHRoaXMgdGhyb3VnaC4NCg0KSSBhbHNvIGJyaW5nIHRoZXNlIHVwIGFzIHRo
ZXkgYXJlIGl0ZW1zIHRoYXQgaGF2ZSBiZWVuIGJyb3VnaHQgdXAgcmVwZWF0ZWRseSBvdmVyIHRo
ZSBwYXN0IHllYXJzLCBidXQgbm90IHJlc29sdmVkIG5vciBkaXNjdXNzZWQuDQoNCkxvb3BzDQpK
dXN0IHRvIGJyaW5nIHRoaXMgb3V0OiBJIHNoYXJlIENocmlz4oCZIHdvcnJ5IGFib3V0IGNvbmZs
aWN0aW5nIGFuZCBjb25jdXJyZW50IHN0YXRlbWVudHMgZnJvbSB0aGUgYXV0aG9ycyBvbiDigJxU
aGVyZSBhcmUgbm8gbG9vcHMgcG9zc2libGXigJ0gYW5kIOKAnFdlIG5lZWQgdG8gZml4IHR3byBz
aXR1YXRpb25zIHdoZXJlIGxvb3BzIGNhbiBvY2N1cuKAnSBhbmQg4oCcd2UgYXJlIHN0aWxsIGlu
dmVzdGlnYXRpbmcgc29tZSBsb29wIGNvbmRpdGlvbnPigJ0NCg0KSSBwYXJ0aWN1bGFybHkgd29y
cnkgdGhhdCB0aGlzIGlzIG5vdCBhIGRpc2N1c3Npb24gaGFkIGluIHB1YmxpYywgYnV0IGFwcGFy
ZW50bHkgaW4gc29tZSBvdGhlciBmb3J1beKApg0KDQoNCkludGVybWVkaWF0ZSBSb3V0ZSBSZXBs
aWVzLCBhbmQgYWxsIG9mIHNlY3Rpb24gMTANClNlY3Rpb24gMTAgY29udGFpbnMgYSBzZXQgb2Yg
4oCcdmFndWVseSBzcGVjaWZpZWQgZXh0ZW5zaW9uc+KAnSwgd2hpY2ggaXMgaW5jb2hlcmVudCB3
aXRoIHRoZSBpbnRlbmRlZCBzdGF0dXMgaW5kaWNhdGVkIGZvciB0aGlzIGRvY3VtZW50Lg0KDQpT
cGVjaWZpY2FsbHksIGFuZCB0aGlzIGlzIG5vdCB1bnJlbGF0ZWQgdG8gdGhlIHBvaW50IGFib3V0
IGxvb3BzIGFib3ZlLCBpbnRlcm1lZGlhdGUgUlJFUHMgKHNlY3Rpb24gMTAuMykgYXJlIGEgcG90
ZW50aWFsIHNvdXJjZSBmb3IgbG9vcHMuDQoNCkV4cGFuZGluZyBSaW5nIE11bHRpY2FzdCAoc2Vj
dGlvbiAxMC4xKSBpcyBub3QgZG9jdW1lbnRlZCBpbiBhIHdheSB0aGF0IGNhbiBiZSBpbXBsZW1l
bnRlZCAoYW5kIGFsc28sIHNlZSDigJxGb3J3YXJkaW5nLXZzLXJlZ2VuZXJhdGlvbuKAnSBiZWxv
dywgaXQgaXMgaW4gdGhlIHByZXNlbnQgZm9ybSBvZiB0aGlzIHByb3RvY29sIGltcG9zc2libGUp
LCBldGMuDQoNCg0KRm9yd2FyZGluZy12cy1yZWdlbmVyYXRpb24NClJlY2VudCBleGNoYW5nZXMg
b24gdGhlIGxpc3QgbWFkZSBtZSB1bmRlcnN0YW5kIHRoYXQgcHJvdG9jb2wgY29udHJvbCBtZXNz
YWdlcyBhcmUgKm5vdCogZm9yd2FyZGVkLCBidXQgYXJlIGNvbnN1bWVkIGF0IGVhY2ggaG9wLCB0
aGVuIGEgbmV3IG1lc3NhZ2Ugd2l0aCAoYWxtb3N0LWJ1dC1ub3QtcXVpdGUpIHRoZSBzYW1lIGNv
bnRlbnQgaXMgZ2VuZXJhdGVkIGFuZCB0cmFuc21pdHRlZC4NCg0KSSBoYXZlIHRob3VnaHQgc29t
ZSBtb3JlIG9uIHRoaXMgKCYgcmVhZCBzb21lIG9mIHRoZSBleGNoYW5nZXMgb24gdGhlIGxpc3Qg
b24gdGhpcyB0b3BpYyBieSBDaHJpcywgVWxyaWNoLCBhbmQgb3RoZXJzKSwgYW5kIEkgYW0gY29u
dmluY2VkIHRoYXQgdGhpcyBpcyBub3QgdGhlIHJpZ2h0IHdheSB0byBnbywgYXQgbGVhc3QgZm9y
IHRoZSBmb2xsb3dpbmcgcmVhc29uczoNCg0KDQogICAgICAgICAgICBvICAgICAgICAgIEl0IHJl
bmRlcnMgdGhlIGhvcC1saW1pdC9ob3AtY291bnQgZmllbGRzIGluIHRoZSBSRkM1NDQ0IG1lc3Nh
Z2UgaGVhZGVyIHVzZWxlc3MuDQogICAgICAgICAgICAgICAgICAgICAgICBUaGlzIHdvdWxkIG5v
dCBiZSBiYWQgaWYgdGhlIGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBieSB0aG9zZSBmaWVsZHMgd2Fz
IG5vdCB1c2VmdWwNCiAgICAgICAgICAgICAgICAgICAgICAgIOKAlCBzYWRseSwgaXQgaXMuIEZv
ciBleGFtcGxlLCBmb3Igc2NvcGUgbGltaXRlZCBmbG9vZGluZyAoZXhwYW5kaW5nIHJpbmcgc2Vh
cmNoLCBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgIHN1Y2gpIHdoaWNoIG1heSBiZSBvZiBp
bnRlcmVzdCwgYW5kIHdoaWNoIHJlcXVpcmUgaG9wLWxpbWl0Lg0KICAgICAgICAgICAgICAgICAg
ICAgICAgQSBob3AtY291bnQgZmllbGQgbWF5IGFsc28gcHJvdmlkZSBhIOKAnGNoZWFw4oCdIChp
biB0ZXJtcyBvZiBvdmVyaGVhZCkgYWRkaXRpb25hbCBwaWVjZQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgb2YgaW5mb3JtYXRpb24gdG8gdXNlIGNvbmp1bmN0aXZlbHkgd2l0aCBhIOKAnHJlYWzi
gJ0gbWV0cmljLg0KDQogICAgICAgICAgICAgICAgICAgICAgICBUaGUgb25seSBwcmFjdGljYWwg
c29sdXRpb24gd291bGQgYmUgdG8gcmUtaW50cm9kdWNlIHRoZXNlIGZ1bmN0aW9ucyBieSB3YXkg
b2YgaW5zZXJ0aW5nIGENCiAgICAgICAgICAgICAgICAgICAgICAgIE1lc3NhZ2VUTFYg4oCUIHdo
aWNoIChpKSBpcyBub3Qgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQsIGFuZCAoaWkpIHdoaWNo
IHdvdWxkIGp1c3QNCiAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZlIHRvIHJlbmRlciBtZXNz
YWdlcyBiaWdnZXIgdGhhbiBzdHJpY3RseSBuZWVkZWQuDQoNCiAgICAgICAgICAgICAgICAgICAg
ICAgIFNjb3BlIGxpbWl0ZWQgZmxvb2RpbmcgIGRvZXMgc2VlbSB0byBiZSBhIG5lY2Vzc2FyeSBy
ZXF1aXJlbWVudCwgaWYgZm9yIG5vDQogICAgICAgICAgICAgICAgICAgICAgICBvdGhlciByZWFz
b24gdGhhbiB0byBwcmV2ZW50IGluZm9ybWF0aW9uIGZyb20g4oCcY2lyY3VsYXRpbmcgZm9yZXZl
ciBpbiB0aGUgbmV0d29ya+KAnS4NCg0KICAgICAgICAgICAgbyAgICAgICAgICBJdCBtYWtlcyBl
bmQtdG8tZW5kIGF1dGhlbnRpY2F0aW9uIHVubmVjZXNzYXJpbHkgaGFyZC4NCiAgICAgICAgICAg
ICAgICAgICAgICAgIEkgdGhpbmsgQ2hyaXMgY2FsbGVkIHRoaXMgb3V0IGFscmVhZHksIGJ1dCBp
dCBiZWFycyByZXBlYXRpbmc6IFMgZ2VuZXJhdGVzIGEgbWVzc2FnZQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgKHNheSwgYSBSUkVRKSwgYW5kIGluY2x1ZGVzIGFuIElDViBjYWxjdWxhdGVkIG92
ZXIgdGhlIGNvbnRlbnQgb2YgdGhlIG1lc3NhZ2UuDQogICAgICAgICAgICAgICAgICAgICAgICBG
b3IgYW55IHJlY2lwaWVudCB0byBiZSBhYmxlIHRvIHZhbGlkYXRlIHRoZSBJQ1YsIHRoZSBtZXNz
YWdlIGhhcyB0byBiZSBleGFjdGx5DQogICAgICAgICAgICAgICAgICAgICAgICB0aGUgc2FtZSDi
gJQgbm90IGp1c3QgaW4gY29udGVudCwgYnV0IGluIHN0cnVjdHVyZSDigJQgYXMgd2hhdCB3YXMg
Z2VuZXJhdGVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICDigJxSZWdlbmVyYXRpbmfigJ0g
cmF0aGVyIHRoYW4g4oCcZm9yd2FyZGluZ+KAnSBtZXNzYWdlcyBtZWFucywgdGhhdCB0aGUgaW50
ZXJtZWRpYXRlDQogICAgICAgICAgICAgICAgICAgICAgICByb3V0ZXIg4oCccmVnZW5lcmF0aW5n
4oCdIHRoZSBSUkVRIG1heSBjaG9zZSBhIGRpZmZlcmVudCBzdHJ1Y3R1cmUgKGUuZy4sIGluY2x1
ZGUgVExWcw0KICAgICAgICAgICAgICAgICAgICAgICAgaW4gYSBkaWZmZXJlbnQgb3JkZXIpLg0K
DQogICAgICAgICAgICAgICAgICAgICAgICBUaGUgcHJvcG9zYWwgZnJvbSBodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMA0KICAgICAg
ICAgICAgICAgICAgICAgICAgaXMgdG8gYWRkIGNvbnN0cmFpbnRzIG9uIChpKSB0aGUgc2V0IG9m
IGVsZW1lbnRzIHRvIGluY2x1ZGUgaW4gYSBzaWduYXR1cmUgYW5kIChpaSkgdGhlDQogICAgICAg
ICAgICAgICAgICAgICAgICBvcmRlciBvZiB0aGVzZSBlbGVtZW50cy4NCg0KICAgICAgICAgICAg
ICAgICAgICAgICAgT25lIHByb2JsZW0gd2l0aCB0aGF0IGFwcHJvYWNoIGlzIChpKTogaWYgYW4g
ZXh0ZW5zaW9uIGFkZHMgYSBtZXNzYWdlIFRMViwgb3IgYW4NCiAgICAgICAgICAgICAgICAgICAg
ICAgIEFkZHJlc3MgVExWLCB0byBhIG1lc3NhZ2UsIHRoZW4gdGhhdCB3aWxsIG5vdCBiZSDigJxj
b3ZlcmVk4oCdIGJ5IHRoZSBwcm9wb3NlZCBlMmVzZWMgVExWLg0KICAgICAgICAgICAgICAgICAg
ICAgICAgUmF0aGVyIGZvciAqZWFjaCogZXh0ZW5zaW9uIGRldmVsb3BlZCwgYW4g4oCcdXBkYXRl
cyBlMmVzZWPigJ0gY2xhdXNlIG5lZWRzIHRvIGJlIGRvbmUuDQoNCiAgICAgICAgICAgICAgICAg
ICAgICAgIEnigJlkIHNheSB0aGF0IHRoaXMgYXBwcm9hY2ggd291bGQgYmUgcHJvbmUgdG8gZXJy
b3JzIOKAlCBhbmQgYWRkIGVudHJvcHkgdG8gdGhlIHByb2Nlc3MNCiAgICAgICAgICAgICAgICAg
ICAgICAgIG9mIGRlc2lnbmluZyBwcm90b2NvbCBleHRlbnNpb25zLiBUaGUgYWx0ZXJuYXRpdmUs
IGEgbWVzc2FnZSBiZWluZyBnZW5lcmF0ZWQgYnkgdGhlDQogICAgICAgICAgICAgICAgICAgICAg
ICBzb3VyY2UgYW5kICpmb3J3YXJkZWQqIChhcyB3ZSBkbyBpbiBPTFNSdjIsIGZvciBleGFtcGxl
KSB3b3VsZCBhbGxvdyBJQ1YgVExWcw0KICAgICAgICAgICAgICAgICAgICAgICAgKGV2ZW4sIGFs
bG93IHJldXNlIG9mIHRob3NlIHNwZWNpZmllZCBmb3IgT0xTUnYyKSBmb3IgY292ZXJpbmcgYSBt
ZXNzYWdlIGFuZA0KICAgICAgICAgICAgICAgICAgICAgICAgZXh0ZW5zaW9ucy4NCg0KICAgICAg
ICAgICAgICAgICAgICAgICAg4oCcQnV0IHdoYXQgYWJvdXQgdGhlIG1ldHJpY3MgdmFsdWUgd2hp
Y2ggd2lsbCBjaGFuZ2Ugb24gZWFjaCBob3DigJ0sIHlvdSBtYXkgc2F5Pw0KICAgICAgICAgICAg
ICAgICAgICAgICAgRm9ydHVuYXRlbHksIHRoYXQgaXMgcmVsYXRpdmVseSBlYXN5IHRvIGhhbmRs
ZTogc2ltcGx5IHplcm8gb3V0IHRoZSB2YWx1ZSBvZiB0aGF0IFRMViB3aGVuDQogICAgICAgICAg
ICAgICAgICAgICAgICBnZW5lcmF0aW5nIG9yIHZlcmlmeWluZyB0aGUgSUNWIE1lc3NhZ2VUTFYu
IEFuZCB1c2UgUGFja2V0LVRMVnMgZm9yIGhvcC1ieS1ob3ANCiAgICAgICAgICAgICAgICAgICAg
ICAgIGF1dGhlbnRpY2F0aW9uLCBpZiBuZWVkZWQgKGJ1dCwgc2VlIGJlbG93KS4NCg0KICAgICAg
ICAgICAgbyAgICAgICAgICBJdCBwcmV2ZW50cyB0aGUgdXNlIG9mIG1vcmUgY2xldmVyL2FkdmFu
Y2VkIHNpZ25hdHVyZSBzY2hlbWVzL0lDVnMNCiAgICAgICAgICAgICAgICAgICAgICAgIEFnZ3Jl
Z2F0ZSBzaWduYXR1cmUgYWxnb3JpdGhtcyAoIGh0dHBzOi8vY3J5cHRvLnN0YW5mb3JkLmVkdS9+
ZGFiby9wYXBlcnMvYWdnc3VydmV5LnBkZikNCiAgICAgICAgICAgICAgICAgICAgICAgIGV4aXN0
LCBhbmQgYW4gaW50ZXJlc3RpbmcgdXNlLWNhc2UgY2FuIGJlIGZvdW5kIGluIGFsc28gcmVhY3Rp
dmUgcHJvdG9jb2xzLCBhbGxvd2luZyB2ZXJpZnlpbmcNCiAgICAgICAgICAgICAgICAgICAgICAg
IG5vdCDigJxqdXN04oCdIHRoZSBlbmQgcG9pbnRzLCBidXQgYWxzbyB0aGUgaW50ZXJtZWRpYXJp
ZXMgKGFnYWluLCB3aXRoIHRoZSBhcHByb3ByaWF0ZSDigJx6ZXJvIG91dOKAnQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgZGlzY3Vzc2VkIGFib3ZlLCBvciBzb21ldGhpbmcgc21hcnRlcikuDQog
ICAgICAgICAgICAgICAgICAgICAgICBSZWdlbmVyYXRpb24gb2YgbWVzc2FnZXMsIHJhdGhlciB0
aGFuIGZvcndhcmRpbmcsIHJlbmRlcnMgdGhhdCBpbXBvc3NpYmxlIChvciwgaWYgdXNlZCwNCiAg
ICAgICAgICAgICAgICAgICAgICAgIHVwZGF0aW5nIHRvICBodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtcGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMCkNCg0KVGhlcmUgYXJlIG90
aGVyIHJlYXNvbnMsIGJ1dCB0aGUgYWJvdmUgYXJlIHRob3NlIHRoYXQganVtcCBhdCBtZSBhcyBp
bW1lZGlhdGUgc2hvdy1zdG9wcGVycy4NCg0KSSBkbyBob25lc3RseSBub3Qgc2VlIHdoYXQgcG9z
c2libGUgYmVuZWZpdCB0aGVyZSBpcyBmcm9tIOKAnHJlZ2VuZXJhdGlvbuKAnSDigJQgYnV0IEkg
c2VlIHZlcnkgY2xlYXIgaW5jb252ZW5pZW5jZXMsIGFuZCBzZWN1cml0eSBpcyBub3QgdGhlIGxl
YXN0IG9mIHRoZXNlLiBJbnNpc3Rpbmcgb24g4oCccmVnZW5lcmF0aW9u4oCdIHJlcXVpcmVzIGRl
dmVsb3BtZW50IG9mIOKAnG5vbi1nZW5lcmFsIHdvcmthcm91bmRz4oCdIGFzIHBvaW50ZWQgb3V0
IGFib3ZlLg0KDQpTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KVGhpcyBpcyBhbiBhbHdheXMgdGhv
cm55IHN1YmplY3QuIFdoZW4gT0xTUnYyIHdhcyBnb2luZyB0aHJvdWdoIHRoZSBwcm9jZXNzIHdl
IGdvdCBhIHRob3JvdWdoIGVkdWNhdGlvbiBpbiBob3cgbGl0dGxlIHdlIGtuZXcgYWJvdXQgc2Vj
dXJpdHkgZnJvbSB0aGUgU0VDLUFEcywgYW5kIGhhZCB0byBzcGVuZCBhYm91dCBhIHllYXIgb3Ig
c28gZGV2ZWxvcGluZyBSRkM3MTgzLiBUaGUgYm90dG9tIGxpbmUgaXMsIHRoYXQgdGhpcyBwcm90
b2NvbCBuZWVkcyBpdHMg4oCcUkZDNzE4MyAgZXF1aXZhbGVudOKAnSwgZWl0aGVyIGFzIHBhcnQg
b2YgdGhlIG1haW4gZG9jdW1lbnQsIG9yIGFzIGFuIGluZGVwZW5kZW50IGRvY3VtZW50LiBjdXJy
ZW50bHksIHRoYXQgaXMgbm90IHRoZSBjYXNlLg0KDQpBIG1pbmltYSwgbG9va2luZyBhdCBCQ1A3
MiBhbmQgQkNQMTA3IOKAlCB0YWtpbmcgaW5zcGlyYXRpb24gZnJvbSBSRkM3MTgzIG1pZ2h0IGJl
IGF3IGdvb2QgaWRlYSwgYXMgdGhhdCB3YXMgdGhlIG1vc3QgcmVjZW50IHRoYXQgd2VudCB0aHJv
dWdoIHRoZSBTRUMgQUQuIFJlZ2FyZGxlc3Mgb2YgaG93LCBob3dldmVyLCBhIOKAnG1hbmRhdG9y
eSB0byBpbXBsZW1lbnTigJ0gc2VjdXJpdHkgbWVjaGFuaXNtIG1vc3QgYmUgc3BlY2lmaWVkIChJ
IHRoaW5rIHRoZSByaWdodCB0ZXJtIHdhcyDigJxNVVNUIGltcGxlbWVudCwgU0hPVUxEIHVzZeKA
nSksIGluIHN1ZmZpY2llbnQgZGV0YWlsIHRvIGVuc3VyZSBpbnRlcm9wZXJhYmxlIGltcGxlbWVu
dGF0aW9ucy4NCg0KQXMgYW4gZXhhbXBsZSwgYm90aCBbUkZDNjEzMF0gYW5kIFtSRkM3MTgxXSBz
ZXQgb3V0IHRoYXQgdGhhdDoNCg0KICAgICAgT24gcmVjZWl2aW5nIGEgLi4uIG1lc3NhZ2UsIGEg
cm91dGVyIE1VU1QgZmlyc3QgY2hlY2sgaWYgdGhlDQogICAgICBtZXNzYWdlIGlzIGludmFsaWQg
Zm9yIHByb2Nlc3NpbmcgYnkgdGhpcyByb3V0ZXINCg0KYW5kIHRoZW4gcHJvY2VlZCB0byBnaXZl
IGEgbnVtYmVyIG9mIGNvbmRpdGlvbnMgdGhhdCwgZWFjaCwgd2lsbCBsZWFkIHRvIGEgcmVqZWN0
aW9uIG9mIHRoZSBtZXNzYWdlIGFzICJiYWRseSBmb3JtZWQgYW5kIHRoZXJlZm9yZSBpbnZhbGlk
IGZvciBwcm9jZXNzaW5n4oCdIOKAlCBhIGxpc3Qgd2hpY2ggUkZDNzE4MyB0aGVuIGFtZW5kZWQu
IFRoYXQgZ2F2ZSBhIOKAnGhvb2vigJ0gZm9yIFJGQzcxODMgZm9yIGluc2VydGluZyDigJxyZWpl
Y3Rpb27igJ0uIElkZW0gZm9yIG1lc3NhZ2UgZ2VuZXJhdGlvbi4NCg0KSWYgSSB3YXMgdG8gZG8g
UkZDNzE4MS9SRkM2MTMwIHRvZGF5LCBJIHdvdWxkIGluY2x1ZGUgdGhhdCBkaXJlY3RseSBpbnRv
IHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucy4gSXQgdHVybmVkIG91dCB0byBiZSBtb3JlIG92
ZXJoZWFkIChhbmQgc2xvdyBkb3duIHB1YmxpY2F0aW9uIGFueXdheXMpIHRvIGRvIGl0IGFzIHNl
cGFyYXRlIGRvY3VtZW50cy4NCg0KU2Vjb25kbHksIHdlIG5lZWQgdG8gYmUgYSBsb3QgbW9yZSBy
aWdpZCBpbiB0ZXJtcyBvZiB3aGF0IElDVnMsIFRpbWVzdGFtcHMsIGV0Yy4gYXJlIGFkZGVkL3Jl
bW92ZWQsIGFuZCB3aGF0IHRoYXQgYnJpbmdzLg0KDQpGb3IgZXhhbXBsZSAod2l0aCB0aGUgYXNz
dW1wdGlvbiB0aGF0IG1lc3NhZ2VzIGFyZSAqZm9yd2FyZGVkKiBhbmQgKm5vdCogcmVnZW5lcmF0
ZWQpLCB0aGlzIGNvdWxkIGJlIG9uZSBvcHRpb246DQoNCiAgICAgICAgICAgICAgICAgICAgICAg
IG8gICAgICAgICAgV2hlbiBhIFJSRVEsIFJSRVAgbWVzc2FnZSBpcyBnZW5lcmF0ZWQsIGFkZCBh
biBJQ1YgTWVzc2FnZSBUTFYsIHdoaWNoIGlzIGNhbGN1bGF0ZWQgPHRoaXMgd2F5Pg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIOKApih0YWtlIGluc3BpcmF0aW9uIGZyb20g
UkZDNzE4MyBoZXJlKQ0KDQouLi4NCg0KW01lc3NhZ2UgY2xpcHBlZF0NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1h
bmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFp
bHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9tYW5ldA0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqDQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg
YXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCBhbmQgbWF5IGFsc28g
YmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGllbnQgcGxl
YXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4NCllv
dSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xv
c2Ugb3INCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uDQoqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5v
cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxp
bmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0
QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vbWFuZXQNCg0K

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B15E3GLKXM0002VGREEN_
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
cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy
Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm
b250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwg
ZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r
OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx
cHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm
Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy
ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp
bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFy
ZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUt
bmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z
ZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQN
Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z
dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ
e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4w
cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg
c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi
IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+
DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs
YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgaGFzIHRvIGdvIGJhY2sgdG8gVmljdG9yaWHi
gJlzIHN1bW1hcnkgaGVyZS4gSXQgc2F5czo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjIpIEMgY3JlYXRlcyB0aGUgUlJFUC4gU2luY2UgaXQgZG9lc250IGtub3cgaWYgdGhlIGxpbmsg
dG8gQiBpcyBiaWRpcmVjdGlvbmFsLCBpdCBpbmNsdWRlcyB0aGUgQWNrUmVxIChhbiBhZGRyZXNz
IHRvIGluZGljYXRlIHRoYXQgaXQgZXhwZWN0cyB0byByZWNlaXZlIGEgUlJFUF9BY2sgZnJvbSBC
KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+VGhhdCBkb2VzbuKAmXQgYWN0dWFsbHkgaW5kaWNhdGUgaWYgdGhhdOKAmXMgQ+KAmXMg
YWRkcmVzcyBvciBC4oCZcyBhZGRyZXNzIGJlaW5nIGluY2x1ZGVkLiBJ4oCZZCBhc3N1bWVkIGl0
IHdhcyBD4oCZcyBhZGRyZXNzLiBZb3VyIGNvbW1lbnQgbWFrZXMgc2Vuc2UgaWYgaXTigJlzIELi
gJlzIGFkZHJlc3MuDQogUmVhZGluZyBhZ2FpbiwgSSB0aGluayB5b3XigJlyZSBwcm9iYWJseSBy
aWdodC4gQnV0IG9ubHkgcHJvYmFibHkuIENhbiB3ZSBjb25maXJtIHRoYXQuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J
IGFzc3VtZSB5b3UgbWVhbnQgdGhhdCB0aGUgUlJFUCAobm90IFJSRVBfQWNrKSBpcyBtdWx0aWNh
c3QuIFRoZXJl4oCZcyBhIGJpdCBvZiBhIGNoaWNrZW4gYW5kIGVnZyBwcm9ibGVtIGhlcmUuIFdl
IGRvIGtub3cgaG93IHdlIHdhbnQgdG8gdW5pY2FzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMwMDdFN0UiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2Vu
aW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdl
bmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7JiM0Mzs0NCAoMCkxMjQ1IDI0
MjE5NCAmbmJzcDt8ICZuYnNwOzxiPkU6DQo8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJs
b3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+
DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMg
QXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBC
YWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3
dy5iYWVzeXN0ZW1zLmNvbS9haSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVz
eXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBT
eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVu
Z2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBS
ZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206
PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0
aW4gRGVhbiBbbWFpbHRvOmJlYmVtYXN0ZXJAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+
IDI1IEFwcmlsIDIwMTYgMTU6MjY8YnI+DQo8Yj5Ubzo8L2I+IFRob21hcyBIZWlkZSBDbGF1c2Vu
PGJyPg0KPGI+Q2M6PC9iPiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgQ2hyaXN0b3BoZXIg
RGVhcmxvdmU7IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0OyBWaWN0b3JpYSBN
ZXJjaWVjYTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBNZXNzYWdlIGludGVncml0
eSBhbmQgbWVzc2FnZSBtdXRhYmlsaXR5ICh3YXMgUkU6IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYy
LTEzIHJldmlldyAtIGEgY291cGxlIG9mIGJpZyB0aWNrZXQgSXRlbXMpPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBw
dCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4
dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh
bGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAq
Kio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQt
YWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRl
IG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhl
IGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5
b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVw
bHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJk
aW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBv
dXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8vaW50
cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0Rv
Y3VtZW50cy9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklm
IHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBocmVm
PSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9z
cG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMu
cGRmIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGFkZHJlc3MgaW4g
dGhlIFJSRVBfQWNrIG1heSBiZSByZXF1aXJlZCBkdWUgdG8gdGhlIFJSRVBfQWNrIGJlaW5nIG11
bHRpY2FzdCBhcyB0aGVyZSBpcyBub3QgeWV0IGEgdmVyaWZpZWQgdW5pY2FzdCByb3V0ZSBpbnN0
YWxsZWQgeWV0LiZuYnNwOyBHb2luZyB0byBkb3VibGUgY2hlY2sgaWYgSSdtIHJlbWVtYmVyaW5n
IGNvcnJlY3RseS4mbmJzcDs8YnI+DQo8YnI+DQpKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXByIDI1LCAyMDE2IGF0IDEwOjE4IEFN
LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmciIHRhcmdldD0iX2Js
YW5rIj5pZXRmQHRob21hc2NsYXVzZW4ub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG11c3QgYWRtaXQgdGhhdCB3aGlsZSBJIGhhdmUgcmV2
aWV3ZWQgdGhlIHByb3RvY29sIHNldmVyYWwgdGltZXMsIEnigJl2ZSBub3QgYmVlbiBkaWdnaW5n
IHRoYXQgZGVlcCBpbnRvIHRoZSBwcm90b2NvbCBmdW5jdGlvbmluZyB0byBjYXRjaCB0aGlzIGlz
c3VlIG9mIGhvdyBpbnZhc2l2ZSB0aGUgcHJvdG9jb2wgb3BlcmF0aW9ucyBhcmUgd2hlbiBmb3J3
YXJkaW5nIGEgbWVzc2FnZTogdGhlcmUgd2VyZSBvdGhlcg0KIOKAnG1ham9y4oCdIGlzc3VlcyB0
byBhZGRyZXNzIChhbmQgd2hpY2ggb2JzY3VyZWQgdGhlIGRldGFpbHMpLCBzbyBhcyBhIGZpcnN0
IG9yZGVyOiB0aGFuayB5b3UgVmljdG9yaWEsIGZvciBoYXZpbmcgY2FsbGVkIGF0dGVudGlvbiB0
byB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5UbyB0aGUgc3Vic3RhbmNlIG9mIHRoZXNlIGVtYWlscy48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBhZnJhaWQgdGhhdCBJIGRv
IG5vdCB1bmRlcnN0YW5kIHRoZSB1c2Ugb2YgaW5zZXJ0aW5nIHZhbGlkaXR5IFRMVnMgd2hpbGUg
aW4tZmxpZ2h0LCBpbnRvIGEgbWVzc2FnZS4gQWN0dWFsbHksIEkgYW0gZHViaW91cyBmb3IgYm90
aCB0aGUgb3JpZ2luYXRvciBpbnNlcnRpbmcgdGhpcyAoaG93IGNhbiB0aGUgb3JpZ2luYXRvciBv
ZiBhIG1lc3NhZ2Uga25vdyBob3cg4oCcbGF0dGVyIHBhcnRzIG9mIHRoZSBwYXRo4oCdDQogd2ls
bCBiZSBoYXZl4oCdKSBleGNlcHQgaWYgd2UgYXJlIHRhbGtpbmcgZHV0eS1jeWNsaW5nIG9mIGRl
dmljZXMgYW5kIGluc2VydGluZyDigJx0aGUgcmVtYWluaW5nIHRpbWUgdGhhdCBJIGFtIGdvaW5n
IHRvIGJlIHVwIGJlZm9yZSBJIHN1c3BlbmTigJ0uIEludHVpdGl2ZWx5LCB0aGF0IHdvdWxkIGFs
c28gYXNzdW1lIGZhaXJseSBsb25nIGR1dHkgY3ljbGVzIOKAnEkgYW0gdXAgZm9yIHRlbnMgb2Yg
c2Vjb25kc+KAnSwgd2hpY2ggSSBhbSBub3Qgc3VyZSBhcmUNCiBhY3R1YWxseSByZWFsaXN0aWMu
IEFuZCwgYXMgQ2hyaXMgc2F5cyBpbiBhbm90aGVyIGVtYWlsLCB0aGlzIGlzIHRyYWRpbmcgb2Zm
IOKAnHRoZSBhYmlsaXR5IHRvIGRvIHNlY3VyaXR54oCdIGZvciBhbiB1bmtub3duL3VudGVzdGVk
IGZlYXR1cmUg4oCUIHdoaWNoIEkgdGhpbmsgaXMgdGhlIHdyb25nIHRyYWRlLW9mZi48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gaGUgdG9w
aWMgb2Yg4oCcbmVlZGluZyB0byBwdXQgYW4gYWRkcmVzcyBpbuKAnSBmb3IgUlJFUC1BQ0ssIEkg
bXVzdCBhZG1pdCB0aGF0IHRoaXMgc2VlbXMgcm91bmRhYm91dC4gSSBjYW4gc2VlIHRocmVlIGlz
c3VlcyBoZXJlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5vIEkgYW0gbm90IHN1cmUgdGhhdCBhZGRpbmcgYW4gYWRkcmVzcyB2cy4gYSBmbGFn
IG1heSBub3QgaGF2ZSB0byBkbyB3aXRoIHRoZSDigJxtdWx0aXBsZSBpbnRlcmZhY2VzLzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bXVsdGlwbGUg
YWRkcmVzc2Vz4oCdIGRpc2NyaW1pbmF0aW9uIG1lY2hhbmljcyBvZiB0aGUgcHJvdG9jb2w/IEkg
aGF2ZW7igJl0IHdvcmtlZCBpdCB0aHJvdWdoLCB0aG91Z2gsJm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5idXQgdGhhdCB3b3VsZCBiZSBh
IGd1ZXNzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5vIFRoZSBlbmQtdG8tZW5kIHRvcG9sb2d5IGRpZmZ1c2lvbiBtZWNoYW5pc20gc2hvdWxk
IG5vdCBuZWVkIHRvIGJlIGNvbmNlcm5lZCB3aXRoIHRoZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcYmlkaXJlY3Rpb25hbGx5IGNo
ZWNr4oCdIG9mIGEgbG9jYWwgbGluayAoaW4gcGFydCwgYXMgaXQgZW5jdW1iZXJzIHNlY3VyaXR5
LCBidXQgbm90IG9ubHkpLiZuYnNwOyBJbiBzaG9ydCwgYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZmxhZyBvciBhbiBhZGRyZXNzLCBib3RoIGFy
ZSAoZXF1YWxseSkgYmFkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5vIEEgY2xlYW5lciBtZWNoYW5pc20gd291bGQgYmUgYSDigJxoZWxsbyBt
ZWNoYW5pc23igJ0sIG5vdCBuZWNlc3NhcmlseSBhcyBOSERQLCBidXQgYSDigJx3aGVuJm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mb3J3
YXJkaW5nIGEgUlJFUS9SUkVQLCB0cmlnZ2VyIGEgMy13YXkgaGVsbG8gZXhjaGFuZ2UsIGlmIHRo
ZSBsaW5rIGlzIGVzdGltYXRlZCB0byBiZSBvZiBhJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50eXBlIHdoaWNoIHBvdGVudGlhbGx5IGNh
biBiZSZuYnNwO3VuaWRpcmVjdGlvbmFs4oCdLiBUaGVyZSBpcyBhbm90aGVyIGJlbmVmaXQgdG8g
ZG9pbmcgdGhhdCwgc2VlIHRoZSBlbmQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9mIHRoaXMgZW1haWwuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVpdGhlciB3YXksIEkgZG8gbm90
IGxpa2UgdGhlIG5vdGlvbiBvZiBmdXNpbmcgbWV0cmljcy1hbmQtbGluay1iaWRpcmVjdGlvbmFs
aXR5LWRldGVjdGlvbiBhbnkgbW9yZSB0aGFuIEkgbGlrZSBmdXNpbmcgZ2xvYmFsLXRvcG9sb2d5
LWRpZmZ1c2lvbi1hbmQtbGluay1iaWRpcmVjdGlvbmFsaXR5LWRldGVjdGlvbi4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNv
bHV0aW9uIGFsbCB0aGlzIGlzLCB0byBtZSwgdGhyZWVmb2xkPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEpIEZhY3RvciBvdXQgdGhlIGJpZGly
ZWN0aW9uYWxseSBjaGVjayBpbiBhICh0cmlnZ2VyZWQpIG5laWdoYm91ciBkZXRlY3Rpb24gbWVj
aGFuaXNtJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4odHJpZ2dlcmVkIEhFTExPIG1lc3NhZ2UpPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIpIFJlbW92ZSB0aGUg4oCcdmFsaWRpdHkg
dGltZSBUTFZz4oCdLCBzaW5jZSB0aGV5IGFkZCBjb21wbGV4aXR5IGZvciBubyBwZXJjZWl2YWJs
ZSBiZW5lZml0czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4zKSBVc2UgdGhlIHNlY3VyaXR5IG1vZGVsIHRoYXQgd2XigJl2ZSBkaXNjdXNzZWQg
cHJldmlvdXNseSwgd2hlcmUgKG9ubHkpIHRoZSBtZXRyaWNzIGNoYW5nZSBwZXIgaG9wLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW5jZSB3
ZeKAmXJlIGRpc2N1c3NpbmcgYmktZGlyZWN0aW9uYWxpdHkgb2YgbGlua3MgaGVyZSwgYW5kIHRo
ZSBuZWNlc3NpdHkgb2YgYSBtZWNoYW5pc20gZm9yIGhhbmRsaW5nIHRoZXNlLCBJIHdhbnQgdG8g
Y2FsbCBhdHRlbnRpb24gdG8gYSByZWxhdGVkIGlzc3VlLCBhcyBJIGhpbnRlZCBwcmV2aW91c2x5
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgYWJzdHJhY3Qgc3RhdGVzIHRoYXQgdGhlIHByb3RvY29s
OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2
Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IC4uLmlzIGludGVuZGVkIGZvciB1c2UgYnkgbW9i
aWxlIHJvdXRlcnMgaW4gd2lyZWxlc3MsIG11bHRpaG9wPG86cD48L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7Jm5ic3A7IG5ldHdvcmtzLjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHByZT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U2VjdGlv
biA1IHBhcmFncmFwaCA0ICZuYnNwO29mIHRoZSBkb2N1bWVudCwgaG93ZXZlciwgcmVhZHM6PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEFzc3VtaW5nIGxpbmsgbWV0cmljcyBhcmUgc3ltbWV0
cmljLCB0aGUgY29zdCBvZiB0aGUgcm91dGVzIGluc3RhbGxlZDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOyZuYnNwOyBpbiB0aGUgTG9jYWwgUm91dGUgU2V0IGF0IGVhY2ggcm91dGVyIHdp
bGwgYmUgY29ycmVjdC4mbmJzcDsgV2hpbGUgdGhpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOyZuYnNwOyBhc3N1bXB0aW9uIGlzIG5vdCBhbHdheXMgY29ycmVjdCwgY2FsY3VsYXRpbmcg
aW5jb21pbmcvb3V0Z29pbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbWV0
cmljIGRhdGEgaXMgb3V0c2lkZSBvZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiA8bzpwPjwvbzpw
PjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5vdCBr
bm93IG9mIDxiPjxpPmFueTwvaT48L2I+IHdpcmVsZXNzIHN5c3RlbXMsIHdoZXJlIHRoZSBhc3N1
bXB0aW9uIHRoYXQg4oCcbGluayBtZXRyaWNzIGFyZSBzeW1tZXRyaWPigJ0gYWN0dWFsbHkgaG9s
ZHMuIENvbnNlcXVlbnRseSwgdGhlIGNvbmNsdXNpb24gaW4gdGhlIHF1b3RlZCBwYXJhZ3JhcGg6
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjYWxjdWxhdGluZyBpbmNvbWluZy9vdXRnb2luZzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBtZXRyaWMgZGF0YSBpcyBvdXRzaWRlIG9m
IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgbm90IGFuIGFjY2VwdGFibGUgZGVzaWduIGNob2lj
ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
V2hpbGUgdGhpcyBwcm90b2NvbCBtYXkgbm90IHdhbnQgdG8g4oCcY2FsY3VsYXRlIGlmIGZvciB0
aGlzIGxpbmsgdGhlIG1ldHJpY3MgaXMgNCBvciA14oCdLCB0aGUgcHJvdG9jb2wgbXVzdCBiZSBh
YmxlIHRvIGNvbnZleSBhbmQgZGlzdGluZ3Vpc2ggdGhhdCDigJx0aGUgbWV0cmljIGZyb20gQSB0
byBCIGlzIDQsIGFuZCB0aGUgbWV0cmljIGZyb20gQiB0byBBIGlzIDE54oCdLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGEg4oCc
cmVsYXRlZCBpc3N1ZeKAnSBzaW5jZSB0aGUgc29sdXRpb24gbWF5IChhcyB3aXRoIHRoZSBiaS1k
aXJlY3Rpb25hbGl0eSBjaGVjaykgYmUgaW4gdGhlIHRyaWdnZXJlZCBuZWlnaGJvdXIgZGV0ZWN0
aW9uIG1lY2hhbmlzbTogdGhhdCBleGNoYW5nZSBjb3VsZCwgaWYgZGVzaWduZWQgY2FyZWZ1bGx5
LCBiZSB1c2VkIHRvIHByb2JlIGZvciBhbmQgY29udmV5IG1ldHJpY3MgaW5mb3JtYXRpb24sIGFs
c28uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkhvcGUgdGhpcyBoZWxwcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5UaG9tYXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDI1IEFwciAyMDE2LCBhdCAx
NToyNywgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJp
cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3Zl
QGJhZXN5c3RlbXMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPkFzc3VtaW5nIGZvciB0aGUgbW9tZW50IHRoYXQgZXZlcnlvbmUgd2lsbCBu
ZWVkIGFuIFJSRVAtQWNrIG9yIHdvbuKAmXQgKGxldOKAmXMgY29tZSBiYWNrIHRvIHRoYXQpIHdo
eSBkbyBDIGFuZCBCIG5lZWQgdG8gcHV0IGFuIGFkZHJlc3MgaW4gYXMgYW4gUlJFUS1BY2sgcmVx
dWVzdD8NCiBXaHkgbm90IGEgZmxhZywgYmVjYXVzZSB0aGUgYWRkcmVzcyB3aWxsIGJlIGluY2x1
ZGVkIGFzIHRoZSBJUCBzZW5kaW5nIGFkZHJlc3MgLSBhbmQgd2Uga25vdyA1NDQ0IGlzIHJlcXVp
cmVkIHRvIHBhc3MgdGhhdCBvbi4gKEl04oCZcyB1c2VkIGJ5IE5IRFAgYXMgd2VsbC4pIFRoZW4g
d2UgZG9u4oCZdCBuZWVkIHRvIGNoYW5nZSB0aGUgUlJFUCwgaXQgd2lsbCBoYXZlIGEgZmxhZyBz
ZXQgb3Igbm90LCBhbmQgd29u4oCZdCBjaGFuZ2UgKGluIHRoaXMgcmVnYXJkKS48L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vdyBsZXTigJlzIGNvbnNpZGVyIGRvIHdl
IGtub3cgd2hldGhlciB3ZSBjYW4gc2V0IGEgZml4ZWQgZmxhZy4gRmlyc3QgSeKAmWQgc2F5IHRo
ZXJlIGFyZSB0d28gY2FzZXMgLSB5b3XigJl2ZSBnb3QgYSBmaXJtIGNvbnRyb2wgb24gd2hhdOKA
mXMgZ29pbmcgb24gaW4geW91ciBuZXR3b3JrLA0KIG9yIGl04oCZcyBvbmUgb2YgdW5rbm93biBw
YXJ0aWVzIGFuZCBiZWhhdmlvdXIgKGNvbnNpc3RlbnQgd2l0aCBzcGVjaWZpY2F0aW9uKS4gSW4g
dGhlIGZvcm1lciBjYXNlIHlvdSBvbmx5IHdhbnQgb25lIHNldHRpbmcsIGZvciBleGFtcGxlIG5v
LUFjayBpZiBydW5uaW5nIE5IRFAgb3IgeW91ciBNQUMgbGF5ZXIgdGVsbHMgeW91IGFib3V0IGJp
ZGlyZWN0aW9uYWxpdHksIEFjayBvdGhlcndpc2UuIEluIHRoZSBsYXR0ZXIgY2FzZSwgSSB0aGlu
ayB5b3UNCiBqdXN0IGFsd2F5cyB3YW50IGFuIEFjay4gU28gYm90aCBjYXNlcyBnZXQgeW91IHRv
IHRoZSBzYW1lIHBsYWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
U2hvdWxkIHRoYXQgbm90IGJlIGFuIGFjY2VwdGFibGUgYXJndW1lbnQgKHRob3VnaCBJIHRoaW5r
IGl04oCZcyBnb29kIGZvciB3aGVyZSB3ZSBhcmUgLSBpbiBmYWN0IGFsd2F5cyBBY2sgaXMgY2xv
c2UpIHRoZW4gYXQgZmxhZyBpcyBhIHN0ZXAgYmV0dGVyLCBpdOKAmXMgYSBmaXhlZA0KIGxvY2F0
aW9uIHRvIGNoYW5nZS4gSG93ZXZlciBpdCB3b3VsZCBiZSBiZXR0ZXIgaW4gdGhhdCBjYXNlIGlm
IHRoZSB0d28gdGhpbmdzIHRvIGNoYW5nZSAobWV0cmljIGFuZCBhY2sgZmxhZykgd2VyZSB0b2dl
dGhlci4gQnV0IHRoYXQgaGFzIGl0cyBvd24gaXNzdWVzLCBzbyBJIHdvbuKAmXQgZ28gdGhlcmUu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw
MDdFN0UiPi0tPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lw
YWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0
b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOzxhIGhyZWY9InRlbDolMkI0NCUyMCUyODAlMjkx
MjQ1JTIwMjQyMTk0IiB0YXJnZXQ9Il9ibGFuayI+JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NDwvYT4N
CiAmbmJzcDt8ICZuYnNwOzxiPkU6Jm5ic3A7PC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFy
bG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw
dXJwbGUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT48YnI+DQo8L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGll
ZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3cs
IENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVz
eXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4Qjky
Ij53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4N
ClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJl
Z2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXks
IEdVMiA3WVA8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7VmljdG9yaWEg
TWVyY2llY2EgWzxhIGhyZWY9Im1haWx0bzp2bWVyY2llY2EwQGdtYWlsLmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzp2bWVyY2llY2EwQGdtYWls
LmNvbTwvc3Bhbj48L2E+XSZuYnNwOzxicj4NCjxiPlNlbnQ6PC9iPiZuYnNwOzI1IEFwcmlsIDIw
MTYgMTQ6MTU8YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7SmlhemkgWUk8YnI+DQo8Yj5DYzo8L2I+Jm5i
c3A7RGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk7IENocmlzdG9waGVyIERlYXJsb3ZlOyBNb2Jp
bGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiZuYnNw
O1JlOiBbbWFuZXRdIE1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBtZXNzYWdlIG11dGFiaWxpdHkgKHdh
cyBSRTogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmln
IHRpY2tldCBJdGVtcyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls
ZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4w
cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxp
Z246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5
bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPC9zcGFuPjwvYj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj
ZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNr
Z3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91
bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3Vy
IG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50
ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMz
OTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBz
aG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48
L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcm
bmJzcDs8L3NwYW4+PC9lbT48L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+Jm5ic3A7dGhhdA0KIHlvdSBjYW4g
bG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2smbmJzcDs8YSBocmVmPSJo
dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90
bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz
dHlsZT0iY29sb3I6cHVycGxlIj5oZXJlPC9zcGFuPjwvYT4uPC9zcGFuPjwvZW0+PGk+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklm
IHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93Jm5ic3A7PGEg
aHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJp
dHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1h
aWxzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRoaXMN
CiBwcm9jZXNzPC9zcGFuPjwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1ib3R0b206MTIuMHB0Ij5IaSBKaWF6aSw8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBcHIg
MjUsIDIwMTYgYXQgMTowNCBQTSwgSmlhemkgWUkgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGpp
YXppeWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWV0
ZkBqaWF6aXlpLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSwmbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiBNb24sIEFwciAyNSwgMjAxNiBhdCAxMToyMCBBTSwgRGVhcmxvdmUsIENocmlzdG9waGVy
IChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNocmlzLmRlYXJsb3Zl
QGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2l0aCByZWdhcmQgdG8geW91ciB2YWxp
ZGl0eSB0aW1lIHBvaW50LCB3ZSBoZXJlIGhhdmUgYSB0cmFkZW9mZi4gSWYgeW91IGFsbG93IHRo
YXQgZmVhdHVyZSwgaXQgc2lnbmlmaWNhbnRseSBpbXBhY3RzIG9uIHRoZSBhcHByb2FjaCB0aGF0
IHdhcyBjb21pbmcgdG9nZXRoZXINCiBvbiBhcyBiZXN0IHlvdSBjYW4gZW5kIHRvIGVuZCBlbmNy
eXB0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28gdGhlIHF1
ZXN0aW9uIGlzLCBpcyB0aGlzIGEgZmVhdHVyZSB0aGF04oCZcyByZWFsbHkgd2FudGVkPyBVbmZv
cnR1bmF0ZWx5IEkgdGhpbmsgd2Uga25vdyB0aGF0IHRoZSBhbnN3ZXIgdG8gdGhhdCBpcywgd2Ug
ZG9u4oCZdCBrbm93IGJlY2F1c2Ugd2UgZG9u4oCZdCBoYXZlIGFueQ0KIGV4cGVyaWVuY2UuIE15
IHZpZXcgd291bGQgYmUgdGhhdCBpbiB0aGUgdHJhZGVvZmYgb2YgYW4gdW50ZXN0ZWQgZmVhdHVy
ZSAodW5sZXNzIEnigJltIHdyb25nIGFib3V0IHRoYXQpIGFuZCB0aGUgc2VjdXJpdHkgY29tcGxp
Y2F0aW9uLCBzZWN1cml0eSB3aW5zIGFuZCBkcm9wIHRoZSBmZWF0dXJlLiBJZiB0aGVyZSBpcyBz
b21lIHJlYWwgcmVxdWlyZW1lbnQsIHRoZW4gdGhlcmXigJlzIGEgZGlzY3Vzc2lvbi4gKFF1ZXN0
aW9ucyBsaWtlIGhvdyBvZnRlbg0KIHRoZSBpbnRlcm1lZGlhdGUgcm91dGVycyBhY3R1YWxseSBo
YXZlIGFueSBrbm93bGVkZ2UgLSB0eXBpY2FsbHkgbGlua3MgYnJlYWsgZm9yIHVuZXhwZWN0ZWQg
cmF0aGVyIHRoYW4gZXhwZWN0ZWQgcmVhc29ucy4gQW5kYW4gaW50ZXJtZWRpYXRlIHJvdXRlciBj
b3VsZCBwb3NzaWJseSB1c2UgYSB2YWxpZGl0eSB0aW1lIHRvIGluZmx1ZW5jZSBpdHMgYmVoYXZp
b3VyLikgTm90ZSB0aGF0IGRyb3BwaW5nIHRoZSBhYmlsaXR5IG9mIGludGVybWVkaWF0ZQ0KIHJv
dXRlcnMgdG8gbW9kaWZ5L3NldCBzdGlsbCBhbGxvd3MgdmFsaWRpdHkgdGltZXMgcGVyIHJvdXRl
IHRvIGJlIHNldCBhdCBlbmRwb2ludHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkkgYWdyZWUgd2l0aCBDaHJpcycgY29uY2Vybi48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBWYWxp
ZGl0eVRpbWUgaXMgb3B0aW9uYWwsIHdoaWNoIG1ha2VzIHRoZSBpbnRlZ3JpdHkgcHJvdGVjdGlv
biBoYXJkLiBGdXJ0aGVybW9yZSwgaXQgZ2l2ZXMgYSBwb3RlbnRpYWwgYXR0YWNrIHZlY3Rvcjog
YXMgYWxsIHRoZSByb3V0ZXJzIGluIGEgcGF0aCB3aWxsIHRha2UgdGhlIHNob3J0ZXN0IHZhbGlk
aXR5VGltZSwgYSBjb21wcm9taXNlZCByb3V0ZXIgY2FuIHNldCB0aGUgdGhlIHZhbGlkaXR5VGlt
ZQ0KIHRvIGEgdmVyeSBzaG9ydCB2YWx1ZSwgd2hpY2ggd2lsbCBtYWtlIHRoZSByb3V0ZSBpbnN0
YWxsZWQgYWxvbmcgdGhlIHBhdGggYmVjYW1lIGludmFsaWQgKHZlcnkgc29vbikuJm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIHRoZSBvdGhlciBoYW5kLCBJJ20gbm90IHN1cmUg
dGhpcyBvcHRpb24gd2lsbCBnaXZlIHVzIG11Y2ggaGVscC4gQ2hyaXMgbWVudGlvbmVkIG11Y2gg
a25vd2xlZGdlIGludGVybWVkaWF0ZSByb3V0ZXIgd291bGQgaGF2ZSB0byBkZWNpZGUgdGhpcyB2
YWx1ZSAoYW5kIGhvdyBtdWNoIHNlbnNlIHRoZSB2YWx1ZSB3b3VsZCBtYWtlKS4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkFub3RoZXIgaXNzdWUgaXMsIGEgcm91dGUgdG8gYSBkZXN0aW5hdGlvbiBtaWdodCBi
ZSB1cGRhdGVkIGJ5IGRpZmZlcmVudCBzb3VyY2VzLiBGb3IgZXhhbXBsZSwgaW4gdGhlIG5ldHdv
cmsgYmVsb3c6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QS0tLS1CLS0tLS1DPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGZpcnN0IGVzdGFibGlzaCBhIHJvdXRlIHRvIEIgd2l0aCBs
b25nIHZhbGlkaXR5IHRpbWUuIFRoZW4gQSBpbml0aWF0ZXMgYSByb3V0ZSBkaXNjb3ZlcnkgdG8g
Qy4gQyB0ZW5kcyB0byBzZXQgYSBzaG9ydCB2YWxpZGl0eSB0aW1lLCB3aGljaCB3aWxsIG1ha2Ug
dGhlIHJvdXRlIGJldHdlZW4gQiBhbmQgQSBleHBpcmUgZWFybGllciB0aGFuIGV4cGVjdGVkLiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SXMgdGhpcyBhIHByb2JsZW0/IE1heWJlIHllcywgbWF5YmUgbm8gLS0g
SSdtIG5vdCBzdXJlIGl0J3MgY29uc2lkZXJlZCBvciBub3QuJm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQiPk5vdCBzdXJlIEkgZm9sbG93IGhlcmUuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv
bToxMi4wcHQiPkN1cnJlbnRseSwgdGhlIHZhbGlkaXR5IHRpbWUgb2YgdGhlIHJvdXRlIGJldHdl
ZW4gQSBhbmQgQiB3b3VsZCBub3QgYWZmZWN0ZWQgYnkgYSBzaG9ydCB2YWxpZGl0eSB0aW1lIG9m
IGEgcm91dGUgYmV0d2VlbiBBIGFuZCBDLiBWYWxpZGl0eSB0aW1lcyBhcmUgcGVyLXJvdXRlLCBh
bmQgdGhlIHJvdXRlIEEtQiBhbmQgdGhlIHJvdXRlIEEtQyBhcmUgc2VwYXJhdGUuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2Ug
c3dpdGNoZWQgdG8gYSB2YWxpZGl0eSB0aW1lIHBlciBuZWlnaGJvciAoc28gdGhhdCB3ZSBjYW4g
a2VlcCB2YWxpZGl0eSB0aW1lIHNlcGFyYXRlIGZyb20gcm91dGUgYWR2ZXJ0aXNlbWVudHMpIGFz
IEkgbWVudGlvbmVkIGluIHRoZSBlbWFpbCBiZWxvdywgdGhlbiB0aGUgdmFsaWRpdHkgb2YgYSBy
b3V0ZSBiZXR3ZWVuIEEgYW5kIEMgd291bGQgYmUgYWZmZWN0ZWQgaWYgdGhlcmUgd2FzIGEgc2hv
cnQNCiB2YWxpZGl0eSB0aW1lIGJldHdlZW4gQSBhbmQgQi4gQnV0LCBpZiBCIHdpbGwgb25seSBy
b3V0ZSBmb3IgYSBjZXJ0YWluIGFtb3VudCBvZiB0aW1lLCB0aGVuIHRoZSByb3V0ZSBiZXR3ZWVu
IEEgYW5kIEMgd2lsbCBvZiBjb3Vyc2UgYmUgYWZmZWN0ZWQuIElzIGl0IGJlc3QgdG8ga25vdyBp
biBhZHZhbmNlIHRoYXQgdGhlcmUncyBhIHRpbWUgbGltaXQsIG9yIGp1c3QgZGVhbCB3aXRoIFJF
UlJzIHdoZW4gdGhleSBoYXBwZW4/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu
ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND
QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+V2l0aCByZWdhcmQgdG8gdGhlIGFja25vd2xlZGdlbWVudHMsIHRo
ZSBwcm9ibGVtICh3aXRoIHJlZ2FyZCB0byBzZWN1cml0eSkgY29tZXMgZnJvbSB0cnlpbmcgdG8g
ZG8gdHdvIGpvYnMgd2l0aCB0aGUgc2FtZSBtZXNzYWdlIC0gZW5kIHRvIGVuZCByb3V0ZSBhZHZl
cnRpc2VtZW50DQogYW5kIGhvcCBieSBob3AgYWNrbm93bGVkZ2VtZW50LiBJIHVuZGVyc3RhbmQg
dGhlIHJlYXNvbnMgLSBzYXZpbmcgYnl0ZXMgYW5kIG1lc3NhZ2UgdHlwZXMuIChJIHdvdWxkIGhh
dmUgdG8gc3R1ZHkgdGhlIHByb3RvY29sIHJlYWxseSBoYXJkIHRvIGlkZW50aWZ5IGlmIGFueSBt
ZXNzYWdlIHR5cGVzIGNhbiBiZSBmb2xkZWQgdG9nZXRoZXIgYW5kIHJlY29nbmlzZWQgYnkgY29u
dGVudCByYXRoZXIgdGhhbiB0eXBlIGVmZmljaWVudGx5LiBUaGlzDQogSSBkbyBub3QgZXhwZWN0
IHRvIGRvLikgQWdhaW4gYSB0cmFkZW9mZi4gVGhpcyBvbmUgaXMgaW4gZGlzY3Vzc2lvbiBzcGFj
ZSwgdGhvdWdoIHRoYXQgbmVlZHMgcGVvcGxlIHdobyB1bmRlcnN0YW5kIGJvdGggc2lkZXMgb2Yg
dGhlIGlzc3VlLCBpbmNsdWRpbmcgdGhlIGRldGFpbHMgb2YgdGhlIGJpZGlyZWN0aW9uYWxpdHkg
bWVjaGFuaXNtLiBPZiBjb3Vyc2UsIGFzIGhhcyBiZWVuIHNhaWQsIHdlIG5lZWQgb25lIG9mIHRo
b3NlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5JIGhhdmVuJ3QgZmluaXNoZWQgbXkgcmV2aWV3IG9mIHRoZSBsYXRlc3QgZHJhZnQsIGFu
ZCBJIGRvbid0IGdldCB0aGUgbmVjZXNzaXR5IG9mIEFja1JlcSBhbmQgdGhlIGNvcnJlc3BvbmRp
bmcgbXVsdGljYXN0IFJSRVAgeWV0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgcG9zc2libGUsIHRoaXMg
JnF1b3Q7b3B0aW9uYWwmcXVvdDsgZmllbGQgc2hvdWxkIGJlIGF2b2lkZWQuJm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpUbyBnaXZlIGFuIG92ZXJ2aWV3IG9mIEFj
a1JlcSBhbmQgUlJFUDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+U2luY2UgQU9EVnYyIHJlcXVp
cmVzIGJpZGlyZWN0aW9uYWwgbGlua3MsIHRoaXMgaXMgdGhlIHdheSB0byBkZXRlcm1pbmUgaWYg
YSBsaW5rIGlzIGJpZGlyZWN0aW9uYWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QS0tLS1CLS0tLUM8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjEp
IEEgc2VuZHMgUlJFUSwgQiBmb3J3YXJkcyBpdCwgQyByZWNlaXZlcyB0aGUgUlJFUS4gQiBhbmQg
QyBib3RoIGluc3RhbGwgYSByb3V0ZSB0byBPcmlnQWRkciBidXQgdGhleSBkb250IHlldCBrbm93
IGlmIGl0J3MgdmFsaWQgYmVjYXVzZSB0aGV5IGRvbnQga25vdyBpZiB0aGUgbGluayB0byB0aGVp
ciBuZXh0IGhvcCBpcyBhdmFpbGFibGUgaW4gdGhlIHJldmVyc2UgZGlyZWN0aW9uLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+MikgQyBjcmVhdGVzIHRoZSBSUkVQLiBTaW5jZSBpdCBkb2VzbnQga25vdyBpZiB0aGUgbGlu
ayB0byBCIGlzIGJpZGlyZWN0aW9uYWwsIGl0IGluY2x1ZGVzIHRoZSBBY2tSZXEgKGFuIGFkZHJl
c3MgdG8gaW5kaWNhdGUgdGhhdCBpdCBleHBlY3RzIHRvIHJlY2VpdmUgYSBSUkVQX0FjayBmcm9t
IEIpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+MykgQiByZWNlaXZlcyB0aGUgUlJFUCwgaW5zdGFsbHMgYSByb3V0ZSB0
byBUYXJnQWRkciBhbmQgbWFya3MgaXQgYXMgdmFsaWQsIHNpbmNlIGl0IGtub3dzIHRoZSBsaW5r
IHRvIEMgaXMgYmlkaXJlY3Rpb25hbCwgYmVjYXVzZSB0aGUgUlJFUSB3ZW50IGluIG9uZSBkaXJl
Y3Rpb24gYW5kIHRoZSBSUkVQIGNhbWUgaW4gdGhlIG90aGVyLiBCIGFsc28gc2VuZHMgdGhlIFJS
RVBfQWNrIHRvIEMgYW5kIGZvcndhcmRzDQogdGhlIFJSRVAgdG8gQSAoYW5kIG1pZ2h0IGNoYW5n
ZSB0aGUgbWVzc2FnZSB0byBpbmRpY2F0ZSBpdHMgb3duIEFja1JlcSAtIGllIHRoYXQgaXQgcmVx
dWlyZXMgYW4gYWNrIGZyb20gQSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40KSBDIHJlY2VpdmVzIHRoZSBSUkVQX0Fj
ayBmcm9tIEIsIGFuZCB0aGVyZWZvcmUga25vd3MgdGhhdCBCIHJlY2VpdmVkIHRoZSBSUkVQLCB0
aGVyZWZvcmUgdGhlIGxpbmsgaXMgYmlkaXJlY3Rpb25hbC4gQyBjYW4gdGhlbiBtYXJrIGl0cyBy
b3V0ZSB0byBPcmlnQWRkciBhcyB2YWxpZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjUpIFNpbWlsYXJseSwgQSByZWNl
aXZlcyB0aGUgUlJFUCwgaW5zdGFsbHMgdGhlIHJvdXRlIHRvIFRhcmdBZGRyIGFuZCBzZW5kcyBh
biBSUkVQX0FjayB0byBCLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NikgQiByZWNlaXZlcyB0aGUgUlJFUF9BY2sgYW5k
IG1hcmtzIGl0cyByb3V0ZSB0byBPcmlnQWRkciBhcyB2YWxpZC48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkFsdGVybmF0aXZlbHksIGluIHN0ZXAgMiwg
aWYgQyBrbm93cyB0aGUgbGluayB0byBCIGlzIGJpZGlyZWN0aW9uYWwgKHBlcmhhcHMgZnJvbSBz
b21lIGVhcmxpZXIgcm91dGUgZGlzY292ZXJ5KSwgaXQgZG9lc250IG5lZWQgdG8gcHV0IHRoZSBB
Y2tSZXEgaW4gdGhlIFJSRVAuIFRoZW4gaW4gc3RlcCAzLCBzaW5jZSBCIGRvZXNudCBrbm93IGlm
IHRoZSBsaW5rDQogdG8gQSBpcyBiaWRpcmVjdGlvbmFsLCBpdCBjaGFuZ2VzIHRoZSBtZXNzYWdl
IHRvIGFkZCB0aGUgQWNrUmVxIGFkZHJlc3MsIGluIG9yZGVyIHRvIGdldCBhbiBSUkVQX0FjayBm
cm9tIEEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPklmIHdlIHdhbnQgdG8gYXZvaWQgY2hhbmdp
bmcgdGhlIG1lc3NhZ2UsIHdlJ2xsIG5lZWQgdG8gbG9vayBhdCBmb3J3YXJkaW5nIHRoZSBSUkVQ
IGFzLWlzLCBhbmQgY3JlYXRpbmcgYSBzZWNvbmQgbWVzc2FnZSB0byBzb2xpY2l0IGFuIFJSRVBf
QWNrLCBpbiBvcmRlciB0byB2ZXJpZnkgdGhhdCB0aGUgbGluayBpcyBiaWRpcmVjdGlvbmFsIGJl
Zm9yZSBtYXJraW5nDQogdGhlIHJvdXRlIHRvIE9yaWdBZGRyIGFzIHZhbGlkLiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktp
bmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlZpY3RvcmlhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox
Mi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu
MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZWdhcmRzPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkppYXppPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h
cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3
RTdFIj4tLTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFs
IEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9y
aWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNC
RUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0
NSUyMDI0MjE5NCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPiYj
NDM7NDQNCiAoMCkxMjQ1IDI0MjE5NDwvc3Bhbj48L2E+Jm5ic3A7Jm5ic3A7fCAmbmJzcDs8Yj5F
OiZuYnNwOzwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20i
IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5jaHJpcy5kZWFybG92
ZUBiYWVzeXN0ZW1zLmNvbTwvc3Bhbj48L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVs
bXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBD
TTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdl
dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29t
L2FpPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0
ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xh
bmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3Vy
cmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwO1ZpY3RvcmlhIE1lcmNpZWNhIFttYWlsdG86PGEg
aHJlZj0ibWFpbHRvOnZtZXJjaWVjYTBAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g
c3R5bGU9ImNvbG9yOnB1cnBsZSI+dm1lcmNpZWNhMEBnbWFpbC5jb208L3NwYW4+PC9hPl0mbmJz
cDs8YnI+DQo8Yj5TZW50OjwvYj4mbmJzcDsyMyBBcHJpbCAyMDE2IDEwOjU1PGJyPg0KPGI+VG86
PC9iPiZuYnNwO0NocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KPGI+Q2M6PC9iPiZuYnNwOzxhIGhy
ZWY9Im1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g
c3R5bGU9ImNvbG9yOnB1cnBsZSI+aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzwvc3Bhbj48L2E+OyBE
ZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5n
IGxpc3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiZuYnNwO1JlOiBbbWFu
ZXRdIE1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBtZXNzYWdlIG11dGFiaWxpdHkgKHdhcyBSRTogZHJh
ZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJ
dGVtcyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAy
LjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz
dHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln
bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8
L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxp
Z246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0
aWFsO2JhY2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCUiPg0K
PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ug
b3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4g
ZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPGJyPg0KQ29uc2lkZXIgY2FyZWZ1bGx5
IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1l
bnRzIG9yIHJlcGx5Ljxicj4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcmbmJzcDs8L3NwYW4+
PC9pPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8
L3NwYW4+PC9pPjwvYj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIi
PiZuYnNwO3RoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzDQogeW91IHJlY2VpdmUs
IGNsaWNrJm5ic3A7PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9o
b3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIiB0
YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aGVyZTwvc3Bhbj48L2E+
Ljxicj4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93
Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdv
cmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNp
b3VzJTIwRW1haWxzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw
bGUiPnRoaXMgcHJvY2Vzczwvc3Bhbj48L2E+Ljwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBDaHJp
cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXNlIGhhdmUgYm90aCBiZWVuIGluIHRoZSBkcmFmdCBp
biBzb21lIGZvcm0gc2luY2UgYmVmb3JlIEkgZ290IGludm9sdmVkLi4uIGJ1dCBJJ2xsIGRvIG15
IGJlc3QgdG8gZXhwbGFpbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gRm9yIFZhbGlkaXR5IFRpbWUs
IGl0cyBhIHdheSB0byBhZHZlcnRpc2UgdGhhdCB5b3Ugd291bGQgb25seSBzdXBwb3J0IHRoZSBy
b3V0ZSBjb250YWluZWQgaW4gdGhlIG1lc3NhZ2UgZm9yIGEgY2VydGFpbiBwZXJpb2Qgb2YgdGlt
ZS4gVGhlIG9yaWdpbmF0b3IgbWlnaHQgdXNlIHRoaXMsIGJ1dCB0aGUgZHJhZnQgd2FzIHdyaXR0
ZW4gdG8gYWxsb3cgYW55IGludGVybWVkaWF0ZSBub2RlIHRvIGJlIGFibGUNCiB0byBhZGQgaXQg
b3IgdXBkYXRlIGl0IHRvby4gVGhlIHJvdXRlIGNyZWF0ZWQgaW4gdGhlIExvY2FsIFJvdXRlIFNl
dCBoYXMgYW4gZXhwaXJhdGlvbiB0aW1lIGFzc29jaWF0ZWQgd2l0aCBpdCwgYmFzZWQgb24gdGhl
IHJlY2VpdmVkIHZhbGlkaXR5IHRpbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEZvciB0aGUgQWNrUmVxIGFkZHJl
c3MsIGl0cyBzbyB0aGF0IHlvdSBjYW4gYWRkIGludG8gYSBSUkVQIGEgcmVxdWVzdCBmb3IgYW4g
YWNrbm93bGVkZ2VtZW50LCBzbyB0aGF0IHlvdSBkb24ndCBoYXZlIHRvIGhhdmUgYSBkaWZmZXJl
bnQgbWVzc2FnZSB0eXBlIGFsdG9nZXRoZXIgZm9yIHdvcmtpbmcgb3V0IHdoZXRoZXIgbGlua3Mg
dG8gbmVpZ2hib3JzIGFyZSBiaWRpcmVjdGlvbmFsLCBhbmQgYWxzbywgc2luY2UNCiB5b3Ugb25s
eSBjYXJlIGFib3V0IGJpZGlyZWN0aW9uYWxpdHkgb24gcm91dGVzIHRoYXQgYXJlIGJlaW5nIHNl
dCB1cCwgeW91IGRvbnQgbmVlZCB0byBjb25zdGFudGx5IG1vbml0b3IgYWxsIG5laWdoYm9ycy48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBvcmRlciB0byBh
dm9pZCB0aGUgcG90ZW50aWFsIEFja1JlcS1yZWxhdGVkIGNoYW5nZXMgdG8gZWFjaCBtZXNzYWdl
LCBtYXliZSB3ZSBkbyBuZWVkIHRvIGludHJvZHVjZSBhIGRpZmZlcmVudCBtZXNzYWdlIHNwZWNp
ZmljYWxseSBmb3IgdGhpcy4gV2UgY291bGQgbWF5YmUgdXNlIFJSRVBfQWNrIHRvIGJvdGggcmVx
dWVzdCBhbmQgYWNrbm93bGVkZ2U/IEl0IG1lYW5zIGFuIGV4dHJhIG1lc3NhZ2Ugb2YgY29udHJv
bA0KIHRyYWZmaWMgdGhhdCBuZWVkcyB0byBiZSBzZW50LCBtYXliZSBvbmUgZXh0cmEgbWVzc2Fn
ZSBwZXIgaG9wIG9uIHRoZSBwYXRoIG9mIGEgUlJFUCwgYnV0IGl0IGNvdWxkIHN0aWxsIGJlIGxp
bWl0ZWQgdG8gbmVpZ2hib3JzIHdoaWNoIGhhdmUgcGFydGljaXBhdGVkIGluIHRoZSByb3V0ZSBk
aXNjb3ZlcnkgcmF0aGVyIHRoYW4gbW9uaXRvcmluZyBhbGwgbmVpZ2hib3JzIGF0IGFsbCB0aW1l
cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBtZXNzYWdlIGNvdWxkIG1h
eWJlIGFsc28gaW5jbHVkZSAmcXVvdDtJJ20gaGFwcHkgdG8gcm91dGUgYW55d2hlcmUgZm9yIGEg
Y2VydGFpbiBhbW91bnQgb2YgdGltZSZxdW90Oywgc29ydCBvZiBsaWtlIHdpbGxpbmduZXNzIGlu
IE9MU1IvT0xTUnYyLiBTbyBpbnN0ZWFkIG9mIGhhdmluZyBhIHZhbGlkaXR5IHRpbWUgcGVyIHJv
dXRlLCBpdHMgYSB2YWxpZGl0eSB0aW1lIHBlciBuZWlnaGJvci4gVGhlbiwgZm9yIFJSRVENCiBh
bmQgUlJFUCwgb25seSB0aGUgbWV0cmljIHZhbHVlIHdvdWxkIGNoYW5nZSBpbiB0cmFuc2l0LCBh
cyBkaXNjdXNzZWQuIEhvd2V2ZXIsIHRoYXQgbGVhZHMgdG8gc29tZSBpc3N1ZXMgd2l0aCBkZWNp
ZGluZyB3aGF0IGEgcm91dGUncyBleHBpcmF0aW9uIHRpbWUgaXMuIFlvdSBtaWdodCBrbm93IGhv
dyBsb25nIHRoZSBuZXh0IGhvcCByb3V0ZXIgaXMgdmFsaWQgZm9yLCBidXQgd2hhdCBpZiBhIHJv
dXRlciBiZXlvbmQgdGhhdCwgd2hpY2ggd2FzDQogYWxzbyBwYXJ0IG9mIHRoZSByb3V0ZSwgaGFk
IGEgbG93ZXIgdmFsaWRpdHkgdGltZT8gWW91IGNvdWxkbid0IGRldGVybWluZSB0aGUgcmVhbCB2
YWxpZGl0eSB0aW1lLiBEbyB3ZSByZW1vdmUgdGhlIHJvdXRlIGV4cGlyYXRpb24gdGltZSBhbHRv
Z2V0aGVyIHRvIGF2b2lkIHRoaXMgaXNzdWU/IEluIHdoaWNoIGNhc2UsIHdlIHdvdWxkIGhhdmUg
dG8gcmVseSBvbiBSRVJSIG1lc3NhZ2VzIGJlaW5nIHNlbnQgZm9yIHJvdXRlcyB3aGljaCBiZWNv
bWUNCiBpbnZhbGlkIHdoZW4gdGhlIG5laWdoYm9yJ3MgdmFsaWRpdHkgdGltZSBoYXMgZXhwaXJl
ZD8gU28gbmVpZ2hib3IgdmFsaWRpdHkgdGltZSBleHBpcmF0aW9uIGlzIHRyZWF0ZWQgdGhlIHNh
bWUgYXMgYSBsaW5rIGJyZWFrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGRvIHlv
dSB0aGluaz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2luZCByZWdhcmRzLDxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+VmljdG9yaWEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPk9uIFNhdCwgQXByIDIzLCAyMDE2IGF0IDE6MDkgQU0sIENocmlzdG9waGVyIERl
YXJsb3ZlICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrIiB0
YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2hyaXNAbW5lbW9zeW5l
LmRlbW9uLmNvLnVrPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QcmV0dHkgbXVjaCBh
bGwgb2YgdGhlIGRpc2N1c3Npb24gaGFzIGJlZW4gYXNzdW1pbmcgb25seSBhIG1ldHJpYyB2YWx1
ZSBjaGFuZ2UuIFdpdGggbXVsdGlwbGUgdGhpbmdzIGNoYW5naW5nIG1hbnkgb2YgdGhlIGlkZWFz
IGdvIG91dCBvZiB0aGUgd2luZG93LiBUaGF0IHJlaW5mb3JjZXMgdGhlIHBvaW50IGFib3V0IG5v
dCBtYWtpbmcgc3BlY2lmaWNhdGlvbnMgbm93IHRoYXQgbWlnaHQgdHVybiBvdXQgdG8gYmUNCiB3
cm9uZyBmb3IgSUNWcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWdub3JpbmcgaG93IHRo
aXMgbWlzdW5kZXJzdGFuZGluZyBoYXBwZW5lZCwgSSdsbCBzdGFydCBieSBhc2tpbmcgd2h5LiBN
ZXRyaWMgY2hhbmdpbmcgSSB1bmRlcnN0YW5kLiBXaHkgdGhlIG90aGVyIHR3bz8gKHRoZXJlJ3Mg
YSBwYXJ0aWFsIGV4cGxhbmF0aW9uIG9mIG9uZSkuIFdoYXQgYWx0ZXJuYXRpdmVzIGhhdmUgcGVv
cGxlIGltcGxlbWVudGVkIGluIGNvbXBhcmFibGUgcHJvdG9jb2xzPzxicj4NCjxicj4NCi0tICZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkNocmlzdG9waGVyIERlYXJsb3ZlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86Y2hy
aXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9
ImNvbG9yOnB1cnBsZSI+Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tPC9zcGFuPjwvYT4m
bmJzcDsoaVBob25lKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOmNocmlzQG1uZW1vc3luZS5k
ZW1vbi5jby51ayIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNo
cmlzQG1uZW1vc3luZS5kZW1vbi5jby51azwvc3Bhbj48L2E+Jm5ic3A7KGhvbWUpPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAyMyBBcHIgMjAxNiwgYXQg
MDA6MjYsIFZpY3RvcmlhIE1lcmNpZWNhICZsdDs8YSBocmVmPSJtYWlsdG86dm1lcmNpZWNhMEBn
bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj52bWVy
Y2llY2EwQGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5IaSBhbGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbnRpbnVl
ZCBpbiB0aGlzIHRocmVhZCBiZWNhdXNlIHRoZSBvdGhlciBvbmUgc2VlbXMgdG8gYmUgbW9yZSBh
Ym91dCBUTFYgdHlwZXMgYW5kIG1ldHJpYyB0eXBlIG51bWJlcnMsIHdoZXJlYXMgdGhpcyBpcyBh
Ym91dCByZWdlbmVyYXRpb24vZm9yd2FyZGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
VG8gcmVjYXAsIGluIHRoZSBjdXJyZW50IGRyYWZ0LCB0aGVyZSBhcmUgMyB0aGluZ3MgdGhhdCBt
aWdodCBjaGFuZ2UgYXQgZWFjaCBob3A6Jm5ic3A7PGJyPg0KLSB0aGUgbWV0cmljIHZhbHVlICho
YXBwZW5zIGluIFJSRVEgYW5kIFJSRVApLCZuYnNwOzxicj4NCi0gYWRkaW5nL2NoYW5naW5nIFZh
bGlkaXR5IFRpbWUgdXNpbmcgdGhlIFZhbGlkaXR5IFRpbWUgVExWIChjYW4gaGFwcGVuIGluIFJS
RVEgYW5kIFJSRVApLCZuYnNwOzxicj4NCi0gYWRkaW5nIGFuIGFkZHJlc3MgKGFuZCBjb3JyZXNw
b25kaW5nIHZhbHVlIGluIHRoZSBBZGRyZXNzVHlwZSBUTFYgdG8gaW5kaWNhdGUgaG93IHRvIGlu
dGVycHJldCB0aGUgYWRkcmVzcykgdG8gaW5kaWNhdGUgdGhlIGFkZHJlc3MgZnJvbSB3aGljaCBh
biBSUkVQX0FjayBpcyBleHBlY3RlZCwgdG8gYWNjb21wbGlzaCB0aGUgYmlkaXJlY3Rpb25hbGl0
eSBjaGVjayAoY2FuIGhhcHBlbiBpbiBSUkVQKS48YnI+DQo8YnI+DQpJZiB3ZSBkZWZpbmUmbmJz
cDthIGNlcnRhaW4gcG9ydGlvbiBvZiB0aGUgbWVzc2FnZSBhcyBpbW11dGFibGUgYW5kIGluY2x1
ZGUgdGhlIElDViB0byB2ZXJpZnkgdGhhdCBwYXJ0LCBlbmQgdG8gZW5kOiZuYnNwOzxicj4NCi0g
VGhlIG1ldHJpYyB2YWx1ZSB3b3VsZCBiZSBleGNsdWRlZCBmcm9tIHRoZSBJQ1Ygc2luY2UgaXQg
bmVlZHMgY2hhbmdpbmcgYXQgZWFjaCBob3AuJm5ic3A7PGJyPg0KLSBXb3VsZCBhZGRpbmcgYSBW
YWxpZGl0eSBUaW1lIFRMViBhdCBhbiBpbnRlcm1lZGlhdGUgaG9wIGJlIGFjY2VwdGFibGU/IFRo
ZSB3aG9sZSBUTFYgY291bGQgYmUgcmVtb3ZlZCBpbiBvcmRlciB0byBjYWxjdWxhdGUgdGhlIElD
Vj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+LSBXb3VsZCBhZGRpbmcgYW4gYWRkcmVzcyBjYXVzZSBpc3N1ZXMgZm9yIHRoZSBJQ1Ys
IGJlY2F1c2UgaXQncyBpbiB0aGUgYWRkcmVzcyBibG9jaz8gQ291bGQgdGhlIHJ1bGUgYmUgJnF1
b3Q7aWYgaXQgY29udGFpbnMgYW4gQWNrUmVxIGFkZHJlc3MsIHJlbW92ZSBpdCAoYW5kIHRoZSBj
b3JyZXNwb25kaW5nIHZhbHVlIGluIHRoZSBBZGRyZXNzVHlwZSBUTFYpLCBiZWZvcmUgY2hlY2tp
bmcgdGhlIElDViZxdW90OywgaXMgdGhhdA0KIE9LPyBPciB3b3VsZCB3ZSBuZWVkIHRvIGF2b2lk
IHRvdWNoaW5nIHRoZSBJQ1YnZWQgcGFydCBvZiB0aGUgbWVzc2FnZSBhbHRvZ2V0aGVyLCBtYXli
ZSBwdXQgdGhlIEFja1JlcSBhZGRyZXNzIGluIGEgc2VwYXJhdGUgQWRkcmVzcyBCbG9jaywgd2l0
aCBhbiBleHRyYSBBZGRyZXNzVHlwZSBUTFYgZm9sbG93aW5nIHRoYXQgYWRkcmVzcyBibG9jaz8g
SXMgdGhlcmUgYSB3YXkgdG8gYWNjb21wbGlzaCB0aGlzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5BbHNvLCB0byBiZSB0aG9yb3VnaCwgZG8gd2UgbmVlZCB0byBjb25zaWRlciBSRVJSIG1l
c3NhZ2VzIHdoaWxlIHdlIGRpc2N1c3MgcmVnZW5lcmF0aW9uIHZzIGZvcndhcmRpbmc/Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4tIFJFUlIgKHNlbnQgd2hlbiBhIGxpbmsgYnJlYWtzKSBpcyBhIHdheSBvZiBz
YXlpbmcgJnF1b3Q7SSd2ZSBsb3N0IG15IHJvdXRlIHNvIEknbSB0ZWxsaW5nIG90aGVycyZxdW90
OyBhbmQgJnF1b3Q7eW91IHdlcmUgbXkgbmV4dCBob3AsIHNvJm5ic3A7bm93Jm5ic3A7SSd2ZSBh
bHNvIGxvc3QgbXkgcm91dGUsIEknbGwgdGVsbCBvdGhlcnMmcXVvdDssIGV0Yy4gSXQncyBnb2lu
ZyB0byBiZSB0YWlsb3JlZCBhdCBlYWNoIHN0ZXAgdG8gaW5jbHVkZSB0aGUgcmVsZXZhbnQNCiBy
b3V0ZXMgdGhhdCBnb3QgZGVsZXRlZCwgaXQncyBub3Qgb25lIG1lc3NhZ2UgYmVpbmcgc2VudCBl
bmQtdG8tZW5kIGxpa2UgUlJFUSBhbmQgUlJFUCBhcmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEhvd2V2
ZXIsIFJFUlIgKHNlbnQgd2hlbiBhIHNvdXJjZSBvZiB0cmFmZmljIGlzIHNlbmRpbmcgZGF0YSBv
biBhIHJvdXRlIHdoaWNoIGNvbWVzIHRocm91Z2ggeW91LCBhbmQgeW91IHdhbnQgdG8gdGVsbCB0
aGUgUGFja2V0IFNvdXJjZSdzIHJvdXRlciB0byBkZWxldGUgdGhlIHJvdXRlKSBjb3VsZCBiZSBz
ZWVuIGFzIGFuIGVuZC10by1lbmQgbWVzc2FnZSB3aGljaCBhbGwgaW50ZXJtZWRpYXRlIHJvdXRl
cnMNCiBsZWFybiBmcm9tLCBzaW1pbGFyIHRvIFJSRVEgYW5kIFJSRVAuIEl0IHJlcG9ydHMgb25l
IHJvdXRlLCBhbmQgZG9lc24ndCBuZWVkIGNoYW5naW5nIGF0IGludGVybWVkaWF0ZSBob3BzLCBz
byBjb3VsZCBiZSBwcm90ZWN0ZWQgd2l0aCBJQ1YuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFdvdWxkIGl0IGJlIE9L
IHRvIG9ubHkgcmVxdWlyZSBhIG1lc3NhZ2UgSUNWIGlmIGEgUGt0U291cmNlIGFkZHJlc3Mgd2Fz
IGluY2x1ZGVkLCBpLmUuIHdoZW4gdGhlIG1lc3NhZ2UgbmVlZHMgdG8gZ28gdmlhIGEgbnVtYmVy
IG9mIGludGVybWVkaWF0ZSBob3BzIHRvIFBrdFNvdXJjZSdzIHJvdXRlcj8gQWxsIG90aGVyIFJF
UlJzIGFyZSBpbnRlbmRlZCB0byBiZSBvbmUtaG9wIG1lc3NhZ2VzLCB3aGljaCBtYXkNCiBpbiB0
dXJuIHByb21wdCBvdGhlciBvbmUtaG9wIG1lc3NhZ2VzLCBldGMuLi4sIGFuZCBhIHBhY2tldCBJ
Q1YgbWlnaHQgYmUgbW9yZSBhcHByb3ByaWF0ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LaW5kIHJl
Z2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPlZpY3RvcmlhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgMTcsIDIw
MTYgYXQgNToyNiBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWV0ZkB0aG9tYXNj
bGF1c2VuLm9yZzwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAx
NyBNYXIgMjAxNiwgYXQgMTg6MTcsIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspICZsdDs8YSBo
cmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5r
Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNv
bTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzLCBJIG1lYW50IEFPRFZ2Miwg
dGhhbmtzIGZvciB0aGUgY2F0Y2guPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBpcyB5b3VyIChUaG9tYXMpIHBy
b3Bvc2VkIGJhc2Ugc3BlY2lmaWNhdGlvbiBhIGhvcCBjb3VudCBvbmx5IG1ldHJpYz88L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vLCB0
aGUgd291bGQgYmUgc2lsbHkgYXMgYmFzZSBzcGVjaWZpY2F0aW9uLCBnaXZlbiB0aGF0IGhvcCBj
b3VudCBtb3N0bHkgaXMgdXNlbGVzcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgYmFz
ZSBzcGVjaWZpY2F0aW9uIEkgd291bGQgc2ltcGx5IHNheSDigJxJbmNsdWRlIGEgTWV0cmljIFR5
cGUgTWVzc2FnZSBUTFYgd2l0aCBhIHZhbHVlIGZpZWxkLCBhbmQgYSA3MTgyIE1lc3NhZ2UgVExW
ICZhbXA7IFRpbWVzdGFtcOKAnSBhcyB3ZSBkbyBpbiBPTFNSdjIgKHdpdGggdGhlIGFwcHJvcHJp
YXRlIHZlcmJpYWdlIGFzIHRvIGdlbmVyYXRpb24gYW5kIHByb2Nlc3NpbmcpLiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIHRoZSBtZXNzYWdlIGdlbmVyYXRlZCBieSB0aGUg
b3JpZ2luYXRvciBvZiB0aGUgUlJFUS9SUkVQIGFuZCAqbm90KiBkZWNvbnN0cnVjdGVkL3JlY29u
c3RydWN0ZWQvcmVvcmRlcmVkIChhcyBpcyB0aGUgcmlzayB3aXRoIOKAnHJlZ2VuZXJhdGlvbikg
YWxsb3dzIGtub3dpbmcgdGhhdCBpdCB3b3VsZCBiZSAqb25seSogdGhhdCBtZXRyaWMgZmllbGQg
YmVpbmcgbW9kaWZpZWQgKG90aGVyIHRoYW4gaG9wIGNvdW50L2xpbWl0KQ0KIGZvciB3aGVuIGV2
ZW50dWFsbHkgd3JpdGluZyB1cCB0aGUgZXh0ZW5zaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
KEFjdHVhbGx5IGRvZXNu4oCZdCB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uIG9ubHkgZGVmaW5l
IGhvcCBjb3VudCwgb3IgaGFzIHRoYXQgY2hhbmdlZCBpbiBsYXRlc3QgZHJhZnQ/KTwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vLiBUaGF0IGlzIG9u
ZSBvZiB0aGUgaXNzdWVzIEkgcmFpc2UgaW4gbXkgb3JpZ2luYWwuIEZvciBzb21lIHJlYXNvbiwg
aXQgY2l0ZXMgUkZDNjU1MSwgd2hpY2ggaXMgYSBST0xMIGRvY3VtZW50IGFuZCB3aGljaCBoYXMg
aW4gaXRzIGFic3RyYWN0IHRoYXQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgTG93LVBvd2VyIGFuZCBMb3Nz
eSBOZXR3b3JrcyAoTExOcykgaGF2ZSB1bmlxdWUgY2hhcmFjdGVyaXN0aWNzPG86cD48L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGNvbXBhcmVkIHdpdGggdHJhZGl0aW9uYWwgd2lyZWQg
YW5kIGFkIGhvYyBuZXR3b3JrcyB0aGF0IHJlcXVpcmUgdGhlPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7IHNwZWNpZmljYXRpb24gb2YgbmV3IHJvdXRpbmcgbWV0cmljcyBhbmQg
Y29uc3RyYWludHMuIDxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SS5lLiB0aGlzIGRvY3VtZW50IGNpdGVzIGEgbWV0
cmljIGRvY3VtZW50IHdoaWNoIGNsZWFybHkgY2xhaW1zIHRvIGJlIGluYXBwbGljYWJsZSBpbiBh
ZCBob2MgbmV0d29ya3MuIEkgbm90ZSB0aGF0IHRoaXMgaXMgYW5vdGhlciB0aGluZyBJ4oCZdmUg
cmFpc2VkIGZvciB5ZWFycyB3aXRob3V0IHNlZWluZyBpdCBhdHRlbXB0ZWQgcmVzb2x2ZWQuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlRob21hczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+
DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRl
bGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDs8YSBocmVmPSJ0ZWw6
JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5NCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl
PSJjb2xvcjpwdXJwbGUiPiYjNDM7NDQNCiAoMCkxMjQ1IDI0MjE5NDwvc3Bhbj48L2E+Jm5ic3A7
Jm5ic3A7fCAmbmJzcDs8Yj5FOiZuYnNwOzwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxv
dmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy
cGxlIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvc3Bhbj48L2E+PGJyPg0KPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQg
SW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBD
aGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lz
dGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5MiI+
d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVk
PGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxk
Zm9yZCwgU3VycmV5LCBHVTIgN1lQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2lu
ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4mbmJzcDs8YSBocmVmPSJtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlldGZAdGhvbWFzY2xhdXNl
bi5vcmc8L3NwYW4+PC9hPiZuYnNwO1s8YSBocmVmPSJtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2Vu
Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpp
ZXRmQHRob21hc2NsYXVzZW4ub3JnPC9zcGFuPjwvYT5dJm5ic3A7PGJyPg0KPGI+U2VudDo8L2I+
Jm5ic3A7MTcgTWFyY2ggMjAxNiAxNzoxMDxicj4NCjxiPlRvOjwvYj4mbmJzcDtEZWFybG92ZSwg
Q2hyaXN0b3BoZXIgKFVLKTxicj4NCjxiPkNjOjwvYj4mbmJzcDtMb3R0ZSBTdGVlbmJyaW5rOyBN
b2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiZu
YnNwO1JlOiBbbWFuZXRdIE1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBtZXNzYWdlIG11dGFiaWxpdHkg
KHdhcyBSRTogZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2Yg
YmlnIHRpY2tldCBJdGVtcyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlk
IGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tn
cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246
Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlO2Jh
Y2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXBvc2l0aW9uLXg6MCU7
YmFja2dyb3VuZC1wb3NpdGlvbi15OjAlIj4NCjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBv
cmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVy
bmV0Ljxicj4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24g
YW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48YnI+DQpGb3IgaW5mb3Jt
YXRpb24gcmVnYXJkaW5nJm5ic3A7PC9zcGFuPjwvaT48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L2I+PGk+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4mbmJzcDt0aGF0IHlvdSBjYW4gbG9vayBvdXQg
Zm9yIGluIGVtYWlscw0KIHlvdSByZWNlaXZlLCBjbGljayZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9p
bnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMv
RG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj
b2xvcjpwdXJwbGUiPmhlcmU8L3NwYW4+PC9hPi48YnI+DQpJZiB5b3UgZmVlbCB0aGUgZW1haWwg
aXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5l
dC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1l
bnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiIHRhcmdldD0iX2Js
YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50aGlzIHByb2Nlc3M8L3NwYW4+PC9hPi48
L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g
MTcgTWFyIDIwMTYsIGF0IDE4OjA0LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFu
ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j
b208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+T0ssIHNvIHdlIGhhdmUgYSBtZXNzYWdlIHRoYXQgbXV0YXRlcyBieTo8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+LSBNb2RpZnlpbmcgaG9wIGNvdW50L2xpbWl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tIE1v
ZGlmeWluZyBhIG1ldHJpYyB2YWx1ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW55dGhpbmcgZWxzZT88
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIG11dGF0aW5nIChv
dGhlciB0aGFuIGhvcCBjb3VudC9saW1pdCkgbWVzc2FnZXMgYXJlbuKAmXQgY292ZXJlZCBieSA1
NDQ0IG9yIGFueSBkZXJpdmF0aXZlIGRvY3VtZW50IChidXQgb25seSByZWNvbW1lbmRlZCBhZ2Fp
bnN0LCBub3QgYmFubmVkKSB0aGF0IHlvdSBtYXkNCiBuZWVkIHRvIG1ha2UgdGhlIG1lc3NhZ2Ug
b3RoZXJ3aXNlIGltbXV0YWJsZSAobm8gZGVjb25zdHJ1Y3Rpb24gYW5kIHJlYnVpbGRpbmcsIG90
aGVyIHRoYW4gZ3VhcmFudGVlZCB1bmNoYW5naW5nKSB0aGF0IHdvdWxkIGhhdmUgdG8gYmUgc3Bl
Y2lmaWVkIGJ5IEFPRFZ2Mi4gKEVhc3kgdG8gc2F5LCBidXQgbmVlZHMgc2F5aW5nLik8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5XaXRoIHlvdSBzbyBmYXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVuIHRoYXQgaW5mb3JtYXRpb24gaXMgbm90IGlu
IGEgZ3VhcmFudGVlZCBmaXhlZCBsb2NhdGlvbiBnaXZlbiBieSBhIHNpbXBsZSBvZmZzZXQuIFNv
IGFueSBzaWduYXR1cmUgYWxnb3JpdGhtIHRoYXQgZmluZHMgaXQgYW5kIGlnbm9yZXMgaXQgb3Ig
YWdncmVnYXRlcw0KIG9uIGl0IGlzIHNwZWNpZmljIHRvIE9MU1J2Mi48L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VyZWx5IHlvdSBtZWFu
IEFPRFZ2MjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
U28gc3RhbmRhcmQgNzE4MiBJQ1ZzIGRvbuKAmXQgZG8gdGhlIGpvYiwgeW91IHdvdWxkIG5lZWQg
YW4gQU9EVnYyIHNwZWNpYWxpc2VkIHZhcmlhbnQuIFdoaWNoIGlzIHRoZSBzb3J0IG9mIHRoaW5n
IHRoYXQgdGhlIG1lc3NhZ2Ugc3BlY2lmaWMgVExWIHNwYWNlIGlzIHRoZXJlDQogZm9yLCBJ4oCZ
ZCBiZSBzdHJvbmdseSBhZ2FpbnN0IGEg4oCcYnV0IGlnbm9yZSB0aGUgdmFsdWUgb2YgdGhpcyBz
cGVjaWZpYyBUTFYgc2hvdWxkIGl0IG9jY3Vy4oCdIGJlaW5nIGluIHRoZSBnZW5lcmFsIHNwYWNl
LiBIb3dldmVyIGl0IGNhbiBlYXNpbHkgYmUgZGVmaW5lZCBieSByZWZlcmVuY2UgdG8gNzE4MiAo
4oCcdGhpcyBUTFYgaXMgbGlrZSB0aGF0IFRMViwgZXhjZXB0IGlmIGFuIFggVExWIGlzIHByZXNl
bnQsIHNldCBpdHMgdmFsdWUgZmllbGQgdG8NCiB6ZXJv4oCdKS48L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1lc3N5LCBidXQgY291bGQgd29yay48L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IHRoYXQg
bWVzc3ksIGFjdHVhbGx5LCBhbHRob3VnaCBjbGVhcmx5IG5vdCBhcyBuaWNlIGFzIOKAnGZpeGVk
IG9mZnNldOKAnS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+VGhhdCBzYWlkLCBJIGFtIGFyZ3VpbmcgZm9yIHRoZSBiYXNlIHNwZWMgYmVp
bmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwO+KAnG1ha2UgdGhlIG1lc3NhZ2Ugb3RoZXJ3aXNlIGltbXV0YWJs
ZSAobm8gZGVjb25zdHJ1Y3Rpb24gYW5kIHJlYnVpbGRpbmcsIG90aGVyJm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGFuIGd1YXJhbnRlZWQgdW5j
aGFuZ2luZynigJ0gd2hpY2ggaXMgYWZmb3JkZWQgYnkgZm9yd2FyZGluZzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtSRkM3
MTgyIFRpbWVzdGFtcHMgYW5kIElDVnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyYjNDM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1JGQzcxODMgc3R5bGUgdGV4dCBicmlu
Z2luZyBpdCBhbGwgdG9nZXRoZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSDigJxhZ2dyZWdhdGVkIHNpZ25hdHVyZXMgYXJvdW5k
IG11dGFibGUgZmllbGTigJ0gd291bGQgdmVyeSBiZSBhbiBleHBlcmltZW50YWwgZXh0ZW5zaW9u
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5XaGF0IEkgb2JqZWN0IHRvIGlzLCBpZiB0aGUgYmFzZSBzcGVjIHNwZWNpZmljYWxseSByZW5k
ZXJzIHN1Y2ggZXh0ZW5zaW9ucyBpbXBvc3NpYmxlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS08L3NwYW4+PC9iPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu
MHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9w
aGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0
ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0Ui
Pjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+
VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5i
c3A7PGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQiIHRhcmdldD0iX2Js
YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mIzQzOzQ0DQogKDApMTI0NSAyNDIxOTQ8
L3NwYW4+PC9hPiZuYnNwOyZuYnNwO3wgJm5ic3A7PGI+RTombmJzcDs8L2I+PGEgaHJlZj0ibWFp
bHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g
c3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+
PC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+
PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUg
U3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmss
IEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJo
dHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9
ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxp
ZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsg
V2FsZXMgTm86IDAxMzM3NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZp
Y2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4w
cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPiZuYnNwO0xvdHRlIFN0ZWVuYnJpbmsgWzxhIGhyZWY9Im1haWx0bzpsb3R0ZS5zdGVlbmJy
aW5rQGZ1LWJlcmxpbi5kZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw
bGUiPm1haWx0bzpsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZTwvc3Bhbj48L2E+XSZuYnNw
Ozxicj4NCjxiPlNlbnQ6PC9iPiZuYnNwOzE3IE1hcmNoIDIwMTYgMTY6NDg8YnI+DQo8Yj5Ubzo8
L2I+Jm5ic3A7RGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk8YnI+DQo8Yj5DYzo8L2I+Jm5ic3A7
PGEgaHJlZj0ibWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmciIHRhcmdldD0iX2JsYW5rIj48
c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZXRmQHRob21hc2NsYXVzZW4ub3JnPC9zcGFuPjwv
YT47IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0PGJyPg0KPGI+U3ViamVjdDo8
L2I+Jm5ic3A7UmU6IFttYW5ldF0gTWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2UgbXV0YWJp
bGl0eSAod2FzIFJFOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBs
ZSBvZiBiaWcgdGlja2V0IEl0ZW1zKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIu
MHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0
eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu
PSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjwv
c3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGln
bjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRp
YWw7YmFja2dyb3VuZC1wb3NpdGlvbi14OjAlO2JhY2tncm91bmQtcG9zaXRpb24teTowJSI+DQo8
aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBv
cmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBl
eHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48YnI+DQpDb25zaWRlciBjYXJlZnVsbHkg
d2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVu
dHMgb3IgcmVwbHkuPGJyPg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyZuYnNwOzwvc3Bhbj48
L2k+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwv
c3Bhbj48L2k+PC9iPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+
Jm5ic3A7dGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMNCiB5b3UgcmVjZWl2ZSwg
Y2xpY2smbmJzcDs8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hv
d3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiIHRh
cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5oZXJlPC9zcGFuPjwvYT4u
PGJyPg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cm
bmJzcDs8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29y
ay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lv
dXMlMjBFbWFpbHMucGRmIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs
ZSI+dGhpcyBwcm9jZXNzPC9zcGFuPjwvYT4uPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I
aSBhbGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW0gMTcuMDMuMjAxNiB1bSAxNzo0NCBzY2hy
aWViIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMu
ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s
b3I6cHVycGxlIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvc3Bhbj48L2E+Jmd0Ozo8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj5Hb29kIHBvaW50IGFib3V0IHdoZXRoZXIgeW91IGp1c3QgcGFzcyBvbiBvbmUgY29z
dCBvciBhIHNldCBvZiBjb3N0cy4gQXMgSSBzYWlkLCBub3QgbG9va2VkIGF0IGRldGFpbHMgLSBJ
IHdpbGwsIHdoZW4gdGltZSBwZXJtaXRzLiBPbmUgY29zdCBpcyBtdWNoIGVhc2llciwNCiBhbmQg
eWVzLCBpdCByZWR1Y2VzIHRoZSBmaXhlZCBzaXplIGFnZ3JlZ2F0ZWQgc2lnbmF0dXJlcyBwcm9i
bGVtIHRvIOKAnGp1c3TigJ0gb25lIG9mIGNvbXB1dGF0aW9uYWwgbG9hZC48L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHRoZSBy
ZWNvcmQsIFRob21hc+KAmSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3Q7IHRoZSBjb3N0IGlzIG9u
ZSBhZ2dyZWdhdGVkIHZhbHVlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C
ZXN0IHJlZ2FyZHMsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5Mb3R0ZSBTdGVlbnJiaW5rPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS08L3NwYW4+PC9iPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVyIERl
YXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFw
cGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N
Cjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4N
Cjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bh
bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7PGEg
aHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQiIHRhcmdldD0iX2JsYW5rIj48
c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj4mIzQzOzQ0DQogKDApMTI0NSAyNDIxOTQ8L3NwYW4+
PC9hPiZuYnNwOyZuYnNwO3wgJm5ic3A7PGI+RTombmJzcDs8L2I+PGEgaHJlZj0ibWFpbHRvOmNo
cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9
ImNvbG9yOnB1cnBsZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPjxi
cj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0K
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVt
cyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0
IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8v
d3d3LmJhZXN5c3RlbXMuY29tL2FpIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y
OiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBs
aWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7
IFdhbGVzIE5vOiAwMTMzNzQ1MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0
b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0
ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1Uy
IDdZUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8YSBocmVmPSJtYWlsdG86
aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPmlldGZAdGhvbWFzY2xhdXNlbi5vcmc8L3NwYW4+PC9hPiZuYnNwO1s8YSBocmVm
PSJtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0
eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3JnPC9zcGFuPjwv
YT5dJm5ic3A7PGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7MTcgTWFyY2ggMjAxNiAxNjozODxicj4N
CjxiPlRvOjwvYj4mbmJzcDtEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4NCjxiPkNjOjwv
Yj4mbmJzcDtNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdDxicj4NCjxiPlN1Ympl
Y3Q6PC9iPiZuYnNwO1JlOiBNZXNzYWdlIGludGVncml0eSBhbmQgbWVzc2FnZSBtdXRhYmlsaXR5
ICh3YXMgUkU6IFttYW5ldF0gZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBj
b3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBi
bGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3Jv
dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNl
bnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZTtiYWNr
Z3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1wb3NpdGlvbi14OjAlO2Jh
Y2tncm91bmQtcG9zaXRpb24teTowJSI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3Jn
YW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5l
dC48YnI+DQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFu
eSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPGJyPg0KRm9yIGluZm9ybWF0
aW9uIHJlZ2FyZGluZyZuYnNwOzwvc3Bhbj48L2k+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9iPjxpPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+Jm5ic3A7dGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZv
ciBpbiBlbWFpbHMNCiB5b3UgcmVjZWl2ZSwgY2xpY2smbmJzcDs8YSBocmVmPSJodHRwOi8vaW50
cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0Rv
Y3VtZW50cy9SZWQlMjBGbGFncy5wZGYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s
b3I6cHVycGxlIj5oZXJlPC9zcGFuPjwvYT4uPGJyPg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlz
IHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cmbmJzcDs8YSBocmVmPSJodHRwOi8vaW50cmFuZXQu
ZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50
cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIiB0YXJnZXQ9Il9ibGFu
ayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dGhpcyBwcm9jZXNzPC9zcGFuPjwvYT4uPC9z
cGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTcgTWFyIDIwMTYsIGF0
IDE3OjMwLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNo
cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9
ImNvbG9yOnB1cnBsZSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPiZn
dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhcHByZWNp
YXRlIFRob21hc+KAmXMgY29tbWVudHMgYWJvdXQgdGhlIGxpbWl0YXRpb25zIG9mIG1lc3NhZ2Ug
cmVnZW5lcmF0aW9uLCBidXQgSSB3b3VsZCBiZSBhIGJpdCBsZXNzIGFic29sdXRlLjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGlzc3VlcyBvdmVyIGVu
ZCB0byBlbmQgYXV0aGVudGljYXRpb24gYW5kIG1vcmUgYWR2YW5jZWQgc2lnbmF0dXJlcyBhcmUg
dmFsaWQuIEkgbmVlZCB0byByZWFkIHRoZSBnaXZlbiByZWZlcmVuY2Ugb24gYWdncmVnYXRlIHNp
Z25hdHVyZXMgdG8gaW5jcmVhc2UgbXkNCiBrbm93bGVkZ2UgKHRoYW5rcyBmb3IgaXQpLCBidXQg
bXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgcG9zc2liaWxpdGllcyBpbiB0aGlzIGZpZWxkIG1heSBv
ZmZlciBhIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtLCBidXQgd2l0aCBzb21lIG90aGVyIGlzc3Vl
cyAocG9zc2libHkgaW5jbHVkaW5nIGEgbmV3IHR5cGUgb2YgVExWKS48L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCB0aGUgaG9wIGNvdW50L2xpbWl0IHBv
aW50IEkgZG9u4oCZdCBmdWxseSBhZ3JlZSB3aXRoLCB5b3UgY2FuIHJlZ2VuZXJhdGUgd2l0aCBh
biBpbmNyZW1lbnRlZC9kZWNyZW1lbnRlZCBjb3VudC9saW1pdCwgd2hpY2ggbGVhdmVzIHRoZSBh
YmlsaXR5IHRvIHByZXZlbnQNCiBtZXNzYWdlcyBwcm9wYWdhdGluZyBpbmRlZmluaXRlbHksIGlu
Y2x1ZGluZyBleHBhbmRpbmcgcmluZyBzZWFyY2hlcywgYW5kIHJldGFpbnMgdGhlIGFiaWxpdHkg
dG8gdXNlIFJGQyA1NDk3IGludGVydmFsIGFuZCB2YWxpZGl0eSB0aW1lcyB0aGF0IG1pZ2h0IGJl
IHVzZWZ1bCB3aXRoIGFuIGV4cGFuZGluZyByaW5nIHNlYXJjaCAob3IgbWlnaHQgbm90KS48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCB0aGUga2V5IGlz
c3VlIGlzIHRoYXQgQU9EVnYyIHdhbnRzIHRvIGFjY3VtdWxhdGUgbWV0cmljcy4gSSBzdGlsbCBo
YXZlbuKAmXQgZ290IHRvIHRoZSBib3R0b20gb2YgbWFueSBkZXRhaWxzIGhlcmUsIGJ1dCBsZXTi
gJlzIGZvciB0aGUgbW9tZW50IGp1c3QgY29uc2lkZXINCiB0aGF0IGNvbmNlcHR1YWxseS48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl04oCZcyBoYXJkIHRv
IGhhbmRsZSBlbmQgdG8gZW5kLiBDaGFybGll4oCZcyBkcmFmdCBhdHRlbXB0cyB0byBkbyBhbiBl
bmQgdG8gZW5kIG9mIHNvbWUgaW5mb3JtYXRpb24sIG5vdCB0aGlzIGluZm9ybWF0aW9uLiBJ4oCZ
bSBub3Qgc3VyZSBpZiB0aGF04oCZcyB1c2VmdWwgKGFuZCB0aGUNCiBzcGVjaWFsaXNlZCBmb3Jt
YXQgaXMgYmV0dGVyIGF2b2lkZWQgaWYgcG9zc2libGUpLiBPdGhlciBhcHByb2FjaGVzIGFyZSBo
b3AgYnkgaG9wIChtaWdodCBhcyB3ZWxsIHVzZSBwYWNrZXQgc2lnbmF0dXJlcykgYW5kIHNoYXJl
ZCBrZXkgKG1pZ2h0IGFzIHdlbGwgZ28gaG9wIGJ5IGhvcCkuIFBhaXJ3aXNlIHNpZ25hdHVyZXMg
Zm9yIGVhY2ggcGFpciBvZiByb3V0ZXJzIEnigJltIGRpc2NvdW50aW5nIGFzIHNjYWxpbmcgdGVy
cmlibHkuIEluIHRoZQ0KIGludGVyZXN0cyBvZiBjb21wbGV0ZW5lc3MgbGV04oCZcyBtZW50aW9u
IG5vdCBhY2N1bXVsYXRpbmcgbWV0cmljcywgd2hpY2ggcHV0cyB1cyBiYWNrIHRvIGhvcCBjb3Vu
dCBhbmQgdGhhdOKAmXMgbm90IGlkZWFsIGVpdGhlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhbiBpZGVhbCBz
b2x1dGlvbi4gKEkgbGlrZSBpZGVhcyBJ4oCZdmUgc2VlbiBhYm91dCBhZ2dyZWdhdGluZywgYnV0
IHRoYXQgaGFzIHNvbWUgaXNzdWVzIG9mIGl0cyBvd24sIGV2ZW4gYXBhcnQgZnJvbSBjb21wdXRh
dGlvbmFsIGxvYWQuKQ0KIEnigJlkIGxvdmUgdG8gYmUgcHJvdmVkIHdyb25nIC0gc29tZW9uZSB3
aXRoIHRoZSBwZXJmZWN0IHNvbHV0aW9uIHRvIGNvbWUgYWxvbmcuPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGljaCBtZWFucyB0aGF0IGVpdGhlciB3ZSBt
YWtlIGFuIGFyYml0cmFyeSBjaG9pY2UgLSB3aGljaCB3aWxsIGJlIGRpc2FncmVlZCB3aXRoLCBi
dXQgbmVlZHMgZGlzY3Vzc2luZyBmaXJzdCAtIG9yIGNyZWF0ZSBzb21ldGhpbmcgZmxleGlibGUu
IFVuZm9ydHVuYXRlbHkNCiBmbGV4aWJsZSBpbiB0aGF0IHJlZ2FyZCBjb25zdHJhaW5zIGluIG90
aGVycywgZS5nLiBzb21lIChtYW55PyBtb3N0PykgYWdncmVnYXRpbmcgc2lnbmF0dXJlcyBuZWVk
IGZpeGVkIGRhdGEgc2l6ZXMgKHdoaWNoIHdlIGNhbiBkbyBieSBkZWZpbmluZyBhIFRMViB0aGF0
IOKAnGZpbGxzIHVw4oCdIHdpdGggaG9wIGNvdW50LCBidXQgdGhhdCBoYXMgYSBjb3N0IHRvbyku
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIGJlZW4gdG9sZCBieSBwZW9wbGUgbXVj
aCBtb3JlIHdlbGwgdmVyc2VkIGluIHRoaXMgdGhhbiBJIGluIGNyeXB0b2xvZ3ksIHRoYXQgdGhl
IGNvcnJlY3QgYW5zd2VyIGlzIOKAnHNvbWXigJ0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgc2FpZCwgJnF1b3Q7QU9EVnYy
IHdhbnRzIHRvIGFjY3VtdWxhdGUgbWV0cmljc+KAnSDigJQgZG9lcyB0aGF0IG1lYW4gdGhhdCB0
aGUgbWVzc2FnZSBncm93cyBhcyBpdCBpcyBiZWluZyBmb3J3YXJkZWQsIGFuZCB0aGF0IHRoZSBy
ZWNpcGllbnQgb2YgYSBSUkVRL1JSRVAgd2lsbCBrbm93IHRoZSBpbmRpdmlkdWFsIGNvc3RzIG9m
IGVhY2ggcGF0aCBzZWdtZW50PyBNeSB1bmRlcnN0YW5kaW5nIGlzLCB0aGF0IHRoZSByZWNpcGll
bnQNCiB3aWxsIGdldCDigJx0aGUgc3VtIHRoZSBjb3N0cyBvZiBlYWNoIHBhdGggc2VnbWVudOKA
nSB3aGljaCBzaG91bGQgYmUgZml0dGluZyB3aXRoaW4gYSBmaXhlZCBzaXplPzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaG9tYXM8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5Tb3JyeSwgbm8gYW5zd2VycywganVzdCBjb21tZW50cy4gQW5kIEnigJltIG5vdCBhZGRy
ZXNzaW5nIFRob21hc+KAmXMgbGF0ZXIgcG9pbnRzIGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92
ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVk
IEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3Nw
YW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOzxhIGhyZWY9
InRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g
c3R5bGU9ImNvbG9yOnB1cnBsZSI+JiM0Mzs0NA0KICgwKTEyNDUgMjQyMTk0PC9zcGFuPjwvYT4m
bmJzcDsmbmJzcDt8ICZuYnNwOzxiPkU6Jm5ic3A7PC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5k
ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv
cjpwdXJwbGUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT48YnI+DQo8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBw
bGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRk
b3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5i
YWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4
QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFw
cGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFt
cDsgV2FsZXMgTm86IDAxMzM3NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThC
OTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBT
dXJyZXksIEdVMiA3WVA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp
bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPiZuYnNwO21hbmV0IFs8YSBocmVmPSJtYWlsdG86bWFuZXQtYm91bmNlc0BpZXRm
Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpt
YW5ldC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dJm5ic3A7PGI+T24NCiBCZWhhbGYgT2Ym
bmJzcDs8L2I+PGEgaHJlZj0ibWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmciIHRhcmdldD0i
X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZXRmQHRob21hc2NsYXVzZW4ub3Jn
PC9zcGFuPjwvYT48YnI+DQo8Yj5TZW50OjwvYj4mbmJzcDsxNyBNYXJjaCAyMDE2IDE2OjAwPGJy
Pg0KPGI+VG86PC9iPiZuYnNwO01vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0PGJy
Pg0KPGI+U3ViamVjdDo8L2I+Jm5ic3A7W21hbmV0XSBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0x
MyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIu
MHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50
ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJOSU5H
ICoqKjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4
dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZTtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFs
IGluaXRpYWw7YmFja2dyb3VuZC1wb3NpdGlvbi14OjAlO2JhY2tncm91bmQtcG9zaXRpb24teTow
JSI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVz
c2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJv
bSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48YnI+DQpDb25zaWRlciBjYXJl
ZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0
YWNobWVudHMgb3IgcmVwbHkuPGJyPg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyZuYnNwOzwv
c3Bhbj48L2k+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBG
bGFnczwvc3Bhbj48L2k+PC9iPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMz
Mzk3MiI+Jm5ic3A7dGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMNCiB5b3UgcmVj
ZWl2ZSwgY2xpY2smbmJzcDs8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMu
Y29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5w
ZGYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5oZXJlPC9zcGFu
PjwvYT4uPGJyPg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBm
b2xsb3cmbmJzcDs8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hv
d3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1
c3BpY2lvdXMlMjBFbWFpbHMucGRmIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y
OnB1cnBsZSI+dGhpcyBwcm9jZXNzPC9zcGFuPjwvYT4uPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdpbmRv
d3RleHQgMS4wcHQ7cGFkZGluZzoxLjBwdCA0LjBwdCAxLjBwdCA0LjBwdCI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij4qPGI+KiombmJzcDs8L2I+PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PldBUk5JTkcmbmJzcDs8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qKio8L3NwYW4+PC9iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lk
ZSBvdXIgb3JnYW5pemF0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ljwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBhbGwsPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5BcG9sb2dpZXMgZm9yIG5vdCBoYXZpbmcgZ290dGVuIHRoaXMgZG9u
ZSBzb29uZXIgLSBkYXktam9iIGxlYXZpbmcgZmV3IHNwYXJlIGN5Y2xlcy48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmXZlIHByZXZpb3VzbHkgb2ZmZXJlZCByZXZpZXdzIGFu
ZCBjb21tZW50cywgYW5kIHNvbWUgb2YgdGhvc2UgaGF2ZSBiZWVuIGFkZHJlc3NlZCBpbiB0aGUg
bGF0ZXN0IEktRCDigJQgb3RoZXJzIGhhdmUgbm90LCBidXQgc2hvdWxkIGJlLiBJIHJlY2FsbCB0
aGF0IHRoZXJlIHdhcyBzb21lIG1haWwgYXR0ZW1wdGluZyB0byByZWJ1dCBwYXJ0cyBvZiB0aGUg
cmV2aWV3LCBhbmQgSSB3aWxsIGRpZyBpdCBvdXQgYW5kDQogcmVwbHkgdG8gdGhhdC48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2l0aCB0aGF0IGJlaW5nIHNhaWQsIEkgaGF2ZSBy
ZXZpZXdlZCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LCBhbmQgZnVsbCBkZXRh
aWxzIHdpbGwgYmUgZm9ydGhjb21pbmcuIFRoZXJl4oCZcmUgYSBjb3VwbGUgb2YgYmlnLXRpY2tl
dC9hcmNoaXRlY3R1cmFsIGl0ZW1zIHRoYXQgSSB3YW50IHRvIGFkZHJlc3MgdXAgZnJvbnQsIGFz
IEkgYmVsaWV2ZSB0aGF0IGJlZm9yZSB3ZSBoYXZlIHRob3NlDQogaGFtbWVyZWQgb3V0LCBpdCB3
aWxsIGJlIHVzZWxlc3MgdG8gZ28gaW50byBkZXRhaWxzLiBOb3RlLCBJIGRvIG5vdCBjbGFpbSB0
aGF0IHRoaXMgaXMgYW4gZXhoYXVzdGl2ZSBsaXN0IG9mIOKAnGJpZyB0aWNrZXQgaXRlbXPigJ0s
IGJ1dCB0aGF04oCZcyBhcyBmYXIgYXMgSSBoYXZlIGdvdHRlbiBpbiB0aGlua2luZyB0aGlzIHRo
cm91Z2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyBicmluZyB0aGVz
ZSB1cCBhcyB0aGV5IGFyZSBpdGVtcyB0aGF0IGhhdmUgYmVlbiBicm91Z2h0IHVwIHJlcGVhdGVk
bHkgb3ZlciB0aGUgcGFzdCB5ZWFycywgYnV0IG5vdCByZXNvbHZlZCBub3IgZGlzY3Vzc2VkLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48dT5Mb29wczwvdT48L2I+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5KdXN0IHRvIGJyaW5nIHRoaXMgb3V0OiBJIHNoYXJlIENocmlz4oCZIHdvcnJ5IGFi
b3V0IGNvbmZsaWN0aW5nIGFuZCBjb25jdXJyZW50IHN0YXRlbWVudHMgZnJvbSB0aGUgYXV0aG9y
cyBvbiDigJxUaGVyZSBhcmUgbm8gbG9vcHMgcG9zc2libGXigJ0gYW5kIOKAnFdlIG5lZWQgdG8g
Zml4IHR3byBzaXR1YXRpb25zIHdoZXJlIGxvb3BzIGNhbiBvY2N1cuKAnSBhbmQg4oCcd2UgYXJl
IHN0aWxsIGludmVzdGlnYXRpbmcgc29tZSBsb29wDQogY29uZGl0aW9uc+KAnTxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHBhcnRpY3VsYXJseSB3b3JyeSB0aGF0IHRoaXMgaXMg
bm90IGEgZGlzY3Vzc2lvbiBoYWQgaW4gcHVibGljLCBidXQgYXBwYXJlbnRseSBpbiBzb21lIG90
aGVyIGZvcnVt4oCmPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxiPjx1PkludGVybWVkaWF0ZSBSb3V0ZSBSZXBsaWVzLCBhbmQgYWxs
IG9mIHNlY3Rpb24gMTA8L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlvbiAxMCBjb250YWlucyBh
IHNldCBvZiDigJx2YWd1ZWx5IHNwZWNpZmllZCBleHRlbnNpb25z4oCdLCB3aGljaCBpcyBpbmNv
aGVyZW50IHdpdGggdGhlIGludGVuZGVkIHN0YXR1cyBpbmRpY2F0ZWQgZm9yIHRoaXMgZG9jdW1l
bnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZWNpZmljYWxseSwg
YW5kIHRoaXMgaXMgbm90IHVucmVsYXRlZCB0byB0aGUgcG9pbnQgYWJvdXQgbG9vcHMgYWJvdmUs
IGludGVybWVkaWF0ZSBSUkVQcyAoc2VjdGlvbiAxMC4zKSBhcmUgYSBwb3RlbnRpYWwgc291cmNl
IGZvciBsb29wcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXhwYW5kaW5nIFJp
bmcgTXVsdGljYXN0IChzZWN0aW9uIDEwLjEpIGlzIG5vdCBkb2N1bWVudGVkIGluIGEgd2F5IHRo
YXQgY2FuIGJlIGltcGxlbWVudGVkIChhbmQgYWxzbywgc2VlIOKAnEZvcndhcmRpbmctdnMtcmVn
ZW5lcmF0aW9u4oCdIGJlbG93LCBpdCBpcyBpbiB0aGUgcHJlc2VudCBmb3JtIG9mIHRoaXMgcHJv
dG9jb2wgaW1wb3NzaWJsZSksIGV0Yy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjx1PkZvcndhcmRpbmctdnMtcmVnZW5lcmF0
aW9uPC91PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlY2VudCBleGNoYW5nZXMgb24gdGhlIGxpc3QgbWFk
ZSBtZSB1bmRlcnN0YW5kIHRoYXQgcHJvdG9jb2wgY29udHJvbCBtZXNzYWdlcyBhcmUgKm5vdCog
Zm9yd2FyZGVkLCBidXQgYXJlIGNvbnN1bWVkIGF0IGVhY2ggaG9wLCB0aGVuIGEgbmV3IG1lc3Nh
Z2Ugd2l0aCAoYWxtb3N0LWJ1dC1ub3QtcXVpdGUpIHRoZSBzYW1lIGNvbnRlbnQgaXMgZ2VuZXJh
dGVkIGFuZCB0cmFuc21pdHRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBo
YXZlIHRob3VnaHQgc29tZSBtb3JlIG9uIHRoaXMgKCZhbXA7IHJlYWQgc29tZSBvZiB0aGUgZXhj
aGFuZ2VzIG9uIHRoZSBsaXN0IG9uIHRoaXMgdG9waWMgYnkgQ2hyaXMsIFVscmljaCwgYW5kIG90
aGVycyksIGFuZCBJIGFtIGNvbnZpbmNlZCB0aGF0IHRoaXMgaXMgbm90IHRoZSByaWdodCB3YXkg
dG8gZ28sJm5ic3A7PGI+YXQgbGVhc3Q8L2I+Jm5ic3A7Zm9yIHRoZSBmb2xsb3dpbmcgcmVhc29u
czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDtvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7PGI+SXQgcmVuZGVycyB0aGUgaG9wLWxpbWl0L2hvcC1jb3VudCBm
aWVsZHMgaW4gdGhlIFJGQzU0NDQgbWVzc2FnZSBoZWFkZXIgdXNlbGVzcy48L2I+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGlzIHdvdWxkIG5vdCBiZSBiYWQg
aWYgdGhlIGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBieSB0aG9zZSBmaWVsZHMgd2FzIG5vdCB1c2Vm
dWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO+KAlCBzYWRseSwg
aXQgaXMuIEZvciBleGFtcGxlLCBmb3Igc2NvcGUgbGltaXRlZCBmbG9vZGluZyAoZXhwYW5kaW5n
IHJpbmcgc2VhcmNoLCBhbmQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwO3N1Y2gpIHdoaWNoIG1heSBiZSBvZiBpbnRlcmVzdCwgYW5kIHdoaWNoIHJlcXVp
cmUgaG9wLWxpbWl0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7QSBob3AtY291bnQgZmllbGQgbWF5IGFsc28gcHJvdmlkZSBhIOKAnGNoZWFw4oCdIChp
biB0ZXJtcyBvZiBvdmVyaGVhZCkgYWRkaXRpb25hbCBwaWVjZTxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7b2YgaW5mb3JtYXRpb24gdG8gdXNlIGNvbmp1bmN0aXZl
bHkgd2l0aCBhIOKAnHJlYWzigJ0gbWV0cmljLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgb25seSBwcmFjdGljYWwgc29s
dXRpb24gd291bGQgYmUgdG8gcmUtaW50cm9kdWNlIHRoZXNlIGZ1bmN0aW9ucyBieSB3YXkgb2Yg
aW5zZXJ0aW5nIGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO01l
c3NhZ2VUTFYg4oCUIHdoaWNoIChpKSBpcyBub3Qgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQs
IGFuZCAoaWkpIHdoaWNoIHdvdWxkIGp1c3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwO3NlcnZlIHRvIHJlbmRlciBtZXNzYWdlcyBiaWdnZXIgdGhhbiBzdHJpY3Rs
eSBuZWVkZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO1Njb3BlIGxpbWl0ZWQgZmxvb2RpbmcgJm5ic3A7ZG9lcyBzZWVtIHRv
IGJlIGEgbmVjZXNzYXJ5IHJlcXVpcmVtZW50LCBpZiBmb3Igbm88bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO290aGVyIHJlYXNvbiB0aGFuIHRvIHByZXZlbnQgaW5m
b3JtYXRpb24gZnJvbSDigJxjaXJjdWxhdGluZyBmb3JldmVyIGluIHRoZSBuZXR3b3Jr4oCdLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGI+PHU+
SXQgbWFrZXMgZW5kLXRvLWVuZCBhdXRoZW50aWNhdGlvbiB1bm5lY2Vzc2FyaWx5IGhhcmQuPC91
PjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0kgdGhpbmsg
Q2hyaXMgY2FsbGVkIHRoaXMgb3V0IGFscmVhZHksIGJ1dCBpdCBiZWFycyByZXBlYXRpbmc6IFMg
Z2VuZXJhdGVzIGEgbWVzc2FnZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7KHNheSwgYSBSUkVRKSwgYW5kIGluY2x1ZGVzIGFuIElDViBjYWxjdWxhdGVk
IG92ZXIgdGhlIGNvbnRlbnQgb2YgdGhlIG1lc3NhZ2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDtGb3IgYW55IHJlY2lwaWVudCB0byBiZSBhYmxlIHRvIHZhbGlk
YXRlIHRoZSBJQ1YsIHRoZSBtZXNzYWdlIGhhcyB0byBiZSBleGFjdGx5PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgc2FtZSDigJQgbm90IGp1c3QgaW4gY29u
dGVudCwgYnV0IGluIHN0cnVjdHVyZSDigJQgYXMgd2hhdCB3YXMgZ2VuZXJhdGVkLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvi
gJxSZWdlbmVyYXRpbmfigJ0gcmF0aGVyIHRoYW4g4oCcZm9yd2FyZGluZ+KAnSBtZXNzYWdlcyBt
ZWFucywgdGhhdCB0aGUgaW50ZXJtZWRpYXRlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDtyb3V0ZXIg4oCccmVnZW5lcmF0aW5n4oCdIHRoZSBSUkVRIG1heSBjaG9z
ZSBhIGRpZmZlcmVudCBzdHJ1Y3R1cmUgKGUuZy4sIGluY2x1ZGUgVExWczxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aW4gYSBkaWZmZXJlbnQgb3JkZXIpLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDtUaGUgcHJvcG9zYWwgZnJvbSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1wZXJraW5zLW1hbmV0LWFvZHYtZTJlc2VjLTAwIiB0YXJnZXQ9Il9ibGFuayI+
PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LXBlcmtpbnMtbWFuZXQtYW9kdi1lMmVzZWMtMDA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aXMgdG8gYWRkIGNvbnN0cmFpbnRzIG9uIChp
KSB0aGUgc2V0IG9mIGVsZW1lbnRzIHRvIGluY2x1ZGUgaW4gYSBzaWduYXR1cmUgYW5kIChpaSkg
dGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvcmRlciBvZiB0
aGVzZSBlbGVtZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7T25lJm5ic3A7cHJvYmxlbSB3aXRoIHRoYXQgYXBwcm9hY2gg
aXMgKGkpOiBpZiBhbiBleHRlbnNpb24gYWRkcyBhIG1lc3NhZ2UgVExWLCBvciBhbiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QWRkcmVzcyBUTFYsIHRv
IGEgbWVzc2FnZSwgdGhlbiB0aGF0IHdpbGwgbm90IGJlIOKAnGNvdmVyZWTigJ0gYnkgdGhlIHBy
b3Bvc2VkIGUyZXNlYyBUTFYuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDtSYXRoZXIgZm9yICplYWNoKiBleHRlbnNpb24gZGV2ZWxvcGVkLCBhbiDigJx1cGRhdGVz
IGUyZXNlY+KAnSBjbGF1c2UgbmVlZHMgdG8gYmUgZG9uZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SeKAmWQgc2F5IHRoYXQg
dGhpcyBhcHByb2FjaCB3b3VsZCBiZSBwcm9uZSB0byBlcnJvcnMg4oCUIGFuZCBhZGQgZW50cm9w
eSB0byB0aGUgcHJvY2VzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7b2YgZGVzaWduaW5nIHByb3RvY29sIGV4dGVuc2lvbnMuIFRoZSBhbHRlcm5hdGl2ZSwgYSBt
ZXNzYWdlIGJlaW5nIGdlbmVyYXRlZCBieSB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO3NvdXJjZSBhbmQgKmZvcndhcmRlZCogKGFzIHdlIGRvIGluIE9MU1J2
MiwgZm9yIGV4YW1wbGUpIHdvdWxkIGFsbG93IElDViBUTFZzJm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsoZXZlbiwgYWxsb3cgcmV1c2Ugb2YgdGhvc2Ug
c3BlY2lmaWVkIGZvciBPTFNSdjIpIGZvciBjb3ZlcmluZyBhIG1lc3NhZ2UgYW5kJm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtleHRlbnNpb25zLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDvigJxCdXQgd2hhdCBhYm91dCB0aGUgbWV0cmljcyB2YWx1ZSB3aGljaCB3aWxsIGNoYW5nZSBv
biBlYWNoIGhvcOKAnSwgeW91IG1heSBzYXk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDtGb3J0dW5hdGVseSwgdGhhdCBpcyByZWxhdGl2ZWx5IGVhc3kgdG8gaGFu
ZGxlOiBzaW1wbHkgemVybyBvdXQgdGhlIHZhbHVlIG9mIHRoYXQgVExWIHdoZW48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2dlbmVyYXRpbmcgb3IgdmVyaWZ5aW5n
IHRoZSBJQ1YgTWVzc2FnZVRMVi4gQW5kIHVzZSBQYWNrZXQtVExWcyBmb3IgaG9wLWJ5LWhvcCZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YXV0aGVudGlj
YXRpb24sIGlmIG5lZWRlZCAoYnV0LCBzZWUgYmVsb3cpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGI+PHU+SXQgcHJldmVudHMgdGhlIHVzZSBv
ZiBtb3JlIGNsZXZlci9hZHZhbmNlZCBzaWduYXR1cmUgc2NoZW1lcy9JQ1ZzPC91PjwvYj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0FnZ3JlZ2F0ZSBzaWduYXR1
cmUgYWxnb3JpdGhtcyAoJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9jcnlwdG8uc3RhbmZvcmQuZWR1
L35kYWJvL3BhcGVycy9hZ2dzdXJ2ZXkucGRmIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9
ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9jcnlwdG8uc3RhbmZvcmQuZWR1L35kYWJvL3BhcGVycy9h
Z2dzdXJ2ZXkucGRmPC9zcGFuPjwvYT4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDtleGlzdCwgYW5kIGFuIGludGVyZXN0aW5nIHVzZS1jYXNlIGNhbiBiZSBmb3Vu
ZCBpbiBhbHNvIHJlYWN0aXZlIHByb3RvY29scywgYWxsb3dpbmcgdmVyaWZ5aW5nPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtub3Qg4oCcanVzdOKAnSB0aGUgZW5k
IHBvaW50cywgYnV0IGFsc28gdGhlIGludGVybWVkaWFyaWVzIChhZ2Fpbiwgd2l0aCB0aGUgYXBw
cm9wcmlhdGUg4oCcemVybyBvdXTigJ08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwO2Rpc2N1c3NlZCBhYm92ZSwgb3Igc29tZXRoaW5nIHNtYXJ0ZXIpLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UmVnZW5lcmF0aW9uIG9mIG1lc3Nh
Z2VzLCByYXRoZXIgdGhhbiBmb3J3YXJkaW5nLCByZW5kZXJzIHRoYXQgaW1wb3NzaWJsZSAob3Is
IGlmIHVzZWQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt1cGRh
dGluZyB0byAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
cGVya2lucy1tYW5ldC1hb2R2LWUyZXNlYy0wMCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl
PSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wZXJraW5z
LW1hbmV0LWFvZHYtZTJlc2VjLTAwPC9zcGFuPjwvYT4pPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPlRoZXJlIGFyZSBvdGhlciByZWFzb25zLCBidXQgdGhlIGFib3ZlIGFyZSB0aG9z
ZSB0aGF0IGp1bXAgYXQgbWUgYXMgaW1tZWRpYXRlIHNob3ctc3RvcHBlcnMuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gaG9uZXN0bHkgbm90IHNlZSB3aGF0IHBvc3NpYmxl
IGJlbmVmaXQgdGhlcmUgaXMgZnJvbSDigJxyZWdlbmVyYXRpb27igJ0g4oCUIGJ1dCBJIHNlZSB2
ZXJ5IGNsZWFyIGluY29udmVuaWVuY2VzLCBhbmQgc2VjdXJpdHkgaXMgbm90IHRoZSBsZWFzdCBv
ZiB0aGVzZS4gSW5zaXN0aW5nIG9uIOKAnHJlZ2VuZXJhdGlvbuKAnSByZXF1aXJlcyBkZXZlbG9w
bWVudCBvZiDigJxub24tZ2VuZXJhbCB3b3JrYXJvdW5kc+KAnSBhcyBwb2ludGVkDQogb3V0IGFi
b3ZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48dT5TZWN1cml0eSBDb25z
aWRlcmF0aW9uczwvdT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGFuIGFsd2F5cyB0aG9ybnkg
c3ViamVjdC4gV2hlbiBPTFNSdjIgd2FzIGdvaW5nIHRocm91Z2ggdGhlIHByb2Nlc3Mgd2UgZ290
IGEgdGhvcm91Z2ggZWR1Y2F0aW9uIGluIGhvdyBsaXR0bGUgd2Uga25ldyBhYm91dCBzZWN1cml0
eSBmcm9tIHRoZSBTRUMtQURzLCBhbmQgaGFkIHRvIHNwZW5kIGFib3V0IGEgeWVhciBvciBzbyBk
ZXZlbG9waW5nIFJGQzcxODMuIFRoZSBib3R0b20gbGluZSBpcywgdGhhdA0KIHRoaXMgcHJvdG9j
b2wgbmVlZHMgaXRzIOKAnFJGQzcxODMgJm5ic3A7ZXF1aXZhbGVudOKAnSwgZWl0aGVyIGFzIHBh
cnQgb2YgdGhlIG1haW4gZG9jdW1lbnQsIG9yIGFzIGFuIGluZGVwZW5kZW50IGRvY3VtZW50LiBj
dXJyZW50bHksIHRoYXQgaXMgbm90IHRoZSBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5BIG1pbmltYSwgbG9va2luZyBhdCBCQ1A3MiBhbmQgQkNQMTA3IOKAlCB0YWtpbmcg
aW5zcGlyYXRpb24gZnJvbSBSRkM3MTgzIG1pZ2h0IGJlIGF3IGdvb2QgaWRlYSwgYXMgdGhhdCB3
YXMgdGhlIG1vc3QgcmVjZW50IHRoYXQgd2VudCB0aHJvdWdoIHRoZSBTRUMgQUQuIFJlZ2FyZGxl
c3Mgb2YgaG93LCBob3dldmVyLCBhIOKAnG1hbmRhdG9yeSB0byBpbXBsZW1lbnTigJ0gc2VjdXJp
dHkgbWVjaGFuaXNtIG1vc3QgYmUgc3BlY2lmaWVkDQogKEkgdGhpbmsgdGhlIHJpZ2h0IHRlcm0g
d2FzIOKAnE1VU1QgaW1wbGVtZW50LCBTSE9VTEQgdXNl4oCdKSwgaW4gc3VmZmljaWVudCBkZXRh
aWwgdG8gZW5zdXJlIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBhbiBleGFtcGxlLCBib3RoIFtSRkM2MTMwXSBhbmQgW1JG
QzcxODFdIHNldCBvdXQgdGhhdCB0aGF0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgT24gcmVjZWl2aW5nIGEgLi4uIG1lc3NhZ2Us
IGEgcm91dGVyIE1VU1QgZmlyc3QgY2hlY2sgaWYgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i
c3A7ICZuYnNwOyBtZXNzYWdlIGlzIGludmFsaWQgZm9yIHByb2Nlc3NpbmcgYnkgdGhpcyByb3V0
ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIHRoZW4gcHJvY2VlZCB0byBn
aXZlIGEgbnVtYmVyIG9mIGNvbmRpdGlvbnMgdGhhdCwgZWFjaCwgd2lsbCBsZWFkIHRvIGEgcmVq
ZWN0aW9uIG9mIHRoZSBtZXNzYWdlIGFzICZxdW90O2JhZGx5IGZvcm1lZCBhbmQgdGhlcmVmb3Jl
IGludmFsaWQgZm9yIHByb2Nlc3NpbmfigJ0g4oCUIGEgbGlzdCB3aGljaCBSRkM3MTgzIHRoZW4g
YW1lbmRlZC4gVGhhdCBnYXZlIGEg4oCcaG9va+KAnSBmb3IgUkZDNzE4MyBmb3IgaW5zZXJ0aW5n
DQog4oCccmVqZWN0aW9u4oCdLiBJZGVtIGZvciBtZXNzYWdlIGdlbmVyYXRpb24uPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIEkgd2FzIHRvIGRvIFJGQzcxODEvUkZDNjEzMCB0
b2RheSwgSSB3b3VsZCBpbmNsdWRlIHRoYXQgZGlyZWN0bHkgaW50byB0aGUgcHJvdG9jb2wgc3Bl
Y2lmaWNhdGlvbnMuIEl0IHR1cm5lZCBvdXQgdG8gYmUgbW9yZSBvdmVyaGVhZCAoYW5kIHNsb3cg
ZG93biBwdWJsaWNhdGlvbiBhbnl3YXlzKSB0byBkbyBpdCBhcyBzZXBhcmF0ZSBkb2N1bWVudHMu
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2Vjb25kbHksIHdlIG5l
ZWQgdG8gYmUgYSBsb3QgbW9yZSByaWdpZCBpbiB0ZXJtcyBvZiB3aGF0IElDVnMsIFRpbWVzdGFt
cHMsIGV0Yy4gYXJlIGFkZGVkL3JlbW92ZWQsIGFuZCB3aGF0IHRoYXQgYnJpbmdzLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgZXhhbXBsZSAod2l0aCB0aGUgYXNzdW1wdGlv
biB0aGF0IG1lc3NhZ2VzIGFyZSAqZm9yd2FyZGVkKiBhbmQgKm5vdCogcmVnZW5lcmF0ZWQpLCB0
aGlzIGNvdWxkIGJlIG9uZSBvcHRpb246PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO28mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtXaGVuIGEgUlJFUSwgUlJFUCBtZXNz
YWdlIGlzIGdlbmVyYXRlZCwgYWRkIGFuIElDViBNZXNzYWdlIFRMViwgd2hpY2ggaXMgY2FsY3Vs
YXRlZCAmbHQ7dGhpcyB3YXkmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvigKYodGFrZSBpbnNwaXJhdGlvbiBmcm9tIFJG
QzcxODMgaGVyZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu
MHB0Ij4uLi48YnI+DQo8YnI+DQpbTWVzc2FnZSBjbGlwcGVkXSZuYnNwOyZuYnNwOzxicj4NCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQg
bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9
Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFuZXRAaWV0Zi5vcmc8L3NwYW4+
PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bWFuZXQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9zcGFuPjwvYT48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i
bWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y
OnB1cnBsZSI+bWFuZXRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj48c3Bh
biBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL21hbmV0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwPioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KVGhpcyBlbWFp
bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJy
Pg0KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0
aGUgaW50ZW5kZWQ8YnI+DQpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lz
dGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+DQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9y
IHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPg0KZGlzdHJpYnV0ZSBp
dHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+DQoqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv
bToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0
QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFu
ZXRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s
b3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9z
cGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFp
bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo
cmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhy
ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0i
X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B15E3GLKXM0002VGREEN_--


From nobody Mon Apr 25 07:54: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 7FCF612D156 for ; Mon, 25 Apr 2016 07:54:15 -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 s7g-XUj-txBU for ; Mon, 25 Apr 2016 07:54:05 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 A4AF012D61A for ; Mon, 25 Apr 2016 07:54:05 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id t10so216288708ywa.0 for ; Mon, 25 Apr 2016 07:54:05 -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=D079YavZiG+muu/KK3/XkPNyRCSYfu9qu14AlNj1cCk=; b=jF4KkwbpCAXCgywo80H8lwLcRf6r7nEaqtFyD3OS2ghNlRG+p1CZQDHjWndSi8F/iA EpiUe97ujsOiE7GysuaAlmx82Uaw4ITNtzBsTTVPDvO1lguEevv3Ec9Sau+jDFF7Ewm3 ORD56QfKEKJCxM+NJmpIjHQecWLkNMn9OdbTlMVGIjV/bdjkLlXpUt9vls8kJzamK5bX s6ln6envNMem24268gpf/lx7GwbuyYTjUSzi1woyF+UwBXpkhyV1Nc4/mLqISRsGW8H/ b40wE47zT/q/M8Uwyj/VnwMqTsSmLtc/Nro1f/2Y5NnCC7osGIJgXkjmSRjtWNmIDMUu xDuQ==
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=D079YavZiG+muu/KK3/XkPNyRCSYfu9qu14AlNj1cCk=; b=EUWhsHcfCTA6jDuRaZqSqTANBhUV+cuD5NNxWP8RODW3ysJmarSSjkuljqTXJ4ZqM1 tqo8eLGCcBqAM25P44KvyahDqzRC8C3Pulm8Z+1BMKrH3WPJbFPkB54oY2psRPG1JLVS NQB1uVL4q4BMrpGCdYRW/H3ZvSFPkkOO99JPAbPll55eFw47pTV4/FPVkcYPQ6h+jHuT MO1D7JOIeSOnE5G/2qocGcNs9aXIQFcgNN7YRCGgtu4MVSIqKtnSd39J+pvRuHRcr4i/ vCgCsz/rOTtYE3K1+XMH/Ks0fHwCHuunvOiMPbSY3kmpROsuvMRYSkkuLF3aKAxw9niA Dt0g==
X-Gm-Message-State: AOPr4FUQoc1O1qgXrk58fExXI5dCjVK7Qhs5sorEWgpfwq8s+vUx7Rw5teUPqu1/c9tndm/hfIBH8XGZXNgO8A==
MIME-Version: 1.0
X-Received: by 10.176.1.108 with SMTP id 99mr12578834uak.54.1461596044927; Mon, 25 Apr 2016 07:54:04 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Mon, 25 Apr 2016 07:54:04 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>          
Date: Mon, 25 Apr 2016 10:54:04 -0400
Message-ID: 
From: Justin Dean 
To: Thomas Heide Clausen 
Content-Type: multipart/alternative; boundary=001a113d0cd4102cf005315059ce
Archived-At: 
Cc: Christopher Dearlove , Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 14:54:15 -0000

--001a113d0cd4102cf005315059ce
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 25, 2016 at 10:37 AM, Thomas Heide Clausen <
ietf@thomasclausen.org> wrote:

>
>
> On 25 avr. 2016, at 16:32, Justin Dean  wrote:
>
>
>
> On Mon, Apr 25, 2016 at 10:28 AM,  wrote:
>
>>
>> On 25 Apr 2016, at 16:20, Justin Dean  wrote:
>>
>> A thought regarding integrity checking.  A possible future "fix" for
>> integrity could be done on a "virtual" packet in which known TLVs/values
>> along with ordered addresses are uncompressed and then verified.  It cou=
ld
>> allow extra TLV tagging without modifying the validity of that data.  Th=
e
>> very big drawback would be the overhead of having to uncompressed
>> everything to check the validity.  It's functionally the same as zeroing
>> out local (this is my stuff) TLV data vs remote (this is not my stuff) T=
LV
>> data.
>>
>>
>> That requires an imposed ordering of addresses, address TLVs, Message
>> TLVs, etc., even if only =E2=80=9Cin memory=E2=80=9D, it is something th=
at everybody should
>> be aware of, and doing the same way
>>
>> o That ordering would have to be specified in this document (no, it
>> would not be a =E2=80=9Cfuture fix=E2=80=9D, this is
>> a requirement to the base spec, since *not* doing that would mean that
>> this =E2=80=9Cfuture fix=E2=80=9D could render
>> current implementations non-compliant!)
>>
>> If you're building the virutal packet you could specify the order there,
> the on the wire packet doesn't need to be in that order.
>
>
>
> No idea what a virtual packet is.
>
> But imposing a point of universal agreement on how *any* packet - now or
> in the future - uncompresses  is not a trivial task.
>
>
o While this would be *hard* for the current messages/TLVs, I=E2=80=99d ima=
gine
>> that it=E2=80=99d make extensions
>> impossible (in an interoperable fashion).
>>
>> Not at all if the integrity check in question only used well known
> registred TLVs (i.e. don't change the value of these!) types for building
> the virutal packet then you could add whatever other TLV info you wanted.
>
>
> If I understand you correctly, then you would do the ICV only over some o=
f
> the packet content? In other words, any extensions would be unprotected, =
OR
> would require an update to whatever records the "known TLVs" list?
>

Correct extensions which didn't register wouldn't be protected.  It's
essentially the same as zeroing out unknown TLVs so lets go with that as
it's easier.

Those extensions in the case of AODVv2 are fundamentally different than
OLSRv2/NHDP messages as they do not contain information about the
originating router.  I get that this is an issue with current integrity
checking methods but there is value in having that data included in the
same message.  Local only information could be sent in another message
which would be locally signed.  That would work for AckReq messages but it
wouldn't work for information about the "path" traveled as there would be
no way of verifying or even associating that information with the data
contained in the original message.

Justin

>
>
That to me is a showstopper, similar to M. Perkins' E2E draft, to be
> designing an extensible protocol specifically so that extensions are
> "unsecured". We can and must. do better than that.
>
>
>
>> o It=E2=80=99d be *exceptionally* heavy for all intermediate routers, wa=
nting to
>> verify the integrity of a
>> message: to be able to force everybody in a network to =E2=80=9Cunwrap=
=E2=80=9D the
>> message into an
>> uncompressed form *before* validating its origins is opening up for DoS
>> attacks.
>>
>> I want to do a *minimum* number of operations with a message, *before*
>> deciding
>> to discard a message as harmful.
>>
>> This is true enough it'd be hell on processing.
>
>
> Indeed. There are many reasons why this is a bad idea.
>
> Thomas.
>
>

--001a113d0cd4102cf005315059ce
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Apr 25, 2016 at 10:37 AM, Thomas Heide Clausen <ietf@thom=
asclausen.org> wrote:


On 25 avr. 2016, at 16:32, Justin Dean=
 <bebemaster@g=
mail.com> wrote:



On =
Mon, Apr 25, 2016 at 10:28 AM,  <ietf@thomasclausen.org> wrote:

On 25 Apr 2016, at 16:20, Justi=
n Dean <bebema=
ster@gmail.com> wrote:

A thought rega=
rding integrity checking.=C2=A0 A possible future "fix" for integ=
rity could be done on a "virtual" packet in which known TLVs/valu=
es along with ordered addresses are uncompressed and then verified.=C2=A0 I=
t could allow extra TLV tagging without modifying the validity of that data=
.=C2=A0 The very big drawback would be the overhead of having to uncompress=
ed everything to check the validity.=C2=A0 It's functionally the same a=
s zeroing out local (this is my stuff) TLV data vs remote (this is not my s=
tuff) TLV data. =C2=A0

That requ=
ires an imposed ordering of addresses, address TLVs, Message TLVs, etc., ev=
en if only =E2=80=9Cin memory=E2=80=9D, it is something that everybody shou=
ld be aware of, and doing the same way

	o	That ordering would have to be specified in this document (no, it woul=
d not be a =E2=80=9Cfuture fix=E2=80=9D, this is=C2=A0
		a requirement to the base spec, since *=
not* doing that would mean that this =E2=80=9Cfuture fix=E2=80=9D could ren=
der
		current impleme=
ntations non-compliant!)

If you=
're building the virutal packet you could specify the order there, the =
on the wire packet doesn't need to be in that order.
=C2=A0

No idea what a virt=
ual packet is.=C2=A0

But imposing a point of universal a=
greement on how *any* packet - now or in the future - uncompresses =C2=A0is=
 not a trivial task.=C2=A0
=C2=A0
=

	o	While this would be *hard* for the current messa=
ges/TLVs, I=E2=80=99d imagine that it=E2=80=99d make extensions
<=
span style=3D"white-space:pre-wrap">		impossible (in an interoperabl=
e fashion).

Not at all if the i=
ntegrity check in question only used well known registred TLVs (i.e. don=
9;t change the value of these!) types for building the virutal packet then =
you could add whatever other TLV info you wanted.

If I understand you correctly, then you wou=
ld do the ICV only over some of the packet content? In other words, any ext=
ensions would be unprotected, OR would require an update to whatever record=
s the "known TLVs" list? =C2=A0
=C2=
=A0
Correct extensions which didn't register wouldn't be =
protected.=C2=A0 It's essentially the same as zeroing out unknown TLVs =
so lets go with that as it's easier.

Those extensions in the cas=
e of AODVv2 are fundamentally different than OLSRv2/NHDP messages as they d=
o not contain information about the originating router.=C2=A0 I get that th=
is is an issue with current integrity checking methods but there is value i=
n having that data included in the same message.=C2=A0 Local only informati=
on could be sent in another message which would be locally signed.=C2=A0 Th=
at would work for AckReq messages but it wouldn't work for information =
about the "path" traveled as there would be no way of verifying o=
r even associating that information with the data contained in the original=
 message.

Justin
=C2=A0
That to me is a showstopper, si=
milar to M. Perkins' E2E draft, to be designing an extensible protocol =
specifically so that extensions are "unsecured". We can and must.=
 do better than that.=C2=A0

=
=C2=A0
	o	It=E2=80=99d be *exceptionally* heavy f=
or all intermediate routers, wanting to verify the integrity of a=C2=A0
		message: to be able to=
 force everybody in a network to =E2=80=9Cunwrap=E2=80=9D the message into =
an=C2=A0
		uncompress=
ed form *before* validating its origins is opening up for DoS attacks.=C2=
=A0

		=
I want to do a *minimum* number of operations with a message, *before* deci=
ding=C2=A0
		to disca=
rd a message as harmful.

This i=
s true enough it'd be hell on processing.=C2=A0
=


Indeed. There are many reasons why this i=
s a bad idea.=C2=A0

Thomas.=C2=A0



--001a113d0cd4102cf005315059ce--


From nobody Mon Apr 25 07:59:59 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 DBD8312D1B0 for ; Mon, 25 Apr 2016 07:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.143
X-Spam-Level: 
X-Spam-Status: No, score=-1.143 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, TRACKER_ID=1.306] 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 whlP17heXMod for ; Mon, 25 Apr 2016 07:59:48 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002: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 20C7C12D10A for ; Mon, 25 Apr 2016 07:59:48 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id t10so216693646ywa.0 for ; Mon, 25 Apr 2016 07:59:48 -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=K6acDlM7oT51womuzfwx6i6sFsxqhs3iYWlD+rEP5HY=; b=VPhPqdOcfoy3hp1F5hUEMC9PV8NXFEsRXNj5mbHJ+7WZg0f1QAn1KEVtr8r1TGJxJs 4ot72sBHq2kBLNNjtKoCQAO9rzpnU6Rlj1qXu4HJsjx++HBg/CqLi2smOF8O+ZDYvRzl IFgUyrIrH1D7Te0M2uFcARabG0HEi51qVNk4LBBxy5SAH6GCoHY/rAwbZPOQehiBh9ul l+py7+131usBkPWI3VF+e9EfuiKY2TBnKuMAHfNKNGTn3r2fS/yyLKoRal4oV1XDzBhM 14lAnM9nPNWP9wxwZVZVtkbgnDoPleADFcZYq7YufTYy2taA9Nm9aj6tVGRAiC5mD/IG yiBw==
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=K6acDlM7oT51womuzfwx6i6sFsxqhs3iYWlD+rEP5HY=; b=Kei8bbjI1UzVvX6HWoCPcxZ/rXzqTsW/LHBvjIi4INjHb0AZSCa8s0M/6S0odUYz1P 6/0p6NuIgDWWB8XYLTSlspMtIQUoXACKXn+VjTYpJNNWIU27AKmdTr++/Jc9R7fihmQt 53es4GPUoCHM5emAwc3GmpDFmFMNuLAX2VcSVLmTT+WQS+bRTBBTAbjsQc4RSiCvyBoc SpQcTz33oC5aLqY1fi3OTDFou5shqjC0zuq8gFLnYNLL8eghZBsJx5Lpzhr6CViMK/hB cmUJrOsKo0sddbRGiNAS+QnToutJYVduTcSosUoGsf9FTB/DRqtbO9nXL2xiQVfmLXhd wclg==
X-Gm-Message-State: AOPr4FUxSno887G9awJeJ1r7DokoGa36f2zpEWnsU9fHCLfPtezx7YtMjB3VGntwyOAtUOGELuCqRW8ywFRIIQ==
MIME-Version: 1.0
X-Received: by 10.176.4.20 with SMTP id 20mr20070672uav.125.1461596387111; Mon, 25 Apr 2016 07:59:47 -0700 (PDT)
Received: by 10.176.65.40 with HTTP; Mon, 25 Apr 2016 07:59:46 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org>  
Date: Mon, 25 Apr 2016 15:59:46 +0100
Message-ID: 
From: Victoria Mercieca 
To: "Dearlove, Christopher (UK)" 
Content-Type: multipart/alternative; boundary=001a114fd886757c730531506d80
Archived-At: 
Cc: Christopher Dearlove , Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 14:59:58 -0000

--001a114fd886757c730531506d80
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Chris,


On Mon, Apr 25, 2016 at 3:51 PM, Dearlove, Christopher (UK) <
chris.dearlove@baesystems.com> wrote:

> I has to go back to Victoria=E2=80=99s summary here. It says:
>
>
>
> 2) C creates the RREP. Since it doesnt know if the link to B is
> bidirectional, it includes the AckReq (an address to indicate that it
> expects to receive a RREP_Ack from B).
>
>
>
> That doesn=E2=80=99t actually indicate if that=E2=80=99s C=E2=80=99s addr=
ess or B=E2=80=99s address being
> included. I=E2=80=99d assumed it was C=E2=80=99s address. Your comment ma=
kes sense if it=E2=80=99s
> B=E2=80=99s address. Reading again, I think you=E2=80=99re probably right=
. But only
> probably. Can we confirm that.
>
>
>

C creates the RREP. The included AckReq address is B's address. The RREP
then gets multicast.
B receives it, sees that it own address is marked as the AckReq address,
and sends an ack unicast back to C.
Anyone else who receives the multicast RREP from C does not send the Ack,
since the AckReq address does not match any of their interface addresses.


> I assume you meant that the RREP (not RREP_Ack) is multicast. There=E2=80=
=99s a
> bit of a chicken and egg problem here. We do know how we want to unicast.
>

The RREP is multicast (when we dont know if the link is bidirectional), the
RREP_Ack is always unicast.

Kind regards,
Vicky.


>
> *-- *
>
>
>
>
> *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:* 25 April 2016 15:26
> *To:* Thomas Heide Clausen
> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
> Networks mailing list; Victoria Mercieca
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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
> .*
>
> The address in the RREP_Ack may be required due to the RREP_Ack being
> multicast as there is not yet a verified unicast route installed yet.
> Going to double check if I'm remembering correctly.
>
> Justin
>
>
>
> On Mon, Apr 25, 2016 at 10:18 AM,  wrote:
>
> Hi,
>
>
>
> I must admit that while I have reviewed the protocol several times, I=E2=
=80=99ve
> not been digging that deep into the protocol functioning to catch this
> issue of how invasive the protocol operations are when forwarding a
> message: there were other =E2=80=9Cmajor=E2=80=9D issues to address (and =
which obscured the
> details), so as a first order: thank you Victoria, for having called
> attention to this.
>
>
>
> To the substance of these emails.
>
>
>
> I am afraid that I do not understand the use of inserting validity TLVs
> while in-flight, into a message. Actually, I am dubious for both the
> originator inserting this (how can the originator of a message know how
> =E2=80=9Clatter parts of the path=E2=80=9D will be have=E2=80=9D) except =
if we are talking
> duty-cycling of devices and inserting =E2=80=9Cthe remaining time that I =
am going
> to be up before I suspend=E2=80=9D. Intuitively, that would also assume f=
airly long
> duty cycles =E2=80=9CI am up for tens of seconds=E2=80=9D, which I am not=
 sure are actually
> realistic. And, as Chris says in another email, this is trading off =E2=
=80=9Cthe
> ability to do security=E2=80=9D for an unknown/untested feature =E2=80=94=
 which I think is
> the wrong trade-off.
>
>
>
> On he topic of =E2=80=9Cneeding to put an address in=E2=80=9D for RREP-AC=
K, I must admit
> that this seems roundabout. I can see three issues here:
>
>
>
> o I am not sure that adding an address vs. a flag may not have to do with
> the =E2=80=9Cmultiple interfaces/
>
> multiple addresses=E2=80=9D discrimination mechanics of the protocol? I h=
aven=E2=80=99t
> worked it through, though,
>
> but that would be a guess.
>
>
>
> o The end-to-end topology diffusion mechanism should not need to be
> concerned with the
>
> =E2=80=9Cbidirectionally check=E2=80=9D of a local link (in part, as it e=
ncumbers
> security, but not only).  In short, a
>
> flag or an address, both are (equally) bad.
>
>
>
> o A cleaner mechanism would be a =E2=80=9Chello mechanism=E2=80=9D, not n=
ecessarily as
> NHDP, but a =E2=80=9Cwhen
>
> forwarding a RREQ/RREP, trigger a 3-way hello exchange, if the link is
> estimated to be of a
>
> type which potentially can be unidirectional=E2=80=9D. There is another b=
enefit to
> doing that, see the end
>
> of this email.
>
>
>
> Either way, I do not like the notion of fusing
> metrics-and-link-bidirectionality-detection any more than I like fusing
> global-topology-diffusion-and-link-bidirectionality-detection.
>
>
>
> The solution all this is, to me, threefold
>
>
>
> 1) Factor out the bidirectionally check in a (triggered) neighbour
> detection mechanism
>
> (triggered HELLO message)
>
>
>
> 2) Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, since they add comple=
xity for no
> perceivable benefits
>
>
>
> 3) Use the security model that we=E2=80=99ve discussed previously, where =
(only)
> the metrics change per hop.
>
>
>
> Since we=E2=80=99re discussing bi-directionality of links here, and the n=
ecessity
> 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:
>
>
>
>    ...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 this
>
>    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 conclusi=
on 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 link t=
he
> metrics is 4 or 5=E2=80=9D, the protocol must be able to convey and disti=
nguish
> 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 mechanis=
m:
> that exchange could, if designed carefully, be used to probe for and conv=
ey
> metrics information, also.
>
>
>
> Hope this helps,
>
>
>
>
>
> Thomas
>
>
>
> On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>
>
> Assuming for the moment that everyone will need an RREP-Ack or won=E2=80=
=99t
> (let=E2=80=99s come back to that) why do C and B need to put an address i=
n as an
> RREQ-Ack request? Why not a flag, because the address will be included as
> the IP sending address - and we know 5444 is required to pass that on.
> (It=E2=80=99s used by NHDP as well.) Then we don=E2=80=99t need to change=
 the RREP, it will
> have a flag set or not, and won=E2=80=99t change (in this regard).
>
>
>
> Now let=E2=80=99s consider do we know whether we can set a fixed flag. Fi=
rst I=E2=80=99d
> say there are two cases - you=E2=80=99ve got a firm control on what=E2=80=
=99s going on in
> your network, or it=E2=80=99s one of unknown parties and behaviour (consi=
stent with
> specification). In the former case you only want one setting, for example
> no-Ack if running NHDP or your MAC layer tells you about bidirectionality=
,
> Ack otherwise. In the latter case, I think you just always want an Ack. S=
o
> both cases get you to the same place.
>
>
>
> Should that not be an acceptable argument (though I think it=E2=80=99s go=
od for
> where we are - in fact always Ack is close) then at flag is a step better=
,
> it=E2=80=99s a fixed location to change. However it would be better in th=
at case if
> the two things to change (metric and ack flag) were together. But that ha=
s
> its own issues, so I won=E2=80=99t go there.
>
>
>
> *--*
>
>
>
>
> *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com
> ]
> *Sent:* 25 April 2016 14:15
> *To:* Jiazi YI
> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
> Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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
> .*
>
> Hi Jiazi,
>
>
>
> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI  wrote:
>
> Hi,
>
>
>
> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
> With regard to your validity time point, we here have a tradeoff. If you
> allow that feature, it significantly impacts on the approach that was
> coming together on as best you can end to end encryption.
>
>
>
> So the question is, is this a feature that=E2=80=99s really wanted? Unfor=
tunately
> I think we know that the answer to that is, we don=E2=80=99t know because=
 we don=E2=80=99t
> have any experience. My view would be that in the tradeoff of an untested
> feature (unless I=E2=80=99m wrong about that) and the security complicati=
on,
> security wins and drop the feature. If there is some real requirement, th=
en
> there=E2=80=99s a discussion. (Questions like how often the intermediate =
routers
> actually have any knowledge - typically links break for unexpected rather
> than expected reasons. Andan intermediate router could possibly use a
> validity time to influence its behaviour.) Note that dropping the ability
> of intermediate routers to modify/set still allows validity times per rou=
te
> to be set at endpoints.
>
>
>
> I agree with Chris' concern.
>
> The ValidityTime is optional, which makes the integrity protection hard.
> Furthermore, it gives a potential attack vector: as all the routers in a
> path will take the shortest validityTime, a compromised router can set th=
e
> the validityTime to a very short value, which will make the route install=
ed
> along the path became invalid (very soon).
>
>
>
> On the other hand, I'm not sure this option will give us much help. Chris
> mentioned much knowledge intermediate router would have to decide this
> value (and how much sense the value would make).
>
> Another issue is, a route to a destination might be updated by different
> sources. For example, in the network below:
>
>
>
> A----B-----C
>
>
>
> A first establish a route to B with long validity time. Then A initiates =
a
> route discovery to C. C tends to set a short validity time, which will ma=
ke
> the route between B and A expire earlier than expected.
>
> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered or
> not.
>
>
>
>
>
> Not sure I follow here.
>
> Currently, the validity time of the route between A and B would not
> affected by a short validity time of a route between A and C. Validity
> times are per-route, and the route A-B and the route A-C are separate.
>
> If we switched to a validity time per neighbor (so that we can keep
> validity time separate from route advertisements) as I mentioned in the
> email below, then the validity of a route between A and C would be affect=
ed
> if there was a short validity time between A and B. But, if B will only
> route for a certain amount of time, then the route between A and C will o=
f
> course be affected. Is it best to know in advance that there's a time
> limit, or just deal with RERRs when they happen?
>
>
>
>
>
>
>
> With regard to the acknowledgements, the problem (with regard to security=
)
> comes from trying to do two jobs with the same message - end to end route
> advertisement and hop by hop acknowledgement. I understand the reasons -
> saving bytes and message types. (I would have to study the protocol reall=
y
> hard to identify if any message types can be folded together and recognis=
ed
> by content rather than type efficiently. This I do not expect to do.) Aga=
in
> a tradeoff. This one is in discussion space, though that needs people who
> understand both sides of the issue, including the details of the
> bidirectionality mechanism. Of course, as has been said, we need one of
> those.
>
>
>
> I haven't finished my review of the latest draft, and I don't get the
> necessity of AckReq and the corresponding multicast RREP yet.
>
> If possible, this "optional" field should be avoided.
>
>
>
>
> To give an overview of AckReq and RREP:
>
> Since AODVv2 requires bidirectional links, this is the way to determine i=
f
> a link is bidirectional.
>
> A----B----C
>
>
> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install
> a route to OrigAddr but they dont yet know if it's valid because they don=
t
> know if the link to their next hop is available in the reverse direction.
>
> 2) C creates the RREP. Since it doesnt know if the link to B is
> bidirectional, it includes the AckReq (an address to indicate that it
> expects to receive a RREP_Ack from B).
>
> 3) B receives the RREP, installs a route to TargAddr and marks it as
> valid, since it knows the link to C is bidirectional, because the RREQ we=
nt
> in one direction and the RREP came in the other. B also sends the RREP_Ac=
k
> to C and forwards the RREP to A (and might change the message to indicate
> its own AckReq - ie that it requires an ack from A).
>
> 4) C receives the RREP_Ack from B, and therefore knows that B received th=
e
> RREP, therefore the link is bidirectional. C can then mark its route to
> OrigAddr as valid.
>
> 5) Similarly, A receives the RREP, installs the route to TargAddr and
> sends an RREP_Ack to B.
>
> 6) B receives the RREP_Ack and marks its route to OrigAddr as valid.
>
>
>
> Alternatively, in step 2, if C knows the link to B is bidirectional
> (perhaps from some earlier route discovery), it doesnt need to put the
> AckReq in the RREP. Then in step 3, since B doesnt know if the link to A =
is
> bidirectional, it changes the message to add the AckReq address, in order
> to get an RREP_Ack from A.
>
> If we want to avoid changing the message, we'll need to look at forwardin=
g
> the RREP as-is, and creating a second message to solicit an RREP_Ack, in
> order to verify that the link is bidirectional before marking the route t=
o
> OrigAddr as valid.
>
> Kind regards,
>
> Victoria.
>
>
>
>
>
> regards
>
>
>
> Jiazi
>
>
>
>
>
> *--*
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *________________________________________________________________________=
__
> *
> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
> *Sent:* 23 April 2016 10:55
> *To:* Christopher Dearlove
> *Cc:* ietf@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc
> Networks mailing list
>
>
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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
> .*
>
> Hi Chris,
>
>
>
> These have both been in the draft in some form since before I got
> involved... but I'll do my best to explain.
>
>
>
> - For Validity Time, its a way to advertise that you would only support
> the route contained in the message for a certain period of time. The
> originator might use this, but the draft was written to allow any
> intermediate node to be able to add it or update it too. The route create=
d
> in the Local Route Set has an expiration time associated with it, based o=
n
> the received validity time.
>
> - For the AckReq address, its so that you can add into a RREP a request
> for an acknowledgement, so that you don't have to have a different messag=
e
> type altogether for working out whether links to neighbors are
> bidirectional, and also, since you only care about bidirectionality on
> routes that are being set up, you dont need to constantly monitor all
> neighbors.
>
>
>
>
>
> In order to avoid the potential AckReq-related changes to each message,
> maybe we do need to introduce a different message specifically for this. =
We
> could maybe use RREP_Ack to both request and acknowledge? It means an ext=
ra
> message of control traffic that needs to be sent, maybe one extra message
> per hop on the path of a RREP, but it could still be limited to neighbors
> which have participated in the route discovery rather than monitoring all
> neighbors at all times.
>
>
>
> This message could maybe also include "I'm happy to route anywhere for a
> certain amount of time", sort of like willingness in OLSR/OLSRv2. So
> instead of having a validity time per route, its a validity time per
> neighbor. Then, for RREQ and RREP, only the metric value would change in
> transit, as discussed. However, that leads to some issues with deciding
> what a route's expiration time is. You might know how long the next hop
> router is valid for, but what if a router beyond that, which was also par=
t
> of the route, had a lower validity time? You couldn't determine the real
> validity time. Do we remove the route expiration time altogether to avoid
> this issue? In which case, we would have to rely on RERR messages being
> sent for routes which become invalid when the neighbor's validity time ha=
s
> expired? So neighbor validity time expiration is treated the same as a li=
nk
> break.
>
>
>
> What do you think?
>
>
>
> Kind regards,
>
> Victoria.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
> chris@mnemosyne.demon.co.uk> wrote:
>
> Pretty much all of the discussion has been assuming only a metric value
> change. With multiple things changing many of the ideas go out of the
> window. That reinforces the point about not making specifications now tha=
t
> might turn out to be wrong for ICVs.
>
>
>
> Ignoring how this misunderstanding happened, I'll start by asking why.
> Metric changing I understand. Why the other two? (there's a partial
> explanation of one). What alternatives have people implemented in
> comparable protocols?
>
> --
>
> Christopher Dearlove
>
> christopher.dearlove@gmail.com (iPhone)
>
> chris@mnemosyne.demon.co.uk (home)
>
>
> On 23 Apr 2016, at 00:26, Victoria Mercieca  wrote:
>
> Hi all,
>
>
>
> Continued in this thread because the other one seems to be more about TLV
> types and metric type numbers, whereas this is about
> regeneration/forwarding.
>
>
>
> To recap, in the current draft, there are 3 things that might change at
> each hop:
> - the metric value (happens in RREQ and RREP),
> - adding/changing Validity Time using the Validity Time TLV (can happen i=
n
> RREQ and RREP),
> - adding an address (and corresponding value in the AddressType TLV to
> indicate how to interpret the address) to indicate the address from which
> an RREP_Ack is expected, to accomplish the bidirectionality check (can
> happen in RREP).
>
> If we define a certain portion of the message as immutable and include th=
e
> ICV to verify that part, end to end:
> - The metric value would be excluded from the ICV since it needs changing
> at each hop.
> - Would adding a Validity Time TLV at an intermediate hop be acceptable?
> The whole TLV could be removed in order to calculate the ICV?
>
> - Would adding an address cause issues for the ICV, because it's in the
> address block? Could the rule be "if it contains an AckReq address, remov=
e
> it (and the corresponding value in the AddressType TLV), before checking
> the ICV", is that OK? Or would we need to avoid touching the ICV'ed part =
of
> the message altogether, maybe put the AckReq address in a separate Addres=
s
> Block, with an extra AddressType TLV following that address block? Is the=
re
> a way to accomplish this?
>
>
>
> Also, to be thorough, do we need to consider RERR messages while we
> discuss regeneration vs forwarding?
>
> - RERR (sent when a link breaks) is a way of saying "I've lost my route s=
o
> I'm telling others" and "you were my next hop, so now I've also lost my
> route, I'll tell others", etc. It's going to be tailored at each step to
> include the relevant routes that got deleted, it's not one message being
> sent end-to-end like RREQ and RREP are.
>
> - However, RERR (sent when a source of traffic is sending data on a route
> which comes through you, and you want to tell the Packet Source's router =
to
> delete the route) could be seen as an end-to-end message which all
> intermediate routers learn from, similar to RREQ and RREP. It reports one
> route, and doesn't need changing at intermediate hops, so could be
> protected with ICV.
>
> - Would it be OK to only require a message ICV if a PktSource address was
> included, i.e. when the message needs to go via a number of intermediate
> hops to PktSource's router? All other RERRs are intended to be one-hop
> messages, which may in turn prompt other one-hop messages, etc..., and a
> packet ICV might be more appropriate?
>
>
>
> Kind regards,
>
> Victoria.
>
>
>
> On Thu, Mar 17, 2016 at 5:26 PM,  wrote:
>
>
>
> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>
>
> Yes, I meant AODVv2, thanks for the catch.
>
>
>
> So is your (Thomas) proposed base specification a hop count only metric?
>
>
>
> No, the would be silly as base specification, given that hop count mostly
> is useless.
>
>
>
> As base specification I would simply say =E2=80=9CInclude a Metric Type M=
essage
> TLV with a value field, and a 7182 Message TLV & Timestamp=E2=80=9D as we=
 do in
> OLSRv2 (with the appropriate verbiage as to generation and processing).
>
>
>
> With the message generated by the originator of the RREQ/RREP and *not*
> deconstructed/reconstructed/reordered (as is the risk with =E2=80=9Cregen=
eration)
> allows knowing that it would be *only* that metric field being modified
> (other than hop count/limit) for when eventually writing up the extension=
.
>
>
>
> (Actually doesn=E2=80=99t the current specification only define hop count=
, or has
> that changed in latest draft?)
>
>
>
> No. That is one of the issues I raise in my original. For some reason, it
> cites RFC6551, which is a ROLL document and which has in its abstract tha=
t:
>
>
>
>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>
>    compared with traditional wired and ad hoc networks that require the
>
>    specification of new routing metrics and constraints.
>
>
>
> I.e. this document cites a metric document which clearly claims to be
> inapplicable in ad hoc networks. I note that this is another thing I=E2=
=80=99ve
> raised for years without seeing it attempted resolved.
>
>
>
> Best,
>
>
>
> Thomas
>
>
>
>
>
>
>
> *--*
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *________________________________________________________________________=
__
> *
> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
> ]
> *Sent:* 17 March 2016 17:10
> *To:* Dearlove, Christopher (UK)
> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>
>
> OK, so we have a message that mutates by:
>
> - Modifying hop count/limit.
>
> - Modifying a metric value.
>
> Anything else?
>
>
>
> As mutating (other than hop count/limit) messages aren=E2=80=99t covered =
by 5444
> or any derivative document (but only recommended against, not banned) tha=
t
> you may need to make the message otherwise immutable (no deconstruction a=
nd
> rebuilding, other than guaranteed unchanging) that would have to be
> specified by AODVv2. (Easy to say, but needs saying.)
>
>
>
> With you so far.
>
>
>
> Then that information is not in a guaranteed fixed location given by a
> simple offset. So any signature algorithm that finds it and ignores it or
> aggregates on it is specific to OLSRv2.
>
>
>
> Surely you mean AODVv2
>
>
>
> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AODVv2
> specialised variant. Which is the sort of thing that the message specific
> TLV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cbut ig=
nore the value of
> this specific TLV should it occur=E2=80=9D being in the general space. Ho=
wever it
> can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like tha=
t TLV,
> except if an X TLV is present, set its value field to zero=E2=80=9D).
>
>
>
> Messy, but could work.
>
>
>
> Not that messy, actually, although clearly not as nice as =E2=80=9Cfixed =
offset=E2=80=9D.
>
>
>
> That said, I am arguing for the base spec being:
>
>
>
>             =E2=80=9Cmake the message otherwise immutable (no deconstruct=
ion and
> rebuilding, other
>
>              than guaranteed unchanging)=E2=80=9D which is afforded by fo=
rwarding
>
>
>
>                                     +
>
>
>
>             RFC7182 Timestamps and ICVs.
>
>
>
>                                     +
>
>
>
>             RFC7183 style text bringing it all together.
>
>
>
> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would ve=
ry be an
> experimental extension.
>
>
>
> What I object to is, if the base spec specifically renders such extension=
s
> impossible
>
>
>
>
>
>
>
> *--*
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *________________________________________________________________________=
__
> *
> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
> ]
> *Sent:* 17 March 2016 16:48
> *To:* Dearlove, Christopher (UK)
> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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
> .*
>
> Hi all,
>
>
>
> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com>:
>
>
>
> Good point about whether you just pass on one cost or a set of costs. As =
I
> said, not looked at details - I will, when time permits. One cost is much
> easier, and yes, it reduces the fixed size aggregated signatures problem =
to
> =E2=80=9Cjust=E2=80=9D one of computational load.
>
>
>
> For the record, Thomas=E2=80=99 understanding is correct; the cost is one
> aggregated value.
>
>
>
> Best regards,
>
> Lotte Steenrbink
>
>
>
>
>
> *--*
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *________________________________________________________________________=
__
> *
> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
> ]
> *Sent:* 17 March 2016 16:38
> *To:* Dearlove, Christopher (UK)
> *Cc:* Mobile Ad Hoc Networks mailing list
> *Subject:* Re: Message integrity and message mutability (was RE: [manet]
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>
>
> I appreciate Thomas=E2=80=99s comments about the limitations of message
> regeneration, but I would be a bit less absolute.
>
>
>
> The issues over end to end authentication and more advanced signatures ar=
e
> valid. I need to read the given reference on aggregate signatures to
> increase my knowledge (thanks for it), but my understanding of the
> possibilities in this field may offer a solution to the problem, but with
> some other issues (possibly including a new type of TLV).
>
>
>
> But the hop count/limit point I don=E2=80=99t fully agree with, you can r=
egenerate
> with an incremented/decremented count/limit, which leaves the ability to
> prevent messages propagating indefinitely, including expanding ring
> searches, and retains the ability to use RFC 5497 interval and validity
> times that might be useful with an expanding ring search (or might not).
>
>
>
> But the key issue is that AODVv2 wants to accumulate metrics. I still
> haven=E2=80=99t got to the bottom of many details here, but let=E2=80=99s=
 for the moment
> just consider that conceptually.
>
>
>
> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft attempts =
to do an end to
> end of some information, not this information. I=E2=80=99m not sure if th=
at=E2=80=99s
> useful (and the specialised format is better avoided if possible). Other
> approaches are hop by hop (might as well use packet signatures) and share=
d
> key (might as well go hop by hop). Pairwise signatures for each pair of
> routers I=E2=80=99m discounting as scaling terribly. In the interests of
> completeness let=E2=80=99s mention not accumulating metrics, which puts u=
s back to
> hop count and that=E2=80=99s not ideal either.
>
>
>
> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=80=
=99ve seen about
> aggregating, but that has some issues of its own, even apart from
> computational load.) I=E2=80=99d love to be proved wrong - someone with t=
he perfect
> solution to come along.
>
>
>
> Which means that either we make an arbitrary choice - which will be
> disagreed with, but needs discussing first - or create something flexible=
.
> Unfortunately flexible in that regard constrains in others, e.g. some
> (many? most?) aggregating signatures need fixed data sizes (which we can =
do
> by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but tha=
t has a cost too).
>
>
>
> I have been told by people much more well versed in this than I in
> cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>
>
>
> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does th=
at mean that the
> message grows as it is being forwarded, and that the recipient of a
> RREQ/RREP will know the individual costs of each path segment? My
> understanding is, that the recipient will get =E2=80=9Cthe sum the costs =
of each
> path segment=E2=80=9D which should be fitting within a fixed size?
>
>
>
> Thomas
>
>
>
>
>
>
>
> Sorry, no answers, just comments. And I=E2=80=99m not addressing Thomas=
=E2=80=99s later
> points here.
>
>
>
> *--*
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *________________________________________________________________________=
__
> *
> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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 *ietf@thomasclausen.org
> *Sent:* 17 March 2016 16:00
> *To:* Mobile Ad Hoc Networks mailing list
> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of big
> ticket Items
>
>
>
>
>
> **** 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.
>
>
>
> Dear all,
>
>
>
> Apologies for not having gotten this done sooner - day-job leaving few
> spare cycles.
>
>
>
> I=E2=80=99ve previously offered reviews and comments, and some of those h=
ave been
> addressed in the latest I-D =E2=80=94 others have not, but should be. I r=
ecall that
> there was some mail attempting to rebut parts of the review, and I will d=
ig
> it out and reply to that.
>
>
>
> With that being said, I have reviewed the latest version of the document,
> and full details will be forthcoming. There=E2=80=99re a couple of
> big-ticket/architectural items that I want to address up front, as I
> believe that before we have those hammered out, it will be useless to go
> into details. Note, I do not claim that this is an exhaustive list of =E2=
=80=9Cbig
> ticket items=E2=80=9D, but that=E2=80=99s as far as I have gotten in thin=
king this through.
>
>
>
> I also bring these up as they are items that have been brought up
> repeatedly over the past years, but not resolved nor discussed.
>
>
>
> *Loops*
>
> Just to bring this out: I share Chris=E2=80=99 worry about conflicting an=
d
> concurrent statements from the authors on =E2=80=9CThere are no loops pos=
sible=E2=80=9D and
> =E2=80=9CWe need to fix two situations where loops can occur=E2=80=9D and=
 =E2=80=9Cwe are still
> investigating some loop conditions=E2=80=9D
>
>
>
> I particularly worry that this is not a discussion had in public, but
> apparently in some other forum=E2=80=A6
>
>
>
>
>
> *Intermediate Route Replies, and all of section 10*
>
> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=80=
=9D, which is
> incoherent with the intended status indicated for this document.
>
>
>
> Specifically, and this is not unrelated to the point about loops above,
> intermediate RREPs (section 10.3) are a potential source for loops.
>
>
>
> Expanding Ring Multicast (section 10.1) is not documented in a way that
> can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=E2=
=80=9D below, it is
> in the present form of this protocol impossible), etc.
>
>
>
>
>
> *Forwarding-vs-regeneration*
>
> Recent exchanges on the list made me understand that protocol control
> messages are *not* forwarded, but are consumed at each hop, then a new
> message with (almost-but-not-quite) the same content is generated and
> transmitted.
>
>
>
> I have thought some more on this (& read some of the exchanges on the lis=
t
> on this topic by Chris, Ulrich, and others), and I am convinced that this
> is not the right way to go, *at least* for the following reasons:
>
>
>
>
>
>             o          *It renders the hop-limit/hop-count fields in the
> RFC5444 message header useless.*
>
>                         This would not be bad if the functionality offere=
d
> by those fields was not useful
>
>                         =E2=80=94 sadly, it is. For example, for scope li=
mited
> flooding (expanding ring search, and
>
>                         such) which may be of interest, and which require
> hop-limit.
>
>                         A hop-count field may also provide a =E2=80=9Cche=
ap=E2=80=9D (in
> terms of overhead) additional piece
>
>                         of information to use conjunctively with a =E2=80=
=9Creal=E2=80=9D
> metric.
>
>
>
>                         The only practical solution would be to
> re-introduce these functions by way of inserting a
>
>                         MessageTLV =E2=80=94 which (i) is not specified i=
n this
> document, and (ii) which would just
>
>                         serve to render messages bigger than strictly
> needed.
>
>
>
>                         Scope limited flooding  does seem to be a
> necessary requirement, if for no
>
>                         other reason than to prevent information from
> =E2=80=9Ccirculating forever in the network=E2=80=9D.
>
>
>
>             o          *It makes end-to-end authentication unnecessarily
> hard.*
>
>                         I think Chris called this out already, but it
> bears repeating: S generates a message
>
>                         (say, a RREQ), and includes an ICV calculated ove=
r
> the content of the message.
>
>                         For any recipient to be able to validate the ICV,
> the message has to be exactly
>
>                         the same =E2=80=94 not just in content, but in st=
ructure =E2=80=94
> as what was generated.
>
>
>
>                         =E2=80=9CRegenerating=E2=80=9D rather than =E2=80=
=9Cforwarding=E2=80=9D messages
> means, that the intermediate
>
>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ ma=
y chose a
> different structure (e.g., include TLVs
>
>                         in a different order).
>
>
>
>                         The proposal from
> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>
>                         is to add constraints on (i) the set of elements
> to include in a signature and (ii) the
>
>                         order of these elements.
>
>
>
>                         One problem with that approach is (i): if an
> extension adds a message TLV, or an
>
>                         Address TLV, to a message, then that will not be
> =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>
>                         Rather for *each* extension developed, an =E2=80=
=9Cupdates
> e2esec=E2=80=9D clause needs to be done.
>
>
>
>                         I=E2=80=99d say that this approach would be prone=
 to
> errors =E2=80=94 and add entropy to the process
>
>                         of designing protocol extensions. The alternative=
,
> a message being generated by the
>
>                         source and *forwarded* (as we do in OLSRv2, for
> example) would allow ICV TLVs
>
>                         (even, allow reuse of those specified for OLSRv2)
> for covering a message and
>
>                         extensions.
>
>
>
>                         =E2=80=9CBut what about the metrics value which w=
ill
> change on each hop=E2=80=9D, you may say?
>
>                         Fortunately, that is relatively easy to handle:
> simply zero out the value of that TLV when
>
>                         generating or verifying the ICV MessageTLV. And
> use Packet-TLVs for hop-by-hop
>
>                         authentication, if needed (but, see below).
>
>
>
>             o          *It prevents the use of more clever/advanced
> signature schemes/ICVs*
>
>                         Aggregate signature algorithms (
> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>
>                         exist, and an interesting use-case can be found i=
n
> also reactive protocols, allowing verifying
>
>                         not =E2=80=9Cjust=E2=80=9D the end points, but al=
so the
> intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D
>
>                         discussed above, or something smarter).
>
>                         Regeneration of messages, rather than forwarding,
> renders that impossible (or, if used,
>
>                         updating to
> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>
>
>
> There are other reasons, but the above are those that jump at me as
> immediate show-stoppers.
>
>
>
> I do honestly not see what possible benefit there is from =E2=80=9Cregene=
ration=E2=80=9D =E2=80=94
> but I see very clear inconveniences, and security is not the least of
> these. Insisting on =E2=80=9Cregeneration=E2=80=9D requires development o=
f =E2=80=9Cnon-general
> workarounds=E2=80=9D as pointed out above.
>
>
>
> *Security Considerations*
>
> This is an always thorny subject. When OLSRv2 was going through the
> process we got a thorough education in how little we knew about security
> from the SEC-ADs, and had to spend about a year or so developing RFC7183.
> The bottom line is, that this protocol needs its =E2=80=9CRFC7183  equiva=
lent=E2=80=9D,
> either as part of the main document, or as an independent document.
> currently, that is not the case.
>
>
>
> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration from R=
FC7183
> might be aw good idea, as that was the most recent that went through the
> SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to implement=E2=
=80=9D security
> mechanism most be specified (I think the right term was =E2=80=9CMUST imp=
lement,
> SHOULD use=E2=80=9D), in sufficient detail to ensure interoperable implem=
entations.
>
>
>
> As an example, both [RFC6130] and [RFC7181] set out that that:
>
>
>
>       On receiving a ... message, a router MUST first check if the
>
>       message is invalid for processing by this router
>
>
>
> and then proceed to give a number of conditions that, each, will lead to =
a
> rejection of the message as "badly formed and therefore invalid for
> processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That gav=
e a =E2=80=9Chook=E2=80=9D for
> RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message gener=
ation.
>
>
>
> If I was to do RFC7181/RFC6130 today, I would include that directly into
> the protocol specifications. It turned out to be more overhead (and slow
> down publication anyways) to do it as separate documents.
>
>
>
> Secondly, we need to be a lot more rigid in terms of what ICVs,
> Timestamps, etc. are added/removed, and what that brings.
>
>
>
> For example (with the assumption that messages are *forwarded* and *not*
> regenerated), this could be one option:
>
>
>
>                         o          When a RREQ, RREP message is generated=
,
> add an ICV Message TLV, which is calculated 
>
>                                      =E2=80=A6(take inspiration from RFC7=
183 here)
>
>
>
> ...
>
> [Message clipped]
> _______________________________________________
> 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
>
>
>
> ********************************************************************
> 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
>
>
>

--001a114fd886757c730531506d80
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Chris,


On Mon, Apr 25, 2016 at 3:51 PM, Dearlove, Christopher (UK=
) <chris.dearlove@baesystems.com> wrote:











I has to go back to Victo=
ria=E2=80=99s summary here. It says:


=C2=A0


2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).


=C2=A0


That doesn=E2=80=99t actu=
ally indicate if that=E2=80=99s C=E2=80=99s address or B=E2=80=99s address =
being included. I=E2=80=99d assumed it was C=E2=80=99s address. Your commen=
t makes sense if it=E2=80=99s B=E2=80=99s address.
 Reading again, I think you=E2=80=99re probably right. But only probably. C=
an we confirm that.


=C2=A0
<=
/div>

C creates the RREP. The include=
d AckReq address is B's address. The RREP then gets multicast.
B receives it, sees that it own address is marked as the AckReq addre=
ss, and sends an ack unicast back to C. 
Anyone else who receives the mu=
lticast RREP from C does not send the Ack, since the AckReq address does no=
t match any of their interface addresses.
=C2=A0


I assume you meant that t=
he RREP (not RREP_Ack) is multicast. There=E2=80=99s a bit of a chicken and=
 egg problem here. We do know how we want to unicast.
=C2=A0
The RREP is multicast (when we dont kno=
w if the link is bidirectional), the RREP_Ack is always unicast. 

Kind regards,
Vicky.

=

=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: 25 April 2016 15:26

To: Thomas Heide Clausen

Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc =
Networks mailing list; Victoria Mercieca

Subject: Re: [manet] Message integrity and message mutability (was R=
E: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)=



=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>








The address in the RREP_Ack may be required due to t=
he RREP_Ack being multicast as there is not yet a verified unicast route in=
stalled yet.=C2=A0 Going to double check if I'm remembering correctly.=
=C2=A0



Justin






=C2=A0




On Mon, Apr 25, 2016 at 10:18 AM, <ietf@thomasclausen.org>=
; wrote:




Hi,




=C2=A0






I must admit that while I have reviewed the protocol=
 several times, I=E2=80=99ve not been digging that deep into the protocol f=
unctioning to catch this issue of how invasive the protocol operations are =
when forwarding a message: there were other
 =E2=80=9Cmajor=E2=80=9D issues to address (and which obscured the details)=
, so as a first order: thank you Victoria, for having called attention to t=
his.






=C2=A0






To the substance of these emails.






=C2=A0






I am afraid that I do not understand the use of inse=
rting validity TLVs while in-flight, into a message. Actually, I am dubious=
 for both the originator inserting this (how can the originator of a messag=
e know how =E2=80=9Clatter parts of the path=E2=80=9D
 will be have=E2=80=9D) except if we are talking duty-cycling of devices an=
d inserting =E2=80=9Cthe remaining time that I am going to be up before I s=
uspend=E2=80=9D. Intuitively, that would also assume fairly long duty cycle=
s =E2=80=9CI am up for tens of seconds=E2=80=9D, which I am not sure are
 actually realistic. And, as Chris says in another email, this is trading o=
ff =E2=80=9Cthe ability to do security=E2=80=9D for an unknown/untested fea=
ture =E2=80=94 which I think is the wrong trade-off.






=C2=A0






On he topic of =E2=80=9Cneeding to put an address in=
=E2=80=9D for RREP-ACK, I must admit that this seems roundabout. I can see =
three issues here:






=C2=A0






o I am not sure that adding an address vs. a flag ma=
y not have to do with the =E2=80=9Cmultiple interfaces/






multiple addresses=E2=80=9D discrimination mechanics=
 of the protocol? I haven=E2=80=99t worked it through, though,=C2=A0=







but that would be a guess.






=C2=A0






o The end-to-end topology diffusion mechanism should=
 not need to be concerned with the=C2=A0






=E2=80=9Cbidirectionally check=E2=80=9D of a local l=
ink (in part, as it encumbers security, but not only).=C2=A0 In short, a=







flag or an address, both are (equally) bad.






=C2=A0






o A cleaner mechanism would be a =E2=80=9Chello mech=
anism=E2=80=9D, not necessarily as NHDP, but a =E2=80=9Cwhen=C2=A0






forwarding a RREQ/RREP, trigger a 3-way hello exchan=
ge, if the link is estimated to be of a=C2=A0






type which potentially can be=C2=A0unidirectional=E2=
=80=9D. There is another benefit to doing that, see the end=C2=A0=







of this email.






=C2=A0






Either way, I do not like the notion of fusing metri=
cs-and-link-bidirectionality-detection any more than I like fusing global-t=
opology-diffusion-and-link-bidirectionality-detection.=C2=A0<=
/p>





=C2=A0






The solution all this is, to me, threefold=







=C2=A0






1) Factor out the bidirectionally check in a (trigge=
red) neighbour detection mechanism=C2=A0






(triggered HELLO message)






=C2=A0






2) Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, =
since they add complexity for no perceivable benefits






=C2=A0






3) Use the security model that we=E2=80=99ve discuss=
ed previously, where (only) the metrics change per hop.






=C2=A0






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 related issue, as I hinted previously.





=C2=A0








The abstract states that the protocol:






=C2=A0






=C2=A0=C2=A0 ...is intended for use by mobile routers in wireless, mul=
tihop


=C2=A0=C2=A0 networks.




=C2=A0






Section 5 paragraph 4 =C2=A0of the document, however, re=
ads:






=C2=A0






=C2=A0=C2=A0 Assuming link metrics are symmetric, the cost of the rout=
es installed


=C2=A0=C2=A0 in the Local Route Set at each router will be correct.=C2=
=A0 While this


=C2=A0=C2=A0 assumption is not always correct, calculating incoming/ou=
tgoing


=C2=A0=C2=A0 metric data is outside of scope of this document. =





=C2=A0








I do not know of any wireless systems,=
 where the assumption that =E2=80=9Clink metrics are symmetric=E2=80=9D act=
ually holds. Consequently, the conclusion in the quoted paragraph:






=C2=A0


=C2=A0=C2=A0 calculating incoming/outgoing


=C2=A0=C2=A0 metric data is outside of scope of this document.<=
u>




=C2=A0








Is not an acceptable design choice.





=C2=A0






While this protocol may not want to =E2=80=9Ccalcula=
te if for this link the metrics is 4 or 5=E2=80=9D, the protocol must be ab=
le to convey and distinguish that =E2=80=9Cthe metric from A to B is 4, and=
 the metric from B to A is 19=E2=80=9D.






=C2=A0






This is a =E2=80=9Crelated issue=E2=80=9D since the =
solution may (as with the bi-directionality check) be in the triggered neig=
hbour detection mechanism: that exchange could, if designed carefully, be u=
sed to probe for and convey metrics information, also.






=C2=A0






Hope this helps,






=C2=A0






=C2=A0






Thomas






=C2=A0












On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK)=
 <chr=
is.dearlove@baesystems.com> wrote:




=C2=A0








Assuming for the moment t=
hat everyone will need an RREP-Ack or won=E2=80=99t (let=E2=80=99s come bac=
k to that) why do C and B need to put an address in as an RREQ-Ack request?
 Why not a flag, because the address will be included as the IP sending add=
ress - and we know 5444 is required to pass that on. (It=E2=80=99s used by =
NHDP as well.) Then we don=E2=80=99t need to change the RREP, it will have =
a flag set or not, and won=E2=80=99t change (in this regard).=







=C2=A0






Now let=E2=80=99s conside=
r do we know whether we can set a fixed flag. First I=E2=80=99d say there a=
re two cases - you=E2=80=99ve got a firm control on what=E2=80=99s going on=
 in your network,
 or it=E2=80=99s one of unknown parties and behaviour (consistent with spec=
ification). In the former case you only want one setting, for example no-Ac=
k if running NHDP or your MAC layer tells you about bidirectionality, Ack o=
therwise. In the latter case, I think you
 just always want an Ack. So both cases get you to the same place.






=C2=A0






Should that not be an acc=
eptable argument (though I think it=E2=80=99s good for where we are - in fa=
ct always Ack is close) then at flag is a step better, it=E2=80=99s a fixed
 location to change. However it would be better in that case if the two thi=
ngs to change (metric and ack flag) were together. But that has its own iss=
ues, so I won=E2=80=99t go there.






=C2=A0




--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44 (0)12=
45 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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:=C2=A0Victoria Mercieca [mailto:vmercieca0=
@gmail.com]=C2=A0

Sent:=C2=A025 April 2016 14:15

To:=C2=A0Jiazi YI

Cc:=C2=A0Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad=
 Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)






=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=C2=A0=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.








Hi Jiazi,










=C2=A0








On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <ietf@jiaziyi.com> wrote:








Hi,=C2=A0








=C2=A0








On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christop=
her (UK) <chris.dearlove@baesystems.com&=
gt; wrote:










With regard to your valid=
ity time point, we here have a tradeoff. If you allow that feature, it sign=
ificantly impacts on the approach that was coming together
 on as best you can end to end encryption.






=C2=A0






So the question is, is th=
is a feature that=E2=80=99s really wanted? Unfortunately I think we know th=
at the answer to that is, we don=E2=80=99t know because we don=E2=80=99t ha=
ve any
 experience. My view would be that in the tradeoff of an untested feature (=
unless I=E2=80=99m wrong about that) and the security complication, securit=
y wins and drop the feature. If there is some real requirement, then there=
=E2=80=99s a discussion. (Questions like how often
 the intermediate routers actually have any knowledge - typically links bre=
ak for unexpected rather than expected reasons. Andan intermediate router c=
ould possibly use a validity time to influence its behaviour.) Note that dr=
opping the ability of intermediate
 routers to modify/set still allows validity times per route to be set at e=
ndpoints.












=C2=A0










I agree with Chris' concern.










The ValidityTime is optional, which makes the integr=
ity protection hard. Furthermore, it gives a potential attack vector: as al=
l the routers in a path will take the shortest validityTime, a compromised =
router can set the the validityTime
 to a very short value, which will make the route installed along the path =
became invalid (very soon).=C2=A0










=C2=A0










On the other hand, I'm not sure this option will=
 give us much help. Chris mentioned much knowledge intermediate router woul=
d have to decide this value (and how much sense the value would make).=C2=
=A0










Another issue is, a route to a destination might be =
updated by different sources. For example, in the network below:<=
/u>










=C2=A0










=
A----B-----C










=C2=A0










A first establish a route to B with long validity ti=
me. Then A initiates a route discovery to C. C tends to set a short validit=
y time, which will make the route between B and A expire earlier than expec=
ted.=C2=A0










Is this a problem? Maybe yes, maybe no -- I'm no=
t sure it's considered or not.=C2=A0










=C2=A0
















=C2=A0








Not sure I follow her=
e.






Currently, the validi=
ty time of the route between A and B would not affected by a short validity=
 time of a route between A and C. Validity times are per-route, and the rou=
te A-B and the route A-C are separate.








If we switched to a validity time per neighbor (so t=
hat we can keep validity time separate from route advertisements) as I ment=
ioned in the email below, then the validity of a route between A and C woul=
d be affected if there was a short
 validity time between A and B. But, if B will only route for a certain amo=
unt of time, then the route between A and C will of course be affected. Is =
it best to know in advance that there's a time limit, or just deal with=
 RERRs when they happen?








=C2=A0<=
/p>







=C2=A0






















=C2=A0






With regard to the acknow=
ledgements, the problem (with regard to security) comes from trying to do t=
wo jobs with the same message - end to end route advertisement
 and hop by hop acknowledgement. I understand the reasons - saving bytes an=
d message types. (I would have to study the protocol really hard to identif=
y if any message types can be folded together and recognised by content rat=
her than type efficiently. This
 I do not expect to do.) Again a tradeoff. This one is in discussion space,=
 though that needs people who understand both sides of the issue, including=
 the details of the bidirectionality mechanism. Of course, as has been said=
, we need one of those.














=C2=A0










I haven't finished my review of the latest draft=
, and I don't get the necessity of AckReq and the corresponding multica=
st RREP yet.=C2=A0










If possible, this "optional" field should =
be avoided.=C2=A0










=C2=A0


















To give an overview of AckReq and RREP:






Since AODVv2 requires=
 bidirectional links, this is the way to determine if a link is bidirection=
al.








A----B----C












1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install a=
 route to OrigAddr but they dont yet know if it's valid because they do=
nt know if the link to their next hop is available in the reverse direction=
.










2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).










3) B receives the RREP, installs a route to TargAddr=
 and marks it as valid, since it knows the link to C is bidirectional, beca=
use the RREQ went in one direction and the RREP came in the other. B also s=
ends the RREP_Ack to C and forwards
 the RREP to A (and might change the message to indicate its own AckReq - i=
e that it requires an ack from A).










4) C receives the RREP_Ack from B, and therefore kno=
ws that B received the RREP, therefore the link is bidirectional. C can the=
n mark its route to OrigAddr as valid.










5) Similarly, A receives the RREP, installs the rout=
e to TargAddr and sends an RREP_Ack to B.










6) B receives the RREP_Ack and marks its route to Or=
igAddr as valid.










=C2=A0








Alternatively, in ste=
p 2, if C knows the link to B is bidirectional (perhaps from some earlier r=
oute discovery), it doesnt need to put the AckReq in the RREP. Then in step=
 3, since B doesnt know if the link
 to A is bidirectional, it changes the message to add the AckReq address, i=
n order to get an RREP_Ack from A.






If we want to avoid c=
hanging the message, we'll need to look at forwarding the RREP as-is, a=
nd creating a second message to solicit an RREP_Ack, in order to verify tha=
t the link is bidirectional before marking
 the route to OrigAddr as valid.=C2=A0








Kind regards,










Victoria.








=C2=A0<=
/p>







=C2=A0


















regards










=C2=A0










Jiazi










=C2=A0














=C2=A0




--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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:=C2=A0Victoria Mercieca [mailto:vmercieca0=
@gmail.com]=C2=A0

Sent:=C2=A023 April 2016 10:55

To:=C2=A0Christopher Dearlove

Cc:=C2=A0ietf@thomasclausen.org; Dearlove, =
Christopher (UK); Mobile Ad Hoc Networks mailing list<=
/p>











Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.










Hi Chris,








=C2=A0










These have both been in the draft in some form since=
 before I got involved... but I'll do my best to explain.=









=C2=A0










- For Validity Time, its a way to advertise that you=
 would only support the route contained in the message for a certain period=
 of time. The originator might use this, but the draft was written to allow=
 any intermediate node to be able
 to add it or update it too. The route created in the Local Route Set has a=
n expiration time associated with it, based on the received validity time.<=
u>










- For the AckReq address, its so that you can add in=
to a RREP a request for an acknowledgement, so that you don't have to h=
ave a different message type altogether for working out whether links to ne=
ighbors are bidirectional, and also, since
 you only care about bidirectionality on routes that are being set up, you =
dont need to constantly monitor all neighbors.










=C2=A0










=C2=A0










In order to avoid the potential AckReq-related chang=
es to each message, maybe we do need to introduce a different message speci=
fically for this. We could maybe use RREP_Ack to both request and acknowled=
ge? It means an extra message of control
 traffic that needs to be sent, maybe one extra message per hop on the path=
 of a RREP, but it could still be limited to neighbors which have participa=
ted in the route discovery rather than monitoring all neighbors at all time=
s.=C2=A0










=C2=A0










This message could maybe also include "I'm =
happy to route anywhere for a certain amount of time", sort of like wi=
llingness in OLSR/OLSRv2. So instead of having a validity time per route, i=
ts a validity time per neighbor. Then, for RREQ
 and RREP, only the metric value would change in transit, as discussed. How=
ever, that leads to some issues with deciding what a route's expiration=
 time is. You might know how long the next hop router is valid for, but wha=
t if a router beyond that, which was
 also part of the route, had a lower validity time? You couldn't determ=
ine the real validity time. Do we remove the route expiration time altogeth=
er to avoid this issue? In which case, we would have to rely on RERR messag=
es being sent for routes which become
 invalid when the neighbor's validity time has expired? So neighbor val=
idity time expiration is treated the same as a link break.









=C2=A0










What do you think?










=C2=A0










Kind regards,










Victoria.










=C2=A0










=C2=A0










=C2=A0










=C2=A0










=C2=A0












=C2=A0








On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlov=
e <chris@mnemosyne.demon.co.uk> wrote:<=
u>










Pretty much all of the discussion has been assuming =
only a metric value change. With multiple things changing many of the ideas=
 go out of the window. That reinforces the point about not making specifica=
tions now that might turn out to be
 wrong for ICVs.










=C2=A0










Ignoring how this misunderstanding happened, I'l=
l start by asking why. Metric changing I understand. Why the other two? (th=
ere's a partial explanation of one). What alternatives have people impl=
emented in comparable protocols?



-- =C2=A0








Christopher Dearlove














On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmai=
l.com> wrote:


















Hi all,










=C2=A0










Continued in this thread because the other one seems=
 to be more about TLV types and metric type numbers, whereas this is about =
regeneration/forwarding.










=C2=A0










To recap, in the current draft, there are 3 things t=
hat might change at each hop:=C2=A0

- the metric value (happens in RREQ and RREP),=C2=A0

- adding/changing Validity Time using the Validity Time TLV (can happen in =
RREQ and RREP),=C2=A0

- adding an address (and corresponding value in the AddressType TLV to indi=
cate how to interpret the address) to indicate the address from which an RR=
EP_Ack is expected, to accomplish the bidirectionality check (can happen in=
 RREP).



If we define=C2=A0a certain portion of the message as immutable and include=
 the ICV to verify that part, end to end:=C2=A0

- The metric value would be excluded from the ICV since it needs changing a=
t each hop.=C2=A0

- Would adding a Validity Time TLV at an intermediate hop be acceptable? Th=
e whole TLV could be removed in order to calculate the ICV?







- Would adding an address cause issues for the ICV, =
because it's in the address block? Could the rule be "if it contai=
ns an AckReq address, remove it (and the corresponding value in the Address=
Type TLV), before checking the ICV", is that
 OK? Or would we need to avoid touching the ICV'ed part of the message =
altogether, maybe put the AckReq address in a separate Address Block, with =
an extra AddressType TLV following that address block? Is there a way to ac=
complish this?










=C2=A0










Also, to be thorough, do we need to consider RERR me=
ssages while we discuss regeneration vs forwarding?=C2=A0










- RERR (sent when a link breaks) is a way of saying =
"I've lost my route so I'm telling others" and "you =
were my next hop, so=C2=A0now=C2=A0I've also lost my route, I'll te=
ll others", etc. It's going to be tailored at each step to include=
 the relevant
 routes that got deleted, it's not one message being sent end-to-end li=
ke RREQ and RREP are.=C2=A0










- However, RERR (sent when a source of traffic is se=
nding data on a route which comes through you, and you want to tell the Pac=
ket Source's router to delete the route) could be seen as an end-to-end=
 message which all intermediate routers
 learn from, similar to RREQ and RREP. It reports one route, and doesn'=
t need changing at intermediate hops, so could be protected with ICV.










- Would it be OK to only require a message ICV if a =
PktSource address was included, i.e. when the message needs to go via a num=
ber of intermediate hops to PktSource's router? All other RERRs are int=
ended to be one-hop messages, which may
 in turn prompt other one-hop messages, etc..., and a packet ICV might be m=
ore appropriate?










=C2=A0








Kind regards,








Victoria.










=C2=A0








On Thu, Mar 17, 2016 at 5:26 PM, <i=
etf@thomasclausen.org> wrote:








=C2=A0












On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:








=C2=A0












Yes, I meant AODVv2, than=
ks for the catch.










=C2=A0










So is your (Thomas) propo=
sed base specification a hop count only metric?
















=C2=A0








No, the would be silly as base specification, given =
that hop count mostly is useless.










=C2=A0










As base specification I would simply say =E2=80=9CIn=
clude a Metric Type Message TLV with a value field, and a 7182 Message TLV =
& Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage =
as to generation and processing).=C2=A0










=C2=A0










With the message generated by the originator of the =
RREQ/RREP and *not* deconstructed/reconstructed/reordered (as is the risk w=
ith =E2=80=9Cregeneration) allows knowing that it would be *only* that metr=
ic field being modified (other than hop count/limit)
 for when eventually writing up the extension.










=C2=A0
















(Actually doesn=E2=80=99t=
 the current specification only define hop count, or has that changed in la=
test draft?)














=C2=A0








No. That is one of the issues I raise in my original=
. For some reason, it cites RFC6551, which is a ROLL document and which has=
 in its abstract that:










=C2=A0








=C2=A0=C2=A0 Low-Power and Lossy Networks (LLNs) have unique character=
istics


=C2=A0=C2=A0 compared with traditional wired and ad hoc networks that =
require the


=C2=A0=C2=A0 specification of new routing metrics and constraints. =







=C2=A0










I.e. this document cites a metric document which cle=
arly claims to be inapplicable in ad hoc networks. I note that this is anot=
her thing I=E2=80=99ve raised for years without seeing it attempted resolve=
d.










=C2=A0










Best,










=C2=A0










Thomas










=C2=A0










=C2=A0














=C2=A0








--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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:=C2=A0ietf@thomasclausen.org=
=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 17:10

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Lotte Steenbrink; Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.










=C2=A0
















On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:












=C2=A0














OK, so we have a message =
that mutates by:














- Modifying hop count/lim=
it.














- Modifying a metric valu=
e.














Anything else?<=
/u>














=C2=A0














As mutating (other than h=
op count/limit) messages aren=E2=80=99t covered by 5444 or any derivative d=
ocument (but only recommended against, not banned) that you may
 need to make the message otherwise immutable (no deconstruction and rebuil=
ding, other than guaranteed unchanging) that would have to be specified by =
AODVv2. (Easy to say, but needs saying.)


















=C2=A0












With you so far.












=C2=A0<=
/p>









Then that information is =
not in a guaranteed fixed location given by a simple offset. So any signatu=
re algorithm that finds it and ignores it or aggregates
 on it is specific to OLSRv2.














=C2=A0












Surely you mean AODVv2












=C2=A0<=
/p>









So standard 7182 ICVs don=
=E2=80=99t do the job, you would need an AODVv2 specialised variant. Which =
is the sort of thing that the message specific TLV space is there
 for, I=E2=80=99d be strongly against a =E2=80=9Cbut ignore the value of th=
is specific TLV should it occur=E2=80=9D being in the general space. Howeve=
r it can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like =
that TLV, except if an X TLV is present, set its value field to
 zero=E2=80=9D).














=C2=A0














Messy, but could work.














=C2=A0












Not that messy, actually, although clearly not as ni=
ce as =E2=80=9Cfixed offset=E2=80=9D.














=C2=A0














That said, I am arguing for the base spec being:<=
/u>














=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=E2=80=9Cmake the message otherwise immutable (no deco=
nstruction and rebuilding, other=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=A0than guaranteed unchanging)=E2=80=9D which is af=
forded by forwarding














=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7182 Timestamps and ICVs.














=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7183 style text bringing it all together.=















=C2=A0














The =E2=80=9Caggregated signatures around mutable fi=
eld=E2=80=9D would very be an experimental extension.














=C2=A0














What I object to is, if the base spec specifically r=
enders such extensions impossible














=C2=A0












=C2=A0<=
/p>









=C2=A0










--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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:=C2=A0Lotte Steenbrink [mailto:lo=
tte.steenbrink@fu-berlin.de]=C2=A0

Sent:=C2=A017 March 2016 16:48

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0ietf@thomasclausen.org; Mobile Ad =
Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)


















=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.












Hi all,
















=C2=A0




















Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher=
 (UK) <chris.dearlove@baesystems.com>=
:
















=C2=A0


















Good point about whether =
you just pass on one cost or a set of costs. As I said, not looked at detai=
ls - I will, when time permits. One cost is much easier,
 and yes, it reduces the fixed size aggregated signatures problem to =E2=80=
=9Cjust=E2=80=9D one of computational load.






















=C2=A0


















For the record, Thomas=E2=80=99 understanding is cor=
rect; the cost is one aggregated value.=C2=A0


















=C2=A0


















Best regards,=C2=A0


















Lotte Steenrbink














=C2=A0<=
/p>















=C2=A0












--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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:=C2=A0ietf@thomasclausen.org=
=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 16:38

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: Message integrity and message mutability (was RE: =
[manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)






















=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.














=C2=A0
























On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:




















=C2=A0






















I appreciate Thomas=E2=80=
=99s comments about the limitations of message regeneration, but I would be=
 a bit less absolute.






















=C2=A0






















The issues over end to en=
d authentication and more advanced signatures are valid. I need to read the=
 given reference on aggregate signatures to increase my
 knowledge (thanks for it), but my understanding of the possibilities in th=
is field may offer a solution to the problem, but with some other issues (p=
ossibly including a new type of TLV).






















=C2=A0






















But the hop count/limit p=
oint I don=E2=80=99t fully agree with, you can regenerate with an increment=
ed/decremented count/limit, which leaves the ability to prevent
 messages propagating indefinitely, including expanding ring searches, and =
retains the ability to use RFC 5497 interval and validity times that might =
be useful with an expanding ring search (or might not).






















=C2=A0






















But the key issue is that=
 AODVv2 wants to accumulate metrics. I still haven=E2=80=99t got to the bot=
tom of many details here, but let=E2=80=99s for the moment just consider
 that conceptually.






















=C2=A0






















It=E2=80=99s hard to hand=
le end to end. Charlie=E2=80=99s draft attempts to do an end to end of some=
 information, not this information. I=E2=80=99m not sure if that=E2=80=99s =
useful (and the
 specialised format is better avoided if possible). Other approaches are ho=
p by hop (might as well use packet signatures) and shared key (might as wel=
l go hop by hop). Pairwise signatures for each pair of routers I=E2=80=99m =
discounting as scaling terribly. In the
 interests of completeness let=E2=80=99s mention not accumulating metrics, =
which puts us back to hop count and that=E2=80=99s not ideal either.=























=C2=A0






















I don=E2=80=99t think the=
re is an ideal solution. (I like ideas I=E2=80=99ve seen about aggregating,=
 but that has some issues of its own, even apart from computational load.)
 I=E2=80=99d love to be proved wrong - someone with the perfect solution to=
 come along.






















=C2=A0






















Which means that either w=
e make an arbitrary choice - which will be disagreed with, but needs discus=
sing first - or create something flexible. Unfortunately
 flexible in that regard constrains in others, e.g. some (many? most?) aggr=
egating signatures need fixed data sizes (which we can do by defining a TLV=
 that =E2=80=9Cfills up=E2=80=9D with hop count, but that has a cost too).<=
/span>


























=C2=A0




















I have been told by people much more well versed in =
this than I in cryptology, that the correct answer is =E2=80=9Csome=E2=80=
=9D.






















=C2=A0






















That said, "AODVv2 wants to accumulate metrics=
=E2=80=9D =E2=80=94 does that mean that the message grows as it is being fo=
rwarded, and that the recipient of a RREQ/RREP will know the individual cos=
ts of each path segment? My understanding is, that the recipient
 will get =E2=80=9Cthe sum the costs of each path segment=E2=80=9D which sh=
ould be fitting within a fixed size?






















=C2=A0






















Thomas






















=C2=A0




















=C2=A0<=
/p>



















=C2=A0






















Sorry, no answers, just c=
omments. And I=E2=80=99m not addressing Thomas=E2=80=99s later points here.=























=C2=A0














--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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:=C2=A0manet [mailto:manet-bounces@ietf.o=
rg]=C2=A0On
 Behalf Of=C2=A0ietf@thomasclausen.org

Sent:=C2=A017 March 2016 16:00

To:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0[manet] draft-ietf-manet-aodvv2-13 review - a couple o=
f big ticket Items


























=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.








***=C2=A0<=
/b>WARNING=C2=A0***

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














=C2=A0
























Dear all,
























=C2=A0


























Apologies for not having gotten this done sooner - d=
ay-job leaving few spare cycles.


























=C2=A0


























I=E2=80=99ve previously offered reviews and comments=
, and some of those have been addressed in the latest I-D =E2=80=94 others =
have not, but should be. I recall that there was some mail attempting to re=
but parts of the review, and I will dig it out and
 reply to that.


























=C2=A0


























With that being said, I have reviewed the latest ver=
sion of the document, and full details will be forthcoming. There=E2=80=99r=
e a couple of big-ticket/architectural items that I want to address up fron=
t, as I believe that before we have those
 hammered out, it will be useless to go into details. Note, I do not claim =
that this is an exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D, but =
that=E2=80=99s as far as I have gotten in thinking this through.<=
/u>


























=C2=A0


























I also bring these up as they are items that have be=
en brought up repeatedly over the past years, but not resolved nor discusse=
d.


























=C2=A0


























Loops


























Just to bring this out: I share Chris=E2=80=99 worry=
 about conflicting and concurrent statements from the authors on =E2=80=9CT=
here are no loops possible=E2=80=9D and =E2=80=9CWe need to fix two situati=
ons where loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating =
some loop
 conditions=E2=80=9D


























=C2=A0


























I particularly worry that this is not a discussion h=
ad in public, but apparently in some other forum=E2=80=A6


























=C2=A0


























=C2=A0




























Intermediate Route Replies, and all of section=
 10


























Section 10 contains a set of =E2=80=9Cvaguely specif=
ied extensions=E2=80=9D, which is incoherent with the intended status indic=
ated for this document.=C2=A0


























=C2=A0


























Specifically, and this is not unrelated to the point=
 about loops above, intermediate RREPs (section 10.3) are a potential sourc=
e for loops.


























=C2=A0


























Expanding Ring Multicast (section 10.1) is not docum=
ented in a way that can be implemented (and also, see =E2=80=9CForwarding-v=
s-regeneration=E2=80=9D below, it is in the present form of this protocol i=
mpossible), etc.




























=C2=A0


























=C2=A0


























Forwarding-vs-regeneration


























Recent exchanges on the list made me understand that=
 protocol control messages are *not* forwarded, but are consumed at each ho=
p, then a new message with (almost-but-not-quite) the same content is gener=
ated and transmitted.


























=C2=A0


























I have thought some more on this (& read some of=
 the exchanges on the list on this topic by Chris, Ulrich, and others), and=
 I am convinced that this is not the right way to go,=C2=A0at least=
=C2=A0for the following reasons:


























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It renders the hop-limit/hop-count fields in the RFC5444 messag=
e header useless.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0This would not be bad if the functionality offered by tho=
se fields was not useful


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=94 sadly, it is. For example, for scope limited fl=
ooding (expanding ring search, and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0such) which may be of interest, and which require hop-lim=
it.=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0A hop-count field may also provide a =E2=80=9Ccheap=E2=80=
=9D (in terms of overhead) additional piece


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of information to use conjunctively with a =E2=80=9Creal=
=E2=80=9D metric.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The only practical solution would be to re-introduce thes=
e functions by way of inserting a


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0MessageTLV =E2=80=94 which (i) is not specified in this d=
ocument, and (ii) which would just


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0serve to render messages bigger than strictly needed.<=
/u>


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Scope limited flooding =C2=A0does seem to be a necessary =
requirement, if for no


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0other reason than to prevent information from =E2=80=9Cci=
rculating forever in the network=E2=80=9D.


























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It makes end-to-end authentication unnecessarily hard.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I think Chris called this out already, but it bears repea=
ting: S generates a message=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(say, a RREQ), and includes an ICV calculated over the co=
ntent of the message.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0For any recipient to be able to validate the ICV, the mes=
sage has to be exactly


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0the same =E2=80=94 not just in content, but in structure =
=E2=80=94 as what was generated.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforwa=
rding=E2=80=9D messages means, that the intermediate


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose =
a different structure (e.g., include TLVs


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0in a different order).


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The proposal from=C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00=



























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0is to add constraints on (i) the set of elements to inclu=
de in a signature and (ii) the


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0order of these elements.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0One=C2=A0problem with that approach is (i): if an extensi=
on adds a message TLV, or an=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Address TLV, to a message, then that will not be =E2=80=
=9Ccovered=E2=80=9D by the proposed e2esec TLV.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Rather for *each* extension developed, an =E2=80=9Cupdate=
s e2esec=E2=80=9D clause needs to be done.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I=E2=80=99d say that this approach would be prone to erro=
rs =E2=80=94 and add entropy to the process


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of designing protocol extensions. The alternative, a mess=
age being generated by the


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0source and *forwarded* (as we do in OLSRv2, for example) =
would allow ICV TLVs=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(even, allow reuse of those specified for OLSRv2) for cov=
ering a message and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0extensions.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CBut what about the metrics value which will chan=
ge on each hop=E2=80=9D, you may say?


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Fortunately, that is relatively easy to handle: simply ze=
ro out the value of that TLV when


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0generating or verifying the ICV MessageTLV. And use Packe=
t-TLVs for hop-by-hop=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0authentication, if needed (but, see below).=



























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It prevents the use of more clever/advanced signature scheme=
s/ICVs


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Aggregate signature algorithms (=C2=A0https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf<=
/span>)


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0exist, and an interesting use-case can be found in also r=
eactive protocols, allowing verifying


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0not =E2=80=9Cjust=E2=80=9D the end points, but also the i=
ntermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0discussed above, or something smarter).


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Regeneration of messages, rather than forwarding, renders=
 that impossible (or, if used,


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0updating to =C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)


























=C2=A0


























There are other reasons, but the above are those tha=
t jump at me as immediate show-stoppers.


























=C2=A0


























I do honestly not see what possible benefit there is=
 from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inconve=
niences, and security is not the least of these. Insisting on =E2=80=9Crege=
neration=E2=80=9D requires development of =E2=80=9Cnon-general workarounds=
=E2=80=9D as pointed
 out above.


























=C2=A0


























Security Considerations<=
/p>

























This is an always thorny subject. When OLSRv2 was go=
ing through the process we got a thorough education in how little we knew a=
bout security from the SEC-ADs, and had to spend about a year or so develop=
ing RFC7183. The bottom line is, that
 this protocol needs its =E2=80=9CRFC7183 =C2=A0equivalent=E2=80=9D, either=
 as part of the main document, or as an independent document. currently, th=
at is not the case.


























=C2=A0


























A minima, looking at BCP72 and BCP107 =E2=80=94 taki=
ng inspiration from RFC7183 might be aw good idea, as that was the most rec=
ent that went through the SEC AD. Regardless of how, however, a =E2=80=9Cma=
ndatory to implement=E2=80=9D security mechanism most be specified
 (I think the right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D),=
 in sufficient detail to ensure interoperable implementations.


























=C2=A0


























As an example, both [RFC6130] and [RFC7181] set out =
that that:




























=C2=A0


























=C2=A0 =C2=A0 =C2=A0 On receiving a ... message, a r=
outer MUST first check if the


























=C2=A0 =C2=A0 =C2=A0 message is invalid for processi=
ng by this router


























=C2=A0


























and then proceed to give a number of conditions that=
, each, will lead to a rejection of the message as "badly formed and t=
herefore invalid for processing=E2=80=9D =E2=80=94 a list which RFC7183 the=
n amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting
 =E2=80=9Crejection=E2=80=9D. Idem for message generation.

























=C2=A0


























If I was to do RFC7181/RFC6130 today, I would includ=
e that directly into the protocol specifications. It turned out to be more =
overhead (and slow down publication anyways) to do it as separate documents=
.




























=C2=A0


























Secondly, we need to be a lot more rigid in terms of=
 what ICVs, Timestamps, etc. are added/removed, and what that brings.


























=C2=A0


























For example (with the assumption that messages are *=
forwarded* and *not* regenerated), this could be one option:<=
/p>

























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0When a RREQ, RREP message is generated, add an ICV Message TLV, which=
 is calculated <this way>


























=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=E2=80=A6(take inspiration from RFC7183 here)


























=C2=A0


































...



[Message clipped]=C2=A0=C2=A0

_______________________________________________

manet mailing list

manet@ietf.org

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/manet






=C2=A0
















_______________________________________________

manet mailing list

manet@ietf.org

<=
span style=3D"color:purple">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 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

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/manet








=C2=A0














=C2=A0










______________________________________=
_________

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




=C2=A0












--001a114fd886757c730531506d80--


From nobody Mon Apr 25 08:01: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 16B1D12D1B0 for ; Mon, 25 Apr 2016 08:01:03 -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 il3SkMgWGigE for ; Mon, 25 Apr 2016 08:01:01 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 5595612D530 for ; Mon, 25 Apr 2016 08:01:01 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id g133so189350784ywb.2 for ; Mon, 25 Apr 2016 08:01: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=WGa67Dp3RJJ6Kd51RZ+2SCEhwi9hBcEHlj8x4b4eibw=; b=WRF8RClfEVqJSm+D994iwQonU28KrBTTsQTouiGiapbHXhvxPlgIJDq8LBEaTIvfIU EMrkYjCMubFg64oTF4UN12vcmPBLbPAR30NF6ne0LHrue+NahnxZwTwT0nxDPDmS42fb ARYeWcjfbshx5l/s6JdvZY+T/mtLdehApQGCxjHIfgSBdiQF2CitkQv+MU1CMf0oe9co IURqBqB5y00Yakgf422ezKsQ3IBdIMz/2eUko3GKWoKg9DL3L4YLgt8+Zw9Yel6gLKV0 kFXXLK7E/FBWluo/Cd+o3w588hGWcGptBbYRdwQ2V1GHhgQHqtr6E+LyyKfSmcc/Wsxa 0YGw==
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=WGa67Dp3RJJ6Kd51RZ+2SCEhwi9hBcEHlj8x4b4eibw=; b=kALsfhONqtarznhg3vf+AUxxNgAEZORj8YRYUo2iJNTW/zwiyTHaqbF1kn4qon4vQu idFbxOTToAWQyOgXarqxCDNhV6ycjPRl3UmZhMvJQRNpJHjBzg3mfLEWcBybr1LshLA+ SIuMgoMp9krG0MKPEF5aWL7xcDd6FBRNO1s76ibefpNVllfFrxYIS2RdiSDQSIogI1df bTZmviIsnTK/ZPDGyAM+SkeGwKzkhYtD6VFm2U94Eb00ii/RuzX4b+9yPeO0wozs3tdY P4L2Rw1IO3jvVuY2K2C4ByOFZPFdAoidBS548bnT+JRysXIfalWRn6Q54UUnqaJmuYWj 2w5A==
X-Gm-Message-State: AOPr4FXtUyY9uc8nlX2qoFQU+OD9VS1mQE53jm5OuflQEAFs9Yi6nELay96JyciE/xhtHiZpwQLtj2QMv29+nw==
MIME-Version: 1.0
X-Received: by 10.176.65.133 with SMTP id 5mr6168061uap.29.1461596458015; Mon, 25 Apr 2016 08:00:58 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Mon, 25 Apr 2016 08:00:57 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org>  
Date: Mon, 25 Apr 2016 11:00:57 -0400
Message-ID: 
From: Justin Dean 
To: "Dearlove, Christopher (UK)" 
Content-Type: multipart/alternative; boundary=94eb2c093e42b0194305315071f6
Archived-At: 
Cc: Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 15:01:03 -0000

--94eb2c093e42b0194305315071f6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 25, 2016 at 10:51 AM, Dearlove, Christopher (UK) <
chris.dearlove@baesystems.com> wrote:

> I has to go back to Victoria=E2=80=99s summary here. It says:
>
>
>
> 2) C creates the RREP. Since it doesnt know if the link to B is
> bidirectional, it includes the AckReq (an address to indicate that it
> expects to receive a RREP_Ack from B).
>
>
>
> That doesn=E2=80=99t actually indicate if that=E2=80=99s C=E2=80=99s addr=
ess or B=E2=80=99s address being
> included. I=E2=80=99d assumed it was C=E2=80=99s address. Your comment ma=
kes sense if it=E2=80=99s
> B=E2=80=99s address. Reading again, I think you=E2=80=99re probably right=
. But only
> probably. Can we confirm that.
>
>
>
> I assume you meant that the RREP (not RREP_Ack) is multicast. There=E2=80=
=99s a
> bit of a chicken and egg problem here. We do know how we want to unicast.
>
> Yes I meant RREP and not RREP_Ack.

>
>
>From 7.2.3 again

The procedure for RREP regeneration is as follows:

   1.  If the link to the next hop router toward OrigAddr is not known
       to be bidirectional, include the AckReq with the address of the
       intended next hop router

 2. Set AddressList, PrefixLengthList, TargSeqNum and MetricType to

       the values in the received RREP

   3.  Set TargMetric :=3D LocalRoute[TargAddr].Metric


4.  If the received RREP contains a ValidityTime, or if the
       regenerating router wishes to limit the time that it will offer a
       route to TargAddr (and any other addresses included in the given
       prefix length), the regenerated RREP MUST include ValidityTime

       *  The ValidityTime is either the time limit the previous AODVv2
          router specified, or the time limit this router wishes to
          impose, whichever is lower.

--94eb2c093e42b0194305315071f6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Apr 25, 2016 at 10:51 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:











I has to go back to Victoria=E2=80=99s summa=
ry here. It says:


=C2=A0


2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).


=C2=A0


That doesn=E2=80=99t actually indicate if th=
at=E2=80=99s C=E2=80=99s address or B=E2=80=99s address being included. I=
=E2=80=99d assumed it was C=E2=80=99s address. Your comment makes sense if =
it=E2=80=99s B=E2=80=99s address.
 Reading again, I think you=E2=80=99re probably right. But only probably. C=
an we confirm that.


=C2=A0


I assume you meant that the RREP (not RREP_A=
ck) is multicast. There=E2=80=99s a bit of a chicken and egg problem here. =
We do know how we want to unicast.


<=
div>Yes I meant RREP and not RREP_Ack.=C2=A0
=C2=A0
From 7.2.3 again
The procedure for RREP regeneration is as follows:

   1.  If the link to the next hop router toward OrigAddr is not known
       to be bidirectional, include the AckReq with the address of the
       intended next hop router
=C2=A02.  Set Ad=
dressList, PrefixLengthList, TargSeqNum and MetricType to
       the values in the received RREP

   3.  Set TargMetric :=3D LocalRoute[TargAddr].Metric


4.  If the r=
eceived RREP contains a ValidityTime, or if the
       regenerating router wishes to limit the time that it will offer a
       route to TargAddr (and any other addresses included in the given
       prefix length), the regenerated RREP MUST include ValidityTime

       *  The ValidityTime is either the time limit the previous AODVv2
          router specified, or the time limit this router wishes to
          impose, whichever is lower.


--94eb2c093e42b0194305315071f6--


From nobody Mon Apr 25 08:29: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 37F2812D1B9 for ; Mon, 25 Apr 2016 08:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.093
X-Spam-Level: 
X-Spam-Status: No, score=-1.093 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, TRACKER_ID=1.306] 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 nvCBOWCUeV7p for ; Mon, 25 Apr 2016 08:29:48 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c: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 D1FCD12B03B for ; Mon, 25 Apr 2016 08:29:47 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id 127so23955581wmz.0 for ; Mon, 25 Apr 2016 08:29:47 -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=9aS/wffKSSk25MQnXG7hkGWRUeO6ggl//yI7zzDmZeE=; b=pzF7BNkyget1YgBD+LVtDtM3t8OPUGAq4vebyeyMK67fiIST7cghU/qqxor/woj6Gr y/IM2LVfzWkmbsOH5/o8fp43a39l7kEJSWYxA9Ad3XZokEh8YnHoFGz3PY6Fg/vdcafA NfVNZPnQtwd9QfjFE5Xpbo8TxNrg5FuOuE0fbaProiKja5FAzQhRCSWb3JoQjsxfx6an B0wd5CGSWEadKiq01A6EodrCTm1wfHlVEwcpYdv16kdoDkhHuDX4BhkauHmlNc8fp4TZ 4D+1B3MEprrvcoXir1ZTOiCdiVVHVrtB+KZvF9TenYQvh++o0hECxusCByLwczNaqiJu 6/rA==
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=9aS/wffKSSk25MQnXG7hkGWRUeO6ggl//yI7zzDmZeE=; b=bJoyx1ioEnMZU5ZpW2fsd26m2OBdQk5y53PbaEAZeyXxd5AP+e6pmJXoLwKqOpO5xE uDlNs3E77gXyBIQlojJU+VDerm4A5tHyt4jNGC8exD8Vdo3Ht2v7JH8rXs17Yk7CKWJF r9oyyjsc/9Htmfk3JVJmNoBUhtv2g2S5v1fofj7NkplAfXzQtBsdqmZO0KStMV8DZS20 C7zDOhYi014Un+Qh9dJoWU77Wp8WKwYTXAGwwZ/9X6g+I/yQicUJvcZ2GUP2/4mhmWNC xIlY+CCOex7UORS3bxetzR1XFV9CFOk8hIbLlKFGIJzu+4q7Xf4Kx0FraRVUodimpkJf fwAQ==
X-Gm-Message-State: AOPr4FUIQC1iAQCCT71HqYNC/cm71+2IIXAPhOYkMGf9UAj4fwAJYHr6Bcqu81jFDMKTreiaix8Ty93R4GLn+Q==
MIME-Version: 1.0
X-Received: by 10.28.16.17 with SMTP id 17mr12377664wmq.17.1461598186144; Mon, 25 Apr 2016 08:29:46 -0700 (PDT)
Sender: yi.jiazi@gmail.com
Received: by 10.194.153.166 with HTTP; Mon, 25 Apr 2016 08:29:45 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org>   
Date: Mon, 25 Apr 2016 17:29:45 +0200
X-Google-Sender-Auth: ge9JwNLvAs1vKTPkey8FBNUKHUE
Message-ID: 
From: Jiazi YI 
To: Victoria Mercieca 
Content-Type: multipart/alternative; boundary=001a1145ad26b08c6e053150d8b5
Archived-At: 
Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 15:29:55 -0000

--001a1145ad26b08c6e053150d8b5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Maybe I missed a bit here:

If only the desired receiver of the multicast RREP (carrying a destination
address) can reply to the multicast RREP, why not using unicast directly?

best

Jiazi

On Mon, Apr 25, 2016 at 4:59 PM, Victoria Mercieca 
wrote:

> Hi Chris,
>
>
> On Mon, Apr 25, 2016 at 3:51 PM, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>> I has to go back to Victoria=E2=80=99s summary here. It says:
>>
>>
>>
>> 2) C creates the RREP. Since it doesnt know if the link to B is
>> bidirectional, it includes the AckReq (an address to indicate that it
>> expects to receive a RREP_Ack from B).
>>
>>
>>
>> That doesn=E2=80=99t actually indicate if that=E2=80=99s C=E2=80=99s add=
ress or B=E2=80=99s address being
>> included. I=E2=80=99d assumed it was C=E2=80=99s address. Your comment m=
akes sense if it=E2=80=99s
>> B=E2=80=99s address. Reading again, I think you=E2=80=99re probably righ=
t. But only
>> probably. Can we confirm that.
>>
>>
>>
>
> C creates the RREP. The included AckReq address is B's address. The RREP
> then gets multicast.
> B receives it, sees that it own address is marked as the AckReq address,
> and sends an ack unicast back to C.
> Anyone else who receives the multicast RREP from C does not send the Ack,
> since the AckReq address does not match any of their interface addresses.
>
>
>> I assume you meant that the RREP (not RREP_Ack) is multicast. There=E2=
=80=99s a
>> bit of a chicken and egg problem here. We do know how we want to unicast=
.
>>
>
> The RREP is multicast (when we dont know if the link is bidirectional),
> the RREP_Ack is always unicast.
>
> Kind regards,
> Vicky.
>
>
>>
>> *-- *
>>
>>
>>
>>
>> *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:* 25 April 2016 15:26
>> *To:* Thomas Heide Clausen
>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
>> Networks mailing list; Victoria Mercieca
>> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>>
>>
>>
>> **** 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
>> .*
>>
>> The address in the RREP_Ack may be required due to the RREP_Ack being
>> multicast as there is not yet a verified unicast route installed yet.
>> Going to double check if I'm remembering correctly.
>>
>> Justin
>>
>>
>>
>> On Mon, Apr 25, 2016 at 10:18 AM,  wrote:
>>
>> Hi,
>>
>>
>>
>> I must admit that while I have reviewed the protocol several times, I=E2=
=80=99ve
>> not been digging that deep into the protocol functioning to catch this
>> issue of how invasive the protocol operations are when forwarding a
>> message: there were other =E2=80=9Cmajor=E2=80=9D issues to address (and=
 which obscured the
>> details), so as a first order: thank you Victoria, for having called
>> attention to this.
>>
>>
>>
>> To the substance of these emails.
>>
>>
>>
>> I am afraid that I do not understand the use of inserting validity TLVs
>> while in-flight, into a message. Actually, I am dubious for both the
>> originator inserting this (how can the originator of a message know how
>> =E2=80=9Clatter parts of the path=E2=80=9D will be have=E2=80=9D) except=
 if we are talking
>> duty-cycling of devices and inserting =E2=80=9Cthe remaining time that I=
 am going
>> to be up before I suspend=E2=80=9D. Intuitively, that would also assume =
fairly long
>> duty cycles =E2=80=9CI am up for tens of seconds=E2=80=9D, which I am no=
t sure are actually
>> realistic. And, as Chris says in another email, this is trading off =E2=
=80=9Cthe
>> ability to do security=E2=80=9D for an unknown/untested feature =E2=80=
=94 which I think is
>> the wrong trade-off.
>>
>>
>>
>> On he topic of =E2=80=9Cneeding to put an address in=E2=80=9D for RREP-A=
CK, I must admit
>> that this seems roundabout. I can see three issues here:
>>
>>
>>
>> o I am not sure that adding an address vs. a flag may not have to do wit=
h
>> the =E2=80=9Cmultiple interfaces/
>>
>> multiple addresses=E2=80=9D discrimination mechanics of the protocol? I =
haven=E2=80=99t
>> worked it through, though,
>>
>> but that would be a guess.
>>
>>
>>
>> o The end-to-end topology diffusion mechanism should not need to be
>> concerned with the
>>
>> =E2=80=9Cbidirectionally check=E2=80=9D of a local link (in part, as it =
encumbers
>> security, but not only).  In short, a
>>
>> flag or an address, both are (equally) bad.
>>
>>
>>
>> o A cleaner mechanism would be a =E2=80=9Chello mechanism=E2=80=9D, not =
necessarily as
>> NHDP, but a =E2=80=9Cwhen
>>
>> forwarding a RREQ/RREP, trigger a 3-way hello exchange, if the link is
>> estimated to be of a
>>
>> type which potentially can be unidirectional=E2=80=9D. There is another =
benefit
>> to doing that, see the end
>>
>> of this email.
>>
>>
>>
>> Either way, I do not like the notion of fusing
>> metrics-and-link-bidirectionality-detection any more than I like fusing
>> global-topology-diffusion-and-link-bidirectionality-detection.
>>
>>
>>
>> The solution all this is, to me, threefold
>>
>>
>>
>> 1) Factor out the bidirectionally check in a (triggered) neighbour
>> detection mechanism
>>
>> (triggered HELLO message)
>>
>>
>>
>> 2) Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, since they add compl=
exity for no
>> perceivable benefits
>>
>>
>>
>> 3) Use the security model that we=E2=80=99ve discussed previously, where=
 (only)
>> the metrics change per hop.
>>
>>
>>
>> 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 related
>> 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 this
>>
>>    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 conclus=
ion 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 link =
the
>> metrics is 4 or 5=E2=80=9D, the protocol must be able to convey and dist=
inguish
>> 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 wit=
h the
>> bi-directionality check) be in the triggered neighbour detection mechani=
sm:
>> that exchange could, if designed carefully, be used to probe for and con=
vey
>> metrics information, also.
>>
>>
>>
>> Hope this helps,
>>
>>
>>
>>
>>
>> Thomas
>>
>>
>>
>> On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>>
>>
>> Assuming for the moment that everyone will need an RREP-Ack or won=E2=80=
=99t
>> (let=E2=80=99s come back to that) why do C and B need to put an address =
in as an
>> RREQ-Ack request? Why not a flag, because the address will be included a=
s
>> the IP sending address - and we know 5444 is required to pass that on.
>> (It=E2=80=99s used by NHDP as well.) Then we don=E2=80=99t need to chang=
e the RREP, it will
>> have a flag set or not, and won=E2=80=99t change (in this regard).
>>
>>
>>
>> Now let=E2=80=99s consider do we know whether we can set a fixed flag. F=
irst I=E2=80=99d
>> say there are two cases - you=E2=80=99ve got a firm control on what=E2=
=80=99s going on in
>> your network, or it=E2=80=99s one of unknown parties and behaviour (cons=
istent with
>> specification). In the former case you only want one setting, for exampl=
e
>> no-Ack if running NHDP or your MAC layer tells you about bidirectionalit=
y,
>> Ack otherwise. In the latter case, I think you just always want an Ack. =
So
>> both cases get you to the same place.
>>
>>
>>
>> Should that not be an acceptable argument (though I think it=E2=80=99s g=
ood for
>> where we are - in fact always Ack is close) then at flag is a step bette=
r,
>> it=E2=80=99s a fixed location to change. However it would be better in t=
hat case if
>> the two things to change (metric and ack flag) were together. But that h=
as
>> its own issues, so I won=E2=80=99t go there.
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com
>> ]
>> *Sent:* 25 April 2016 14:15
>> *To:* Jiazi YI
>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
>> Networks mailing list
>> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>>
>>
>>
>> **** 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
>> .*
>>
>> Hi Jiazi,
>>
>>
>>
>> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI  wrote:
>>
>> Hi,
>>
>>
>>
>> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>> With regard to your validity time point, we here have a tradeoff. If you
>> allow that feature, it significantly impacts on the approach that was
>> coming together on as best you can end to end encryption.
>>
>>
>>
>> So the question is, is this a feature that=E2=80=99s really wanted? Unfo=
rtunately
>> I think we know that the answer to that is, we don=E2=80=99t know becaus=
e we don=E2=80=99t
>> have any experience. My view would be that in the tradeoff of an unteste=
d
>> feature (unless I=E2=80=99m wrong about that) and the security complicat=
ion,
>> security wins and drop the feature. If there is some real requirement, t=
hen
>> there=E2=80=99s a discussion. (Questions like how often the intermediate=
 routers
>> actually have any knowledge - typically links break for unexpected rathe=
r
>> than expected reasons. Andan intermediate router could possibly use a
>> validity time to influence its behaviour.) Note that dropping the abilit=
y
>> of intermediate routers to modify/set still allows validity times per ro=
ute
>> to be set at endpoints.
>>
>>
>>
>> I agree with Chris' concern.
>>
>> The ValidityTime is optional, which makes the integrity protection hard.
>> Furthermore, it gives a potential attack vector: as all the routers in a
>> path will take the shortest validityTime, a compromised router can set t=
he
>> the validityTime to a very short value, which will make the route instal=
led
>> along the path became invalid (very soon).
>>
>>
>>
>> On the other hand, I'm not sure this option will give us much help. Chri=
s
>> mentioned much knowledge intermediate router would have to decide this
>> value (and how much sense the value would make).
>>
>> Another issue is, a route to a destination might be updated by different
>> sources. For example, in the network below:
>>
>>
>>
>> A----B-----C
>>
>>
>>
>> A first establish a route to B with long validity time. Then A initiates
>> a route discovery to C. C tends to set a short validity time, which will
>> make the route between B and A expire earlier than expected.
>>
>> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered o=
r
>> not.
>>
>>
>>
>>
>>
>> Not sure I follow here.
>>
>> Currently, the validity time of the route between A and B would not
>> affected by a short validity time of a route between A and C. Validity
>> times are per-route, and the route A-B and the route A-C are separate.
>>
>> If we switched to a validity time per neighbor (so that we can keep
>> validity time separate from route advertisements) as I mentioned in the
>> email below, then the validity of a route between A and C would be affec=
ted
>> if there was a short validity time between A and B. But, if B will only
>> route for a certain amount of time, then the route between A and C will =
of
>> course be affected. Is it best to know in advance that there's a time
>> limit, or just deal with RERRs when they happen?
>>
>>
>>
>>
>>
>>
>>
>> With regard to the acknowledgements, the problem (with regard to
>> security) comes from trying to do two jobs with the same message - end t=
o
>> end route advertisement and hop by hop acknowledgement. I understand the
>> reasons - saving bytes and message types. (I would have to study the
>> protocol really hard to identify if any message types can be folded
>> together and recognised by content rather than type efficiently. This I =
do
>> not expect to do.) Again a tradeoff. This one is in discussion space,
>> though that needs people who understand both sides of the issue, includi=
ng
>> the details of the bidirectionality mechanism. Of course, as has been sa=
id,
>> we need one of those.
>>
>>
>>
>> I haven't finished my review of the latest draft, and I don't get the
>> necessity of AckReq and the corresponding multicast RREP yet.
>>
>> If possible, this "optional" field should be avoided.
>>
>>
>>
>>
>> To give an overview of AckReq and RREP:
>>
>> Since AODVv2 requires bidirectional links, this is the way to determine
>> if a link is bidirectional.
>>
>> A----B----C
>>
>>
>> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both instal=
l
>> a route to OrigAddr but they dont yet know if it's valid because they do=
nt
>> know if the link to their next hop is available in the reverse direction=
.
>>
>> 2) C creates the RREP. Since it doesnt know if the link to B is
>> bidirectional, it includes the AckReq (an address to indicate that it
>> expects to receive a RREP_Ack from B).
>>
>> 3) B receives the RREP, installs a route to TargAddr and marks it as
>> valid, since it knows the link to C is bidirectional, because the RREQ w=
ent
>> in one direction and the RREP came in the other. B also sends the RREP_A=
ck
>> to C and forwards the RREP to A (and might change the message to indicat=
e
>> its own AckReq - ie that it requires an ack from A).
>>
>> 4) C receives the RREP_Ack from B, and therefore knows that B received
>> the RREP, therefore the link is bidirectional. C can then mark its route=
 to
>> OrigAddr as valid.
>>
>> 5) Similarly, A receives the RREP, installs the route to TargAddr and
>> sends an RREP_Ack to B.
>>
>> 6) B receives the RREP_Ack and marks its route to OrigAddr as valid.
>>
>>
>>
>> Alternatively, in step 2, if C knows the link to B is bidirectional
>> (perhaps from some earlier route discovery), it doesnt need to put the
>> AckReq in the RREP. Then in step 3, since B doesnt know if the link to A=
 is
>> bidirectional, it changes the message to add the AckReq address, in orde=
r
>> to get an RREP_Ack from A.
>>
>> If we want to avoid changing the message, we'll need to look at
>> forwarding the RREP as-is, and creating a second message to solicit an
>> RREP_Ack, in order to verify that the link is bidirectional before marki=
ng
>> the route to OrigAddr as valid.
>>
>> Kind regards,
>>
>> Victoria.
>>
>>
>>
>>
>>
>> regards
>>
>>
>>
>> Jiazi
>>
>>
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>> Intelligence Laboratories *
>> *_______________________________________________________________________=
___
>> *
>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
>> *Sent:* 23 April 2016 10:55
>> *To:* Christopher Dearlove
>> *Cc:* ietf@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc
>> Networks mailing list
>>
>>
>> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>>
>>
>>
>> **** 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
>> .*
>>
>> Hi Chris,
>>
>>
>>
>> These have both been in the draft in some form since before I got
>> involved... but I'll do my best to explain.
>>
>>
>>
>> - For Validity Time, its a way to advertise that you would only support
>> the route contained in the message for a certain period of time. The
>> originator might use this, but the draft was written to allow any
>> intermediate node to be able to add it or update it too. The route creat=
ed
>> in the Local Route Set has an expiration time associated with it, based =
on
>> the received validity time.
>>
>> - For the AckReq address, its so that you can add into a RREP a request
>> for an acknowledgement, so that you don't have to have a different messa=
ge
>> type altogether for working out whether links to neighbors are
>> bidirectional, and also, since you only care about bidirectionality on
>> routes that are being set up, you dont need to constantly monitor all
>> neighbors.
>>
>>
>>
>>
>>
>> In order to avoid the potential AckReq-related changes to each message,
>> maybe we do need to introduce a different message specifically for this.=
 We
>> could maybe use RREP_Ack to both request and acknowledge? It means an ex=
tra
>> message of control traffic that needs to be sent, maybe one extra messag=
e
>> per hop on the path of a RREP, but it could still be limited to neighbor=
s
>> which have participated in the route discovery rather than monitoring al=
l
>> neighbors at all times.
>>
>>
>>
>> This message could maybe also include "I'm happy to route anywhere for a
>> certain amount of time", sort of like willingness in OLSR/OLSRv2. So
>> instead of having a validity time per route, its a validity time per
>> neighbor. Then, for RREQ and RREP, only the metric value would change in
>> transit, as discussed. However, that leads to some issues with deciding
>> what a route's expiration time is. You might know how long the next hop
>> router is valid for, but what if a router beyond that, which was also pa=
rt
>> of the route, had a lower validity time? You couldn't determine the real
>> validity time. Do we remove the route expiration time altogether to avoi=
d
>> this issue? In which case, we would have to rely on RERR messages being
>> sent for routes which become invalid when the neighbor's validity time h=
as
>> expired? So neighbor validity time expiration is treated the same as a l=
ink
>> break.
>>
>>
>>
>> What do you think?
>>
>>
>>
>> Kind regards,
>>
>> Victoria.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
>> chris@mnemosyne.demon.co.uk> wrote:
>>
>> Pretty much all of the discussion has been assuming only a metric value
>> change. With multiple things changing many of the ideas go out of the
>> window. That reinforces the point about not making specifications now th=
at
>> might turn out to be wrong for ICVs.
>>
>>
>>
>> Ignoring how this misunderstanding happened, I'll start by asking why.
>> Metric changing I understand. Why the other two? (there's a partial
>> explanation of one). What alternatives have people implemented in
>> comparable protocols?
>>
>> --
>>
>> Christopher Dearlove
>>
>> christopher.dearlove@gmail.com (iPhone)
>>
>> chris@mnemosyne.demon.co.uk (home)
>>
>>
>> On 23 Apr 2016, at 00:26, Victoria Mercieca  wrote=
:
>>
>> Hi all,
>>
>>
>>
>> Continued in this thread because the other one seems to be more about TL=
V
>> types and metric type numbers, whereas this is about
>> regeneration/forwarding.
>>
>>
>>
>> To recap, in the current draft, there are 3 things that might change at
>> each hop:
>> - the metric value (happens in RREQ and RREP),
>> - adding/changing Validity Time using the Validity Time TLV (can happen
>> in RREQ and RREP),
>> - adding an address (and corresponding value in the AddressType TLV to
>> indicate how to interpret the address) to indicate the address from whic=
h
>> an RREP_Ack is expected, to accomplish the bidirectionality check (can
>> happen in RREP).
>>
>> If we define a certain portion of the message as immutable and include
>> the ICV to verify that part, end to end:
>> - The metric value would be excluded from the ICV since it needs changin=
g
>> at each hop.
>> - Would adding a Validity Time TLV at an intermediate hop be acceptable?
>> The whole TLV could be removed in order to calculate the ICV?
>>
>> - Would adding an address cause issues for the ICV, because it's in the
>> address block? Could the rule be "if it contains an AckReq address, remo=
ve
>> it (and the corresponding value in the AddressType TLV), before checking
>> the ICV", is that OK? Or would we need to avoid touching the ICV'ed part=
 of
>> the message altogether, maybe put the AckReq address in a separate Addre=
ss
>> Block, with an extra AddressType TLV following that address block? Is th=
ere
>> a way to accomplish this?
>>
>>
>>
>> Also, to be thorough, do we need to consider RERR messages while we
>> discuss regeneration vs forwarding?
>>
>> - RERR (sent when a link breaks) is a way of saying "I've lost my route
>> so I'm telling others" and "you were my next hop, so now I've also lost =
my
>> route, I'll tell others", etc. It's going to be tailored at each step to
>> include the relevant routes that got deleted, it's not one message being
>> sent end-to-end like RREQ and RREP are.
>>
>> - However, RERR (sent when a source of traffic is sending data on a rout=
e
>> which comes through you, and you want to tell the Packet Source's router=
 to
>> delete the route) could be seen as an end-to-end message which all
>> intermediate routers learn from, similar to RREQ and RREP. It reports on=
e
>> route, and doesn't need changing at intermediate hops, so could be
>> protected with ICV.
>>
>> - Would it be OK to only require a message ICV if a PktSource address wa=
s
>> included, i.e. when the message needs to go via a number of intermediate
>> hops to PktSource's router? All other RERRs are intended to be one-hop
>> messages, which may in turn prompt other one-hop messages, etc..., and a
>> packet ICV might be more appropriate?
>>
>>
>>
>> Kind regards,
>>
>> Victoria.
>>
>>
>>
>> On Thu, Mar 17, 2016 at 5:26 PM,  wrote:
>>
>>
>>
>> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>>
>>
>> Yes, I meant AODVv2, thanks for the catch.
>>
>>
>>
>> So is your (Thomas) proposed base specification a hop count only metric?
>>
>>
>>
>> No, the would be silly as base specification, given that hop count mostl=
y
>> is useless.
>>
>>
>>
>> As base specification I would simply say =E2=80=9CInclude a Metric Type =
Message
>> TLV with a value field, and a 7182 Message TLV & Timestamp=E2=80=9D as w=
e do in
>> OLSRv2 (with the appropriate verbiage as to generation and processing).
>>
>>
>>
>> With the message generated by the originator of the RREQ/RREP and *not*
>> deconstructed/reconstructed/reordered (as is the risk with =E2=80=9Crege=
neration)
>> allows knowing that it would be *only* that metric field being modified
>> (other than hop count/limit) for when eventually writing up the extensio=
n.
>>
>>
>>
>> (Actually doesn=E2=80=99t the current specification only define hop coun=
t, or has
>> that changed in latest draft?)
>>
>>
>>
>> No. That is one of the issues I raise in my original. For some reason, i=
t
>> cites RFC6551, which is a ROLL document and which has in its abstract th=
at:
>>
>>
>>
>>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>>
>>    compared with traditional wired and ad hoc networks that require the
>>
>>    specification of new routing metrics and constraints.
>>
>>
>>
>> I.e. this document cites a metric document which clearly claims to be
>> inapplicable in ad hoc networks. I note that this is another thing I=E2=
=80=99ve
>> raised for years without seeing it attempted resolved.
>>
>>
>>
>> Best,
>>
>>
>>
>> Thomas
>>
>>
>>
>>
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>> Intelligence Laboratories *
>> *_______________________________________________________________________=
___
>> *
>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>> ]
>> *Sent:* 17 March 2016 17:10
>> *To:* Dearlove, Christopher (UK)
>> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>>
>>
>>
>> **** 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 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>>
>>
>> OK, so we have a message that mutates by:
>>
>> - Modifying hop count/limit.
>>
>> - Modifying a metric value.
>>
>> Anything else?
>>
>>
>>
>> As mutating (other than hop count/limit) messages aren=E2=80=99t covered=
 by 5444
>> or any derivative document (but only recommended against, not banned) th=
at
>> you may need to make the message otherwise immutable (no deconstruction =
and
>> rebuilding, other than guaranteed unchanging) that would have to be
>> specified by AODVv2. (Easy to say, but needs saying.)
>>
>>
>>
>> With you so far.
>>
>>
>>
>> Then that information is not in a guaranteed fixed location given by a
>> simple offset. So any signature algorithm that finds it and ignores it o=
r
>> aggregates on it is specific to OLSRv2.
>>
>>
>>
>> Surely you mean AODVv2
>>
>>
>>
>> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AODVv2
>> specialised variant. Which is the sort of thing that the message specifi=
c
>> TLV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cbut i=
gnore the value of
>> this specific TLV should it occur=E2=80=9D being in the general space. H=
owever it
>> can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like th=
at TLV,
>> except if an X TLV is present, set its value field to zero=E2=80=9D).
>>
>>
>>
>> Messy, but could work.
>>
>>
>>
>> Not that messy, actually, although clearly not as nice as =E2=80=9Cfixed=
 offset=E2=80=9D.
>>
>>
>>
>> That said, I am arguing for the base spec being:
>>
>>
>>
>>             =E2=80=9Cmake the message otherwise immutable (no deconstruc=
tion and
>> rebuilding, other
>>
>>              than guaranteed unchanging)=E2=80=9D which is afforded by f=
orwarding
>>
>>
>>
>>                                     +
>>
>>
>>
>>             RFC7182 Timestamps and ICVs.
>>
>>
>>
>>                                     +
>>
>>
>>
>>             RFC7183 style text bringing it all together.
>>
>>
>>
>> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would v=
ery be an
>> experimental extension.
>>
>>
>>
>> What I object to is, if the base spec specifically renders such
>> extensions impossible
>>
>>
>>
>>
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>> Intelligence Laboratories *
>> *_______________________________________________________________________=
___
>> *
>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
>> ]
>> *Sent:* 17 March 2016 16:48
>> *To:* Dearlove, Christopher (UK)
>> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
>> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>>
>>
>>
>> **** 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
>> .*
>>
>> Hi all,
>>
>>
>>
>> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com>:
>>
>>
>>
>> Good point about whether you just pass on one cost or a set of costs. As
>> I said, not looked at details - I will, when time permits. One cost is m=
uch
>> easier, and yes, it reduces the fixed size aggregated signatures problem=
 to
>> =E2=80=9Cjust=E2=80=9D one of computational load.
>>
>>
>>
>> For the record, Thomas=E2=80=99 understanding is correct; the cost is on=
e
>> aggregated value.
>>
>>
>>
>> Best regards,
>>
>> Lotte Steenrbink
>>
>>
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>> Intelligence Laboratories *
>> *_______________________________________________________________________=
___
>> *
>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>> ]
>> *Sent:* 17 March 2016 16:38
>> *To:* Dearlove, Christopher (UK)
>> *Cc:* Mobile Ad Hoc Networks mailing list
>> *Subject:* Re: Message integrity and message mutability (was RE: [manet]
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>>
>>
>>
>> **** 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 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>>
>>
>> I appreciate Thomas=E2=80=99s comments about the limitations of message
>> regeneration, but I would be a bit less absolute.
>>
>>
>>
>> The issues over end to end authentication and more advanced signatures
>> are valid. I need to read the given reference on aggregate signatures to
>> increase my knowledge (thanks for it), but my understanding of the
>> possibilities in this field may offer a solution to the problem, but wit=
h
>> some other issues (possibly including a new type of TLV).
>>
>>
>>
>> But the hop count/limit point I don=E2=80=99t fully agree with, you can
>> regenerate with an incremented/decremented count/limit, which leaves the
>> ability to prevent messages propagating indefinitely, including expandin=
g
>> ring searches, and retains the ability to use RFC 5497 interval and
>> validity times that might be useful with an expanding ring search (or mi=
ght
>> not).
>>
>>
>>
>> But the key issue is that AODVv2 wants to accumulate metrics. I still
>> haven=E2=80=99t got to the bottom of many details here, but let=E2=80=99=
s for the moment
>> just consider that conceptually.
>>
>>
>>
>> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft attempts=
 to do an end to
>> end of some information, not this information. I=E2=80=99m not sure if t=
hat=E2=80=99s
>> useful (and the specialised format is better avoided if possible). Other
>> approaches are hop by hop (might as well use packet signatures) and shar=
ed
>> key (might as well go hop by hop). Pairwise signatures for each pair of
>> routers I=E2=80=99m discounting as scaling terribly. In the interests of
>> completeness let=E2=80=99s mention not accumulating metrics, which puts =
us back to
>> hop count and that=E2=80=99s not ideal either.
>>
>>
>>
>> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=80=
=99ve seen about
>> aggregating, but that has some issues of its own, even apart from
>> computational load.) I=E2=80=99d love to be proved wrong - someone with =
the perfect
>> solution to come along.
>>
>>
>>
>> Which means that either we make an arbitrary choice - which will be
>> disagreed with, but needs discussing first - or create something flexibl=
e.
>> Unfortunately flexible in that regard constrains in others, e.g. some
>> (many? most?) aggregating signatures need fixed data sizes (which we can=
 do
>> by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but th=
at has a cost too).
>>
>>
>>
>> I have been told by people much more well versed in this than I in
>> cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>>
>>
>>
>> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does t=
hat mean that the
>> message grows as it is being forwarded, and that the recipient of a
>> RREQ/RREP will know the individual costs of each path segment? My
>> understanding is, that the recipient will get =E2=80=9Cthe sum the costs=
 of each
>> path segment=E2=80=9D which should be fitting within a fixed size?
>>
>>
>>
>> Thomas
>>
>>
>>
>>
>>
>>
>>
>> Sorry, no answers, just comments. And I=E2=80=99m not addressing Thomas=
=E2=80=99s later
>> points here.
>>
>>
>>
>> *--*
>>
>>
>>
>>
>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>> Intelligence Laboratories *
>> *_______________________________________________________________________=
___
>> *
>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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 *ietf@thomasclausen.org
>> *Sent:* 17 March 2016 16:00
>> *To:* Mobile Ad Hoc Networks mailing list
>> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of big
>> ticket Items
>>
>>
>>
>>
>>
>> **** 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.
>>
>>
>>
>> Dear all,
>>
>>
>>
>> Apologies for not having gotten this done sooner - day-job leaving few
>> spare cycles.
>>
>>
>>
>> I=E2=80=99ve previously offered reviews and comments, and some of those =
have been
>> addressed in the latest I-D =E2=80=94 others have not, but should be. I =
recall that
>> there was some mail attempting to rebut parts of the review, and I will =
dig
>> it out and reply to that.
>>
>>
>>
>> With that being said, I have reviewed the latest version of the document=
,
>> and full details will be forthcoming. There=E2=80=99re a couple of
>> big-ticket/architectural items that I want to address up front, as I
>> believe that before we have those hammered out, it will be useless to go
>> into details. Note, I do not claim that this is an exhaustive list of =
=E2=80=9Cbig
>> ticket items=E2=80=9D, but that=E2=80=99s as far as I have gotten in thi=
nking this through.
>>
>>
>>
>> I also bring these up as they are items that have been brought up
>> repeatedly over the past years, but not resolved nor discussed.
>>
>>
>>
>> *Loops*
>>
>> Just to bring this out: I share Chris=E2=80=99 worry about conflicting a=
nd
>> concurrent statements from the authors on =E2=80=9CThere are no loops po=
ssible=E2=80=9D and
>> =E2=80=9CWe need to fix two situations where loops can occur=E2=80=9D an=
d =E2=80=9Cwe are still
>> investigating some loop conditions=E2=80=9D
>>
>>
>>
>> I particularly worry that this is not a discussion had in public, but
>> apparently in some other forum=E2=80=A6
>>
>>
>>
>>
>>
>> *Intermediate Route Replies, and all of section 10*
>>
>> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=80=
=9D, which is
>> incoherent with the intended status indicated for this document.
>>
>>
>>
>> Specifically, and this is not unrelated to the point about loops above,
>> intermediate RREPs (section 10.3) are a potential source for loops.
>>
>>
>>
>> Expanding Ring Multicast (section 10.1) is not documented in a way that
>> can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=E2=
=80=9D below, it is
>> in the present form of this protocol impossible), etc.
>>
>>
>>
>>
>>
>> *Forwarding-vs-regeneration*
>>
>> Recent exchanges on the list made me understand that protocol control
>> messages are *not* forwarded, but are consumed at each hop, then a new
>> message with (almost-but-not-quite) the same content is generated and
>> transmitted.
>>
>>
>>
>> I have thought some more on this (& read some of the exchanges on the
>> list on this topic by Chris, Ulrich, and others), and I am convinced tha=
t
>> this is not the right way to go, *at least* for the following reasons:
>>
>>
>>
>>
>>
>>             o          *It renders the hop-limit/hop-count fields in the
>> RFC5444 message header useless.*
>>
>>                         This would not be bad if the functionality
>> offered by those fields was not useful
>>
>>                         =E2=80=94 sadly, it is. For example, for scope l=
imited
>> flooding (expanding ring search, and
>>
>>                         such) which may be of interest, and which requir=
e
>> hop-limit.
>>
>>                         A hop-count field may also provide a =E2=80=9Cch=
eap=E2=80=9D (in
>> terms of overhead) additional piece
>>
>>                         of information to use conjunctively with a =E2=
=80=9Creal=E2=80=9D
>> metric.
>>
>>
>>
>>                         The only practical solution would be to
>> re-introduce these functions by way of inserting a
>>
>>                         MessageTLV =E2=80=94 which (i) is not specified =
in this
>> document, and (ii) which would just
>>
>>                         serve to render messages bigger than strictly
>> needed.
>>
>>
>>
>>                         Scope limited flooding  does seem to be a
>> necessary requirement, if for no
>>
>>                         other reason than to prevent information from
>> =E2=80=9Ccirculating forever in the network=E2=80=9D.
>>
>>
>>
>>             o          *It makes end-to-end authentication unnecessarily
>> hard.*
>>
>>                         I think Chris called this out already, but it
>> bears repeating: S generates a message
>>
>>                         (say, a RREQ), and includes an ICV calculated
>> over the content of the message.
>>
>>                         For any recipient to be able to validate the ICV=
,
>> the message has to be exactly
>>
>>                         the same =E2=80=94 not just in content, but in s=
tructure
>> =E2=80=94 as what was generated.
>>
>>
>>
>>                         =E2=80=9CRegenerating=E2=80=9D rather than =E2=
=80=9Cforwarding=E2=80=9D messages
>> means, that the intermediate
>>
>>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ m=
ay chose a
>> different structure (e.g., include TLVs
>>
>>                         in a different order).
>>
>>
>>
>>                         The proposal from
>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>>
>>                         is to add constraints on (i) the set of elements
>> to include in a signature and (ii) the
>>
>>                         order of these elements.
>>
>>
>>
>>                         One problem with that approach is (i): if an
>> extension adds a message TLV, or an
>>
>>                         Address TLV, to a message, then that will not be
>> =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>>
>>                         Rather for *each* extension developed, an
>> =E2=80=9Cupdates e2esec=E2=80=9D clause needs to be done.
>>
>>
>>
>>                         I=E2=80=99d say that this approach would be pron=
e to
>> errors =E2=80=94 and add entropy to the process
>>
>>                         of designing protocol extensions. The
>> alternative, a message being generated by the
>>
>>                         source and *forwarded* (as we do in OLSRv2, for
>> example) would allow ICV TLVs
>>
>>                         (even, allow reuse of those specified for OLSRv2=
)
>> for covering a message and
>>
>>                         extensions.
>>
>>
>>
>>                         =E2=80=9CBut what about the metrics value which =
will
>> change on each hop=E2=80=9D, you may say?
>>
>>                         Fortunately, that is relatively easy to handle:
>> simply zero out the value of that TLV when
>>
>>                         generating or verifying the ICV MessageTLV. And
>> use Packet-TLVs for hop-by-hop
>>
>>                         authentication, if needed (but, see below).
>>
>>
>>
>>             o          *It prevents the use of more clever/advanced
>> signature schemes/ICVs*
>>
>>                         Aggregate signature algorithms (
>> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>>
>>                         exist, and an interesting use-case can be found
>> in also reactive protocols, allowing verifying
>>
>>                         not =E2=80=9Cjust=E2=80=9D the end points, but a=
lso the
>> intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D
>>
>>                         discussed above, or something smarter).
>>
>>                         Regeneration of messages, rather than forwarding=
,
>> renders that impossible (or, if used,
>>
>>                         updating to
>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>>
>>
>>
>> There are other reasons, but the above are those that jump at me as
>> immediate show-stoppers.
>>
>>
>>
>> I do honestly not see what possible benefit there is from =E2=80=9Cregen=
eration=E2=80=9D
>> =E2=80=94 but I see very clear inconveniences, and security is not the l=
east of
>> these. Insisting on =E2=80=9Cregeneration=E2=80=9D requires development =
of =E2=80=9Cnon-general
>> workarounds=E2=80=9D as pointed out above.
>>
>>
>>
>> *Security Considerations*
>>
>> This is an always thorny subject. When OLSRv2 was going through the
>> process we got a thorough education in how little we knew about security
>> from the SEC-ADs, and had to spend about a year or so developing RFC7183=
.
>> The bottom line is, that this protocol needs its =E2=80=9CRFC7183  equiv=
alent=E2=80=9D,
>> either as part of the main document, or as an independent document.
>> currently, that is not the case.
>>
>>
>>
>> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration from =
RFC7183
>> might be aw good idea, as that was the most recent that went through the
>> SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to implement=E2=
=80=9D security
>> mechanism most be specified (I think the right term was =E2=80=9CMUST im=
plement,
>> SHOULD use=E2=80=9D), in sufficient detail to ensure interoperable imple=
mentations.
>>
>>
>>
>> As an example, both [RFC6130] and [RFC7181] set out that that:
>>
>>
>>
>>       On receiving a ... message, a router MUST first check if the
>>
>>       message is invalid for processing by this router
>>
>>
>>
>> and then proceed to give a number of conditions that, each, will lead to
>> a rejection of the message as "badly formed and therefore invalid for
>> processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That ga=
ve a =E2=80=9Chook=E2=80=9D for
>> RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message gene=
ration.
>>
>>
>>
>> If I was to do RFC7181/RFC6130 today, I would include that directly into
>> the protocol specifications. It turned out to be more overhead (and slow
>> down publication anyways) to do it as separate documents.
>>
>>
>>
>> Secondly, we need to be a lot more rigid in terms of what ICVs,
>> Timestamps, etc. are added/removed, and what that brings.
>>
>>
>>
>> For example (with the assumption that messages are *forwarded* and *not*
>> regenerated), this could be one option:
>>
>>
>>
>>                         o          When a RREQ, RREP message is
>> generated, add an ICV Message TLV, which is calculated 
>>
>>                                      =E2=80=A6(take inspiration from RFC=
7183 here)
>>
>>
>>
>> ...
>>
>> [Message clipped]
>> _______________________________________________
>> 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
>>
>>
>>
>> ********************************************************************
>> 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
>
>

--001a1145ad26b08c6e053150d8b5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,=C2=A0

Maybe I missed a bit here:=C2=
=A0

If only the desired receiver of the multicast =
RREP (carrying a destination address) can reply to the multicast RREP, why =
not using unicast directly?

best

Jiazi

=
On Mon, Apr 25, 2016 at 4:59 PM, Victoria Mercieca <vmercieca0@gmail.co=
m> wrote:
=
Hi Chris,


=
On Mon, Apr 25, 2016 at 3:51 PM, Dearlove, Christopher (UK) <c=
hris.dearlove@baesystems.com> wrote:











I has to go back to Victo=
ria=E2=80=99s summary here. It says:


=C2=A0


2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).


=C2=A0


That doesn=E2=80=99t actu=
ally indicate if that=E2=80=99s C=E2=80=99s address or B=E2=80=99s address =
being included. I=E2=80=99d assumed it was C=E2=80=99s address. Your commen=
t makes sense if it=E2=80=99s B=E2=80=99s address.
 Reading again, I think you=E2=80=99re probably right. But only probably. C=
an we confirm that.


=C2=A0
<=
/div>

C creates the RREP. The include=
d AckReq address is B's address. The RREP then gets multicast.
B receives it, sees that it own address is marked as the AckReq addre=
ss, and sends an ack unicast back to C. 
Anyone else who receives the mu=
lticast RREP from C does not send the Ack, since the AckReq address does no=
t match any of their interface addresses.
=C2=A0


I assume you meant that t=
he RREP (not RREP_Ack) is multicast. There=E2=80=99s a bit of a chicken and=
 egg problem here. We do know how we want to unicast.
=C2=A0
The RREP is multicast (when we dont kno=
w if the link is bidirectional), the RREP_Ack is always unicast. 

Kind regards,
Vicky.

=

=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: 25 April 2016 15:26

To: Thomas Heide Clausen

Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc =
Networks mailing list; Victoria Mercieca

Subject: Re: [manet] Message integrity and message mutability (was R=
E: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)=



=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>








The address in the RREP_Ack may be required due to t=
he RREP_Ack being multicast as there is not yet a verified unicast route in=
stalled yet.=C2=A0 Going to double check if I'm remembering correctly.=
=C2=A0



Justin






=C2=A0




On Mon, Apr 25, 2016 at 10:18 AM, <ietf@thomasclausen.org>=
; wrote:




Hi,




=C2=A0






I must admit that while I have reviewed the protocol=
 several times, I=E2=80=99ve not been digging that deep into the protocol f=
unctioning to catch this issue of how invasive the protocol operations are =
when forwarding a message: there were other
 =E2=80=9Cmajor=E2=80=9D issues to address (and which obscured the details)=
, so as a first order: thank you Victoria, for having called attention to t=
his.






=C2=A0






To the substance of these emails.






=C2=A0






I am afraid that I do not understand the use of inse=
rting validity TLVs while in-flight, into a message. Actually, I am dubious=
 for both the originator inserting this (how can the originator of a messag=
e know how =E2=80=9Clatter parts of the path=E2=80=9D
 will be have=E2=80=9D) except if we are talking duty-cycling of devices an=
d inserting =E2=80=9Cthe remaining time that I am going to be up before I s=
uspend=E2=80=9D. Intuitively, that would also assume fairly long duty cycle=
s =E2=80=9CI am up for tens of seconds=E2=80=9D, which I am not sure are
 actually realistic. And, as Chris says in another email, this is trading o=
ff =E2=80=9Cthe ability to do security=E2=80=9D for an unknown/untested fea=
ture =E2=80=94 which I think is the wrong trade-off.






=C2=A0






On he topic of =E2=80=9Cneeding to put an address in=
=E2=80=9D for RREP-ACK, I must admit that this seems roundabout. I can see =
three issues here:






=C2=A0






o I am not sure that adding an address vs. a flag ma=
y not have to do with the =E2=80=9Cmultiple interfaces/






multiple addresses=E2=80=9D discrimination mechanics=
 of the protocol? I haven=E2=80=99t worked it through, though,=C2=A0=







but that would be a guess.






=C2=A0






o The end-to-end topology diffusion mechanism should=
 not need to be concerned with the=C2=A0






=E2=80=9Cbidirectionally check=E2=80=9D of a local l=
ink (in part, as it encumbers security, but not only).=C2=A0 In short, a=







flag or an address, both are (equally) bad.






=C2=A0






o A cleaner mechanism would be a =E2=80=9Chello mech=
anism=E2=80=9D, not necessarily as NHDP, but a =E2=80=9Cwhen=C2=A0






forwarding a RREQ/RREP, trigger a 3-way hello exchan=
ge, if the link is estimated to be of a=C2=A0






type which potentially can be=C2=A0unidirectional=E2=
=80=9D. There is another benefit to doing that, see the end=C2=A0=







of this email.






=C2=A0






Either way, I do not like the notion of fusing metri=
cs-and-link-bidirectionality-detection any more than I like fusing global-t=
opology-diffusion-and-link-bidirectionality-detection.=C2=A0<=
/p>





=C2=A0






The solution all this is, to me, threefold=







=C2=A0






1) Factor out the bidirectionally check in a (trigge=
red) neighbour detection mechanism=C2=A0






(triggered HELLO message)






=C2=A0






2) Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, =
since they add complexity for no perceivable benefits






=C2=A0






3) Use the security model that we=E2=80=99ve discuss=
ed previously, where (only) the metrics change per hop.






=C2=A0






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 related issue, as I hinted previously.





=C2=A0








The abstract states that the protocol:






=C2=A0






=C2=A0=C2=A0 ...is intended for use by mobile routers in wireless, mul=
tihop


=C2=A0=C2=A0 networks.




=C2=A0






Section 5 paragraph 4 =C2=A0of the document, however, re=
ads:






=C2=A0






=C2=A0=C2=A0 Assuming link metrics are symmetric, the cost of the rout=
es installed


=C2=A0=C2=A0 in the Local Route Set at each router will be correct.=C2=
=A0 While this


=C2=A0=C2=A0 assumption is not always correct, calculating incoming/ou=
tgoing


=C2=A0=C2=A0 metric data is outside of scope of this document. =





=C2=A0








I do not know of any wireless systems,=
 where the assumption that =E2=80=9Clink metrics are symmetric=E2=80=9D act=
ually holds. Consequently, the conclusion in the quoted paragraph:






=C2=A0


=C2=A0=C2=A0 calculating incoming/outgoing


=C2=A0=C2=A0 metric data is outside of scope of this document.<=
u>




=C2=A0








Is not an acceptable design choice.





=C2=A0






While this protocol may not want to =E2=80=9Ccalcula=
te if for this link the metrics is 4 or 5=E2=80=9D, the protocol must be ab=
le to convey and distinguish that =E2=80=9Cthe metric from A to B is 4, and=
 the metric from B to A is 19=E2=80=9D.






=C2=A0






This is a =E2=80=9Crelated issue=E2=80=9D since the =
solution may (as with the bi-directionality check) be in the triggered neig=
hbour detection mechanism: that exchange could, if designed carefully, be u=
sed to probe for and convey metrics information, also.






=C2=A0






Hope this helps,






=C2=A0






=C2=A0






Thomas






=C2=A0












On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK)=
 <chr=
is.dearlove@baesystems.com> wrote:




=C2=A0








Assuming for the moment t=
hat everyone will need an RREP-Ack or won=E2=80=99t (let=E2=80=99s come bac=
k to that) why do C and B need to put an address in as an RREQ-Ack request?
 Why not a flag, because the address will be included as the IP sending add=
ress - and we know 5444 is required to pass that on. (It=E2=80=99s used by =
NHDP as well.) Then we don=E2=80=99t need to change the RREP, it will have =
a flag set or not, and won=E2=80=99t change (in this regard).=







=C2=A0






Now let=E2=80=99s conside=
r do we know whether we can set a fixed flag. First I=E2=80=99d say there a=
re two cases - you=E2=80=99ve got a firm control on what=E2=80=99s going on=
 in your network,
 or it=E2=80=99s one of unknown parties and behaviour (consistent with spec=
ification). In the former case you only want one setting, for example no-Ac=
k if running NHDP or your MAC layer tells you about bidirectionality, Ack o=
therwise. In the latter case, I think you
 just always want an Ack. So both cases get you to the same place.






=C2=A0






Should that not be an acc=
eptable argument (though I think it=E2=80=99s good for where we are - in fa=
ct always Ack is close) then at flag is a step better, it=E2=80=99s a fixed
 location to change. However it would be better in that case if the two thi=
ngs to change (metric and ack flag) were together. But that has its own iss=
ues, so I won=E2=80=99t go there.






=C2=A0




--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44 (0)12=
45 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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:=C2=A0Victoria Mercieca [mailto:vmercieca0=
@gmail.com]=C2=A0

Sent:=C2=A025 April 2016 14:15

To:=C2=A0Jiazi YI

Cc:=C2=A0Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad=
 Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)






=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=C2=A0=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.








Hi Jiazi,










=C2=A0








On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <ietf@jiaziyi.com> wrote:








Hi,=C2=A0








=C2=A0








On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christop=
her (UK) <chris.dearlove@baesystems.com&=
gt; wrote:










With regard to your valid=
ity time point, we here have a tradeoff. If you allow that feature, it sign=
ificantly impacts on the approach that was coming together
 on as best you can end to end encryption.






=C2=A0






So the question is, is th=
is a feature that=E2=80=99s really wanted? Unfortunately I think we know th=
at the answer to that is, we don=E2=80=99t know because we don=E2=80=99t ha=
ve any
 experience. My view would be that in the tradeoff of an untested feature (=
unless I=E2=80=99m wrong about that) and the security complication, securit=
y wins and drop the feature. If there is some real requirement, then there=
=E2=80=99s a discussion. (Questions like how often
 the intermediate routers actually have any knowledge - typically links bre=
ak for unexpected rather than expected reasons. Andan intermediate router c=
ould possibly use a validity time to influence its behaviour.) Note that dr=
opping the ability of intermediate
 routers to modify/set still allows validity times per route to be set at e=
ndpoints.












=C2=A0










I agree with Chris' concern.










The ValidityTime is optional, which makes the integr=
ity protection hard. Furthermore, it gives a potential attack vector: as al=
l the routers in a path will take the shortest validityTime, a compromised =
router can set the the validityTime
 to a very short value, which will make the route installed along the path =
became invalid (very soon).=C2=A0










=C2=A0










On the other hand, I'm not sure this option will=
 give us much help. Chris mentioned much knowledge intermediate router woul=
d have to decide this value (and how much sense the value would make).=C2=
=A0










Another issue is, a route to a destination might be =
updated by different sources. For example, in the network below:<=
/u>










=C2=A0










=
A----B-----C










=C2=A0










A first establish a route to B with long validity ti=
me. Then A initiates a route discovery to C. C tends to set a short validit=
y time, which will make the route between B and A expire earlier than expec=
ted.=C2=A0










Is this a problem? Maybe yes, maybe no -- I'm no=
t sure it's considered or not.=C2=A0










=C2=A0
















=C2=A0








Not sure I follow her=
e.






Currently, the validi=
ty time of the route between A and B would not affected by a short validity=
 time of a route between A and C. Validity times are per-route, and the rou=
te A-B and the route A-C are separate.








If we switched to a validity time per neighbor (so t=
hat we can keep validity time separate from route advertisements) as I ment=
ioned in the email below, then the validity of a route between A and C woul=
d be affected if there was a short
 validity time between A and B. But, if B will only route for a certain amo=
unt of time, then the route between A and C will of course be affected. Is =
it best to know in advance that there's a time limit, or just deal with=
 RERRs when they happen?








=C2=A0<=
/p>







=C2=A0






















=C2=A0






With regard to the acknow=
ledgements, the problem (with regard to security) comes from trying to do t=
wo jobs with the same message - end to end route advertisement
 and hop by hop acknowledgement. I understand the reasons - saving bytes an=
d message types. (I would have to study the protocol really hard to identif=
y if any message types can be folded together and recognised by content rat=
her than type efficiently. This
 I do not expect to do.) Again a tradeoff. This one is in discussion space,=
 though that needs people who understand both sides of the issue, including=
 the details of the bidirectionality mechanism. Of course, as has been said=
, we need one of those.














=C2=A0










I haven't finished my review of the latest draft=
, and I don't get the necessity of AckReq and the corresponding multica=
st RREP yet.=C2=A0










If possible, this "optional" field should =
be avoided.=C2=A0










=C2=A0


















To give an overview of AckReq and RREP:






Since AODVv2 requires=
 bidirectional links, this is the way to determine if a link is bidirection=
al.








A----B----C












1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install a=
 route to OrigAddr but they dont yet know if it's valid because they do=
nt know if the link to their next hop is available in the reverse direction=
.










2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).










3) B receives the RREP, installs a route to TargAddr=
 and marks it as valid, since it knows the link to C is bidirectional, beca=
use the RREQ went in one direction and the RREP came in the other. B also s=
ends the RREP_Ack to C and forwards
 the RREP to A (and might change the message to indicate its own AckReq - i=
e that it requires an ack from A).










4) C receives the RREP_Ack from B, and therefore kno=
ws that B received the RREP, therefore the link is bidirectional. C can the=
n mark its route to OrigAddr as valid.










5) Similarly, A receives the RREP, installs the rout=
e to TargAddr and sends an RREP_Ack to B.










6) B receives the RREP_Ack and marks its route to Or=
igAddr as valid.










=C2=A0








Alternatively, in ste=
p 2, if C knows the link to B is bidirectional (perhaps from some earlier r=
oute discovery), it doesnt need to put the AckReq in the RREP. Then in step=
 3, since B doesnt know if the link
 to A is bidirectional, it changes the message to add the AckReq address, i=
n order to get an RREP_Ack from A.






If we want to avoid c=
hanging the message, we'll need to look at forwarding the RREP as-is, a=
nd creating a second message to solicit an RREP_Ack, in order to verify tha=
t the link is bidirectional before marking
 the route to OrigAddr as valid.=C2=A0








Kind regards,










Victoria.








=C2=A0<=
/p>







=C2=A0


















regards










=C2=A0










Jiazi










=C2=A0














=C2=A0




--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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:=C2=A0Victoria Mercieca [mailto:vmercieca0=
@gmail.com]=C2=A0

Sent:=C2=A023 April 2016 10:55

To:=C2=A0Christopher Dearlove

Cc:=C2=A0ietf@thomasclausen.org; Dearlove, =
Christopher (UK); Mobile Ad Hoc Networks mailing list<=
/p>











Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.










Hi Chris,








=C2=A0










These have both been in the draft in some form since=
 before I got involved... but I'll do my best to explain.=









=C2=A0










- For Validity Time, its a way to advertise that you=
 would only support the route contained in the message for a certain period=
 of time. The originator might use this, but the draft was written to allow=
 any intermediate node to be able
 to add it or update it too. The route created in the Local Route Set has a=
n expiration time associated with it, based on the received validity time.<=
u>










- For the AckReq address, its so that you can add in=
to a RREP a request for an acknowledgement, so that you don't have to h=
ave a different message type altogether for working out whether links to ne=
ighbors are bidirectional, and also, since
 you only care about bidirectionality on routes that are being set up, you =
dont need to constantly monitor all neighbors.










=C2=A0










=C2=A0










In order to avoid the potential AckReq-related chang=
es to each message, maybe we do need to introduce a different message speci=
fically for this. We could maybe use RREP_Ack to both request and acknowled=
ge? It means an extra message of control
 traffic that needs to be sent, maybe one extra message per hop on the path=
 of a RREP, but it could still be limited to neighbors which have participa=
ted in the route discovery rather than monitoring all neighbors at all time=
s.=C2=A0










=C2=A0










This message could maybe also include "I'm =
happy to route anywhere for a certain amount of time", sort of like wi=
llingness in OLSR/OLSRv2. So instead of having a validity time per route, i=
ts a validity time per neighbor. Then, for RREQ
 and RREP, only the metric value would change in transit, as discussed. How=
ever, that leads to some issues with deciding what a route's expiration=
 time is. You might know how long the next hop router is valid for, but wha=
t if a router beyond that, which was
 also part of the route, had a lower validity time? You couldn't determ=
ine the real validity time. Do we remove the route expiration time altogeth=
er to avoid this issue? In which case, we would have to rely on RERR messag=
es being sent for routes which become
 invalid when the neighbor's validity time has expired? So neighbor val=
idity time expiration is treated the same as a link break.









=C2=A0










What do you think?










=C2=A0










Kind regards,










Victoria.










=C2=A0










=C2=A0










=C2=A0










=C2=A0










=C2=A0












=C2=A0








On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlov=
e <chris@mnemosyne.demon.co.uk> wrote:<=
u>










Pretty much all of the discussion has been assuming =
only a metric value change. With multiple things changing many of the ideas=
 go out of the window. That reinforces the point about not making specifica=
tions now that might turn out to be
 wrong for ICVs.










=C2=A0










Ignoring how this misunderstanding happened, I'l=
l start by asking why. Metric changing I understand. Why the other two? (th=
ere's a partial explanation of one). What alternatives have people impl=
emented in comparable protocols?



-- =C2=A0








Christopher Dearlove














On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmai=
l.com> wrote:


















Hi all,










=C2=A0










Continued in this thread because the other one seems=
 to be more about TLV types and metric type numbers, whereas this is about =
regeneration/forwarding.










=C2=A0










To recap, in the current draft, there are 3 things t=
hat might change at each hop:=C2=A0

- the metric value (happens in RREQ and RREP),=C2=A0

- adding/changing Validity Time using the Validity Time TLV (can happen in =
RREQ and RREP),=C2=A0

- adding an address (and corresponding value in the AddressType TLV to indi=
cate how to interpret the address) to indicate the address from which an RR=
EP_Ack is expected, to accomplish the bidirectionality check (can happen in=
 RREP).



If we define=C2=A0a certain portion of the message as immutable and include=
 the ICV to verify that part, end to end:=C2=A0

- The metric value would be excluded from the ICV since it needs changing a=
t each hop.=C2=A0

- Would adding a Validity Time TLV at an intermediate hop be acceptable? Th=
e whole TLV could be removed in order to calculate the ICV?







- Would adding an address cause issues for the ICV, =
because it's in the address block? Could the rule be "if it contai=
ns an AckReq address, remove it (and the corresponding value in the Address=
Type TLV), before checking the ICV", is that
 OK? Or would we need to avoid touching the ICV'ed part of the message =
altogether, maybe put the AckReq address in a separate Address Block, with =
an extra AddressType TLV following that address block? Is there a way to ac=
complish this?










=C2=A0










Also, to be thorough, do we need to consider RERR me=
ssages while we discuss regeneration vs forwarding?=C2=A0










- RERR (sent when a link breaks) is a way of saying =
"I've lost my route so I'm telling others" and "you =
were my next hop, so=C2=A0now=C2=A0I've also lost my route, I'll te=
ll others", etc. It's going to be tailored at each step to include=
 the relevant
 routes that got deleted, it's not one message being sent end-to-end li=
ke RREQ and RREP are.=C2=A0










- However, RERR (sent when a source of traffic is se=
nding data on a route which comes through you, and you want to tell the Pac=
ket Source's router to delete the route) could be seen as an end-to-end=
 message which all intermediate routers
 learn from, similar to RREQ and RREP. It reports one route, and doesn'=
t need changing at intermediate hops, so could be protected with ICV.










- Would it be OK to only require a message ICV if a =
PktSource address was included, i.e. when the message needs to go via a num=
ber of intermediate hops to PktSource's router? All other RERRs are int=
ended to be one-hop messages, which may
 in turn prompt other one-hop messages, etc..., and a packet ICV might be m=
ore appropriate?










=C2=A0








Kind regards,








Victoria.










=C2=A0








On Thu, Mar 17, 2016 at 5:26 PM, <i=
etf@thomasclausen.org> wrote:








=C2=A0












On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:








=C2=A0












Yes, I meant AODVv2, than=
ks for the catch.










=C2=A0










So is your (Thomas) propo=
sed base specification a hop count only metric?
















=C2=A0








No, the would be silly as base specification, given =
that hop count mostly is useless.










=C2=A0










As base specification I would simply say =E2=80=9CIn=
clude a Metric Type Message TLV with a value field, and a 7182 Message TLV =
& Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage =
as to generation and processing).=C2=A0










=C2=A0










With the message generated by the originator of the =
RREQ/RREP and *not* deconstructed/reconstructed/reordered (as is the risk w=
ith =E2=80=9Cregeneration) allows knowing that it would be *only* that metr=
ic field being modified (other than hop count/limit)
 for when eventually writing up the extension.










=C2=A0
















(Actually doesn=E2=80=99t=
 the current specification only define hop count, or has that changed in la=
test draft?)














=C2=A0








No. That is one of the issues I raise in my original=
. For some reason, it cites RFC6551, which is a ROLL document and which has=
 in its abstract that:










=C2=A0








=C2=A0=C2=A0 Low-Power and Lossy Networks (LLNs) have unique character=
istics


=C2=A0=C2=A0 compared with traditional wired and ad hoc networks that =
require the


=C2=A0=C2=A0 specification of new routing metrics and constraints. =







=C2=A0










I.e. this document cites a metric document which cle=
arly claims to be inapplicable in ad hoc networks. I note that this is anot=
her thing I=E2=80=99ve raised for years without seeing it attempted resolve=
d.










=C2=A0










Best,










=C2=A0










Thomas










=C2=A0










=C2=A0














=C2=A0








--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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:=C2=A0ietf@thomasclausen.org=
=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 17:10

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Lotte Steenbrink; Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.










=C2=A0
















On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:












=C2=A0














OK, so we have a message =
that mutates by:














- Modifying hop count/lim=
it.














- Modifying a metric valu=
e.














Anything else?<=
/u>














=C2=A0














As mutating (other than h=
op count/limit) messages aren=E2=80=99t covered by 5444 or any derivative d=
ocument (but only recommended against, not banned) that you may
 need to make the message otherwise immutable (no deconstruction and rebuil=
ding, other than guaranteed unchanging) that would have to be specified by =
AODVv2. (Easy to say, but needs saying.)


















=C2=A0












With you so far.












=C2=A0<=
/p>









Then that information is =
not in a guaranteed fixed location given by a simple offset. So any signatu=
re algorithm that finds it and ignores it or aggregates
 on it is specific to OLSRv2.














=C2=A0












Surely you mean AODVv2












=C2=A0<=
/p>









So standard 7182 ICVs don=
=E2=80=99t do the job, you would need an AODVv2 specialised variant. Which =
is the sort of thing that the message specific TLV space is there
 for, I=E2=80=99d be strongly against a =E2=80=9Cbut ignore the value of th=
is specific TLV should it occur=E2=80=9D being in the general space. Howeve=
r it can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like =
that TLV, except if an X TLV is present, set its value field to
 zero=E2=80=9D).














=C2=A0














Messy, but could work.














=C2=A0












Not that messy, actually, although clearly not as ni=
ce as =E2=80=9Cfixed offset=E2=80=9D.














=C2=A0














That said, I am arguing for the base spec being:<=
/u>














=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=E2=80=9Cmake the message otherwise immutable (no deco=
nstruction and rebuilding, other=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=A0than guaranteed unchanging)=E2=80=9D which is af=
forded by forwarding














=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7182 Timestamps and ICVs.














=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7183 style text bringing it all together.=















=C2=A0














The =E2=80=9Caggregated signatures around mutable fi=
eld=E2=80=9D would very be an experimental extension.














=C2=A0














What I object to is, if the base spec specifically r=
enders such extensions impossible














=C2=A0












=C2=A0<=
/p>









=C2=A0










--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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:=C2=A0Lotte Steenbrink [mailto:lo=
tte.steenbrink@fu-berlin.de]=C2=A0

Sent:=C2=A017 March 2016 16:48

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0ietf@thomasclausen.org; Mobile Ad =
Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)


















=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.












Hi all,
















=C2=A0




















Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher=
 (UK) <chris.dearlove@baesystems.com>=
:
















=C2=A0


















Good point about whether =
you just pass on one cost or a set of costs. As I said, not looked at detai=
ls - I will, when time permits. One cost is much easier,
 and yes, it reduces the fixed size aggregated signatures problem to =E2=80=
=9Cjust=E2=80=9D one of computational load.






















=C2=A0


















For the record, Thomas=E2=80=99 understanding is cor=
rect; the cost is one aggregated value.=C2=A0


















=C2=A0


















Best regards,=C2=A0


















Lotte Steenrbink














=C2=A0<=
/p>















=C2=A0












--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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:=C2=A0ietf@thomasclausen.org=
=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 16:38

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: Message integrity and message mutability (was RE: =
[manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)






















=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.














=C2=A0
























On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:




















=C2=A0






















I appreciate Thomas=E2=80=
=99s comments about the limitations of message regeneration, but I would be=
 a bit less absolute.






















=C2=A0






















The issues over end to en=
d authentication and more advanced signatures are valid. I need to read the=
 given reference on aggregate signatures to increase my
 knowledge (thanks for it), but my understanding of the possibilities in th=
is field may offer a solution to the problem, but with some other issues (p=
ossibly including a new type of TLV).






















=C2=A0






















But the hop count/limit p=
oint I don=E2=80=99t fully agree with, you can regenerate with an increment=
ed/decremented count/limit, which leaves the ability to prevent
 messages propagating indefinitely, including expanding ring searches, and =
retains the ability to use RFC 5497 interval and validity times that might =
be useful with an expanding ring search (or might not).






















=C2=A0






















But the key issue is that=
 AODVv2 wants to accumulate metrics. I still haven=E2=80=99t got to the bot=
tom of many details here, but let=E2=80=99s for the moment just consider
 that conceptually.






















=C2=A0






















It=E2=80=99s hard to hand=
le end to end. Charlie=E2=80=99s draft attempts to do an end to end of some=
 information, not this information. I=E2=80=99m not sure if that=E2=80=99s =
useful (and the
 specialised format is better avoided if possible). Other approaches are ho=
p by hop (might as well use packet signatures) and shared key (might as wel=
l go hop by hop). Pairwise signatures for each pair of routers I=E2=80=99m =
discounting as scaling terribly. In the
 interests of completeness let=E2=80=99s mention not accumulating metrics, =
which puts us back to hop count and that=E2=80=99s not ideal either.=























=C2=A0






















I don=E2=80=99t think the=
re is an ideal solution. (I like ideas I=E2=80=99ve seen about aggregating,=
 but that has some issues of its own, even apart from computational load.)
 I=E2=80=99d love to be proved wrong - someone with the perfect solution to=
 come along.






















=C2=A0






















Which means that either w=
e make an arbitrary choice - which will be disagreed with, but needs discus=
sing first - or create something flexible. Unfortunately
 flexible in that regard constrains in others, e.g. some (many? most?) aggr=
egating signatures need fixed data sizes (which we can do by defining a TLV=
 that =E2=80=9Cfills up=E2=80=9D with hop count, but that has a cost too).<=
/span>


























=C2=A0




















I have been told by people much more well versed in =
this than I in cryptology, that the correct answer is =E2=80=9Csome=E2=80=
=9D.






















=C2=A0






















That said, "AODVv2 wants to accumulate metrics=
=E2=80=9D =E2=80=94 does that mean that the message grows as it is being fo=
rwarded, and that the recipient of a RREQ/RREP will know the individual cos=
ts of each path segment? My understanding is, that the recipient
 will get =E2=80=9Cthe sum the costs of each path segment=E2=80=9D which sh=
ould be fitting within a fixed size?






















=C2=A0






















Thomas






















=C2=A0




















=C2=A0<=
/p>



















=C2=A0






















Sorry, no answers, just c=
omments. And I=E2=80=99m not addressing Thomas=E2=80=99s later points here.=























=C2=A0














--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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:=C2=A0manet [mailto:manet-bounces@ietf.o=
rg]=C2=A0On
 Behalf Of=C2=A0ietf@thomasclausen.org

Sent:=C2=A017 March 2016 16:00

To:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0[manet] draft-ietf-manet-aodvv2-13 review - a couple o=
f big ticket Items


























=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=C2=A0Red Fl=
ags=C2=A0that you can look out f=
or in emails
 you receive, click=C2=A0here.

If you feel the email is suspicious, please follow=C2=A0this process.








***=C2=A0<=
/b>WARNING=C2=A0***

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














=C2=A0
























Dear all,
























=C2=A0


























Apologies for not having gotten this done sooner - d=
ay-job leaving few spare cycles.


























=C2=A0


























I=E2=80=99ve previously offered reviews and comments=
, and some of those have been addressed in the latest I-D =E2=80=94 others =
have not, but should be. I recall that there was some mail attempting to re=
but parts of the review, and I will dig it out and
 reply to that.


























=C2=A0


























With that being said, I have reviewed the latest ver=
sion of the document, and full details will be forthcoming. There=E2=80=99r=
e a couple of big-ticket/architectural items that I want to address up fron=
t, as I believe that before we have those
 hammered out, it will be useless to go into details. Note, I do not claim =
that this is an exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D, but =
that=E2=80=99s as far as I have gotten in thinking this through.<=
/u>


























=C2=A0


























I also bring these up as they are items that have be=
en brought up repeatedly over the past years, but not resolved nor discusse=
d.


























=C2=A0


























Loops


























Just to bring this out: I share Chris=E2=80=99 worry=
 about conflicting and concurrent statements from the authors on =E2=80=9CT=
here are no loops possible=E2=80=9D and =E2=80=9CWe need to fix two situati=
ons where loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating =
some loop
 conditions=E2=80=9D


























=C2=A0


























I particularly worry that this is not a discussion h=
ad in public, but apparently in some other forum=E2=80=A6


























=C2=A0


























=C2=A0




























Intermediate Route Replies, and all of section=
 10


























Section 10 contains a set of =E2=80=9Cvaguely specif=
ied extensions=E2=80=9D, which is incoherent with the intended status indic=
ated for this document.=C2=A0


























=C2=A0


























Specifically, and this is not unrelated to the point=
 about loops above, intermediate RREPs (section 10.3) are a potential sourc=
e for loops.


























=C2=A0


























Expanding Ring Multicast (section 10.1) is not docum=
ented in a way that can be implemented (and also, see =E2=80=9CForwarding-v=
s-regeneration=E2=80=9D below, it is in the present form of this protocol i=
mpossible), etc.




























=C2=A0


























=C2=A0


























Forwarding-vs-regeneration


























Recent exchanges on the list made me understand that=
 protocol control messages are *not* forwarded, but are consumed at each ho=
p, then a new message with (almost-but-not-quite) the same content is gener=
ated and transmitted.


























=C2=A0


























I have thought some more on this (& read some of=
 the exchanges on the list on this topic by Chris, Ulrich, and others), and=
 I am convinced that this is not the right way to go,=C2=A0at least=
=C2=A0for the following reasons:


























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It renders the hop-limit/hop-count fields in the RFC5444 messag=
e header useless.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0This would not be bad if the functionality offered by tho=
se fields was not useful


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=94 sadly, it is. For example, for scope limited fl=
ooding (expanding ring search, and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0such) which may be of interest, and which require hop-lim=
it.=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0A hop-count field may also provide a =E2=80=9Ccheap=E2=80=
=9D (in terms of overhead) additional piece


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of information to use conjunctively with a =E2=80=9Creal=
=E2=80=9D metric.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The only practical solution would be to re-introduce thes=
e functions by way of inserting a


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0MessageTLV =E2=80=94 which (i) is not specified in this d=
ocument, and (ii) which would just


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0serve to render messages bigger than strictly needed.<=
/u>


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Scope limited flooding =C2=A0does seem to be a necessary =
requirement, if for no


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0other reason than to prevent information from =E2=80=9Cci=
rculating forever in the network=E2=80=9D.


























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It makes end-to-end authentication unnecessarily hard.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I think Chris called this out already, but it bears repea=
ting: S generates a message=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(say, a RREQ), and includes an ICV calculated over the co=
ntent of the message.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0For any recipient to be able to validate the ICV, the mes=
sage has to be exactly


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0the same =E2=80=94 not just in content, but in structure =
=E2=80=94 as what was generated.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforwa=
rding=E2=80=9D messages means, that the intermediate


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose =
a different structure (e.g., include TLVs


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0in a different order).


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The proposal from=C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00=



























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0is to add constraints on (i) the set of elements to inclu=
de in a signature and (ii) the


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0order of these elements.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0One=C2=A0problem with that approach is (i): if an extensi=
on adds a message TLV, or an=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Address TLV, to a message, then that will not be =E2=80=
=9Ccovered=E2=80=9D by the proposed e2esec TLV.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Rather for *each* extension developed, an =E2=80=9Cupdate=
s e2esec=E2=80=9D clause needs to be done.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I=E2=80=99d say that this approach would be prone to erro=
rs =E2=80=94 and add entropy to the process


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of designing protocol extensions. The alternative, a mess=
age being generated by the


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0source and *forwarded* (as we do in OLSRv2, for example) =
would allow ICV TLVs=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(even, allow reuse of those specified for OLSRv2) for cov=
ering a message and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0extensions.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CBut what about the metrics value which will chan=
ge on each hop=E2=80=9D, you may say?


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Fortunately, that is relatively easy to handle: simply ze=
ro out the value of that TLV when


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0generating or verifying the ICV MessageTLV. And use Packe=
t-TLVs for hop-by-hop=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0authentication, if needed (but, see below).=



























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It prevents the use of more clever/advanced signature scheme=
s/ICVs


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Aggregate signature algorithms (=C2=A0https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf<=
/span>)


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0exist, and an interesting use-case can be found in also r=
eactive protocols, allowing verifying


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0not =E2=80=9Cjust=E2=80=9D the end points, but also the i=
ntermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0discussed above, or something smarter).


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Regeneration of messages, rather than forwarding, renders=
 that impossible (or, if used,


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0updating to =C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)


























=C2=A0


























There are other reasons, but the above are those tha=
t jump at me as immediate show-stoppers.


























=C2=A0


























I do honestly not see what possible benefit there is=
 from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inconve=
niences, and security is not the least of these. Insisting on =E2=80=9Crege=
neration=E2=80=9D requires development of =E2=80=9Cnon-general workarounds=
=E2=80=9D as pointed
 out above.


























=C2=A0


























Security Considerations<=
/p>

























This is an always thorny subject. When OLSRv2 was go=
ing through the process we got a thorough education in how little we knew a=
bout security from the SEC-ADs, and had to spend about a year or so develop=
ing RFC7183. The bottom line is, that
 this protocol needs its =E2=80=9CRFC7183 =C2=A0equivalent=E2=80=9D, either=
 as part of the main document, or as an independent document. currently, th=
at is not the case.


























=C2=A0


























A minima, looking at BCP72 and BCP107 =E2=80=94 taki=
ng inspiration from RFC7183 might be aw good idea, as that was the most rec=
ent that went through the SEC AD. Regardless of how, however, a =E2=80=9Cma=
ndatory to implement=E2=80=9D security mechanism most be specified
 (I think the right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D),=
 in sufficient detail to ensure interoperable implementations.


























=C2=A0


























As an example, both [RFC6130] and [RFC7181] set out =
that that:




























=C2=A0


























=C2=A0 =C2=A0 =C2=A0 On receiving a ... message, a r=
outer MUST first check if the


























=C2=A0 =C2=A0 =C2=A0 message is invalid for processi=
ng by this router


























=C2=A0


























and then proceed to give a number of conditions that=
, each, will lead to a rejection of the message as "badly formed and t=
herefore invalid for processing=E2=80=9D =E2=80=94 a list which RFC7183 the=
n amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting
 =E2=80=9Crejection=E2=80=9D. Idem for message generation.

























=C2=A0


























If I was to do RFC7181/RFC6130 today, I would includ=
e that directly into the protocol specifications. It turned out to be more =
overhead (and slow down publication anyways) to do it as separate documents=
.




























=C2=A0


























Secondly, we need to be a lot more rigid in terms of=
 what ICVs, Timestamps, etc. are added/removed, and what that brings.


























=C2=A0


























For example (with the assumption that messages are *=
forwarded* and *not* regenerated), this could be one option:<=
/p>

























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0When a RREQ, RREP message is generated, add an ICV Message TLV, which=
 is calculated <this way>


























=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=E2=80=A6(take inspiration from RFC7183 here)


























=C2=A0


































...



[Message clipped]=C2=A0=C2=A0

_______________________________________________

manet mailing list

manet@ietf.org

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/manet






=C2=A0
















_______________________________________________

manet mailing list

manet@ietf.org

<=
span style=3D"color:purple">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 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

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/manet








=C2=A0














=C2=A0










______________________________________=
_________

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




=C2=A0












_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet





--001a1145ad26b08c6e053150d8b5--


From nobody Mon Apr 25 08:35: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 59E9912D52E for ; Mon, 25 Apr 2016 08:35:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.393
X-Spam-Level: 
X-Spam-Status: No, score=-1.393 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, TRACKER_ID=1.306] 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 I_mY_qxHeg7l for ; Mon, 25 Apr 2016 08:34:55 -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 DC4BC12D1B0 for ; Mon, 25 Apr 2016 08:34:53 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id t10so219190621ywa.0 for ; Mon, 25 Apr 2016 08:34:53 -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=+XKByFJj8gHL/lqEi4tKtiS2u8w6BjuYthhQyCUsjPI=; b=BZiy+DO3I3USWPgYa3kfR3Yzx09T3gvKQAv4NL91XYaUQbFxODqJ5Jhu/JDXFnheVT JGaWdR7or5RVxjz3pPa8pnosXhZml69Jablu2ZxZq1kiWxiCG1GUD7TAmzlJp73c+2y2 iJQWRrInqpOyxiRAnFhEAny1KNqyw7I67kY3p/BHKajPl/HQ9L9UVOEyYaFMWp70FQMT Dcs//RiMiUYiIbs+hHm3yem/iTKG+4okp8RAJu+Nmrm98pwEoNSQqjA9SnM8epygnd6i O0RB3hggZp2TFxhyrJAbCxNuDg3TPiR/vMEeS6ltN+2VoYdy4JerOXtjMAmYOHkw4KO5 yzaw==
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=+XKByFJj8gHL/lqEi4tKtiS2u8w6BjuYthhQyCUsjPI=; b=XZTPxOQHoQl6ayHVmSKrWdsTbh1NI2ZJSD6B7Td+hgEyu1IHDEw6VX0RHFf1PEV5X7 tKEC4A1SuBlXZoSvbimYqxfm2RMOoYi56jDsQn7fIstdBxzEEllZuRABOT6YFIaih4gA eVtNtlYQUXeaEaKP5HTx/Dn4WPBQkTgRZJtbpFh8uChrdx2ZwNtxDIOLx3+uU7axuzx5 vkQ5MG0yxqUUdRhhXItTXWPQO9osWUK4/fiiwQDJLP3PijOni6OmwrME+JMpqVLRfvfP xSoIpy5smT6K7ZKWbOG72Qibsh+BQlWVdmNo+wggREWFPX3W3JjmRwTw11Wk8dVTOgi2 ZL7A==
X-Gm-Message-State: AOPr4FViDSGoO4bdmAYBK7Qif2NvF3Txx9V3ALrjTuiIAnmBbmTtIuE23ymPICSxWE544YALwxq0dSOakV2NEA==
MIME-Version: 1.0
X-Received: by 10.176.7.10 with SMTP id h10mr14445423uah.40.1461598492892; Mon, 25 Apr 2016 08:34:52 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Mon, 25 Apr 2016 08:34:52 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org>    
Date: Mon, 25 Apr 2016 11:34:52 -0400
Message-ID: 
From: Justin Dean 
To: Jiazi YI 
Content-Type: multipart/alternative; boundary=94eb2c123f7cf93ecc053150ea5d
Archived-At: 
Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 15:35:01 -0000

--94eb2c123f7cf93ecc053150ea5d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 25, 2016 at 11:29 AM, Jiazi YI  wrote:

> Hi,
>
> Maybe I missed a bit here:
>
> If only the desired receiver of the multicast RREP (carrying a destinatio=
n
> address) can reply to the multicast RREP, why not using unicast directly?
>
> Because the link isn't yet known to be bi-directional and a unicast route
can't be installed yet.

Justin


> best
>
> Jiazi
>
> On Mon, Apr 25, 2016 at 4:59 PM, Victoria Mercieca 
> wrote:
>
>> Hi Chris,
>>
>>
>> On Mon, Apr 25, 2016 at 3:51 PM, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>>
>>> I has to go back to Victoria=E2=80=99s summary here. It says:
>>>
>>>
>>>
>>> 2) C creates the RREP. Since it doesnt know if the link to B is
>>> bidirectional, it includes the AckReq (an address to indicate that it
>>> expects to receive a RREP_Ack from B).
>>>
>>>
>>>
>>> That doesn=E2=80=99t actually indicate if that=E2=80=99s C=E2=80=99s ad=
dress or B=E2=80=99s address
>>> being included. I=E2=80=99d assumed it was C=E2=80=99s address. Your co=
mment makes sense if
>>> it=E2=80=99s B=E2=80=99s address. Reading again, I think you=E2=80=99re=
 probably right. But only
>>> probably. Can we confirm that.
>>>
>>>
>>>
>>
>> C creates the RREP. The included AckReq address is B's address. The RREP
>> then gets multicast.
>> B receives it, sees that it own address is marked as the AckReq address,
>> and sends an ack unicast back to C.
>> Anyone else who receives the multicast RREP from C does not send the Ack=
,
>> since the AckReq address does not match any of their interface addresses=
.
>>
>>
>>> I assume you meant that the RREP (not RREP_Ack) is multicast. There=E2=
=80=99s a
>>> bit of a chicken and egg problem here. We do know how we want to unicas=
t.
>>>
>>
>> The RREP is multicast (when we dont know if the link is bidirectional),
>> the RREP_Ack is always unicast.
>>
>> Kind regards,
>> Vicky.
>>
>>
>>>
>>> *-- *
>>>
>>>
>>>
>>>
>>> *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:* 25 April 2016 15:26
>>> *To:* Thomas Heide Clausen
>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
>>> Networks mailing list; Victoria Mercieca
>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>
>>>
>>>
>>>
>>>
>>> **** 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
>>> .*
>>>
>>> The address in the RREP_Ack may be required due to the RREP_Ack being
>>> multicast as there is not yet a verified unicast route installed yet.
>>> Going to double check if I'm remembering correctly.
>>>
>>> Justin
>>>
>>>
>>>
>>> On Mon, Apr 25, 2016 at 10:18 AM,  wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> I must admit that while I have reviewed the protocol several times, I=
=E2=80=99ve
>>> not been digging that deep into the protocol functioning to catch this
>>> issue of how invasive the protocol operations are when forwarding a
>>> message: there were other =E2=80=9Cmajor=E2=80=9D issues to address (an=
d which obscured the
>>> details), so as a first order: thank you Victoria, for having called
>>> attention to this.
>>>
>>>
>>>
>>> To the substance of these emails.
>>>
>>>
>>>
>>> I am afraid that I do not understand the use of inserting validity TLVs
>>> while in-flight, into a message. Actually, I am dubious for both the
>>> originator inserting this (how can the originator of a message know how
>>> =E2=80=9Clatter parts of the path=E2=80=9D will be have=E2=80=9D) excep=
t if we are talking
>>> duty-cycling of devices and inserting =E2=80=9Cthe remaining time that =
I am going
>>> to be up before I suspend=E2=80=9D. Intuitively, that would also assume=
 fairly long
>>> duty cycles =E2=80=9CI am up for tens of seconds=E2=80=9D, which I am n=
ot sure are actually
>>> realistic. And, as Chris says in another email, this is trading off =E2=
=80=9Cthe
>>> ability to do security=E2=80=9D for an unknown/untested feature =E2=80=
=94 which I think is
>>> the wrong trade-off.
>>>
>>>
>>>
>>> On he topic of =E2=80=9Cneeding to put an address in=E2=80=9D for RREP-=
ACK, I must admit
>>> that this seems roundabout. I can see three issues here:
>>>
>>>
>>>
>>> o I am not sure that adding an address vs. a flag may not have to do
>>> with the =E2=80=9Cmultiple interfaces/
>>>
>>> multiple addresses=E2=80=9D discrimination mechanics of the protocol? I=
 haven=E2=80=99t
>>> worked it through, though,
>>>
>>> but that would be a guess.
>>>
>>>
>>>
>>> o The end-to-end topology diffusion mechanism should not need to be
>>> concerned with the
>>>
>>> =E2=80=9Cbidirectionally check=E2=80=9D of a local link (in part, as it=
 encumbers
>>> security, but not only).  In short, a
>>>
>>> flag or an address, both are (equally) bad.
>>>
>>>
>>>
>>> o A cleaner mechanism would be a =E2=80=9Chello mechanism=E2=80=9D, not=
 necessarily as
>>> NHDP, but a =E2=80=9Cwhen
>>>
>>> forwarding a RREQ/RREP, trigger a 3-way hello exchange, if the link is
>>> estimated to be of a
>>>
>>> type which potentially can be unidirectional=E2=80=9D. There is another=
 benefit
>>> to doing that, see the end
>>>
>>> of this email.
>>>
>>>
>>>
>>> Either way, I do not like the notion of fusing
>>> metrics-and-link-bidirectionality-detection any more than I like fusing
>>> global-topology-diffusion-and-link-bidirectionality-detection.
>>>
>>>
>>>
>>> The solution all this is, to me, threefold
>>>
>>>
>>>
>>> 1) Factor out the bidirectionally check in a (triggered) neighbour
>>> detection mechanism
>>>
>>> (triggered HELLO message)
>>>
>>>
>>>
>>> 2) Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, since they add comp=
lexity for no
>>> perceivable benefits
>>>
>>>
>>>
>>> 3) Use the security model that we=E2=80=99ve discussed previously, wher=
e (only)
>>> the metrics change per hop.
>>>
>>>
>>>
>>> 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 t=
o a
>>> related 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 installe=
d
>>>
>>>    in the Local Route Set at each router will be correct.  While this
>>>
>>>    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. Consequent=
ly, the conclusion
>>> 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 link=
 the
>>> metrics is 4 or 5=E2=80=9D, the protocol must be able to convey and dis=
tinguish
>>> that =E2=80=9Cthe metric from A to B is 4, and the metric from B to A i=
s 19=E2=80=9D.
>>>
>>>
>>>
>>> This is a =E2=80=9Crelated issue=E2=80=9D since the solution may (as wi=
th the
>>> bi-directionality check) be in the triggered neighbour detection mechan=
ism:
>>> that exchange could, if designed carefully, be used to probe for and co=
nvey
>>> metrics information, also.
>>>
>>>
>>>
>>> Hope this helps,
>>>
>>>
>>>
>>>
>>>
>>> Thomas
>>>
>>>
>>>
>>> On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK) <
>>> chris.dearlove@baesystems.com> wrote:
>>>
>>>
>>>
>>> Assuming for the moment that everyone will need an RREP-Ack or won=E2=
=80=99t
>>> (let=E2=80=99s come back to that) why do C and B need to put an address=
 in as an
>>> RREQ-Ack request? Why not a flag, because the address will be included =
as
>>> the IP sending address - and we know 5444 is required to pass that on.
>>> (It=E2=80=99s used by NHDP as well.) Then we don=E2=80=99t need to chan=
ge the RREP, it will
>>> have a flag set or not, and won=E2=80=99t change (in this regard).
>>>
>>>
>>>
>>> Now let=E2=80=99s consider do we know whether we can set a fixed flag. =
First I=E2=80=99d
>>> say there are two cases - you=E2=80=99ve got a firm control on what=E2=
=80=99s going on in
>>> your network, or it=E2=80=99s one of unknown parties and behaviour (con=
sistent with
>>> specification). In the former case you only want one setting, for examp=
le
>>> no-Ack if running NHDP or your MAC layer tells you about bidirectionali=
ty,
>>> Ack otherwise. In the latter case, I think you just always want an Ack.=
 So
>>> both cases get you to the same place.
>>>
>>>
>>>
>>> Should that not be an acceptable argument (though I think it=E2=80=99s =
good for
>>> where we are - in fact always Ack is close) then at flag is a step bett=
er,
>>> it=E2=80=99s a fixed location to change. However it would be better in =
that case if
>>> the two things to change (metric and ack flag) were together. But that =
has
>>> its own issues, so I won=E2=80=99t go there.
>>>
>>>
>>>
>>> *--*
>>>
>>>
>>>
>>>
>>> *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com
>>> ]
>>> *Sent:* 25 April 2016 14:15
>>> *To:* Jiazi YI
>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
>>> Networks mailing list
>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>
>>>
>>>
>>>
>>>
>>> **** 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
>>> .*
>>>
>>> Hi Jiazi,
>>>
>>>
>>>
>>> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI  wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
>>> chris.dearlove@baesystems.com> wrote:
>>>
>>> With regard to your validity time point, we here have a tradeoff. If yo=
u
>>> allow that feature, it significantly impacts on the approach that was
>>> coming together on as best you can end to end encryption.
>>>
>>>
>>>
>>> So the question is, is this a feature that=E2=80=99s really wanted?
>>> Unfortunately I think we know that the answer to that is, we don=E2=80=
=99t know
>>> because we don=E2=80=99t have any experience. My view would be that in =
the tradeoff
>>> of an untested feature (unless I=E2=80=99m wrong about that) and the se=
curity
>>> complication, security wins and drop the feature. If there is some real
>>> requirement, then there=E2=80=99s a discussion. (Questions like how oft=
en the
>>> intermediate routers actually have any knowledge - typically links brea=
k
>>> for unexpected rather than expected reasons. Andan intermediate router
>>> could possibly use a validity time to influence its behaviour.) Note th=
at
>>> dropping the ability of intermediate routers to modify/set still allows
>>> validity times per route to be set at endpoints.
>>>
>>>
>>>
>>> I agree with Chris' concern.
>>>
>>> The ValidityTime is optional, which makes the integrity protection hard=
.
>>> Furthermore, it gives a potential attack vector: as all the routers in =
a
>>> path will take the shortest validityTime, a compromised router can set =
the
>>> the validityTime to a very short value, which will make the route insta=
lled
>>> along the path became invalid (very soon).
>>>
>>>
>>>
>>> On the other hand, I'm not sure this option will give us much help.
>>> Chris mentioned much knowledge intermediate router would have to decide
>>> this value (and how much sense the value would make).
>>>
>>> Another issue is, a route to a destination might be updated by differen=
t
>>> sources. For example, in the network below:
>>>
>>>
>>>
>>> A----B-----C
>>>
>>>
>>>
>>> A first establish a route to B with long validity time. Then A initiate=
s
>>> a route discovery to C. C tends to set a short validity time, which wil=
l
>>> make the route between B and A expire earlier than expected.
>>>
>>> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered
>>> or not.
>>>
>>>
>>>
>>>
>>>
>>> Not sure I follow here.
>>>
>>> Currently, the validity time of the route between A and B would not
>>> affected by a short validity time of a route between A and C. Validity
>>> times are per-route, and the route A-B and the route A-C are separate.
>>>
>>> If we switched to a validity time per neighbor (so that we can keep
>>> validity time separate from route advertisements) as I mentioned in the
>>> email below, then the validity of a route between A and C would be affe=
cted
>>> if there was a short validity time between A and B. But, if B will only
>>> route for a certain amount of time, then the route between A and C will=
 of
>>> course be affected. Is it best to know in advance that there's a time
>>> limit, or just deal with RERRs when they happen?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> With regard to the acknowledgements, the problem (with regard to
>>> security) comes from trying to do two jobs with the same message - end =
to
>>> end route advertisement and hop by hop acknowledgement. I understand th=
e
>>> reasons - saving bytes and message types. (I would have to study the
>>> protocol really hard to identify if any message types can be folded
>>> together and recognised by content rather than type efficiently. This I=
 do
>>> not expect to do.) Again a tradeoff. This one is in discussion space,
>>> though that needs people who understand both sides of the issue, includ=
ing
>>> the details of the bidirectionality mechanism. Of course, as has been s=
aid,
>>> we need one of those.
>>>
>>>
>>>
>>> I haven't finished my review of the latest draft, and I don't get the
>>> necessity of AckReq and the corresponding multicast RREP yet.
>>>
>>> If possible, this "optional" field should be avoided.
>>>
>>>
>>>
>>>
>>> To give an overview of AckReq and RREP:
>>>
>>> Since AODVv2 requires bidirectional links, this is the way to determine
>>> if a link is bidirectional.
>>>
>>> A----B----C
>>>
>>>
>>> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both
>>> install a route to OrigAddr but they dont yet know if it's valid becaus=
e
>>> they dont know if the link to their next hop is available in the revers=
e
>>> direction.
>>>
>>> 2) C creates the RREP. Since it doesnt know if the link to B is
>>> bidirectional, it includes the AckReq (an address to indicate that it
>>> expects to receive a RREP_Ack from B).
>>>
>>> 3) B receives the RREP, installs a route to TargAddr and marks it as
>>> valid, since it knows the link to C is bidirectional, because the RREQ =
went
>>> in one direction and the RREP came in the other. B also sends the RREP_=
Ack
>>> to C and forwards the RREP to A (and might change the message to indica=
te
>>> its own AckReq - ie that it requires an ack from A).
>>>
>>> 4) C receives the RREP_Ack from B, and therefore knows that B received
>>> the RREP, therefore the link is bidirectional. C can then mark its rout=
e to
>>> OrigAddr as valid.
>>>
>>> 5) Similarly, A receives the RREP, installs the route to TargAddr and
>>> sends an RREP_Ack to B.
>>>
>>> 6) B receives the RREP_Ack and marks its route to OrigAddr as valid.
>>>
>>>
>>>
>>> Alternatively, in step 2, if C knows the link to B is bidirectional
>>> (perhaps from some earlier route discovery), it doesnt need to put the
>>> AckReq in the RREP. Then in step 3, since B doesnt know if the link to =
A is
>>> bidirectional, it changes the message to add the AckReq address, in ord=
er
>>> to get an RREP_Ack from A.
>>>
>>> If we want to avoid changing the message, we'll need to look at
>>> forwarding the RREP as-is, and creating a second message to solicit an
>>> RREP_Ack, in order to verify that the link is bidirectional before mark=
ing
>>> the route to OrigAddr as valid.
>>>
>>> Kind regards,
>>>
>>> Victoria.
>>>
>>>
>>>
>>>
>>>
>>> regards
>>>
>>>
>>>
>>> Jiazi
>>>
>>>
>>>
>>>
>>>
>>> *--*
>>>
>>>
>>>
>>>
>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>> Intelligence Laboratories *
>>> *______________________________________________________________________=
____
>>> *
>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
>>> *Sent:* 23 April 2016 10:55
>>> *To:* Christopher Dearlove
>>> *Cc:* ietf@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc
>>> Networks mailing list
>>>
>>>
>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>
>>>
>>>
>>>
>>>
>>> **** 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
>>> .*
>>>
>>> Hi Chris,
>>>
>>>
>>>
>>> These have both been in the draft in some form since before I got
>>> involved... but I'll do my best to explain.
>>>
>>>
>>>
>>> - For Validity Time, its a way to advertise that you would only support
>>> the route contained in the message for a certain period of time. The
>>> originator might use this, but the draft was written to allow any
>>> intermediate node to be able to add it or update it too. The route crea=
ted
>>> in the Local Route Set has an expiration time associated with it, based=
 on
>>> the received validity time.
>>>
>>> - For the AckReq address, its so that you can add into a RREP a request
>>> for an acknowledgement, so that you don't have to have a different mess=
age
>>> type altogether for working out whether links to neighbors are
>>> bidirectional, and also, since you only care about bidirectionality on
>>> routes that are being set up, you dont need to constantly monitor all
>>> neighbors.
>>>
>>>
>>>
>>>
>>>
>>> In order to avoid the potential AckReq-related changes to each message,
>>> maybe we do need to introduce a different message specifically for this=
. We
>>> could maybe use RREP_Ack to both request and acknowledge? It means an e=
xtra
>>> message of control traffic that needs to be sent, maybe one extra messa=
ge
>>> per hop on the path of a RREP, but it could still be limited to neighbo=
rs
>>> which have participated in the route discovery rather than monitoring a=
ll
>>> neighbors at all times.
>>>
>>>
>>>
>>> This message could maybe also include "I'm happy to route anywhere for =
a
>>> certain amount of time", sort of like willingness in OLSR/OLSRv2. So
>>> instead of having a validity time per route, its a validity time per
>>> neighbor. Then, for RREQ and RREP, only the metric value would change i=
n
>>> transit, as discussed. However, that leads to some issues with deciding
>>> what a route's expiration time is. You might know how long the next hop
>>> router is valid for, but what if a router beyond that, which was also p=
art
>>> of the route, had a lower validity time? You couldn't determine the rea=
l
>>> validity time. Do we remove the route expiration time altogether to avo=
id
>>> this issue? In which case, we would have to rely on RERR messages being
>>> sent for routes which become invalid when the neighbor's validity time =
has
>>> expired? So neighbor validity time expiration is treated the same as a =
link
>>> break.
>>>
>>>
>>>
>>> What do you think?
>>>
>>>
>>>
>>> Kind regards,
>>>
>>> Victoria.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
>>> chris@mnemosyne.demon.co.uk> wrote:
>>>
>>> Pretty much all of the discussion has been assuming only a metric value
>>> change. With multiple things changing many of the ideas go out of the
>>> window. That reinforces the point about not making specifications now t=
hat
>>> might turn out to be wrong for ICVs.
>>>
>>>
>>>
>>> Ignoring how this misunderstanding happened, I'll start by asking why.
>>> Metric changing I understand. Why the other two? (there's a partial
>>> explanation of one). What alternatives have people implemented in
>>> comparable protocols?
>>>
>>> --
>>>
>>> Christopher Dearlove
>>>
>>> christopher.dearlove@gmail.com (iPhone)
>>>
>>> chris@mnemosyne.demon.co.uk (home)
>>>
>>>
>>> On 23 Apr 2016, at 00:26, Victoria Mercieca 
>>> wrote:
>>>
>>> Hi all,
>>>
>>>
>>>
>>> Continued in this thread because the other one seems to be more about
>>> TLV types and metric type numbers, whereas this is about
>>> regeneration/forwarding.
>>>
>>>
>>>
>>> To recap, in the current draft, there are 3 things that might change at
>>> each hop:
>>> - the metric value (happens in RREQ and RREP),
>>> - adding/changing Validity Time using the Validity Time TLV (can happen
>>> in RREQ and RREP),
>>> - adding an address (and corresponding value in the AddressType TLV to
>>> indicate how to interpret the address) to indicate the address from whi=
ch
>>> an RREP_Ack is expected, to accomplish the bidirectionality check (can
>>> happen in RREP).
>>>
>>> If we define a certain portion of the message as immutable and include
>>> the ICV to verify that part, end to end:
>>> - The metric value would be excluded from the ICV since it needs
>>> changing at each hop.
>>> - Would adding a Validity Time TLV at an intermediate hop be acceptable=
?
>>> The whole TLV could be removed in order to calculate the ICV?
>>>
>>> - Would adding an address cause issues for the ICV, because it's in the
>>> address block? Could the rule be "if it contains an AckReq address, rem=
ove
>>> it (and the corresponding value in the AddressType TLV), before checkin=
g
>>> the ICV", is that OK? Or would we need to avoid touching the ICV'ed par=
t of
>>> the message altogether, maybe put the AckReq address in a separate Addr=
ess
>>> Block, with an extra AddressType TLV following that address block? Is t=
here
>>> a way to accomplish this?
>>>
>>>
>>>
>>> Also, to be thorough, do we need to consider RERR messages while we
>>> discuss regeneration vs forwarding?
>>>
>>> - RERR (sent when a link breaks) is a way of saying "I've lost my route
>>> so I'm telling others" and "you were my next hop, so now I've also lost=
 my
>>> route, I'll tell others", etc. It's going to be tailored at each step t=
o
>>> include the relevant routes that got deleted, it's not one message bein=
g
>>> sent end-to-end like RREQ and RREP are.
>>>
>>> - However, RERR (sent when a source of traffic is sending data on a
>>> route which comes through you, and you want to tell the Packet Source's
>>> router to delete the route) could be seen as an end-to-end message whic=
h
>>> all intermediate routers learn from, similar to RREQ and RREP. It repor=
ts
>>> one route, and doesn't need changing at intermediate hops, so could be
>>> protected with ICV.
>>>
>>> - Would it be OK to only require a message ICV if a PktSource address
>>> was included, i.e. when the message needs to go via a number of
>>> intermediate hops to PktSource's router? All other RERRs are intended t=
o be
>>> one-hop messages, which may in turn prompt other one-hop messages, etc.=
..,
>>> and a packet ICV might be more appropriate?
>>>
>>>
>>>
>>> Kind regards,
>>>
>>> Victoria.
>>>
>>>
>>>
>>> On Thu, Mar 17, 2016 at 5:26 PM,  wrote:
>>>
>>>
>>>
>>> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
>>> chris.dearlove@baesystems.com> wrote:
>>>
>>>
>>>
>>> Yes, I meant AODVv2, thanks for the catch.
>>>
>>>
>>>
>>> So is your (Thomas) proposed base specification a hop count only metric=
?
>>>
>>>
>>>
>>> No, the would be silly as base specification, given that hop count
>>> mostly is useless.
>>>
>>>
>>>
>>> As base specification I would simply say =E2=80=9CInclude a Metric Type=
 Message
>>> TLV with a value field, and a 7182 Message TLV & Timestamp=E2=80=9D as =
we do in
>>> OLSRv2 (with the appropriate verbiage as to generation and processing).
>>>
>>>
>>>
>>> With the message generated by the originator of the RREQ/RREP and *not*
>>> deconstructed/reconstructed/reordered (as is the risk with =E2=80=9Creg=
eneration)
>>> allows knowing that it would be *only* that metric field being modified
>>> (other than hop count/limit) for when eventually writing up the extensi=
on.
>>>
>>>
>>>
>>> (Actually doesn=E2=80=99t the current specification only define hop cou=
nt, or
>>> has that changed in latest draft?)
>>>
>>>
>>>
>>> No. That is one of the issues I raise in my original. For some reason,
>>> it cites RFC6551, which is a ROLL document and which has in its abstrac=
t
>>> that:
>>>
>>>
>>>
>>>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>>>
>>>    compared with traditional wired and ad hoc networks that require the
>>>
>>>    specification of new routing metrics and constraints.
>>>
>>>
>>>
>>> I.e. this document cites a metric document which clearly claims to be
>>> inapplicable in ad hoc networks. I note that this is another thing I=E2=
=80=99ve
>>> raised for years without seeing it attempted resolved.
>>>
>>>
>>>
>>> Best,
>>>
>>>
>>>
>>> Thomas
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *--*
>>>
>>>
>>>
>>>
>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>> Intelligence Laboratories *
>>> *______________________________________________________________________=
____
>>> *
>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>>> ]
>>> *Sent:* 17 March 2016 17:10
>>> *To:* Dearlove, Christopher (UK)
>>> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>
>>>
>>>
>>>
>>>
>>> **** 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 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
>>> chris.dearlove@baesystems.com> wrote:
>>>
>>>
>>>
>>> OK, so we have a message that mutates by:
>>>
>>> - Modifying hop count/limit.
>>>
>>> - Modifying a metric value.
>>>
>>> Anything else?
>>>
>>>
>>>
>>> As mutating (other than hop count/limit) messages aren=E2=80=99t covere=
d by 5444
>>> or any derivative document (but only recommended against, not banned) t=
hat
>>> you may need to make the message otherwise immutable (no deconstruction=
 and
>>> rebuilding, other than guaranteed unchanging) that would have to be
>>> specified by AODVv2. (Easy to say, but needs saying.)
>>>
>>>
>>>
>>> With you so far.
>>>
>>>
>>>
>>> Then that information is not in a guaranteed fixed location given by a
>>> simple offset. So any signature algorithm that finds it and ignores it =
or
>>> aggregates on it is specific to OLSRv2.
>>>
>>>
>>>
>>> Surely you mean AODVv2
>>>
>>>
>>>
>>> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AODVv=
2
>>> specialised variant. Which is the sort of thing that the message specif=
ic
>>> TLV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cbut =
ignore the value of
>>> this specific TLV should it occur=E2=80=9D being in the general space. =
However it
>>> can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like t=
hat TLV,
>>> except if an X TLV is present, set its value field to zero=E2=80=9D).
>>>
>>>
>>>
>>> Messy, but could work.
>>>
>>>
>>>
>>> Not that messy, actually, although clearly not as nice as =E2=80=9Cfixe=
d offset=E2=80=9D.
>>>
>>>
>>>
>>> That said, I am arguing for the base spec being:
>>>
>>>
>>>
>>>             =E2=80=9Cmake the message otherwise immutable (no deconstru=
ction and
>>> rebuilding, other
>>>
>>>              than guaranteed unchanging)=E2=80=9D which is afforded by =
forwarding
>>>
>>>
>>>
>>>                                     +
>>>
>>>
>>>
>>>             RFC7182 Timestamps and ICVs.
>>>
>>>
>>>
>>>                                     +
>>>
>>>
>>>
>>>             RFC7183 style text bringing it all together.
>>>
>>>
>>>
>>> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would =
very be an
>>> experimental extension.
>>>
>>>
>>>
>>> What I object to is, if the base spec specifically renders such
>>> extensions impossible
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *--*
>>>
>>>
>>>
>>>
>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>> Intelligence Laboratories *
>>> *______________________________________________________________________=
____
>>> *
>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
>>> ]
>>> *Sent:* 17 March 2016 16:48
>>> *To:* Dearlove, Christopher (UK)
>>> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>
>>>
>>>
>>>
>>>
>>> **** 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
>>> .*
>>>
>>> Hi all,
>>>
>>>
>>>
>>> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
>>> chris.dearlove@baesystems.com>:
>>>
>>>
>>>
>>> Good point about whether you just pass on one cost or a set of costs. A=
s
>>> I said, not looked at details - I will, when time permits. One cost is =
much
>>> easier, and yes, it reduces the fixed size aggregated signatures proble=
m to
>>> =E2=80=9Cjust=E2=80=9D one of computational load.
>>>
>>>
>>>
>>> For the record, Thomas=E2=80=99 understanding is correct; the cost is o=
ne
>>> aggregated value.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Lotte Steenrbink
>>>
>>>
>>>
>>>
>>>
>>> *--*
>>>
>>>
>>>
>>>
>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>> Intelligence Laboratories *
>>> *______________________________________________________________________=
____
>>> *
>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>>> ]
>>> *Sent:* 17 March 2016 16:38
>>> *To:* Dearlove, Christopher (UK)
>>> *Cc:* Mobile Ad Hoc Networks mailing list
>>> *Subject:* Re: Message integrity and message mutability (was RE:
>>> [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Item=
s)
>>>
>>>
>>>
>>>
>>>
>>> **** 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 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
>>> chris.dearlove@baesystems.com> wrote:
>>>
>>>
>>>
>>> I appreciate Thomas=E2=80=99s comments about the limitations of message
>>> regeneration, but I would be a bit less absolute.
>>>
>>>
>>>
>>> The issues over end to end authentication and more advanced signatures
>>> are valid. I need to read the given reference on aggregate signatures t=
o
>>> increase my knowledge (thanks for it), but my understanding of the
>>> possibilities in this field may offer a solution to the problem, but wi=
th
>>> some other issues (possibly including a new type of TLV).
>>>
>>>
>>>
>>> But the hop count/limit point I don=E2=80=99t fully agree with, you can
>>> regenerate with an incremented/decremented count/limit, which leaves th=
e
>>> ability to prevent messages propagating indefinitely, including expandi=
ng
>>> ring searches, and retains the ability to use RFC 5497 interval and
>>> validity times that might be useful with an expanding ring search (or m=
ight
>>> not).
>>>
>>>
>>>
>>> But the key issue is that AODVv2 wants to accumulate metrics. I still
>>> haven=E2=80=99t got to the bottom of many details here, but let=E2=80=
=99s for the moment
>>> just consider that conceptually.
>>>
>>>
>>>
>>> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft attempt=
s to do an end to
>>> end of some information, not this information. I=E2=80=99m not sure if =
that=E2=80=99s
>>> useful (and the specialised format is better avoided if possible). Othe=
r
>>> approaches are hop by hop (might as well use packet signatures) and sha=
red
>>> key (might as well go hop by hop). Pairwise signatures for each pair of
>>> routers I=E2=80=99m discounting as scaling terribly. In the interests o=
f
>>> completeness let=E2=80=99s mention not accumulating metrics, which puts=
 us back to
>>> hop count and that=E2=80=99s not ideal either.
>>>
>>>
>>>
>>> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=80=
=99ve seen about
>>> aggregating, but that has some issues of its own, even apart from
>>> computational load.) I=E2=80=99d love to be proved wrong - someone with=
 the perfect
>>> solution to come along.
>>>
>>>
>>>
>>> Which means that either we make an arbitrary choice - which will be
>>> disagreed with, but needs discussing first - or create something flexib=
le.
>>> Unfortunately flexible in that regard constrains in others, e.g. some
>>> (many? most?) aggregating signatures need fixed data sizes (which we ca=
n do
>>> by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but t=
hat has a cost too).
>>>
>>>
>>>
>>> I have been told by people much more well versed in this than I in
>>> cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>>>
>>>
>>>
>>> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does =
that mean that
>>> the message grows as it is being forwarded, and that the recipient of a
>>> RREQ/RREP will know the individual costs of each path segment? My
>>> understanding is, that the recipient will get =E2=80=9Cthe sum the cost=
s of each
>>> path segment=E2=80=9D which should be fitting within a fixed size?
>>>
>>>
>>>
>>> Thomas
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Sorry, no answers, just comments. And I=E2=80=99m not addressing Thomas=
=E2=80=99s later
>>> points here.
>>>
>>>
>>>
>>> *--*
>>>
>>>
>>>
>>>
>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>> Intelligence Laboratories *
>>> *______________________________________________________________________=
____
>>> *
>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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 *ietf@thomasclausen.org
>>> *Sent:* 17 March 2016 16:00
>>> *To:* Mobile Ad Hoc Networks mailing list
>>> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of big
>>> ticket Items
>>>
>>>
>>>
>>>
>>>
>>> **** 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=
.
>>>
>>>
>>>
>>> Dear all,
>>>
>>>
>>>
>>> Apologies for not having gotten this done sooner - day-job leaving few
>>> spare cycles.
>>>
>>>
>>>
>>> I=E2=80=99ve previously offered reviews and comments, and some of those=
 have
>>> been addressed in the latest I-D =E2=80=94 others have not, but should =
be. I recall
>>> that there was some mail attempting to rebut parts of the review, and I
>>> will dig it out and reply to that.
>>>
>>>
>>>
>>> With that being said, I have reviewed the latest version of the
>>> document, and full details will be forthcoming. There=E2=80=99re a coup=
le of
>>> big-ticket/architectural items that I want to address up front, as I
>>> believe that before we have those hammered out, it will be useless to g=
o
>>> into details. Note, I do not claim that this is an exhaustive list of =
=E2=80=9Cbig
>>> ticket items=E2=80=9D, but that=E2=80=99s as far as I have gotten in th=
inking this through.
>>>
>>>
>>>
>>> I also bring these up as they are items that have been brought up
>>> repeatedly over the past years, but not resolved nor discussed.
>>>
>>>
>>>
>>> *Loops*
>>>
>>> Just to bring this out: I share Chris=E2=80=99 worry about conflicting =
and
>>> concurrent statements from the authors on =E2=80=9CThere are no loops p=
ossible=E2=80=9D and
>>> =E2=80=9CWe need to fix two situations where loops can occur=E2=80=9D a=
nd =E2=80=9Cwe are still
>>> investigating some loop conditions=E2=80=9D
>>>
>>>
>>>
>>> I particularly worry that this is not a discussion had in public, but
>>> apparently in some other forum=E2=80=A6
>>>
>>>
>>>
>>>
>>>
>>> *Intermediate Route Replies, and all of section 10*
>>>
>>> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=
=80=9D, which is
>>> incoherent with the intended status indicated for this document.
>>>
>>>
>>>
>>> Specifically, and this is not unrelated to the point about loops above,
>>> intermediate RREPs (section 10.3) are a potential source for loops.
>>>
>>>
>>>
>>> Expanding Ring Multicast (section 10.1) is not documented in a way that
>>> can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=
=E2=80=9D below, it is
>>> in the present form of this protocol impossible), etc.
>>>
>>>
>>>
>>>
>>>
>>> *Forwarding-vs-regeneration*
>>>
>>> Recent exchanges on the list made me understand that protocol control
>>> messages are *not* forwarded, but are consumed at each hop, then a new
>>> message with (almost-but-not-quite) the same content is generated and
>>> transmitted.
>>>
>>>
>>>
>>> I have thought some more on this (& read some of the exchanges on the
>>> list on this topic by Chris, Ulrich, and others), and I am convinced th=
at
>>> this is not the right way to go, *at least* for the following reasons:
>>>
>>>
>>>
>>>
>>>
>>>             o          *It renders the hop-limit/hop-count fields in
>>> the RFC5444 message header useless.*
>>>
>>>                         This would not be bad if the functionality
>>> offered by those fields was not useful
>>>
>>>                         =E2=80=94 sadly, it is. For example, for scope =
limited
>>> flooding (expanding ring search, and
>>>
>>>                         such) which may be of interest, and which
>>> require hop-limit.
>>>
>>>                         A hop-count field may also provide a =E2=80=9Cc=
heap=E2=80=9D (in
>>> terms of overhead) additional piece
>>>
>>>                         of information to use conjunctively with a
>>> =E2=80=9Creal=E2=80=9D metric.
>>>
>>>
>>>
>>>                         The only practical solution would be to
>>> re-introduce these functions by way of inserting a
>>>
>>>                         MessageTLV =E2=80=94 which (i) is not specified=
 in this
>>> document, and (ii) which would just
>>>
>>>                         serve to render messages bigger than strictly
>>> needed.
>>>
>>>
>>>
>>>                         Scope limited flooding  does seem to be a
>>> necessary requirement, if for no
>>>
>>>                         other reason than to prevent information from
>>> =E2=80=9Ccirculating forever in the network=E2=80=9D.
>>>
>>>
>>>
>>>             o          *It makes end-to-end authentication
>>> unnecessarily hard.*
>>>
>>>                         I think Chris called this out already, but it
>>> bears repeating: S generates a message
>>>
>>>                         (say, a RREQ), and includes an ICV calculated
>>> over the content of the message.
>>>
>>>                         For any recipient to be able to validate the
>>> ICV, the message has to be exactly
>>>
>>>                         the same =E2=80=94 not just in content, but in =
structure
>>> =E2=80=94 as what was generated.
>>>
>>>
>>>
>>>                         =E2=80=9CRegenerating=E2=80=9D rather than =E2=
=80=9Cforwarding=E2=80=9D messages
>>> means, that the intermediate
>>>
>>>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ =
may chose a
>>> different structure (e.g., include TLVs
>>>
>>>                         in a different order).
>>>
>>>
>>>
>>>                         The proposal from
>>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>>>
>>>                         is to add constraints on (i) the set of element=
s
>>> to include in a signature and (ii) the
>>>
>>>                         order of these elements.
>>>
>>>
>>>
>>>                         One problem with that approach is (i): if an
>>> extension adds a message TLV, or an
>>>
>>>                         Address TLV, to a message, then that will not b=
e
>>> =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>>>
>>>                         Rather for *each* extension developed, an
>>> =E2=80=9Cupdates e2esec=E2=80=9D clause needs to be done.
>>>
>>>
>>>
>>>                         I=E2=80=99d say that this approach would be pro=
ne to
>>> errors =E2=80=94 and add entropy to the process
>>>
>>>                         of designing protocol extensions. The
>>> alternative, a message being generated by the
>>>
>>>                         source and *forwarded* (as we do in OLSRv2, for
>>> example) would allow ICV TLVs
>>>
>>>                         (even, allow reuse of those specified for
>>> OLSRv2) for covering a message and
>>>
>>>                         extensions.
>>>
>>>
>>>
>>>                         =E2=80=9CBut what about the metrics value which=
 will
>>> change on each hop=E2=80=9D, you may say?
>>>
>>>                         Fortunately, that is relatively easy to handle:
>>> simply zero out the value of that TLV when
>>>
>>>                         generating or verifying the ICV MessageTLV. And
>>> use Packet-TLVs for hop-by-hop
>>>
>>>                         authentication, if needed (but, see below).
>>>
>>>
>>>
>>>             o          *It prevents the use of more clever/advanced
>>> signature schemes/ICVs*
>>>
>>>                         Aggregate signature algorithms (
>>> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>>>
>>>                         exist, and an interesting use-case can be found
>>> in also reactive protocols, allowing verifying
>>>
>>>                         not =E2=80=9Cjust=E2=80=9D the end points, but =
also the
>>> intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D
>>>
>>>                         discussed above, or something smarter).
>>>
>>>                         Regeneration of messages, rather than
>>> forwarding, renders that impossible (or, if used,
>>>
>>>                         updating to
>>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>>>
>>>
>>>
>>> There are other reasons, but the above are those that jump at me as
>>> immediate show-stoppers.
>>>
>>>
>>>
>>> I do honestly not see what possible benefit there is from =E2=80=9Crege=
neration=E2=80=9D
>>> =E2=80=94 but I see very clear inconveniences, and security is not the =
least of
>>> these. Insisting on =E2=80=9Cregeneration=E2=80=9D requires development=
 of =E2=80=9Cnon-general
>>> workarounds=E2=80=9D as pointed out above.
>>>
>>>
>>>
>>> *Security Considerations*
>>>
>>> This is an always thorny subject. When OLSRv2 was going through the
>>> process we got a thorough education in how little we knew about securit=
y
>>> from the SEC-ADs, and had to spend about a year or so developing RFC718=
3.
>>> The bottom line is, that this protocol needs its =E2=80=9CRFC7183  equi=
valent=E2=80=9D,
>>> either as part of the main document, or as an independent document.
>>> currently, that is not the case.
>>>
>>>
>>>
>>> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration from=
 RFC7183
>>> might be aw good idea, as that was the most recent that went through th=
e
>>> SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to implement=
=E2=80=9D security
>>> mechanism most be specified (I think the right term was =E2=80=9CMUST i=
mplement,
>>> SHOULD use=E2=80=9D), in sufficient detail to ensure interoperable impl=
ementations.
>>>
>>>
>>>
>>> As an example, both [RFC6130] and [RFC7181] set out that that:
>>>
>>>
>>>
>>>       On receiving a ... message, a router MUST first check if the
>>>
>>>       message is invalid for processing by this router
>>>
>>>
>>>
>>> and then proceed to give a number of conditions that, each, will lead t=
o
>>> a rejection of the message as "badly formed and therefore invalid for
>>> processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That g=
ave a =E2=80=9Chook=E2=80=9D for
>>> RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message gen=
eration.
>>>
>>>
>>>
>>> If I was to do RFC7181/RFC6130 today, I would include that directly int=
o
>>> the protocol specifications. It turned out to be more overhead (and slo=
w
>>> down publication anyways) to do it as separate documents.
>>>
>>>
>>>
>>> Secondly, we need to be a lot more rigid in terms of what ICVs,
>>> Timestamps, etc. are added/removed, and what that brings.
>>>
>>>
>>>
>>> For example (with the assumption that messages are *forwarded* and *not=
*
>>> regenerated), this could be one option:
>>>
>>>
>>>
>>>                         o          When a RREQ, RREP message is
>>> generated, add an ICV Message TLV, which is calculated 
>>>
>>>                                      =E2=80=A6(take inspiration from RF=
C7183
>>> here)
>>>
>>>
>>>
>>> ...
>>>
>>> [Message clipped]
>>> _______________________________________________
>>> 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
>>>
>>>
>>>
>>> ********************************************************************
>>> 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
>
>

--94eb2c123f7cf93ecc053150ea5d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Apr 25, 2016 at 11:29 AM, Jiazi YI <ietf@jiaziyi.com> wro=
te:
Hi,=C2=A0

Maybe=
 I missed a bit here:=C2=A0

If only the desired re=
ceiver of the multicast RREP (carrying a destination address) can reply to =
the multicast RREP, why not using unicast directly?

Because the link isn't yet known to be bi-directio=
nal and a unicast route can't be installed yet.

Justin
=C2=A0
best

Jiazi
On Mon, Apr 25, 2016 at 4:59 PM, Victoria Merci=
eca <vmercieca0@gmail.com> wrote:
Hi Chris,


On Mon, Apr 25, 2016 at 3:51 PM, Dearlove, Christopher (UK) <=
span dir=3D"ltr"><chris.dearlove@baesystems.com> wrote:











I has to go back to Victoria=E2=80=99s summa=
ry here. It says:


=C2=A0


2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).


=C2=A0


That doesn=E2=80=99t actually indicate if th=
at=E2=80=99s C=E2=80=99s address or B=E2=80=99s address being included. I=
=E2=80=99d assumed it was C=E2=80=99s address. Your comment makes sense if =
it=E2=80=99s B=E2=80=99s address.
 Reading again, I think you=E2=80=99re probably right. But only probably. C=
an we confirm that.


=C2=A0

C creates the RREP. The included AckReq address is=
 B's address. The RREP then gets multicast.
B receives it=
, sees that it own address is marked as the AckReq address, and sends an ac=
k unicast back to C. 
Anyone else who receives the multicast RREP from C=
 does not send the Ack, since the AckReq address does not match any of thei=
r interface addresses.
=C2=A0
<=
span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73=
,125)">


I assume you meant that the RREP (not RREP_A=
ck) is multicast. There=E2=80=99s a bit of a chicken and egg problem here. =
We do know how we want to unicast.
=
=C2=A0
The RREP is multicast (when we dont know if the link is bi=
directional), the RREP_Ack is always unicast. 

Kind regar=
ds,
Vicky.

=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:
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 Intelligence 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: 25 April 2016 15:26

To: Thomas Heide Clausen

Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc =
Networks mailing list; Victoria Mercieca

Subject: Re: [manet] Message integrity and message mutability (was R=
E: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)=



=C2=A0




=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether =
you should click on any links, open any attachments or reply.
For information regarding <=
/span>
Red Flags that you can look out=
 for in emails you receive,
 click 
here.

If you feel the email is su=
spicious, please follow

this process.








The address in the RREP_Ack may be required due to t=
he RREP_Ack being multicast as there is not yet a verified unicast route in=
stalled yet.=C2=A0 Going to double check if I'm remembering correctly.=
=C2=A0



Justin






=C2=A0




On Mon, Apr 25, 2016 at 10:18 AM, <ietf@thomasclausen.org>=
; wrote:




Hi,




=C2=A0






I must admit that while I have reviewed the protocol=
 several times, I=E2=80=99ve not been digging that deep into the protocol f=
unctioning to catch this issue of how invasive the protocol operations are =
when forwarding a message: there were other
 =E2=80=9Cmajor=E2=80=9D issues to address (and which obscured the details)=
, so as a first order: thank you Victoria, for having called attention to t=
his.






=C2=A0






To the substance of these emails.






=C2=A0






I am afraid that I do not understand the use of inse=
rting validity TLVs while in-flight, into a message. Actually, I am dubious=
 for both the originator inserting this (how can the originator of a messag=
e know how =E2=80=9Clatter parts of the path=E2=80=9D
 will be have=E2=80=9D) except if we are talking duty-cycling of devices an=
d inserting =E2=80=9Cthe remaining time that I am going to be up before I s=
uspend=E2=80=9D. Intuitively, that would also assume fairly long duty cycle=
s =E2=80=9CI am up for tens of seconds=E2=80=9D, which I am not sure are
 actually realistic. And, as Chris says in another email, this is trading o=
ff =E2=80=9Cthe ability to do security=E2=80=9D for an unknown/untested fea=
ture =E2=80=94 which I think is the wrong trade-off.






=C2=A0






On he topic of =E2=80=9Cneeding to put an address in=
=E2=80=9D for RREP-ACK, I must admit that this seems roundabout. I can see =
three issues here:






=C2=A0






o I am not sure that adding an address vs. a flag ma=
y not have to do with the =E2=80=9Cmultiple interfaces/






multiple addresses=E2=80=9D discrimination mechanics=
 of the protocol? I haven=E2=80=99t worked it through, though,=C2=A0=







but that would be a guess.






=C2=A0






o The end-to-end topology diffusion mechanism should=
 not need to be concerned with the=C2=A0






=E2=80=9Cbidirectionally check=E2=80=9D of a local l=
ink (in part, as it encumbers security, but not only).=C2=A0 In short, a=







flag or an address, both are (equally) bad.






=C2=A0






o A cleaner mechanism would be a =E2=80=9Chello mech=
anism=E2=80=9D, not necessarily as NHDP, but a =E2=80=9Cwhen=C2=A0






forwarding a RREQ/RREP, trigger a 3-way hello exchan=
ge, if the link is estimated to be of a=C2=A0






type which potentially can be=C2=A0unidirectional=E2=
=80=9D. There is another benefit to doing that, see the end=C2=A0=







of this email.






=C2=A0






Either way, I do not like the notion of fusing metri=
cs-and-link-bidirectionality-detection any more than I like fusing global-t=
opology-diffusion-and-link-bidirectionality-detection.=C2=A0<=
/p>





=C2=A0






The solution all this is, to me, threefold=







=C2=A0






1) Factor out the bidirectionally check in a (trigge=
red) neighbour detection mechanism=C2=A0






(triggered HELLO message)






=C2=A0






2) Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, =
since they add complexity for no perceivable benefits






=C2=A0






3) Use the security model that we=E2=80=99ve discuss=
ed previously, where (only) the metrics change per hop.






=C2=A0






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 related issue, as I hinted previously.





=C2=A0








The abs=
tract states that the protocol:






=
=C2=A0






=C2=A0=C2=A0 ...is intended for use by mobile routers in wireless, mul=
tihop


=C2=A0=C2=A0 networks.




=
=C2=A0






Section=
 5 paragraph 4 =C2=A0of the document, however, reads:<=
/pre>





=
=C2=A0






=C2=A0=C2=A0 Assuming link metrics are symmetric, the cost of the rout=
es installed


=C2=A0=C2=A0 in the Local Route Set at each router will be correct.=C2=
=A0 While this


=C2=A0=C2=A0 assumption is not always correct, calculating incoming/ou=
tgoing


=C2=A0=C2=A0 metric data is outside of scope of this document. =





=C2=A0








I do not know of any wireless systems,=
 where the assumption that =E2=80=9Clink metrics are symmetric=E2=80=9D act=
ually holds. Consequently, the conclusion in the quoted paragraph:






=C2=A0


=C2=A0=C2=A0 calculating incoming/outgoing


=C2=A0=C2=A0 metric data is outside of scope of this document.<=
u>




=C2=A0








Is not an acceptable design choice.





=C2=A0






While this protocol may not want to =E2=80=9Ccalcula=
te if for this link the metrics is 4 or 5=E2=80=9D, the protocol must be ab=
le to convey and distinguish that =E2=80=9Cthe metric from A to B is 4, and=
 the metric from B to A is 19=E2=80=9D.






=C2=A0






This is a =E2=80=9Crelated issue=E2=80=9D since the =
solution may (as with the bi-directionality check) be in the triggered neig=
hbour detection mechanism: that exchange could, if designed carefully, be u=
sed to probe for and convey metrics information, also.






=C2=A0






Hope this helps,






=C2=A0






=C2=A0






Thomas






=C2=A0












On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK)=
 <chr=
is.dearlove@baesystems.com> wrote:




=C2=A0








Assuming for the moment that everyone will n=
eed an RREP-Ack or won=E2=80=99t (let=E2=80=99s come back to that) why do C=
 and B need to put an address in as an RREQ-Ack request?
 Why not a flag, because the address will be included as the IP sending add=
ress - and we know 5444 is required to pass that on. (It=E2=80=99s used by =
NHDP as well.) Then we don=E2=80=99t need to change the RREP, it will have =
a flag set or not, and won=E2=80=99t change (in this regard).=







=C2=A0






Now let=E2=80=99s consider do we know whethe=
r we can set a fixed flag. First I=E2=80=99d say there are two cases - you=
=E2=80=99ve got a firm control on what=E2=80=99s going on in your network,
 or it=E2=80=99s one of unknown parties and behaviour (consistent with spec=
ification). In the former case you only want one setting, for example no-Ac=
k if running NHDP or your MAC layer tells you about bidirectionality, Ack o=
therwise. In the latter case, I think you
 just always want an Ack. So both cases get you to the same place.






=C2=A0






Should that not be an acceptable argument (t=
hough I think it=E2=80=99s good for where we are - in fact always Ack is cl=
ose) then at flag is a step better, it=E2=80=99s a fixed
 location to change. However it would be better in that case if the two thi=
ngs to change (metric and ack flag) were together. But that has its own iss=
ues, so I won=E2=80=99t go there.






=C2=A0




--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44 (0)1245 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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






From:=C2=A0Victoria Mercieca [mailto:vmercieca0@gmail.com]=C2=A0

Sent:=C2=A025 April 2016 14:15

To:=C2=A0Jiazi YI

Cc:=C2=A0Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad=
 Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)






=C2=A0






=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om 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=C2=A0tha=
t
 you can look out for in emails you receive, click=C2=A0here.

If you feel the email is su=
spicious, please follow=C2=A0this
 process.








Hi Jiazi,










=C2=A0








On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <ietf@jiaziyi.com> wrote:








Hi,=C2=A0








=C2=A0








On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christop=
her (UK) <chris.dearlove@baesystems.com&=
gt; wrote:










With regard to your validity time point, we =
here have a tradeoff. If you allow that feature, it significantly impacts o=
n the approach that was coming together
 on as best you can end to end encryption.






=C2=A0






So the question is, is this a feature that=
=E2=80=99s really wanted? Unfortunately I think we know that the answer to =
that is, we don=E2=80=99t know because we don=E2=80=99t have any
 experience. My view would be that in the tradeoff of an untested feature (=
unless I=E2=80=99m wrong about that) and the security complication, securit=
y wins and drop the feature. If there is some real requirement, then there=
=E2=80=99s a discussion. (Questions like how often
 the intermediate routers actually have any knowledge - typically links bre=
ak for unexpected rather than expected reasons. Andan intermediate router c=
ould possibly use a validity time to influence its behaviour.) Note that dr=
opping the ability of intermediate
 routers to modify/set still allows validity times per route to be set at e=
ndpoints.












=C2=A0










I agree with Chris' concern.










The ValidityTime is optional, which makes the integr=
ity protection hard. Furthermore, it gives a potential attack vector: as al=
l the routers in a path will take the shortest validityTime, a compromised =
router can set the the validityTime
 to a very short value, which will make the route installed along the path =
became invalid (very soon).=C2=A0










=C2=A0










On the other hand, I'm not sure this option will=
 give us much help. Chris mentioned much knowledge intermediate router woul=
d have to decide this value (and how much sense the value would make).=C2=
=A0










Another issue is, a route to a destination might be =
updated by different sources. For example, in the network below:<=
/u>










=C2=A0










A-=
---B-----C










=C2=A0










A first establish a route to B with long validity ti=
me. Then A initiates a route discovery to C. C tends to set a short validit=
y time, which will make the route between B and A expire earlier than expec=
ted.=C2=A0










Is this a problem? Maybe yes, maybe no -- I'm no=
t sure it's considered or not.=C2=A0










=C2=A0
















=C2=A0








Not sure I follow here.=







Currently, the validity=
 time of the route between A and B would not affected by a short validity t=
ime of a route between A and C. Validity times are per-route, and the route=
 A-B and the route A-C are separate.








If we switched to a validity time per neighbor (so t=
hat we can keep validity time separate from route advertisements) as I ment=
ioned in the email below, then the validity of a route between A and C woul=
d be affected if there was a short
 validity time between A and B. But, if B will only route for a certain amo=
unt of time, then the route between A and C will of course be affected. Is =
it best to know in advance that there's a time limit, or just deal with=
 RERRs when they happen?








=C2=A0







=C2=A0






















=C2=A0






With regard to the acknowledgements, the pro=
blem (with regard to security) comes from trying to do two jobs with the sa=
me message - end to end route advertisement
 and hop by hop acknowledgement. I understand the reasons - saving bytes an=
d message types. (I would have to study the protocol really hard to identif=
y if any message types can be folded together and recognised by content rat=
her than type efficiently. This
 I do not expect to do.) Again a tradeoff. This one is in discussion space,=
 though that needs people who understand both sides of the issue, including=
 the details of the bidirectionality mechanism. Of course, as has been said=
, we need one of those.














=C2=A0










I haven't finished my review of the latest draft=
, and I don't get the necessity of AckReq and the corresponding multica=
st RREP yet.=C2=A0










If possible, this "optional" field should =
be avoided.=C2=A0










=C2=A0


















To give an overview of AckReq and RREP:






Since AODVv2 requires b=
idirectional links, this is the way to determine if a link is bidirectional=
.








A----B----C












1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install a=
 route to OrigAddr but they dont yet know if it's valid because they do=
nt know if the link to their next hop is available in the reverse direction=
.










2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).










3) B receives the RREP, installs a route to TargAddr=
 and marks it as valid, since it knows the link to C is bidirectional, beca=
use the RREQ went in one direction and the RREP came in the other. B also s=
ends the RREP_Ack to C and forwards
 the RREP to A (and might change the message to indicate its own AckReq - i=
e that it requires an ack from A).










4) C receives the RREP_Ack from B, and therefore kno=
ws that B received the RREP, therefore the link is bidirectional. C can the=
n mark its route to OrigAddr as valid.










5) Similarly, A receives the RREP, installs the rout=
e to TargAddr and sends an RREP_Ack to B.










6) B receives the RREP_Ack and marks its route to Or=
igAddr as valid.










=C2=A0








Alternatively, in step =
2, if C knows the link to B is bidirectional (perhaps from some earlier rou=
te discovery), it doesnt need to put the AckReq in the RREP. Then in step 3=
, since B doesnt know if the link
 to A is bidirectional, it changes the message to add the AckReq address, i=
n order to get an RREP_Ack from A.






If we want to avoid cha=
nging the message, we'll need to look at forwarding the RREP as-is, and=
 creating a second message to solicit an RREP_Ack, in order to verify that =
the link is bidirectional before marking
 the route to OrigAddr as valid.=C2=A0








Kind regards,










Victoria.








=C2=A0







=C2=A0


















regards










=C2=A0










Jiazi










=C2=A0














=C2=A0




--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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






From:=C2=A0Victoria Mercieca [mailto=
:vmercieca0@gmail.com]=C2=A0

Sent:=C2=A023 April 2016 10:55

To:=C2=A0Christopher Dearlove

Cc:=C2=A0ietf@thomasclausen.org; Dearlove, =
Christopher (UK); Mobile Ad Hoc Networks mailing list<=
/p>











Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=C2=A0






=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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.










Hi Chris,








=C2=A0










These have both been in the draft in some form since=
 before I got involved... but I'll do my best to explain.=









=C2=A0










- For Validity Time, its a way to advertise that you=
 would only support the route contained in the message for a certain period=
 of time. The originator might use this, but the draft was written to allow=
 any intermediate node to be able
 to add it or update it too. The route created in the Local Route Set has a=
n expiration time associated with it, based on the received validity time.<=
u>










- For the AckReq address, its so that you can add in=
to a RREP a request for an acknowledgement, so that you don't have to h=
ave a different message type altogether for working out whether links to ne=
ighbors are bidirectional, and also, since
 you only care about bidirectionality on routes that are being set up, you =
dont need to constantly monitor all neighbors.










=C2=A0










=C2=A0










In order to avoid the potential AckReq-related chang=
es to each message, maybe we do need to introduce a different message speci=
fically for this. We could maybe use RREP_Ack to both request and acknowled=
ge? It means an extra message of control
 traffic that needs to be sent, maybe one extra message per hop on the path=
 of a RREP, but it could still be limited to neighbors which have participa=
ted in the route discovery rather than monitoring all neighbors at all time=
s.=C2=A0










=C2=A0










This message could maybe also include "I'm =
happy to route anywhere for a certain amount of time", sort of like wi=
llingness in OLSR/OLSRv2. So instead of having a validity time per route, i=
ts a validity time per neighbor. Then, for RREQ
 and RREP, only the metric value would change in transit, as discussed. How=
ever, that leads to some issues with deciding what a route's expiration=
 time is. You might know how long the next hop router is valid for, but wha=
t if a router beyond that, which was
 also part of the route, had a lower validity time? You couldn't determ=
ine the real validity time. Do we remove the route expiration time altogeth=
er to avoid this issue? In which case, we would have to rely on RERR messag=
es being sent for routes which become
 invalid when the neighbor's validity time has expired? So neighbor val=
idity time expiration is treated the same as a link break.









=C2=A0










What do you think?










=C2=A0










Kind regards,










Victoria.










=C2=A0










=C2=A0










=C2=A0










=C2=A0










=C2=A0












=C2=A0








On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlov=
e <chris@mnemosyne.demon.co.uk> wrote:<=
u>










Pretty much all of the discussion has been assuming =
only a metric value change. With multiple things changing many of the ideas=
 go out of the window. That reinforces the point about not making specifica=
tions now that might turn out to be
 wrong for ICVs.










=C2=A0










Ignoring how this misunderstanding happened, I'l=
l start by asking why. Metric changing I understand. Why the other two? (th=
ere's a partial explanation of one). What alternatives have people impl=
emented in comparable protocols?



-- =C2=A0








Christopher Dearlove














On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmai=
l.com> wrote:


















Hi all,










=C2=A0










Continued in this thread because the other one seems=
 to be more about TLV types and metric type numbers, whereas this is about =
regeneration/forwarding.










=C2=A0










To recap, in the current draft, there are 3 things t=
hat might change at each hop:=C2=A0

- the metric value (happens in RREQ and RREP),=C2=A0

- adding/changing Validity Time using the Validity Time TLV (can happen in =
RREQ and RREP),=C2=A0

- adding an address (and corresponding value in the AddressType TLV to indi=
cate how to interpret the address) to indicate the address from which an RR=
EP_Ack is expected, to accomplish the bidirectionality check (can happen in=
 RREP).



If we define=C2=A0a certain portion of the message as immutable and include=
 the ICV to verify that part, end to end:=C2=A0

- The metric value would be excluded from the ICV since it needs changing a=
t each hop.=C2=A0

- Would adding a Validity Time TLV at an intermediate hop be acceptable? Th=
e whole TLV could be removed in order to calculate the ICV?







- Would adding an address cause issues for the ICV, =
because it's in the address block? Could the rule be "if it contai=
ns an AckReq address, remove it (and the corresponding value in the Address=
Type TLV), before checking the ICV", is that
 OK? Or would we need to avoid touching the ICV'ed part of the message =
altogether, maybe put the AckReq address in a separate Address Block, with =
an extra AddressType TLV following that address block? Is there a way to ac=
complish this?










=C2=A0










Also, to be thorough, do we need to consider RERR me=
ssages while we discuss regeneration vs forwarding?=C2=A0










- RERR (sent when a link breaks) is a way of saying =
"I've lost my route so I'm telling others" and "you =
were my next hop, so=C2=A0now=C2=A0I've also lost my route, I'll te=
ll others", etc. It's going to be tailored at each step to include=
 the relevant
 routes that got deleted, it's not one message being sent end-to-end li=
ke RREQ and RREP are.=C2=A0










- However, RERR (sent when a source of traffic is se=
nding data on a route which comes through you, and you want to tell the Pac=
ket Source's router to delete the route) could be seen as an end-to-end=
 message which all intermediate routers
 learn from, similar to RREQ and RREP. It reports one route, and doesn'=
t need changing at intermediate hops, so could be protected with ICV.










- Would it be OK to only require a message ICV if a =
PktSource address was included, i.e. when the message needs to go via a num=
ber of intermediate hops to PktSource's router? All other RERRs are int=
ended to be one-hop messages, which may
 in turn prompt other one-hop messages, etc..., and a packet ICV might be m=
ore appropriate?










=C2=A0








Kind regards,








Victoria.










=C2=A0








On Thu, Mar 17, 2016 at 5:26 PM, <i=
etf@thomasclausen.org> wrote:








=C2=A0












On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:








=C2=A0












Yes, I meant AODVv2, thanks for the catch.










=C2=A0










So is your (Thomas) proposed base specificat=
ion a hop count only metric?
















=C2=A0








No, the would be silly as base specification, given =
that hop count mostly is useless.










=C2=A0










As base specification I would simply say =E2=80=9CIn=
clude a Metric Type Message TLV with a value field, and a 7182 Message TLV =
& Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage =
as to generation and processing).=C2=A0










=C2=A0










With the message generated by the originator of the =
RREQ/RREP and *not* deconstructed/reconstructed/reordered (as is the risk w=
ith =E2=80=9Cregeneration) allows knowing that it would be *only* that metr=
ic field being modified (other than hop count/limit)
 for when eventually writing up the extension.










=C2=A0
















(Actually doesn=E2=80=99t the current specif=
ication only define hop count, or has that changed in latest draft?)=















=C2=A0








No. That is one of the issues I raise in my original=
. For some reason, it cites RFC6551, which is a ROLL document and which has=
 in its abstract that:










=C2=A0








=C2=A0=C2=A0 Low-Power and Lossy Networks (LLNs) have unique character=
istics


=C2=A0=C2=A0 compared with traditional wired and ad hoc networks that =
require the


=C2=A0=C2=A0 specification of new routing metrics and constraints. =







=C2=A0










I.e. this document cites a metric document which cle=
arly claims to be inapplicable in ad hoc networks. I note that this is anot=
her thing I=E2=80=99ve raised for years without seeing it attempted resolve=
d.










=C2=A0










Best,










=C2=A0










Thomas










=C2=A0










=C2=A0














=C2=A0








--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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














From:=C2=A0ietf@thomas=
clausen.org=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 17:10

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Lotte Steenbrink; Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=C2=A0








=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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=A0
















On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:












=C2=A0














OK, so we have a message that mutates by:














- Modifying hop count/limit.














- Modifying a metric value.=















Anything else?














=C2=A0














As mutating (other than hop count/limit) mes=
sages aren=E2=80=99t covered by 5444 or any derivative document (but only r=
ecommended against, not banned) that you may
 need to make the message otherwise immutable (no deconstruction and rebuil=
ding, other than guaranteed unchanging) that would have to be specified by =
AODVv2. (Easy to say, but needs saying.)


















=C2=A0












With you so far.












=C2=A0









Then that information is not in a guaranteed=
 fixed location given by a simple offset. So any signature algorithm that f=
inds it and ignores it or aggregates
 on it is specific to OLSRv2.














=C2=A0












Surely you mean AODVv2












=C2=A0









So standard 7182 ICVs don=E2=80=99t do the j=
ob, you would need an AODVv2 specialised variant. Which is the sort of thin=
g that the message specific TLV space is there
 for, I=E2=80=99d be strongly against a =E2=80=9Cbut ignore the value of th=
is specific TLV should it occur=E2=80=9D being in the general space. Howeve=
r it can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like =
that TLV, except if an X TLV is present, set its value field to
 zero=E2=80=9D).














=C2=A0














Messy, but could work.<=
/p>













=C2=A0












Not that messy, actually, although clearly not as ni=
ce as =E2=80=9Cfixed offset=E2=80=9D.














=C2=A0














That said, I am arguing for the base spec being:<=
/u>














=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=E2=80=9Cmake the message otherwise immutable (no deco=
nstruction and rebuilding, other=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=A0than guaranteed unchanging)=E2=80=9D which is af=
forded by forwarding














=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7182 Timestamps and ICVs.














=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7183 style text bringing it all together.=















=C2=A0














The =E2=80=9Caggregated signatures around mutable fi=
eld=E2=80=9D would very be an experimental extension.














=C2=A0














What I object to is, if the base spec specifically r=
enders such extensions impossible














=C2=A0












=C2=A0









=C2=A0










--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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


















From:=C2=A0Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]=C2=A0

Sent:=C2=A017 March 2016 16:48

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0ietf@thomasclausen.org; Mobile Ad =
Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)


















=C2=A0










=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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.












Hi all,
















=C2=A0




















Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher=
 (UK) <chris.dearlove@baesystems.com>=
:
















=C2=A0


















Good point about whether you just pass on on=
e cost or a set of costs. As I said, not looked at details - I will, when t=
ime permits. One cost is much easier,
 and yes, it reduces the fixed size aggregated signatures problem to =E2=80=
=9Cjust=E2=80=9D one of computational load.






















=C2=A0


















For the record, Thomas=E2=80=99 understanding is cor=
rect; the cost is one aggregated value.=C2=A0


















=C2=A0


















Best regards,=C2=A0


















Lotte Steenrbink














=C2=A0















=C2=A0












--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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






















From:=C2=A0ietf@thomas=
clausen.org=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 16:38

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: Message integrity and message mutability (was RE: =
[manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)






















=C2=A0












=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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=A0
























On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:




















=C2=A0






















I appreciate Thomas=E2=80=99s comments about=
 the limitations of message regeneration, but I would be a bit less absolut=
e.






















=C2=A0






















The issues over end to end authentication an=
d more advanced signatures are valid. I need to read the given reference on=
 aggregate signatures to increase my
 knowledge (thanks for it), but my understanding of the possibilities in th=
is field may offer a solution to the problem, but with some other issues (p=
ossibly including a new type of TLV).






















=C2=A0






















But the hop count/limit point I don=E2=80=99=
t fully agree with, you can regenerate with an incremented/decremented coun=
t/limit, which leaves the ability to prevent
 messages propagating indefinitely, including expanding ring searches, and =
retains the ability to use RFC 5497 interval and validity times that might =
be useful with an expanding ring search (or might not).






















=C2=A0






















But the key issue is that AODVv2 wants to ac=
cumulate metrics. I still haven=E2=80=99t got to the bottom of many details=
 here, but let=E2=80=99s for the moment just consider
 that conceptually.






















=C2=A0






















It=E2=80=99s hard to handle end to end. Char=
lie=E2=80=99s draft attempts to do an end to end of some information, not t=
his information. I=E2=80=99m not sure if that=E2=80=99s useful (and the
 specialised format is better avoided if possible). Other approaches are ho=
p by hop (might as well use packet signatures) and shared key (might as wel=
l go hop by hop). Pairwise signatures for each pair of routers I=E2=80=99m =
discounting as scaling terribly. In the
 interests of completeness let=E2=80=99s mention not accumulating metrics, =
which puts us back to hop count and that=E2=80=99s not ideal either.=























=C2=A0






















I don=E2=80=99t think there is an ideal solu=
tion. (I like ideas I=E2=80=99ve seen about aggregating, but that has some =
issues of its own, even apart from computational load.)
 I=E2=80=99d love to be proved wrong - someone with the perfect solution to=
 come along.






















=C2=A0






















Which means that either we make an arbitrary=
 choice - which will be disagreed with, but needs discussing first - or cre=
ate something flexible. Unfortunately
 flexible in that regard constrains in others, e.g. some (many? most?) aggr=
egating signatures need fixed data sizes (which we can do by defining a TLV=
 that =E2=80=9Cfills up=E2=80=9D with hop count, but that has a cost too).<=
/span>


























=C2=A0




















I have been told by people much more well versed in =
this than I in cryptology, that the correct answer is =E2=80=9Csome=E2=80=
=9D.






















=C2=A0






















That said, "AODVv2 wants to accumulate metrics=
=E2=80=9D =E2=80=94 does that mean that the message grows as it is being fo=
rwarded, and that the recipient of a RREQ/RREP will know the individual cos=
ts of each path segment? My understanding is, that the recipient
 will get =E2=80=9Cthe sum the costs of each path segment=E2=80=9D which sh=
ould be fitting within a fixed size?






















=C2=A0






















Thomas






















=C2=A0




















=C2=A0



















=C2=A0






















Sorry, no answers, just comments. And I=E2=
=80=99m not addressing Thomas=E2=80=99s later points here.=























=C2=A0














--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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


























From:=C2=A0manet [mail=
to:manet-bounces@ietf.org]=C2=A0On
 Behalf Of=C2=A0ietf@thomasclausen.org

Sent:=C2=A017 March 2016 16:00

To:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0[manet] draft-ietf-manet-aodvv2-13 review - a couple o=
f big ticket Items


























=C2=A0














=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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***

EXTERNAL=
 EMAIL -- This message originates from outside our organization.<=
/u>














=C2=A0
























Dear all,
























=C2=A0


























Apologies for not having gotten this done sooner - d=
ay-job leaving few spare cycles.


























=C2=A0


























I=E2=80=99ve previously offered reviews and comments=
, and some of those have been addressed in the latest I-D =E2=80=94 others =
have not, but should be. I recall that there was some mail attempting to re=
but parts of the review, and I will dig it out and
 reply to that.


























=C2=A0


























With that being said, I have reviewed the latest ver=
sion of the document, and full details will be forthcoming. There=E2=80=99r=
e a couple of big-ticket/architectural items that I want to address up fron=
t, as I believe that before we have those
 hammered out, it will be useless to go into details. Note, I do not claim =
that this is an exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D, but =
that=E2=80=99s as far as I have gotten in thinking this through.<=
/u>


























=C2=A0


























I also bring these up as they are items that have be=
en brought up repeatedly over the past years, but not resolved nor discusse=
d.


























=C2=A0


























Loops


























Just to bring this out: I share Chris=E2=80=99 worry=
 about conflicting and concurrent statements from the authors on =E2=80=9CT=
here are no loops possible=E2=80=9D and =E2=80=9CWe need to fix two situati=
ons where loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating =
some loop
 conditions=E2=80=9D


























=C2=A0


























I particularly worry that this is not a discussion h=
ad in public, but apparently in some other forum=E2=80=A6


























=C2=A0


























=C2=A0




























Intermediate Route Replies, and all of section=
 10


























Section 10 contains a set of =E2=80=9Cvaguely specif=
ied extensions=E2=80=9D, which is incoherent with the intended status indic=
ated for this document.=C2=A0


























=C2=A0


























Specifically, and this is not unrelated to the point=
 about loops above, intermediate RREPs (section 10.3) are a potential sourc=
e for loops.


























=C2=A0


























Expanding Ring Multicast (section 10.1) is not docum=
ented in a way that can be implemented (and also, see =E2=80=9CForwarding-v=
s-regeneration=E2=80=9D below, it is in the present form of this protocol i=
mpossible), etc.




























=C2=A0


























=C2=A0


























Forwarding-vs-regeneration


























Recent exchanges on the list made me understand that=
 protocol control messages are *not* forwarded, but are consumed at each ho=
p, then a new message with (almost-but-not-quite) the same content is gener=
ated and transmitted.


























=C2=A0


























I have thought some more on this (& read some of=
 the exchanges on the list on this topic by Chris, Ulrich, and others), and=
 I am convinced that this is not the right way to go,=C2=A0at least=
=C2=A0for the following reasons:


























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It renders the hop-limit/hop-count fields in the RFC5444 messag=
e header useless.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0This would not be bad if the functionality offered by tho=
se fields was not useful


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=94 sadly, it is. For example, for scope limited fl=
ooding (expanding ring search, and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0such) which may be of interest, and which require hop-lim=
it.=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0A hop-count field may also provide a =E2=80=9Ccheap=E2=80=
=9D (in terms of overhead) additional piece


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of information to use conjunctively with a =E2=80=9Creal=
=E2=80=9D metric.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The only practical solution would be to re-introduce thes=
e functions by way of inserting a


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0MessageTLV =E2=80=94 which (i) is not specified in this d=
ocument, and (ii) which would just


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0serve to render messages bigger than strictly needed.<=
/u>


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Scope limited flooding =C2=A0does seem to be a necessary =
requirement, if for no


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0other reason than to prevent information from =E2=80=9Cci=
rculating forever in the network=E2=80=9D.


























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It makes end-to-end authentication unnecessarily hard.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I think Chris called this out already, but it bears repea=
ting: S generates a message=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(say, a RREQ), and includes an ICV calculated over the co=
ntent of the message.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0For any recipient to be able to validate the ICV, the mes=
sage has to be exactly


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0the same =E2=80=94 not just in content, but in structure =
=E2=80=94 as what was generated.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforwa=
rding=E2=80=9D messages means, that the intermediate


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose =
a different structure (e.g., include TLVs


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0in a different order).


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The proposal from=C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00=



























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0is to add constraints on (i) the set of elements to inclu=
de in a signature and (ii) the


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0order of these elements.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0One=C2=A0problem with that approach is (i): if an extensi=
on adds a message TLV, or an=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Address TLV, to a message, then that will not be =E2=80=
=9Ccovered=E2=80=9D by the proposed e2esec TLV.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Rather for *each* extension developed, an =E2=80=9Cupdate=
s e2esec=E2=80=9D clause needs to be done.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I=E2=80=99d say that this approach would be prone to erro=
rs =E2=80=94 and add entropy to the process


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of designing protocol extensions. The alternative, a mess=
age being generated by the


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0source and *forwarded* (as we do in OLSRv2, for example) =
would allow ICV TLVs=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(even, allow reuse of those specified for OLSRv2) for cov=
ering a message and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0extensions.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CBut what about the metrics value which will chan=
ge on each hop=E2=80=9D, you may say?


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Fortunately, that is relatively easy to handle: simply ze=
ro out the value of that TLV when


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0generating or verifying the ICV MessageTLV. And use Packe=
t-TLVs for hop-by-hop=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0authentication, if needed (but, see below).=



























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It prevents the use of more clever/advanced signature scheme=
s/ICVs


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Aggregate signature algorithms (=C2=A0https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf<=
/span>)


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0exist, and an interesting use-case can be found in also r=
eactive protocols, allowing verifying


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0not =E2=80=9Cjust=E2=80=9D the end points, but also the i=
ntermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0discussed above, or something smarter).


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Regeneration of messages, rather than forwarding, renders=
 that impossible (or, if used,


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0updating to =C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)


























=C2=A0


























There are other reasons, but the above are those tha=
t jump at me as immediate show-stoppers.


























=C2=A0


























I do honestly not see what possible benefit there is=
 from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inconve=
niences, and security is not the least of these. Insisting on =E2=80=9Crege=
neration=E2=80=9D requires development of =E2=80=9Cnon-general workarounds=
=E2=80=9D as pointed
 out above.


























=C2=A0


























Security Considerations<=
/p>

























This is an always thorny subject. When OLSRv2 was go=
ing through the process we got a thorough education in how little we knew a=
bout security from the SEC-ADs, and had to spend about a year or so develop=
ing RFC7183. The bottom line is, that
 this protocol needs its =E2=80=9CRFC7183 =C2=A0equivalent=E2=80=9D, either=
 as part of the main document, or as an independent document. currently, th=
at is not the case.


























=C2=A0


























A minima, looking at BCP72 and BCP107 =E2=80=94 taki=
ng inspiration from RFC7183 might be aw good idea, as that was the most rec=
ent that went through the SEC AD. Regardless of how, however, a =E2=80=9Cma=
ndatory to implement=E2=80=9D security mechanism most be specified
 (I think the right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D),=
 in sufficient detail to ensure interoperable implementations.


























=C2=A0


























As an example, both [RFC6130] and [RFC7181] set out =
that that:




























=C2=A0


























=C2=A0 =C2=A0 =C2=A0 On receiving a ... message, a r=
outer MUST first check if the


























=C2=A0 =C2=A0 =C2=A0 message is invalid for processi=
ng by this router


























=C2=A0


























and then proceed to give a number of conditions that=
, each, will lead to a rejection of the message as "badly formed and t=
herefore invalid for processing=E2=80=9D =E2=80=94 a list which RFC7183 the=
n amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting
 =E2=80=9Crejection=E2=80=9D. Idem for message generation.

























=C2=A0


























If I was to do RFC7181/RFC6130 today, I would includ=
e that directly into the protocol specifications. It turned out to be more =
overhead (and slow down publication anyways) to do it as separate documents=
.




























=C2=A0


























Secondly, we need to be a lot more rigid in terms of=
 what ICVs, Timestamps, etc. are added/removed, and what that brings.


























=C2=A0


























For example (with the assumption that messages are *=
forwarded* and *not* regenerated), this could be one option:<=
/p>

























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0When a RREQ, RREP message is generated, add an ICV Message TLV, which=
 is calculated <this way>


























=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=E2=80=A6(take inspiration from RFC7183 here)


























=C2=A0


































...



[Message clipped]=C2=A0=C2=A0

_______________________________________________

manet mailing list

manet@ietf.org

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/manet






=C2=A0
















_______________________________________________

manet mailing list

manet@ietf.org

<=
span style=3D"color:purple">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 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

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/manet








=C2=A0














=C2=A0










_______________________________________________

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




=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





--94eb2c123f7cf93ecc053150ea5d--


From nobody Mon Apr 25 08:42: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 948B312D198 for ; Mon, 25 Apr 2016 08:42:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.093
X-Spam-Level: 
X-Spam-Status: No, score=-1.093 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, TRACKER_ID=1.306] 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 LG8r8VcmB8B8 for ; Mon, 25 Apr 2016 08:42:10 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 BABA412D1AB for ; Mon, 25 Apr 2016 08:42:09 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id 127so24031719wmz.0 for ; Mon, 25 Apr 2016 08:42: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=8EBatMy8dijsnq17fbGk15Kllpyad+W01X5sM8vPIQA=; b=z7q/DoOWWPV1L+VshUcQV3z2AbNJW1DA2ZeeobaSbJopD0V4ombyLtRFE0Taw4FKYd skpAqak56EilrbhFsSXXJBbULWr/qz4f5TiFcTrNcS9haeyVHdc0YxRFvWlk2zEy358v KPIn+0g5Bfy15yC5cM2oMBae1NS1v535LyHGp6SotofC6ye98um+8BygDMJoYAsM0WjF /qKDUx1JJXeKAMaYSiVjYsuARca48V2dJs/B05XoGZtFQye4EAb+yYjRe+n5I1LojxUr e+53ZJc+Q2q7b2Jq/4frxlrmiCtEUD6XpNa7tY4lLlEfQ72XhOrufx6+pSqC1sAxbjfi gQCg==
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=8EBatMy8dijsnq17fbGk15Kllpyad+W01X5sM8vPIQA=; b=DY0X3Ug9R/gtFwDDpbIbsNjHObCoXxGtvLAiV5u5siwXPUuqQ+EmUKt0I86Qth9HH9 f2DjkWvbWMfNgEGaIOxyUPfcVr1zsdhCe/gop6ui1UXZ980V+Bwo2MiAJRMdgNS2NAAf uiE2hs5T9s0vuTM/T/+wmVTB5IgZMz1x5rT8JKsJZJV5YDjjNMPc3et36+dCJ4MDQU5Z KpAFA3DCJYPyDeQMh5k0CG9Mj5ieGKwzwDcr+6IcsIQEOCJwk0wnm+F5/NhsdFjYuooV xxx8z3URtBSJCP7dGbmQx6awYNxpWPsES9dyUQVwtLf3yf0QiLnKShepj1SVrgxbph4r Mk+g==
X-Gm-Message-State: AOPr4FV/svXsVamsTWn3I7jksh6UdHiCkNo0zcCPYvX499DSv7mllviET/1zNj1Br+ocL/qCmYIEiW+Wnedv1Q==
MIME-Version: 1.0
X-Received: by 10.28.113.67 with SMTP id m64mr13599562wmc.58.1461598928087; Mon, 25 Apr 2016 08:42:08 -0700 (PDT)
Sender: yi.jiazi@gmail.com
Received: by 10.194.153.166 with HTTP; Mon, 25 Apr 2016 08:42:07 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org>     
Date: Mon, 25 Apr 2016 17:42:07 +0200
X-Google-Sender-Auth: cehl3kF2HezY4Y6vEXu1PPKaJVg
Message-ID: 
From: Jiazi YI 
To: Justin Dean 
Content-Type: multipart/alternative; boundary=001a1147dab0e9d0ce05315104ec
Archived-At: 
Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 25 Apr 2016 15:42:17 -0000

--001a1147dab0e9d0ce05315104ec
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 25, 2016 at 5:34 PM, Justin Dean  wrote:

> On Mon, Apr 25, 2016 at 11:29 AM, Jiazi YI  wrote:
>
>> Hi,
>>
>> Maybe I missed a bit here:
>>
>> If only the desired receiver of the multicast RREP (carrying a
>> destination address) can reply to the multicast RREP, why not using unic=
ast
>> directly?
>>
>> Because the link isn't yet known to be bi-directional and a unicast rout=
e
> can't be installed yet.
>

Does it matter? I can send a unicast to the next hop anyways: if I didn't
get a RREP-ACK, then it's unidirectional, so that I can blacklist the next
hop.

If I get a RREP-ACK, then it's bidirectional and I can continue to set up
the (bi-directdional) route.

best

Jiazi



>
> Justin
>
>
>> best
>>
>> Jiazi
>>
>> On Mon, Apr 25, 2016 at 4:59 PM, Victoria Mercieca 
>> wrote:
>>
>>> Hi Chris,
>>>
>>>
>>> On Mon, Apr 25, 2016 at 3:51 PM, Dearlove, Christopher (UK) <
>>> chris.dearlove@baesystems.com> wrote:
>>>
>>>> I has to go back to Victoria=E2=80=99s summary here. It says:
>>>>
>>>>
>>>>
>>>> 2) C creates the RREP. Since it doesnt know if the link to B is
>>>> bidirectional, it includes the AckReq (an address to indicate that it
>>>> expects to receive a RREP_Ack from B).
>>>>
>>>>
>>>>
>>>> That doesn=E2=80=99t actually indicate if that=E2=80=99s C=E2=80=99s a=
ddress or B=E2=80=99s address
>>>> being included. I=E2=80=99d assumed it was C=E2=80=99s address. Your c=
omment makes sense if
>>>> it=E2=80=99s B=E2=80=99s address. Reading again, I think you=E2=80=99r=
e probably right. But only
>>>> probably. Can we confirm that.
>>>>
>>>>
>>>>
>>>
>>> C creates the RREP. The included AckReq address is B's address. The RRE=
P
>>> then gets multicast.
>>> B receives it, sees that it own address is marked as the AckReq address=
,
>>> and sends an ack unicast back to C.
>>> Anyone else who receives the multicast RREP from C does not send the
>>> Ack, since the AckReq address does not match any of their interface
>>> addresses.
>>>
>>>
>>>> I assume you meant that the RREP (not RREP_Ack) is multicast. There=E2=
=80=99s a
>>>> bit of a chicken and egg problem here. We do know how we want to unica=
st.
>>>>
>>>
>>> The RREP is multicast (when we dont know if the link is bidirectional),
>>> the RREP_Ack is always unicast.
>>>
>>> Kind regards,
>>> Vicky.
>>>
>>>
>>>>
>>>> *-- *
>>>>
>>>>
>>>>
>>>>
>>>> *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:* 25 April 2016 15:26
>>>> *To:* Thomas Heide Clausen
>>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
>>>> Networks mailing list; Victoria Mercieca
>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** 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
>>>> .*
>>>>
>>>> The address in the RREP_Ack may be required due to the RREP_Ack being
>>>> multicast as there is not yet a verified unicast route installed yet.
>>>> Going to double check if I'm remembering correctly.
>>>>
>>>> Justin
>>>>
>>>>
>>>>
>>>> On Mon, Apr 25, 2016 at 10:18 AM,  wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I must admit that while I have reviewed the protocol several times,
>>>> I=E2=80=99ve not been digging that deep into the protocol functioning =
to catch this
>>>> issue of how invasive the protocol operations are when forwarding a
>>>> message: there were other =E2=80=9Cmajor=E2=80=9D issues to address (a=
nd which obscured the
>>>> details), so as a first order: thank you Victoria, for having called
>>>> attention to this.
>>>>
>>>>
>>>>
>>>> To the substance of these emails.
>>>>
>>>>
>>>>
>>>> I am afraid that I do not understand the use of inserting validity TLV=
s
>>>> while in-flight, into a message. Actually, I am dubious for both the
>>>> originator inserting this (how can the originator of a message know ho=
w
>>>> =E2=80=9Clatter parts of the path=E2=80=9D will be have=E2=80=9D) exce=
pt if we are talking
>>>> duty-cycling of devices and inserting =E2=80=9Cthe remaining time that=
 I am going
>>>> to be up before I suspend=E2=80=9D. Intuitively, that would also assum=
e fairly long
>>>> duty cycles =E2=80=9CI am up for tens of seconds=E2=80=9D, which I am =
not sure are actually
>>>> realistic. And, as Chris says in another email, this is trading off =
=E2=80=9Cthe
>>>> ability to do security=E2=80=9D for an unknown/untested feature =E2=80=
=94 which I think is
>>>> the wrong trade-off.
>>>>
>>>>
>>>>
>>>> On he topic of =E2=80=9Cneeding to put an address in=E2=80=9D for RREP=
-ACK, I must
>>>> admit that this seems roundabout. I can see three issues here:
>>>>
>>>>
>>>>
>>>> o I am not sure that adding an address vs. a flag may not have to do
>>>> with the =E2=80=9Cmultiple interfaces/
>>>>
>>>> multiple addresses=E2=80=9D discrimination mechanics of the protocol? =
I haven=E2=80=99t
>>>> worked it through, though,
>>>>
>>>> but that would be a guess.
>>>>
>>>>
>>>>
>>>> o The end-to-end topology diffusion mechanism should not need to be
>>>> concerned with the
>>>>
>>>> =E2=80=9Cbidirectionally check=E2=80=9D of a local link (in part, as i=
t encumbers
>>>> security, but not only).  In short, a
>>>>
>>>> flag or an address, both are (equally) bad.
>>>>
>>>>
>>>>
>>>> o A cleaner mechanism would be a =E2=80=9Chello mechanism=E2=80=9D, no=
t necessarily as
>>>> NHDP, but a =E2=80=9Cwhen
>>>>
>>>> forwarding a RREQ/RREP, trigger a 3-way hello exchange, if the link is
>>>> estimated to be of a
>>>>
>>>> type which potentially can be unidirectional=E2=80=9D. There is anothe=
r benefit
>>>> to doing that, see the end
>>>>
>>>> of this email.
>>>>
>>>>
>>>>
>>>> Either way, I do not like the notion of fusing
>>>> metrics-and-link-bidirectionality-detection any more than I like fusin=
g
>>>> global-topology-diffusion-and-link-bidirectionality-detection.
>>>>
>>>>
>>>>
>>>> The solution all this is, to me, threefold
>>>>
>>>>
>>>>
>>>> 1) Factor out the bidirectionally check in a (triggered) neighbour
>>>> detection mechanism
>>>>
>>>> (triggered HELLO message)
>>>>
>>>>
>>>>
>>>> 2) Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, since they add com=
plexity for no
>>>> perceivable benefits
>>>>
>>>>
>>>>
>>>> 3) Use the security model that we=E2=80=99ve discussed previously, whe=
re (only)
>>>> the metrics change per hop.
>>>>
>>>>
>>>>
>>>> Since we=E2=80=99re discussing bi-directionality of links here, and th=
e
>>>> 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:
>>>>
>>>>
>>>>
>>>>    ...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 install=
ed
>>>>
>>>>    in the Local Route Set at each router will be correct.  While this
>>>>
>>>>    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. Consequen=
tly, the conclusion
>>>> 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 lin=
k the
>>>> metrics is 4 or 5=E2=80=9D, the protocol must be able to convey and di=
stinguish
>>>> 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 w=
ith the
>>>> bi-directionality check) be in the triggered neighbour detection mecha=
nism:
>>>> that exchange could, if designed carefully, be used to probe for and c=
onvey
>>>> metrics information, also.
>>>>
>>>>
>>>>
>>>> Hope this helps,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thomas
>>>>
>>>>
>>>>
>>>> On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK) <
>>>> chris.dearlove@baesystems.com> wrote:
>>>>
>>>>
>>>>
>>>> Assuming for the moment that everyone will need an RREP-Ack or won=E2=
=80=99t
>>>> (let=E2=80=99s come back to that) why do C and B need to put an addres=
s in as an
>>>> RREQ-Ack request? Why not a flag, because the address will be included=
 as
>>>> the IP sending address - and we know 5444 is required to pass that on.
>>>> (It=E2=80=99s used by NHDP as well.) Then we don=E2=80=99t need to cha=
nge the RREP, it will
>>>> have a flag set or not, and won=E2=80=99t change (in this regard).
>>>>
>>>>
>>>>
>>>> Now let=E2=80=99s consider do we know whether we can set a fixed flag.=
 First
>>>> I=E2=80=99d say there are two cases - you=E2=80=99ve got a firm contro=
l on what=E2=80=99s going on
>>>> in your network, or it=E2=80=99s one of unknown parties and behaviour =
(consistent
>>>> with specification). In the former case you only want one setting, for
>>>> example no-Ack if running NHDP or your MAC layer tells you about
>>>> bidirectionality, Ack otherwise. In the latter case, I think you just
>>>> always want an Ack. So both cases get you to the same place.
>>>>
>>>>
>>>>
>>>> Should that not be an acceptable argument (though I think it=E2=80=99s=
 good for
>>>> where we are - in fact always Ack is close) then at flag is a step bet=
ter,
>>>> it=E2=80=99s a fixed location to change. However it would be better in=
 that case if
>>>> the two things to change (metric and ack flag) were together. But that=
 has
>>>> its own issues, so I won=E2=80=99t go there.
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com
>>>> ]
>>>> *Sent:* 25 April 2016 14:15
>>>> *To:* Jiazi YI
>>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
>>>> Networks mailing list
>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** 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
>>>> .*
>>>>
>>>> Hi Jiazi,
>>>>
>>>>
>>>>
>>>> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI  wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
>>>> chris.dearlove@baesystems.com> wrote:
>>>>
>>>> With regard to your validity time point, we here have a tradeoff. If
>>>> you allow that feature, it significantly impacts on the approach that =
was
>>>> coming together on as best you can end to end encryption.
>>>>
>>>>
>>>>
>>>> So the question is, is this a feature that=E2=80=99s really wanted?
>>>> Unfortunately I think we know that the answer to that is, we don=E2=80=
=99t know
>>>> because we don=E2=80=99t have any experience. My view would be that in=
 the tradeoff
>>>> of an untested feature (unless I=E2=80=99m wrong about that) and the s=
ecurity
>>>> complication, security wins and drop the feature. If there is some rea=
l
>>>> requirement, then there=E2=80=99s a discussion. (Questions like how of=
ten the
>>>> intermediate routers actually have any knowledge - typically links bre=
ak
>>>> for unexpected rather than expected reasons. Andan intermediate router
>>>> could possibly use a validity time to influence its behaviour.) Note t=
hat
>>>> dropping the ability of intermediate routers to modify/set still allow=
s
>>>> validity times per route to be set at endpoints.
>>>>
>>>>
>>>>
>>>> I agree with Chris' concern.
>>>>
>>>> The ValidityTime is optional, which makes the integrity protection
>>>> hard. Furthermore, it gives a potential attack vector: as all the rout=
ers
>>>> in a path will take the shortest validityTime, a compromised router ca=
n set
>>>> the the validityTime to a very short value, which will make the route
>>>> installed along the path became invalid (very soon).
>>>>
>>>>
>>>>
>>>> On the other hand, I'm not sure this option will give us much help.
>>>> Chris mentioned much knowledge intermediate router would have to decid=
e
>>>> this value (and how much sense the value would make).
>>>>
>>>> Another issue is, a route to a destination might be updated by
>>>> different sources. For example, in the network below:
>>>>
>>>>
>>>>
>>>> A----B-----C
>>>>
>>>>
>>>>
>>>> A first establish a route to B with long validity time. Then A
>>>> initiates a route discovery to C. C tends to set a short validity time=
,
>>>> which will make the route between B and A expire earlier than expected=
.
>>>>
>>>> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered
>>>> or not.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Not sure I follow here.
>>>>
>>>> Currently, the validity time of the route between A and B would not
>>>> affected by a short validity time of a route between A and C. Validity
>>>> times are per-route, and the route A-B and the route A-C are separate.
>>>>
>>>> If we switched to a validity time per neighbor (so that we can keep
>>>> validity time separate from route advertisements) as I mentioned in th=
e
>>>> email below, then the validity of a route between A and C would be aff=
ected
>>>> if there was a short validity time between A and B. But, if B will onl=
y
>>>> route for a certain amount of time, then the route between A and C wil=
l of
>>>> course be affected. Is it best to know in advance that there's a time
>>>> limit, or just deal with RERRs when they happen?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> With regard to the acknowledgements, the problem (with regard to
>>>> security) comes from trying to do two jobs with the same message - end=
 to
>>>> end route advertisement and hop by hop acknowledgement. I understand t=
he
>>>> reasons - saving bytes and message types. (I would have to study the
>>>> protocol really hard to identify if any message types can be folded
>>>> together and recognised by content rather than type efficiently. This =
I do
>>>> not expect to do.) Again a tradeoff. This one is in discussion space,
>>>> though that needs people who understand both sides of the issue, inclu=
ding
>>>> the details of the bidirectionality mechanism. Of course, as has been =
said,
>>>> we need one of those.
>>>>
>>>>
>>>>
>>>> I haven't finished my review of the latest draft, and I don't get the
>>>> necessity of AckReq and the corresponding multicast RREP yet.
>>>>
>>>> If possible, this "optional" field should be avoided.
>>>>
>>>>
>>>>
>>>>
>>>> To give an overview of AckReq and RREP:
>>>>
>>>> Since AODVv2 requires bidirectional links, this is the way to determin=
e
>>>> if a link is bidirectional.
>>>>
>>>> A----B----C
>>>>
>>>>
>>>> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both
>>>> install a route to OrigAddr but they dont yet know if it's valid becau=
se
>>>> they dont know if the link to their next hop is available in the rever=
se
>>>> direction.
>>>>
>>>> 2) C creates the RREP. Since it doesnt know if the link to B is
>>>> bidirectional, it includes the AckReq (an address to indicate that it
>>>> expects to receive a RREP_Ack from B).
>>>>
>>>> 3) B receives the RREP, installs a route to TargAddr and marks it as
>>>> valid, since it knows the link to C is bidirectional, because the RREQ=
 went
>>>> in one direction and the RREP came in the other. B also sends the RREP=
_Ack
>>>> to C and forwards the RREP to A (and might change the message to indic=
ate
>>>> its own AckReq - ie that it requires an ack from A).
>>>>
>>>> 4) C receives the RREP_Ack from B, and therefore knows that B received
>>>> the RREP, therefore the link is bidirectional. C can then mark its rou=
te to
>>>> OrigAddr as valid.
>>>>
>>>> 5) Similarly, A receives the RREP, installs the route to TargAddr and
>>>> sends an RREP_Ack to B.
>>>>
>>>> 6) B receives the RREP_Ack and marks its route to OrigAddr as valid.
>>>>
>>>>
>>>>
>>>> Alternatively, in step 2, if C knows the link to B is bidirectional
>>>> (perhaps from some earlier route discovery), it doesnt need to put the
>>>> AckReq in the RREP. Then in step 3, since B doesnt know if the link to=
 A is
>>>> bidirectional, it changes the message to add the AckReq address, in or=
der
>>>> to get an RREP_Ack from A.
>>>>
>>>> If we want to avoid changing the message, we'll need to look at
>>>> forwarding the RREP as-is, and creating a second message to solicit an
>>>> RREP_Ack, in order to verify that the link is bidirectional before mar=
king
>>>> the route to OrigAddr as valid.
>>>>
>>>> Kind regards,
>>>>
>>>> Victoria.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> regards
>>>>
>>>>
>>>>
>>>> Jiazi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *_____________________________________________________________________=
_____
>>>> *
>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
>>>> *Sent:* 23 April 2016 10:55
>>>> *To:* Christopher Dearlove
>>>> *Cc:* ietf@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad
>>>> Hoc Networks mailing list
>>>>
>>>>
>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** WARNING ****
>>>>
>>>>
>>>>
>>>> *This message originates from outside our organisation, either from an
>>>> external partner or the internet. Consider carefully whether you shoul=
d
>>>> 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
>>>> .*
>>>>
>>>> Hi Chris,
>>>>
>>>>
>>>>
>>>> These have both been in the draft in some form since before I got
>>>> involved... but I'll do my best to explain.
>>>>
>>>>
>>>>
>>>> - For Validity Time, its a way to advertise that you would only suppor=
t
>>>> the route contained in the message for a certain period of time. The
>>>> originator might use this, but the draft was written to allow any
>>>> intermediate node to be able to add it or update it too. The route cre=
ated
>>>> in the Local Route Set has an expiration time associated with it, base=
d on
>>>> the received validity time.
>>>>
>>>> - For the AckReq address, its so that you can add into a RREP a reques=
t
>>>> for an acknowledgement, so that you don't have to have a different mes=
sage
>>>> type altogether for working out whether links to neighbors are
>>>> bidirectional, and also, since you only care about bidirectionality on
>>>> routes that are being set up, you dont need to constantly monitor all
>>>> neighbors.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> In order to avoid the potential AckReq-related changes to each message=
,
>>>> maybe we do need to introduce a different message specifically for thi=
s. We
>>>> could maybe use RREP_Ack to both request and acknowledge? It means an =
extra
>>>> message of control traffic that needs to be sent, maybe one extra mess=
age
>>>> per hop on the path of a RREP, but it could still be limited to neighb=
ors
>>>> which have participated in the route discovery rather than monitoring =
all
>>>> neighbors at all times.
>>>>
>>>>
>>>>
>>>> This message could maybe also include "I'm happy to route anywhere for
>>>> a certain amount of time", sort of like willingness in OLSR/OLSRv2. So
>>>> instead of having a validity time per route, its a validity time per
>>>> neighbor. Then, for RREQ and RREP, only the metric value would change =
in
>>>> transit, as discussed. However, that leads to some issues with decidin=
g
>>>> what a route's expiration time is. You might know how long the next ho=
p
>>>> router is valid for, but what if a router beyond that, which was also =
part
>>>> of the route, had a lower validity time? You couldn't determine the re=
al
>>>> validity time. Do we remove the route expiration time altogether to av=
oid
>>>> this issue? In which case, we would have to rely on RERR messages bein=
g
>>>> sent for routes which become invalid when the neighbor's validity time=
 has
>>>> expired? So neighbor validity time expiration is treated the same as a=
 link
>>>> break.
>>>>
>>>>
>>>>
>>>> What do you think?
>>>>
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Victoria.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
>>>> chris@mnemosyne.demon.co.uk> wrote:
>>>>
>>>> Pretty much all of the discussion has been assuming only a metric valu=
e
>>>> change. With multiple things changing many of the ideas go out of the
>>>> window. That reinforces the point about not making specifications now =
that
>>>> might turn out to be wrong for ICVs.
>>>>
>>>>
>>>>
>>>> Ignoring how this misunderstanding happened, I'll start by asking why.
>>>> Metric changing I understand. Why the other two? (there's a partial
>>>> explanation of one). What alternatives have people implemented in
>>>> comparable protocols?
>>>>
>>>> --
>>>>
>>>> Christopher Dearlove
>>>>
>>>> christopher.dearlove@gmail.com (iPhone)
>>>>
>>>> chris@mnemosyne.demon.co.uk (home)
>>>>
>>>>
>>>> On 23 Apr 2016, at 00:26, Victoria Mercieca 
>>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> Continued in this thread because the other one seems to be more about
>>>> TLV types and metric type numbers, whereas this is about
>>>> regeneration/forwarding.
>>>>
>>>>
>>>>
>>>> To recap, in the current draft, there are 3 things that might change a=
t
>>>> each hop:
>>>> - the metric value (happens in RREQ and RREP),
>>>> - adding/changing Validity Time using the Validity Time TLV (can happe=
n
>>>> in RREQ and RREP),
>>>> - adding an address (and corresponding value in the AddressType TLV to
>>>> indicate how to interpret the address) to indicate the address from wh=
ich
>>>> an RREP_Ack is expected, to accomplish the bidirectionality check (can
>>>> happen in RREP).
>>>>
>>>> If we define a certain portion of the message as immutable and include
>>>> the ICV to verify that part, end to end:
>>>> - The metric value would be excluded from the ICV since it needs
>>>> changing at each hop.
>>>> - Would adding a Validity Time TLV at an intermediate hop be
>>>> acceptable? The whole TLV could be removed in order to calculate the I=
CV?
>>>>
>>>> - Would adding an address cause issues for the ICV, because it's in th=
e
>>>> address block? Could the rule be "if it contains an AckReq address, re=
move
>>>> it (and the corresponding value in the AddressType TLV), before checki=
ng
>>>> the ICV", is that OK? Or would we need to avoid touching the ICV'ed pa=
rt of
>>>> the message altogether, maybe put the AckReq address in a separate Add=
ress
>>>> Block, with an extra AddressType TLV following that address block? Is =
there
>>>> a way to accomplish this?
>>>>
>>>>
>>>>
>>>> Also, to be thorough, do we need to consider RERR messages while we
>>>> discuss regeneration vs forwarding?
>>>>
>>>> - RERR (sent when a link breaks) is a way of saying "I've lost my rout=
e
>>>> so I'm telling others" and "you were my next hop, so now I've also los=
t my
>>>> route, I'll tell others", etc. It's going to be tailored at each step =
to
>>>> include the relevant routes that got deleted, it's not one message bei=
ng
>>>> sent end-to-end like RREQ and RREP are.
>>>>
>>>> - However, RERR (sent when a source of traffic is sending data on a
>>>> route which comes through you, and you want to tell the Packet Source'=
s
>>>> router to delete the route) could be seen as an end-to-end message whi=
ch
>>>> all intermediate routers learn from, similar to RREQ and RREP. It repo=
rts
>>>> one route, and doesn't need changing at intermediate hops, so could be
>>>> protected with ICV.
>>>>
>>>> - Would it be OK to only require a message ICV if a PktSource address
>>>> was included, i.e. when the message needs to go via a number of
>>>> intermediate hops to PktSource's router? All other RERRs are intended =
to be
>>>> one-hop messages, which may in turn prompt other one-hop messages, etc=
...,
>>>> and a packet ICV might be more appropriate?
>>>>
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Victoria.
>>>>
>>>>
>>>>
>>>> On Thu, Mar 17, 2016 at 5:26 PM,  wrote:
>>>>
>>>>
>>>>
>>>> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
>>>> chris.dearlove@baesystems.com> wrote:
>>>>
>>>>
>>>>
>>>> Yes, I meant AODVv2, thanks for the catch.
>>>>
>>>>
>>>>
>>>> So is your (Thomas) proposed base specification a hop count only metri=
c?
>>>>
>>>>
>>>>
>>>> No, the would be silly as base specification, given that hop count
>>>> mostly is useless.
>>>>
>>>>
>>>>
>>>> As base specification I would simply say =E2=80=9CInclude a Metric Typ=
e Message
>>>> TLV with a value field, and a 7182 Message TLV & Timestamp=E2=80=9D as=
 we do in
>>>> OLSRv2 (with the appropriate verbiage as to generation and processing)=
.
>>>>
>>>>
>>>>
>>>> With the message generated by the originator of the RREQ/RREP and *not=
*
>>>> deconstructed/reconstructed/reordered (as is the risk with =E2=80=9Cre=
generation)
>>>> allows knowing that it would be *only* that metric field being modifie=
d
>>>> (other than hop count/limit) for when eventually writing up the extens=
ion.
>>>>
>>>>
>>>>
>>>> (Actually doesn=E2=80=99t the current specification only define hop co=
unt, or
>>>> has that changed in latest draft?)
>>>>
>>>>
>>>>
>>>> No. That is one of the issues I raise in my original. For some reason,
>>>> it cites RFC6551, which is a ROLL document and which has in its abstra=
ct
>>>> that:
>>>>
>>>>
>>>>
>>>>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>>>>
>>>>    compared with traditional wired and ad hoc networks that require th=
e
>>>>
>>>>    specification of new routing metrics and constraints.
>>>>
>>>>
>>>>
>>>> I.e. this document cites a metric document which clearly claims to be
>>>> inapplicable in ad hoc networks. I note that this is another thing I=
=E2=80=99ve
>>>> raised for years without seeing it attempted resolved.
>>>>
>>>>
>>>>
>>>> Best,
>>>>
>>>>
>>>>
>>>> Thomas
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *_____________________________________________________________________=
_____
>>>> *
>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>>>> ]
>>>> *Sent:* 17 March 2016 17:10
>>>> *To:* Dearlove, Christopher (UK)
>>>> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** WARNING ****
>>>>
>>>>
>>>>
>>>> *This message originates from outside our organisation, either from an
>>>> external partner or the internet. Consider carefully whether you shoul=
d
>>>> 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 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
>>>> chris.dearlove@baesystems.com> wrote:
>>>>
>>>>
>>>>
>>>> OK, so we have a message that mutates by:
>>>>
>>>> - Modifying hop count/limit.
>>>>
>>>> - Modifying a metric value.
>>>>
>>>> Anything else?
>>>>
>>>>
>>>>
>>>> As mutating (other than hop count/limit) messages aren=E2=80=99t cover=
ed by
>>>> 5444 or any derivative document (but only recommended against, not ban=
ned)
>>>> that you may need to make the message otherwise immutable (no
>>>> deconstruction and rebuilding, other than guaranteed unchanging) that =
would
>>>> have to be specified by AODVv2. (Easy to say, but needs saying.)
>>>>
>>>>
>>>>
>>>> With you so far.
>>>>
>>>>
>>>>
>>>> Then that information is not in a guaranteed fixed location given by a
>>>> simple offset. So any signature algorithm that finds it and ignores it=
 or
>>>> aggregates on it is specific to OLSRv2.
>>>>
>>>>
>>>>
>>>> Surely you mean AODVv2
>>>>
>>>>
>>>>
>>>> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AODV=
v2
>>>> specialised variant. Which is the sort of thing that the message speci=
fic
>>>> TLV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cbut=
 ignore the value of
>>>> this specific TLV should it occur=E2=80=9D being in the general space.=
 However it
>>>> can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like =
that TLV,
>>>> except if an X TLV is present, set its value field to zero=E2=80=9D).
>>>>
>>>>
>>>>
>>>> Messy, but could work.
>>>>
>>>>
>>>>
>>>> Not that messy, actually, although clearly not as nice as =E2=80=9Cfix=
ed
>>>> offset=E2=80=9D.
>>>>
>>>>
>>>>
>>>> That said, I am arguing for the base spec being:
>>>>
>>>>
>>>>
>>>>             =E2=80=9Cmake the message otherwise immutable (no deconstr=
uction
>>>> and rebuilding, other
>>>>
>>>>              than guaranteed unchanging)=E2=80=9D which is afforded by
>>>> forwarding
>>>>
>>>>
>>>>
>>>>                                     +
>>>>
>>>>
>>>>
>>>>             RFC7182 Timestamps and ICVs.
>>>>
>>>>
>>>>
>>>>                                     +
>>>>
>>>>
>>>>
>>>>             RFC7183 style text bringing it all together.
>>>>
>>>>
>>>>
>>>> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would=
 very be an
>>>> experimental extension.
>>>>
>>>>
>>>>
>>>> What I object to is, if the base spec specifically renders such
>>>> extensions impossible
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *_____________________________________________________________________=
_____
>>>> *
>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
>>>> ]
>>>> *Sent:* 17 March 2016 16:48
>>>> *To:* Dearlove, Christopher (UK)
>>>> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** WARNING ****
>>>>
>>>>
>>>>
>>>> *This message originates from outside our organisation, either from an
>>>> external partner or the internet. Consider carefully whether you shoul=
d
>>>> 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
>>>> .*
>>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
>>>> chris.dearlove@baesystems.com>:
>>>>
>>>>
>>>>
>>>> Good point about whether you just pass on one cost or a set of costs.
>>>> As I said, not looked at details - I will, when time permits. One cost=
 is
>>>> much easier, and yes, it reduces the fixed size aggregated signatures
>>>> problem to =E2=80=9Cjust=E2=80=9D one of computational load.
>>>>
>>>>
>>>>
>>>> For the record, Thomas=E2=80=99 understanding is correct; the cost is =
one
>>>> aggregated value.
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Lotte Steenrbink
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *_____________________________________________________________________=
_____
>>>> *
>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>>>> ]
>>>> *Sent:* 17 March 2016 16:38
>>>> *To:* Dearlove, Christopher (UK)
>>>> *Cc:* Mobile Ad Hoc Networks mailing list
>>>> *Subject:* Re: Message integrity and message mutability (was RE:
>>>> [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Ite=
ms)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** WARNING ****
>>>>
>>>>
>>>>
>>>> *This message originates from outside our organisation, either from an
>>>> external partner or the internet. Consider carefully whether you shoul=
d
>>>> 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 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
>>>> chris.dearlove@baesystems.com> wrote:
>>>>
>>>>
>>>>
>>>> I appreciate Thomas=E2=80=99s comments about the limitations of messag=
e
>>>> regeneration, but I would be a bit less absolute.
>>>>
>>>>
>>>>
>>>> The issues over end to end authentication and more advanced signatures
>>>> are valid. I need to read the given reference on aggregate signatures =
to
>>>> increase my knowledge (thanks for it), but my understanding of the
>>>> possibilities in this field may offer a solution to the problem, but w=
ith
>>>> some other issues (possibly including a new type of TLV).
>>>>
>>>>
>>>>
>>>> But the hop count/limit point I don=E2=80=99t fully agree with, you ca=
n
>>>> regenerate with an incremented/decremented count/limit, which leaves t=
he
>>>> ability to prevent messages propagating indefinitely, including expand=
ing
>>>> ring searches, and retains the ability to use RFC 5497 interval and
>>>> validity times that might be useful with an expanding ring search (or =
might
>>>> not).
>>>>
>>>>
>>>>
>>>> But the key issue is that AODVv2 wants to accumulate metrics. I still
>>>> haven=E2=80=99t got to the bottom of many details here, but let=E2=80=
=99s for the moment
>>>> just consider that conceptually.
>>>>
>>>>
>>>>
>>>> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft attemp=
ts to do an end
>>>> to end of some information, not this information. I=E2=80=99m not sure=
 if that=E2=80=99s
>>>> useful (and the specialised format is better avoided if possible). Oth=
er
>>>> approaches are hop by hop (might as well use packet signatures) and sh=
ared
>>>> key (might as well go hop by hop). Pairwise signatures for each pair o=
f
>>>> routers I=E2=80=99m discounting as scaling terribly. In the interests =
of
>>>> completeness let=E2=80=99s mention not accumulating metrics, which put=
s us back to
>>>> hop count and that=E2=80=99s not ideal either.
>>>>
>>>>
>>>>
>>>> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=
=80=99ve seen about
>>>> aggregating, but that has some issues of its own, even apart from
>>>> computational load.) I=E2=80=99d love to be proved wrong - someone wit=
h the perfect
>>>> solution to come along.
>>>>
>>>>
>>>>
>>>> Which means that either we make an arbitrary choice - which will be
>>>> disagreed with, but needs discussing first - or create something flexi=
ble.
>>>> Unfortunately flexible in that regard constrains in others, e.g. some
>>>> (many? most?) aggregating signatures need fixed data sizes (which we c=
an do
>>>> by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but =
that has a cost too).
>>>>
>>>>
>>>>
>>>> I have been told by people much more well versed in this than I in
>>>> cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>>>>
>>>>
>>>>
>>>> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does=
 that mean that
>>>> the message grows as it is being forwarded, and that the recipient of =
a
>>>> RREQ/RREP will know the individual costs of each path segment? My
>>>> understanding is, that the recipient will get =E2=80=9Cthe sum the cos=
ts of each
>>>> path segment=E2=80=9D which should be fitting within a fixed size?
>>>>
>>>>
>>>>
>>>> Thomas
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Sorry, no answers, just comments. And I=E2=80=99m not addressing Thoma=
s=E2=80=99s later
>>>> points here.
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *_____________________________________________________________________=
_____
>>>> *
>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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 *ietf@thomasclausen.org
>>>> *Sent:* 17 March 2016 16:00
>>>> *To:* Mobile Ad Hoc Networks mailing list
>>>> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of big
>>>> ticket Items
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** WARNING ****
>>>>
>>>>
>>>>
>>>> *This message originates from outside our organisation, either from an
>>>> external partner or the internet. Consider carefully whether you shoul=
d
>>>> 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 organizatio=
n
>>>> .
>>>>
>>>>
>>>>
>>>> Dear all,
>>>>
>>>>
>>>>
>>>> Apologies for not having gotten this done sooner - day-job leaving few
>>>> spare cycles.
>>>>
>>>>
>>>>
>>>> I=E2=80=99ve previously offered reviews and comments, and some of thos=
e have
>>>> been addressed in the latest I-D =E2=80=94 others have not, but should=
 be. I recall
>>>> that there was some mail attempting to rebut parts of the review, and =
I
>>>> will dig it out and reply to that.
>>>>
>>>>
>>>>
>>>> With that being said, I have reviewed the latest version of the
>>>> document, and full details will be forthcoming. There=E2=80=99re a cou=
ple of
>>>> big-ticket/architectural items that I want to address up front, as I
>>>> believe that before we have those hammered out, it will be useless to =
go
>>>> into details. Note, I do not claim that this is an exhaustive list of =
=E2=80=9Cbig
>>>> ticket items=E2=80=9D, but that=E2=80=99s as far as I have gotten in t=
hinking this through.
>>>>
>>>>
>>>>
>>>> I also bring these up as they are items that have been brought up
>>>> repeatedly over the past years, but not resolved nor discussed.
>>>>
>>>>
>>>>
>>>> *Loops*
>>>>
>>>> Just to bring this out: I share Chris=E2=80=99 worry about conflicting=
 and
>>>> concurrent statements from the authors on =E2=80=9CThere are no loops =
possible=E2=80=9D and
>>>> =E2=80=9CWe need to fix two situations where loops can occur=E2=80=9D =
and =E2=80=9Cwe are still
>>>> investigating some loop conditions=E2=80=9D
>>>>
>>>>
>>>>
>>>> I particularly worry that this is not a discussion had in public, but
>>>> apparently in some other forum=E2=80=A6
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Intermediate Route Replies, and all of section 10*
>>>>
>>>> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=
=80=9D, which is
>>>> incoherent with the intended status indicated for this document.
>>>>
>>>>
>>>>
>>>> Specifically, and this is not unrelated to the point about loops above=
,
>>>> intermediate RREPs (section 10.3) are a potential source for loops.
>>>>
>>>>
>>>>
>>>> Expanding Ring Multicast (section 10.1) is not documented in a way tha=
t
>>>> can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=
=E2=80=9D below, it is
>>>> in the present form of this protocol impossible), etc.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Forwarding-vs-regeneration*
>>>>
>>>> Recent exchanges on the list made me understand that protocol control
>>>> messages are *not* forwarded, but are consumed at each hop, then a new
>>>> message with (almost-but-not-quite) the same content is generated and
>>>> transmitted.
>>>>
>>>>
>>>>
>>>> I have thought some more on this (& read some of the exchanges on the
>>>> list on this topic by Chris, Ulrich, and others), and I am convinced t=
hat
>>>> this is not the right way to go, *at least* for the following reasons:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>             o          *It renders the hop-limit/hop-count fields in
>>>> the RFC5444 message header useless.*
>>>>
>>>>                         This would not be bad if the functionality
>>>> offered by those fields was not useful
>>>>
>>>>                         =E2=80=94 sadly, it is. For example, for scope=
 limited
>>>> flooding (expanding ring search, and
>>>>
>>>>                         such) which may be of interest, and which
>>>> require hop-limit.
>>>>
>>>>                         A hop-count field may also provide a =E2=80=9C=
cheap=E2=80=9D
>>>> (in terms of overhead) additional piece
>>>>
>>>>                         of information to use conjunctively with a
>>>> =E2=80=9Creal=E2=80=9D metric.
>>>>
>>>>
>>>>
>>>>                         The only practical solution would be to
>>>> re-introduce these functions by way of inserting a
>>>>
>>>>                         MessageTLV =E2=80=94 which (i) is not specifie=
d in this
>>>> document, and (ii) which would just
>>>>
>>>>                         serve to render messages bigger than strictly
>>>> needed.
>>>>
>>>>
>>>>
>>>>                         Scope limited flooding  does seem to be a
>>>> necessary requirement, if for no
>>>>
>>>>                         other reason than to prevent information from
>>>> =E2=80=9Ccirculating forever in the network=E2=80=9D.
>>>>
>>>>
>>>>
>>>>             o          *It makes end-to-end authentication
>>>> unnecessarily hard.*
>>>>
>>>>                         I think Chris called this out already, but it
>>>> bears repeating: S generates a message
>>>>
>>>>                         (say, a RREQ), and includes an ICV calculated
>>>> over the content of the message.
>>>>
>>>>                         For any recipient to be able to validate the
>>>> ICV, the message has to be exactly
>>>>
>>>>                         the same =E2=80=94 not just in content, but in
>>>> structure =E2=80=94 as what was generated.
>>>>
>>>>
>>>>
>>>>                         =E2=80=9CRegenerating=E2=80=9D rather than =E2=
=80=9Cforwarding=E2=80=9D
>>>> messages means, that the intermediate
>>>>
>>>>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ=
 may chose a
>>>> different structure (e.g., include TLVs
>>>>
>>>>                         in a different order).
>>>>
>>>>
>>>>
>>>>                         The proposal from
>>>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>>>>
>>>>                         is to add constraints on (i) the set of
>>>> elements to include in a signature and (ii) the
>>>>
>>>>                         order of these elements.
>>>>
>>>>
>>>>
>>>>                         One problem with that approach is (i): if an
>>>> extension adds a message TLV, or an
>>>>
>>>>                         Address TLV, to a message, then that will not
>>>> be =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>>>>
>>>>                         Rather for *each* extension developed, an
>>>> =E2=80=9Cupdates e2esec=E2=80=9D clause needs to be done.
>>>>
>>>>
>>>>
>>>>                         I=E2=80=99d say that this approach would be pr=
one to
>>>> errors =E2=80=94 and add entropy to the process
>>>>
>>>>                         of designing protocol extensions. The
>>>> alternative, a message being generated by the
>>>>
>>>>                         source and *forwarded* (as we do in OLSRv2, fo=
r
>>>> example) would allow ICV TLVs
>>>>
>>>>                         (even, allow reuse of those specified for
>>>> OLSRv2) for covering a message and
>>>>
>>>>                         extensions.
>>>>
>>>>
>>>>
>>>>                         =E2=80=9CBut what about the metrics value whic=
h will
>>>> change on each hop=E2=80=9D, you may say?
>>>>
>>>>                         Fortunately, that is relatively easy to handle=
:
>>>> simply zero out the value of that TLV when
>>>>
>>>>                         generating or verifying the ICV MessageTLV. An=
d
>>>> use Packet-TLVs for hop-by-hop
>>>>
>>>>                         authentication, if needed (but, see below).
>>>>
>>>>
>>>>
>>>>             o          *It prevents the use of more clever/advanced
>>>> signature schemes/ICVs*
>>>>
>>>>                         Aggregate signature algorithms (
>>>> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>>>>
>>>>                         exist, and an interesting use-case can be foun=
d
>>>> in also reactive protocols, allowing verifying
>>>>
>>>>                         not =E2=80=9Cjust=E2=80=9D the end points, but=
 also the
>>>> intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D
>>>>
>>>>                         discussed above, or something smarter).
>>>>
>>>>                         Regeneration of messages, rather than
>>>> forwarding, renders that impossible (or, if used,
>>>>
>>>>                         updating to
>>>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>>>>
>>>>
>>>>
>>>> There are other reasons, but the above are those that jump at me as
>>>> immediate show-stoppers.
>>>>
>>>>
>>>>
>>>> I do honestly not see what possible benefit there is from
>>>> =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inconven=
iences, and security is not
>>>> the least of these. Insisting on =E2=80=9Cregeneration=E2=80=9D requir=
es development of
>>>> =E2=80=9Cnon-general workarounds=E2=80=9D as pointed out above.
>>>>
>>>>
>>>>
>>>> *Security Considerations*
>>>>
>>>> This is an always thorny subject. When OLSRv2 was going through the
>>>> process we got a thorough education in how little we knew about securi=
ty
>>>> from the SEC-ADs, and had to spend about a year or so developing RFC71=
83.
>>>> The bottom line is, that this protocol needs its =E2=80=9CRFC7183  equ=
ivalent=E2=80=9D,
>>>> either as part of the main document, or as an independent document.
>>>> currently, that is not the case.
>>>>
>>>>
>>>>
>>>> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration fro=
m RFC7183
>>>> might be aw good idea, as that was the most recent that went through t=
he
>>>> SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to implement=
=E2=80=9D security
>>>> mechanism most be specified (I think the right term was =E2=80=9CMUST =
implement,
>>>> SHOULD use=E2=80=9D), in sufficient detail to ensure interoperable imp=
lementations.
>>>>
>>>>
>>>>
>>>> As an example, both [RFC6130] and [RFC7181] set out that that:
>>>>
>>>>
>>>>
>>>>       On receiving a ... message, a router MUST first check if the
>>>>
>>>>       message is invalid for processing by this router
>>>>
>>>>
>>>>
>>>> and then proceed to give a number of conditions that, each, will lead
>>>> to a rejection of the message as "badly formed and therefore invalid f=
or
>>>> processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That =
gave a =E2=80=9Chook=E2=80=9D for
>>>> RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message ge=
neration.
>>>>
>>>>
>>>>
>>>> If I was to do RFC7181/RFC6130 today, I would include that directly
>>>> into the protocol specifications. It turned out to be more overhead (a=
nd
>>>> slow down publication anyways) to do it as separate documents.
>>>>
>>>>
>>>>
>>>> Secondly, we need to be a lot more rigid in terms of what ICVs,
>>>> Timestamps, etc. are added/removed, and what that brings.
>>>>
>>>>
>>>>
>>>> For example (with the assumption that messages are *forwarded* and
>>>> *not* regenerated), this could be one option:
>>>>
>>>>
>>>>
>>>>                         o          When a RREQ, RREP message is
>>>> generated, add an ICV Message TLV, which is calculated 
>>>>
>>>>                                      =E2=80=A6(take inspiration from R=
FC7183
>>>> here)
>>>>
>>>>
>>>>
>>>> ...
>>>>
>>>> [Message clipped]
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>>
>>>> ********************************************************************
>>>> 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
>>
>>
>

--001a1147dab0e9d0ce05315104ec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Apr 25, 2016 at 5:34 PM, Justin Dean <bebemaster@gmail.com<=
/a>> wrote:
On Mon, Apr 25, 2016 at=
 11:29 AM, Jiazi YI <ietf@jiaziyi.com> wrote:
Hi,=C2=A0

Maybe I missed a bit her=
e:=C2=A0

If only the desired receiver of the multi=
cast RREP (carrying a destination address) can reply to the multicast RREP,=
 why not using unicast directly?

Because the link isn't yet known to be bi-directional and a unicast r=
oute can't be installed yet.
<=
br>
Does it matter? I can send a unicast to the next hop anyways:=
 if I didn't get a RREP-ACK, then it's unidirectional, so that I ca=
n blacklist the next hop.=C2=A0

If I get a RREP-AC=
K, then it's bidirectional and I can continue to set up the (bi-directd=
ional) route.=C2=A0

best

=
Jiazi

=C2=A0
<=
div dir=3D"ltr">
=

Justin
=C2=A0
best

Jiazi

On Mon, Apr 25, 2016 at 4:59 PM, V=
ictoria Mercieca <vmercieca0@gmail.com> wrote:
Hi Chris,


=

On Mon, Apr 25, 2016 at 3:51 PM, Dearlove, Chris=
topher (UK) <chris.dearlove@baesystems.com> wrot=
e:











I has to go back to Victoria=E2=80=99s summa=
ry here. It says:


=C2=A0


2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).


=C2=A0


That doesn=E2=80=99t actually indicate if th=
at=E2=80=99s C=E2=80=99s address or B=E2=80=99s address being included. I=
=E2=80=99d assumed it was C=E2=80=99s address. Your comment makes sense if =
it=E2=80=99s B=E2=80=99s address.
 Reading again, I think you=E2=80=99re probably right. But only probably. C=
an we confirm that.


=C2=A0

C creates the RREP. The included AckReq address is=
 B's address. The RREP then gets multicast.
B receives it=
, sees that it own address is marked as the AckReq address, and sends an ac=
k unicast back to C. 
Anyone else who receives the multicast RREP from C=
 does not send the Ack, since the AckReq address does not match any of thei=
r interface addresses.
=C2=A0
<=
span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73=
,125)">


I assume you meant that the RREP (not RREP_A=
ck) is multicast. There=E2=80=99s a bit of a chicken and egg problem here. =
We do know how we want to unicast.
=
=C2=A0
The RREP is multicast (when we dont know if the link is bi=
directional), the RREP_Ack is always unicast. 

Kind regar=
ds,
Vicky.

=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:
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 Intelligence 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: 25 April 2016 15:26

To: Thomas Heide Clausen

Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc =
Networks mailing list; Victoria Mercieca

Subject: Re: [manet] Message integrity and message mutability (was R=
E: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)=



=C2=A0




=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether =
you should click on any links, open any attachments or reply.
For information regarding <=
/span>
Red Flags that you can look out=
 for in emails you receive,
 click 
here.

If you feel the email is su=
spicious, please follow

this process.








The address in the RREP_Ack may be required due to t=
he RREP_Ack being multicast as there is not yet a verified unicast route in=
stalled yet.=C2=A0 Going to double check if I'm remembering correctly.=
=C2=A0



Justin






=C2=A0




On Mon, Apr 25, 2016 at 10:18 AM, <ietf@thomasclausen.org>=
; wrote:




Hi,




=C2=A0






I must admit that while I have reviewed the protocol=
 several times, I=E2=80=99ve not been digging that deep into the protocol f=
unctioning to catch this issue of how invasive the protocol operations are =
when forwarding a message: there were other
 =E2=80=9Cmajor=E2=80=9D issues to address (and which obscured the details)=
, so as a first order: thank you Victoria, for having called attention to t=
his.






=C2=A0






To the substance of these emails.






=C2=A0






I am afraid that I do not understand the use of inse=
rting validity TLVs while in-flight, into a message. Actually, I am dubious=
 for both the originator inserting this (how can the originator of a messag=
e know how =E2=80=9Clatter parts of the path=E2=80=9D
 will be have=E2=80=9D) except if we are talking duty-cycling of devices an=
d inserting =E2=80=9Cthe remaining time that I am going to be up before I s=
uspend=E2=80=9D. Intuitively, that would also assume fairly long duty cycle=
s =E2=80=9CI am up for tens of seconds=E2=80=9D, which I am not sure are
 actually realistic. And, as Chris says in another email, this is trading o=
ff =E2=80=9Cthe ability to do security=E2=80=9D for an unknown/untested fea=
ture =E2=80=94 which I think is the wrong trade-off.






=C2=A0






On he topic of =E2=80=9Cneeding to put an address in=
=E2=80=9D for RREP-ACK, I must admit that this seems roundabout. I can see =
three issues here:






=C2=A0






o I am not sure that adding an address vs. a flag ma=
y not have to do with the =E2=80=9Cmultiple interfaces/






multiple addresses=E2=80=9D discrimination mechanics=
 of the protocol? I haven=E2=80=99t worked it through, though,=C2=A0=







but that would be a guess.






=C2=A0






o The end-to-end topology diffusion mechanism should=
 not need to be concerned with the=C2=A0






=E2=80=9Cbidirectionally check=E2=80=9D of a local l=
ink (in part, as it encumbers security, but not only).=C2=A0 In short, a=







flag or an address, both are (equally) bad.






=C2=A0






o A cleaner mechanism would be a =E2=80=9Chello mech=
anism=E2=80=9D, not necessarily as NHDP, but a =E2=80=9Cwhen=C2=A0






forwarding a RREQ/RREP, trigger a 3-way hello exchan=
ge, if the link is estimated to be of a=C2=A0






type which potentially can be=C2=A0unidirectional=E2=
=80=9D. There is another benefit to doing that, see the end=C2=A0=







of this email.






=C2=A0






Either way, I do not like the notion of fusing metri=
cs-and-link-bidirectionality-detection any more than I like fusing global-t=
opology-diffusion-and-link-bidirectionality-detection.=C2=A0<=
/p>





=C2=A0






The solution all this is, to me, threefold=







=C2=A0






1) Factor out the bidirectionally check in a (trigge=
red) neighbour detection mechanism=C2=A0






(triggered HELLO message)






=C2=A0






2) Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, =
since they add complexity for no perceivable benefits






=C2=A0






3) Use the security model that we=E2=80=99ve discuss=
ed previously, where (only) the metrics change per hop.






=C2=A0






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 related issue, as I hinted previously.





=C2=A0








The abs=
tract states that the protocol:






=
=C2=A0






=C2=A0=C2=A0 ...is intended for use by mobile routers in wireless, mul=
tihop


=C2=A0=C2=A0 networks.




=
=C2=A0






Section=
 5 paragraph 4 =C2=A0of the document, however, reads:<=
/pre>





=
=C2=A0






=C2=A0=C2=A0 Assuming link metrics are symmetric, the cost of the rout=
es installed


=C2=A0=C2=A0 in the Local Route Set at each router will be correct.=C2=
=A0 While this


=C2=A0=C2=A0 assumption is not always correct, calculating incoming/ou=
tgoing


=C2=A0=C2=A0 metric data is outside of scope of this document. =





=C2=A0








I do not know of any wireless systems,=
 where the assumption that =E2=80=9Clink metrics are symmetric=E2=80=9D act=
ually holds. Consequently, the conclusion in the quoted paragraph:






=C2=A0


=C2=A0=C2=A0 calculating incoming/outgoing


=C2=A0=C2=A0 metric data is outside of scope of this document.<=
u>




=C2=A0








Is not an acceptable design choice.





=C2=A0






While this protocol may not want to =E2=80=9Ccalcula=
te if for this link the metrics is 4 or 5=E2=80=9D, the protocol must be ab=
le to convey and distinguish that =E2=80=9Cthe metric from A to B is 4, and=
 the metric from B to A is 19=E2=80=9D.






=C2=A0






This is a =E2=80=9Crelated issue=E2=80=9D since the =
solution may (as with the bi-directionality check) be in the triggered neig=
hbour detection mechanism: that exchange could, if designed carefully, be u=
sed to probe for and convey metrics information, also.






=C2=A0






Hope this helps,






=C2=A0






=C2=A0






Thomas






=C2=A0












On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK)=
 <chr=
is.dearlove@baesystems.com> wrote:




=C2=A0








Assuming for the moment that everyone will n=
eed an RREP-Ack or won=E2=80=99t (let=E2=80=99s come back to that) why do C=
 and B need to put an address in as an RREQ-Ack request?
 Why not a flag, because the address will be included as the IP sending add=
ress - and we know 5444 is required to pass that on. (It=E2=80=99s used by =
NHDP as well.) Then we don=E2=80=99t need to change the RREP, it will have =
a flag set or not, and won=E2=80=99t change (in this regard).=







=C2=A0






Now let=E2=80=99s consider do we know whethe=
r we can set a fixed flag. First I=E2=80=99d say there are two cases - you=
=E2=80=99ve got a firm control on what=E2=80=99s going on in your network,
 or it=E2=80=99s one of unknown parties and behaviour (consistent with spec=
ification). In the former case you only want one setting, for example no-Ac=
k if running NHDP or your MAC layer tells you about bidirectionality, Ack o=
therwise. In the latter case, I think you
 just always want an Ack. So both cases get you to the same place.






=C2=A0






Should that not be an acceptable argument (t=
hough I think it=E2=80=99s good for where we are - in fact always Ack is cl=
ose) then at flag is a step better, it=E2=80=99s a fixed
 location to change. However it would be better in that case if the two thi=
ngs to change (metric and ack flag) were together. But that has its own iss=
ues, so I won=E2=80=99t go there.






=C2=A0




--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44 (0)1245 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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






From:=C2=A0Victoria Mercieca [mailto:vmercieca0@gmail.com]=C2=A0

Sent:=C2=A025 April 2016 14:15

To:=C2=A0Jiazi YI

Cc:=C2=A0Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad=
 Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)






=C2=A0






=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om 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=C2=A0tha=
t
 you can look out for in emails you receive, click=C2=A0here.

If you feel the email is su=
spicious, please follow=C2=A0this
 process.








Hi Jiazi,










=C2=A0








On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <ietf@jiaziyi.com> wrote:








Hi,=C2=A0








=C2=A0








On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christop=
her (UK) <chris.dearlove@baesystems.com&=
gt; wrote:










With regard to your validity time point, we =
here have a tradeoff. If you allow that feature, it significantly impacts o=
n the approach that was coming together
 on as best you can end to end encryption.






=C2=A0






So the question is, is this a feature that=
=E2=80=99s really wanted? Unfortunately I think we know that the answer to =
that is, we don=E2=80=99t know because we don=E2=80=99t have any
 experience. My view would be that in the tradeoff of an untested feature (=
unless I=E2=80=99m wrong about that) and the security complication, securit=
y wins and drop the feature. If there is some real requirement, then there=
=E2=80=99s a discussion. (Questions like how often
 the intermediate routers actually have any knowledge - typically links bre=
ak for unexpected rather than expected reasons. Andan intermediate router c=
ould possibly use a validity time to influence its behaviour.) Note that dr=
opping the ability of intermediate
 routers to modify/set still allows validity times per route to be set at e=
ndpoints.












=C2=A0










I agree with Chris' concern.










The ValidityTime is optional, which makes the integr=
ity protection hard. Furthermore, it gives a potential attack vector: as al=
l the routers in a path will take the shortest validityTime, a compromised =
router can set the the validityTime
 to a very short value, which will make the route installed along the path =
became invalid (very soon).=C2=A0










=C2=A0










On the other hand, I'm not sure this option will=
 give us much help. Chris mentioned much knowledge intermediate router woul=
d have to decide this value (and how much sense the value would make).=C2=
=A0










Another issue is, a route to a destination might be =
updated by different sources. For example, in the network below:<=
/u>










=C2=A0










A-=
---B-----C










=C2=A0










A first establish a route to B with long validity ti=
me. Then A initiates a route discovery to C. C tends to set a short validit=
y time, which will make the route between B and A expire earlier than expec=
ted.=C2=A0










Is this a problem? Maybe yes, maybe no -- I'm no=
t sure it's considered or not.=C2=A0










=C2=A0
















=C2=A0








Not sure I follow here.=







Currently, the validity=
 time of the route between A and B would not affected by a short validity t=
ime of a route between A and C. Validity times are per-route, and the route=
 A-B and the route A-C are separate.








If we switched to a validity time per neighbor (so t=
hat we can keep validity time separate from route advertisements) as I ment=
ioned in the email below, then the validity of a route between A and C woul=
d be affected if there was a short
 validity time between A and B. But, if B will only route for a certain amo=
unt of time, then the route between A and C will of course be affected. Is =
it best to know in advance that there's a time limit, or just deal with=
 RERRs when they happen?








=C2=A0







=C2=A0






















=C2=A0






With regard to the acknowledgements, the pro=
blem (with regard to security) comes from trying to do two jobs with the sa=
me message - end to end route advertisement
 and hop by hop acknowledgement. I understand the reasons - saving bytes an=
d message types. (I would have to study the protocol really hard to identif=
y if any message types can be folded together and recognised by content rat=
her than type efficiently. This
 I do not expect to do.) Again a tradeoff. This one is in discussion space,=
 though that needs people who understand both sides of the issue, including=
 the details of the bidirectionality mechanism. Of course, as has been said=
, we need one of those.














=C2=A0










I haven't finished my review of the latest draft=
, and I don't get the necessity of AckReq and the corresponding multica=
st RREP yet.=C2=A0










If possible, this "optional" field should =
be avoided.=C2=A0










=C2=A0


















To give an overview of AckReq and RREP:






Since AODVv2 requires b=
idirectional links, this is the way to determine if a link is bidirectional=
.








A----B----C












1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install a=
 route to OrigAddr but they dont yet know if it's valid because they do=
nt know if the link to their next hop is available in the reverse direction=
.










2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).










3) B receives the RREP, installs a route to TargAddr=
 and marks it as valid, since it knows the link to C is bidirectional, beca=
use the RREQ went in one direction and the RREP came in the other. B also s=
ends the RREP_Ack to C and forwards
 the RREP to A (and might change the message to indicate its own AckReq - i=
e that it requires an ack from A).










4) C receives the RREP_Ack from B, and therefore kno=
ws that B received the RREP, therefore the link is bidirectional. C can the=
n mark its route to OrigAddr as valid.










5) Similarly, A receives the RREP, installs the rout=
e to TargAddr and sends an RREP_Ack to B.










6) B receives the RREP_Ack and marks its route to Or=
igAddr as valid.










=C2=A0








Alternatively, in step =
2, if C knows the link to B is bidirectional (perhaps from some earlier rou=
te discovery), it doesnt need to put the AckReq in the RREP. Then in step 3=
, since B doesnt know if the link
 to A is bidirectional, it changes the message to add the AckReq address, i=
n order to get an RREP_Ack from A.






If we want to avoid cha=
nging the message, we'll need to look at forwarding the RREP as-is, and=
 creating a second message to solicit an RREP_Ack, in order to verify that =
the link is bidirectional before marking
 the route to OrigAddr as valid.=C2=A0








Kind regards,










Victoria.








=C2=A0







=C2=A0


















regards










=C2=A0










Jiazi










=C2=A0














=C2=A0




--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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






From:=C2=A0Victoria Mercieca [mailto=
:vmercieca0@gmail.com]=C2=A0

Sent:=C2=A023 April 2016 10:55

To:=C2=A0Christopher Dearlove

Cc:=C2=A0ietf@thomasclausen.org; Dearlove, =
Christopher (UK); Mobile Ad Hoc Networks mailing list<=
/p>











Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=C2=A0






=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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.










Hi Chris,








=C2=A0










These have both been in the draft in some form since=
 before I got involved... but I'll do my best to explain.=









=C2=A0










- For Validity Time, its a way to advertise that you=
 would only support the route contained in the message for a certain period=
 of time. The originator might use this, but the draft was written to allow=
 any intermediate node to be able
 to add it or update it too. The route created in the Local Route Set has a=
n expiration time associated with it, based on the received validity time.<=
u>










- For the AckReq address, its so that you can add in=
to a RREP a request for an acknowledgement, so that you don't have to h=
ave a different message type altogether for working out whether links to ne=
ighbors are bidirectional, and also, since
 you only care about bidirectionality on routes that are being set up, you =
dont need to constantly monitor all neighbors.










=C2=A0










=C2=A0










In order to avoid the potential AckReq-related chang=
es to each message, maybe we do need to introduce a different message speci=
fically for this. We could maybe use RREP_Ack to both request and acknowled=
ge? It means an extra message of control
 traffic that needs to be sent, maybe one extra message per hop on the path=
 of a RREP, but it could still be limited to neighbors which have participa=
ted in the route discovery rather than monitoring all neighbors at all time=
s.=C2=A0










=C2=A0










This message could maybe also include "I'm =
happy to route anywhere for a certain amount of time", sort of like wi=
llingness in OLSR/OLSRv2. So instead of having a validity time per route, i=
ts a validity time per neighbor. Then, for RREQ
 and RREP, only the metric value would change in transit, as discussed. How=
ever, that leads to some issues with deciding what a route's expiration=
 time is. You might know how long the next hop router is valid for, but wha=
t if a router beyond that, which was
 also part of the route, had a lower validity time? You couldn't determ=
ine the real validity time. Do we remove the route expiration time altogeth=
er to avoid this issue? In which case, we would have to rely on RERR messag=
es being sent for routes which become
 invalid when the neighbor's validity time has expired? So neighbor val=
idity time expiration is treated the same as a link break.









=C2=A0










What do you think?










=C2=A0










Kind regards,










Victoria.










=C2=A0










=C2=A0










=C2=A0










=C2=A0










=C2=A0












=C2=A0








On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlov=
e <chris@mnemosyne.demon.co.uk> wrote:<=
u>










Pretty much all of the discussion has been assuming =
only a metric value change. With multiple things changing many of the ideas=
 go out of the window. That reinforces the point about not making specifica=
tions now that might turn out to be
 wrong for ICVs.










=C2=A0










Ignoring how this misunderstanding happened, I'l=
l start by asking why. Metric changing I understand. Why the other two? (th=
ere's a partial explanation of one). What alternatives have people impl=
emented in comparable protocols?



-- =C2=A0








Christopher Dearlove














On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmai=
l.com> wrote:


















Hi all,










=C2=A0










Continued in this thread because the other one seems=
 to be more about TLV types and metric type numbers, whereas this is about =
regeneration/forwarding.










=C2=A0










To recap, in the current draft, there are 3 things t=
hat might change at each hop:=C2=A0

- the metric value (happens in RREQ and RREP),=C2=A0

- adding/changing Validity Time using the Validity Time TLV (can happen in =
RREQ and RREP),=C2=A0

- adding an address (and corresponding value in the AddressType TLV to indi=
cate how to interpret the address) to indicate the address from which an RR=
EP_Ack is expected, to accomplish the bidirectionality check (can happen in=
 RREP).



If we define=C2=A0a certain portion of the message as immutable and include=
 the ICV to verify that part, end to end:=C2=A0

- The metric value would be excluded from the ICV since it needs changing a=
t each hop.=C2=A0

- Would adding a Validity Time TLV at an intermediate hop be acceptable? Th=
e whole TLV could be removed in order to calculate the ICV?







- Would adding an address cause issues for the ICV, =
because it's in the address block? Could the rule be "if it contai=
ns an AckReq address, remove it (and the corresponding value in the Address=
Type TLV), before checking the ICV", is that
 OK? Or would we need to avoid touching the ICV'ed part of the message =
altogether, maybe put the AckReq address in a separate Address Block, with =
an extra AddressType TLV following that address block? Is there a way to ac=
complish this?










=C2=A0










Also, to be thorough, do we need to consider RERR me=
ssages while we discuss regeneration vs forwarding?=C2=A0










- RERR (sent when a link breaks) is a way of saying =
"I've lost my route so I'm telling others" and "you =
were my next hop, so=C2=A0now=C2=A0I've also lost my route, I'll te=
ll others", etc. It's going to be tailored at each step to include=
 the relevant
 routes that got deleted, it's not one message being sent end-to-end li=
ke RREQ and RREP are.=C2=A0










- However, RERR (sent when a source of traffic is se=
nding data on a route which comes through you, and you want to tell the Pac=
ket Source's router to delete the route) could be seen as an end-to-end=
 message which all intermediate routers
 learn from, similar to RREQ and RREP. It reports one route, and doesn'=
t need changing at intermediate hops, so could be protected with ICV.










- Would it be OK to only require a message ICV if a =
PktSource address was included, i.e. when the message needs to go via a num=
ber of intermediate hops to PktSource's router? All other RERRs are int=
ended to be one-hop messages, which may
 in turn prompt other one-hop messages, etc..., and a packet ICV might be m=
ore appropriate?










=C2=A0








Kind regards,








Victoria.










=C2=A0








On Thu, Mar 17, 2016 at 5:26 PM, <i=
etf@thomasclausen.org> wrote:








=C2=A0












On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:








=C2=A0












Yes, I meant AODVv2, thanks for the catch.










=C2=A0










So is your (Thomas) proposed base specificat=
ion a hop count only metric?
















=C2=A0








No, the would be silly as base specification, given =
that hop count mostly is useless.










=C2=A0










As base specification I would simply say =E2=80=9CIn=
clude a Metric Type Message TLV with a value field, and a 7182 Message TLV =
& Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage =
as to generation and processing).=C2=A0










=C2=A0










With the message generated by the originator of the =
RREQ/RREP and *not* deconstructed/reconstructed/reordered (as is the risk w=
ith =E2=80=9Cregeneration) allows knowing that it would be *only* that metr=
ic field being modified (other than hop count/limit)
 for when eventually writing up the extension.










=C2=A0
















(Actually doesn=E2=80=99t the current specif=
ication only define hop count, or has that changed in latest draft?)=















=C2=A0








No. That is one of the issues I raise in my original=
. For some reason, it cites RFC6551, which is a ROLL document and which has=
 in its abstract that:










=C2=A0








=C2=A0=C2=A0 Low-Power and Lossy Networks (LLNs) have unique character=
istics


=C2=A0=C2=A0 compared with traditional wired and ad hoc networks that =
require the


=C2=A0=C2=A0 specification of new routing metrics and constraints. =







=C2=A0










I.e. this document cites a metric document which cle=
arly claims to be inapplicable in ad hoc networks. I note that this is anot=
her thing I=E2=80=99ve raised for years without seeing it attempted resolve=
d.










=C2=A0










Best,










=C2=A0










Thomas










=C2=A0










=C2=A0














=C2=A0








--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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














From:=C2=A0ietf@thomas=
clausen.org=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 17:10

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Lotte Steenbrink; Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=C2=A0








=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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=A0
















On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:












=C2=A0














OK, so we have a message that mutates by:














- Modifying hop count/limit.














- Modifying a metric value.=















Anything else?














=C2=A0














As mutating (other than hop count/limit) mes=
sages aren=E2=80=99t covered by 5444 or any derivative document (but only r=
ecommended against, not banned) that you may
 need to make the message otherwise immutable (no deconstruction and rebuil=
ding, other than guaranteed unchanging) that would have to be specified by =
AODVv2. (Easy to say, but needs saying.)


















=C2=A0












With you so far.












=C2=A0









Then that information is not in a guaranteed=
 fixed location given by a simple offset. So any signature algorithm that f=
inds it and ignores it or aggregates
 on it is specific to OLSRv2.














=C2=A0












Surely you mean AODVv2












=C2=A0









So standard 7182 ICVs don=E2=80=99t do the j=
ob, you would need an AODVv2 specialised variant. Which is the sort of thin=
g that the message specific TLV space is there
 for, I=E2=80=99d be strongly against a =E2=80=9Cbut ignore the value of th=
is specific TLV should it occur=E2=80=9D being in the general space. Howeve=
r it can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like =
that TLV, except if an X TLV is present, set its value field to
 zero=E2=80=9D).














=C2=A0














Messy, but could work.<=
/p>













=C2=A0












Not that messy, actually, although clearly not as ni=
ce as =E2=80=9Cfixed offset=E2=80=9D.














=C2=A0














That said, I am arguing for the base spec being:<=
/u>














=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=E2=80=9Cmake the message otherwise immutable (no deco=
nstruction and rebuilding, other=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=A0than guaranteed unchanging)=E2=80=9D which is af=
forded by forwarding














=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7182 Timestamps and ICVs.














=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7183 style text bringing it all together.=















=C2=A0














The =E2=80=9Caggregated signatures around mutable fi=
eld=E2=80=9D would very be an experimental extension.














=C2=A0














What I object to is, if the base spec specifically r=
enders such extensions impossible














=C2=A0












=C2=A0









=C2=A0










--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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


















From:=C2=A0Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]=C2=A0

Sent:=C2=A017 March 2016 16:48

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0ietf@thomasclausen.org; Mobile Ad =
Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)


















=C2=A0










=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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.












Hi all,
















=C2=A0




















Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher=
 (UK) <chris.dearlove@baesystems.com>=
:
















=C2=A0


















Good point about whether you just pass on on=
e cost or a set of costs. As I said, not looked at details - I will, when t=
ime permits. One cost is much easier,
 and yes, it reduces the fixed size aggregated signatures problem to =E2=80=
=9Cjust=E2=80=9D one of computational load.






















=C2=A0


















For the record, Thomas=E2=80=99 understanding is cor=
rect; the cost is one aggregated value.=C2=A0


















=C2=A0


















Best regards,=C2=A0


















Lotte Steenrbink














=C2=A0















=C2=A0












--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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






















From:=C2=A0ietf@thomas=
clausen.org=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 16:38

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: Message integrity and message mutability (was RE: =
[manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)






















=C2=A0












=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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=A0
























On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:




















=C2=A0






















I appreciate Thomas=E2=80=99s comments about=
 the limitations of message regeneration, but I would be a bit less absolut=
e.






















=C2=A0






















The issues over end to end authentication an=
d more advanced signatures are valid. I need to read the given reference on=
 aggregate signatures to increase my
 knowledge (thanks for it), but my understanding of the possibilities in th=
is field may offer a solution to the problem, but with some other issues (p=
ossibly including a new type of TLV).






















=C2=A0






















But the hop count/limit point I don=E2=80=99=
t fully agree with, you can regenerate with an incremented/decremented coun=
t/limit, which leaves the ability to prevent
 messages propagating indefinitely, including expanding ring searches, and =
retains the ability to use RFC 5497 interval and validity times that might =
be useful with an expanding ring search (or might not).






















=C2=A0






















But the key issue is that AODVv2 wants to ac=
cumulate metrics. I still haven=E2=80=99t got to the bottom of many details=
 here, but let=E2=80=99s for the moment just consider
 that conceptually.






















=C2=A0






















It=E2=80=99s hard to handle end to end. Char=
lie=E2=80=99s draft attempts to do an end to end of some information, not t=
his information. I=E2=80=99m not sure if that=E2=80=99s useful (and the
 specialised format is better avoided if possible). Other approaches are ho=
p by hop (might as well use packet signatures) and shared key (might as wel=
l go hop by hop). Pairwise signatures for each pair of routers I=E2=80=99m =
discounting as scaling terribly. In the
 interests of completeness let=E2=80=99s mention not accumulating metrics, =
which puts us back to hop count and that=E2=80=99s not ideal either.=























=C2=A0






















I don=E2=80=99t think there is an ideal solu=
tion. (I like ideas I=E2=80=99ve seen about aggregating, but that has some =
issues of its own, even apart from computational load.)
 I=E2=80=99d love to be proved wrong - someone with the perfect solution to=
 come along.






















=C2=A0






















Which means that either we make an arbitrary=
 choice - which will be disagreed with, but needs discussing first - or cre=
ate something flexible. Unfortunately
 flexible in that regard constrains in others, e.g. some (many? most?) aggr=
egating signatures need fixed data sizes (which we can do by defining a TLV=
 that =E2=80=9Cfills up=E2=80=9D with hop count, but that has a cost too).<=
/span>


























=C2=A0




















I have been told by people much more well versed in =
this than I in cryptology, that the correct answer is =E2=80=9Csome=E2=80=
=9D.






















=C2=A0






















That said, "AODVv2 wants to accumulate metrics=
=E2=80=9D =E2=80=94 does that mean that the message grows as it is being fo=
rwarded, and that the recipient of a RREQ/RREP will know the individual cos=
ts of each path segment? My understanding is, that the recipient
 will get =E2=80=9Cthe sum the costs of each path segment=E2=80=9D which sh=
ould be fitting within a fixed size?






















=C2=A0






















Thomas






















=C2=A0




















=C2=A0



















=C2=A0






















Sorry, no answers, just comments. And I=E2=
=80=99m not addressing Thomas=E2=80=99s later points here.=























=C2=A0














--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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


























From:=C2=A0manet [mail=
to:manet-bounces@ietf.org]=C2=A0On
 Behalf Of=C2=A0ietf@thomasclausen.org

Sent:=C2=A017 March 2016 16:00

To:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0[manet] draft-ietf-manet-aodvv2-13 review - a couple o=
f big ticket Items


























=C2=A0














=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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***

EXTERNAL=
 EMAIL -- This message originates from outside our organization.<=
/u>














=C2=A0
























Dear all,
























=C2=A0


























Apologies for not having gotten this done sooner - d=
ay-job leaving few spare cycles.


























=C2=A0


























I=E2=80=99ve previously offered reviews and comments=
, and some of those have been addressed in the latest I-D =E2=80=94 others =
have not, but should be. I recall that there was some mail attempting to re=
but parts of the review, and I will dig it out and
 reply to that.


























=C2=A0


























With that being said, I have reviewed the latest ver=
sion of the document, and full details will be forthcoming. There=E2=80=99r=
e a couple of big-ticket/architectural items that I want to address up fron=
t, as I believe that before we have those
 hammered out, it will be useless to go into details. Note, I do not claim =
that this is an exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D, but =
that=E2=80=99s as far as I have gotten in thinking this through.<=
/u>


























=C2=A0


























I also bring these up as they are items that have be=
en brought up repeatedly over the past years, but not resolved nor discusse=
d.


























=C2=A0


























Loops


























Just to bring this out: I share Chris=E2=80=99 worry=
 about conflicting and concurrent statements from the authors on =E2=80=9CT=
here are no loops possible=E2=80=9D and =E2=80=9CWe need to fix two situati=
ons where loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating =
some loop
 conditions=E2=80=9D


























=C2=A0


























I particularly worry that this is not a discussion h=
ad in public, but apparently in some other forum=E2=80=A6


























=C2=A0


























=C2=A0




























Intermediate Route Replies, and all of section=
 10


























Section 10 contains a set of =E2=80=9Cvaguely specif=
ied extensions=E2=80=9D, which is incoherent with the intended status indic=
ated for this document.=C2=A0


























=C2=A0


























Specifically, and this is not unrelated to the point=
 about loops above, intermediate RREPs (section 10.3) are a potential sourc=
e for loops.


























=C2=A0


























Expanding Ring Multicast (section 10.1) is not docum=
ented in a way that can be implemented (and also, see =E2=80=9CForwarding-v=
s-regeneration=E2=80=9D below, it is in the present form of this protocol i=
mpossible), etc.




























=C2=A0


























=C2=A0


























Forwarding-vs-regeneration


























Recent exchanges on the list made me understand that=
 protocol control messages are *not* forwarded, but are consumed at each ho=
p, then a new message with (almost-but-not-quite) the same content is gener=
ated and transmitted.


























=C2=A0


























I have thought some more on this (& read some of=
 the exchanges on the list on this topic by Chris, Ulrich, and others), and=
 I am convinced that this is not the right way to go,=C2=A0at least=
=C2=A0for the following reasons:


























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It renders the hop-limit/hop-count fields in the RFC5444 messag=
e header useless.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0This would not be bad if the functionality offered by tho=
se fields was not useful


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=94 sadly, it is. For example, for scope limited fl=
ooding (expanding ring search, and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0such) which may be of interest, and which require hop-lim=
it.=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0A hop-count field may also provide a =E2=80=9Ccheap=E2=80=
=9D (in terms of overhead) additional piece


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of information to use conjunctively with a =E2=80=9Creal=
=E2=80=9D metric.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The only practical solution would be to re-introduce thes=
e functions by way of inserting a


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0MessageTLV =E2=80=94 which (i) is not specified in this d=
ocument, and (ii) which would just


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0serve to render messages bigger than strictly needed.<=
/u>


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Scope limited flooding =C2=A0does seem to be a necessary =
requirement, if for no


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0other reason than to prevent information from =E2=80=9Cci=
rculating forever in the network=E2=80=9D.


























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It makes end-to-end authentication unnecessarily hard.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I think Chris called this out already, but it bears repea=
ting: S generates a message=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(say, a RREQ), and includes an ICV calculated over the co=
ntent of the message.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0For any recipient to be able to validate the ICV, the mes=
sage has to be exactly


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0the same =E2=80=94 not just in content, but in structure =
=E2=80=94 as what was generated.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforwa=
rding=E2=80=9D messages means, that the intermediate


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose =
a different structure (e.g., include TLVs


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0in a different order).


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The proposal from=C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00=



























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0is to add constraints on (i) the set of elements to inclu=
de in a signature and (ii) the


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0order of these elements.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0One=C2=A0problem with that approach is (i): if an extensi=
on adds a message TLV, or an=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Address TLV, to a message, then that will not be =E2=80=
=9Ccovered=E2=80=9D by the proposed e2esec TLV.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Rather for *each* extension developed, an =E2=80=9Cupdate=
s e2esec=E2=80=9D clause needs to be done.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I=E2=80=99d say that this approach would be prone to erro=
rs =E2=80=94 and add entropy to the process


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of designing protocol extensions. The alternative, a mess=
age being generated by the


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0source and *forwarded* (as we do in OLSRv2, for example) =
would allow ICV TLVs=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(even, allow reuse of those specified for OLSRv2) for cov=
ering a message and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0extensions.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CBut what about the metrics value which will chan=
ge on each hop=E2=80=9D, you may say?


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Fortunately, that is relatively easy to handle: simply ze=
ro out the value of that TLV when


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0generating or verifying the ICV MessageTLV. And use Packe=
t-TLVs for hop-by-hop=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0authentication, if needed (but, see below).=



























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It prevents the use of more clever/advanced signature scheme=
s/ICVs


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Aggregate signature algorithms (=C2=A0https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf<=
/span>)


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0exist, and an interesting use-case can be found in also r=
eactive protocols, allowing verifying


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0not =E2=80=9Cjust=E2=80=9D the end points, but also the i=
ntermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0discussed above, or something smarter).


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Regeneration of messages, rather than forwarding, renders=
 that impossible (or, if used,


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0updating to =C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)


























=C2=A0


























There are other reasons, but the above are those tha=
t jump at me as immediate show-stoppers.


























=C2=A0


























I do honestly not see what possible benefit there is=
 from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inconve=
niences, and security is not the least of these. Insisting on =E2=80=9Crege=
neration=E2=80=9D requires development of =E2=80=9Cnon-general workarounds=
=E2=80=9D as pointed
 out above.


























=C2=A0


























Security Considerations<=
/p>

























This is an always thorny subject. When OLSRv2 was go=
ing through the process we got a thorough education in how little we knew a=
bout security from the SEC-ADs, and had to spend about a year or so develop=
ing RFC7183. The bottom line is, that
 this protocol needs its =E2=80=9CRFC7183 =C2=A0equivalent=E2=80=9D, either=
 as part of the main document, or as an independent document. currently, th=
at is not the case.


























=C2=A0


























A minima, looking at BCP72 and BCP107 =E2=80=94 taki=
ng inspiration from RFC7183 might be aw good idea, as that was the most rec=
ent that went through the SEC AD. Regardless of how, however, a =E2=80=9Cma=
ndatory to implement=E2=80=9D security mechanism most be specified
 (I think the right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D),=
 in sufficient detail to ensure interoperable implementations.


























=C2=A0


























As an example, both [RFC6130] and [RFC7181] set out =
that that:




























=C2=A0


























=C2=A0 =C2=A0 =C2=A0 On receiving a ... message, a r=
outer MUST first check if the


























=C2=A0 =C2=A0 =C2=A0 message is invalid for processi=
ng by this router


























=C2=A0


























and then proceed to give a number of conditions that=
, each, will lead to a rejection of the message as "badly formed and t=
herefore invalid for processing=E2=80=9D =E2=80=94 a list which RFC7183 the=
n amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting
 =E2=80=9Crejection=E2=80=9D. Idem for message generation.

























=C2=A0


























If I was to do RFC7181/RFC6130 today, I would includ=
e that directly into the protocol specifications. It turned out to be more =
overhead (and slow down publication anyways) to do it as separate documents=
.




























=C2=A0


























Secondly, we need to be a lot more rigid in terms of=
 what ICVs, Timestamps, etc. are added/removed, and what that brings.


























=C2=A0


























For example (with the assumption that messages are *=
forwarded* and *not* regenerated), this could be one option:<=
/p>

























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0When a RREQ, RREP message is generated, add an ICV Message TLV, which=
 is calculated <this way>


























=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=E2=80=A6(take inspiration from RFC7183 here)


























=C2=A0


































...



[Message clipped]=C2=A0=C2=A0

_______________________________________________

manet mailing list

manet@ietf.org

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/manet






=C2=A0
















_______________________________________________

manet mailing list

manet@ietf.org

<=
span style=3D"color:purple">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 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

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/manet








=C2=A0














=C2=A0










_______________________________________________

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




=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







--001a1147dab0e9d0ce05315104ec--


From nobody Mon Apr 25 08:51: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 9596212D137 for ; Mon, 25 Apr 2016 08:51:23 -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 qviA4x74YuQB for ; Mon, 25 Apr 2016 08:51:22 -0700 (PDT)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 7684612B05C for ; Mon, 25 Apr 2016 08:51:22 -0700 (PDT)
Received: by mail-io0-x236.google.com with SMTP id 2so187986645ioy.1 for ; Mon, 25 Apr 2016 08:51:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim;  h=mime-version:date:message-id:subject:from:to:cc :content-transfer-encoding; bh=RtjJ04MWnDOO0AtgQseksS98LVoattqrXKdadsBlWao=; b=N+rMQZFDsgM3LhRfqAzll9cJq2+ZD3v48oOJMQbqSIShINUHAdvAQqv+eP1RFphw+x z5UfyCPwdOTyEEPtJq6dS1bEM1RVrf8mRPJQ9dLgKxi/t7NF/2cgPmZr+nWCA434BxPI r3IEyNQhXO2uCZ6/yA3rjGFuKRUdPAG/FJ994=
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 :content-transfer-encoding; bh=RtjJ04MWnDOO0AtgQseksS98LVoattqrXKdadsBlWao=; b=U3NISTR2yj4y/+zA1r9FVuhOLIK6W9Vh71KgKxz2n+7yEFidg6CHRxsSmHk/FHAp6s /XteZCElMwu+Yn8G1CnNuJ7GodI5D5oCATeKYVxJXJH9wZ76MC6jPQB2ho/bRj+JLJuw OAn+oikkVlw0D2BnHkr1icScn86ZMOLvZ3tStdFRDGM/+cW9fnGLfQDZaqNjAUK6Vqvv jyLoFnD7QZsY/M9kCops+bQ74N7YjszFJkXtlZZMo52igDH1ZU6reIpkil1qzqxSlnQb 53LvLiIk3Hai0x9ivdC0wWC/C3T3gdxQLkaLK+RHx6XjIfkKkcni2/RygjDIRGrpPQ5z MEBQ==
X-Gm-Message-State: AOPr4FU9yhbf52DmWO+P0+2fy/USWjV1OOli9SQKpEVjd8daYWvTn+QYlsL8ZkmAtStvqf4MNxLrESZvgamM/w==
MIME-Version: 1.0
X-Received: by 10.107.180.194 with SMTP id d185mr16594961iof.151.1461599481558;  Mon, 25 Apr 2016 08:51:21 -0700 (PDT)
Received: by 10.36.86.142 with HTTP; Mon, 25 Apr 2016 08:51:21 -0700 (PDT)
Date: Mon, 25 Apr 2016 08:51:21 -0700
Message-ID: 
From: Ulrich Herberg 
To: Thomas Heide Clausen 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Christopher Dearlove , Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: [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, 25 Apr 2016 15:51:24 -0000

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 n=
ecessity of
> a mechanism for handling these, I want to call attention to a related iss=
ue,
> 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 this
>    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 conclusi=
on 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 link t=
he metrics
> is 4 or 5=E2=80=9D, the protocol must be able to convey and distinguish t=
hat =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 mechanis=
m:
> that exchange could, if designed carefully, be used to probe for and conv=
ey
> metrics information, also.


From nobody Mon Apr 25 10:21:46 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 F133F12D64F for ; Mon, 25 Apr 2016 10:21:44 -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 idyuaYUcHbbU for ; Mon, 25 Apr 2016 10:21:43 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 6CA0212D63D for ; Mon, 25 Apr 2016 10:21:42 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id j74so198367655ywg.1 for ; Mon, 25 Apr 2016 10:21:42 -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=SQOuhFVUoOWvvPKKYjbQBOMTlcWbLy/9owA9Olqx0+g=; b=gZLrAqkr9X2YV0akg6jLhZqOVeoYA3d1qzyhkL2MbK7JGDZQgfwhrqdX9mIVT1NTBQ vPmS5XUmNoDHWKHx05BCOeVjOqWDY0BlsUBJ7nF3exbUQcOqSzqKtzKe2fR86aYA7ri4 GsSP6qbR21mW0KX2Ew2sjjmwBv7fjxZ5Vk51beuOLyn7iem5GdGEP+IrEWd/l4pR/UPF y8NxFOr/9ud3ZcIO80ni+tHiacUuFFgnPT9bqehk/Amptca9c4LtUVPqZRKBooFzkDk0 l1M5GrxJ9FxQpFEq5MO0lzCnzCBS3Yhv6tgpqJptRb7uQZ6KrU1lJscl2z3llDTbn77n 6DCQ==
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=SQOuhFVUoOWvvPKKYjbQBOMTlcWbLy/9owA9Olqx0+g=; b=HKfTX8vQnCL4XMQ/MOkl23KokjhqwhxTpXDEXgwN0Er/Vxqw7n921a3sBIxbPJ4WtP +xONNCU91kqxSG/uI565VcemV5a9v5AaiX6RCJamww41pyuzrNUIX9jLEVpel6N9q+ii S2BLwxnZ8gjJORykXyCrQf+B+yaiR2ZAjP+ZLgfTyDn0oiimgKwKXTL4hcgmUp2V+RME U+T+bBtN05CVJvN4MzLOuJTUF7Hs2405l21f6vzk341BFdvDNB8Lw1lFZ7hATcxy3oqY qTgU/6i9mhHH+P05VUR2hmtcxKHDFuVTPNgBHBMoLx1s3cHbo6x1Wj1ptRQqIvqTJZSq X/6g==
X-Gm-Message-State: AOPr4FWa4McHf1utvIFfFOGyLLRl24oMb33gtBKTJXKJvOmqRgPzxSePkEHInvvXm646+OTT0ed1NYPOQxym6A==
MIME-Version: 1.0
X-Received: by 10.176.4.20 with SMTP id 20mr20491868uav.125.1461604901628; Mon, 25 Apr 2016 10:21:41 -0700 (PDT)
Received: by 10.176.65.40 with HTTP; Mon, 25 Apr 2016 10:21:41 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 25 Apr 2016 18:21:41 +0100
Message-ID: 
From: Victoria Mercieca 
To: Ulrich Herberg 
Content-Type: multipart/alternative; boundary=001a114fd886f6b21b05315268f6
Archived-At: 
Cc: Christopher Dearlove , Christopher Dearlove , 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, 25 Apr 2016 17:21:45 -0000

--001a114fd886f6b21b05315268f6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 route
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 which 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 related
> 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 installe=
d
> >    in the Local Route Set at each router will be correct.  While this
> >    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 conclu=
sion 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 link=
 the
> metrics
> > is 4 or 5=E2=80=9D, the protocol must be able to convey and distinguish=
 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 wi=
th 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
>

--001a114fd886f6b21b05315268f6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Ulrich,

Do we just need to add up li=
nk costs looking backwards to where the message came from? Back toward Orig=
Addr 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 th=
e message.

At RREP_Gen we would end up with the ro=
ute cost looking in the correct direction from RREP_Gen back to OrigAddr, a=
long the reverse of the route the RREQ took (although that's not necess=
arily the optimal route to OrigAddr), and at RREQ_Gen we would get the rout=
e cost along the optimal route which the RREQ travelled on, from RREQ_Gen t=
o TargAddr.

Kind regards,
Victoria.

On Mon, Apr 25, =
2016 at 4:51 PM, Ulrich Herberg <ulrich@herberg.name> wrot=
e:
Hi,



I am in the process of reviewing the AODVv2 draft, and like Thomas, I

was surprised about your conclusion to move "asymmetric links" ou=
t 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 thi=
s

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 here, and th=
e 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 wireless, mul=
tihop

>=C2=A0 =C2=A0 networks.

>

>

> Section 5 paragraph 4=C2=A0 of the document, however, reads:

>

>=C2=A0 =C2=A0 Assuming link metrics are symmetric, the cost of the rout=
es installed

>=C2=A0 =C2=A0 in the Local Route Set at each router will be correct.=C2=
=A0 While this

>=C2=A0 =C2=A0 assumption is not always correct, calculating incoming/ou=
tgoing

>=C2=A0 =C2=A0 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 concl=
usion 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 lin=
k the metrics

> is 4 or 5=E2=80=9D, the protocol must be able to convey and distinguis=
h 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 w=
ith the

> bi-directionality check) be in the triggered neighbour detection mecha=
nism:

> that exchange could, if designed carefully, be used to probe for and c=
onvey

> metrics information, also.



_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet





--001a114fd886f6b21b05315268f6--


From nobody Mon Apr 25 19:39:32 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 73D5612D096 for ; Mon, 25 Apr 2016 19:39:31 -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 QuNbXxkjtUtV for ; Mon, 25 Apr 2016 19:39:29 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 A47C612B008 for ; Mon, 25 Apr 2016 19:39:29 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id d62so3797839iof.2 for ; Mon, 25 Apr 2016 19:39:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=EYIdXAHIDLPv/8uZMiAVdzhCWQxqhWXEKmWpKoOaJNo=; b=oQJak6xZ2XK0E7RKbruoog5htKuNBJIEjQL/PmjJEHHhKkvqWfOWRISA83Hqc5GY9T 8sE+28Cf4TPq4J5s+jnwZhNuyQ+afO4P4uUH+wcnoqFTbRfpS5u8bjP2HpRnj/LdaIK2 wKFfMcL6gOtDNOkPB0Zt+hn8zr/7Lj0t+lKpw=
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:content-transfer-encoding; bh=EYIdXAHIDLPv/8uZMiAVdzhCWQxqhWXEKmWpKoOaJNo=; b=C1f2dmtggLIB/APhPeWunrfdsaMUDn1ARV4UCxlvpQWjmO/tW5TE/foUmBvAvG+Uwj Qv6NgnkWch0qr37ooE6AySxwTYEK15A+j8i/ovC5H25w78wq2p6gU3/vaSkmD3XDrL9o yinTxDOy0vP4Hc48HGCwaol7MjJEeuuXBZn4wk9JHdJnvjRH28pHrINSUo/3n38Tv8Tq hP5vgu1LSj1P4VpiQDZsxTxV5fhZqAK0J/jLaZosn77W8eIdnMgw8U8Yimm/8gg04UT5 jFPaa8mjqjpg7GT9HsFO2wytP++u0j8jYmJkIjlCUGjxcVItFaYrNVdv6dTsdfjt8x2I MveQ==
X-Gm-Message-State: AOPr4FWuSX4ox3oVmBXd4IiPDqdAUVorfiUuuWvf3AAYETJnOFsgB088fJvle2Ln2nEMre6XBYcTwFzrTQkEYw==
MIME-Version: 1.0
X-Received: by 10.107.168.85 with SMTP id r82mr547883ioe.179.1461638368770; Mon, 25 Apr 2016 19:39:28 -0700 (PDT)
Received: by 10.36.86.142 with HTTP; Mon, 25 Apr 2016 19:39:28 -0700 (PDT)
In-Reply-To: 
References:  
Date: Mon, 25 Apr 2016 19:39:28 -0700
Message-ID: 
From: Ulrich Herberg 
To: Victoria Mercieca 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Christopher Dearlove , Christopher Dearlove , 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: Tue, 26 Apr 2016 02:39:31 -0000

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 messa=
ge
> 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 l=
ast
> 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 route =
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 which
> the RREQ travelled on, from RREQ_Gen to TargAddr.
>
> Kind regards,
> Victoria.
>
> On Mon, Apr 25, 2016 at 4:51 PM, Ulrich Herberg  wro=
te:
>>
>> 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 th=
e
>> > 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:
>> >
>> >    ...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 install=
ed
>> >    in the Local Route Set at each router will be correct.  While this
>> >    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 concl=
usion 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 lin=
k the
>> > metrics
>> > is 4 or 5=E2=80=9D, the protocol must be able to convey and distinguis=
h 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 w=
ith 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
>
>


From nobody Tue Apr 26 01:44: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 76ABF12D0C2 for ; Tue, 26 Apr 2016 01:44:09 -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 oA9GNfjerNke for ; Tue, 26 Apr 2016 01:44: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 7070912B01F for ; Tue, 26 Apr 2016 01:44:05 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,536,1454976000"; d="scan'208,217"; a="34229323"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 26 Apr 2016 09:44:03 +0100
X-IronPort-AV: E=Sophos;i="5.24,536,1454976000";  d="scan'208,217";a="115482155"
Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 26 Apr 2016 09:44:02 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.34]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Tue, 26 Apr 2016 09:44:01 +0100
From: "Dearlove, Christopher (UK)" 
To: Victoria Mercieca , Ulrich Herberg 
Thread-Topic: [manet] Symmetric link metrics (was: Re: Message integrity and message mutability)
Thread-Index: AQHRnxbwhtMff84LEkCStHnfcl2th5+b8CUw
Date: Tue, 26 Apr 2016 08:44: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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1759GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: 
Cc: Christopher Dearlove , 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: Tue, 26 Apr 2016 08:44:09 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1759GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

SWYgeW91IGFsc28gY2hhbmdlIG1ldHJpY3MgaW4gYW4gUlJFUSAod2hpY2ggaWYgeW91IHdhbnQg
dG8gZXN0YWJsaXNoIGFzeW1tZXRyaWMgbWV0cmljcyBib3RoIGVuZHMgdG8gZWFjaCBvdGhlciBp
cyBsb2dpY2FsKSB3aGF0IGFjdHVhbGx5IG5vdyBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGFu
IFJSRVEgYW5kIGFuIFJSRVAuIChFdmVuIGlmIHlvdSBtdWx0aWNhc3Qgb25lIGFuZCB1bmljYXN0
IHRoZSBvdGhlciwgb3IgbXVsdGljYXN0IGJvdGggYnV0IG9uZSBvbmx5IG9uIG9uZSBpbnRlcmZh
Y2UsIHRoYXTigJlzIG5vdCBhIGRpZmZlcmVuY2UgaW4gdGhlIG1lc3NhZ2UuKSBPZiBjb3Vyc2Ug
eW91IG1heSBuZWVkIHRvIGtub3cgd2hpY2ggb25lIGEgcGFydGljdWxhciBtZXNzYWdlIGlzLCBi
dXQgYW55dGhpbmcgZWxzZT8gKFNvcnJ5LCBtZWFudCB0byBzYXkgaWYgeW91IHNlcGFyYXRlIG91
dCB0aGUgUlJFUV9BY2sgbWVjaGFuaXNtIGFuZCBhc3N1bWluZyBubyBpbnRlcm1lZGlhdGUgdmFs
aWRpdHkgdGltZXMuKQ0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lw
YWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmll
cw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hy
aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl
bXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBU
ZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4N
Cnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFF
IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmds
YW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2Vh
cmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IFZpY3RvcmlhIE1l
cmNpZWNhIFttYWlsdG86dm1lcmNpZWNhMEBnbWFpbC5jb21dDQpTZW50OiAyNSBBcHJpbCAyMDE2
IDE4OjIyDQpUbzogVWxyaWNoIEhlcmJlcmcNCkNjOiBUaG9tYXMgSGVpZGUgQ2xhdXNlbjsgRGVh
cmxvdmUsIENocmlzdG9waGVyIChVSyk7IENocmlzdG9waGVyIERlYXJsb3ZlOyBNb2JpbGUgQWQg
SG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdA0KU3ViamVjdDogUmU6IFttYW5ldF0gU3ltbWV0cmlj
IGxpbmsgbWV0cmljcyAod2FzOiBSZTogTWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2UgbXV0
YWJpbGl0eSkNCg0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZy
b20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0
bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91
bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZv
ciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBm
b3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQu
YmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1Jl
ZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxl
YXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNv
bS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGgl
MjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQpIaSBVbHJpY2gsDQoNCkRvIHdlIGp1c3QgbmVl
ZCB0byBhZGQgdXAgbGluayBjb3N0cyBsb29raW5nIGJhY2t3YXJkcyB0byB3aGVyZSB0aGUgbWVz
c2FnZSBjYW1lIGZyb20/IEJhY2sgdG93YXJkIE9yaWdBZGRyIGluIGEgUlJFUSwgYmFjayB0b3dh
cmQgVGFyZ0FkZHIgaW4gYSBSUkVQPyBFYWNoIGludGVybWVkaWF0ZSBob3AgYWRkcyB0aGUgY29z
dCBvZiB0aGUgbGluayBmcm9tIGl0c2VsZiBiYWNrIHRvIHRoZSBsYXN0IHJvdXRlciB3aGljaCBm
b3J3YXJkZWQgdGhlIG1lc3NhZ2UuDQoNCkF0IFJSRVBfR2VuIHdlIHdvdWxkIGVuZCB1cCB3aXRo
IHRoZSByb3V0ZSBjb3N0IGxvb2tpbmcgaW4gdGhlIGNvcnJlY3QgZGlyZWN0aW9uIGZyb20gUlJF
UF9HZW4gYmFjayB0byBPcmlnQWRkciwgYWxvbmcgdGhlIHJldmVyc2Ugb2YgdGhlIHJvdXRlIHRo
ZSBSUkVRIHRvb2sgKGFsdGhvdWdoIHRoYXQncyBub3QgbmVjZXNzYXJpbHkgdGhlIG9wdGltYWwg
cm91dGUgdG8gT3JpZ0FkZHIpLCBhbmQgYXQgUlJFUV9HZW4gd2Ugd291bGQgZ2V0IHRoZSByb3V0
ZSBjb3N0IGFsb25nIHRoZSBvcHRpbWFsIHJvdXRlIHdoaWNoIHRoZSBSUkVRIHRyYXZlbGxlZCBv
biwgZnJvbSBSUkVRX0dlbiB0byBUYXJnQWRkci4NCg0KS2luZCByZWdhcmRzLA0KVmljdG9yaWEu
DQoNCk9uIE1vbiwgQXByIDI1LCAyMDE2IGF0IDQ6NTEgUE0sIFVscmljaCBIZXJiZXJnIDx1bHJp
Y2hAaGVyYmVyZy5uYW1lPG1haWx0bzp1bHJpY2hAaGVyYmVyZy5uYW1lPj4gd3JvdGU6DQpIaSwN
Cg0KSSBhbSBpbiB0aGUgcHJvY2VzcyBvZiByZXZpZXdpbmcgdGhlIEFPRFZ2MiBkcmFmdCwgYW5k
IGxpa2UgVGhvbWFzLCBJDQp3YXMgc3VycHJpc2VkIGFib3V0IHlvdXIgY29uY2x1c2lvbiB0byBt
b3ZlICJhc3ltbWV0cmljIGxpbmtzIiBvdXQgb2YNCnNjb3BlIG9mIEFPRFZ2Mi4gTW9zdCAoaWYg
bm90IGFsbCkgd2lyZWxlc3MgbmV0d29ya3MgdGhhdCBJIGhhdmUgc2Vlbg0KaW5jbHVkZSBhc3lt
bWV0cmljIGxpbmtzLiBJIGRvbid0IHRoaW5rIGl0J3MgYSBnb29kIGlkZWEgbW92aW5nIHRoaXMN
Cm91dCBvZiB0aGUgcHJvdG9jb2wuDQoNCkJlc3QgcmVnYXJkcw0KVWxyaWNoDQoNCk9uIE1vbiwg
QXByIDI1LCAyMDE2IGF0IDc6MTggQU0sICA8aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzxtYWlsdG86
aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZz4+IHdyb3RlOg0KPlsuLi5dDQo+IFNpbmNlIHdl4oCZcmUg
ZGlzY3Vzc2luZyBiaS1kaXJlY3Rpb25hbGl0eSBvZiBsaW5rcyBoZXJlLCBhbmQgdGhlIG5lY2Vz
c2l0eSBvZg0KPiBhIG1lY2hhbmlzbSBmb3IgaGFuZGxpbmcgdGhlc2UsIEkgd2FudCB0byBjYWxs
IGF0dGVudGlvbiB0byBhIHJlbGF0ZWQgaXNzdWUsDQo+IGFzIEkgaGludGVkIHByZXZpb3VzbHku
DQo+DQo+IFRoZSBhYnN0cmFjdCBzdGF0ZXMgdGhhdCB0aGUgcHJvdG9jb2w6DQo+DQo+ICAgIC4u
LmlzIGludGVuZGVkIGZvciB1c2UgYnkgbW9iaWxlIHJvdXRlcnMgaW4gd2lyZWxlc3MsIG11bHRp
aG9wDQo+ICAgIG5ldHdvcmtzLg0KPg0KPg0KPiBTZWN0aW9uIDUgcGFyYWdyYXBoIDQgIG9mIHRo
ZSBkb2N1bWVudCwgaG93ZXZlciwgcmVhZHM6DQo+DQo+ICAgIEFzc3VtaW5nIGxpbmsgbWV0cmlj
cyBhcmUgc3ltbWV0cmljLCB0aGUgY29zdCBvZiB0aGUgcm91dGVzIGluc3RhbGxlZA0KPiAgICBp
biB0aGUgTG9jYWwgUm91dGUgU2V0IGF0IGVhY2ggcm91dGVyIHdpbGwgYmUgY29ycmVjdC4gIFdo
aWxlIHRoaXMNCj4gICAgYXNzdW1wdGlvbiBpcyBub3QgYWx3YXlzIGNvcnJlY3QsIGNhbGN1bGF0
aW5nIGluY29taW5nL291dGdvaW5nDQo+ICAgIG1ldHJpYyBkYXRhIGlzIG91dHNpZGUgb2Ygc2Nv
cGUgb2YgdGhpcyBkb2N1bWVudC4NCj4NCj4NCj4gSSBkbyBub3Qga25vdyBvZiBhbnkgd2lyZWxl
c3Mgc3lzdGVtcywgd2hlcmUgdGhlIGFzc3VtcHRpb24gdGhhdCDigJxsaW5rDQo+IG1ldHJpY3Mg
YXJlIHN5bW1ldHJpY+KAnSBhY3R1YWxseSBob2xkcy4gQ29uc2VxdWVudGx5LCB0aGUgY29uY2x1
c2lvbiBpbiB0aGUNCj4gcXVvdGVkIHBhcmFncmFwaDoNCj4NCj4NCj4gICAgY2FsY3VsYXRpbmcg
aW5jb21pbmcvb3V0Z29pbmcNCj4gICAgbWV0cmljIGRhdGEgaXMgb3V0c2lkZSBvZiBzY29wZSBv
ZiB0aGlzIGRvY3VtZW50Lg0KPg0KPg0KPiBJcyBub3QgYW4gYWNjZXB0YWJsZSBkZXNpZ24gY2hv
aWNlLg0KPg0KPiBXaGlsZSB0aGlzIHByb3RvY29sIG1heSBub3Qgd2FudCB0byDigJxjYWxjdWxh
dGUgaWYgZm9yIHRoaXMgbGluayB0aGUgbWV0cmljcw0KPiBpcyA0IG9yIDXigJ0sIHRoZSBwcm90
b2NvbCBtdXN0IGJlIGFibGUgdG8gY29udmV5IGFuZCBkaXN0aW5ndWlzaCB0aGF0IOKAnHRoZQ0K
PiBtZXRyaWMgZnJvbSBBIHRvIEIgaXMgNCwgYW5kIHRoZSBtZXRyaWMgZnJvbSBCIHRvIEEgaXMg
MTnigJ0uDQo+DQo+IFRoaXMgaXMgYSDigJxyZWxhdGVkIGlzc3Vl4oCdIHNpbmNlIHRoZSBzb2x1
dGlvbiBtYXkgKGFzIHdpdGggdGhlDQo+IGJpLWRpcmVjdGlvbmFsaXR5IGNoZWNrKSBiZSBpbiB0
aGUgdHJpZ2dlcmVkIG5laWdoYm91ciBkZXRlY3Rpb24gbWVjaGFuaXNtOg0KPiB0aGF0IGV4Y2hh
bmdlIGNvdWxkLCBpZiBkZXNpZ25lZCBjYXJlZnVsbHksIGJlIHVzZWQgdG8gcHJvYmUgZm9yIGFu
ZCBjb252ZXkNCj4gbWV0cmljcyBpbmZvcm1hdGlvbiwgYWxzby4NCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFu
ZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkg
YXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFu
ZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVj
aXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBz
ZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBu
b3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv
bi4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioK

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1759GLKXM0002VGREEN_
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
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K
ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h
eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9
IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k
eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX
b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHlvdSBhbHNvIGNoYW5nZSBtZXRyaWNzIGluIGFuIFJS
RVEgKHdoaWNoIGlmIHlvdSB3YW50IHRvIGVzdGFibGlzaCBhc3ltbWV0cmljIG1ldHJpY3MgYm90
aCBlbmRzIHRvIGVhY2ggb3RoZXIgaXMgbG9naWNhbCkgd2hhdCBhY3R1YWxseSBub3cgaXMgdGhl
IGRpZmZlcmVuY2UNCiBiZXR3ZWVuIGFuIFJSRVEgYW5kIGFuIFJSRVAuIChFdmVuIGlmIHlvdSBt
dWx0aWNhc3Qgb25lIGFuZCB1bmljYXN0IHRoZSBvdGhlciwgb3IgbXVsdGljYXN0IGJvdGggYnV0
IG9uZSBvbmx5IG9uIG9uZSBpbnRlcmZhY2UsIHRoYXTigJlzIG5vdCBhIGRpZmZlcmVuY2UgaW4g
dGhlIG1lc3NhZ2UuKSBPZiBjb3Vyc2UgeW91IG1heSBuZWVkIHRvIGtub3cgd2hpY2ggb25lIGEg
cGFydGljdWxhciBtZXNzYWdlIGlzLCBidXQgYW55dGhpbmcgZWxzZT8gKFNvcnJ5LA0KIG1lYW50
IHRvIHNheSBpZiB5b3Ugc2VwYXJhdGUgb3V0IHRoZSBSUkVRX0FjayBtZWNoYW5pc20gYW5kIGFz
c3VtaW5nIG5vIGludGVybWVkaWF0ZSB2YWxpZGl0eSB0aW1lcy4pPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxi
cj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIElu
dGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOyYjNDM7NDQgKDAp
MTI0NSAyNDIxOTQgJm5ic3A7fCAmbmJzcDs8Yj5FOg0KPC9iPjxhIGhyZWY9Im1haWx0bzpjaHJp
cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208
L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48
YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBT
eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywg
R3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0
dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53
d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4Qjky
Ij5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJl
ZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBT
dXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij4gVmljdG9yaWEgTWVyY2llY2EgW21haWx0bzp2bWVyY2llY2EwQGdtYWlsLmNvbV0NCjxicj4N
CjxiPlNlbnQ6PC9iPiAyNSBBcHJpbCAyMDE2IDE4OjIyPGJyPg0KPGI+VG86PC9iPiBVbHJpY2gg
SGVyYmVyZzxicj4NCjxiPkNjOjwvYj4gVGhvbWFzIEhlaWRlIENsYXVzZW47IERlYXJsb3ZlLCBD
aHJpc3RvcGhlciAoVUspOyBDaHJpc3RvcGhlciBEZWFybG92ZTsgTW9iaWxlIEFkIEhvYyBOZXR3
b3JrcyBtYWlsaW5nIGxpc3Q8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gU3ltbWV0
cmljIGxpbmsgbWV0cmljcyAod2FzOiBSZTogTWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2Ug
bXV0YWJpbGl0eSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBw
dDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu
OmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i
bWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+
DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3Nh
Z2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20g
YW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNv
bnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBv
cGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48L3NwYW4+PC9pPjxz
dHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwv
c3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMz
Mzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLA0K
IGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3
b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiI+DQpoZXJl
PC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5
NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lv
dXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVt
cy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBX
aXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3NwYW4+
PC9lbT48L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5IaSBVbHJpY2gsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5EbyB3ZSBqdXN0IG5lZWQgdG8gYWRkIHVwIGxpbmsgY29zdHMgbG9va2luZyBi
YWNrd2FyZHMgdG8gd2hlcmUgdGhlIG1lc3NhZ2UgY2FtZSBmcm9tPyBCYWNrIHRvd2FyZCBPcmln
QWRkciBpbiBhIFJSRVEsIGJhY2sgdG93YXJkIFRhcmdBZGRyIGluIGEgUlJFUD8gRWFjaCBpbnRl
cm1lZGlhdGUgaG9wIGFkZHMgdGhlIGNvc3Qgb2YgdGhlIGxpbmsgZnJvbSBpdHNlbGYgYmFjayB0
byB0aGUgbGFzdCByb3V0ZXIgd2hpY2gNCiBmb3J3YXJkZWQgdGhlIG1lc3NhZ2UuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IFJSRVBfR2Vu
IHdlIHdvdWxkIGVuZCB1cCB3aXRoIHRoZSByb3V0ZSBjb3N0IGxvb2tpbmcgaW4gdGhlIGNvcnJl
Y3QgZGlyZWN0aW9uIGZyb20gUlJFUF9HZW4gYmFjayB0byBPcmlnQWRkciwgYWxvbmcgdGhlIHJl
dmVyc2Ugb2YgdGhlIHJvdXRlIHRoZSBSUkVRIHRvb2sgKGFsdGhvdWdoIHRoYXQncyBub3QgbmVj
ZXNzYXJpbHkgdGhlIG9wdGltYWwgcm91dGUgdG8gT3JpZ0FkZHIpLCBhbmQgYXQgUlJFUV9HZW4N
CiB3ZSB3b3VsZCBnZXQgdGhlIHJvdXRlIGNvc3QgYWxvbmcgdGhlIG9wdGltYWwgcm91dGUgd2hp
Y2ggdGhlIFJSRVEgdHJhdmVsbGVkIG9uLCBmcm9tIFJSRVFfR2VuIHRvIFRhcmdBZGRyLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LaW5kIHJl
Z2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5WaWN0b3JpYS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk9uIE1vbiwgQXByIDI1LCAyMDE2IGF0IDQ6NTEgUE0sIFVscmljaCBIZXJiZXJnICZsdDs8YSBo
cmVmPSJtYWlsdG86dWxyaWNoQGhlcmJlcmcubmFtZSIgdGFyZ2V0PSJfYmxhbmsiPnVscmljaEBo
ZXJiZXJnLm5hbWU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkhpLDxicj4NCjxicj4NCkkgYW0gaW4gdGhlIHByb2Nlc3Mgb2YgcmV2aWV3aW5nIHRo
ZSBBT0RWdjIgZHJhZnQsIGFuZCBsaWtlIFRob21hcywgSTxicj4NCndhcyBzdXJwcmlzZWQgYWJv
dXQgeW91ciBjb25jbHVzaW9uIHRvIG1vdmUgJnF1b3Q7YXN5bW1ldHJpYyBsaW5rcyZxdW90OyBv
dXQgb2Y8YnI+DQpzY29wZSBvZiBBT0RWdjIuIE1vc3QgKGlmIG5vdCBhbGwpIHdpcmVsZXNzIG5l
dHdvcmtzIHRoYXQgSSBoYXZlIHNlZW48YnI+DQppbmNsdWRlIGFzeW1tZXRyaWMgbGlua3MuIEkg
ZG9uJ3QgdGhpbmsgaXQncyBhIGdvb2QgaWRlYSBtb3ZpbmcgdGhpczxicj4NCm91dCBvZiB0aGUg
cHJvdG9jb2wuPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzPGJyPg0KVWxyaWNoPGJyPg0KPGJyPg0K
T24gTW9uLCBBcHIgMjUsIDIwMTYgYXQgNzoxOCBBTSwmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0
bzppZXRmQHRob21hc2NsYXVzZW4ub3JnIj5pZXRmQHRob21hc2NsYXVzZW4ub3JnPC9hPiZndDsg
d3JvdGU6PGJyPg0KJmd0O1suLi5dPGJyPg0KJmd0OyBTaW5jZSB3ZeKAmXJlIGRpc2N1c3Npbmcg
YmktZGlyZWN0aW9uYWxpdHkgb2YgbGlua3MgaGVyZSwgYW5kIHRoZSBuZWNlc3NpdHkgb2Y8YnI+
DQomZ3Q7IGEgbWVjaGFuaXNtIGZvciBoYW5kbGluZyB0aGVzZSwgSSB3YW50IHRvIGNhbGwgYXR0
ZW50aW9uIHRvIGEgcmVsYXRlZCBpc3N1ZSw8YnI+DQomZ3Q7IGFzIEkgaGludGVkIHByZXZpb3Vz
bHkuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIGFic3RyYWN0IHN0YXRlcyB0aGF0IHRoZSBwcm90
b2NvbDo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgLi4uaXMgaW50ZW5kZWQgZm9y
IHVzZSBieSBtb2JpbGUgcm91dGVycyBpbiB3aXJlbGVzcywgbXVsdGlob3A8YnI+DQomZ3Q7Jm5i
c3A7ICZuYnNwOyBuZXR3b3Jrcy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgU2VjdGlv
biA1IHBhcmFncmFwaCA0Jm5ic3A7IG9mIHRoZSBkb2N1bWVudCwgaG93ZXZlciwgcmVhZHM6PGJy
Pg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7IEFzc3VtaW5nIGxpbmsgbWV0cmljcyBhcmUg
c3ltbWV0cmljLCB0aGUgY29zdCBvZiB0aGUgcm91dGVzIGluc3RhbGxlZDxicj4NCiZndDsmbmJz
cDsgJm5ic3A7IGluIHRoZSBMb2NhbCBSb3V0ZSBTZXQgYXQgZWFjaCByb3V0ZXIgd2lsbCBiZSBj
b3JyZWN0LiZuYnNwOyBXaGlsZSB0aGlzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgYXNzdW1wdGlv
biBpcyBub3QgYWx3YXlzIGNvcnJlY3QsIGNhbGN1bGF0aW5nIGluY29taW5nL291dGdvaW5nPGJy
Pg0KJmd0OyZuYnNwOyAmbmJzcDsgbWV0cmljIGRhdGEgaXMgb3V0c2lkZSBvZiBzY29wZSBvZiB0
aGlzIGRvY3VtZW50Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGRvIG5vdCBrbm93
IG9mIGFueSB3aXJlbGVzcyBzeXN0ZW1zLCB3aGVyZSB0aGUgYXNzdW1wdGlvbiB0aGF0IOKAnGxp
bms8YnI+DQomZ3Q7IG1ldHJpY3MgYXJlIHN5bW1ldHJpY+KAnSBhY3R1YWxseSBob2xkcy4gQ29u
c2VxdWVudGx5LCB0aGUgY29uY2x1c2lvbiBpbiB0aGU8YnI+DQomZ3Q7IHF1b3RlZCBwYXJhZ3Jh
cGg6PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBjYWxjdWxhdGlu
ZyBpbmNvbWluZy9vdXRnb2luZzxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG1ldHJpYyBkYXRhIGlz
IG91dHNpZGUgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVudC48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi
cj4NCiZndDsgSXMgbm90IGFuIGFjY2VwdGFibGUgZGVzaWduIGNob2ljZS48YnI+DQomZ3Q7PGJy
Pg0KJmd0OyBXaGlsZSB0aGlzIHByb3RvY29sIG1heSBub3Qgd2FudCB0byDigJxjYWxjdWxhdGUg
aWYgZm9yIHRoaXMgbGluayB0aGUgbWV0cmljczxicj4NCiZndDsgaXMgNCBvciA14oCdLCB0aGUg
cHJvdG9jb2wgbXVzdCBiZSBhYmxlIHRvIGNvbnZleSBhbmQgZGlzdGluZ3Vpc2ggdGhhdCDigJx0
aGU8YnI+DQomZ3Q7IG1ldHJpYyBmcm9tIEEgdG8gQiBpcyA0LCBhbmQgdGhlIG1ldHJpYyBmcm9t
IEIgdG8gQSBpcyAxOeKAnS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIGlzIGEg4oCccmVsYXRl
ZCBpc3N1ZeKAnSBzaW5jZSB0aGUgc29sdXRpb24gbWF5IChhcyB3aXRoIHRoZTxicj4NCiZndDsg
YmktZGlyZWN0aW9uYWxpdHkgY2hlY2spIGJlIGluIHRoZSB0cmlnZ2VyZWQgbmVpZ2hib3VyIGRl
dGVjdGlvbiBtZWNoYW5pc206PGJyPg0KJmd0OyB0aGF0IGV4Y2hhbmdlIGNvdWxkLCBpZiBkZXNp
Z25lZCBjYXJlZnVsbHksIGJlIHVzZWQgdG8gcHJvYmUgZm9yIGFuZCBjb252ZXk8YnI+DQomZ3Q7
IG1ldHJpY3MgaW5mb3JtYXRpb24sIGFsc28uPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+
DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4N
CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRh
cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0
PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwPioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJy
PgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUg
aW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91
IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9t
IHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+CllvdSBzaG91bGQgbm90IGNv
cHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+CmRpc3Ry
aWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uPGJyPgoqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwv
cD48L2JvZHk+DQo8L2h0bWw+DQo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1759GLKXM0002VGREEN_--


From nobody Tue Apr 26 03:29: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 E61D612D0CD for ; Tue, 26 Apr 2016 03:29:38 -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 YstsxpA5WUKA for ; Tue, 26 Apr 2016 03:29:36 -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 5776D12B037 for ; Tue, 26 Apr 2016 03:29:36 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id u23so11259709vkb.2 for ; Tue, 26 Apr 2016 03:29:36 -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=GqzeHsy0NFNoHNlfJuFcJFFkBE2b/A8PXldRIenXO3o=; b=aU3DzNN9T4ld3UhXCLBgmdwC+1ZTjUCEFeaWzbmWKwCc/6bxVI14SbUmtmYvH0g8km bkOlIUJRQIseiHSnpe8luWQUqwGQumFDBBu/qydnmWJGFEpjcciffBny8LIAunxWzIAQ /wg5hzuxfL05COSe3DSeyQL+VYcrbLqzY1ldV/G/c6KtRDGYFBk+eld/xfAcmwfscCZh /PfJXOi8sgelYlhayAjGbrjLuFHB7iD6SZz9C/jheOPj33xNsQkUE9mm+kd877DCKdlm 7MEDkQhtwd5FPyM6hXMfrk5OKIaC+EREM2vp5Y5qnG5MgI2vN33MSMqtwGePA+u5BCXt AKew==
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=GqzeHsy0NFNoHNlfJuFcJFFkBE2b/A8PXldRIenXO3o=; b=A8XzmcpnvNV8eU4CtbpEiGHwsw8+Gwm2fyIsn8TNtU+knrzjEaboDMCJORsaDUZNtI vnoXAlsnEdamgrBtaun6KKTaIvJJrJ0+pTUYrUiFLXCoCYSlBjO1t/KeW7lls6Q7MJIH UeaTiSHYNsrFHvz1qZya8BUW5NLfbZUMIL71SJR4nwoZDQzwvjoupRUUhvUDHPIb3HGQ NIb+Ocjyemu6JASn0Kr/7jLYOuGsXsVwjFLS+6yL7hPTcJ9ANivCUmFOOAoxRDAnWSs4 j2PAj3Tpf8NaJl/JRFZ7x3qFrat7Xgsw5Cj8sPyOD8POileIP8+vktI6SIJbvn7QYTY/ qgdQ==
X-Gm-Message-State: AOPr4FXFltoXVBECQ4muaypxym3QbBnkmJxlVYfcn7bDpmrAIc0ny6I9iabnRiIKIZ14AhhI1dXtoDOiwECirg==
MIME-Version: 1.0
X-Received: by 10.31.8.71 with SMTP id 68mr852440vki.29.1461666575378; Tue, 26 Apr 2016 03:29:35 -0700 (PDT)
Received: by 10.176.65.40 with HTTP; Tue, 26 Apr 2016 03:29:35 -0700 (PDT)
In-Reply-To: 
References:   
Date: Tue, 26 Apr 2016 11:29:35 +0100
Message-ID: 
From: Victoria Mercieca 
To: "Dearlove, Christopher (UK)" 
Content-Type: multipart/alternative; boundary=001a11458b0a017228053160c5f3
Archived-At: 
Cc: Christopher Dearlove , 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: Tue, 26 Apr 2016 10:29:39 -0000

--001a11458b0a017228053160c5f3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Interesting question...We already do change metrics in the RREQ so that
every intermediate router learns the metric of the route to OrigAddr.

If we don't include ValidityTime or AckReq in the RREP, then its use is
pretty similar to RREQ. Are you thinking we could use one message type and
judge from the contents of it whether its a request or a reply?
i.e. if its got OrigSeqNum its a RREQ, if its got TargSeqNum its a RREP?
But this would make it impossible for an extension where you might want to
include both seqnums. Would there be similar arguments against using the
presence of OrigMetric to signal it's a RREQ? Or would you introduce a flag
somewhere indicating that it's a request or a response?

Kind regards,
Victoria.


On Tue, Apr 26, 2016 at 9:44 AM, Dearlove, Christopher (UK) <
chris.dearlove@baesystems.com> wrote:

> If you also change metrics in an RREQ (which if you want to establish
> asymmetric metrics both ends to each other is logical) what actually now =
is
> the difference between an RREQ and an RREP. (Even if you multicast one an=
d
> unicast the other, or multicast both but one only on one interface, that=
=E2=80=99s
> not a difference in the message.) Of course you may need to know which on=
e
> a particular message is, but anything else? (Sorry, meant to say if you
> separate out the RREQ_Ack mechanism and assuming no intermediate validity
> times.)
>
>
>
> *-- *
>
>
>
>
> *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
> *Sent:* 25 April 2016 18:22
> *To:* Ulrich Herberg
> *Cc:* Thomas Heide Clausen; Dearlove, Christopher (UK); Christopher
> Dearlove; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Symmetric link metrics (was: Re: Message integrity
> and message mutability)
>
>
>
>
>
> **** 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
> .*
>
> 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 i=
n
> 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 route
> 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 which 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 related
> 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 installe=
d
> >    in the Local Route Set at each router will be correct.  While this
> >    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 conclu=
sion 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 link=
 the
> metrics
> > is 4 or 5=E2=80=9D, the protocol must be able to convey and distinguish=
 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 wi=
th 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
>
>
>
> ********************************************************************
> 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.
> ********************************************************************
>

--001a11458b0a017228053160c5f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Interesting question...We already do change=
 metrics in the RREQ so that every intermediate router learns the metric of=
 the route to OrigAddr. 

If we don't include ValidityTime =
or AckReq in the RREP, then its use is pretty similar to RREQ. Are you thin=
king we could use one message type and judge from the contents of it whethe=
r its a request or a reply?
i.e. if its got OrigSeqNum its a RREQ,=
 if its got TargSeqNum its a RREP? But this would make it impossible for an=
 extension where you might want to include both seqnums. Would there be sim=
ilar arguments against using the presence of OrigMetric to signal it's =
a RREQ? Or would you introduce a flag somewhere indicating that it's a =
request or a response?

Kind regards,
Victoria.


O=
n Tue, Apr 26, 2016 at 9:44 AM, Dearlove, Christopher (UK) <ch=
ris.dearlove@baesystems.com> wrote:











If you also change m=
etrics in an RREQ (which if you want to establish asymmetric metrics both e=
nds to each other is logical) what actually now is the difference
 between an RREQ and an RREP. (Even if you multicast one and unicast the ot=
her, or multicast both but one only on one interface, that=E2=80=99s not a =
difference in the message.) Of course you may need to know which one a part=
icular message is, but anything else? (Sorry,
 meant to say if you separate out the RREQ_Ack mechanism and assuming no in=
termediate validity times.)


=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: Victoria Mercieca [mailto:vmercieca0@gmail.com]


Sent: 25 April 2016 18:22

To: Ulrich Herberg

Cc: Thomas Heide Clausen; Dearlove, Christopher (UK); Christopher De=
arlove; Mobile Ad Hoc Networks mailing list

Subject: Re: [manet] Symmetric link metrics (was: Re: Message integr=
ity and message mutability)


=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>








Hi Ulrich,




=C2=A0






Do we just need to add up link costs looking backwar=
ds to where the message came from? Back toward OrigAddr in a RREQ, back tow=
ard TargAddr in a RREP? Each intermediate hop adds the cost of the link fro=
m itself back to the last router which
 forwarded the message.






=C2=A0






At RREP_Gen we would end up with the route cost look=
ing in the correct direction from RREP_Gen back to OrigAddr, along the reve=
rse of the route the RREQ took (although that's not necessarily the opt=
imal route to OrigAddr), and at RREQ_Gen
 we would get the route cost along the optimal route which the RREQ travell=
ed on, from RREQ_Gen to TargAddr.






=C2=A0






Kind regards,






Victoria.






=C2=A0




On Mon, Apr 25, 2016 at 4:51 PM, Ulrich Herberg <=
ulrich@herberg.nam=
e> 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" ou=
t 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 thi=
s

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 here, and th=
e 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 wireless, mul=
tihop

>=C2=A0 =C2=A0 networks.

>

>

> Section 5 paragraph 4=C2=A0 of the document, however, reads:

>

>=C2=A0 =C2=A0 Assuming link metrics are symmetric, the cost of the rout=
es installed

>=C2=A0 =C2=A0 in the Local Route Set at each router will be correct.=C2=
=A0 While this

>=C2=A0 =C2=A0 assumption is not always correct, calculating incoming/ou=
tgoing

>=C2=A0 =C2=A0 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 concl=
usion 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 lin=
k the metrics

> is 4 or 5=E2=80=9D, the protocol must be able to convey and distinguis=
h 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 w=
ith the

> bi-directionality check) be in the triggered neighbour detection mecha=
nism:

> that exchange could, if designed carefully, be used to probe for and c=
onvey

> metrics information, also.



_______________________________________________

manet mailing list

manet@ietf.org

h=
ttps://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 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.

********************************************************************






--001a11458b0a017228053160c5f3--


From nobody Tue Apr 26 03:54: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 C1DAC12D142 for ; Tue, 26 Apr 2016 03:54:28 -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 E_cFZlYBkdA1 for ; Tue, 26 Apr 2016 03:54:25 -0700 (PDT)
Received: from ukmta1.baesystems.com (unknown [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 1B5EF12D0F8 for ; Tue, 26 Apr 2016 03:54:24 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,536,1454976000"; d="scan'208,217"; a="64255969"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 26 Apr 2016 11:54:24 +0100
X-IronPort-AV: E=Sophos;i="5.24,536,1454976000";  d="scan'208,217";a="115515775"
Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 26 Apr 2016 11:54:23 +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, 26 Apr 2016 11:54:23 +0100
From: "Dearlove, Christopher (UK)" 
To: Victoria Mercieca 
Thread-Topic: [manet] Symmetric link metrics (was: Re: Message integrity and message mutability)
Thread-Index: AQHRnxbwhtMff84LEkCStHnfcl2th5+b8CUwgAAN94CAABZz0A==
Date: Tue, 26 Apr 2016 10:54:21 +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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1837GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: 
Cc: Christopher Dearlove , 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: Tue, 26 Apr 2016 10:54:29 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1837GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2hldGhlciB0byB1c2Ugb25lIG1lc3NhZ2UgdHlwZSBpcyBvbmUgaXNzdWUgLSBidXQgSSB0aGlu
ayB3ZeKAmXJlIGFncmVlZCB0aGF0IHlvdSB3aWxsIHByb2JhYmx5IG5lZWQgdG8ga25vdyB3aGlj
aCBpdCBpcyBmcm9tIHRoZSBtZXNzYWdlIGl0c2VsZi4gV2hpY2ggaXMgYSB0cmFkZW9mZiBvZiB0
aGUgdXNlIG9mIGEgbWVzc2FnZSB0eXBlIChjdXJyZW50bHkgbm90IGFuIGlzc3VlIGlmIHVzaW5n
IGV4cGVyaW1lbnRhbCBzdWdnZXN0aW9ucyBvbmx5IC0gSeKAmW0gbm90IHN1cmUgaWYgdGhhdCBp
cyBhZ3JlZWQgb3Igbm90KSBhbmQgdGhlIG1pbmltdW0gdG8gb3RoZXJ3aXNlIGluZGljYXRlIHRo
YXQgKHdoaWNoIGlzIGEgdGhyZWUgb2N0ZXQgVExWIEkgdGhpbmsgLSBkZWZpbml0ZWx5IGluIHRo
ZSBtZXNzYWdlIHR5cGUgc3BlY2lmaWMgc3BhY2UsIGFzIGl04oCZcyBoYXJkIHRvIHRoaW5rIG9m
IGFueXRoaW5nIG1vcmUgbWVzc2FnZSB0eXBlIHNwZWNpZmljLg0KDQpCdXQgcG9zc2libHkgYXMg
aW1wb3J0YW50IGlzIHRoYXQgd2hlcmUgUlJFUXMgYW5kIFJSRVBzIGFyZSBlc3NlbnRpYWxseSB0
aGUgc2FtZSwgZXZlbiBpZiBkaWZmZXJlbnQgbWVzc2FnZSB0eXBlcywgdGhlcmXigJlzIG9uZSBk
ZXNjcmlwdGlvbiBvZiB3aGF0IHRoZXkgZG8gdGhhdCBpcyBjb21tb24uIEFnYWluLCBtYXliZSB0
aGVyZSBhbHJlYWR5IGlzLCBJIGRvbuKAmXQga25vdy4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJs
b3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs
bGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0
NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJp
cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxp
Z2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2Zv
cmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVz
eXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQN
ClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBP
ZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0K
DQpGcm9tOiBWaWN0b3JpYSBNZXJjaWVjYSBbbWFpbHRvOnZtZXJjaWVjYTBAZ21haWwuY29tXQ0K
U2VudDogMjYgQXByaWwgMjAxNiAxMTozMA0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp
DQpDYzogVWxyaWNoIEhlcmJlcmc7IFRob21hcyBIZWlkZSBDbGF1c2VuOyBDaHJpc3RvcGhlciBE
ZWFybG92ZTsgTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3QNClN1YmplY3Q6IFJl
OiBbbWFuZXRdIFN5bW1ldHJpYyBsaW5rIG1ldHJpY3MgKHdhczogUmU6IE1lc3NhZ2UgaW50ZWdy
aXR5IGFuZCBtZXNzYWdlIG11dGFiaWxpdHkpDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1l
c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZy
b20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVs
bHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNo
bWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0
IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxo
dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90
bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWls
IGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5l
dC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1l
bnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KSW50ZXJlc3Rp
bmcgcXVlc3Rpb24uLi5XZSBhbHJlYWR5IGRvIGNoYW5nZSBtZXRyaWNzIGluIHRoZSBSUkVRIHNv
IHRoYXQgZXZlcnkgaW50ZXJtZWRpYXRlIHJvdXRlciBsZWFybnMgdGhlIG1ldHJpYyBvZiB0aGUg
cm91dGUgdG8gT3JpZ0FkZHIuDQpJZiB3ZSBkb24ndCBpbmNsdWRlIFZhbGlkaXR5VGltZSBvciBB
Y2tSZXEgaW4gdGhlIFJSRVAsIHRoZW4gaXRzIHVzZSBpcyBwcmV0dHkgc2ltaWxhciB0byBSUkVR
LiBBcmUgeW91IHRoaW5raW5nIHdlIGNvdWxkIHVzZSBvbmUgbWVzc2FnZSB0eXBlIGFuZCBqdWRn
ZSBmcm9tIHRoZSBjb250ZW50cyBvZiBpdCB3aGV0aGVyIGl0cyBhIHJlcXVlc3Qgb3IgYSByZXBs
eT8NCmkuZS4gaWYgaXRzIGdvdCBPcmlnU2VxTnVtIGl0cyBhIFJSRVEsIGlmIGl0cyBnb3QgVGFy
Z1NlcU51bSBpdHMgYSBSUkVQPyBCdXQgdGhpcyB3b3VsZCBtYWtlIGl0IGltcG9zc2libGUgZm9y
IGFuIGV4dGVuc2lvbiB3aGVyZSB5b3UgbWlnaHQgd2FudCB0byBpbmNsdWRlIGJvdGggc2VxbnVt
cy4gV291bGQgdGhlcmUgYmUgc2ltaWxhciBhcmd1bWVudHMgYWdhaW5zdCB1c2luZyB0aGUgcHJl
c2VuY2Ugb2YgT3JpZ01ldHJpYyB0byBzaWduYWwgaXQncyBhIFJSRVE/IE9yIHdvdWxkIHlvdSBp
bnRyb2R1Y2UgYSBmbGFnIHNvbWV3aGVyZSBpbmRpY2F0aW5nIHRoYXQgaXQncyBhIHJlcXVlc3Qg
b3IgYSByZXNwb25zZT8NCktpbmQgcmVnYXJkcywNClZpY3RvcmlhLg0KDQoNCk9uIFR1ZSwgQXBy
IDI2LCAyMDE2IGF0IDk6NDQgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5k
ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j
b20+PiB3cm90ZToNCklmIHlvdSBhbHNvIGNoYW5nZSBtZXRyaWNzIGluIGFuIFJSRVEgKHdoaWNo
IGlmIHlvdSB3YW50IHRvIGVzdGFibGlzaCBhc3ltbWV0cmljIG1ldHJpY3MgYm90aCBlbmRzIHRv
IGVhY2ggb3RoZXIgaXMgbG9naWNhbCkgd2hhdCBhY3R1YWxseSBub3cgaXMgdGhlIGRpZmZlcmVu
Y2UgYmV0d2VlbiBhbiBSUkVRIGFuZCBhbiBSUkVQLiAoRXZlbiBpZiB5b3UgbXVsdGljYXN0IG9u
ZSBhbmQgdW5pY2FzdCB0aGUgb3RoZXIsIG9yIG11bHRpY2FzdCBib3RoIGJ1dCBvbmUgb25seSBv
biBvbmUgaW50ZXJmYWNlLCB0aGF04oCZcyBub3QgYSBkaWZmZXJlbmNlIGluIHRoZSBtZXNzYWdl
LikgT2YgY291cnNlIHlvdSBtYXkgbmVlZCB0byBrbm93IHdoaWNoIG9uZSBhIHBhcnRpY3VsYXIg
bWVzc2FnZSBpcywgYnV0IGFueXRoaW5nIGVsc2U/IChTb3JyeSwgbWVhbnQgdG8gc2F5IGlmIHlv
dSBzZXBhcmF0ZSBvdXQgdGhlIFJSRVFfQWNrIG1lY2hhbmlzbSBhbmQgYXNzdW1pbmcgbm8gaW50
ZXJtZWRpYXRlIHZhbGlkaXR5IHRpbWVzLikNCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpT
ZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j
ZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIx
OTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92
ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoN
CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kg
UGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5
c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBB
cHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxl
cyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywg
R3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTogVmljdG9yaWEgTWVyY2llY2EgW21h
aWx0bzp2bWVyY2llY2EwQGdtYWlsLmNvbTxtYWlsdG86dm1lcmNpZWNhMEBnbWFpbC5jb20+XQ0K
U2VudDogMjUgQXByaWwgMjAxNiAxODoyMg0KVG86IFVscmljaCBIZXJiZXJnDQpDYzogVGhvbWFz
IEhlaWRlIENsYXVzZW47IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBDaHJpc3RvcGhlciBE
ZWFybG92ZTsgTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3QNClN1YmplY3Q6IFJl
OiBbbWFuZXRdIFN5bW1ldHJpYyBsaW5rIG1ldHJpY3MgKHdhczogUmU6IE1lc3NhZ2UgaW50ZWdy
aXR5IGFuZCBtZXNzYWdlIG11dGFiaWxpdHkpDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1l
c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZy
b20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVs
bHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNo
bWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0
IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxo
dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90
bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWls
IGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5l
dC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1l
bnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KSGkgVWxyaWNo
LA0KDQpEbyB3ZSBqdXN0IG5lZWQgdG8gYWRkIHVwIGxpbmsgY29zdHMgbG9va2luZyBiYWNrd2Fy
ZHMgdG8gd2hlcmUgdGhlIG1lc3NhZ2UgY2FtZSBmcm9tPyBCYWNrIHRvd2FyZCBPcmlnQWRkciBp
biBhIFJSRVEsIGJhY2sgdG93YXJkIFRhcmdBZGRyIGluIGEgUlJFUD8gRWFjaCBpbnRlcm1lZGlh
dGUgaG9wIGFkZHMgdGhlIGNvc3Qgb2YgdGhlIGxpbmsgZnJvbSBpdHNlbGYgYmFjayB0byB0aGUg
bGFzdCByb3V0ZXIgd2hpY2ggZm9yd2FyZGVkIHRoZSBtZXNzYWdlLg0KDQpBdCBSUkVQX0dlbiB3
ZSB3b3VsZCBlbmQgdXAgd2l0aCB0aGUgcm91dGUgY29zdCBsb29raW5nIGluIHRoZSBjb3JyZWN0
IGRpcmVjdGlvbiBmcm9tIFJSRVBfR2VuIGJhY2sgdG8gT3JpZ0FkZHIsIGFsb25nIHRoZSByZXZl
cnNlIG9mIHRoZSByb3V0ZSB0aGUgUlJFUSB0b29rIChhbHRob3VnaCB0aGF0J3Mgbm90IG5lY2Vz
c2FyaWx5IHRoZSBvcHRpbWFsIHJvdXRlIHRvIE9yaWdBZGRyKSwgYW5kIGF0IFJSRVFfR2VuIHdl
IHdvdWxkIGdldCB0aGUgcm91dGUgY29zdCBhbG9uZyB0aGUgb3B0aW1hbCByb3V0ZSB3aGljaCB0
aGUgUlJFUSB0cmF2ZWxsZWQgb24sIGZyb20gUlJFUV9HZW4gdG8gVGFyZ0FkZHIuDQoNCktpbmQg
cmVnYXJkcywNClZpY3RvcmlhLg0KDQpPbiBNb24sIEFwciAyNSwgMjAxNiBhdCA0OjUxIFBNLCBV
bHJpY2ggSGVyYmVyZyA8dWxyaWNoQGhlcmJlcmcubmFtZTxtYWlsdG86dWxyaWNoQGhlcmJlcmcu
bmFtZT4+IHdyb3RlOg0KSGksDQoNCkkgYW0gaW4gdGhlIHByb2Nlc3Mgb2YgcmV2aWV3aW5nIHRo
ZSBBT0RWdjIgZHJhZnQsIGFuZCBsaWtlIFRob21hcywgSQ0Kd2FzIHN1cnByaXNlZCBhYm91dCB5
b3VyIGNvbmNsdXNpb24gdG8gbW92ZSAiYXN5bW1ldHJpYyBsaW5rcyIgb3V0IG9mDQpzY29wZSBv
ZiBBT0RWdjIuIE1vc3QgKGlmIG5vdCBhbGwpIHdpcmVsZXNzIG5ldHdvcmtzIHRoYXQgSSBoYXZl
IHNlZW4NCmluY2x1ZGUgYXN5bW1ldHJpYyBsaW5rcy4gSSBkb24ndCB0aGluayBpdCdzIGEgZ29v
ZCBpZGVhIG1vdmluZyB0aGlzDQpvdXQgb2YgdGhlIHByb3RvY29sLg0KDQpCZXN0IHJlZ2FyZHMN
ClVscmljaA0KDQpPbiBNb24sIEFwciAyNSwgMjAxNiBhdCA3OjE4IEFNLCAgPGlldGZAdGhvbWFz
Y2xhdXNlbi5vcmc8bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmc+PiB3cm90ZToNCj5bLi4u
XQ0KPiBTaW5jZSB3ZeKAmXJlIGRpc2N1c3NpbmcgYmktZGlyZWN0aW9uYWxpdHkgb2YgbGlua3Mg
aGVyZSwgYW5kIHRoZSBuZWNlc3NpdHkgb2YNCj4gYSBtZWNoYW5pc20gZm9yIGhhbmRsaW5nIHRo
ZXNlLCBJIHdhbnQgdG8gY2FsbCBhdHRlbnRpb24gdG8gYSByZWxhdGVkIGlzc3VlLA0KPiBhcyBJ
IGhpbnRlZCBwcmV2aW91c2x5Lg0KPg0KPiBUaGUgYWJzdHJhY3Qgc3RhdGVzIHRoYXQgdGhlIHBy
b3RvY29sOg0KPg0KPiAgICAuLi5pcyBpbnRlbmRlZCBmb3IgdXNlIGJ5IG1vYmlsZSByb3V0ZXJz
IGluIHdpcmVsZXNzLCBtdWx0aWhvcA0KPiAgICBuZXR3b3Jrcy4NCj4NCj4NCj4gU2VjdGlvbiA1
IHBhcmFncmFwaCA0ICBvZiB0aGUgZG9jdW1lbnQsIGhvd2V2ZXIsIHJlYWRzOg0KPg0KPiAgICBB
c3N1bWluZyBsaW5rIG1ldHJpY3MgYXJlIHN5bW1ldHJpYywgdGhlIGNvc3Qgb2YgdGhlIHJvdXRl
cyBpbnN0YWxsZWQNCj4gICAgaW4gdGhlIExvY2FsIFJvdXRlIFNldCBhdCBlYWNoIHJvdXRlciB3
aWxsIGJlIGNvcnJlY3QuICBXaGlsZSB0aGlzDQo+ICAgIGFzc3VtcHRpb24gaXMgbm90IGFsd2F5
cyBjb3JyZWN0LCBjYWxjdWxhdGluZyBpbmNvbWluZy9vdXRnb2luZw0KPiAgICBtZXRyaWMgZGF0
YSBpcyBvdXRzaWRlIG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQo+DQo+DQo+IEkgZG8gbm90
IGtub3cgb2YgYW55IHdpcmVsZXNzIHN5c3RlbXMsIHdoZXJlIHRoZSBhc3N1bXB0aW9uIHRoYXQg
4oCcbGluaw0KPiBtZXRyaWNzIGFyZSBzeW1tZXRyaWPigJ0gYWN0dWFsbHkgaG9sZHMuIENvbnNl
cXVlbnRseSwgdGhlIGNvbmNsdXNpb24gaW4gdGhlDQo+IHF1b3RlZCBwYXJhZ3JhcGg6DQo+DQo+
DQo+ICAgIGNhbGN1bGF0aW5nIGluY29taW5nL291dGdvaW5nDQo+ICAgIG1ldHJpYyBkYXRhIGlz
IG91dHNpZGUgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCj4NCj4NCj4gSXMgbm90IGFuIGFj
Y2VwdGFibGUgZGVzaWduIGNob2ljZS4NCj4NCj4gV2hpbGUgdGhpcyBwcm90b2NvbCBtYXkgbm90
IHdhbnQgdG8g4oCcY2FsY3VsYXRlIGlmIGZvciB0aGlzIGxpbmsgdGhlIG1ldHJpY3MNCj4gaXMg
NCBvciA14oCdLCB0aGUgcHJvdG9jb2wgbXVzdCBiZSBhYmxlIHRvIGNvbnZleSBhbmQgZGlzdGlu
Z3Vpc2ggdGhhdCDigJx0aGUNCj4gbWV0cmljIGZyb20gQSB0byBCIGlzIDQsIGFuZCB0aGUgbWV0
cmljIGZyb20gQiB0byBBIGlzIDE54oCdLg0KPg0KPiBUaGlzIGlzIGEg4oCccmVsYXRlZCBpc3N1
ZeKAnSBzaW5jZSB0aGUgc29sdXRpb24gbWF5IChhcyB3aXRoIHRoZQ0KPiBiaS1kaXJlY3Rpb25h
bGl0eSBjaGVjaykgYmUgaW4gdGhlIHRyaWdnZXJlZCBuZWlnaGJvdXIgZGV0ZWN0aW9uIG1lY2hh
bmlzbToNCj4gdGhhdCBleGNoYW5nZSBjb3VsZCwgaWYgZGVzaWduZWQgY2FyZWZ1bGx5LCBiZSB1
c2VkIHRvIHByb2JlIGZvciBhbmQgY29udmV5DQo+IG1ldHJpY3MgaW5mb3JtYXRpb24sIGFsc28u
DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5l
dCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KDQoqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
Kg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhl
IGludGVuZGVkDQpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBh
cmUgbm90IHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3Vy
IHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuDQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9y
IHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yDQpkaXN0cmlidXRlIGl0cyBj
b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLg0KKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0K

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1837GLKXM0002VGREEN_
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
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl
dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5
bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu
cy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x
DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3
Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0
eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp
dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5
XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk
aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl
YWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2
IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoZXRoZXIgdG8gdXNlIG9uZSBtZXNzYWdl
IHR5cGUgaXMgb25lIGlzc3VlIC0gYnV0IEkgdGhpbmsgd2XigJlyZSBhZ3JlZWQgdGhhdCB5b3Ug
d2lsbCBwcm9iYWJseSBuZWVkIHRvIGtub3cgd2hpY2ggaXQgaXMgZnJvbSB0aGUgbWVzc2FnZSBp
dHNlbGYuIFdoaWNoIGlzIGENCiB0cmFkZW9mZiBvZiB0aGUgdXNlIG9mIGEgbWVzc2FnZSB0eXBl
IChjdXJyZW50bHkgbm90IGFuIGlzc3VlIGlmIHVzaW5nIGV4cGVyaW1lbnRhbCBzdWdnZXN0aW9u
cyBvbmx5IC0gSeKAmW0gbm90IHN1cmUgaWYgdGhhdCBpcyBhZ3JlZWQgb3Igbm90KSBhbmQgdGhl
IG1pbmltdW0gdG8gb3RoZXJ3aXNlIGluZGljYXRlIHRoYXQgKHdoaWNoIGlzIGEgdGhyZWUgb2N0
ZXQgVExWIEkgdGhpbmsgLSBkZWZpbml0ZWx5IGluIHRoZSBtZXNzYWdlIHR5cGUgc3BlY2lmaWMN
CiBzcGFjZSwgYXMgaXTigJlzIGhhcmQgdG8gdGhpbmsgb2YgYW55dGhpbmcgbW9yZSBtZXNzYWdl
IHR5cGUgc3BlY2lmaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgcG9zc2libHkgYXMgaW1wb3J0YW50IGlzIHRo
YXQgd2hlcmUgUlJFUXMgYW5kIFJSRVBzIGFyZSBlc3NlbnRpYWxseSB0aGUgc2FtZSwgZXZlbiBp
ZiBkaWZmZXJlbnQgbWVzc2FnZSB0eXBlcywgdGhlcmXigJlzIG9uZSBkZXNjcmlwdGlvbiBvZiB3
aGF0IHRoZXkgZG8gdGhhdA0KIGlzIGNvbW1vbi4gQWdhaW4sIG1heWJlIHRoZXJlIGFscmVhZHkg
aXMsIEkgZG9u4oCZdCBrbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3
RSI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFs
IEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9y
aWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNC
RUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wg
Jm5ic3A7PGI+RToNCjwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVt
cy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs
bGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1z
Zm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMu
Y29tL2FpIj48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2Fp
PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGll
ZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBX
YWxlcyBObzogMDEzMzc0NTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmss
IEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFZpY3RvcmlhIE1lcmNpZWNh
IFttYWlsdG86dm1lcmNpZWNhMEBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjYgQXBy
aWwgMjAxNiAxMTozMDxicj4NCjxiPlRvOjwvYj4gRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk8
YnI+DQo8Yj5DYzo8L2I+IFVscmljaCBIZXJiZXJnOyBUaG9tYXMgSGVpZGUgQ2xhdXNlbjsgQ2hy
aXN0b3BoZXIgRGVhcmxvdmU7IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0PGJy
Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFuZXRdIFN5bW1ldHJpYyBsaW5rIG1ldHJpY3MgKHdh
czogUmU6IE1lc3NhZ2UgaW50ZWdyaXR5IGFuZCBtZXNzYWdlIG11dGFiaWxpdHkpPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBw
dCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls
ZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh
Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3
aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FS
TklORyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBv
dXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIg
b3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hl
dGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMg
b3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24g
cmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxl
bT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4g
bG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRw
Oi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGln
aHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8
YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1
cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBF
bWFpbHMucGRmIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JbnRlcmVzdGluZyBxdWVz
dGlvbi4uLldlIGFscmVhZHkgZG8gY2hhbmdlIG1ldHJpY3MgaW4gdGhlIFJSRVEgc28gdGhhdCBl
dmVyeSBpbnRlcm1lZGlhdGUgcm91dGVyIGxlYXJucyB0aGUgbWV0cmljIG9mIHRoZSByb3V0ZSB0
byBPcmlnQWRkci4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5JZiB3ZSBkb24ndCBpbmNsdWRlIFZhbGlkaXR5VGltZSBvciBBY2tSZXEgaW4gdGhlIFJSRVAs
IHRoZW4gaXRzIHVzZSBpcyBwcmV0dHkgc2ltaWxhciB0byBSUkVRLiBBcmUgeW91IHRoaW5raW5n
IHdlIGNvdWxkIHVzZSBvbmUgbWVzc2FnZSB0eXBlIGFuZCBqdWRnZSBmcm9tIHRoZSBjb250ZW50
cyBvZiBpdCB3aGV0aGVyIGl0cyBhIHJlcXVlc3Qgb3IgYSByZXBseT88bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij5pLmUuIGlmIGl0cyBnb3QgT3JpZ1NlcU51bSBpdHMgYSBSUkVRLCBpZiBpdHMgZ290IFRhcmdT
ZXFOdW0gaXRzIGEgUlJFUD8gQnV0IHRoaXMgd291bGQgbWFrZSBpdCBpbXBvc3NpYmxlIGZvciBh
biBleHRlbnNpb24gd2hlcmUgeW91IG1pZ2h0IHdhbnQgdG8gaW5jbHVkZSBib3RoIHNlcW51bXMu
IFdvdWxkIHRoZXJlIGJlIHNpbWlsYXIgYXJndW1lbnRzIGFnYWluc3QNCiB1c2luZyB0aGUgcHJl
c2VuY2Ugb2YgT3JpZ01ldHJpYyB0byBzaWduYWwgaXQncyBhIFJSRVE/IE9yIHdvdWxkIHlvdSBp
bnRyb2R1Y2UgYSBmbGFnIHNvbWV3aGVyZSBpbmRpY2F0aW5nIHRoYXQgaXQncyBhIHJlcXVlc3Qg
b3IgYSByZXNwb25zZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPktpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+VmljdG9yaWEuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk9uIFR1ZSwgQXByIDI2LCAyMDE2IGF0IDk6NDQgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhl
ciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20i
IHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB5b3UgYWxzbyBj
aGFuZ2UgbWV0cmljcyBpbiBhbiBSUkVRICh3aGljaCBpZiB5b3Ugd2FudCB0byBlc3RhYmxpc2gg
YXN5bW1ldHJpYyBtZXRyaWNzIGJvdGggZW5kcw0KIHRvIGVhY2ggb3RoZXIgaXMgbG9naWNhbCkg
d2hhdCBhY3R1YWxseSBub3cgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhbiBSUkVRIGFuZCBh
biBSUkVQLiAoRXZlbiBpZiB5b3UgbXVsdGljYXN0IG9uZSBhbmQgdW5pY2FzdCB0aGUgb3RoZXIs
IG9yIG11bHRpY2FzdCBib3RoIGJ1dCBvbmUgb25seSBvbiBvbmUgaW50ZXJmYWNlLCB0aGF04oCZ
cyBub3QgYSBkaWZmZXJlbmNlIGluIHRoZSBtZXNzYWdlLikgT2YgY291cnNlIHlvdSBtYXkgbmVl
ZCB0bw0KIGtub3cgd2hpY2ggb25lIGEgcGFydGljdWxhciBtZXNzYWdlIGlzLCBidXQgYW55dGhp
bmcgZWxzZT8gKFNvcnJ5LCBtZWFudCB0byBzYXkgaWYgeW91IHNlcGFyYXRlIG91dCB0aGUgUlJF
UV9BY2sgbWVjaGFuaXNtIGFuZCBhc3N1bWluZyBubyBpbnRlcm1lZGlhdGUgdmFsaWRpdHkgdGlt
ZXMuKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMDA3RTdFIj4tLQ0KPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy
LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3Rv
cGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lz
dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdF
Ij48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0Qi
PlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZu
YnNwOzxhIGhyZWY9InRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0IiB0YXJnZXQ9Il9i
bGFuayI+JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NDwvYT4NCiAmbmJzcDt8ICZuYnNwOzxiPkU6IDwv
Yj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0i
X2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRl
bGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxt
c2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1z
LmNvbS9haSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53d3cu
YmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIi
PkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVk
IGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h
cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5
MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1
cnJleSwgR1UyIDdZUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVmljdG9yaWENCiBNZXJjaWVjYSBbbWFpbHRv
OjxhIGhyZWY9Im1haWx0bzp2bWVyY2llY2EwQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZt
ZXJjaWVjYTBAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNSBBcHJpbCAyMDE2
IDE4OjIyPGJyPg0KPGI+VG86PC9iPiBVbHJpY2ggSGVyYmVyZzxicj4NCjxiPkNjOjwvYj4gVGhv
bWFzIEhlaWRlIENsYXVzZW47IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBDaHJpc3RvcGhl
ciBEZWFybG92ZTsgTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3Q8YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gU3ltbWV0cmljIGxpbmsgbWV0cmljcyAod2FzOiBSZTog
TWVzc2FnZSBpbnRlZ3JpdHkgYW5kIG1lc3NhZ2UgbXV0YWJpbGl0eSk8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp
diBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4w
cHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxp
Z246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1hdHRhY2htZW50OnNjcm9sbDti
YWNrZ3JvdW5kLXBvc2l0aW9uLXg6MCU7YmFja2dyb3VuZC1wb3NpdGlvbi15OjAlIj4NCjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyO2JhY2tn
cm91bmQ6d2hpdGU7YmFja2dyb3VuZC1hdHRhY2htZW50OnNjcm9sbDtiYWNrZ3JvdW5kLXBvc2l0
aW9uLXg6MCU7YmFja2dyb3VuZC1wb3NpdGlvbi15OjAlIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPC9zcGFuPjwvYj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50
ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDt0
ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtYXR0YWNobWVudDpz
Y3JvbGw7YmFja2dyb3VuZC1wb3NpdGlvbi14OjAlO2JhY2tncm91bmQtcG9zaXRpb24teTowJSI+
DQo8aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2Fn
ZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBh
biBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48YnI+DQpDb25zaWRlciBjYXJlZnVs
bHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNo
bWVudHMgb3IgcmVwbHkuPGJyPg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+PC9p
PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3Nw
YW4+PC9pPjwvYj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0
aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscw0KIHlvdSByZWNlaXZlLCBjbGljayA8
YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1
cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiIHRhcmdldD0iX2JsYW5r
Ij4NCmhlcmU8L2E+Ljxicj4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBw
bGVhc2UgZm9sbG93IDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20v
aG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIw
U3VzcGljaW91cyUyMEVtYWlscy5wZGYiIHRhcmdldD0iX2JsYW5rIj4NCnRoaXMgcHJvY2Vzczwv
YT4uPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5IaSBVbHJpY2gsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RG8gd2UganVzdCBuZWVkIHRvIGFkZCB1cCBsaW5rIGNv
c3RzIGxvb2tpbmcgYmFja3dhcmRzIHRvIHdoZXJlIHRoZSBtZXNzYWdlIGNhbWUgZnJvbT8gQmFj
ayB0b3dhcmQgT3JpZ0FkZHIgaW4gYSBSUkVRLCBiYWNrIHRvd2FyZCBUYXJnQWRkciBpbiBhIFJS
RVA/IEVhY2ggaW50ZXJtZWRpYXRlIGhvcCBhZGRzDQogdGhlIGNvc3Qgb2YgdGhlIGxpbmsgZnJv
bSBpdHNlbGYgYmFjayB0byB0aGUgbGFzdCByb3V0ZXIgd2hpY2ggZm9yd2FyZGVkIHRoZSBtZXNz
YWdlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+QXQgUlJFUF9HZW4gd2Ugd291bGQgZW5kIHVwIHdpdGggdGhlIHJvdXRlIGNvc3QgbG9v
a2luZyBpbiB0aGUgY29ycmVjdCBkaXJlY3Rpb24gZnJvbSBSUkVQX0dlbiBiYWNrIHRvIE9yaWdB
ZGRyLCBhbG9uZyB0aGUgcmV2ZXJzZSBvZiB0aGUgcm91dGUgdGhlIFJSRVEgdG9vayAoYWx0aG91
Z2ggdGhhdCdzIG5vdA0KIG5lY2Vzc2FyaWx5IHRoZSBvcHRpbWFsIHJvdXRlIHRvIE9yaWdBZGRy
KSwgYW5kIGF0IFJSRVFfR2VuIHdlIHdvdWxkIGdldCB0aGUgcm91dGUgY29zdCBhbG9uZyB0aGUg
b3B0aW1hbCByb3V0ZSB3aGljaCB0aGUgUlJFUSB0cmF2ZWxsZWQgb24sIGZyb20gUlJFUV9HZW4g
dG8gVGFyZ0FkZHIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5LaW5kIHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlZpY3RvcmlhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgQXByIDI1LCAyMDE2IGF0IDQ6NTEg
UE0sIFVscmljaCBIZXJiZXJnICZsdDs8YSBocmVmPSJtYWlsdG86dWxyaWNoQGhlcmJlcmcubmFt
ZSIgdGFyZ2V0PSJfYmxhbmsiPnVscmljaEBoZXJiZXJnLm5hbWU8L2E+Jmd0OyB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGksPGJyPg0KPGJyPg0KSSBhbSBp
biB0aGUgcHJvY2VzcyBvZiByZXZpZXdpbmcgdGhlIEFPRFZ2MiBkcmFmdCwgYW5kIGxpa2UgVGhv
bWFzLCBJPGJyPg0Kd2FzIHN1cnByaXNlZCBhYm91dCB5b3VyIGNvbmNsdXNpb24gdG8gbW92ZSAm
cXVvdDthc3ltbWV0cmljIGxpbmtzJnF1b3Q7IG91dCBvZjxicj4NCnNjb3BlIG9mIEFPRFZ2Mi4g
TW9zdCAoaWYgbm90IGFsbCkgd2lyZWxlc3MgbmV0d29ya3MgdGhhdCBJIGhhdmUgc2Vlbjxicj4N
CmluY2x1ZGUgYXN5bW1ldHJpYyBsaW5rcy4gSSBkb24ndCB0aGluayBpdCdzIGEgZ29vZCBpZGVh
IG1vdmluZyB0aGlzPGJyPg0Kb3V0IG9mIHRoZSBwcm90b2NvbC48YnI+DQo8YnI+DQpCZXN0IHJl
Z2FyZHM8YnI+DQpVbHJpY2g8YnI+DQo8YnI+DQpPbiBNb24sIEFwciAyNSwgMjAxNiBhdCA3OjE4
IEFNLCZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmciIHRh
cmdldD0iX2JsYW5rIj5pZXRmQHRob21hc2NsYXVzZW4ub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0K
Jmd0O1suLi5dPGJyPg0KJmd0OyBTaW5jZSB3ZeKAmXJlIGRpc2N1c3NpbmcgYmktZGlyZWN0aW9u
YWxpdHkgb2YgbGlua3MgaGVyZSwgYW5kIHRoZSBuZWNlc3NpdHkgb2Y8YnI+DQomZ3Q7IGEgbWVj
aGFuaXNtIGZvciBoYW5kbGluZyB0aGVzZSwgSSB3YW50IHRvIGNhbGwgYXR0ZW50aW9uIHRvIGEg
cmVsYXRlZCBpc3N1ZSw8YnI+DQomZ3Q7IGFzIEkgaGludGVkIHByZXZpb3VzbHkuPGJyPg0KJmd0
Ozxicj4NCiZndDsgVGhlIGFic3RyYWN0IHN0YXRlcyB0aGF0IHRoZSBwcm90b2NvbDo8YnI+DQom
Z3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgLi4uaXMgaW50ZW5kZWQgZm9yIHVzZSBieSBtb2Jp
bGUgcm91dGVycyBpbiB3aXJlbGVzcywgbXVsdGlob3A8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBu
ZXR3b3Jrcy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgU2VjdGlvbiA1IHBhcmFncmFw
aCA0Jm5ic3A7IG9mIHRoZSBkb2N1bWVudCwgaG93ZXZlciwgcmVhZHM6PGJyPg0KJmd0Ozxicj4N
CiZndDsmbmJzcDsgJm5ic3A7IEFzc3VtaW5nIGxpbmsgbWV0cmljcyBhcmUgc3ltbWV0cmljLCB0
aGUgY29zdCBvZiB0aGUgcm91dGVzIGluc3RhbGxlZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGlu
IHRoZSBMb2NhbCBSb3V0ZSBTZXQgYXQgZWFjaCByb3V0ZXIgd2lsbCBiZSBjb3JyZWN0LiZuYnNw
OyBXaGlsZSB0aGlzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgYXNzdW1wdGlvbiBpcyBub3QgYWx3
YXlzIGNvcnJlY3QsIGNhbGN1bGF0aW5nIGluY29taW5nL291dGdvaW5nPGJyPg0KJmd0OyZuYnNw
OyAmbmJzcDsgbWV0cmljIGRhdGEgaXMgb3V0c2lkZSBvZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50
Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGRvIG5vdCBrbm93IG9mIGFueSB3aXJl
bGVzcyBzeXN0ZW1zLCB3aGVyZSB0aGUgYXNzdW1wdGlvbiB0aGF0IOKAnGxpbms8YnI+DQomZ3Q7
IG1ldHJpY3MgYXJlIHN5bW1ldHJpY+KAnSBhY3R1YWxseSBob2xkcy4gQ29uc2VxdWVudGx5LCB0
aGUgY29uY2x1c2lvbiBpbiB0aGU8YnI+DQomZ3Q7IHF1b3RlZCBwYXJhZ3JhcGg6PGJyPg0KJmd0
Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBjYWxjdWxhdGluZyBpbmNvbWluZy9v
dXRnb2luZzxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG1ldHJpYyBkYXRhIGlzIG91dHNpZGUgb2Yg
c2NvcGUgb2YgdGhpcyBkb2N1bWVudC48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSXMg
bm90IGFuIGFjY2VwdGFibGUgZGVzaWduIGNob2ljZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaGls
ZSB0aGlzIHByb3RvY29sIG1heSBub3Qgd2FudCB0byDigJxjYWxjdWxhdGUgaWYgZm9yIHRoaXMg
bGluayB0aGUgbWV0cmljczxicj4NCiZndDsgaXMgNCBvciA14oCdLCB0aGUgcHJvdG9jb2wgbXVz
dCBiZSBhYmxlIHRvIGNvbnZleSBhbmQgZGlzdGluZ3Vpc2ggdGhhdCDigJx0aGU8YnI+DQomZ3Q7
IG1ldHJpYyBmcm9tIEEgdG8gQiBpcyA0LCBhbmQgdGhlIG1ldHJpYyBmcm9tIEIgdG8gQSBpcyAx
OeKAnS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIGlzIGEg4oCccmVsYXRlZCBpc3N1ZeKAnSBz
aW5jZSB0aGUgc29sdXRpb24gbWF5IChhcyB3aXRoIHRoZTxicj4NCiZndDsgYmktZGlyZWN0aW9u
YWxpdHkgY2hlY2spIGJlIGluIHRoZSB0cmlnZ2VyZWQgbmVpZ2hib3VyIGRldGVjdGlvbiBtZWNo
YW5pc206PGJyPg0KJmd0OyB0aGF0IGV4Y2hhbmdlIGNvdWxkLCBpZiBkZXNpZ25lZCBjYXJlZnVs
bHksIGJlIHVzZWQgdG8gcHJvYmUgZm9yIGFuZCBjb252ZXk8YnI+DQomZ3Q7IG1ldHJpY3MgaW5m
b3JtYXRpb24sIGFsc28uPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt
YWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9yZzwvYT48
YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0
IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t
YW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwPioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqPGJyPg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwg
dG8gdGhlIGludGVuZGVkPGJyPg0KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2Vk
LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNpcGllbnQgcGxlYXNlIGRlbGV0
ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+DQpZb3Ugc2hv
dWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9y
PGJyPg0KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+DQoq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1837GLKXM0002VGREEN_--


From nobody Tue Apr 26 06:17: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 F057212D129 for ; Tue, 26 Apr 2016 06:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zS8Uk1V6oPei for ; Tue, 26 Apr 2016 06:17:26 -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 8C7C612D130 for ; Tue, 26 Apr 2016 06:17:25 -0700 (PDT)
Received: from rosout.astrium.eads.net ([10.221.0.46]) by isabel.astrium.eads.net (8.14.4/8.14.4) with ESMTP id u3QDHMQZ001100; Tue, 26 Apr 2016 14:17:22 +0100
Received: from rosout.astrium.eads.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9B52A3C805E; Tue, 26 Apr 2016 14:17:22 +0100 (BST)
Received: from localhost (unknown [127.0.0.1]) by IMSVA (Postfix) with SMTP id 8EB693C8061; Tue, 26 Apr 2016 14:17:22 +0100 (BST)
X-IMSS-HAND-OFF-DIRECTIVE: 127.0.0.1:10026
Received: from AUK52840.UKN.UKNROOT.ASTRIUM.CORP (unknown [10.221.1.31]) by rosout.astrium.eads.net (Postfix) with ESMTPS id 08BA63C805D; Tue, 26 Apr 2016 14:17:15 +0100 (BST)
Received: from AUK52982.UKN.UKNROOT.ASTRIUM.CORP ([fe80::543e:db1:48aa:1c6]) by AUK52840.UKN.UKNROOT.ASTRIUM.CORP ([fe80::7584:4b98:38c0:4ce7%15]) with mapi id 14.03.0123.003; Tue, 26 Apr 2016 14:17:14 +0100
From: "MATTY, Steven" 
To: "'Rick Taylor'" , "manet@ietf.org" 
Thread-Topic: draft-ietf-manet-dlep-22 submitted
Thread-Index: AQHRkRL+F04MDIxdbUK+r54MalYdS5+cWYow
Date: Tue, 26 Apr 2016 13:17:14 +0000
Message-ID: 
References: <14984_1460063926_5706CEB6_14984_9625_1_1460063893.2056.30.camel@tropicalstormsoftware.com>
In-Reply-To: <14984_1460063926_5706CEB6_14984_9625_1_1460063893.2056.30.camel@tropicalstormsoftware.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-22284.006
X-TM-AS-Result: No--13.999-5.0-31-10
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
X-imss-scan-details: No--13.999-5.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1549-8.0.1202-22284.006
X-TMASE-Result: 10--13.999500-10.000000
X-TMASE-MatchedRID: csPTYAMX1+GQ4R94VvPFuVPjo7D4SFg4zqjWbj4t+i/fUZT83lbkEAbv pZUZTZvqTWLw2jvbfpzPDExIjNkthvnVY0DWsTq3nVTWWiNp+v9hBfGxmdHCgjRCaZSKE/Osf0x RbeegyCaW/5k55DP0iBw58L6+gfo0WY4dPt9TpLbdGyK7SuYx/ODGuXjxtbvLikvLPxTKpjiM82 3SqBkeEnNAZ3Iao4w9fyYDewMOrQBWRVlrjsKO8Grz/G/ZSbVq+gtHj7OwNO2J8YJgRrgXFzGio g6v2d4NtN+oQObzkwICgnZr44h5oO3SIdIWhaYV
X-TMASE-SNAP-Result: 1.811037.0001-0-1-22:0,12:0
Archived-At: 
Subject: Re: [manet] draft-ietf-manet-dlep-22 submitted
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, 26 Apr 2016 13:17:28 -0000

Hi all

It's all been very quiet on the DLEP front for the best part of 3 weeks..=
.
I personally have no comments to add for DLEPv22, this is just a nudge to=
 see if it heading to WGLC soon

Regards

Steve
>-----Original Message-----
>From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Rick Taylor
>Sent: Thursday, April 07, 2016 10:18 PM
>To: manet@ietf.org
>Subject: [manet] draft-ietf-manet-dlep-22 submitted
>
>All,
>
>We have just submitted DLEP-22.
>
>https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/
>
>This is an update to fix nits and typos.
>
>Thanks,
>
>Rick Taylor
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www.ietf.org/mailman/listinfo/manet
>
>This mail has originated outside your organization, either from an exter=
nal
>partner or the Global Internet.
>Keep this in mind if you answer this message.
>

This email (including any attachments) may contain confidential and/or pr=
ivileged information or information otherwise protected from disclosure. =
If you are not the intended recipient, please notify the sender immediate=
ly, do not copy this message or any attachments and do not use it for any=
 purpose or disclose its content to any person, but delete this message a=
nd any attachments from your system. Airbus Defence and Space Limited dis=
claims any and all liability if this email transmission was virus corrupt=
ed, altered or falsified.
-o-
Emails to Airbus Defence and Space Limited may be processed, recorded and=
 monitored outside the UK.
-o-
Airbus Defence and Space Limited, Registered in England and Wales No. 244=
9259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, =
England


From nobody Tue Apr 26 06:27: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 69AA612D13B for ; Tue, 26 Apr 2016 06:27:03 -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 gywH7u5Mqboc for ; Tue, 26 Apr 2016 06:27:01 -0700 (PDT)
Received: from smtp1.idirect.net (smtp1.idirect.net [198.180.159.61]) (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 99A7412D13E for ; Tue, 26 Apr 2016 06:27:01 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,536,1454994000";  d="scan'208";a="4816638"
IronPort-PHdr: =?us-ascii?q?9a23=3A3LGBvxTFgiuxg9TnHEzL5EFJ+dpsv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa65ZBKN2/xhgRfzUJnB7Loc0qyN4/CmBj1LvM3J8ChbNscTB1ld0Y?= =?us-ascii?q?RetjdjKfDGIHWzFOTtYS0+EZYKf35e1Fb/D3JoHt3jbUbZuHy44G1aMBz+MQ1o?= =?us-ascii?q?Ora9QdaK3Iyfntq/8JzLYghOmCH1IfYrdE33/k3tsZxcpKJeFpd1giDVr2VFfa?= =?us-ascii?q?4ekXh0KEyemVD579us7bZq8j5apuln/MlFB+GyMJ45Rr8QMD03N2cvq4W/rxjI?= =?us-ascii?q?TiOT/HwEU24flgFUBBLA9xb0Qoj4qCa8ve14jm3Sd8j/S70ocTWv86ktTwXnwm?= =?us-ascii?q?9TMjc//X3/i8FsguRcuh339DJlxIuBKrucKP5/cK2ZNegGTGxFU9cbH3haGIqg?= =?us-ascii?q?a4oBAcIAMedCooLh4V0DsU3tVkGXGOrzx2oQ1TfN1qog3rFkSFme0Q=3D=3D?=
X-IPAS-Result: =?us-ascii?q?A2A3AQDJax9X/8r6+gpeGgEBAYNufQa5dgENgWoKFwuFbAK?= =?us-ascii?q?BchQBAQEBAQEBAYELgi2CFAEBAQEDAQEBNzQDFAQCAQgRBAEBHwkHJwsUCQgCB?= =?us-ascii?q?AESCIgwxAcBAQEBAQEBAQEBAQEBAQEBAQEBEwSGIoRKhA8KBgIBhXMFmAsFAYV?= =?us-ascii?q?7iBSBboRNiF2GJIkMHgEBhC1sh0I/fwEBAQ?=
From: "Ratliff, Stanley" 
To: "MATTY, Steven" , 'Rick Taylor' , "manet@ietf.org" 
Thread-Topic: draft-ietf-manet-dlep-22 submitted
Thread-Index: AQHRkRL+F04MDIxdbUK+r54MalYdS5+cWYowgAAAzGA=
Date: Tue, 26 Apr 2016 13:26:58 +0000
Message-ID: 
References: <14984_1460063926_5706CEB6_14984_9625_1_1460063893.2056.30.camel@tropicalstormsoftware.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.250.250.20]
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [manet] draft-ietf-manet-dlep-22 submitted
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, 26 Apr 2016 13:27:03 -0000

Steve, =


DLEP successfully completed WGLC at version 21. Publication of the draft wa=
s requested by the Working Group. It's on the queue for a review at the IES=
G level. During the publication process, there will most likely be a need t=
o alter a small bit of text here & there (based on the IESG review comments=
). If the changes are small (for example, fixing typos), then a new version=
 will be posted, and the process will continue without the WG needing to be=
 involved. If proposed changes are large, the document may be returned to t=
he WG for additional discussion. But for now, there's no Working Group acti=
on required on the document. =


Regards,
Stan

> -----Original Message-----
> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of MATTY, Steven
> Sent: Tuesday, April 26, 2016 9:17 AM
> To: 'Rick Taylor' ; manet@ietf.org
> Subject: Re: [manet] draft-ietf-manet-dlep-22 submitted
> =

> Hi all
> =

> It's all been very quiet on the DLEP front for the best part of 3 weeks...
> I personally have no comments to add for DLEPv22, this is just a nudge to=
 see
> if it heading to WGLC soon
> =

> Regards
> =

> Steve
> >-----Original Message-----
> >From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Rick Taylor
> >Sent: Thursday, April 07, 2016 10:18 PM
> >To: manet@ietf.org
> >Subject: [manet] draft-ietf-manet-dlep-22 submitted
> >
> >All,
> >
> >We have just submitted DLEP-22.
> >
> >https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/
> >
> >This is an update to fix nits and typos.
> >
> >Thanks,
> >
> >Rick Taylor
> >_______________________________________________
> >manet mailing list
> >manet@ietf.org
> >https://www.ietf.org/mailman/listinfo/manet
> >
> >This mail has originated outside your organization, either from an
> >external partner or the Global Internet.
> >Keep this in mind if you answer this message.
> >
> =

> This email (including any attachments) may contain confidential and/or
> privileged information or information otherwise protected from disclosure=
. If
> you are not the intended recipient, please notify the sender immediately,=
 do
> not copy this message or any attachments and do not use it for any purpose
> or disclose its content to any person, but delete this message and any
> attachments from your system. Airbus Defence and Space Limited disclaims
> any and all liability if this email transmission was virus corrupted, alt=
ered or
> falsified.
> -o-
> Emails to Airbus Defence and Space Limited may be processed, recorded and
> monitored outside the UK.
> -o-
> Airbus Defence and Space Limited, Registered in England and Wales No.
> 2449259 Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire,
> SG1 2AS, England
> =

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


_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________


From nobody Tue Apr 26 06:31: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 2915C12D13E for ; Tue, 26 Apr 2016 06:31:36 -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 bMwXbw56oL3x for ; Tue, 26 Apr 2016 06:31:34 -0700 (PDT)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001: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 614FD12D13B for ; Tue, 26 Apr 2016 06:31:34 -0700 (PDT)
Received: by mail-ig0-x22d.google.com with SMTP id g8so15251356igr.0 for ; Tue, 26 Apr 2016 06:31:34 -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=28MmtzV0VEjw/PGSVyDz9LkCl17tRSjkiWyZHk+C/dA=; b=0Qp0G/PURAQQP/j2wmvzbcn0xqC3wDud6EEC1KEDy0ii31UxTebyuWW4kFhxgsnQFU AmT96Zc7XiQfN0vcAzosQu/Fuqt7aVJ6nRxHHcCBWAmcS8T3jrxln7eMGWyjX22JxyhD cDH8hx3/+HxCXM/1Xesoci/A/kGFmr62YsJOIwxwLoERm0btU1q7melsY8bhRDbVQrej BimN5Y39yFyXMUj6g6y7oS357Ce+VGz7kShY5c7+/5SOD7G0/oboYy51FWKyn7b15vh1 fuQELw0vg8zOMy0MMwGYlnOp/nBR0lkpC6nAXcSzLF+KV9OdUpt+qf1fi/wh87c99IOu zqJQ==
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=28MmtzV0VEjw/PGSVyDz9LkCl17tRSjkiWyZHk+C/dA=; b=RephpfP0+LN16P1L3ZDeFam6zsQwPu+L1A8iBwgZb2ZUTfRt5oDXSsn73TreZWXQXw W04p48+uKOmJpAAOYcqAa57AZsjpOPTZZWrRaqnDcez2MCZ6WhQzWfM/Y37jRTXuwMj3 CozPzxNfEqNo8B8Pjtwhp07EONIQzrNkZ/WaC845948taYa2HMk5fGm3d7Jhuv1+dlFm jtCWcDPdk0Bu5Ub0tdSQLye9QbqPIl8ZKX/IBHJE+DsuIv1zVFBRTQ9Gp7FPAp2t12FB z7uE/r5rGOE9MrCVCmUN9603AMX7xsUjFG+m2SQsyk+vgek4pIpt1Zgtr2o4hBn8sabj roJw==
X-Gm-Message-State: AOPr4FXiNolUUKDqdy+DsTKK3aIrKrS5UktXX5lR/FYPZekahSwmRoG4xWw5OINWDRp+1pTAEAX99bU8XKl/EA==
MIME-Version: 1.0
X-Received: by 10.50.33.225 with SMTP id u1mr3502357igi.36.1461677493422; Tue, 26 Apr 2016 06:31:33 -0700 (PDT)
Received: by 10.79.72.68 with HTTP; Tue, 26 Apr 2016 06:31:33 -0700 (PDT)
Date: Tue, 26 Apr 2016 09:31:33 -0400
Message-ID: 
From: Stan Ratliff 
To: MANET IETF 
Content-Type: multipart/alternative; boundary=f46d044469c9c5939c0531634ff6
Archived-At: 
Subject: [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: Tue, 26 Apr 2016 13:31:36 -0000

--f46d044469c9c5939c0531634ff6
Content-Type: text/plain; charset=UTF-8

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

--f46d044469c9c5939c0531634ff6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


WG,=C2=A0

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...=C2=A0

Does the lack of discussion her=
e on-list indicate that the members of the WG have no interest in a re-char=
ter effort? Or is this (hopefully) a case of having "bigger fish to fr=
y"?=C2=A0

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

Regards,
S=
tan
=C2=A0


--f46d044469c9c5939c0531634ff6--


From nobody Tue Apr 26 06:34:46 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 BFE0D12D0A7 for ; Tue, 26 Apr 2016 06:34:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rM45f7YRnVqP for ; Tue, 26 Apr 2016 06:34:42 -0700 (PDT)
Received: from mirabel.astrium.eads.net (mirabel.astrium.eads.net [194.62.210.46]) (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 8B38D12D1BF for ; Tue, 26 Apr 2016 06:34:40 -0700 (PDT)
Received: from rosout.astrium.eads.net ([10.221.0.46]) by mirabel.astrium.eads.net (8.14.4/8.14.4) with ESMTP id u3QDYZ2T029962; Tue, 26 Apr 2016 14:34:35 +0100
Received: from rosout.astrium.eads.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8D93D3C805D; Tue, 26 Apr 2016 14:34:35 +0100 (BST)
Received: from localhost (unknown [127.0.0.1]) by IMSVA (Postfix) with SMTP id 81F2E3C8038; Tue, 26 Apr 2016 14:34:35 +0100 (BST)
X-IMSS-HAND-OFF-DIRECTIVE: 127.0.0.1:10026
Received: from AUK52840.UKN.UKNROOT.ASTRIUM.CORP (unknown [10.221.1.31]) by rosout.astrium.eads.net (Postfix) with ESMTPS id 223D53C8038; Tue, 26 Apr 2016 14:34:26 +0100 (BST)
Received: from AUK52982.UKN.UKNROOT.ASTRIUM.CORP ([fe80::543e:db1:48aa:1c6]) by AUK52840.UKN.UKNROOT.ASTRIUM.CORP ([fe80::7584:4b98:38c0:4ce7%15]) with mapi id 14.03.0123.003; Tue, 26 Apr 2016 14:34:25 +0100
From: "MATTY, Steven" 
To: "'Ratliff, Stanley'" , "'Rick Taylor'" , "manet@ietf.org" 
Thread-Topic: draft-ietf-manet-dlep-22 submitted
Thread-Index: AQHRkRL+F04MDIxdbUK+r54MalYdS5+cWYowgAAAzGCAAAP9YA==
Date: Tue, 26 Apr 2016 13:34:24 +0000
Message-ID: 
References: <14984_1460063926_5706CEB6_14984_9625_1_1460063893.2056.30.camel@tropicalstormsoftware.com>  <18572_1461677223_571F6CA6_18572_7307_1_b5b496f559bb4634a086148b68ac587e@VAUSDITCHM2.idirect.net>
In-Reply-To: <18572_1461677223_571F6CA6_18572_7307_1_b5b496f559bb4634a086148b68ac587e@VAUSDITCHM2.idirect.net>
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-22284.006
X-TM-AS-Result: No--30.221-5.0-31-10
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
X-imss-scan-details: No--30.221-5.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1549-8.0.1202-22284.006
X-TMASE-Result: 10--30.221200-10.000000
X-TMASE-MatchedRID: Kx0w2sAofbuQ4R94VvPFueYAh37ZsBDCVjkEEmuL2x3adW4iYSMjUUDJ cYxjRM/VKqVj0cf/Tif7wKREjncBxPnVY0DWsTq3GFMYlDUzwr3UZrYvzuo9AtYIrMNiSqPJXxR tKfVFN8M01GXhnwfoh0N0dAOd1po5vkWjwSDbUuT0hv/rD7WVZMMdI0UcXEHzGrKZCS5aXXXfBM dmNimy7Pi0oIKhZqI+fb1p2EyLnCB9RnEeQHhLO1Pjo7D4SFg4zqjWbj4t+i/fUZT83lbkEAbvp ZUZTZvq1CCGjlHZzRs0+NJuUFRWYzUY01xhNnfIQr2qXCJMSV/x6DjDLao3TkaEuXPXlR5qbm3L TFX5bZ1DOOh4Nm/v+5z/ctMEry07hzsX7/vYqPDK09/T6AzbVqvd3WuZF0KAVxk27EKh25L1kfo kRBzdq1j5cal+ZpcswozhoMGi96vm6E2uD55SEpmug812qIbzRtu4vtjjtzQCB9odk/ZD8IrWEM Apefe4j7gRBvCZBYjaw3UtPi2e0mnoPDE7sE9AzAwlZ8w0UGBj0mUvAvV2DRBMzcCTqrAdd+SUm nSk3mbi8zVgXoAltlig9kCpMEfCL+25vAeQJJf6APa9i04WGCq2rl3dzGQ1A/3R8k/14e0=
X-TMASE-SNAP-Result: 1.811037.0001-0-1-22:0,12:0
Archived-At: 
Subject: Re: [manet] draft-ietf-manet-dlep-22 submitted
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, 26 Apr 2016 13:34:46 -0000

Hi Stan

Excellent, thanks for the info on the process :)

Regards

Steve

>-----Original Message-----
>From: Ratliff, Stanley [mailto:sratliff@idirect.net]
>Sent: Tuesday, April 26, 2016 2:27 PM
>To: MATTY, Steven; 'Rick Taylor'; manet@ietf.org
>Subject: RE: draft-ietf-manet-dlep-22 submitted
>
>Steve,
>
>DLEP successfully completed WGLC at version 21. Publication of the draft=
 was
>requested by the Working Group. It's on the queue for a review at the IE=
SG
>level. During the publication process, there will most likely be a need =
to alter a
>small bit of text here & there (based on the IESG review comments). If t=
he
>changes are small (for example, fixing typos), then a new version will b=
e
>posted, and the process will continue without the WG needing to be invol=
ved.
>If proposed changes are large, the document may be returned to the WG fo=
r
>additional discussion. But for now, there's no Working Group action requ=
ired
>on the document.
>
>Regards,
>Stan
>
>> -----Original Message-----
>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of MATTY,
>Steven
>> Sent: Tuesday, April 26, 2016 9:17 AM
>> To: 'Rick Taylor' ; manet@ietf.org
>> Subject: Re: [manet] draft-ietf-manet-dlep-22 submitted
>>
>> Hi all
>>
>> It's all been very quiet on the DLEP front for the best part of 3 week=
s...
>> I personally have no comments to add for DLEPv22, this is just a nudge=
 to
>see
>> if it heading to WGLC soon
>>
>> Regards
>>
>> Steve
>> >-----Original Message-----
>> >From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Rick Taylor
>> >Sent: Thursday, April 07, 2016 10:18 PM
>> >To: manet@ietf.org
>> >Subject: [manet] draft-ietf-manet-dlep-22 submitted
>> >
>> >All,
>> >
>> >We have just submitted DLEP-22.
>> >
>> >https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/
>> >
>> >This is an update to fix nits and typos.
>> >
>> >Thanks,
>> >
>> >Rick Taylor
>> >_______________________________________________
>> >manet mailing list
>> >manet@ietf.org
>> >https://www.ietf.org/mailman/listinfo/manet
>> >
>> >This mail has originated outside your organization, either from an
>> >external partner or the Global Internet.
>> >Keep this in mind if you answer this message.
>> >
>>
>> This email (including any attachments) may contain confidential and/or
>> privileged information or information otherwise protected from disclos=
ure.
>If
>> you are not the intended recipient, please notify the sender immediate=
ly,
>do
>> not copy this message or any attachments and do not use it for any pur=
pose
>> or disclose its content to any person, but delete this message and any
>> attachments from your system. Airbus Defence and Space Limited disclai=
ms
>> any and all liability if this email transmission was virus corrupted, =
altered or
>> falsified.
>> -o-
>> Emails to Airbus Defence and Space Limited may be processed, recorded
>and
>> monitored outside the UK.
>> -o-
>> Airbus Defence and Space Limited, Registered in England and Wales No.
>> 2449259 Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire=
,
>> SG1 2AS, England
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>
>
>_____________________________________________________
>This electronic message and any files transmitted with it contains
>information from iDirect, which may be privileged, proprietary
>and/or confidential. It is intended solely for the use of the individual
>or entity to whom they are addressed. If you are not the original
>recipient or the person responsible for delivering the email to the
>intended recipient, be advised that you have received this email
>in error, and that any use, dissemination, forwarding, printing, or
>copying of this email is strictly prohibited. If you received this email
>in error, please delete it and immediately notify the sender.
>_____________________________________________________
>
>
>This mail has originated outside your organization, either from an exter=
nal
>partner or the Global Internet.
>Keep this in mind if you answer this message.
>

This email (including any attachments) may contain confidential and/or pr=
ivileged information or information otherwise protected from disclosure. =
If you are not the intended recipient, please notify the sender immediate=
ly, do not copy this message or any attachments and do not use it for any=
 purpose or disclose its content to any person, but delete this message a=
nd any attachments from your system. Airbus Defence and Space Limited dis=
claims any and all liability if this email transmission was virus corrupt=
ed, altered or falsified.
-o-
Emails to Airbus Defence and Space Limited may be processed, recorded and=
 monitored outside the UK.
-o-
Airbus Defence and Space Limited, Registered in England and Wales No. 244=
9259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, =
England


From nobody Tue Apr 26 06:35: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 9403C12D1CF for ; Tue, 26 Apr 2016 06:35:47 -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 YC7jZHU97YBD for ; Tue, 26 Apr 2016 06:35:45 -0700 (PDT)
Received: from ukmta1.baesystems.com (unknown [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 2281212D1CC for ; Tue, 26 Apr 2016 06:35:44 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,536,1454976000"; d="scan'208";a="64333074"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 26 Apr 2016 14:35:17 +0100
X-IronPort-AV: E=Sophos;i="5.24,536,1454976000"; d="scan'208";a="115553974"
Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 26 Apr 2016 14:35:17 +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, 26 Apr 2016 14:35:17 +0100
From: "Dearlove, Christopher (UK)" 
To: "Ratliff, Stanley" , "MATTY, Steven" , 'Rick Taylor' , "manet@ietf.org" 
Thread-Topic: draft-ietf-manet-dlep-22 submitted
Thread-Index: AQHRkRL+F04MDIxdbUK+r54MalYdS5+cWYowgAAAzGCAAAOxAA==
Date: Tue, 26 Apr 2016 13:35:16 +0000
Message-ID: 
References: <14984_1460063926_5706CEB6_14984_9625_1_1460063893.2056.30.camel@tropicalstormsoftware.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: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [manet] draft-ietf-manet-dlep-22 submitted
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, 26 Apr 2016 13:35:47 -0000

Sometimes the IESG changes are more than just typos, but it still doesn't g=
et returned to the WG.

But also post-WGLC there is wider IETF review, and reviews by various bodie=
s such as SEC-DIR, GEN-ART, RTG-DIR. Typically a couple of those. Which are=
 intended to help the IESG.

-- =

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 Ratliff, Stanley
Sent: 26 April 2016 14:27
To: MATTY, Steven; 'Rick Taylor'; manet@ietf.org
Subject: Re: [manet] draft-ietf-manet-dlep-22 submitted

----------------------! 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.


Steve, =


DLEP successfully completed WGLC at version 21. Publication of the draft wa=
s requested by the Working Group. It's on the queue for a review at the IES=
G level. During the publication process, there will most likely be a need t=
o alter a small bit of text here & there (based on the IESG review comments=
). If the changes are small (for example, fixing typos), then a new version=
 will be posted, and the process will continue without the WG needing to be=
 involved. If proposed changes are large, the document may be returned to t=
he WG for additional discussion. But for now, there's no Working Group acti=
on required on the document. =


Regards,
Stan

> -----Original Message-----
> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of MATTY, Steven
> Sent: Tuesday, April 26, 2016 9:17 AM
> To: 'Rick Taylor' ; manet@ietf.org
> Subject: Re: [manet] draft-ietf-manet-dlep-22 submitted
> =

> Hi all
> =

> It's all been very quiet on the DLEP front for the best part of 3 weeks...
> I personally have no comments to add for DLEPv22, this is just a nudge =

> to see if it heading to WGLC soon
> =

> Regards
> =

> Steve
> >-----Original Message-----
> >From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Rick Taylor
> >Sent: Thursday, April 07, 2016 10:18 PM
> >To: manet@ietf.org
> >Subject: [manet] draft-ietf-manet-dlep-22 submitted
> >
> >All,
> >
> >We have just submitted DLEP-22.
> >
> >https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/
> >
> >This is an update to fix nits and typos.
> >
> >Thanks,
> >
> >Rick Taylor
> >_______________________________________________
> >manet mailing list
> >manet@ietf.org
> >https://www.ietf.org/mailman/listinfo/manet
> >
> >This mail has originated outside your organization, either from an =

> >external partner or the Global Internet.
> >Keep this in mind if you answer this message.
> >
> =

> This email (including any attachments) may contain confidential and/or =

> privileged information or information otherwise protected from =

> disclosure. If you are not the intended recipient, please notify the =

> sender immediately, do not copy this message or any attachments and do =

> not use it for any purpose or disclose its content to any person, but =

> delete this message and any attachments from your system. Airbus =

> Defence and Space Limited disclaims any and all liability if this =

> email transmission was virus corrupted, altered or falsified.
> -o-
> Emails to Airbus Defence and Space Limited may be processed, recorded =

> and monitored outside the UK.
> -o-
> Airbus Defence and Space Limited, Registered in England and Wales No.
> 2449259 Registered Office: Gunnels Wood Road, Stevenage, =

> Hertfordshire,
> SG1 2AS, England
> =

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


_____________________________________________________
This electronic message and any files transmitted with it contains informat=
ion from iDirect, which may be privileged, proprietary and/or confidential.=
 It is intended solely for the use of the individual or entity to whom they=
 are addressed. If you are not the original recipient or the person respons=
ible for delivering the email to the intended recipient, be advised that yo=
u have received this email in error, and that any use, dissemination, forwa=
rding, printing, or copying of this email is strictly prohibited. If you re=
ceived this email in error, please delete it and immediately notify the sen=
der.
_____________________________________________________

_______________________________________________
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 Tue Apr 26 06:37: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 534BE12D1A5 for ; Tue, 26 Apr 2016 06:37:34 -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 i88Wpej_tf2y for ; Tue, 26 Apr 2016 06:37:28 -0700 (PDT)
Received: from ukmta1.baesystems.com (unknown [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 70B0512D130 for ; Tue, 26 Apr 2016 06:37:27 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,536,1454976000"; d="scan'208,217"; a="64334086"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 26 Apr 2016 14:37:26 +0100
X-IronPort-AV: E=Sophos;i="5.24,536,1454976000";  d="scan'208,217";a="115554570"
Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 26 Apr 2016 14:37:25 +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, 26 Apr 2016 14:37:26 +0100
From: "Dearlove, Christopher (UK)" 
To: Stan Ratliff , MANET IETF 
Thread-Topic: [manet] Interim call
Thread-Index: AQHRn8ATkRwmwTCLE02PTjuIoXiMZp+cQYzw
Date: Tue, 26 Apr 2016 13:37:25 +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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1A12GLKXM0002VGREEN_"
MIME-Version: 1.0
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: Tue, 26 Apr 2016 13:37:34 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1A12GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

SeKAmXZlIG1hZGUgc29tZSBjb21tZW50cyBvbi1saXN0Lg0KDQpJZiB0aGVyZeKAmXMgYSB0ZWxl
Y29uIGFuZCBpdOKAmXMgYXQgYSBjb252ZW5pZW50IHRpbWUgKHdpdGggcmVnYXJkIHRvIGJvdGgg
dGltZXpvbmUgYW5kIHdoYXQgZWxzZSBpcyBoYXBwZW5pbmcpICBJIG1pZ2h0IGpvaW4gaW4sIG9y
IG1pZ2h0IG5vdC4gSSBkbyBoYXZlIHNvbWUgZmlzaCB0byBmcnkuDQoNCi0tDQpDaHJpc3RvcGhl
ciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGll
ZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0
ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWls
dG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQg
SW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBD
aGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93
d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBM
aW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lz
dGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdV
MiA3WVANCg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYgT2YgU3RhbiBSYXRsaWZmDQpTZW50OiAyNiBBcHJpbCAyMDE2IDE0OjMyDQpUbzogTUFO
RVQgSUVURg0KU3ViamVjdDogW21hbmV0XSBJbnRlcmltIGNhbGwNCg0KDQoqKiogV0FSTklORyAq
KioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9u
LCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNp
ZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVu
IGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVk
IEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBj
bGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3Nl
Y3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVl
bCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0
cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxp
Z2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4u
DQoqKiogV0FSTklORyAqKioNCkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5h
dGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uLg0KDQpXRywNCg0KSSBhc2tlZCBhIGZl
dyBkYXlzIGFnbyBhYm91dCBhbiBpbnRlcmltIHRlbGVjb24gdG8gZGlzY3VzcyByZWNoYXJ0ZXIu
IEp1c3RpbiBhbHNvIHNlbnQgdGhlIGxhc3QgY29weSBvZiB0aGUgbmV3IGNoYXJ0ZXIgd2Ugd2Vy
ZSB3b3JraW5nIG9uIGluIFByYWd1ZS4gU28gZmFyLCB0aGUgc2lsZW5jZSBoYXMgYmVlbiBkZWFm
ZW5pbmcuLi4NCg0KRG9lcyB0aGUgbGFjayBvZiBkaXNjdXNzaW9uIGhlcmUgb24tbGlzdCBpbmRp
Y2F0ZSB0aGF0IHRoZSBtZW1iZXJzIG9mIHRoZSBXRyBoYXZlIG5vIGludGVyZXN0IGluIGEgcmUt
Y2hhcnRlciBlZmZvcnQ/IE9yIGlzIHRoaXMgKGhvcGVmdWxseSkgYSBjYXNlIG9mIGhhdmluZyAi
YmlnZ2VyIGZpc2ggdG8gZnJ5Ij8NCg0KUGxlYXNlIGluZGljYXRlIHlvdXIgaW50ZXJlc3QgaW4g
aGF2aW5nIGEgY2FsbCB0byBkaXNjdXNzIHRoZSBjaGFydGVyIC0gSSdkIGxpa2UgdG8gc2NoZWR1
bGUgYSBjYWxsIGFyb3VuZCBNYXkgMTAgKDIgd2Vla3MgZnJvbSB0b2RheSkuDQoNClJlZ2FyZHMs
DQpTdGFuDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUg
Y29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHBy
aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRl
bGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3Vs
ZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpk
aXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1A12GLKXM0002VGREEN_
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
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K
ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h
eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9
IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k
eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX
b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJl2ZSBtYWRlIHNvbWUgY29tbWVudHMgb24tbGlzdC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPklmIHRoZXJl4oCZcyBhIHRlbGVjb24gYW5kIGl04oCZcyBhdCBhIGNvbnZlbmll
bnQgdGltZSAod2l0aCByZWdhcmQgdG8gYm90aCB0aW1lem9uZSBhbmQgd2hhdCBlbHNlIGlzIGhh
cHBlbmluZykgJm5ic3A7SSBtaWdodCBqb2luIGluLCBvciBtaWdodCBub3QuIEkgZG8gaGF2ZSBz
b21lDQogZmlzaCB0byBmcnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdF
Ij4tLQ0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwg
RW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3Jp
ZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JF
QkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOyYjNDM7NDQgKDApMTI0NSAyNDIxOTQgJm5ic3A7fCAm
bmJzcDs8Yj5FOg0KPC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z
LmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+PGJyPg0KPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxs
aWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNm
b3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5j
b20vYWkiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8
L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVk
IEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdh
bGVzIE5vOiAwMTMzNzQ1MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywg
R3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbWFuZXQgW21haWx0bzptYW5l
dC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TdGFuIFJhdGxpZmY8YnI+
DQo8Yj5TZW50OjwvYj4gMjYgQXByaWwgMjAxNiAxNDozMjxicj4NCjxiPlRvOjwvYj4gTUFORVQg
SUVURjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbbWFuZXRdIEludGVyaW0gY2FsbDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQg
Mi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9
InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr
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+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XRywmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYXNrZWQgYSBmZXcgZGF5cyBhZ28gYWJvdXQgYW4g
aW50ZXJpbSB0ZWxlY29uIHRvIGRpc2N1c3MgcmVjaGFydGVyLiBKdXN0aW4gYWxzbyBzZW50IHRo
ZSBsYXN0IGNvcHkgb2YgdGhlIG5ldyBjaGFydGVyIHdlIHdlcmUgd29ya2luZyBvbiBpbiBQcmFn
dWUuIFNvIGZhciwgdGhlIHNpbGVuY2UgaGFzIGJlZW4gZGVhZmVuaW5nLi4uJm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgdGhl
IGxhY2sgb2YgZGlzY3Vzc2lvbiBoZXJlIG9uLWxpc3QgaW5kaWNhdGUgdGhhdCB0aGUgbWVtYmVy
cyBvZiB0aGUgV0cgaGF2ZSBubyBpbnRlcmVzdCBpbiBhIHJlLWNoYXJ0ZXIgZWZmb3J0PyBPciBp
cyB0aGlzIChob3BlZnVsbHkpIGEgY2FzZSBvZiBoYXZpbmcgJnF1b3Q7YmlnZ2VyIGZpc2ggdG8g
ZnJ5JnF1b3Q7PyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5QbGVhc2UgaW5kaWNhdGUgeW91ciBpbnRlcmVzdCBpbiBoYXZpbmcgYSBj
YWxsIHRvIGRpc2N1c3MgdGhlIGNoYXJ0ZXIgLSBJJ2QgbGlrZSB0byBzY2hlZHVsZSBhIGNhbGwg
YXJvdW5kIE1heSAxMCAoMiB3ZWVrcyBmcm9tIHRvZGF5KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0YW48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+KioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+ClRoaXMgZW1haWwg
YW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZDxicj4K
cmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg
aW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0g
YW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj4KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2Ug
aXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcjxicj4KZGlzdHJpYnV0ZSBpdHMgY29u
dGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+CioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPC9wPjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1A12GLKXM0002VGREEN_--


From nobody Tue Apr 26 06:42: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 5945112D1A5 for ; Tue, 26 Apr 2016 06:42:01 -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 7YHxwey9LiSf for ; Tue, 26 Apr 2016 06:41:59 -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 4C96D12D152 for ; Tue, 26 Apr 2016 06:41:59 -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; Tue, 26 Apr 2016 14:41:20 +0100
From: Rick Taylor 
To: "ratliffstan@gmail.com" , "manet@ietf.org" 
Thread-Topic: [manet] Interim call
Thread-Index: AQHRn7/2GxqVdqxItEuiSjuFxOGplZ+cMj2A
Date: Tue, 26 Apr 2016 13:40:53 +0000
Message-ID: <1461678053.8100.3.camel@tropicalstormsoftware.com>
References: 
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: <60dfc959-0050-42a0-9ac9-e964c866415e>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Tue, 26 Apr 2016 13:42:01 -0000

SGkgU3RhbiwgQWxsLA0KDQpJIHdvdWxkIGJlIGluIGZhdm91ciBvZiBhbiBpbnRlcmltIG1lZXRp
bmcuDQoNClJpY2sNCg0KT24gVHVlLCAyMDE2LTA0LTI2IGF0IDA5OjMxIC0wNDAwLCBTdGFuIFJh
dGxpZmYgd3JvdGU6DQo+IFdHLCANCj4gDQo+IEkgYXNrZWQgYSBmZXcgZGF5cyBhZ28gYWJvdXQg
YW4gaW50ZXJpbSB0ZWxlY29uIHRvIGRpc2N1c3MgcmVjaGFydGVyLg0KPiBKdXN0aW4gYWxzbyBz
ZW50IHRoZSBsYXN0IGNvcHkgb2YgdGhlIG5ldyBjaGFydGVyIHdlIHdlcmUgd29ya2luZyBvbg0K
PiBpbiBQcmFndWUuIFNvIGZhciwgdGhlIHNpbGVuY2UgaGFzIGJlZW4gZGVhZmVuaW5nLi4uIA0K
PiANCj4gRG9lcyB0aGUgbGFjayBvZiBkaXNjdXNzaW9uIGhlcmUgb24tbGlzdCBpbmRpY2F0ZSB0
aGF0IHRoZSBtZW1iZXJzIG9mDQo+IHRoZSBXRyBoYXZlIG5vIGludGVyZXN0IGluIGEgcmUtY2hh
cnRlciBlZmZvcnQ/IE9yIGlzIHRoaXMNCj4gKGhvcGVmdWxseSkgYSBjYXNlIG9mIGhhdmluZyAi
YmlnZ2VyIGZpc2ggdG8gZnJ5Ij8gDQo+IA0KPiBQbGVhc2UgaW5kaWNhdGUgeW91ciBpbnRlcmVz
dCBpbiBoYXZpbmcgYSBjYWxsIHRvIGRpc2N1c3MgdGhlIGNoYXJ0ZXINCj4gLSBJJ2QgbGlrZSB0
byBzY2hlZHVsZSBhIGNhbGwgYXJvdW5kIE1heSAxMCAoMiB3ZWVrcyBmcm9tIHRvZGF5KS4NCj4g
DQo+IFJlZ2FyZHMsDQo+IFN0YW4NCj4gIA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gbWFuZXRAaWV0Zi5v
cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA==


From nobody Tue Apr 26 07:45: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 055ED12D1DD for ; Tue, 26 Apr 2016 07:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.915
X-Spam-Level: 
X-Spam-Status: No, score=-7.915 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] 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 MYugkZOBclWr for ; Tue, 26 Apr 2016 07:45:16 -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 687E612D1D4 for ; Tue, 26 Apr 2016 07:45:14 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,536,1454976000"; d="scan'208,217"; a="34270275"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 26 Apr 2016 15:45:12 +0100
X-IronPort-AV: E=Sophos;i="5.24,536,1454976000";  d="scan'208,217";a="115571387"
Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 26 Apr 2016 15:45:12 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.34]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Tue, 26 Apr 2016 15:45:12 +0100
From: "Dearlove, Christopher (UK)" 
To: Stan Ratliff , MANET IETF 
Thread-Topic: [manet] Interim call
Thread-Index: AQHRn8ATkRwmwTCLE02PTjuIoXiMZp+cQYzwgAATQHA=
Date: Tue, 26 Apr 2016 14:45:12 +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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1A4BGLKXM0002VGREEN_"
MIME-Version: 1.0
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: Tue, 26 Apr 2016 14:45:18 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1A4BGLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U29ycnksIHRoYXQgd2FzIGFtYmlndW91cy4gSSBtZWFudCBvdGhlciBmaXNoIHRvIGZyeSBvdXRz
aWRlIE1BTkVUIHRoYXQgbWlnaHQgcHJldmVudCBtZSBqb2luaW5nLg0KDQotLQ0KQ2hyaXN0b3Bo
ZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxp
ZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0
NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFp
bHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVk
IEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywg
Q2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8v
d3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2Ug
TGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdp
c3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBH
VTIgN1lQDQoNCkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24g
QmVoYWxmIE9mIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpTZW50OiAyNiBBcHJpbCAyMDE2
IDE0OjM3DQpUbzogU3RhbiBSYXRsaWZmOyBNQU5FVCBJRVRGDQpTdWJqZWN0OiBSZTogW21hbmV0
XSBJbnRlcmltIGNhbGwNCg0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5h
dGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5h
bCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlv
dSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBs
eS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29r
IG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5l
dC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1l
bnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91
cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0
ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUy
MFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4uDQoqKiogV0FSTklORyAqKioNCkVYVEVS
TkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3Jn
YW5pemF0aW9uLg0KDQpJ4oCZdmUgbWFkZSBzb21lIGNvbW1lbnRzIG9uLWxpc3QuDQoNCklmIHRo
ZXJl4oCZcyBhIHRlbGVjb24gYW5kIGl04oCZcyBhdCBhIGNvbnZlbmllbnQgdGltZSAod2l0aCBy
ZWdhcmQgdG8gYm90aCB0aW1lem9uZSBhbmQgd2hhdCBlbHNlIGlzIGhhcHBlbmluZykgIEkgbWln
aHQgam9pbiBpbiwgb3IgbWlnaHQgbm90LiBJIGRvIGhhdmUgc29tZSBmaXNoIHRvIGZyeS4NCg0K
LS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUg
U3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5
c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5
c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBH
cmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5j
b20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQg
SW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAw
MTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZv
cmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGFuIFJhdGxpZmYNClNlbnQ6IDI2IEFwcmlsIDIwMTYg
MTQ6MzINClRvOiBNQU5FVCBJRVRGDQpTdWJqZWN0OiBbbWFuZXRdIEludGVyaW0gY2FsbA0KDQoN
CioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91
ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGlu
dGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBh
bnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9u
IHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMg
eW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNv
bS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRm
Pi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRo
aXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9z
ZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMl
MjBFbWFpbHMucGRmPi4NCioqKiBXQVJOSU5HICoqKg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBt
ZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb24uDQoNCldHLA0K
DQpJIGFza2VkIGEgZmV3IGRheXMgYWdvIGFib3V0IGFuIGludGVyaW0gdGVsZWNvbiB0byBkaXNj
dXNzIHJlY2hhcnRlci4gSnVzdGluIGFsc28gc2VudCB0aGUgbGFzdCBjb3B5IG9mIHRoZSBuZXcg
Y2hhcnRlciB3ZSB3ZXJlIHdvcmtpbmcgb24gaW4gUHJhZ3VlLiBTbyBmYXIsIHRoZSBzaWxlbmNl
IGhhcyBiZWVuIGRlYWZlbmluZy4uLg0KDQpEb2VzIHRoZSBsYWNrIG9mIGRpc2N1c3Npb24gaGVy
ZSBvbi1saXN0IGluZGljYXRlIHRoYXQgdGhlIG1lbWJlcnMgb2YgdGhlIFdHIGhhdmUgbm8gaW50
ZXJlc3QgaW4gYSByZS1jaGFydGVyIGVmZm9ydD8gT3IgaXMgdGhpcyAoaG9wZWZ1bGx5KSBhIGNh
c2Ugb2YgaGF2aW5nICJiaWdnZXIgZmlzaCB0byBmcnkiPw0KDQpQbGVhc2UgaW5kaWNhdGUgeW91
ciBpbnRlcmVzdCBpbiBoYXZpbmcgYSBjYWxsIHRvIGRpc2N1c3MgdGhlIGNoYXJ0ZXIgLSBJJ2Qg
bGlrZSB0byBzY2hlZHVsZSBhIGNhbGwgYXJvdW5kIE1heSAxMCAoMiB3ZWVrcyBmcm9tIHRvZGF5
KS4NCg0KUmVnYXJkcywNClN0YW4NCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KVGhpcyBlbWFpbCBhbmQgYW55
IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkDQpyZWNpcGllbnQg
YW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0K
cmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRo
ZSBzZW5kZXIuDQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBv
c2Ugbm9yIGRpc2Nsb3NlIG9yDQpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIg
cGVyc29uLg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioNCg==

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1A4BGLKXM0002VGREEN_
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
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl
dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv
bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJh
bGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp
bms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N
CnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv
Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu
MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn
aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn
ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl
bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl
ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0
PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJs
dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5T
b3JyeSwgdGhhdCB3YXMgYW1iaWd1b3VzLiBJIG1lYW50IG90aGVyIGZpc2ggdG8gZnJ5IG91dHNp
ZGUgTUFORVQgdGhhdCBtaWdodCBwcmV2ZW50IG1lIGpvaW5pbmcuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVh
cmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBw
bGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K
PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0K
PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFu
PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDsmIzQz
OzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wgJm5ic3A7PGI+RToNCjwvYj48YSBocmVmPSJtYWls
dG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl
bXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAw
MDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4Qjky
Ij5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5
IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBo
cmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHlsZT0iY29sb3I6IzNB
OEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJl
Z2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w
cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVkIE9m
ZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg
I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8
L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1hbmV0
IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGVh
cmxvdmUsIENocmlzdG9waGVyIChVSyk8YnI+DQo8Yj5TZW50OjwvYj4gMjYgQXByaWwgMjAxNiAx
NDozNzxicj4NCjxiPlRvOjwvYj4gU3RhbiBSYXRsaWZmOyBNQU5FVCBJRVRGPGJyPg0KPGI+U3Vi
amVjdDo8L2I+IFJlOiBbbWFuZXRdIEludGVyaW0gY2FsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIu
MHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0
eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi
bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5k
OndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioqKiBX
QVJOSU5HICoqKjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w
cHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8ZW0+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9t
IG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5l
ciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVmdWxseSB3
aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50
cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBpbmZvcm1hdGlv
biByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9zdHJvbmc+
PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+IHRoYXQgeW91IGNh
biBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLA0KIGNsaWNrIDxhIGhyZWY9Imh0
dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3Rs
aWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiI+DQpoZXJlPC9hPi48L3NwYW4+PC9lbT48
aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cN
CjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3Nl
Y3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUy
MEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3NwYW4+PC9lbT48L3NwYW4+PC9pPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0
IDEuMHB0O3BhZGRpbmc6MS4wcHQgNC4wcHQgMS4wcHQgNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
KjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPioqDQo8L3NwYW4+PC9zdHJvbmc+PC9zcGFuPjxzdHJvbmc+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V0FSTklORw0KPC9zcGFuPjwvc3Ryb25nPjxzdHJvbmc+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPioqKjwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxi
cj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5FWFRFUk5BTCBFTUFJTCAtLSBU
aGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbjwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkni
gJl2ZSBtYWRlIHNvbWUgY29tbWVudHMgb24tbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHRoZXJl4oCZcyBh
IHRlbGVjb24gYW5kIGl04oCZcyBhdCBhIGNvbnZlbmllbnQgdGltZSAod2l0aCByZWdhcmQgdG8g
Ym90aCB0aW1lem9uZSBhbmQgd2hhdCBlbHNlIGlzIGhhcHBlbmluZykgJm5ic3A7SSBtaWdodCBq
b2luIGluLCBvciBtaWdodCBub3QuIEkgZG8gaGF2ZSBzb21lDQogZmlzaCB0byBmcnkuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPG86cD48L286cD48L3NwYW4+
PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhl
ciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVt
cyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48
YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNw
OyYjNDM7NDQgKDApMTI0NSAyNDIxOTQgJm5ic3A7fCAmbmJzcDs8Yj5FOg0KPC9iPjxhIGhyZWY9
Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFl
c3lzdGVtcy5jb208L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz
QThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hu
b2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4N
CjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiPjxzcGFuIHN0eWxlPSJjb2xv
cjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJy
Pg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t
OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVy
ZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3
WVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij4gbWFuZXQgWzxhIGhyZWY9Im1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYu
b3JnIj5tYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg
PC9iPlN0YW4gUmF0bGlmZjxicj4NCjxiPlNlbnQ6PC9iPiAyNiBBcHJpbCAyMDE2IDE0OjMyPGJy
Pg0KPGI+VG86PC9iPiBNQU5FVCBJRVRGPGJyPg0KPGI+U3ViamVjdDo8L2I+IFttYW5ldF0gSW50
ZXJpbSBjYWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7
cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh
bGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpj
ZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1h
cmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0K
PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdl
IG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFu
IGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25z
aWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3Bl
biBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ry
b25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3Nw
YW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5
NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBj
bGljayA8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29y
ay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwv
YT4uPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcy
Ij48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3Vz
LCBwbGVhc2UgZm9sbG93DQo8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMu
Y29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0
aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwv
ZW0+PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+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
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldHLCZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhc2tlZCBhIGZl
dyBkYXlzIGFnbyBhYm91dCBhbiBpbnRlcmltIHRlbGVjb24gdG8gZGlzY3VzcyByZWNoYXJ0ZXIu
IEp1c3RpbiBhbHNvIHNlbnQgdGhlIGxhc3QgY29weSBvZiB0aGUgbmV3IGNoYXJ0ZXIgd2Ugd2Vy
ZSB3b3JraW5nIG9uIGluIFByYWd1ZS4gU28gZmFyLCB0aGUgc2lsZW5jZSBoYXMgYmVlbiBkZWFm
ZW5pbmcuLi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+RG9lcyB0aGUgbGFjayBvZiBkaXNjdXNzaW9uIGhlcmUgb24tbGlzdCBpbmRp
Y2F0ZSB0aGF0IHRoZSBtZW1iZXJzIG9mIHRoZSBXRyBoYXZlIG5vIGludGVyZXN0IGluIGEgcmUt
Y2hhcnRlciBlZmZvcnQ/IE9yIGlzIHRoaXMgKGhvcGVmdWxseSkgYSBjYXNlIG9mIGhhdmluZyAm
cXVvdDtiaWdnZXIgZmlzaCB0byBmcnkmcXVvdDs/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBpbmRpY2F0ZSB5b3VyIGlu
dGVyZXN0IGluIGhhdmluZyBhIGNhbGwgdG8gZGlzY3VzcyB0aGUgY2hhcnRlciAtIEknZCBsaWtl
IHRvIHNjaGVkdWxlIGEgY2FsbCBhcm91bmQgTWF5IDEwICgyIHdlZWtzIGZyb20gdG9kYXkpLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdh
cmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
U3RhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+KioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+
DQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUg
aW50ZW5kZWQ8YnI+DQpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlv
dSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4NCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZy
b20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj4NCllvdSBzaG91bGQgbm90
IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+DQpk
aXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4NCioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1A4BGLKXM0002VGREEN_--


From nobody Tue Apr 26 10:07: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 E8B8212D52E for ; Tue, 26 Apr 2016 10:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.715
X-Spam-Level: 
X-Spam-Status: No, score=-3.715 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, 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 xVn9AVrkXCKI for ; Tue, 26 Apr 2016 10:07:44 -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 6A2DB12D51D for ; Tue, 26 Apr 2016 10:07:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=SXiaG4z6vdRS/o6JBQot/QmGAwURNmueUBUzui4yUBuq9n3o87gWwR0SvL3rCCqd; 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-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1av6ST-0005sB-BR; Tue, 26 Apr 2016 13:07:33 -0400
To: Stan Ratliff , MANET IETF 
References: 
From: Charlie Perkins 
Message-ID: <2437f179-2907-c924-dbf0-8c2a3a4cb2c9@earthlink.net>
Date: Tue, 26 Apr 2016 10:07:27 -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="------------83FBE6BA967FA70C454773BA"
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac75dcb89e951e79b9b9af210a9702c8042350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
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: Tue, 26 Apr 2016 17:07:47 -0000

This is a multi-part message in MIME format.
--------------83FBE6BA967FA70C454773BA
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hello Stan,

I would be happy to attend a teleconference about rechartering.

Regards,
Charlie P.

On 4/26/2016 6:31 AM, Stan Ratliff wrote:
> 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


--------------83FBE6BA967FA70C454773BA
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello Stan,

    
I would be happy to attend a teleconference about rechartering.

    
Regards,

      Charlie P.

    

    
On 4/26/2016 6:31 AM, Stan Ratliff
      wrote:

    

    

      
      
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


    

    

  


--------------83FBE6BA967FA70C454773BA--


From nobody Tue Apr 26 11:48: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 2F09112D567 for ; Tue, 26 Apr 2016 11:48:39 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, 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 qEv0og3oAkoG for ; Tue, 26 Apr 2016 11:48:37 -0700 (PDT)
Received: from mail3.nrl.navy.mil (mail3.nrl.navy.mil [IPv6:2001:480:20:404::465:27]) (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 BF0D312D55F for ; Tue, 26 Apr 2016 11:48:35 -0700 (PDT)
Received: from fips236142.nrl.navy.mil (fips236142.nrl.navy.mil [132.250.236.142]) (authenticated bits=0) by mail3.nrl.navy.mil (8.15.2/8.15.2) with ESMTPSA id u3QImX0t017380 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Apr 2016 14:48:33 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_F0620B64-38F8-46FB-A8A1-A4A9E62CEC18"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Brian Adamson 
In-Reply-To: <2437f179-2907-c924-dbf0-8c2a3a4cb2c9@earthlink.net>
Date: Tue, 26 Apr 2016 14:48:33 -0400
Message-Id: <6F87B6E6-7ED6-4C65-AFF4-C681CCB45D89@nrl.navy.mil>
References:  <2437f179-2907-c924-dbf0-8c2a3a4cb2c9@earthlink.net>
To: MANET IETF 
X-Mailer: Apple Mail (2.3124)
X-Scanned-By: MIMEDefang 2.78
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: Tue, 26 Apr 2016 18:48:39 -0000

--Apple-Mail=_F0620B64-38F8-46FB-A8A1-A4A9E62CEC18
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I would be interested in participating.

- Brian


> On Apr 26, 2016, at 1:07 PM, Charlie Perkins =
 wrote:
>=20
> Hello Stan,
>=20
> I would be happy to attend a teleconference about rechartering.
>=20
> Regards,
> Charlie P.
> On 4/26/2016 6:31 AM, Stan Ratliff wrote:
>> 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
>>=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=_F0620B64-38F8-46FB-A8A1-A4A9E62CEC18
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=windows-1252

I would be interested in participating.

- Brian


On Apr 26, 2016, at 1:07 PM, Charlie Perkins <charles.perkins@earthlink.net> wrote:


  
    
  
  
Hello Stan,
I would be happy to attend a teleconference about rechartering.
Regards,

      Charlie P.

    

    
On 4/26/2016 6:31 AM, Stan Ratliff
      wrote:

    

    

      
      
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


    

    

  


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


--Apple-Mail=_F0620B64-38F8-46FB-A8A1-A4A9E62CEC18--


From nobody Tue Apr 26 11:55: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 C7BD012D567 for ; Tue, 26 Apr 2016 11:55:29 -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 7n9aTdSb1zFf for ; Tue, 26 Apr 2016 11:55:27 -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 A4C0D12D553 for ; Tue, 26 Apr 2016 11:55:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 64896259F28; Tue, 26 Apr 2016 11:55:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461696927; bh=3WjGgb7LsVoZVXhRy//DaQis+wioCc7ZclkRCEtyH/A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=HIEXwGgiVUAIe2AmAyq5eqGjVUfs2c7Q+vtETYrdJ3bdyMuKvfF8PkB6XELOSVXGm HoAH3Yq2hnmR8cTZ1T846k4Hl0gOJzqy10A0oXtYX0uWW8VIfyLC+OIivOKRpFqNpp ieEBqGzYKfAtS8ZaWoPu7fOv3X0YP3Jhwktgy7wY=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.147.204] (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 8500C258B1E; Tue, 26 Apr 2016 11:55:26 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-861C9C74-55F3-406E-A25B-9F1F5E66707D
Mime-Version: 1.0 (1.0)
From: Thomas Clausen 
X-Mailer: iPad Mail (13E238)
In-Reply-To: 
Date: Tue, 26 Apr 2016 20:55:24 +0200
Content-Transfer-Encoding: 7bit
Message-Id: 
References:   
To: Stan Ratliff 
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: Tue, 26 Apr 2016 18:55:30 -0000

--Apple-Mail-861C9C74-55F3-406E-A25B-9F1F5E66707D
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi,

I believe that an virtual interim is premature: a teleconference is, mechani=
cally, less inclusive than are mailing list discussions (time-zones, other c=
ommitments, requirement of synchronicity of participation, etc.).

Furthermore....

Until such time that a strawman charter is proposed, updated to reflect the r=
eality of the group as stipulated by the AD and by Mr. Dean, as well as addi=
tional charter items emerging on the list,  and with relatively broad and de=
ep support for the included items by the working group, having an interim - v=
irtual or otherwise - is not constructive.

In other words, it should be established on the list that there are meaningf=
ul things to do, and there's a meaningful critical mass of people to be doin=
g those things, before a (virtual) interim is called. Brainstorming on a tel=
econference is rarely a constructive way to spend time.

Best,

Thomas

Sent from my iPad

> On 22 Apr 2016, at 17:50, Stan Ratliff  wrote:
>=20
> Hello WG,=20
>=20
> Do we need to hold an interim meeting (via WebEX) to discuss? I'd like to g=
et opinions on the list about that. We'll need a couple of weeks to schedule=
, but we can do that.=20
>=20
> One other point inline:=20
>=20
>> On Fri, Apr 22, 2016 at 11:45 AM, Dearlove, Christopher (UK)  wrote:
>> 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 is=
 going to be Experimental at most.
>>=20
>> =20
>>=20
>> 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.
>>=20
>> =20
>>=20
>> I would have to make an IPR declaration to say some of what I might have t=
o say about encryption. Not today.
>>=20
>=20
> Understood. But please remember - there's only about a 5-week gap now befo=
re the charter needs to be complete in order for the WG to meet in Berlin.=20=

>=20
> Regards,
> Stan
>=20
>=20
> =20
>> =20
>>=20
>> Missing from the list is any work on OLSRv2 (or NHDP). MT-OLSRv2 is exper=
imental. That would need implementation tests to advance to PS. Anyone inter=
ested 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 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: 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 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
>> I'll start things off by floating the draft re-charter which was presente=
d in Prague. =20
>>=20
>>=20
>>=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 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 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
>> 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
>> 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 to=
 cut some and focus the work.  For me personally I know I have the time and b=
acking 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
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

--Apple-Mail-861C9C74-55F3-406E-A25B-9F1F5E66707D
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi,
=


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

Furthermore....

U=
ntil 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, a=
s well as additional charter items emerging on the list,  and wit=
h relatively broad and deep support for the included items by the wo=
rking group, having an interim - virtual or otherwise - is not constructive.=


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) i=
nterim is called. Brainstorming on a teleconference is rarely a constructive=
 way to spend time.

Best,

Thomas

Sent from my iPad

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

Hello WG, 

Do we need to hold=
 an interim meeting (via WebEX) to discuss? I'd like to get opinions on the l=
ist 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:4=
5 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com<=
/a>> 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 m=
ost.


 =



Management we did of course=
 have an NHDP/OLSRv2 draft killed by AD. Which since NHDP/OLSRv2 us all we h=
ave (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 t=
oday.

Understood. But=
 please remember - there's only about a 5-week gap now before the charter ne=
eds to be complete in order for the WG to meet in Berlin. 
Regards,
Stan


 
<=
/u>


 =



Missing from the list is an=
y work on OLSRv2 (or NHDP). MT-OLSRv2 is experimental. That would need imple=
mentation tests to advance to PS. Anyone interested in
 that (I=E2=80=99m 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 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 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-bounces@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 organis=
ation, either from an external partner or the internet.

Con=
sider carefully whether you should click on any links, open any attachments o=
r reply.

For=
 information 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 by floating the draft re-charte=
r 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)<=
/span>


 


 


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.

********************************************************************



_______________________________________________

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-861C9C74-55F3-406E-A25B-9F1F5E66707D--


From nobody Tue Apr 26 13:14: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 8753A12D57A for ; Tue, 26 Apr 2016 13:14:05 -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 i9z7_yTokzZl for ; Tue, 26 Apr 2016 13:14:04 -0700 (PDT)
Received: from ndmsvnpf101.ndc.nasa.gov (NDMSVNPF101.ndc.nasa.gov [198.117.0.151]) by ietfa.amsl.com (Postfix) with ESMTP id 64BA312D0B4 for ; Tue, 26 Apr 2016 13:14:04 -0700 (PDT)
Received: from ndjsppt102.ndc.nasa.gov (ndjsppt102.ndc.nasa.gov [198.117.1.196]) by ndmsvnpf101.ndc.nasa.gov (Postfix) with ESMTP id BC51940059D7 for ; Tue, 26 Apr 2016 15:14:03 -0500 (CDT)
Received: from NDJSCHT105.ndc.nasa.gov (ndjscht105-pub.ndc.nasa.gov [198.117.1.205]) by ndjsppt102.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id u3QKE32G022585 for ; Tue, 26 Apr 2016 15:14:03 -0500
Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.156]) by NDJSCHT105.ndc.nasa.gov ([198.117.1.205]) with mapi id 14.03.0266.001; Tue, 26 Apr 2016 15:14:03 -0500
From: "Ivancic, William D. (GRC-LCA0)" 
To: "manet@ietf.org" 
Thread-Topic: Review of:  draft-ietf-manet-aodvv2-14 
Thread-Index: AQHRn/gtriohW61wV0KrUd9ncQlHXg==
Date: Tue, 26 Apr 2016 20:14:02 +0000
Message-ID: 
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: 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-04-26_10:, , signatures=0
Archived-At: 
Subject: [manet] Review of:  draft-ietf-manet-aodvv2-14
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, 26 Apr 2016 20:14:05 -0000

I reviewed  draft-ietf-manet-aodvv2-14 over the past few days and do not
have any major issues with it.  I think, as written, there are no
ambiguities I could find and it appear complete.  I fully believe multiple
independent implementations could be written and expect to interoperate.

I sent Charlie a list of minor typos and fixes.  The following might
require some discussion:

13.4.2 . Integrity and Trust using ICVs
=8A.
The data contained in AODVv2 routing protocol messages MUST be
verified using Integrity Check Values, to avoid the use of message
data if the message has been tampered with.

Followed by=20


13.4.4 . Application to AODVv2
Implementations of AODVv2 MUST support ICV TLVs using type-extensions
1 and 2, hash-function HASH_FUNCTION, and cryptographic function
CRYPTOGRAPHIC_FUNCTION. An ICV MUST be included with every message.
The ICV value MAY be truncated as specified in [RFC7182 ].


Question:
Should the MUSTs be a SHOULDs?  Are there low-processor implementations or
specifice deployments that do not require such support?



13.4.4 . Application to AODVv2  Paragraph 3


"...In this case, the RFC5444  multiplexer MUST be
instructed to include the Packet TLVs in packets containing AODVv2
messages, or MUST be selected because it always performs these
additions. If the multiplexer is not capable of adding the Packet
TLVs, the TLVs MUST be included as Message TLVs in each AODVv2
message in the packet."


Comment:
Wording is unclear to me.  Should the "or" be an "and"?  The last sentance
 in the paragraph contradics the previous two.

Perhaps: " If the multiplexer is  capable of adding the Packet TLVs,  the
RFC5444  multiplexer SHOULD be instructed to include the Packet TLVs in
packets containing AODVv2 messages. However, If the multiplexer is not
capable of adding the Packet TLVs, the TLVs MUST be included as Message
TLVs in each AODVv2 message in the packet."



Will Ivancic


From nobody Tue Apr 26 13:22: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 8A33612D58A for ; Tue, 26 Apr 2016 13:22:00 -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 4yzFqikHI3Bv for ; Tue, 26 Apr 2016 13:21:57 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 ECC3012D585 for ; Tue, 26 Apr 2016 13:21:52 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id j74so31974871ywg.1 for ; Tue, 26 Apr 2016 13:21: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=+fb4wgCisFu8FzKvSZRX8ggvHWow9OjY8pwMdv5HqzU=; b=pcYz6/vxQrmZ2Z0Aqo9yv1WGb2wilM+7K8HRmw5uwjAg9q1swqR3dIh/hVbK+0csIn 5T2fkjTF3Y2AGRSkUS6HOyASMiobDZRWxlSEt/gQJ7Vfa/XfuTXX0A+gjQJFnxA+kxWa MNagXfrUwknr3ZE/8bz0f8DjGwZiKmcT/Zgwj4W+VdgdV+nZpwJwyi6XiohdaHVaS2Em XOfyCgKbU9/+iGqnr7pnpF1teeXLPQijfyeI8UB0AXwoRWxyrVBVXPyB5jkgmGd4o+wu ouCYcQJIN2ZuhiqEJ4RqKMQJwt8VzcxpEzA1RMyp3/5nPUoxbbUrTX5jkNPz9okGDEel xPaw==
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=+fb4wgCisFu8FzKvSZRX8ggvHWow9OjY8pwMdv5HqzU=; b=T2cZRpfZPBZR7xF9hFARlSQn4k15x2ToEVvx03zKQqeq4kpVk42l9kRRr1F/9zL9Tt WZ9Un1EE/fY3VnNkQvmytJoUe40ZxzNpuRbu4J0xXfJlixLDrhyLGrw9emN6bDCAknso k623DBN5yH9GLxMT28AYno61VLrfzr+89bkeG+um8cn15DcvD8WzvaLHFOEyJZ+Qv54a /Cv9XlTMDaLwdSt0mvSO7Qhw7fJhrx12zy2EJEM4bxJDkyswW5CtgNzhwpWlg0qpAztM pfV3tecp51hxzBa1EFYpQStvmhZIMW7/JNeCO0in6qL7i0LZj+hIWLLKek8Gfj3AIEV6 ePvQ==
X-Gm-Message-State: AOPr4FXiCCY2EYDMOlWZSbZPuuzAt2vGig3NkFqlHoH4xr03Okx61AJN2/nLTDGX9ola4JnmBrmzeiJiRnKvmA==
MIME-Version: 1.0
X-Received: by 10.159.37.245 with SMTP id 108mr2347093uaf.140.1461702112117; Tue, 26 Apr 2016 13:21:52 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Tue, 26 Apr 2016 13:21:52 -0700 (PDT)
In-Reply-To: 
References:    
Date: Tue, 26 Apr 2016 16:21:52 -0400
Message-ID: 
From: Justin Dean 
To: Thomas Clausen 
Content-Type: multipart/alternative; boundary=001a113ad63c290ca30531690b0d
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: Tue, 26 Apr 2016 20:22:00 -0000

--001a113ad63c290ca30531690b0d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thomas I understand your concerns but we have mostly gone over this before
in previous meetings.  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.  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 previously floated
charter, with comments in () with JWD tags.

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 (JWD
TBD), DLEP and NHPD. Of particular interest: security 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 group to
grab the attention of those 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 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:

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 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
>
>

--001a113ad63c290ca30531690b0d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thomas I understand your concerns but we have mostly gone =
over this before in previous meetings.=C2=A0 The AD will not allow us to me=
et at the next IETF meeting if we do not have a new charter and new work it=
ems.=C2=A0 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 charter, with comments in () with JWD tags.
<=
br>
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. =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 (JWD TBD)=
, DLEP and NHPD. Of particular interest: security enhancements, and encrypt=
ion 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.)

The MANET WG will standardize a multicast MANET protocol framework based on=
 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 mu=
lticast forwarding 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:

MANET Management Document (Informational)
MANET Maintenance=20
 - RFC5444 Security extension (Standards) (JWD possibly move this to new wo=
rking group)
MANET Multicast
 - Multicast FIB (Standards)






--001a113ad63c290ca30531690b0d--


From nobody Tue Apr 26 13:38: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 0AE4512D588 for ; Tue, 26 Apr 2016 13:38:35 -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 L4cxzLzqx2Z7 for ; Tue, 26 Apr 2016 13:38:34 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 D16FC12B04B for ; Tue, 26 Apr 2016 13:38:33 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id o66so36931167ywc.3 for ; Tue, 26 Apr 2016 13:38:33 -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=B1DHgiBkizTBZ5t/8VorDxEmcM95+35ejARrXi3AwKI=; b=kuKTAWt8QIXcUuGJshdiyvfkeH3JTlzrWwzLs0/ybuZxG45sdQUC8v3TIOwIrZcbxt YuzlQ6GsJGMvsqgqN49aqdoyy3DgX93qfiwsQAbQ8w+kzpNUsT7RUFiZ1+LKXV6BycCV UBVQmK39pEGAfLM8EVIP8lfXYTclHUHgQY9evdNrKzdV0c6zmg2o+XtVr80m5pfH7Or/ guGUw7X6mbnf/k9NiXhiST6SxCONk6lW/uRsaTA1lnegk6HA4rklM5zZBiw41yVGx2yk eT9G21T8fW/3dmK3TNMosKLZmYKq81Ym4GS/0qFXfMzULBDRDFa2ZOOhwmrq002RhWKz aUPw==
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=B1DHgiBkizTBZ5t/8VorDxEmcM95+35ejARrXi3AwKI=; b=Djo4rf+7ReaTsotc5VfinIBpRCFAbcwS4mB0ZZ/a/SZEjPhCzoW85qPxSoQIoTcbjY 5Tdo8OWemU+ZPa7ZkpIRfDdIbSzSTlVfPS9eyRrZ1DHoRBZUQ6q270p5BxchKLWTqGhN zgZyzrNcpPy0rI/BYvZEr/HMWU/TBEIt4ecpPw7g6PcDPhl40wBFHEWKxRXa1n63VMWA iuwWjxQuos0T0kPivrrNh9SmpmSivbiKBUBsOSmWwlgyFeb/mM3jIi4tYz0ooe4NIURY 2kJd+8d5V9RyTbp66F8XQie7t0k3brgAWxn/NwN1Gbx3hPZO8wD/Pc1wBc7mLSNMQMoo SbVQ==
X-Gm-Message-State: AOPr4FXxunfptoKx5XlhKaT2Y76dmFYUwLWY224hCFKO5ttnKFgDzWwUldurL9D+2Unvm+Q9jXSri7zY4Q0LtA==
MIME-Version: 1.0
X-Received: by 10.176.1.108 with SMTP id 99mr2229536uak.54.1461703113142; Tue, 26 Apr 2016 13:38:33 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Tue, 26 Apr 2016 13:38:33 -0700 (PDT)
Date: Tue, 26 Apr 2016 16:38:33 -0400
Message-ID: 
From: Justin Dean 
To: "manet@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113d0cd4d37be5053169465b
Archived-At: 
Subject: [manet] Webex MANET meeting (tentative date May 10th 2pm EST)
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, 26 Apr 2016 20:38:35 -0000

--001a113d0cd4d37be5053169465b
Content-Type: text/plain; charset=UTF-8

I've requested webex interim meeting for the 10th of May at 2pm EST.  The
goal is to achieve consensus on the draft re-charter.

Justin

--001a113d0cd4d37be5053169465b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I've requested webex interim meeting for the 10th of M=
ay at 2pm EST.=C2=A0 The goal is to achieve consensus on the draft re-chart=
er. =C2=A0

Justin


--001a113d0cd4d37be5053169465b--


From nobody Tue Apr 26 14:00:59 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 EFA6012D59E for ; Tue, 26 Apr 2016 14:00:57 -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 gMT2xx8dPMxF for ; Tue, 26 Apr 2016 14:00:55 -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 2E87912D58E for ; Tue, 26 Apr 2016 14:00:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id CB4A626650D; Tue, 26 Apr 2016 14:00:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461704454; bh=ay6szvScyhULwFogfcBRgRx5VfbC3kAcLhy6a0LVYn4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=gHoeQTsF6d6aDL4SJyqMw159u4cTB7qnCbI6HGJBp559djb+ATSuoKHvfDXMPAb9n i5vzfYNZx3/y3L7TOXVDk806I9Ae3myzyZyRZPiN+Mc1BBqvCfHmHRUYQWrEMY3s3G 70531iSUu4ClZHsurRUWlsW5F5lCLGjP+FZE7Ta0=
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 CCB3C266508; Tue, 26 Apr 2016 14:00:53 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-2F96A126-0A0F-47C7-8847-7E9A053AA98E
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPhone Mail (13E238)
In-Reply-To: 
Date: Tue, 26 Apr 2016 23:00:51 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <82679804-2647-4913-ACF3-18E4FFF731A8@thomasclausen.org>
References:     
To: Justin Dean 
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: Tue, 26 Apr 2016 21:00:58 -0000

--Apple-Mail-2F96A126-0A0F-47C7-8847-7E9A053AA98E
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable




> On 26 avr. 2016, at 22:21, Justin Dean  wrote:
>=20
> 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 meet=
ing, then the chairs did not animate any charter discussion for several 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 hav=
e a new charter and new work items.=20

That does not negate my point, however, which was that:

>> it should be established on the list that there are meaningful things to d=
o, 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 t=
he charter.  With that in mind here is a suggested edit of the previously fl=
oated charter, with comments in () with JWD tags.
>=20
> The purpose of the MANET working group is to standardize IP routing protoc=
ol functionality suitable for wireless routing application within both stati=
c and dynamic topologies with increased dynamics due to node motion or other=
 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 OLSRv2, AODVv2 (JWD TBD=
), DLEP and NHPD. Of particular interest: security enhancements, and encrypt=
ion security extensions for RFC5444. (JWD we may want to break this out of t=
he WG and make a new MANET Sec working group to grab the attention of those i=
nterested in security and get their participation.)
>=20
> 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
> MANET Management Document (Informational)
> MANET Maintenance=20
>  - RFC5444 Security extension (Standards) (JWD possibly move this to new w=
orking group)
> MANET Multicast
>  - Multicast FIB (Standards)
>=20
>=20
>=20
>> On Tue, Apr 26, 2016 at 2:55 PM, Thomas Clausen  w=
rote:
>> Hi,
>>=20
>> I believe that an virtual interim is premature: a teleconference is, mech=
anically, less inclusive than are mailing list discussions (time-zones, othe=
r commitments, requirement of synchronicity of participation, etc.).
>>=20
>> Furthermore....
>>=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
>> In other words, it should be established on the list that there are meani=
ngful 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
>> Best,
>>=20
>> Thomas
>>=20
>> Sent from my iPad
>>=20
>> On 22 Apr 2016, at 17:50, Stan Ratliff  wrote:
>>=20
>>> Hello WG,=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
>>> One other point inline:=20
>>>=20
>>>> On Fri, Apr 22, 2016 at 11:45 AM, Dearlove, Christopher (UK)  wrote:
>>>> Multicast is the obvious top item. Lots of possible approaches, time to=
 discuss.
>>>>=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. Whi=
ch 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 hav=
e to say about encryption. Not today.
>>>>=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
>>> Regards,
>>> Stan
>>>=20
>>>=20
>>> =20
>>>> =20
>>>>=20
>>>> Missing from the list is any work on OLSRv2 (or NHDP). MT-OLSRv2 is exp=
erimental. That would need implementation tests to advance to PS. Anyone int=
erested 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=
 what is really needed is people with a real application. Any that exist wer=
e frightened 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 Bad=
dow, 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 e=
xternal partner or the internet.
>>>> Consider carefully whether you should click on any links, open any atta=
chments 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
>>>> I'll start things off by floating the draft re-charter which was presen=
ted in Prague. =20
>>>>=20
>>>>=20
>>>>=20
>>>> The purpose of the MANET working group is to standardize IP routing pro=
tocol functionality suitable for wireless routing application within both st=
atic and dynamic topologies with increased dynamics due to node motion or ot=
her factors. =20
>>>> =20
>>>> Approaches are intended to be relatively lightweight in nature, suitabl=
e for multiple hardware and wireless environments, and address scenarios whe=
re 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 su=
pported by MANET specifications and management features.
>>>> =20
>>>> 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; se=
curity enhancements, encryption security extensions for RFC5444.=20
>>>> =20
>>>> The MANET WG will standardize a multicast MANET protocol framework base=
d 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 m=
ulticast forwarding information base.
>>>> =20
>>>> The WG will produce an informational draft outlining challenges and bes=
t practices for deploying and managing MANET networks.
>>>> =20
>>>> The MANET WG will interact with the PIM working group on issues relatin=
g 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.
>>>> =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
>>> _______________________________________________
>>> 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

--Apple-Mail-2F96A126-0A0F-47C7-8847-7E9A053AA98E
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



=

--Apple-Mail-2F96A126-0A0F-47C7-8847-7E9A053AA98E--


From nobody Tue Apr 26 14:47:46 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 36F8A12D0CF for ; Tue, 26 Apr 2016 14:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=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 dP70hi8zSZpD for ; Tue, 26 Apr 2016 14:47:43 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002: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 D520612D0F2 for ; Tue, 26 Apr 2016 14:47:42 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id t10so40817997ywa.0 for ; Tue, 26 Apr 2016 14:47:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b+01qImZSHawNDLybcoqTa8tOJGvLReWV/vMHReS5JE=; b=lqk+MLahXZ8EQCYmiN1vnNuX9JW3a67V3ZBgXft1suFDNPqEdoeXJLzKLita4rWp+0 PhcamOEHrEXev03zleXuyDLTRuxKRg3l90EpEobOp4lGSwhTYm3qrtR+/P2u1igFsyUG 7XP0b7Z0UJB2osW9WSO0XowOe3rt9yxKYr06sYz/SPhbYgkG4wmlvhP6gc5g5K2yK8J3 WQE9lJhlXKh6oibjiuhTWStuif9wtmplWXnar71h5yg3xsSzRQyxWoTJICvqx0S1c5N2 wpaeoaRPPMnmpo+YjU034BB6ZwOjoPQYG0Byom39GPJR4hwzGnpZjJwDqGd0cjtBnL0E sVkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b+01qImZSHawNDLybcoqTa8tOJGvLReWV/vMHReS5JE=; b=KlbYWNDNbXfqjoTI8zYX58DLSOuteAJSgJjmwtd0JTE0XJh29iaZapEFE2t5ku+fcM OYJmwuhS6KNdqYcbyikdv44JEHPaJap8A5vQVFUwLyrtHFj+NwQBawe0DPOaKLQYyrYt 5hqey2WCqlJRDlKSAtFqG2YvZme+GFSLnGwmbsZmWHEloODA6qfO2tBPv+GHV0zXwilf MGOszZEL2yEI34VEgLWXg9CiQjzBOZNa7PKZ+AbIeJ5m1Jkkr8cupiJo600B2bs2IEEU NcuKz2gAALfMxwV/asWHd6DoXXfnzxDv2TxwTuym9tR1Nou+EiN4j45YPnNCzK6gh1Ba nmNw==
X-Gm-Message-State: AOPr4FVQD8tC6pbHGZy2qqaHn7HOJ8jr9Nnie+nYEonJTdt0hOrGNXLb3vi89D8AqcUiU01+ivKDv0bpW7Ugqg==
X-Received: by 10.176.7.10 with SMTP id h10mr2451235uah.40.1461707262103; Tue, 26 Apr 2016 14:47:42 -0700 (PDT)
MIME-Version: 1.0
References:  <5B611FD0-BE75-407E-AABB-94B718E4C37D@mnemosyne.demon.co.uk>
In-Reply-To: <5B611FD0-BE75-407E-AABB-94B718E4C37D@mnemosyne.demon.co.uk>
From: Justin Dean 
Date: Tue, 26 Apr 2016 21:47:32 +0000
Message-ID: 
To: Christopher Dearlove 
Content-Type: multipart/alternative; boundary=94eb2c123f7c1f972b05316a3eeb
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] Webex MANET meeting (tentative date May 10th 2pm EST)
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, 26 Apr 2016 21:47:44 -0000

--94eb2c123f7c1f972b05316a3eeb
Content-Type: text/plain; charset=UTF-8

Thank you for that. You're the second one who has mentioned that the time
was bad. I'll look into moving it back a day or two and earlier in the day
timewise.

Justin

On Tue, Apr 26, 2016, 5:37 PM Christopher Dearlove <
chris@mnemosyne.demon.co.uk> wrote:

> That's not a time I can make. That's an evening, and as it happens a day
> of the week I can't do evenings. Of course I may or may not be able to make
> it at any time, but that's a not.
>
> Is there anywhere outside the Americas that's a good time for? It's
> evening in Europe, and even worse across Asia. I don't think even the parts
> of Asia where that's early in the morning it's good, but I haven't checked.
>
> Normal time to arrange a telecon round the world is night over the
> Pacific, which isn't good for Hawaii, but has a chance to catch the
> majority of the world.
>
> --
> Christopher Dearlove
> christopher.dearlove@gmail.com
>
> > On 26 Apr 2016, at 21:38, Justin Dean  wrote:
> >
> > I've requested webex interim meeting for the 10th of May at 2pm EST.
> The goal is to achieve consensus on the draft re-charter.
> >
> > Justin
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www.ietf.org/mailman/listinfo/manet
>
>

--94eb2c123f7c1f972b05316a3eeb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thank you for that. You're the second one who has mentio=
ned that the time was bad. I'll look into moving it back a day or two a=
nd earlier in the day timewise.


Justin


On Tue, Apr 26, 2016, 5:37 =
PM Christopher Dearlove <=
chris@mnemosyne.demon.co.uk> wrote:
That's not a time I can make. That's an evening, and as it =
happens a day of the week I can't do evenings. Of course I may or may n=
ot be able to make it at any time, but that's a not.



Is there anywhere outside the Americas that's a good time for? It's=
 evening in Europe, and even worse across Asia. I don't think even the =
parts of Asia where that's early in the morning it's good, but I ha=
ven't checked.



Normal time to arrange a telecon round the world is night over the Pacific,=
 which isn't good for Hawaii, but has a chance to catch the majority of=
 the world.



--

Christopher Dearlove

christo=
pher.dearlove@gmail.com



> On 26 Apr 2016, at 21:38, Justin Dean <bebemaster@gmail.com> wrote:

>

> I've requested webex interim meeting for the 10th of May at 2pm ES=
T.=C2=A0 The goal is to achieve consensus on the draft re-charter.

>

> Justin

> _______________________________________________

> manet mailing list

> manet@ietf.org=


> https://www.ietf.org/mailman/listinfo/manet






--94eb2c123f7c1f972b05316a3eeb--


From nobody Tue Apr 26 15:06: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 1A82612D198 for ; Tue, 26 Apr 2016 15:06: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, 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 eAgGSYwoOk9K for ; Tue, 26 Apr 2016 15:06:42 -0700 (PDT)
Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 C562D12D15C for ; Tue, 26 Apr 2016 15:06:41 -0700 (PDT)
Received: by mail-wm0-x243.google.com with SMTP id w143so7911873wmw.3 for ; Tue, 26 Apr 2016 15:06:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=AGY5Y1U7y51oKFbTXtdhUAkDhjJKdjXZr7JclteZ3aI=; b=e/ZmpNfYGLMMrIgq+xzHy68u51oEXvl91L1iW3TtR2ugsN2WnWUhd+rOK7A6Fq4I51 w2lwGjOy8NvwZ/lbo0ZTwPsAwv7aNcZmN5JnJiAOOpvRVxmhTLsBN42dIZBra+9geN3A YwIlJRCzfWuT8A7v975nLkNCwOoGDBsb0q8abH6SgmJaXNwDCbNU7skd69c/OBTgug1+ +xDjwftMTRo7vvYVh2f+L6cxgVpq1AdXadpBeCXreK/cX2jRD4Js/h2Zn2LCOeAuLeHc mlJXKzsvZ2QKFvcumw+J/BZQHMyil8F6IWFc5lk6HnEO+OSASw/L9AW+3Me76tb2x/vZ eoRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=AGY5Y1U7y51oKFbTXtdhUAkDhjJKdjXZr7JclteZ3aI=; b=eDnFNfUuy3utAs9gje97BMmEJlhOKtxZhHGhvLNpVGzGT26LsYaOLgyndkCn30TeKJ Y3B4uNv6i2RZ52s/G5rNOV8AejB12pmVsFi676Y5q5sD9xDefoJt7ARcDccTVdHPIK7H lkro2DPC7OjI7/Dh1XAp7I0kZl21lj4dab4VWrum0DWzbVedJhXG05BqvfKKS//g6KVU waixO8TyRZVwTkh0tTy1ezih51jWcyS7qK2fqt5dJSJtJd2MgvhImjagh85QVpUfG0r/ LK/UUY6Dv8UOP4UoadQ+ig0FHH9MpH23ZxIreowN/Nxh4Gv8mbxJqFIsDPpyoOF/9FDa 8pMQ==
X-Gm-Message-State: AOPr4FXZyIHasSVvx7eQO+BAerDE5F+JIXvm2YLe9gCxBGnEktgVOpqyGyDnTFrsZMHPhA==
X-Received: by 10.28.59.133 with SMTP id i127mr12736688wma.24.1461708400281; Tue, 26 Apr 2016 15:06:40 -0700 (PDT)
Received: from johns-mbp-4.home (host86-151-226-34.range86-151.btcentralplus.com. [86.151.226.34]) by smtp.gmail.com with ESMTPSA id w77sm25953771wmw.10.2016.04.26.15.06.39 for  (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Apr 2016 15:06:39 -0700 (PDT)
From: John Dowdell 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <1E296417-D0F3-4E02-8323-F778A9203078@gmail.com>
Date: Tue, 26 Apr 2016 23:06:59 +0100
To: manet@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [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: Tue, 26 Apr 2016 22:06:43 -0000

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 ...

" 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.

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.

Regards
John=


From nobody Tue Apr 26 15:24:05 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 E095C12D0A9 for ; Tue, 26 Apr 2016 15:24:03 -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 NP4VhnanCogz for ; Tue, 26 Apr 2016 15:24:02 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC0812D0B0 for ; Tue, 26 Apr 2016 15:23:56 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=aUjEGtucJvbrJ3FrZGOUToRUsHqGGpepvvXztf/i/PtTqHLoPex+D+hORQsHEUx8; 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-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1avBOZ-0000Fa-5q; Tue, 26 Apr 2016 18:23:51 -0400
To: "Ivancic, William D. (GRC-LCA0)" , "manet@ietf.org" 
References: 
From: Charlie Perkins 
Message-ID: <14cf2f00-1972-9281-980b-3c9cb192173d@earthlink.net>
Date: Tue, 26 Apr 2016 15:23:47 -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: 8bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac70ccbdb54eee2a8934deccb6e00505ace350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: 
Subject: Re: [manet] Review of: draft-ietf-manet-aodvv2-14
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, 26 Apr 2016 22:24:04 -0000

Hello Will,

Thanks much for the review!  I will relay your list of typos to the 
other co-authors as well.

Good timing!  We are trying to finish this revision and go to Last Call 
this week.

Regards,
Charlie P.

On 4/26/2016 1:14 PM, Ivancic, William D. (GRC-LCA0) wrote:
> I reviewed  draft-ietf-manet-aodvv2-14 over the past few days and do not
> have any major issues with it.  I think, as written, there are no
> ambiguities I could find and it appear complete.  I fully believe multiple
> independent implementations could be written and expect to interoperate.
>
> I sent Charlie a list of minor typos and fixes.  The following might
> require some discussion:
>
> 13.4.2 . Integrity and Trust using ICVs
> Š.
> The data contained in AODVv2 routing protocol messages MUST be
> verified using Integrity Check Values, to avoid the use of message
> data if the message has been tampered with.
>
> Followed by
>
>
> 13.4.4 . Application to AODVv2
> Implementations of AODVv2 MUST support ICV TLVs using type-extensions
> 1 and 2, hash-function HASH_FUNCTION, and cryptographic function
> CRYPTOGRAPHIC_FUNCTION. An ICV MUST be included with every message.
> The ICV value MAY be truncated as specified in [RFC7182 ].
>
>
> Question:
> Should the MUSTs be a SHOULDs?  Are there low-processor implementations or
> specifice deployments that do not require such support?
>
>
>
> 13.4.4 . Application to AODVv2  Paragraph 3
>
>
> "...In this case, the RFC5444  multiplexer MUST be
> instructed to include the Packet TLVs in packets containing AODVv2
> messages, or MUST be selected because it always performs these
> additions. If the multiplexer is not capable of adding the Packet
> TLVs, the TLVs MUST be included as Message TLVs in each AODVv2
> message in the packet."
>
>
> Comment:
> Wording is unclear to me.  Should the "or" be an "and"?  The last sentance
>   in the paragraph contradics the previous two.
>
> Perhaps: " If the multiplexer is  capable of adding the Packet TLVs,  the
> RFC5444  multiplexer SHOULD be instructed to include the Packet TLVs in
> packets containing AODVv2 messages. However, If the multiplexer is not
> capable of adding the Packet TLVs, the TLVs MUST be included as Message
> TLVs in each AODVv2 message in the packet."
>
>
>
> Will Ivancic
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>


From nobody Tue Apr 26 16:16:24 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 6BC8712D093 for ; Tue, 26 Apr 2016 16:16:22 -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 HSwSfupJLyZr for ; Tue, 26 Apr 2016 16:16:20 -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 B8C9912B063 for ; Tue, 26 Apr 2016 16:16:20 -0700 (PDT)
Received: by mail-io0-x22c.google.com with SMTP id u185so35835712iod.3 for ; Tue, 26 Apr 2016 16:16:20 -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=5h/lq3SVG6cFuKVdLO0vyOqhpM7fcVXKrFDs1KauWZs=; b=AfXzgq9L66nqCuCgfJlz29hd+DX+G62NMaVUe0+ebU133DqOEMD5BNaS6W2r7ZYWA7 xnxge2944uP4DvWJXy8hvmGKJO7s2b12/RNlXl3VjGY5AnveIKs6WDOYF9AznYYBPulx AyTIloZKRVByjNU+6TylE38U4afNn3XqWCdj5I+q3J6dwMT9SeYqNgmNhZemqrG07Q07 1XhVOMoQe7ff5PlusCzzbOv3bL41XhPdUFLCc0h5+hM8vYQXyQZtW6TdllVflIDn3Wa0 esX9EnLLhEaaCM0Lu6YquZsIgLvULzx4VEDIgFKEsWYWp5XXus1beUE9QEZxN76yAChC dDMQ==
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=5h/lq3SVG6cFuKVdLO0vyOqhpM7fcVXKrFDs1KauWZs=; b=Yq/5onXB5dw2Vd7CQO5Pl6eKBf7mAp/tCqJyaXqxJQNWbYApqkK4CcYxsOk1RdAzbX ZU0kilqO2s+4YGBnwYGi46o80v3DV3Hy4ho5Z820y42+bY7+ZlyDvXw6L7Cpj+YmLnF9 ZE4RZGgkfJUa/00B+e6iU67yGzLmfZTpHMhwoozu/FMC3nUlfovgTQcMxhMXbkJVIr1k e5nHhrJr5esumm9ReirGN09X1NmdJg0zpd470aqxCbN2fisUKYffQk1rj0Y9A9KzSJj/ 9/Bnezxsiji33N4CSFFaUQpUO8wyHrWLhbWrb4kolsjGE2GdmFn1ODMBLXkbulxM4YA9 iOiQ==
X-Gm-Message-State: AOPr4FXpwI+SXZ8hgLIilO0rtwWmWQ7K55Ww1CD0ebMCYNzgClXiNqjp0VCifC7ivzUeD+2Btdy0DbTxkg+LKw==
MIME-Version: 1.0
X-Received: by 10.107.40.9 with SMTP id o9mr6264089ioo.183.1461712580148; Tue, 26 Apr 2016 16:16:20 -0700 (PDT)
Received: by 10.79.72.68 with HTTP; Tue, 26 Apr 2016 16:16:20 -0700 (PDT)
In-Reply-To: <1E296417-D0F3-4E02-8323-F778A9203078@gmail.com>
References: <1E296417-D0F3-4E02-8323-F778A9203078@gmail.com>
Date: Tue, 26 Apr 2016 19:16:20 -0400
Message-ID: 
From: Stan Ratliff 
To: John Dowdell 
Content-Type: multipart/alternative; boundary=001a1141f3321aa98305316b7bee
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: Tue, 26 Apr 2016 23:16:22 -0000

--001a1141f3321aa98305316b7bee
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 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.


>
> 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-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

--001a1141f3321aa98305316b7bee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


John, 

Speaking as a co-author and a DLE=
P 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 implementatio=
n 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 (wou=
ld) fluctuate wildly. From my experience, the "interesting statistic&q=
uot; 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 o=
n an idle link (because, after all, no traffic was flowing)... that drove t=
he router nuts, since it saw a "broken" (or nearly broken) link.<=
br>
=C2=A0



" 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.=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 c=
ase for a "Latency" metric *without* queueing delay. 
=C2=A0



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.<=
br>

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

=

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

Just a thought. 

Regards,
Stan
<=
br>



--001a1141f3321aa98305316b7bee--


From nobody Tue Apr 26 22:26: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 A182812D5BF for ; Tue, 26 Apr 2016 22:26:44 -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 COUD0XyFGi8v for ; Tue, 26 Apr 2016 22:26:43 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 C6BBB12B02E for ; Tue, 26 Apr 2016 22:26:42 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id y84so38330983lfc.0 for ; Tue, 26 Apr 2016 22:26:42 -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=r4o42QcjJUj2jtOp+BPH/V12ahw9IqwhjQRFFJU2ZyE=; b=FylCz1MbHp0LSDdey7AwKoPv4nCCXPEO8KHCdWmFLkJNFrw7P+RjJfZmtT82vy3F1A KQzIt//4LjF0x/TXWA8si1QtYAO2ypinatY1ZWVbGGlE1UmQUSH1DGx3IhDryJSjx2gR itVF8qo6FloKGYOYwH1TfWTxiYG+BKj8G3lSh3fTDu6mD/6Pd51QiHbPWzyDdooHrNwn U+qgJDQUIaFovwCcCU7/3m9orRrntaXvzSYFD60xpJ9wlv6sKz6uSxCpGEG2yA5MtCwg WLgKCzJZDxuuZntXNGomEOkCj+zk1pqT4EQKarjBhfKdJ1VXisGW5L0/imqI2Bz3P3ht XpCA==
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=r4o42QcjJUj2jtOp+BPH/V12ahw9IqwhjQRFFJU2ZyE=; b=lgKwbLmKwhLavUynfOd2m8C0StjPm7Qt9yMw6IUHnMb1E93n0C38rHl9dpSvenDSYl wH2py2zbD2S3YnAGsaFB2+b2XZt29f29Ilh4W3Tj9yMvVeQRo6VNRxvLtPsvidlHN8sv pqRv2w8SP1lypxfwfwd+/sOJBOr+Y5NdDm+OiwuFuqZsGBLYgvQUuJE225UAVrDl18A6 /TWscmqGP78qVx4ZHmPcYHeLHWyjQaogK+bbTnLAzFGHwNUJtD8K4KoD6BA0c6npPSr2 N0INe6V0VpDmkS8GyArUOujFWA5kYsZKDERHry6W4CfqVBpxK0mB3B7CuB0f99EP7H2J AvXw==
X-Gm-Message-State: AOPr4FX9du1qhmHFuQ8gROI79KA0CIYEOUXcxU54LtUSFgswjnWVhEYhJlSz82kg8YE4xujv3KrjREavrPISaQ==
X-Received: by 10.112.54.132 with SMTP id j4mr2695475lbp.3.1461734801092; Tue, 26 Apr 2016 22:26:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.24.42 with HTTP; Tue, 26 Apr 2016 22:26:11 -0700 (PDT)
In-Reply-To: 
References:  <5B611FD0-BE75-407E-AABB-94B718E4C37D@mnemosyne.demon.co.uk> 
From: Henning Rogge 
Date: Wed, 27 Apr 2016 07:26:11 +0200
Message-ID: 
To: Justin Dean 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Christopher Dearlove , "manet@ietf.org" 
Subject: Re: [manet] Webex MANET meeting (tentative date May 10th 2pm EST)
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, 27 Apr 2016 05:26:44 -0000

On Tue, Apr 26, 2016 at 11:47 PM, Justin Dean  wrote:
> Thank you for that. You're the second one who has mentioned that the time
> was bad. I'll look into moving it back a day or two and earlier in the day
> timewise.

I like the time (8pm in MET) because I have a work meeting the same day.

Henning Rogge


From nobody Tue Apr 26 23:44: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 348A712B01E for ; Tue, 26 Apr 2016 23:44:03 -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 2zMANCOpy7Lx for ; Tue, 26 Apr 2016 23:44:01 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 E149012B01B for ; Tue, 26 Apr 2016 23:44:00 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id e201so24208407wme.0 for ; Tue, 26 Apr 2016 23:44:00 -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=Nz6iN+Pzzj5OQSmbwuOZacunjM+zqqEhNj5zd7DQzg8=; b=ZU7sr0oFPLk5MXy00tMQNKMtRAqiGYS/9VGwbG4IolF+AzRvt+vMsRT7BIIeuK7mjU QjcthSWOT8/ND6eIl+oQZ1WqbTko2EfXORfiJjGhhAEropFInLtEDECfvuI6BJrBybva cewEKKK+6ZWVGmge1t6Yft2HaFt5oFNlM8pTsL0NaJVR1Fa33YU60rr8oFrUGQOk3TDy deJ0ywQdHnw+n6vNjtdDcg0LgmS/Yvj1eBAzcOqfEuSAHB78nBy82eQh8VQNIgc+mT18 BgSsEivxdREyxG7r4QwxZ/jiIegj33WvGirOT1u7FcsRyXKKrTGTuvrYwdR3K649LufN IMzA==
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=Nz6iN+Pzzj5OQSmbwuOZacunjM+zqqEhNj5zd7DQzg8=; b=VO7SkLGWffke6arJBZ+v61aOTzrIpWHyxTYYyRy+UIZyq9WwLaPqZiAPSNDV5npjeI 3XUWzRqq2uppr5a2uac1T74c9yCbOSybed9oRGnX4UqCv9km2mt9CaH5K6zmg0psxOZ1 EOzRlEBQ+1aDbIOMUFvRvyVwGV53VCykPIUY+BJNbhbgZbI5JETfrXdk6U0yUi9xJcoG 8ZYswFXwF27Oi5x3WGLui3rSwKt4HIk4JREV/yIMCwI8AMVsEb/huDX036l5YBRso6fg d8vzReUNaEMxIaYOV5tU/QBH9v+6rN9s9E1SG6evU+TkDzy5XyNmzklcvjTXj9asfi2b Ml7A==
X-Gm-Message-State: AOPr4FVwHtHQ0cR6Zx3JHcTahqkQ5TfcVc6qtBUHHMhuNdjHWnjNp3z0CKSEz35WrBc7mw==
X-Received: by 10.28.48.203 with SMTP id w194mr8158085wmw.67.1461739438695; Tue, 26 Apr 2016 23:43:58 -0700 (PDT)
Received: from [192.168.178.17] (524A11D6.cm-4-3a.dynamic.ziggo.nl. [82.74.17.214]) by smtp.gmail.com with ESMTPSA id w3sm2339837wjt.0.2016.04.26.23.43.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Apr 2016 23:43:57 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_35DA408B-4EEA-4C4B-BFA1-092584D381F7"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Teco Boot 
In-Reply-To: 
Date: Wed, 27 Apr 2016 08:43:57 +0200
Message-Id: <2DC54CCE-46BE-48D0-9497-52D31DCB5B40@inf-net.nl>
References: <1E296417-D0F3-4E02-8323-F778A9203078@gmail.com> 
To: Stan Ratliff 
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, 27 Apr 2016 06:44:03 -0000

--Apple-Mail=_35DA408B-4EEA-4C4B-BFA1-092584D381F7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> 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.

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


>=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=_35DA408B-4EEA-4C4B-BFA1-092584D381F7
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

iQIcBAEBCgAGBQJXIF+tAAoJECQbXIDdIQWqR7oP+wTNLT8msye/avf7uWoi6GHG
oY/cWmvA8pi+HAsYGvEHqlo0ZAllslQIxwtpJq1X+cmMm0nggnYonFGmAldQTSYt
bOnKgbmx+GJlfMl/EHgQ2ATWwwjCb/GyejthjVX0UtbUUFZv7xFCY88yfpGFAbdz
cZj6EvGORqMlJd4dT6AbL1g/Oh/0OeBqukXf/BTkORJ12KQbFSzpUHkZpg9NP0Td
bGcoiRX4Mr/yBon6133u8pDqLcilPYra21crpdUobvFrUJAzOcKVOZgqINyuEND1
8VFqhci4u99lkZoJQ0L17jghC+JcmlEe7EXyVjUqh56Z+QNdAwZ6L/0eR1NDHWmH
JtTSrICxLs7i2nXgcTY2TAhprt/jN9lY8QOJYVYdB22Fs5x/OXzEZc07fN38uTsy
l9Nv4BZ+AuSFnTiPjTD5LyjSQAtD7Coy4XQG5Ib5d4Le8+qLqBUA/5lBUfcg3vu5
XELVnkw+Y2Q0k9XVDgrXpeiyzNx3HOPbxbpmj8mquamPVeOyGI/2EdbhFCVtZnKa
P6/+AN0X8oB3qIaCKetiYjpZSC7HDgy6QZEPl7Z/PqYxKvw4W1P68IYfTrL9H7gq
ReFrJwi1sqc3PekQNgLGgEKhrnvmzwIrNnHKyZ1oKvnpeQrbAhzVLIddZTXAXGDd
yOVtBlRUwTZZlEIeps3Q
=BhCk
-----END PGP SIGNATURE-----

--Apple-Mail=_35DA408B-4EEA-4C4B-BFA1-092584D381F7--


From nobody Wed Apr 27 01:56:29 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 5173712D640; Wed, 27 Apr 2016 01:56:28 -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: <20160427085628.25165.47950.idtracker@ietfa.amsl.com>
Date: Wed, 27 Apr 2016 01:56:28 -0700
Archived-At: 
Cc: manet@ietf.org
Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-08.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, 27 Apr 2016 08:56:28 -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           : Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)
        Authors         : Jiazi Yi
                          Benoit Parrein
	Filename        : draft-ietf-manet-olsrv2-multipath-08.txt
	Pages           : 21
	Date            : 2016-04-27

Abstract:
   This document specifies a multi-path extension for the Optimized Link
   State Routing Protocol version 2 (OLSRv2) to discover multiple
   disjoint paths, so as to improve reliability of the OLSRv2 protocol.
   The interoperability with OLSRv2 is retained.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-08


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 Apr 27 02:57: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 16A9B12D6AF for ; Wed, 27 Apr 2016 02:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.915
X-Spam-Level: 
X-Spam-Status: No, score=-7.915 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] 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 62UxcgyWLuYN for ; Wed, 27 Apr 2016 02:56:57 -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 1230D12D6AC for ; Wed, 27 Apr 2016 02:56:55 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,540,1454976000"; d="scan'208,217"; a="34317589"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 27 Apr 2016 10:56:54 +0100
X-IronPort-AV: E=Sophos;i="5.24,540,1454976000";  d="scan'208,217";a="115694218"
Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds016.greenlnk.net with ESMTP; 27 Apr 2016 10:56:54 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.34]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 10:56:54 +0100
From: "Dearlove, Christopher (UK)" 
To: Thomas Heide Clausen , Justin Dean 
Thread-Topic: [manet] Recharter Discussion
Thread-Index: AQHRnKi1tIqGPmFeIkW1v/uroMSbLJ+WICEg///zOgCABnzxAIAAGCgAgAAK5ICAAOMAoA==
Date: Wed, 27 Apr 2016 09:56:53 +0000
Message-ID: 
References:      <82679804-2647-4913-ACF3-18E4FFF731A8@thomasclausen.org>
In-Reply-To: <82679804-2647-4913-ACF3-18E4FFF731A8@thomasclausen.org>
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1BF9GLKXM0002VGREEN_"
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, 27 Apr 2016 09:56:59 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1BF9GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIGtleSBwb2ludHMgYXMgSSBzZWUgaXQgYXJlOg0KLSBXZSBzaG91bGRu4oCZdCB3YWl0IGZv
ciB0ZWxlY29uLCBhbmQgY2Fu4oCZdCByZWx5IG9uIHRlbGVjb24gYW5kIGN1dCBvdXQgbGlzdC4N
Ci0gV2UgYXJlIHZlcnkgc2hvcnQgb2YgY29udHJpYnV0b3JzLiBNYW55IHdobyBoYXZlIGNvbnRy
aWJ1dGVkIGhhdmUgZHJvcHBlZCBhd2F5LiBBbmQgdGhvc2Ugd2hvIGhhdmUgYmVlbiBtYWluIGNy
ZWF0b3JzIG9mIFdHIFJGQ3MgKGxvb2tpbmcgYXQgc3RhdGlzdGljcywgQ2xhdXNlbiBhbmQgRGVh
cmxvdmUgaW4gcGFydGljdWxhciwgYnV0IGFsc28gb3RoZXJzIC0gYnV0IG5vdCBhIGxvdCBvZiBv
dGhlcnMsIGVzcGVjaWFsbHkgYWZ0ZXIgdGhlIGZpcnN0IGJhdGNoIG9mIEV4cGVyaW1lbnRhbCBS
RkNzKSBtYXkgb3IgbWF5IG5vdCBiZSBjb250cmlidXRpbmcuDQotIEJ1dCBldmVuIG1vcmUgaW1w
b3J0YW50bHkgd2UgbmVlZCByZWFsIHBlb3BsZSAocHJlZmVyYWJseSBjb21wYW5pZXMgd2l0aCBw
cm9kdWN0cykgdXNpbmcgb3VyIHByb3RvY29scyB3aXRoIHJlYWwgcHJvYmxlbXMuIERMRVAgSSB0
aGluayBoYXMgc29tZSByZWFsIGFkYXB0b3JzLCB0aG91Z2ggSSB0aGluayBtb3N0IGFyZSB3YWl0
aW5nIGZvciBhbiBSRkMuIE9MU1J2MiBpcyBzaG9ydCBvbiBjb21wYW5pZXMgYWR2ZXJ0aXNpbmcg
dGhleSBhcmUgdXNpbmcgaXQgLSBJIHdpc2ggc29tZSB3b3VsZCAoSeKAmW0gdG9sZCB0aGV5IGV4
aXN0LCBidXQgY291bGRu4oCZdCBuYW1lIGFueSkuIEFPRFZ2MiAod2hpY2ggbWF5IG9yIG1heSBu
b3QgYmUgaW4gc2NvcGUpIGFwcGVhcnMgbm90IHRvIGhhdmUgZXZlbiB1cCB0byBkYXRlIGV4cGVy
aW1lbnRhbCBjb2RlIChwbGVhc2UgY29ycmVjdCBpZiB3cm9uZykuDQotIEhlbmNlIGFsdGhvdWdo
IHdlIG1heSBoYXZlIHNvbWUgZ3JlYXQgaWRlYXMsIGl04oCZcyBub3QgeWV0IGNsZWFyIHBlb3Bs
ZSB3YW50IHRoZW0gYW5kIHdlIGNhbiBkZWxpdmVyIC0gRExFUCBtYWludGVuYW5jZSBiZWluZyBJ
IHRoaW5rIGNsb3Nlc3QgdG8gY29udHJhZGljdGluZyB0aGF0LCBhdCBsZWFzdCBwdWJsaWNseS4N
Cg0KVGhlcmUgaXMgdGhlIGhvcnJpYmxlIHdhcm5pbmcgb2YgQXV0b2NvbmYgdGhhdCB3ZW50IHdy
b25nIGluIHNldmVyYWwgd2F5cywgYnV0IGF0IHRoZSBlbmQsIGhhZCBubyBvbmUgd2hvIHdvdWxk
IGRvIHRoZSB3b3JrICh3aGljaCBpcyBhIGxvdCBvZiB3b3JrLCB0YWtpbmcgbG9uZ2VyIHRoYW4g
eW91IGV4cGVjdCkgdG8gY3JlYXRlIGEgZHJhZnQgYW5kIHRha2UgaXQgYWxsIHRoZSB3YXkuIEFu
ZCB0aGF0IG1lYW5zIGEgc21hbGwgdGVhbSBvZiBhY3R1YWwgYXV0aG9ycywgcGx1cyB3aWRlciBp
bnB1dC4NCg0KSW5jaWRlbnRhbGx5IHRoZSBhdXRvY29uZiBwcm9ibGVtIGlzIHN0aWxsIHJlYWws
IGJ1dCB3YXMgdG9vIG5hcnJvdy4gVGhhdCB3YXMgY29uc2lkZXJpbmcgYWRkcmVzcyBhdXRvY29u
ZmlndXJhdGlvbiAodGhvdWdoIHRoZSBXRyBuZXZlciBhY3R1YWxseSBnb3QgdGhlcmUpLiBBcyBJ
IHNlZSBpdCwgdGhlcmXigJlzIGFuIGluc2VwYXJhYmxlIChpbiB0ZXJtcyBvZiB0aGlua2luZyBh
Ym91dCBpdCwgZHJhZnRzIG1heSBvZiBjb3Vyc2Ugc2VwYXJhdGUgb3V0IGRldGFpbHMpIGlzc3Vl
IHRoYXQgaXMgb2YgYWRkcmVzcyBhc3NpZ25tZW50LCBpZGVudGl0eSBhc3NpZ25tZW50L21hbmFn
ZW1lbnQsIGNyeXB0b2dyYXBoaWMga2V5IG1hbmFnZW1lbnQsIGFuZCBvdGhlciBmb3JtcyBvZiBt
YW5hZ2VtZW50IChuZXR3b3JrIG1hbmFnZW1lbnQpLiBBbmQgc2V2ZXJhbCBjaGlja2VuIGFuZCBl
Z2cgcHJvYmxlbXMgdGhhdCBhcmlzZSBpbiB0aGVtLCBlc3BlY2lhbGx5IGluIGFkIGhvYyBuZXR3
b3Jrcy4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2lu
ZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJs
b3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4N
Cg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9n
eSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFl
c3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1z
IEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdh
bGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJr
LCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaG9tYXMgSGVpZGUgQ2xhdXNlbg0KU2Vu
dDogMjYgQXByaWwgMjAxNiAyMjowMQ0KVG86IEp1c3RpbiBEZWFuDQpDYzogbWFuZXRAaWV0Zi5v
cmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFJlY2hhcnRlciBEaXNjdXNzaW9uDQoNCg0KKioqIFdB
Uk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2Fu
aXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQu
DQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5r
cywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJk
aW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVj
ZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dl
d29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYg
eW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9j
ZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5
L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWls
cy5wZGY+Lg0KKioqIFdBUk5JTkcgKioqDQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ug
b3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbi4NCg0KDQoNCk9uIDI2IGF2
ci4gMjAxNiwgYXQgMjI6MjEsIEp1c3RpbiBEZWFuIDxiZWJlbWFzdGVyQGdtYWlsLmNvbTxtYWls
dG86YmViZW1hc3RlckBnbWFpbC5jb20+PiB3cm90ZToNClRob21hcyBJIHVuZGVyc3RhbmQgeW91
ciBjb25jZXJucyBidXQgd2UgaGF2ZSBtb3N0bHkgZ29uZSBvdmVyIHRoaXMgYmVmb3JlIGluIHBy
ZXZpb3VzIG1lZXRpbmdzLg0KDQpUaGUgSUVURiBjb25kdWN0cyBpcyBidXNpbmVzcyBvbiBtYWls
aW5nIGxpc3RzLg0KDQpNeSByZWNvbGxlY3Rpb24gaXMgdGhhdCB0aGUgc3RyYXdtYW4gY2hhcnRl
ciB3YXMgcHJlc2VudGVkIG9uY2UgaW4gYSBXRyBtZWV0aW5nLCB0aGVuIHRoZSBjaGFpcnMgZGlk
IG5vdCBhbmltYXRlIGFueSBjaGFydGVyIGRpc2N1c3Npb24gZm9yIHNldmVyYWwgSUVURnMsIG9u
IHRoZSBsaXN0IChub3Igd2FzIHRoZSBjaGFydGVyIGRpc2N1c3NlZCBpbiBzdWJzZXF1ZW50IG1l
ZXRpbmdzKSAtIHVudGlsIHRoaXMgcHJlc2VudCAidXJnZW5jeSIgd2FzIGRlY2xhcmVkIChieSB0
aGUgY2hhaXJzKSB0byB0aGUgV0cuDQoNCg0KVGhlIEFEIHdpbGwgbm90IGFsbG93IHVzIHRvIG1l
ZXQgYXQgdGhlIG5leHQgSUVURiBtZWV0aW5nIGlmIHdlIGRvIG5vdCBoYXZlIGEgbmV3IGNoYXJ0
ZXIgYW5kIG5ldyB3b3JrIGl0ZW1zLg0KDQpUaGF0IGRvZXMgbm90IG5lZ2F0ZSBteSBwb2ludCwg
aG93ZXZlciwgd2hpY2ggd2FzIHRoYXQ6DQoNCml0IHNob3VsZCBiZSBlc3RhYmxpc2hlZCBvbiB0
aGUgbGlzdCB0aGF0IHRoZXJlIGFyZSBtZWFuaW5nZnVsIHRoaW5ncyB0byBkbywgYW5kIHRoZXJl
J3MgYSBtZWFuaW5nZnVsIGNyaXRpY2FsIG1hc3Mgb2YgcGVvcGxlIHRvIGJlIGRvaW5nIHRob3Nl
IHRoaW5ncywgYmVmb3JlIGEgKHZpcnR1YWwpIGludGVyaW0gaXMgY2FsbGVkLiBCcmFpbnN0b3Jt
aW5nIG9uIGEgdGVsZWNvbmZlcmVuY2UgaXMgcmFyZWx5IGEgY29uc3RydWN0aXZlIHdheSB0byBz
cGVuZCB0aW1lDQoNCg0KVGhvbWFzDQoNCg0KVG8geW91ciBwb2ludCBpdCdzIGltcGFyYXRpdmUg
dGhhdCB0aGUgZGlzY3Vzc2lvbiBjb250aW51ZXMgb24gbGlzdCBhYm91dCB0aGUgY2hhcnRlci4g
IFdpdGggdGhhdCBpbiBtaW5kIGhlcmUgaXMgYSBzdWdnZXN0ZWQgZWRpdCBvZiB0aGUgcHJldmlv
dXNseSBmbG9hdGVkIGNoYXJ0ZXIsIHdpdGggY29tbWVudHMgaW4gKCkgd2l0aCBKV0QgdGFncy4N
Cg0KDQoNClRoZSBwdXJwb3NlIG9mIHRoZSBNQU5FVCB3b3JraW5nIGdyb3VwIGlzIHRvIHN0YW5k
YXJkaXplIElQIHJvdXRpbmcgcHJvdG9jb2wgZnVuY3Rpb25hbGl0eSBzdWl0YWJsZSBmb3Igd2ly
ZWxlc3Mgcm91dGluZyBhcHBsaWNhdGlvbiB3aXRoaW4gYm90aCBzdGF0aWMgYW5kIGR5bmFtaWMg
dG9wb2xvZ2llcyB3aXRoIGluY3JlYXNlZCBkeW5hbWljcyBkdWUgdG8gbm9kZSBtb3Rpb24gb3Ig
b3RoZXIgZmFjdG9ycy4NCg0KDQoNCkFwcHJvYWNoZXMgYXJlIGludGVuZGVkIHRvIGJlIHJlbGF0
aXZlbHkgbGlnaHR3ZWlnaHQgaW4gbmF0dXJlLCBzdWl0YWJsZSBmb3IgbXVsdGlwbGUgaGFyZHdh
cmUgYW5kIHdpcmVsZXNzIGVudmlyb25tZW50cywgYW5kIGFkZHJlc3Mgc2NlbmFyaW9zIHdoZXJl
IE1BTkVUcyBhcmUgZGVwbG95ZWQgYXQgdGhlIGVkZ2VzIG9mIGFuIElQIGluZnJhc3RydWN0dXJl
LiBIeWJyaWQgbWVzaCBpbmZyYXN0cnVjdHVyZXMgKGUuZy4sIGEgbWl4dHVyZSBvZiBmaXhlZCBh
bmQgbW9iaWxlIHJvdXRlcnMpIHNob3VsZCBhbHNvIGJlIHN1cHBvcnRlZCBieSBNQU5FVCBzcGVj
aWZpY2F0aW9ucyBhbmQgbWFuYWdlbWVudCBmZWF0dXJlcy4NCg0KDQoNClRoZSBNQU5FVCBXRyBp
cyByZXNwb25zaWJsZSBmb3IgdGhlIG1haW50ZW5hbmNlIG9mIE9MU1J2MiwgQU9EVnYyIChKV0Qg
VEJEKSwgRExFUCBhbmQgTkhQRC4gT2YgcGFydGljdWxhciBpbnRlcmVzdDogc2VjdXJpdHkgZW5o
YW5jZW1lbnRzLCBhbmQgZW5jcnlwdGlvbiBzZWN1cml0eSBleHRlbnNpb25zIGZvciBSRkM1NDQ0
LiAoSldEIHdlIG1heSB3YW50IHRvIGJyZWFrIHRoaXMgb3V0IG9mIHRoZSBXRyBhbmQgbWFrZSBh
IG5ldyBNQU5FVCBTZWMgd29ya2luZyBncm91cCB0byBncmFiIHRoZSBhdHRlbnRpb24gb2YgdGhv
c2UgaW50ZXJlc3RlZCBpbiBzZWN1cml0eSBhbmQgZ2V0IHRoZWlyIHBhcnRpY2lwYXRpb24uKQ0K
DQoNCg0KVGhlIE1BTkVUIFdHIHdpbGwgc3RhbmRhcmRpemUgYSBtdWx0aWNhc3QgTUFORVQgcHJv
dG9jb2wgZnJhbWV3b3JrIGJhc2VkIG9uIHByZXZpb3VzIHdvcmsgYW5kIGxlc3NvbnMgbGVhcm5l
ZCBmb3Igc2NvcGVkIGZvcndhcmRpbmcgd2l0aGluIE1BTkVUIG5ldHdvcmtzLiAgQXMgcGFydCBv
ZiB0aGlzIGZyYW1ld29yayB0aGUgV0cgd2lsbCBwcm9kdWNlIGEgd2VsbCBkZWZpbmVkIE1BTkVU
IG11bHRpY2FzdCBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIGJhc2UuDQoNCg0KDQpUaGUgV0cgd2ls
bCBwcm9kdWNlIGFuIGluZm9ybWF0aW9uYWwgZHJhZnQgb3V0bGluaW5nIGNoYWxsZW5nZXMgYW5k
IGJlc3QgcHJhY3RpY2VzIGZvciBkZXBsb3lpbmcgYW5kIG1hbmFnaW5nIE1BTkVUIG5ldHdvcmtz
Lg0KDQoNCg0KVGhlIE1BTkVUIFdHIHdpbGwgaW50ZXJhY3Qgd2l0aCB0aGUgUElNIHdvcmtpbmcg
Z3JvdXAgb24gaXNzdWVzIHJlbGF0aW5nIHRvIHRoZSBtdWx0aWNhc3Qgd29yay4gIFRoZSBXRyB3
aWxsIGFsc28gcGF5IGF0dGVudGlvbiB0byBvdGhlciBJRVRGIGFuZCBJUlRGIHdvcmsgdGhhdCBp
cyBhZGRyZXNzaW5nIHRvcGljcyByZWxhdGVkIHRvIE1BTkVUIGVudmlyb25tZW50cy4NCg0KDQoN
CkluIHN1bW1hcnksIHRoZSBXRyB3aWxsIGRldmVsb3AgdGhlIGZvbGxvd2luZyBkcmFmdHM6DQoN
Cg0KDQpNQU5FVCBNYW5hZ2VtZW50IERvY3VtZW50IChJbmZvcm1hdGlvbmFsKQ0KDQpNQU5FVCBN
YWludGVuYW5jZQ0KDQogLSBSRkM1NDQ0IFNlY3VyaXR5IGV4dGVuc2lvbiAoU3RhbmRhcmRzKSAo
SldEIHBvc3NpYmx5IG1vdmUgdGhpcyB0byBuZXcgd29ya2luZyBncm91cCkNCg0KTUFORVQgTXVs
dGljYXN0DQoNCiAtIE11bHRpY2FzdCBGSUIgKFN0YW5kYXJkcykNCg0KDQoNCk9uIFR1ZSwgQXBy
IDI2LCAyMDE2IGF0IDI6NTUgUE0sIFRob21hcyBDbGF1c2VuIDxpZXRmQHRob21hc2NsYXVzZW4u
b3JnPG1haWx0bzppZXRmQHRob21hc2NsYXVzZW4ub3JnPj4gd3JvdGU6DQpIaSwNCg0KSSBiZWxp
ZXZlIHRoYXQgYW4gdmlydHVhbCBpbnRlcmltIGlzIHByZW1hdHVyZTogYSB0ZWxlY29uZmVyZW5j
ZSBpcywgbWVjaGFuaWNhbGx5LCBsZXNzIGluY2x1c2l2ZSB0aGFuIGFyZSBtYWlsaW5nIGxpc3Qg
ZGlzY3Vzc2lvbnMgKHRpbWUtem9uZXMsIG90aGVyIGNvbW1pdG1lbnRzLCByZXF1aXJlbWVudCBv
ZiBzeW5jaHJvbmljaXR5IG9mIHBhcnRpY2lwYXRpb24sIGV0Yy4pLg0KDQpGdXJ0aGVybW9yZS4u
Li4NCg0KVW50aWwgc3VjaCB0aW1lIHRoYXQgYSBzdHJhd21hbiBjaGFydGVyIGlzIHByb3Bvc2Vk
LCB1cGRhdGVkIHRvIHJlZmxlY3QgdGhlIHJlYWxpdHkgb2YgdGhlIGdyb3VwIGFzIHN0aXB1bGF0
ZWQgYnkgdGhlIEFEIGFuZCBieSBNci4gRGVhbiwgYXMgd2VsbCBhcyBhZGRpdGlvbmFsIGNoYXJ0
ZXIgaXRlbXMgZW1lcmdpbmcgb24gdGhlIGxpc3QsICBhbmQgd2l0aCByZWxhdGl2ZWx5IGJyb2Fk
IGFuZCBkZWVwIHN1cHBvcnQgZm9yIHRoZSBpbmNsdWRlZCBpdGVtcyBieSB0aGUgd29ya2luZyBn
cm91cCwgaGF2aW5nIGFuIGludGVyaW0gLSB2aXJ0dWFsIG9yIG90aGVyd2lzZSAtIGlzIG5vdCBj
b25zdHJ1Y3RpdmUuDQoNCkluIG90aGVyIHdvcmRzLCBpdCBzaG91bGQgYmUgZXN0YWJsaXNoZWQg
b24gdGhlIGxpc3QgdGhhdCB0aGVyZSBhcmUgbWVhbmluZ2Z1bCB0aGluZ3MgdG8gZG8sIGFuZCB0
aGVyZSdzIGEgbWVhbmluZ2Z1bCBjcml0aWNhbCBtYXNzIG9mIHBlb3BsZSB0byBiZSBkb2luZyB0
aG9zZSB0aGluZ3MsIGJlZm9yZSBhICh2aXJ0dWFsKSBpbnRlcmltIGlzIGNhbGxlZC4gQnJhaW5z
dG9ybWluZyBvbiBhIHRlbGVjb25mZXJlbmNlIGlzIHJhcmVseSBhIGNvbnN0cnVjdGl2ZSB3YXkg
dG8gc3BlbmQgdGltZS4NCg0KDQpCZXN0LA0KDQoNClRob21hcw0KDQpTZW50IGZyb20gbXkgaVBh
ZA0KDQpPbiAyMiBBcHIgMjAxNiwgYXQgMTc6NTAsIFN0YW4gUmF0bGlmZiA8cmF0bGlmZnN0YW5A
Z21haWwuY29tPG1haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb20+PiB3cm90ZToNCkhlbGxvIFdH
LA0KDQpEbyB3ZSBuZWVkIHRvIGhvbGQgYW4gaW50ZXJpbSBtZWV0aW5nICh2aWEgV2ViRVgpIHRv
IGRpc2N1c3M/IEknZCBsaWtlIHRvIGdldCBvcGluaW9ucyBvbiB0aGUgbGlzdCBhYm91dCB0aGF0
LiBXZSdsbCBuZWVkIGEgY291cGxlIG9mIHdlZWtzIHRvIHNjaGVkdWxlLCBidXQgd2UgY2FuIGRv
IHRoYXQuDQoNCk9uZSBvdGhlciBwb2ludCBpbmxpbmU6DQoNCk9uIEZyaSwgQXByIDIyLCAyMDE2
IGF0IDExOjQ1IEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVA
YmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3Jv
dGU6DQpNdWx0aWNhc3QgaXMgdGhlIG9idmlvdXMgdG9wIGl0ZW0uIExvdHMgb2YgcG9zc2libGUg
YXBwcm9hY2hlcywgdGltZSB0byBkaXNjdXNzLg0KDQpHYXRld2F5cyBmb3IgQU9EVnYyIGF0IFN0
YW5kYXJkIGlzIG9idmlvdXNseSBub3QgcG9zc2libGUgc2luY2UgQU9EVnYyIGlzIGdvaW5nIHRv
IGJlIEV4cGVyaW1lbnRhbCBhdCBtb3N0Lg0KDQpNYW5hZ2VtZW50IHdlIGRpZCBvZiBjb3Vyc2Ug
aGF2ZSBhbiBOSERQL09MU1J2MiBkcmFmdCBraWxsZWQgYnkgQUQuIFdoaWNoIHNpbmNlIE5IRFAv
T0xTUnYyIHVzIGFsbCB3ZSBoYXZlIChTTUYgZXhjZXB0ZWQpIHRoYXQgd2FzIGEgYml0IHRyaWNr
eS4NCg0KSSB3b3VsZCBoYXZlIHRvIG1ha2UgYW4gSVBSIGRlY2xhcmF0aW9uIHRvIHNheSBzb21l
IG9mIHdoYXQgSSBtaWdodCBoYXZlIHRvIHNheSBhYm91dCBlbmNyeXB0aW9uLiBOb3QgdG9kYXku
DQoNClVuZGVyc3Rvb2QuIEJ1dCBwbGVhc2UgcmVtZW1iZXIgLSB0aGVyZSdzIG9ubHkgYWJvdXQg
YSA1LXdlZWsgZ2FwIG5vdyBiZWZvcmUgdGhlIGNoYXJ0ZXIgbmVlZHMgdG8gYmUgY29tcGxldGUg
aW4gb3JkZXIgZm9yIHRoZSBXRyB0byBtZWV0IGluIEJlcmxpbi4NCg0KUmVnYXJkcywNClN0YW4N
Cg0KDQoNCg0KTWlzc2luZyBmcm9tIHRoZSBsaXN0IGlzIGFueSB3b3JrIG9uIE9MU1J2MiAob3Ig
TkhEUCkuIE1ULU9MU1J2MiBpcyBleHBlcmltZW50YWwuIFRoYXQgd291bGQgbmVlZCBpbXBsZW1l
bnRhdGlvbiB0ZXN0cyB0byBhZHZhbmNlIHRvIFBTLiBBbnlvbmUgaW50ZXJlc3RlZCBpbiB0aGF0
IChJ4oCZbSBub3Qgc2F5aW5nIEkgY2FuKT8NCg0KTW9yZSBicm9hZGx5IG9uIE9MU1J2MiB0aGVy
ZSBhcmUgdmFyaW91cyB0aGluZ3MgdGhhdCBjb3VsZCBiZSBkb25lLCBidXQgd2hhdCBpcyByZWFs
bHkgbmVlZGVkIGlzIHBlb3BsZSB3aXRoIGEgcmVhbCBhcHBsaWNhdGlvbi4gQW55IHRoYXQgZXhp
c3Qgd2VyZSBmcmlnaHRlbmVkIGF3YXkgZnJvbSB0aGlzIGdyb3VwLg0KDQotLQ0KQ2hyaXN0b3Bo
ZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxp
ZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0
NCAoMCkxMjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4gIHwgIEU6
IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVz
eXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2Zv
cmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4
SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4N
CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4g
RW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBS
ZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBtYW5ldCBb
bWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5v
cmc+XSBPbiBCZWhhbGYgT2YgSnVzdGluIERlYW4NClNlbnQ6IDIyIEFwcmlsIDIwMTYgMTY6MDcN
ClRvOiBtYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbWFu
ZXRdIFJlY2hhcnRlciBEaXNjdXNzaW9uDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3Nh
Z2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20g
YW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkg
d2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVu
dHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlv
dSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRw
Oi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGln
aHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlz
IHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5l
bnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRz
L0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KKioqIFdBUk5JTkcg
KioqDQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNp
ZGUgb3VyIG9yZ2FuaXphdGlvbi4NCg0KSSdsbCBzdGFydCB0aGluZ3Mgb2ZmIGJ5IGZsb2F0aW5n
IHRoZSBkcmFmdCByZS1jaGFydGVyIHdoaWNoIHdhcyBwcmVzZW50ZWQgaW4gUHJhZ3VlLg0KDQoN
ClRoZSBwdXJwb3NlIG9mIHRoZSBNQU5FVCB3b3JraW5nIGdyb3VwIGlzIHRvIHN0YW5kYXJkaXpl
IElQIHJvdXRpbmcgcHJvdG9jb2wgZnVuY3Rpb25hbGl0eSBzdWl0YWJsZSBmb3Igd2lyZWxlc3Mg
cm91dGluZyBhcHBsaWNhdGlvbiB3aXRoaW4gYm90aCBzdGF0aWMgYW5kIGR5bmFtaWMgdG9wb2xv
Z2llcyB3aXRoIGluY3JlYXNlZCBkeW5hbWljcyBkdWUgdG8gbm9kZSBtb3Rpb24gb3Igb3RoZXIg
ZmFjdG9ycy4NCg0KDQoNCkFwcHJvYWNoZXMgYXJlIGludGVuZGVkIHRvIGJlIHJlbGF0aXZlbHkg
bGlnaHR3ZWlnaHQgaW4gbmF0dXJlLCBzdWl0YWJsZSBmb3IgbXVsdGlwbGUgaGFyZHdhcmUgYW5k
IHdpcmVsZXNzIGVudmlyb25tZW50cywgYW5kIGFkZHJlc3Mgc2NlbmFyaW9zIHdoZXJlIE1BTkVU
cyBhcmUgZGVwbG95ZWQgYXQgdGhlIGVkZ2VzIG9mIGFuIElQIGluZnJhc3RydWN0dXJlLiBIeWJy
aWQgbWVzaCBpbmZyYXN0cnVjdHVyZXMgKGUuZy4sIGEgbWl4dHVyZSBvZiBmaXhlZCBhbmQgbW9i
aWxlIHJvdXRlcnMpIHNob3VsZCBhbHNvIGJlIHN1cHBvcnRlZCBieSBNQU5FVCBzcGVjaWZpY2F0
aW9ucyBhbmQgbWFuYWdlbWVudCBmZWF0dXJlcy4NCg0KDQoNClRoZSBNQU5FVCBXRyBpcyByZXNw
b25zaWJsZSBmb3IgdGhlIG1haW50ZW5hbmNlIG9mIE9MU1J2MiwgQU9EVnYyLCBETEVQIGFuZCBO
SFBELiBPZiBwYXJ0aWN1bGFyIGludGVyZXN0OiBib3JkZXIgYmVoYXZpb3IgYmV0d2VlbiBNQU5F
VCBuZXR3b3JrcyBhbmQgZml4ZWQgSVAgbmV0d29yayBpbmZyYXN0cnVjdHVyZXMsIGVuaGFuY2Ug
QU9EVnYyIGdhdGV3YXkgZnVuY3Rpb25hbGl0eTsgc2VjdXJpdHkgZW5oYW5jZW1lbnRzLCBlbmNy
eXB0aW9uIHNlY3VyaXR5IGV4dGVuc2lvbnMgZm9yIFJGQzU0NDQuDQoNCg0KDQpUaGUgTUFORVQg
V0cgd2lsbCBzdGFuZGFyZGl6ZSBhIG11bHRpY2FzdCBNQU5FVCBwcm90b2NvbCBmcmFtZXdvcmsg
YmFzZWQgb24gcHJldmlvdXMgd29yayBhbmQgbGVzc29ucyBsZWFybmVkIGZvciBzY29wZWQgZm9y
d2FyZGluZyB3aXRoaW4gTUFORVQgbmV0d29ya3MuICBBcyBwYXJ0IG9mIHRoaXMgZnJhbWV3b3Jr
IHRoZSBXRyB3aWxsIHByb2R1Y2UgYSB3ZWxsIGRlZmluZWQgTUFORVQgbXVsdGljYXN0IGZvcndh
cmRpbmcgaW5mb3JtYXRpb24gYmFzZS4NCg0KDQoNClRoZSBXRyB3aWxsIHByb2R1Y2UgYW4gaW5m
b3JtYXRpb25hbCBkcmFmdCBvdXRsaW5pbmcgY2hhbGxlbmdlcyBhbmQgYmVzdCBwcmFjdGljZXMg
Zm9yIGRlcGxveWluZyBhbmQgbWFuYWdpbmcgTUFORVQgbmV0d29ya3MuDQoNCg0KDQpUaGUgTUFO
RVQgV0cgd2lsbCBpbnRlcmFjdCB3aXRoIHRoZSBQSU0gd29ya2luZyBncm91cCBvbiBpc3N1ZXMg
cmVsYXRpbmcgdG8gdGhlIG11bHRpY2FzdCB3b3JrLiAgVGhlIFdHIHdpbGwgYWxzbyBwYXkgYXR0
ZW50aW9uIHRvIG90aGVyIElFVEYgYW5kIElSVEYgd29yayB0aGF0IGlzIGFkZHJlc3NpbmcgdG9w
aWNzIHJlbGF0ZWQgdG8gTUFORVQgZW52aXJvbm1lbnRzLg0KDQoNCg0KSW4gc3VtbWFyeSwgdGhl
IFdHIHdpbGwgZGV2ZWxvcCB0aGUgZm9sbG93aW5nIGRyYWZ0czoNCg0KDQoNCk1BTkVUIE1hbmFn
ZW1lbnQgRG9jdW1lbnQgKEluZm9ybWF0aW9uYWwpDQoNCk1BTkVUIE1haW50ZW5hbmNlDQoNCiAt
IFJGQzU0NDQgU2VjdXJpdHkgZXh0ZW5zaW9uIChTdGFuZGFyZHMpDQoNCiAtIEVuaGFuY2VkIEFP
RFZ2MiBnYXRld2F5IGV4dGVuc2lvbiAoU3RhbmRhcmRzKQ0KDQpNQU5FVCBNdWx0aWNhc3QNCg0K
IC0gTXVsdGljYXN0IEZJQiAoU3RhbmRhcmRzKQ0KDQoNCg0KDQoNClRoaXMgd2lsbCBsaWtlbHkg
YmUgY29uc2lkZXJlZCB0b28gYnJvYWQgdG8gcGFzcy4gIFdlIHdpbGwgbGlrZWx5IG5lZWQgdG8g
Y3V0IHNvbWUgYW5kIGZvY3VzIHRoZSB3b3JrLiAgRm9yIG1lIHBlcnNvbmFsbHkgSSBrbm93IEkg
aGF2ZSB0aGUgdGltZSBhbmQgYmFja2luZyB0byB3b3JrIG9uIHRoZSBNdWx0aWNhc3QgcGllY2Uu
DQoNCg0KDQpKdXN0aW4NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2ht
ZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50IGFuZCBtYXkg
YWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCnJlY2lwaWVu
dCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVy
Lg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBk
aXNjbG9zZSBvcg0KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4N
CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBp
ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1h
aWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5l
dEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCg==

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1BF9GLKXM0002VGREEN_
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
LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNv
LXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs
InNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6
IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN
Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg
NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi
IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K
PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i
RU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5UaGUga2V5IHBvaW50cyBhcyBJIHNlZSBpdCBhcmU6PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPi0gV2Ugc2hvdWxkbuKAmXQgd2FpdCBmb3IgdGVsZWNvbiwgYW5k
IGNhbuKAmXQgcmVseSBvbiB0ZWxlY29uIGFuZCBjdXQgb3V0IGxpc3QuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPi0gV2UgYXJlIHZlcnkgc2hvcnQgb2YgY29udHJpYnV0b3JzLiBNYW55
IHdobyBoYXZlIGNvbnRyaWJ1dGVkIGhhdmUgZHJvcHBlZCBhd2F5LiBBbmQgdGhvc2Ugd2hvIGhh
dmUgYmVlbiBtYWluIGNyZWF0b3JzIG9mIFdHIFJGQ3MgKGxvb2tpbmcgYXQgc3RhdGlzdGljcywg
Q2xhdXNlbg0KIGFuZCBEZWFybG92ZSBpbiBwYXJ0aWN1bGFyLCBidXQgYWxzbyBvdGhlcnMgLSBi
dXQgbm90IGEgbG90IG9mIG90aGVycywgZXNwZWNpYWxseSBhZnRlciB0aGUgZmlyc3QgYmF0Y2gg
b2YgRXhwZXJpbWVudGFsIFJGQ3MpIG1heSBvciBtYXkgbm90IGJlIGNvbnRyaWJ1dGluZy48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LSBCdXQgZXZlbiBtb3JlIGltcG9ydGFudGx5IHdl
IG5lZWQgcmVhbCBwZW9wbGUgKHByZWZlcmFibHkgY29tcGFuaWVzIHdpdGggcHJvZHVjdHMpIHVz
aW5nIG91ciBwcm90b2NvbHMgd2l0aCByZWFsIHByb2JsZW1zLiBETEVQIEkgdGhpbmsgaGFzIHNv
bWUgcmVhbCBhZGFwdG9ycywNCiB0aG91Z2ggSSB0aGluayBtb3N0IGFyZSB3YWl0aW5nIGZvciBh
biBSRkMuIE9MU1J2MiBpcyBzaG9ydCBvbiBjb21wYW5pZXMgYWR2ZXJ0aXNpbmcgdGhleSBhcmUg
dXNpbmcgaXQgLSBJIHdpc2ggc29tZSB3b3VsZCAoSeKAmW0gdG9sZCB0aGV5IGV4aXN0LCBidXQg
Y291bGRu4oCZdCBuYW1lIGFueSkuIEFPRFZ2MiAod2hpY2ggbWF5IG9yIG1heSBub3QgYmUgaW4g
c2NvcGUpIGFwcGVhcnMgbm90IHRvIGhhdmUgZXZlbiB1cCB0byBkYXRlIGV4cGVyaW1lbnRhbA0K
IGNvZGUgKHBsZWFzZSBjb3JyZWN0IGlmIHdyb25nKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+LSBIZW5jZSBhbHRob3VnaCB3ZSBtYXkgaGF2ZSBzb21lIGdyZWF0IGlkZWFzLCBpdOKA
mXMgbm90IHlldCBjbGVhciBwZW9wbGUgd2FudCB0aGVtIGFuZCB3ZSBjYW4gZGVsaXZlciAtIERM
RVAgbWFpbnRlbmFuY2UgYmVpbmcgSSB0aGluayBjbG9zZXN0IHRvIGNvbnRyYWRpY3RpbmcNCiB0
aGF0LCBhdCBsZWFzdCBwdWJsaWNseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGlzIHRoZSBob3JyaWJsZSB3
YXJuaW5nIG9mIEF1dG9jb25mIHRoYXQgd2VudCB3cm9uZyBpbiBzZXZlcmFsIHdheXMsIGJ1dCBh
dCB0aGUgZW5kLCBoYWQgbm8gb25lIHdobyB3b3VsZCBkbyB0aGUgd29yayAod2hpY2ggaXMgYSBs
b3Qgb2Ygd29yaywgdGFraW5nDQogbG9uZ2VyIHRoYW4geW91IGV4cGVjdCkgdG8gY3JlYXRlIGEg
ZHJhZnQgYW5kIHRha2UgaXQgYWxsIHRoZSB3YXkuIEFuZCB0aGF0IG1lYW5zIGEgc21hbGwgdGVh
bSBvZiBhY3R1YWwgYXV0aG9ycywgcGx1cyB3aWRlciBpbnB1dC48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluY2lkZW50
YWxseSB0aGUgYXV0b2NvbmYgcHJvYmxlbSBpcyBzdGlsbCByZWFsLCBidXQgd2FzIHRvbyBuYXJy
b3cuIFRoYXQgd2FzIGNvbnNpZGVyaW5nIGFkZHJlc3MgYXV0b2NvbmZpZ3VyYXRpb24gKHRob3Vn
aCB0aGUgV0cgbmV2ZXIgYWN0dWFsbHkgZ290IHRoZXJlKS4NCiBBcyBJIHNlZSBpdCwgdGhlcmXi
gJlzIGFuIGluc2VwYXJhYmxlIChpbiB0ZXJtcyBvZiB0aGlua2luZyBhYm91dCBpdCwgZHJhZnRz
IG1heSBvZiBjb3Vyc2Ugc2VwYXJhdGUgb3V0IGRldGFpbHMpIGlzc3VlIHRoYXQgaXMgb2YgYWRk
cmVzcyBhc3NpZ25tZW50LCBpZGVudGl0eSBhc3NpZ25tZW50L21hbmFnZW1lbnQsIGNyeXB0b2dy
YXBoaWMga2V5IG1hbmFnZW1lbnQsIGFuZCBvdGhlciBmb3JtcyBvZiBtYW5hZ2VtZW50IChuZXR3
b3JrIG1hbmFnZW1lbnQpLg0KIEFuZCBzZXZlcmFsIGNoaWNrZW4gYW5kIGVnZyBwcm9ibGVtcyB0
aGF0IGFyaXNlIGluIHRoZW0sIGVzcGVjaWFsbHkgaW4gYWQgaG9jIG5ldHdvcmtzLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8bzpwPjwvbzpwPjwv
c3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206
MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlz
dG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBT
eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bhbj48L2I+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAw
N0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3
RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjog
Jm5ic3A7JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8ICZuYnNwOzxiPkU6DQo8L2I+PGEg
aHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5kZWFybG92
ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQg
VGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4u
PGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSI+PHNwYW4gc3R5bGU9
ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0
ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVn
aXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwg
R1UyIDdZUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg
T2YgPC9iPlRob21hcyBIZWlkZSBDbGF1c2VuPGJyPg0KPGI+U2VudDo8L2I+IDI2IEFwcmlsIDIw
MTYgMjI6MDE8YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBEZWFuPGJyPg0KPGI+Q2M6PC9iPiBtYW5l
dEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBSZWNoYXJ0ZXIgRGlz
Y3Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xp
ZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNr
Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl
PSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9zcGFu
PjwvYj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu
dGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dy
b3VuZDp3aGl0ZSI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcy
Ij5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwg
ZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwv
ZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24g
YW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+
DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48
L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQi
PlJlZCBGbGFnczwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzMzMzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlv
dSByZWNlaXZlLA0KIGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVt
cy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdz
LnBkZiI+DQpoZXJlPC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWls
IGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5l
bnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRz
L0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNz
PC9hPi48L3NwYW4+PC9lbT48L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzMzMzk3MiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjEuMHB0
IDQuMHB0IDEuMHB0IDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPioqDQo8
L3NwYW4+PC9zdHJvbmc+PC9zcGFuPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
V0FSTklORw0KPC9zcGFuPjwvc3Ryb25nPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPioqKjwvc3Bhbj48L3N0
cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5FWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBm
cm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv
dHRvbToxMi4wcHQiPjxicj4NCk9uIDI2IGF2ci4gMjAxNiwgYXQgMjI6MjEsIEp1c3RpbiBEZWFu
ICZsdDs8YSBocmVmPSJtYWlsdG86YmViZW1hc3RlckBnbWFpbC5jb20iPmJlYmVtYXN0ZXJAZ21h
aWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaG9tYXMgSSB1bmRlcnN0YW5kIHlvdXIgY29uY2Vy
bnMgYnV0IHdlIGhhdmUgbW9zdGx5IGdvbmUgb3ZlciB0aGlzIGJlZm9yZSBpbiBwcmV2aW91cyBt
ZWV0aW5ncy4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIElFVEYgY29uZHVjdHMgaXMgYnVzaW5lc3Mgb24g
bWFpbGluZyBsaXN0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+TXkgcmVjb2xsZWN0aW9uIGlzIHRoYXQgdGhlIHN0cmF3bWFuIGNoYXJ0ZXIg
d2FzIHByZXNlbnRlZCBvbmNlIGluIGEgV0cgbWVldGluZywgdGhlbiB0aGUgY2hhaXJzIGRpZCBu
b3QgYW5pbWF0ZSBhbnkgY2hhcnRlciBkaXNjdXNzaW9uIGZvciBzZXZlcmFsIElFVEZzLCBvbiB0
aGUgbGlzdCAobm9yIHdhcyB0aGUgY2hhcnRlciBkaXNjdXNzZWQgaW4gc3Vic2VxdWVudCBtZWV0
aW5ncykgLSB1bnRpbCB0aGlzIHByZXNlbnQNCiAmcXVvdDt1cmdlbmN5JnF1b3Q7IHdhcyBkZWNs
YXJlZCAoYnkgdGhlIGNoYWlycykgdG8gdGhlIFdHLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgQUQgd2lsbCBub3QgYWxsb3cgdXMgdG8gbWVl
dCBhdCB0aGUgbmV4dCBJRVRGIG1lZXRpbmcgaWYgd2UgZG8gbm90IGhhdmUgYSBuZXcgY2hhcnRl
ciBhbmQgbmV3IHdvcmsgaXRlbXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGRvZXMgbm90IG5lZ2F0ZSBteSBwb2ludCwg
aG93ZXZlciwgd2hpY2ggd2FzIHRoYXQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6bm9uZSAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl
ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5pdCBzaG91bGQgYmUgZXN0YWJsaXNoZWQgb24gdGhl
IGxpc3QgdGhhdCB0aGVyZSBhcmUmbmJzcDs8Yj48dT5tZWFuaW5nZnVsIHRoaW5ncyB0byBkbzwv
dT48L2I+LCBhbmQgdGhlcmUncyBhJm5ic3A7PGI+PHU+bWVhbmluZ2Z1bCBjcml0aWNhbCBtYXNz
IG9mIHBlb3BsZSB0byBiZSBkb2luZyB0aG9zZSB0aGluZ3M8L3U+PC9iPiwgYmVmb3JlIGEgKHZp
cnR1YWwpIGludGVyaW0gaXMNCiBjYWxsZWQuIEJyYWluc3Rvcm1pbmcgb24gYSB0ZWxlY29uZmVy
ZW5jZSBpcyByYXJlbHkgYSBjb25zdHJ1Y3RpdmUgd2F5IHRvIHNwZW5kIHRpbWU8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvbWFzPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8geW91ciBwb2lu
dCBpdCdzIGltcGFyYXRpdmUgdGhhdCB0aGUgZGlzY3Vzc2lvbiBjb250aW51ZXMgb24gbGlzdCBh
Ym91dCB0aGUgY2hhcnRlci4mbmJzcDsgV2l0aCB0aGF0IGluIG1pbmQgaGVyZSBpcyBhIHN1Z2dl
c3RlZCBlZGl0IG9mIHRoZSBwcmV2aW91c2x5IGZsb2F0ZWQgY2hhcnRlciwgd2l0aCBjb21tZW50
cyBpbiAoKSB3aXRoIEpXRCB0YWdzLjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K
PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBwdXJwb3NlIG9mIHRoZSBNQU5FVCB3
b3JraW5nIGdyb3VwIGlzIHRvIHN0YW5kYXJkaXplIElQIHJvdXRpbmcgcHJvdG9jb2wgZnVuY3Rp
b25hbGl0eSBzdWl0YWJsZSBmb3Igd2lyZWxlc3Mgcm91dGluZyBhcHBsaWNhdGlvbiB3aXRoaW4g
Ym90aCBzdGF0aWMgYW5kIGR5bmFtaWMgdG9wb2xvZ2llcyB3aXRoIGluY3JlYXNlZCBkeW5hbWlj
cyBkdWUgdG8gbm9kZSBtb3Rpb24gb3Igb3RoZXIgZmFjdG9ycy4mbmJzcDsgPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QXBwcm9h
Y2hlcyBhcmUgaW50ZW5kZWQgdG8gYmUgcmVsYXRpdmVseSBsaWdodHdlaWdodCBpbiBuYXR1cmUs
IHN1aXRhYmxlIGZvciBtdWx0aXBsZSBoYXJkd2FyZSBhbmQgd2lyZWxlc3MgZW52aXJvbm1lbnRz
LCBhbmQgYWRkcmVzcyBzY2VuYXJpb3Mgd2hlcmUgTUFORVRzIGFyZSBkZXBsb3llZCBhdCB0aGUg
ZWRnZXMgb2YgYW4gSVAgaW5mcmFzdHJ1Y3R1cmUuIEh5YnJpZCBtZXNoIGluZnJhc3RydWN0dXJl
cyAoZS5nLiwgYSBtaXh0dXJlIG9mIGZpeGVkIGFuZCBtb2JpbGUgcm91dGVycykgc2hvdWxkIGFs
c28gYmUgc3VwcG9ydGVkIGJ5IE1BTkVUIHNwZWNpZmljYXRpb25zIGFuZCBtYW5hZ2VtZW50IGZl
YXR1cmVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPlRoZSBNQU5FVCBXRyBpcyByZXNwb25zaWJsZSBmb3IgdGhlIG1haW50ZW5h
bmNlIG9mIE9MU1J2MiwgQU9EVnYyIChKV0QgVEJEKSwgRExFUCBhbmQgTkhQRC4gT2YgcGFydGlj
dWxhciBpbnRlcmVzdDogc2VjdXJpdHkgZW5oYW5jZW1lbnRzLCBhbmQgZW5jcnlwdGlvbiBzZWN1
cml0eSBleHRlbnNpb25zIGZvciBSRkM1NDQ0LiAoSldEIHdlIG1heSB3YW50IHRvIGJyZWFrIHRo
aXMgb3V0IG9mIHRoZSBXRyBhbmQgbWFrZSBhIG5ldyBNQU5FVCBTZWMgd29ya2luZyBncm91cCB0
byBncmFiIHRoZSBhdHRlbnRpb24gb2YgdGhvc2UgaW50ZXJlc3RlZCBpbiBzZWN1cml0eSBhbmQg
Z2V0IHRoZWlyIHBhcnRpY2lwYXRpb24uKTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBNQU5FVCBXRyB3aWxsIHN0YW5kYXJk
aXplIGEgbXVsdGljYXN0IE1BTkVUIHByb3RvY29sIGZyYW1ld29yayBiYXNlZCBvbiBwcmV2aW91
cyB3b3JrIGFuZCBsZXNzb25zIGxlYXJuZWQgZm9yIHNjb3BlZCBmb3J3YXJkaW5nIHdpdGhpbiBN
QU5FVCBuZXR3b3Jrcy4mbmJzcDsgQXMgcGFydCBvZiB0aGlzIGZyYW1ld29yayB0aGUgV0cgd2ls
bCBwcm9kdWNlIGEgd2VsbCBkZWZpbmVkIE1BTkVUIG11bHRpY2FzdCBmb3J3YXJkaW5nIGluZm9y
bWF0aW9uIGJhc2UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj
b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJjb2xvcjpibGFjayI+VGhlIFdHIHdpbGwgcHJvZHVjZSBhbiBpbmZvcm1hdGlvbmFsIGRy
YWZ0IG91dGxpbmluZyBjaGFsbGVuZ2VzIGFuZCBiZXN0IHByYWN0aWNlcyBmb3IgZGVwbG95aW5n
IGFuZCBtYW5hZ2luZyBNQU5FVCBuZXR3b3Jrcy4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIE1BTkVUIFdHIHdpbGwgaW50
ZXJhY3Qgd2l0aCB0aGUgUElNIHdvcmtpbmcgZ3JvdXAgb24gaXNzdWVzIHJlbGF0aW5nIHRvIHRo
ZSBtdWx0aWNhc3Qgd29yay4mbmJzcDsgVGhlIFdHIHdpbGwgYWxzbyBwYXkgYXR0ZW50aW9uIHRv
IG90aGVyIElFVEYgYW5kIElSVEYgd29yayB0aGF0IGlzIGFkZHJlc3NpbmcgdG9waWNzIHJlbGF0
ZWQgdG8gTUFORVQgZW52aXJvbm1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkluIHN1bW1hcnksIHRoZSBXRyB3aWxsIGRl
dmVsb3AgdGhlIGZvbGxvd2luZyBkcmFmdHM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TUFORVQgTWFuYWdlbWVudCBEb2N1bWVu
dCAoSW5mb3JtYXRpb25hbCk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsYWNrIj5NQU5FVCBNYWludGVuYW5jZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDstIFJGQzU0NDQgU2VjdXJp
dHkgZXh0ZW5zaW9uIChTdGFuZGFyZHMpIChKV0QgcG9zc2libHkgbW92ZSB0aGlzIHRvIG5ldyB3
b3JraW5nIGdyb3VwKTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPk1BTkVUIE11bHRpY2FzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiAtIE11bHRpY2FzdCBGSUIgKFN0YW5kYXJkcyk8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiBUdWUsIEFwciAyNiwgMjAxNiBhdCAyOjU1IFBNLCBUaG9tYXMgQ2xhdXNlbiAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZXRm
QHRob21hc2NsYXVzZW4ub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZlIHRoYXQgYW4gdmly
dHVhbCBpbnRlcmltIGlzIHByZW1hdHVyZTogYSB0ZWxlY29uZmVyZW5jZSBpcywgbWVjaGFuaWNh
bGx5LCBsZXNzIGluY2x1c2l2ZSB0aGFuIGFyZSBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbnMgKHRp
bWUtem9uZXMsIG90aGVyIGNvbW1pdG1lbnRzLCByZXF1aXJlbWVudCBvZiBzeW5jaHJvbmljaXR5
IG9mIHBhcnRpY2lwYXRpb24sIGV0Yy4pLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GdXJ0aGVybW9yZS4uLi48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VW50aWwgc3VjaCB0aW1lIHRoYXQg
YSBzdHJhd21hbiBjaGFydGVyIGlzIHByb3Bvc2VkLCA8Yj48dT51cGRhdGVkIHRvIHJlZmxlY3Qg
dGhlIHJlYWxpdHkgb2YgdGhlIGdyb3VwPC91PjwvYj4gYXMgc3RpcHVsYXRlZCBieSB0aGUgQUQg
YW5kIGJ5IE1yLiBEZWFuLCBhcyB3ZWxsIGFzIGFkZGl0aW9uYWwgY2hhcnRlciBpdGVtcyBlbWVy
Z2luZyBvbiB0aGUgbGlzdCwgJm5ic3A7YW5kDQo8Yj48dT53aXRoIHJlbGF0aXZlbHkgYnJvYWQg
YW5kIGRlZXAgc3VwcG9ydDwvdT48L2I+IGZvciB0aGUgaW5jbHVkZWQgaXRlbXMgYnkgdGhlIHdv
cmtpbmcgZ3JvdXAsIGhhdmluZyBhbiBpbnRlcmltIC0gdmlydHVhbCBvciBvdGhlcndpc2UgLSBp
cyBub3QgY29uc3RydWN0aXZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gb3RoZXIgd29yZHMsIGl0IHNob3VsZCBiZSBlc3Rh
Ymxpc2hlZCBvbiB0aGUgbGlzdCB0aGF0IHRoZXJlIGFyZQ0KPGI+PHU+bWVhbmluZ2Z1bCB0aGlu
Z3MgdG8gZG88L3U+PC9iPiwgYW5kIHRoZXJlJ3MgYSA8Yj48dT5tZWFuaW5nZnVsIGNyaXRpY2Fs
IG1hc3Mgb2YgcGVvcGxlIHRvIGJlIGRvaW5nIHRob3NlIHRoaW5nczwvdT48L2I+LCBiZWZvcmUg
YSAodmlydHVhbCkgaW50ZXJpbSBpcyBjYWxsZWQuIEJyYWluc3Rvcm1pbmcgb24gYSB0ZWxlY29u
ZmVyZW5jZSBpcyByYXJlbHkgYSBjb25zdHJ1Y3RpdmUgd2F5IHRvIHNwZW5kIHRpbWUuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+
DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJl
c3QsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlRob21hczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZW50IGZyb20gbXkgaVBhZDxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1ib3R0b206MTIuMHB0Ij5PbiAyMiBBcHIgMjAxNiwgYXQgMTc6NTAsIFN0YW4gUmF0bGlm
ZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJhdGxpZmZzdGFuQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh
bmsiPnJhdGxpZmZzdGFuQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gV0csJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB3ZSBuZWVkIHRvIGhvbGQgYW4gaW50ZXJpbSBtZWV0
aW5nICh2aWEgV2ViRVgpIHRvIGRpc2N1c3M/IEknZCBsaWtlIHRvIGdldCBvcGluaW9ucyBvbiB0
aGUgbGlzdCBhYm91dCB0aGF0LiBXZSdsbCBuZWVkIGEgY291cGxlIG9mIHdlZWtzIHRvIHNjaGVk
dWxlLCBidXQgd2UgY2FuIGRvIHRoYXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBvdGhlciBwb2ludCBpbmxpbmU6Jm5ic3A7
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBcHIgMjIsIDIw
MTYgYXQgMTE6NDUgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspICZsdDs8YSBocmVmPSJt
YWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJp
cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NdWx0aWNhc3QgaXMgdGhlIG9idmlvdXMgdG9wIGl0ZW0u
IExvdHMgb2YgcG9zc2libGUgYXBwcm9hY2hlcywgdGltZSB0byBkaXNjdXNzLjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkdhdGV3YXlzIGZvciBBT0RWdjIgYXQgU3RhbmRhcmQgaXMgb2J2aW91c2x5IG5vdCBwb3Nz
aWJsZSBzaW5jZSBBT0RWdjIgaXMgZ29pbmcgdG8gYmUgRXhwZXJpbWVudGFsDQogYXQgbW9zdC48
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5NYW5hZ2VtZW50IHdlIGRpZCBvZiBjb3Vyc2UgaGF2ZSBhbiBOSERQL09M
U1J2MiBkcmFmdCBraWxsZWQgYnkgQUQuIFdoaWNoIHNpbmNlIE5IRFAvT0xTUnYyIHVzIGFsbA0K
IHdlIGhhdmUgKFNNRiBleGNlcHRlZCkgdGhhdCB3YXMgYSBiaXQgdHJpY2t5Ljwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkkgd291bGQgaGF2ZSB0byBtYWtlIGFuIElQUiBkZWNsYXJhdGlvbiB0byBzYXkgc29tZSBv
ZiB3aGF0IEkgbWlnaHQgaGF2ZSB0byBzYXkgYWJvdXQgZW5jcnlwdGlvbi4NCiBOb3QgdG9kYXku
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlVuZGVyc3Rvb2QuIEJ1dCBwbGVhc2UgcmVtZW1iZXIgLSB0aGVyZSdzIG9u
bHkgYWJvdXQgYSA1LXdlZWsgZ2FwIG5vdyBiZWZvcmUgdGhlIGNoYXJ0ZXIgbmVlZHMgdG8gYmUg
Y29tcGxldGUgaW4gb3JkZXIgZm9yIHRoZSBXRyB0byBtZWV0IGluIEJlcmxpbi4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJk
cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0
YW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj
bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWlzc2lu
ZyBmcm9tIHRoZSBsaXN0IGlzIGFueSB3b3JrIG9uIE9MU1J2MiAob3IgTkhEUCkuIE1ULU9MU1J2
MiBpcyBleHBlcmltZW50YWwuIFRoYXQgd291bGQgbmVlZA0KIGltcGxlbWVudGF0aW9uIHRlc3Rz
IHRvIGFkdmFuY2UgdG8gUFMuIEFueW9uZSBpbnRlcmVzdGVkIGluIHRoYXQgKEnigJltIG5vdCBz
YXlpbmcgSSBjYW4pPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1vcmUgYnJvYWRseSBvbiBPTFNSdjIgdGhlcmUg
YXJlIHZhcmlvdXMgdGhpbmdzIHRoYXQgY291bGQgYmUgZG9uZSwgYnV0IHdoYXQgaXMgcmVhbGx5
IG5lZWRlZCBpcw0KIHBlb3BsZSB3aXRoIGEgcmVhbCBhcHBsaWNhdGlvbi4gQW55IHRoYXQgZXhp
c3Qgd2VyZSBmcmlnaHRlbmVkIGF3YXkgZnJvbSB0aGlzIGdyb3VwLjwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy
LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPC9z
cGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNl
bmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln
ZW5jZSBMYWJvcmF0b3JpZXM8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOzxhIGhyZWY9InRlbDolMkI0
NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0IiB0YXJnZXQ9Il9ibGFuayI+JiM0Mzs0NCAoMCkxMjQ1
IDI0MjE5NDwvYT4NCiAmbmJzcDt8ICZuYnNwOzxiPkU6IDwvYj48YSBocmVmPSJtYWlsdG86Y2hy
aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92
ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQg
VGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4u
PGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxh
bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3Nw
YW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQg
SW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2Fs
ZXMgTm86IDAxMzM3NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6
IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4gbWFuZXQNCiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYW5ldC1ib3VuY2VzQGll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P
biBCZWhhbGYgT2YgPC9iPkp1c3RpbiBEZWFuPGJyPg0KPGI+U2VudDo8L2I+IDIyIEFwcmlsIDIw
MTYgMTY6MDc8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIg
dGFyZ2V0PSJfYmxhbmsiPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBb
bWFuZXRdIFJlY2hhcnRlciBEaXNjdXNzaW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNr
Z3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3Rl
eHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8L3NwYW4+PC9iPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl
ciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O3Rl
eHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRz
aWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3Ig
dGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhl
ciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3Ig
cmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVn
YXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9v
ayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8v
aW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRz
L0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiIHRhcmdldD0iX2JsYW5rIj4NCmhlcmU8L2E+Ljwv
c3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJy
Pg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxl
YXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9o
b3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBT
dXNwaWNpb3VzJTIwRW1haWxzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0KdGhpcyBwcm9jZXNzPC9h
Pi48L3NwYW4+PC9lbT48L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n
OjEuMHB0IDQuMHB0IDEuMHB0IDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj
ZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KjxzdHJvbmc+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PioqDQo8L3NwYW4+PC9zdHJvbmc+PC9zcGFuPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+V0FSTklORw0KPC9zcGFuPjwvc3Ryb25nPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPioqKjwvc3Bh
bj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij5FWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2lu
YXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox
Mi4wcHQiPkknbGwgc3RhcnQgdGhpbmdzIG9mZiBieSBmbG9hdGluZyB0aGUgZHJhZnQgcmUtY2hh
cnRlciB3aGljaCB3YXMgcHJlc2VudGVkIGluIFByYWd1ZS4gJm5ic3A7PGJyPg0KPGJyPg0KPG86
cD48L286cD48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIHB1cnBvc2Ug
b2YgdGhlIE1BTkVUIHdvcmtpbmcgZ3JvdXAgaXMgdG8gc3RhbmRhcmRpemUgSVAgcm91dGluZyBw
cm90b2NvbCBmdW5jdGlvbmFsaXR5IHN1aXRhYmxlIGZvciB3aXJlbGVzcyByb3V0aW5nIGFwcGxp
Y2F0aW9uIHdpdGhpbiBib3RoIHN0YXRpYyBhbmQgZHluYW1pYyB0b3BvbG9naWVzIHdpdGggaW5j
cmVhc2VkIGR5bmFtaWNzIGR1ZSB0byBub2RlIG1vdGlvbiBvciBvdGhlciBmYWN0b3JzLiZuYnNw
OyA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsYWNrIj5BcHByb2FjaGVzIGFyZSBpbnRlbmRlZCB0byBiZSByZWxhdGl2ZWx5IGxpZ2h0d2Vp
Z2h0IGluIG5hdHVyZSwgc3VpdGFibGUgZm9yIG11bHRpcGxlIGhhcmR3YXJlIGFuZCB3aXJlbGVz
cyBlbnZpcm9ubWVudHMsIGFuZCBhZGRyZXNzIHNjZW5hcmlvcyB3aGVyZSBNQU5FVHMgYXJlIGRl
cGxveWVkIGF0IHRoZSBlZGdlcyBvZiBhbiBJUCBpbmZyYXN0cnVjdHVyZS4gSHlicmlkIG1lc2gg
aW5mcmFzdHJ1Y3R1cmVzIChlLmcuLCBhIG1peHR1cmUgb2YgZml4ZWQgYW5kIG1vYmlsZSByb3V0
ZXJzKSBzaG91bGQgYWxzbyBiZSBzdXBwb3J0ZWQgYnkgTUFORVQgc3BlY2lmaWNhdGlvbnMgYW5k
IG1hbmFnZW1lbnQgZmVhdHVyZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIE1BTkVUIFdHIGlzIHJlc3BvbnNpYmxlIGZv
ciB0aGUgbWFpbnRlbmFuY2Ugb2YgT0xTUnYyLCBBT0RWdjIsIERMRVAgYW5kIE5IUEQuIE9mIHBh
cnRpY3VsYXIgaW50ZXJlc3Q6IGJvcmRlciBiZWhhdmlvciBiZXR3ZWVuIE1BTkVUIG5ldHdvcmtz
IGFuZCBmaXhlZCBJUCBuZXR3b3JrIGluZnJhc3RydWN0dXJlcywgZW5oYW5jZSBBT0RWdjIgZ2F0
ZXdheSBmdW5jdGlvbmFsaXR5OyBzZWN1cml0eSBlbmhhbmNlbWVudHMsIGVuY3J5cHRpb24gc2Vj
dXJpdHkgZXh0ZW5zaW9ucyBmb3IgUkZDNTQ0NC4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIE1BTkVUIFdHIHdpbGwgc3Rh
bmRhcmRpemUgYSBtdWx0aWNhc3QgTUFORVQgcHJvdG9jb2wgZnJhbWV3b3JrIGJhc2VkIG9uIHBy
ZXZpb3VzIHdvcmsgYW5kIGxlc3NvbnMgbGVhcm5lZCBmb3Igc2NvcGVkIGZvcndhcmRpbmcgd2l0
aGluIE1BTkVUIG5ldHdvcmtzLiZuYnNwOyBBcyBwYXJ0IG9mIHRoaXMgZnJhbWV3b3JrIHRoZSBX
RyB3aWxsIHByb2R1Y2UgYSB3ZWxsIGRlZmluZWQgTUFORVQgbXVsdGljYXN0IGZvcndhcmRpbmcg
aW5mb3JtYXRpb24gYmFzZS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgV0cgd2lsbCBwcm9kdWNlIGFuIGluZm9ybWF0aW9u
YWwgZHJhZnQgb3V0bGluaW5nIGNoYWxsZW5nZXMgYW5kIGJlc3QgcHJhY3RpY2VzIGZvciBkZXBs
b3lpbmcgYW5kIG1hbmFnaW5nIE1BTkVUIG5ldHdvcmtzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBNQU5FVCBXRyB3aWxs
IGludGVyYWN0IHdpdGggdGhlIFBJTSB3b3JraW5nIGdyb3VwIG9uIGlzc3VlcyByZWxhdGluZyB0
byB0aGUgbXVsdGljYXN0IHdvcmsuJm5ic3A7IFRoZSBXRyB3aWxsIGFsc28gcGF5IGF0dGVudGlv
biB0byBvdGhlciBJRVRGIGFuZCBJUlRGIHdvcmsgdGhhdCBpcyBhZGRyZXNzaW5nIHRvcGljcyBy
ZWxhdGVkIHRvIE1BTkVUIGVudmlyb25tZW50cy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JbiBzdW1tYXJ5LCB0aGUgV0cgd2ls
bCBkZXZlbG9wIHRoZSBmb2xsb3dpbmcgZHJhZnRzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1BTkVUIE1hbmFnZW1lbnQgRG9j
dW1lbnQgKEluZm9ybWF0aW9uYWwpPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+TUFORVQgTWFpbnRlbmFuY2UgPC9zcGFuPjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7LSBSRkM1NDQ0IFNl
Y3VyaXR5IGV4dGVuc2lvbiAoU3RhbmRhcmRzKTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiAtIEVuaGFuY2VkIEFPRFZ2MiBnYXRld2F5IGV4
dGVuc2lvbiAoU3RhbmRhcmRzKTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0iY29sb3I6YmxhY2siPk1BTkVUIE11bHRpY2FzdDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiAtIE11bHRpY2FzdCBGSUIgKFN0YW5k
YXJkcyk8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsYWNrIj5UaGlzIHdpbGwgbGlrZWx5IGJlIGNvbnNpZGVyZWQgdG9vIGJyb2Fk
IHRvIHBhc3MuJm5ic3A7IFdlIHdpbGwgbGlrZWx5IG5lZWQgdG8gY3V0IHNvbWUgYW5kIGZvY3Vz
IHRoZSB3b3JrLiZuYnNwOyBGb3IgbWUgcGVyc29uYWxseSBJIGtub3cgSSBoYXZlIHRoZSB0aW1l
IGFuZCBiYWNraW5nIHRvIHdvcmsgb24gdGhlIE11bHRpY2FzdCBwaWVjZS4mbmJzcDsgPC9zcGFu
PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
SnVzdGluPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+KioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKio8YnI+DQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlh
bCB0byB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVn
ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4NCnJlY2lwaWVudCBwbGVhc2UgZGVs
ZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj4NCllvdSBz
aG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ug
b3I8YnI+DQpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4N
CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8
YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRm
Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy
Pg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1h
bmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+bWFu
ZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1BF9GLKXM0002VGREEN_--


From nobody Wed Apr 27 03:04: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 8476F12D6B8 for ; Wed, 27 Apr 2016 03:04:13 -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 0DCSI7oqQNVp for ; Wed, 27 Apr 2016 03:04:05 -0700 (PDT)
Received: from mail-ob0-x242.google.com (mail-ob0-x242.google.com [IPv6:2607:f8b0:4003:c01::242]) (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 8BA3012D6BD for ; Wed, 27 Apr 2016 03:04:05 -0700 (PDT)
Received: by mail-ob0-x242.google.com with SMTP id o7so2446462obl.2 for ; Wed, 27 Apr 2016 03:04:05 -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=hMsqQXeIY3T5ENDWkLR3Rp3cfJh0AY6amhsmo3wVVos=; b=O6ARDghK0kjG7939BnDNS1R9fKEx8wFz+0M9PAp8VkRCvT2ARuf8Ia+XRSlHbSH0iz O9//rbYjrVFNk/TRwbQRZ4RVI8whAJvXCJHcrPFiuDxTPPphd+S9Ww8FJ1geNYh/zgy1 /f5mGsAUeT+MoHpv0VcmdKly7b8/YB5xhqAu+hiZWjGKtl18lTXr0wP00ygszO4xNZnX x1cxuctyvPOp1N2mEq5MOid6Zg49wJPr8Kq+BeqygMq1kMwRKyd7XjgTvnGHOwjQTlwj elvEY95EgpIDR3j+6F/oAKTLrsytgAN+nIs25F2tuVDHVHx3mTyKY1bLXFZVTkQpUm9n BkTg==
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=hMsqQXeIY3T5ENDWkLR3Rp3cfJh0AY6amhsmo3wVVos=; b=Q60duR8e352CIg3LYnoTe5ALnfDvIQgSrLMTmKyAKeNIHzd/lpOQCf40F0Ff8B3I4b sU1Y+lnjHa+7WLPTiRTTqkjHYMuhb3egQ/f+tGbYJmO3Px4WEL/mxFExBS/OT0vonTgO k3nxYHdK3fEoMmAQcU2GU4CLpcdDA/OY62xoyL0IFQOxKKG+q4Bt/LbuQ29xwIpsVUt0 gcqjPaBJQ5rcvUgzZnDklNOLZmxdFpmY//OSusDfjYmcmDMT0wcc984fkLDPED3kRrRd laaCoDpGItkRzxhkSEinoxMY35v4czyl3Vhv/ay+8u5blrKitEkitO34AIsyfvd5eJ21 PJZw==
X-Gm-Message-State: AOPr4FWEUUrB0Vmyos8JMdrOOn7mUbqzAQqtZIQVjGszoqsh/mmohxiodUJHGtQHNcS8B/rVYCY8zm9Y7tNL9g==
MIME-Version: 1.0
X-Received: by 10.129.109.206 with SMTP id i197mr4040149ywc.121.1461751444841;  Wed, 27 Apr 2016 03:04:04 -0700 (PDT)
Received: by 10.37.208.3 with HTTP; Wed, 27 Apr 2016 03:04:04 -0700 (PDT)
Date: Wed, 27 Apr 2016 18:04:04 +0800
Message-ID: 
From: Sandra Evans 
To: manet@ietf.org
Content-Type: multipart/alternative; boundary=001a114dd2669ea9b10531748708
Archived-At: 
Subject: [manet] Call for Participation: IEEE DIPDMWC2016 Moscow, Russia
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, 27 Apr 2016 10:04:13 -0000

--001a114dd2669ea9b10531748708
Content-Type: text/plain; charset=UTF-8

2016 Third International Conference on Digital Information Processing, Data
Mining, and Wireless Communications (DIPDMWC)

National Research Nuclear University MEPhI (Moscow Engineering Physics
Institute), Moscow, Russia

July 06-08, 2016

http://goo.gl/6HTGyi
===================================================================================================================

The conference welcomes papers on the following (but not limited to)
research topics:

- Adaptive Signal Processing
- Parallel Programming & Processing
- Artificial Intelligence
- Expert Systems
- Image Processing
- Information Security and Cryptography
- Modulation, Coding, and Channel Analysis
- Multimedia Signal Processing
- Bioinformatics & Biomedical Imaging
- Biomedical Signal Processing
- Natural Language Processing
- Neural Networks and Genetic Algorithms
- Computer-Aided Surgery
- Data Compression and Watermarking
- Data Mining Techniques
- Ethics of Data Mining
- Risk Management and Analysis
- Data Classification and Clustering
- Abnormally and Outlier Detection
- Feature Extraction and Data Reduction
- Multi-Task Learning
- Optimization Techniques
- Data Cleaning and Processing
- Text and Web Mining
- Bluetooth and Personal Area Networks
- Wireless System Architecture
- Mobile Management in Wireless Networks
- Mobile Database Access and Design
- IP Multimedia Sub-Systems
- Key Management Protocols
- Mobile/ Wireless Network Modeling and Simulation
- Mobile / Wireless Network Planning
- Wireless Network Standard and Protocols
- Digital Right Management and Multimedia Protection
and many more...

===================================================================================================================
Important Dates

Submission Dates Open from now until June 6, 2016
Notification of Acceptance 2-4 weeks from the submission date
Camera Ready Submission June 26, 2016
Registration Deadline June 26, 2016
Conference Dates July 6-8, 2016

--001a114dd2669ea9b10531748708
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


2016 Third International Conference on Digital Inform=
ation Processing, Data Mining, and Wireless Communications (DIPDMWC)
<=
div>
National Research Nuclear University MEPhI (Moscow Engin=
eering Physics Institute), Moscow, Russia

July 06-=
08, 2016

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

The conference welcomes papers on the following (but=
 not limited to) research topics:

- Adaptive Signa=
l Processing	
-=
 Parallel Programming & Processing
- Artificial Intelligence<=
span class=3D"" style=3D"white-space:pre">	
- Expert Syste=
ms
- Image Processing	=

- Information Security and Cryptography
- Modul=
ation, Coding, and Channel Analysis	
- Multimedia Signal Processing
- Bioinforma=
tics & Biomedical Imaging	
- Biomedical Signal Processing
- Natural Language=
 Processing	
- =
Neural Networks and Genetic Algorithms
- Computer-Aided Surgery	
- Data Compress=
ion and Watermarking
- Data Mining Techniques	
- Ethics of Data Mining
- Risk Management and Analysis	=

- Data Classification and Clustering
- Abnormal=
ly and Outlier Detection	=

- Feature Extraction and Data Reduction
- Multi-Task L=
earning	
- Opti=
mization Techniques
- Data Cleaning and Processing	
- Text and Web Mining
<=
div>- Bluetooth and Personal Area Networks	
- Wireless System Architecture
- Mob=
ile Management in Wireless Networks	
- Mobile Database Access and Design
- IP Mu=
ltimedia Sub-Systems	
- Key Management Protocols
- Mobile/ Wireless Network Mode=
ling and Simulation	
- Mobile / Wireless Network Planning
- Wireless Network Sta=
ndard and Protocols	
- Digital Right Management and Multimedia Protection
and ma=
ny more...

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Important Dates

Submission Dates<=
span class=3D"" style=3D"white-space:pre">		Open from now until June=
 6, 2016
Notification of Acceptance	2-4 weeks from the submission date
Camera Re=
ady Submission		June 26, =
2016
Registration Deadline		June 26, 2016
Conference Dates		July 6-8, 2016


--001a114dd2669ea9b10531748708--


From nobody Wed Apr 27 08:27:24 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 4574512D14C for ; Wed, 27 Apr 2016 08:27:22 -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 PlSQn-pbXxbU for ; Wed, 27 Apr 2016 08:27:16 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 0D56712D85B for ; Wed, 27 Apr 2016 08:27:16 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id o66so88915363ywc.3 for ; Wed, 27 Apr 2016 08:27:16 -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=I62VKKJO6KjVjadFZXuph+d4UJsGQ3fzNWzeXlNzI1o=; b=cj/orWx5rvlMfXqf313z4eW1i1K3NWkVIvPYX4ZKOGXh/VdOR3Av/IO2MVKR2fWoDi NAmyV4UaLhDNGx11A0a5pXDU8nxCld3G1tJGBR2/6As/vVQxGLpHg1U7CPrgOj3oZHVY gOzmCFhnXDxy2DxX+gIRzPpfzyVtZZgVrkPWv4iprAi5md+laC84PFL2mFtC7c7QQuF0 ynJitdQ5WU77dpLlNPk50kOP7n5PX7kmYukxuzVoqOJzuZZEdkVfHKxuhz2HxG3UUW+i wDLsCPz8mBkAuQb3cUc9RyD21qPJDjMPC5UG54+oSH5TCbaPjWyI5xSos/coxl0PKfv2 zVnA==
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=I62VKKJO6KjVjadFZXuph+d4UJsGQ3fzNWzeXlNzI1o=; b=ew3YT06OEWMC0kuW4hVUrn1byg5Btr3gJMCfXDKmGndKV51A2ke3Qd46HwG4S7kGPP ym1aA4KtMq9nhfAw6ClcbSqnbwahriRRsEr4/GRApQIIXqjLya3elVBUP9ePTOfZears /XTpRVZnuJyudlEU3zV2mBOmMgOb0Z5Sw9gKaEdcXE5OIdbrjIcp4MfI+kijHNC4Gz7a HS/4A4u3t7PHnxdpPd2+3Ymyz3QG03MTJsHVYgqzvj+dVG9fEAtkHjJiFgTQ7p2LPxQ0 MB7d1nW4vppqN3FNlUPTZwKHd8hggsefpUsrTD9OtJdCitjlxyWkbDA3Pnr+ea0KkfQ+ CT9A==
X-Gm-Message-State: AOPr4FWrg4KHrnxIyKeMtX/zKx8wiVoCPeOCyz1vgyGstXUgpUlKbRkqZTBFO1r8L8N5mTGx7+PcVg4WiHnpIQ==
MIME-Version: 1.0
X-Received: by 10.176.1.45 with SMTP id 42mr4705768uak.65.1461770835292; Wed, 27 Apr 2016 08:27:15 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Wed, 27 Apr 2016 08:27:15 -0700 (PDT)
Date: Wed, 27 Apr 2016 11:27:15 -0400
Message-ID: 
From: Justin Dean 
To: "manet@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11351d9e617be40531790bf4
Archived-At: 
Subject: [manet] New interim meeting date/time
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, 27 Apr 2016 15:27:22 -0000

--001a11351d9e617be40531790bf4
Content-Type: text/plain; charset=UTF-8

How does 5/12/16 at 10am GMT work for everyone?

--001a11351d9e617be40531790bf4
Content-Type: text/html; charset=UTF-8


How does 5/12/16 at 10am GMT work for everyone?


--001a11351d9e617be40531790bf4--


From nobody Wed Apr 27 08:35:59 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 9351612D85D for ; Wed, 27 Apr 2016 08:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level: 
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 hKBfFAYYe6Gk for ; Wed, 27 Apr 2016 08:35:56 -0700 (PDT)
Received: from smtp2.idirect.net (smtp2.idirect.net [198.180.159.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 2DDCE12D1D5 for ; Wed, 27 Apr 2016 08:35:56 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,542,1454994000"; d="scan'208,217";a="1032953"
IronPort-PHdr: =?us-ascii?q?9a23=3A/UUb5BWacFrujdVTVV/0qtsYsGrV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYZh2Dt8tkgFKBZ4jH8fUM07OQ6PCwHzxaqs/c+Fk5M7VyFDY9wf?= =?us-ascii?q?0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3CwN5?= =?us-ascii?q?K6zPF5LIiIzvjqbpq82VM18D3Wf1SIgxBSv1hD2ZjtMRj4pmJ/R54TryiVwMRd?= =?us-ascii?q?5rw3h1L0mYhRf265T41pdi9yNNp6BprJYYAu2pN5g/GJ5FFygnNSgZ6cTt/U3J?= =?us-ascii?q?QAGC43IHTmgMuhVNCgnBqhr9W8G1+mH/v+xwxAGbMNH4C7cuVn7qu6JiThL0oC?= =?us-ascii?q?YKKzB/93vY3J9elqVe9VibrgB7woDaJMmuKPN4eq7MN5tOXnBIQsJQWSJpA4+9?= =?us-ascii?q?dYYEE6wHMPoO/Nq1nEcHsRbrXVrkP+jo0DId3nI=3D?=
X-IPAS-Result: =?us-ascii?q?A2DIBABh2yBX/8n6+gpeHAGCT4EffQa0c4UBgXWGDwIcgUw?= =?us-ascii?q?SAQEBAQEBAQGBC4ItghQBAQEBAyMKXAIBCA4DBAEBKAMCAgIwFAkIAgQBEgi7I?= =?us-ascii?q?JE0AQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYihEqEVB+CSoJWBZgLBQGOD48YjzA?= =?us-ascii?q?nDoQYbIgvfwEBAQ?=
From: "Ratliff, Stanley" 
To: Justin Dean , "manet@ietf.org" 
Thread-Topic: [manet] New interim meeting date/time
Thread-Index: AQHRoJlQqg+zZL1cm0+xtoDaMNXBJJ+d8xug
Date: Wed, 27 Apr 2016 15:35:31 +0000
Message-ID: <375aa29ea2a14f0d81d4d4de67222174@VAUSDITCHM2.idirect.net>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.250.250.20]
Content-Type: multipart/alternative; boundary="_000_375aa29ea2a14f0d81d4d4de67222174VAUSDITCHM2idirectnet_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [manet] New interim meeting date/time
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, 27 Apr 2016 15:35:57 -0000

--_000_375aa29ea2a14f0d81d4d4de67222174VAUSDITCHM2idirectnet_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

SnVzdGluLA0KDQoxMGFtIEdNVD8gQXMgaW4gMDYwMCBFYXN0IGNvYXN0IHRpbWU/ICBJdOKAmXMg
ZG9hYmxlIGZvciBtZSwgYnV0IG9ubHkgaWYgSSBzdGFydCBJVi1jb2ZmZWUgYXQgYXJvdW5kIDA1
MDDigKYuIDstKQ0KDQpSZWdhcmRzLA0KU3Rhbg0KDQoNCkZyb206IG1hbmV0IFttYWlsdG86bWFu
ZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBEZWFuDQpTZW50OiBXZWRu
ZXNkYXksIEFwcmlsIDI3LCAyMDE2IDExOjI3IEFNDQpUbzogbWFuZXRAaWV0Zi5vcmcNClN1Ympl
Y3Q6IFttYW5ldF0gTmV3IGludGVyaW0gbWVldGluZyBkYXRlL3RpbWUNCg0KSG93IGRvZXMgNS8x
Mi8xNiBhdCAxMGFtIEdNVCB3b3JrIGZvciBldmVyeW9uZT8NCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpUaGlzIGVsZWN0cm9uaWMgbWVzc2Fn
ZSBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgY29udGFpbnMKaW5mb3JtYXRpb24g
ZnJvbSBpRGlyZWN0LCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnkKYW5kL29y
IGNvbmZpZGVudGlhbC4gSXQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp
bmRpdmlkdWFsCm9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGFy
ZSBub3QgdGhlIG9yaWdpbmFsCnJlY2lwaWVudCBvciB0aGUgcGVyc29uIHJlc3BvbnNpYmxlIGZv
ciBkZWxpdmVyaW5nIHRoZSBlbWFpbCB0byB0aGUKaW50ZW5kZWQgcmVjaXBpZW50LCBiZSBhZHZp
c2VkIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbAppbiBlcnJvciwgYW5kIHRoYXQg
YW55IHVzZSwgZGlzc2VtaW5hdGlvbiwgZm9yd2FyZGluZywgcHJpbnRpbmcsIG9yCmNvcHlpbmcg
b2YgdGhpcyBlbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhp
cyBlbWFpbAppbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgaW1tZWRpYXRlbHkgbm90aWZ5
IHRoZSBzZW5kZXIuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fCg==

--_000_375aa29ea2a14f0d81d4d4de67222174VAUSDITCHM2idirectnet_
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz
cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu
MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj
dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm
YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv
OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh
W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs
aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SnVzdGluLA0KPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4xMGFtIEdNVD8gQXMgaW4gMDYwMCBF
YXN0IGNvYXN0IHRpbWU/ICZuYnNwO0l04oCZcyBkb2FibGUgZm9yIG1lLCBidXQgb25seSBpZiBJ
IHN0YXJ0IElWLWNvZmZlZSBhdCBhcm91bmQgMDUwMOKApi4gOy0pDQo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlN0
YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gbWFuZXQgW21haWx0bzptYW5l
dC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gRGVhbjxicj4N
CjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDI3LCAyMDE2IDExOjI3IEFNPGJyPg0KPGI+
VG86PC9iPiBtYW5ldEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbbWFuZXRdIE5ldyBp
bnRlcmltIG1lZXRpbmcgZGF0ZS90aW1lPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBkb2VzIDUvMTIvMTYgYXQgMTBhbSBHTVQgd29yayBm
b3IgZXZlcnlvbmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy
aWY7IGNvbG9yOiAjMDAzMzY2OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+VGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgYW5kIGFueSBmaWxl
cyB0cmFuc21pdHRlZCB3aXRoIGl0IGNvbnRhaW5zPGJyPmluZm9ybWF0aW9uIGZyb20gaURpcmVj
dCwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5PGJyPmFuZC9vciBjb25maWRl
bnRpYWwuIEl0IGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh
bDxicj5vciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90
IHRoZSBvcmlnaW5hbDxicj5yZWNpcGllbnQgb3IgdGhlIHBlcnNvbiByZXNwb25zaWJsZSBmb3Ig
ZGVsaXZlcmluZyB0aGUgZW1haWwgdG8gdGhlPGJyPmludGVuZGVkIHJlY2lwaWVudCwgYmUgYWR2
aXNlZCB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWw8YnI+aW4gZXJyb3IsIGFuZCB0
aGF0IGFueSB1c2UsIGRpc3NlbWluYXRpb24sIGZvcndhcmRpbmcsIHByaW50aW5nLCBvcjxicj5j
b3B5aW5nIG9mIHRoaXMgZW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IHJlY2Vp
dmVkIHRoaXMgZW1haWw8YnI+aW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIGltbWVkaWF0
ZWx5IG5vdGlmeSB0aGUgc2VuZGVyLjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48L2JvZHk+DQo8L2h0bWw+DQo=

--_000_375aa29ea2a14f0d81d4d4de67222174VAUSDITCHM2idirectnet_--


From nobody Wed Apr 27 08:38: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 9360512D852 for ; Wed, 27 Apr 2016 08:38:06 -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 cb0uWaq7wtmZ for ; Wed, 27 Apr 2016 08:38:05 -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 02A8612D0AE for ; Wed, 27 Apr 2016 08:38:05 -0700 (PDT)
Received: by mail-ig0-x236.google.com with SMTP id m9so42465390ige.1 for ; Wed, 27 Apr 2016 08:38:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=RD3jGfMvfjjvClj0749HSsb/mIi1A5pt1eEgLWeJy3c=; b=JPBDKDVnM1NrYboptVUPpWgCr9w4InMMjeBfcF6BOrMElcv2Jq0m1ohUpCEkfEe+5j R86H2P9KN4jWNhojGFHel8QCM/FCvTxCVjMut74CDY4omWKu2Vvpst9z0cRFbTpyrk22 KAdI75lytD/WH5wlmLJDP4mRtv+Ttrg0dS+i4=
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:content-transfer-encoding; bh=RD3jGfMvfjjvClj0749HSsb/mIi1A5pt1eEgLWeJy3c=; b=PWAiF6DZ0ahxXf4ZHklayS/LP+0KMRr77Zeu+Y0oYz375SlvCWbBjeHvVaFFsn3BDX JvVUhAlyU2Hlhj+b6VxqVFpbn/7GkgDn48zMDsLVjwMq4CREulp0W33IF8dN1Y4AfKTU aRoBLwlq70mKDeEMHcDOTohC0AN1tp9d8q9IRx51rSPHeuUBsVoAdCgBvOrGa/8K5fRG f24lUXasMRjqBUpS+MS9M4aL/8oPPbBrSI5WbeIIPgqczFJHq4VtnDH1JAluEFaVszFt u7bfloE+ewWxEkaew2WVxU1MbYqBqruunESdNxVNs3SOOoTxJ6tw9RCxUhyoQw6st6QR emqA==
X-Gm-Message-State: AOPr4FViD0JjL15xsTx3xqekjJ1J8qEe46BLrhOWD2LCQmk6D0p74HUYHJRdDCPMcwwPBjhfX4oVokwL4N8zmw==
MIME-Version: 1.0
X-Received: by 10.50.4.9 with SMTP id g9mr27704090igg.35.1461771484311; Wed, 27 Apr 2016 08:38:04 -0700 (PDT)
Received: by 10.36.86.142 with HTTP; Wed, 27 Apr 2016 08:38:04 -0700 (PDT)
In-Reply-To: <375aa29ea2a14f0d81d4d4de67222174@VAUSDITCHM2.idirect.net>
References:  <375aa29ea2a14f0d81d4d4de67222174@VAUSDITCHM2.idirect.net>
Date: Wed, 27 Apr 2016 08:38:04 -0700
Message-ID: 
From: Ulrich Herberg 
To: "Ratliff, Stanley" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New interim meeting date/time
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, 27 Apr 2016 15:38:06 -0000

And for people on the West Coast? ;-)

Best regards
Ulrich

On Wed, Apr 27, 2016 at 8:35 AM, Ratliff, Stanley  wr=
ote:
> Justin,
>
>
>
> 10am GMT? As in 0600 East coast time?  It=E2=80=99s doable for me, but on=
ly if I
> start IV-coffee at around 0500=E2=80=A6. ;-)
>
>
>
> Regards,
>
> Stan
>
>
>
>
>
> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Justin Dean
> Sent: Wednesday, April 27, 2016 11:27 AM
> To: manet@ietf.org
> Subject: [manet] New interim meeting date/time
>
>
>
> How does 5/12/16 at 10am GMT work for everyone?
>
>
> _____________________________________________________
> This electronic message and any files transmitted with it contains
> information from iDirect, which may be privileged, proprietary
> and/or confidential. It is intended solely for the use of the individual
> or entity to whom they are addressed. If you are not the original
> recipient or the person responsible for delivering the email to the
> intended recipient, be advised that you have received this email
> in error, and that any use, dissemination, forwarding, printing, or
> copying of this email is strictly prohibited. If you received this email
> in error, please delete it and immediately notify the sender.
> _____________________________________________________
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>


From nobody Wed Apr 27 08:38:59 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 344D912D86E for ; Wed, 27 Apr 2016 08:38:57 -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_c3W-pTCFwd for ; Wed, 27 Apr 2016 08:38:55 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002: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 9A52D12D86C for ; Wed, 27 Apr 2016 08:38:55 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id o66so89772861ywc.3 for ; Wed, 27 Apr 2016 08:38:55 -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=LDQXizIJ/aYFgWHLegLrb+BavIRo14zLNagDcum7rdM=; b=pBAVzyHoTU3nbUJFkAbUexzwHpuautENDbY5MQUsbM+MYmGLUJHrqfTi8ZxX9esQ6Q sVJ8iDa8DU+wn4tQNDhU2L6rKS3v0o5td8rd3Ly6s5d0N9H+CzSEukj9EeNlzgVcM0uR HKKxICm5b2cgwqJ8P+KVRatlpddNzDdIWnMwUjzSpou5ZpqiiF3p/Sq6+ySozv4jmEe9 dEv3a9NQ0hXFvIU7qM4i2jcnEZrd9yYNjfCs84DwA8RxQ4YStzo8ELVnjV5BXLervfWf rfzWIgVDXjP2uJ9bUVjyhPgNNWRbrHYVYmV3gGTBZNmH9nzEBsSeclVEtkuzYBW4WgIX nt2Q==
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=LDQXizIJ/aYFgWHLegLrb+BavIRo14zLNagDcum7rdM=; b=Kt1fm/FJIWCjtYEGdqz7Ndla08UiMh4YMEQpglT4/bu5U/n1cj7/U8eVJF7wuNrTRG 61yBDYDk5I7uxA905fE8F8+WLnB88J1Jfkus9X2Zezf/WWO6zOPAySF4hIC0SRbieeOu 9w3Sm/iHrMd1Z/pAr0XhlrRF/Q2a2gf7IDibswON37WYk799PXwFuNL+tSP6cBnCdIe7 C71f9yUtyeIex75qkvpcUVPtGSeaZBdhRUFq10UOlPpKUIRT7OtLZMeGaJKqPEM6bhqy rIIHLCRxIvpE3A7bK5tn1DNzeUOdnjgxbWvlTu2itJK/cBd4A4TmEpArKzzPJomBxLow iPjg==
X-Gm-Message-State: AOPr4FXfy4Kock/fWJtibOSDv7pOs0QL2hMpG4NxehyziA7AP7RJb0SbE7xr3mMDhX7lc65RRm+/GL5ZwtnHag==
MIME-Version: 1.0
X-Received: by 10.176.65.133 with SMTP id 5mr4705871uap.29.1461771534829; Wed, 27 Apr 2016 08:38:54 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Wed, 27 Apr 2016 08:38:54 -0700 (PDT)
In-Reply-To: <375aa29ea2a14f0d81d4d4de67222174@VAUSDITCHM2.idirect.net>
References:  <375aa29ea2a14f0d81d4d4de67222174@VAUSDITCHM2.idirect.net>
Date: Wed, 27 Apr 2016 11:38:54 -0400
Message-ID: 
From: Justin Dean 
To: "Ratliff, Stanley" 
Content-Type: multipart/alternative; boundary=94eb2c093e42138ed10531793514
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New interim meeting date/time
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, 27 Apr 2016 15:38:57 -0000

--94eb2c093e42138ed10531793514
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Grrr getting all my letters mixed up.  10am EST!!!

On Wed, Apr 27, 2016 at 11:35 AM, Ratliff, Stanley 
wrote:

> Justin,
>
>
>
> 10am GMT? As in 0600 East coast time?  It=E2=80=99s doable for me, but on=
ly if I
> start IV-coffee at around 0500=E2=80=A6. ;-)
>
>
>
> Regards,
>
> Stan
>
>
>
>
>
> *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Justin Dean
> *Sent:* Wednesday, April 27, 2016 11:27 AM
> *To:* manet@ietf.org
> *Subject:* [manet] New interim meeting date/time
>
>
>
> How does 5/12/16 at 10am GMT work for everyone?
>
> _____________________________________________________
> This electronic message and any files transmitted with it contains
> information from iDirect, which may be privileged, proprietary
> and/or confidential. It is intended solely for the use of the individual
> or entity to whom they are addressed. If you are not the original
> recipient or the person responsible for delivering the email to the
> intended recipient, be advised that you have received this email
> in error, and that any use, dissemination, forwarding, printing, or
> copying of this email is strictly prohibited. If you received this email
> in error, please delete it and immediately notify the sender.
> _____________________________________________________
>

--94eb2c093e42138ed10531793514
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Grrr getting all my letters mixed up. =C2=A010am EST!!!

On Wed, Apr 27=
, 2016 at 11:35 AM, Ratliff, Stanley <sratliff@idirect.net> wrote:











Justin,



=C2=A0


10am GMT? As in 0600 East coast time?=
=C2=A0 It=E2=80=99s doable for me, but only if I start IV-coffee at around =
0500=E2=80=A6. ;-)



=C2=A0


Regards,


Stan


=C2=A0


=C2=A0








From: manet [mailto:manet-bounces@ietf.org]
On Behalf Of Justin Dean

Sent: Wednesday, April 27, 2016 11:27 AM

To: manet@ietf.o=
rg

Subject: [manet] New interim meeting date/time<=
/p>





=C2=A0




How does 5/12/16 at 10am GMT work for everyone?








_____________________________________________________
This electronic =
message and any files transmitted with it contains
information from iDir=
ect, which may be privileged, proprietary
and/or confidential. It is int=
ended solely for the use of the individual
or entity to whom they are ad=
dressed. If you are not the original
recipient or the person responsible=
 for delivering the email to the
intended recipient, be advised that you=
 have received this email
in error, and that any use, dissemination, for=
warding, printing, or
copying of this email is strictly prohibited. If y=
ou received this email
in error, please delete it and immediately notify=
 the sender.
_____________________________________________________






--94eb2c093e42138ed10531793514--


From nobody Wed Apr 27 08:39: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 9134012D864 for ; Wed, 27 Apr 2016 08:39:35 -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 xFQKsA7xcqHL for ; Wed, 27 Apr 2016 08:39:34 -0700 (PDT)
Received: from smtp2.idirect.net (smtp2.idirect.net [198.180.159.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 CBAFA12D86D for ; Wed, 27 Apr 2016 08:39:26 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,542,1454994000";  d="scan'208";a="1032970"
IronPort-PHdr: =?us-ascii?q?9a23=3A9caGLRBuGQjWdODfWC3VUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSP7zpMbcNUDSrc9gkEXOFd2CrakU26yG6eu5BCQp2tWojjMrSNR0TRgLiM?= =?us-ascii?q?EbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpQAbFhi3Dwdp?= =?us-ascii?q?POO9QteU1JTnkbDosMSOKyxzxxODIppKZC2sqgvQssREyaBDEY0WjiXzn31TZu?= =?us-ascii?q?5NznlpL1/A1zz158O34YIxu38I46Fp34d6XK77Z6U1S6BDRHRjajhtpZ6jiR6W?= =?us-ascii?q?cA+V53AcGkUbiBBFGQeNuAz+RJb6sgP6u/B31TOVe8v/SL1iChq46KI+AiXhlC?= =?us-ascii?q?MGOTB9uFrLg8p0gbMR6Ea6vRVjx4/abqmUOPtkc6jBO9UXWTwSDY5qSyVdD9bk?= =?us-ascii?q?PMM0BO0bMLMd9tGlqg=3D=3D?=
X-IPAS-Result: =?us-ascii?q?A2CXAQCz3CBX/8v6+gpeGQEBAQGDbn0GrgmLXQENgWgNFwu?= =?us-ascii?q?FbQIcgUoUAQEBAQEBAQGBC4ItghQBAQEBAwEBASAROgsMBAIBCBEEAQEBAgIjA?= =?us-ascii?q?wICAh8GCxQBCAgCBA4FCIgNAyCyc4xGDYRhAQEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BEQR8hSaESoJBgU4RATOCaYJWBY1UigssBQGMIIFvgW6ETYhdh1GHXx4BAYQtb?= =?us-ascii?q?Id5Nn8BAQE?=
From: "Ratliff, Stanley" 
To: Ulrich Herberg 
Thread-Topic: [manet] New interim meeting date/time
Thread-Index: AQHRoJlQqg+zZL1cm0+xtoDaMNXBJJ+d8xuggABEUwD//70SUA==
Date: Wed, 27 Apr 2016 15:39:23 +0000
Message-ID: 
References:  <375aa29ea2a14f0d81d4d4de67222174@VAUSDITCHM2.idirect.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.250.250.20]
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New interim meeting date/time
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, 27 Apr 2016 15:39:35 -0000

Oi0pICAgV2hhdCwgeW91J3JlIGJhbGtpbmcgYXQgYSAwMzAwICJwYXJ0eSI/Pz8/IDstKSA7LSkg
Oy0pIDstKSANCg0KUmVnYXJkcywNClN0YW4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQo+IEZyb206IFVscmljaCBIZXJiZXJnIFttYWlsdG86dWxyaWNoQGhlcmJlcmcubmFtZV0N
Cj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNywgMjAxNiAxMTozOCBBTQ0KPiBUbzogUmF0bGlm
ZiwgU3RhbmxleSA8c3JhdGxpZmZAaWRpcmVjdC5uZXQ+DQo+IENjOiBKdXN0aW4gRGVhbiA8YmVi
ZW1hc3RlckBnbWFpbC5jb20+OyBtYW5ldEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21hbmV0
XSBOZXcgaW50ZXJpbSBtZWV0aW5nIGRhdGUvdGltZQ0KPiANCj4gQW5kIGZvciBwZW9wbGUgb24g
dGhlIFdlc3QgQ29hc3Q/IDstKQ0KPiANCj4gQmVzdCByZWdhcmRzDQo+IFVscmljaA0KPiANCj4g
T24gV2VkLCBBcHIgMjcsIDIwMTYgYXQgODozNSBBTSwgUmF0bGlmZiwgU3RhbmxleSA8c3JhdGxp
ZmZAaWRpcmVjdC5uZXQ+DQo+IHdyb3RlOg0KPiA+IEp1c3RpbiwNCj4gPg0KPiA+DQo+ID4NCj4g
PiAxMGFtIEdNVD8gQXMgaW4gMDYwMCBFYXN0IGNvYXN0IHRpbWU/ICBJdOKAmXMgZG9hYmxlIGZv
ciBtZSwgYnV0IG9ubHkgaWYNCj4gPiBJIHN0YXJ0IElWLWNvZmZlZSBhdCBhcm91bmQgMDUwMOKA
pi4gOy0pDQo+ID4NCj4gPg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPg0KPiA+IFN0YW4NCj4gPg0K
PiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2Vz
QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIERlYW4NCj4gPiBTZW50OiBXZWRuZXNkYXks
IEFwcmlsIDI3LCAyMDE2IDExOjI3IEFNDQo+ID4gVG86IG1hbmV0QGlldGYub3JnDQo+ID4gU3Vi
amVjdDogW21hbmV0XSBOZXcgaW50ZXJpbSBtZWV0aW5nIGRhdGUvdGltZQ0KPiA+DQo+ID4NCj4g
Pg0KPiA+IEhvdyBkb2VzIDUvMTIvMTYgYXQgMTBhbSBHTVQgd29yayBmb3IgZXZlcnlvbmU/DQo+
ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+ID4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgYW5kIGFueSBmaWxlcyB0cmFu
c21pdHRlZCB3aXRoIGl0IGNvbnRhaW5zDQo+ID4gaW5mb3JtYXRpb24gZnJvbSBpRGlyZWN0LCB3
aGljaCBtYXkgYmUgcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnkgYW5kL29yDQo+ID4gY29uZmlkZW50
aWFsLiBJdCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg
b3INCj4gPiBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90
IHRoZSBvcmlnaW5hbA0KPiA+IHJlY2lwaWVudCBvciB0aGUgcGVyc29uIHJlc3BvbnNpYmxlIGZv
ciBkZWxpdmVyaW5nIHRoZSBlbWFpbCB0byB0aGUNCj4gPiBpbnRlbmRlZCByZWNpcGllbnQsIGJl
IGFkdmlzZWQgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluDQo+ID4gZXJyb3Is
IGFuZCB0aGF0IGFueSB1c2UsIGRpc3NlbWluYXRpb24sIGZvcndhcmRpbmcsIHByaW50aW5nLCBv
cg0KPiA+IGNvcHlpbmcgb2YgdGhpcyBlbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5
b3UgcmVjZWl2ZWQgdGhpcw0KPiA+IGVtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFu
ZCBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlci4NCj4gPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+DQo+ID4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBtYW5ldCBtYWlsaW5nIGxp
c3QNCj4gPiBtYW5ldEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vbWFuZXQNCj4gPg0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgYW5kIGFueSBmaWxl
cyB0cmFuc21pdHRlZCB3aXRoIGl0IGNvbnRhaW5zCmluZm9ybWF0aW9uIGZyb20gaURpcmVjdCwg
d2hpY2ggbWF5IGJlIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5CmFuZC9vciBjb25maWRlbnRpYWwu
IEl0IGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbApvciBl
bnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBvcmln
aW5hbApyZWNpcGllbnQgb3IgdGhlIHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0
aGUgZW1haWwgdG8gdGhlCmludGVuZGVkIHJlY2lwaWVudCwgYmUgYWR2aXNlZCB0aGF0IHlvdSBo
YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwKaW4gZXJyb3IsIGFuZCB0aGF0IGFueSB1c2UsIGRpc3Nl
bWluYXRpb24sIGZvcndhcmRpbmcsIHByaW50aW5nLCBvcgpjb3B5aW5nIG9mIHRoaXMgZW1haWwg
aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmVkIHRoaXMgZW1haWwKaW4gZXJy
b3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyLgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo=


From nobody Wed Apr 27 08:44:53 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 B582C12D891 for ; Wed, 27 Apr 2016 08:44:52 -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 SvJ3dAtqhXNl for ; Wed, 27 Apr 2016 08:44:49 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 474F312D88E for ; Wed, 27 Apr 2016 08:44:49 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id j74so79368822ywg.1 for ; Wed, 27 Apr 2016 08:44:49 -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=8Pa12+NeyYbP4movmcd68IS5EP2+Ec7s+2E/uvleepU=; b=pL466ygLAIZ6ybJtS53Tt+MsfzHw+5jy2Vl4wlzFTwSZ9GVGEvXIjSEOFaM1jIjr68 gFpAxqnZ2jipAc/2ESl1bJ1km8+oUJp9ekI0KXpd6YCgbkz/38RmTrm0QrpJMZ5MX41l pDZ7Yql55RWyK/uiClH661U5A31GmOWfgiow+wYIhdjWo29X9LKK13CHU93PqRce4c97 0QZdAQWqAcaeHIe7jPXYCMbqgvpMkE/0N7yZsnu1qMmBzqR+dXcQvFMDEtmv4kPgOOaZ HqgQB+oDMk7U/vpGF78c5ORGL9+/U34l5vctBRg85BNNV+e5k1zt7jn7WNRuYG0d5md6 GXaQ==
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=8Pa12+NeyYbP4movmcd68IS5EP2+Ec7s+2E/uvleepU=; b=XsGpupgAls322tj2ik6UXw7eGbssAwa4/auEC2pryEd9L49DDwBRQ35gpxWLBOHTow bvCPQmNyr9QNKXyQi5usep9FF60oO2RFRIiskKUtyPm1SVtQVh+K9WNSvCilAXDnjLj/ bVmKP3y+hH79LzL67c37Ub3ROBK9WC1HI9EfIuwhqnYfYDRNlSPUohI+VvTU4AjHSNO5 AEE7u4hqzkYRlh98H+3dvclGimOZd70/pIeb4T6RunSvAV5kFna9kPt9M7h/GujD4Bl9 KdNv2KJpGG7lfbC8T0S43nwkaVkYdiPNvQIZd2nVDFwPtOM8b5ESY1qsCCjLodT/VnpK 51wA==
X-Gm-Message-State: AOPr4FXlYg0JOFJ+EZ01XCBVSq44YdV/uUP8LiJ9CTGOmk64Ma5Rb73oXY+Uky4LrAQmzWs+EspDUFCvQbCaog==
MIME-Version: 1.0
X-Received: by 10.176.1.108 with SMTP id 99mr4941886uak.54.1461771888296; Wed, 27 Apr 2016 08:44:48 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Wed, 27 Apr 2016 08:44:48 -0700 (PDT)
In-Reply-To: 
References:      <82679804-2647-4913-ACF3-18E4FFF731A8@thomasclausen.org> 
Date: Wed, 27 Apr 2016 11:44:48 -0400
Message-ID: 
From: Justin Dean 
To: "Dearlove, Christopher (UK)" 
Content-Type: multipart/alternative; boundary=001a113d0cd42537640531794afe
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, 27 Apr 2016 15:44:53 -0000

--001a113d0cd42537640531794afe
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 invite
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 bring
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 issue 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 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.

>
>
> *-- *
>
>
>
>
> *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
>
>
>

--001a113d0cd42537640531794afe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




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 telecon and cut out list.


I a=
gree.=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 contribut=
ors. Many who have contributed have dropped away. And those who have been m=
ain creators of WG RFCs (looking at statistics, Clausen
 and Dearlove in particular, but also others - but not a lot of others, esp=
ecially after the first batch of Experimental RFCs) may or may not be contr=
ibuting.


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 la=
rger/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 intereste=
d in hasn't brought a lot of discussion on this list but it very well m=
ay bring a lot of interest from the larger ietf community.=C2=A0
=
=C2=A0
- But even more importantly we nee=
d 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 is short on companies a=
dvertising they are using it - I wish some would (I=E2=80=99m told they exi=
st, but couldn=E2=80=99t name any). AODVv2 (which may or may not be in scop=
e) appears not to have even up to date experimental
 code (please correct if wrong).


- Hence although we may have some great idea=
s, it=E2=80=99s not yet clear people want them and we can deliver - DLEP ma=
intenance being I think closest to contradicting
 that, at least publicly.
Well I KN=
OW 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 th=
ere are enough people willing to contribute and engineer a solution to an i=
ssue that needs solving.


=C2=A0=C2=A0


There is the horrible warning of Autoconf th=
at 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 tha=
t means a small team of actual authors, plus wider input.
<=
/div>
=C2=A0


Incidentally the autoconf problem is still r=
eal, but was too narrow. That was considering address autoconfiguration (th=
ough the WG never actually got 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 assig=
nment, identity assignment/management, cryptographic key management, and ot=
her 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 sol=
ve to broad a problem.=C2=A0 There were demonstratable solutions to very sp=
ecific problems (e.g. multihop DHCP) but then there were more exotic soluti=
ons 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 De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44 (0)1245 242194<=
/a> =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 Intelligence 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 organisation, either f=
rom an external partner or the internet.

Consider carefully whether=
 you should click on any links, open any attachments or reply.<=
br>
For information regarding =

Red Flags that you =
can look out for in emails you receive,
 click 
here.

If you feel the email is s=
uspicious, please follow

this process.











***
WARNING
***<=
br>
EXTERNAL=
 EMAIL -- This message originates from outside our organization.<=
/u>




=C2=A0








=C2=A0







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 s=
ubsequent meetings) - until this present
 "urgency" was declared (by the chairs) to the WG.<=
/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 th=
ose things, before a (virtual) interim is
 called. Brainstorming on a teleconference is rarely a constructive way to =
spend time












=C2=A0






=C2=A0






Thomas

















To your point it's imparative that the discussio=
n continues on list about the charter.=C2=A0 With that in mind here is a su=
ggested edit of the previously floated charter, with comments in () with JW=
D 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.<=
u>


=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)<=
u>


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 partic=
ipation, 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 th=
e 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.

















Best,

















Thomas






=C2=A0










Sent from my iPad










=C2=A0




On 22 Apr 2016, at 17:5=
0, 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 p=
ossible approaches, time to discuss.


=C2=A0


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


=C2=A0


Management we did of course have an NHDP/OLS=
Rv2 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 IPR declaration to s=
ay 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 there are various thi=
ngs 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 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


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 organisation, either f=
rom an external partner or the internet.

Consider carefully whether=
 you should click on any links, open any attachments or reply.<=
br>
For information regarding =

Red Flags that you =
can look out for in emails you receive,
 click 
here.

If you feel the email is s=
uspicious, please follow

this process.











***
WARNING
***<=
br>
EXTERNAL=
 EMAIL -- This message originates from outside our organization.<=
/u>




=C2=A0






I'll start things o=
ff 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


















--001a113d0cd42537640531794afe--


From nobody Wed Apr 27 09:23: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 DBA2612D0AD for ; Wed, 27 Apr 2016 09:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.915
X-Spam-Level: 
X-Spam-Status: No, score=-7.915 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] 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 Lso198LWNIVc for ; Wed, 27 Apr 2016 09:23:07 -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 4671012B040 for ; Wed, 27 Apr 2016 09:23:06 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,542,1454976000"; d="scan'208,217"; a="64843882"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 27 Apr 2016 17:23:04 +0100
X-IronPort-AV: E=Sophos;i="5.24,542,1454976000";  d="scan'208,217";a="115784213"
Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 27 Apr 2016 17:23:05 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.34]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 17:23:04 +0100
From: "Dearlove, Christopher (UK)" 
To: Justin Dean , "manet@ietf.org" 
Thread-Topic: [manet] New interim meeting date/time
Thread-Index: AQHRoJlXqUxdpEGzE0GaUKb3ryC4o5+d/vuw
Date: Wed, 27 Apr 2016 16:23:03 +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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1E49GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [manet] New interim meeting date/time
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, 27 Apr 2016 16:23:10 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1E49GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

VW5mb3J0dW5hdGVseSB0aGF0IGV4YWN0bHkgaGl0cyBhbm90aGVyIHRlbGVjb24gSSBtaWdodCBi
ZSBpbi4gU28gSSBtYXkgb3IgbWF5IG5vdCBiZSBhYmxlIHRvIG1ha2UgaXQgKHB1dHRpbmcgYXNp
ZGUgb3RoZXIgcmVhc29ucyBJIG1pZ2h0IG5vdCkuDQoNCkJ1dCB0aGF04oCZcyBqdXN0IHVuZm9y
dHVuYXRlLCBpdOKAmXMgYSBwZXJmZWN0bHkgcmVhc29uYWJsZSB0aW1lIGhlcmUuDQoNCkhvd2V2
ZXIgSSB0aGluayBzdWNoIGEgdGVsZWNvbiBtaWdodCBiZSBhYmxlIHRvIHJlZmluZSBzb21lIGRl
dGFpbHMuIEJ1dCB3aGF04oCZcyByZWFsbHkgbmVlZGVkIGlzIHBlb3BsZSB3aG8gYXJlIHVubGlr
ZWx5IHRvIGJlIGluIGl0LCBhcyBlYXJsaWVyIGNvbW1lbnRzLg0KDQooVGhhdCBpcyBvZiBjb3Vy
c2UgaWdub3JpbmcgdGhhdCBpbiB0aGUgcGFydHMgb2YgdGhlIHdvcmxkIHdpdGggbW9yZSBzZW5z
aWJsZSBkYXRlIGNvbnZlbnRpb25zLCA1LzEyLzE2IGlzIGluIERlY2VtYmVyLiBQZW9wbGUgd2l0
aCBldmVuIGJldHRlciBjb252ZW50aW9ucyBtaWdodCBhcmd1ZSBpdCBtZWFucyBEZWNlbWJlciBl
bGV2ZW4geWVhcnMgYWdvLikNCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJp
bmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0
b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6
IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVz
eXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2Zv
cmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4
SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4N
CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4g
RW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBS
ZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBtYW5ldCBb
bWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gRGVhbg0K
U2VudDogMjcgQXByaWwgMjAxNiAxNjoyNw0KVG86IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBb
bWFuZXRdIE5ldyBpbnRlcmltIG1lZXRpbmcgZGF0ZS90aW1lDQoNCg0KKioqIFdBUk5JTkcgKioq
DQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwg
ZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRl
ciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBh
bnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBG
bGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xp
Y2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1
cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwg
dGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6
Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdo
dHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0K
KioqIFdBUk5JTkcgKioqDQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRl
cyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbi4NCg0KSG93IGRvZXMgNS8xMi8xNiBhdCAx
MGFtIEdNVCB3b3JrIGZvciBldmVyeW9uZT8NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqClRoaXMgZW1haWwgYW5kIGFu
eSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQg
YW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApy
ZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhl
IHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3Nl
IG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVy
c29uLgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKgo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1E49GLKXM0002VGREEN_
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
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K
ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h
eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9
IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k
eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX
b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlVuZm9ydHVuYXRlbHkgdGhhdCBleGFjdGx5IGhpdHMgYW5v
dGhlciB0ZWxlY29uIEkgbWlnaHQgYmUgaW4uIFNvIEkgbWF5IG9yIG1heSBub3QgYmUgYWJsZSB0
byBtYWtlIGl0IChwdXR0aW5nIGFzaWRlIG90aGVyIHJlYXNvbnMgSSBtaWdodCBub3QpLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+QnV0IHRoYXTigJlzIGp1c3QgdW5mb3J0dW5hdGUsIGl04oCZcyBhIHBlcmZlY3RseSBy
ZWFzb25hYmxlIHRpbWUgaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIgSSB0aGluayBzdWNoIGEgdGVs
ZWNvbiBtaWdodCBiZSBhYmxlIHRvIHJlZmluZSBzb21lIGRldGFpbHMuIEJ1dCB3aGF04oCZcyBy
ZWFsbHkgbmVlZGVkIGlzIHBlb3BsZSB3aG8gYXJlIHVubGlrZWx5IHRvIGJlIGluIGl0LCBhcyBl
YXJsaWVyIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KFRoYXQgaXMgb2YgY291cnNlIGlnbm9yaW5nIHRo
YXQgaW4gdGhlIHBhcnRzIG9mIHRoZSB3b3JsZCB3aXRoIG1vcmUgc2Vuc2libGUgZGF0ZSBjb252
ZW50aW9ucywgNS8xMi8xNiBpcyBpbiBEZWNlbWJlci4gUGVvcGxlIHdpdGggZXZlbiBiZXR0ZXIg
Y29udmVudGlvbnMNCiBtaWdodCBhcmd1ZSBpdCBtZWFucyBEZWNlbWJlciBlbGV2ZW4geWVhcnMg
YWdvLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8bzpwPjwv
bzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0Ui
PkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4N
CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bh
bj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdE
N0QiPjogJm5ic3A7JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8ICZuYnNwOzxiPkU6DQo8
L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5k
ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxt
c2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENN
MiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl
IExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3
NDUxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5
MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1
cnJleSwgR1UyIDdZUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0
Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBEZWFuPGJyPg0KPGI+U2VudDo8L2I+
IDI3IEFwcmlsIDIwMTYgMTY6Mjc8YnI+DQo8Yj5Ubzo8L2I+IG1hbmV0QGlldGYub3JnPGJyPg0K
PGI+U3ViamVjdDo8L2I+IFttYW5ldF0gTmV3IGludGVyaW0gbWVldGluZyBkYXRlL3RpbWU8bzpw
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+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQg
d2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjEuMHB0IDQuMHB0IDEuMHB0IDQuMHB0Ij4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+KjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPioqDQo8L3NwYW4+PC9zdHJvbmc+PC9zcGFuPjxzdHJv
bmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V0FSTklORw0KPC9zcGFuPjwvc3Ryb25nPjxz
dHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPioqKjwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5FWFRFUk5BTCBFTUFJ
TCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlv
bjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi48L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IGRvZXMgNS8xMi8xNiBhdCAxMGFt
IEdNVCB3b3JrIGZvciBldmVyeW9uZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
cD4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKjxicj4KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m
aWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHBy
aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4KcmVjaXBpZW50IHBsZWFz
ZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPgpZ
b3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Ns
b3NlIG9yPGJyPgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxi
cj4KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKio8L3A+PC9ib2R5Pg0KPC9odG1sPg0K

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1E49GLKXM0002VGREEN_--


From nobody Wed Apr 27 09:26: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 EB92212D87C for ; Wed, 27 Apr 2016 09:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.915
X-Spam-Level: 
X-Spam-Status: No, score=-7.915 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] 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 CyZo524KTqB8 for ; Wed, 27 Apr 2016 09:26:03 -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 DC79D12D872 for ; Wed, 27 Apr 2016 09:26:02 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,542,1454976000"; d="scan'208,217"; a="64844753"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 27 Apr 2016 17:26:01 +0100
X-IronPort-AV: E=Sophos;i="5.24,542,1454976000";  d="scan'208,217";a="115784599"
Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 27 Apr 2016 17:26:02 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.34]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 17:26:01 +0100
From: "Dearlove, Christopher (UK)" 
To: Justin Dean , "Ratliff, Stanley" 
Thread-Topic: [manet] New interim meeting date/time
Thread-Index: AQHRoJlXqUxdpEGzE0GaUKb3ryC4o5+d4uaAgAAA8gCAAB1fEA==
Date: Wed, 27 Apr 2016 16:26:00 +0000
Message-ID: 
References:  <375aa29ea2a14f0d81d4d4de67222174@VAUSDITCHM2.idirect.net> 
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1E63GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New interim meeting date/time
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, 27 Apr 2016 16:26:09 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1E63GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

T0suIDEwIEVTVCBpcyAxNSBVVEMgSSBiZWxpZXZlLiBUaGF04oCZcyB0aGUgYmVzdCB0aGluZyB0
byBxdW90ZS4gU28gMTYgbG9jYWwgaGVyZSAod2XigJlyZSBvbiBzdW1tZXIgVVRDKzEgLSB0aG91
Z2ggdGhlIHdlYXRoZXIgaGFzbuKAmXQgdGFrZW4gdGhlIGhpbnQpLg0KDQpUaGF0IEkgaGF2ZSBu
byBjbGFzaCB3aXRoLiBQdXQgbWUgZG93biBhcyBhIDUwLTUwIG9uIGpvaW5pbmcuDQoNCi0tDQpD
aHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3Rl
bXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
DQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z
LmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1z
IEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQg
QmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2Fp
PGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs
bGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0
NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBT
dXJyZXksIEdVMiA3WVANCg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYu
b3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIERlYW4NClNlbnQ6IDI3IEFwcmlsIDIwMTYgMTY6MzkN
ClRvOiBSYXRsaWZmLCBTdGFubGV5DQpDYzogbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb
bWFuZXRdIE5ldyBpbnRlcmltIG1lZXRpbmcgZGF0ZS90aW1lDQoNCg0KKioqIFdBUk5JTkcgKioq
DQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwg
ZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRl
ciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBh
bnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBG
bGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xp
Y2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1
cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwg
dGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6
Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdo
dHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0K
KioqIFdBUk5JTkcgKioqDQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRl
cyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbi4NCg0KR3JyciBnZXR0aW5nIGFsbCBteSBs
ZXR0ZXJzIG1peGVkIHVwLiAgMTBhbSBFU1QhISENCg0KT24gV2VkLCBBcHIgMjcsIDIwMTYgYXQg
MTE6MzUgQU0sIFJhdGxpZmYsIFN0YW5sZXkgPHNyYXRsaWZmQGlkaXJlY3QubmV0PG1haWx0bzpz
cmF0bGlmZkBpZGlyZWN0Lm5ldD4+IHdyb3RlOg0KSnVzdGluLA0KDQoxMGFtIEdNVD8gQXMgaW4g
MDYwMCBFYXN0IGNvYXN0IHRpbWU/ICBJdOKAmXMgZG9hYmxlIGZvciBtZSwgYnV0IG9ubHkgaWYg
SSBzdGFydCBJVi1jb2ZmZWUgYXQgYXJvdW5kIDA1MDDigKYuIDstKQ0KDQpSZWdhcmRzLA0KU3Rh
bg0KDQoNCkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86
bWFuZXQtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKdXN0aW4gRGVhbg0KU2VudDog
V2VkbmVzZGF5LCBBcHJpbCAyNywgMjAxNiAxMToyNyBBTQ0KVG86IG1hbmV0QGlldGYub3JnPG1h
aWx0bzptYW5ldEBpZXRmLm9yZz4NClN1YmplY3Q6IFttYW5ldF0gTmV3IGludGVyaW0gbWVldGlu
ZyBkYXRlL3RpbWUNCg0KSG93IGRvZXMgNS8xMi8xNiBhdCAxMGFtIEdNVCB3b3JrIGZvciBldmVy
eW9uZT8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg
d2l0aCBpdCBjb250YWlucw0KaW5mb3JtYXRpb24gZnJvbSBpRGlyZWN0LCB3aGljaCBtYXkgYmUg
cHJpdmlsZWdlZCwgcHJvcHJpZXRhcnkNCmFuZC9vciBjb25maWRlbnRpYWwuIEl0IGlzIGludGVu
ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbA0Kb3IgZW50aXR5IHRvIHdo
b20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgb3JpZ2luYWwNCnJlY2lw
aWVudCBvciB0aGUgcGVyc29uIHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIHRoZSBlbWFpbCB0
byB0aGUNCmludGVuZGVkIHJlY2lwaWVudCwgYmUgYWR2aXNlZCB0aGF0IHlvdSBoYXZlIHJlY2Vp
dmVkIHRoaXMgZW1haWwNCmluIGVycm9yLCBhbmQgdGhhdCBhbnkgdXNlLCBkaXNzZW1pbmF0aW9u
LCBmb3J3YXJkaW5nLCBwcmludGluZywgb3INCmNvcHlpbmcgb2YgdGhpcyBlbWFpbCBpcyBzdHJp
Y3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBlbWFpbA0KaW4gZXJyb3IsIHBs
ZWFzZSBkZWxldGUgaXQgYW5kIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyLg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioKVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8g
dGhlIGludGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91
IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91
ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9y
IHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNv
bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg==

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1E63GLKXM0002VGREEN_
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
ZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFy
ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0
IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+T0suIDEwIEVTVCBpcyAxNSBVVEMgSSBiZWxpZXZlLiBUaGF04oCZcyB0
aGUgYmVzdCB0aGluZyB0byBxdW90ZS4gU28gMTYgbG9jYWwgaGVyZSAod2XigJlyZSBvbiBzdW1t
ZXIgVVRDJiM0MzsxIC0gdGhvdWdoIHRoZSB3ZWF0aGVyIGhhc27igJl0IHRha2VuIHRoZSBoaW50
KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPlRoYXQgSSBoYXZlIG5vIGNsYXNoIHdpdGguIFB1dCBtZSBkb3duIGFzIGEg
NTAtNTAgb24gam9pbmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0Ui
Pi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMwMDdFN0UiPkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBF
bmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmll
czxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVC
RUJFIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8ICZu
YnNwOzxiPkU6DQo8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu
Y29tIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxp
Z2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2Zv
cmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNv
bS9haSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwv
c3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQg
SW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2Fs
ZXMgTm86IDAxMzM3NDUxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBH
dWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtYW5ldCBbbWFpbHRvOm1hbmV0
LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBEZWFuPGJyPg0K
PGI+U2VudDo8L2I+IDI3IEFwcmlsIDIwMTYgMTY6Mzk8YnI+DQo8Yj5Ubzo8L2I+IFJhdGxpZmYs
IFN0YW5sZXk8YnI+DQo8Yj5DYzo8L2I+IG1hbmV0QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8
L2I+IFJlOiBbbWFuZXRdIE5ldyBpbnRlcmltIG1lZXRpbmcgZGF0ZS90aW1lPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAy
LjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i
dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0
ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklO
RyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3Rl
eHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRz
aWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3Ig
dGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhl
ciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3Ig
cmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVn
YXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9v
ayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8v
aW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRz
L0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBo
cmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0
eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFp
bHMucGRmIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdpbmRvd3Rl
eHQgMS4wcHQ7cGFkZGluZzoxLjBwdCA0LjBwdCAxLjBwdCA0LjBwdCI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50ZXIiPg0KPHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPio8
c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij4qKg0KPC9zcGFuPjwvc3Ryb25nPjwvc3Bhbj48c3Ryb25nPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPldBUk5JTkcNCjwvc3Bhbj48L3N0cm9uZz48c3Ryb25nPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4qKio8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+
DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RVhURVJOQUwgRU1BSUwgLS0gVGhp
cyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb248L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdycnIgZ2V0dGluZyBhbGwgbXkgbGV0dGVycyBtaXhl
ZCB1cC4gJm5ic3A7MTBhbSBFU1QhISE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk9uIFdlZCwgQXByIDI3LCAyMDE2IGF0IDExOjM1IEFNLCBSYXRsaWZmLCBT
dGFubGV5ICZsdDs8YSBocmVmPSJtYWlsdG86c3JhdGxpZmZAaWRpcmVjdC5uZXQiIHRhcmdldD0i
X2JsYW5rIj5zcmF0bGlmZkBpZGlyZWN0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SnVzdGluLA0KPC9zcGFuPjxz
cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MTBhbSBHTVQ/IEFzIGluIDA2MDAgRWFzdCBjb2Fz
dCB0aW1lPyZuYnNwOyBJdOKAmXMgZG9hYmxlIGZvciBtZSwgYnV0IG9ubHkgaWYgSSBzdGFydCBJ
Vi1jb2ZmZWUNCiBhdCBhcm91bmQgMDUwMOKApi4gOy0pIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V
UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv
c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U3Rhbjwvc3Bhbj48c3BhbiBsYW5n
PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu
YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48
L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s
aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz
LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiBtYW5ldCBbbWFpbHRvOjxhIGhyZWY9
Im1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXQtYm91
bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBEZWFuPGJyPg0K
PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMjcsIDIwMTYgMTE6MjcgQU08YnI+DQo8Yj5U
bzo8L2I+IDxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1h
bmV0QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbbWFuZXRdIE5ldyBpbnRlcmlt
IG1lZXRpbmcgZGF0ZS90aW1lPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs
YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkhvdyBkb2VzIDUvMTIvMTYgYXQgMTBh
bSBHTVQgd29yayBmb3IgZXZlcnlvbmU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxi
cj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw
MDMzNjYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPGJyPg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRl
ZCB3aXRoIGl0IGNvbnRhaW5zPGJyPg0KaW5mb3JtYXRpb24gZnJvbSBpRGlyZWN0LCB3aGljaCBt
YXkgYmUgcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnk8YnI+DQphbmQvb3IgY29uZmlkZW50aWFsLiBJ
dCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWw8YnI+DQpv
ciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBv
cmlnaW5hbDxicj4NCnJlY2lwaWVudCBvciB0aGUgcGVyc29uIHJlc3BvbnNpYmxlIGZvciBkZWxp
dmVyaW5nIHRoZSBlbWFpbCB0byB0aGU8YnI+DQppbnRlbmRlZCByZWNpcGllbnQsIGJlIGFkdmlz
ZWQgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsPGJyPg0KaW4gZXJyb3IsIGFuZCB0
aGF0IGFueSB1c2UsIGRpc3NlbWluYXRpb24sIGZvcndhcmRpbmcsIHByaW50aW5nLCBvcjxicj4N
CmNvcHlpbmcgb2YgdGhpcyBlbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgcmVj
ZWl2ZWQgdGhpcyBlbWFpbDxicj4NCmluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBpbW1l
ZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlci48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwPioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJy
PgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUg
aW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91
IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9t
IHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+CllvdSBzaG91bGQgbm90IGNv
cHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+CmRpc3Ry
aWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uPGJyPgoqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwv
cD48L2JvZHk+DQo8L2h0bWw+DQo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1E63GLKXM0002VGREEN_--


From nobody Wed Apr 27 09:32: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 9C86712B040 for ; Wed, 27 Apr 2016 09:32:53 -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 Gdto54b2OA1G for ; Wed, 27 Apr 2016 09:32:52 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 9112012D876 for ; Wed, 27 Apr 2016 09:32:51 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id u64so56158449lff.3 for ; Wed, 27 Apr 2016 09:32: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:from:date:message-id:subject:to :cc; bh=ODpVQkqAitIGe3pPM1ilPw8MhRqpPgdeKDqABKMP8U8=; b=MrcIOkV/SUEh0TwoSKFlXzZ/qG+C9s+L/6ISZtU4dQSIo2K3SyTkNAl1bBW+C/Eph4 /hcJxrKgy8BChjLBKkyO4/1rmYdiOaPPFx7QGcDkPqyL03vnXGOwMa2sD0mQ5RT9ElBp eNS4nJpYKegcBiF4NrPYlEy5eK0kWPchPNZoukVMn79SeyFQi46mqKJqAP91/86jrszw YmIMYM5wAZ3DRgVIyq1TN6+39TccjE+pdFdQLzamfCl4sumgdY/ndd/399kcrQpT3Ucc DAtibj6lDIh+Nhn9I9xxRLHUUx6G9nXW4fT3Db23OF8Xy6nib4QB+d8/CpvQnXv8ZO/D JPMw==
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=ODpVQkqAitIGe3pPM1ilPw8MhRqpPgdeKDqABKMP8U8=; b=kK1z1LWCW29vlR3DUrE2KwXWTHLDtP8N6cnIZpnQQK61pfkxMAXM5nuAO2qWQ1Eoe7 r4oKK70Ifn4dk1N40w14ScnENrv+JPc/cXgh/61J/NLq/VPB4fvpbUM6JfuqcrHbsdCj SBqxJXApSnOtdm91M5qfBnBAHgXhvyWdzJlLuGUi+HUScPW5OvzoC52azwEiNA4lpZlf mxwT84WWnVj6iD/XPUTBtwJonidJ8ACWXgnpTIOBcPMyRN7aOAz2c4LP1zoXDZwYLRql Xmdw7NilaI2QMOZYcv/YSN6e839hnxkZrcFeZ7XbpRiUHlIO3kpOasP3qALWISYIZQKf 5hvw==
X-Gm-Message-State: AOPr4FVRHFA1stydmNs40BxseJ5+wS7VSlIpz0V6Lw8lz/UWg40W9baO2S0NTYIbItjw0ac7T5YlclCBDDOyuw==
X-Received: by 10.25.142.207 with SMTP id q198mr4189913lfd.12.1461774769820; Wed, 27 Apr 2016 09:32:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.24.42 with HTTP; Wed, 27 Apr 2016 09:32:20 -0700 (PDT)
In-Reply-To: 
References: 
From: Henning Rogge 
Date: Wed, 27 Apr 2016 18:32:20 +0200
Message-ID: 
To: Justin Dean 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] New interim meeting date/time
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, 27 Apr 2016 16:32:53 -0000

On Wed, Apr 27, 2016 at 5:27 PM, Justin Dean  wrote:
> How does 5/12/16 at 10am GMT work for everyone?

We have an important project meeting on 10th to 12th May, so this
doesn't work for me.

Henning


From nobody Wed Apr 27 09:35:32 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 042B912D8D7 for ; Wed, 27 Apr 2016 09:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.915
X-Spam-Level: 
X-Spam-Status: No, score=-7.915 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] 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 T89YN6x_sPXb for ; Wed, 27 Apr 2016 09:35:27 -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 4036812D8CC for ; Wed, 27 Apr 2016 09:35:25 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,542,1454976000"; d="scan'208,217"; a="64847549"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 27 Apr 2016 17:35:24 +0100
X-IronPort-AV: E=Sophos;i="5.24,542,1454976000";  d="scan'208,217";a="115785582"
Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 27 Apr 2016 17:35:25 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.34]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 17:35:24 +0100
From: "Dearlove, Christopher (UK)" 
To: Justin Dean 
Thread-Topic: [manet] Recharter Discussion
Thread-Index: AQHRnKi1tIqGPmFeIkW1v/uroMSbLJ+WICEg///zOgCABnzxAIAAGCgAgAAK5ICAAOMAoIAAVwgAgAAeS5A=
Date: Wed, 27 Apr 2016 16:35:23 +0000
Message-ID: 
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: 
x-originating-ip: [10.109.62.6]
Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1E8DGLKXM0002VGREEN_"
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, 27 Apr 2016 16:35:31 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1E8DGLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

T0ssIHlvdSBrbm93IHRoZXJlIGFyZSBzb21lIHBlb3BsZSBhdCBOUkwuIEdvb2QuIEJ1dCBzdGls
bCBxdWl0ZSBhIHdheSBzaG9ydCBvZiB3aGF0IHdlIHJlYWxseSBuZWVkIGluIHRlcm1zIG9mIGJ1
eS1pbi4gKEnigJltIGFzc3VtaW5nIHRoZSBwZW9wbGUgYXQgTlJMIGFyZSByZXByZXNlbnRlZCBi
eSB5b3UgYW5kL29yIEJyaWFuLCBhcyBvdGhlcndpc2UgZXZlbiB0aGV5IGFyZW7igJl0IHNob3dp
bmcgdXAuKQ0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5n
aW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hyaXMuZGVh
cmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t
Pg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9s
b2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5i
YWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3Rl
bXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYg
V2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBh
cmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IEp1c3RpbiBEZWFuIFttYWls
dG86YmViZW1hc3RlckBnbWFpbC5jb21dDQpTZW50OiAyNyBBcHJpbCAyMDE2IDE2OjQ1DQpUbzog
RGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNCkNjOiBUaG9tYXMgSGVpZGUgQ2xhdXNlbjsgbWFu
ZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFJlY2hhcnRlciBEaXNjdXNzaW9uDQoN
Cg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUg
b3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUg
aW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9u
IGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRp
b24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWls
cyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMu
Y29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5w
ZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cg
dGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3Jr
L3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91
cyUyMEVtYWlscy5wZGY+Lg0KDQoNCk9uIFdlZCwgQXByIDI3LCAyMDE2IGF0IDU6NTYgQU0sIERl
YXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxt
YWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PiB3cm90ZToNClRoZSBrZXkgcG9p
bnRzIGFzIEkgc2VlIGl0IGFyZToNCi0gV2Ugc2hvdWxkbuKAmXQgd2FpdCBmb3IgdGVsZWNvbiwg
YW5kIGNhbuKAmXQgcmVseSBvbiB0ZWxlY29uIGFuZCBjdXQgb3V0IGxpc3QuDQpJIGFncmVlLiAg
V2Ugc2hvdWxkbid0IHdhaXQgZm9yIHRoZSB0ZWxlY29uLiAgSSdsbCBjb250aW51ZSB0byBlbmdh
Z2UgZXZlcnlvbmUgb24gdGhpcyBsaXN0IGFib3V0IHdoYXQgcGVvcGxlIGFyZSB3aWxsaW5nIHRv
IHdvcmsgb24uDQoNCi0gV2UgYXJlIHZlcnkgc2hvcnQgb2YgY29udHJpYnV0b3JzLiBNYW55IHdo
byBoYXZlIGNvbnRyaWJ1dGVkIGhhdmUgZHJvcHBlZCBhd2F5LiBBbmQgdGhvc2Ugd2hvIGhhdmUg
YmVlbiBtYWluIGNyZWF0b3JzIG9mIFdHIFJGQ3MgKGxvb2tpbmcgYXQgc3RhdGlzdGljcywgQ2xh
dXNlbiBhbmQgRGVhcmxvdmUgaW4gcGFydGljdWxhciwgYnV0IGFsc28gb3RoZXJzIC0gYnV0IG5v
dCBhIGxvdCBvZiBvdGhlcnMsIGVzcGVjaWFsbHkgYWZ0ZXIgdGhlIGZpcnN0IGJhdGNoIG9mIEV4
cGVyaW1lbnRhbCBSRkNzKSBtYXkgb3IgbWF5IG5vdCBiZSBjb250cmlidXRpbmcuDQpXZSBhcmUg
c2hvcnQgY29udHJpYnV0b3JzIGFuZCB3ZSBtYXkgYmUgYWJsZSB0byBnZXQgbW9yZSBieSBmb2N1
c2luZyB0aGUgZ3JvdXAgb24gc3BlY2lmaWMgaXNzdWVzIGFuZCBwb3NzaWJseSBjcmVhdGluZyBu
ZXcgZm9jdXNlZCBncm91cHMgdG8gaW52aXRlIGEgbGFyZ2VyL3dpZGVyIElFVEYgaW52b2x2ZW1l
bnQuICBTZWN1cml0eSBiZWluZyB0aGUgb25lIGNvbWluZyB0byBtaW5kLiAgWW91ciBtZW50aW9u
IG9uIHRoZSBsaXN0IGFib3V0IHNlY3VyaXR5IHN0dWZmIHRoYXQgeW91IGFyZSBpbnRlcmVzdGVk
IGluIGhhc24ndCBicm91Z2h0IGEgbG90IG9mIGRpc2N1c3Npb24gb24gdGhpcyBsaXN0IGJ1dCBp
dCB2ZXJ5IHdlbGwgbWF5IGJyaW5nIGEgbG90IG9mIGludGVyZXN0IGZyb20gdGhlIGxhcmdlciBp
ZXRmIGNvbW11bml0eS4NCg0KLSBCdXQgZXZlbiBtb3JlIGltcG9ydGFudGx5IHdlIG5lZWQgcmVh
bCBwZW9wbGUgKHByZWZlcmFibHkgY29tcGFuaWVzIHdpdGggcHJvZHVjdHMpIHVzaW5nIG91ciBw
cm90b2NvbHMgd2l0aCByZWFsIHByb2JsZW1zLiBETEVQIEkgdGhpbmsgaGFzIHNvbWUgcmVhbCBh
ZGFwdG9ycywgdGhvdWdoIEkgdGhpbmsgbW9zdCBhcmUgd2FpdGluZyBmb3IgYW4gUkZDLiBPTFNS
djIgaXMgc2hvcnQgb24gY29tcGFuaWVzIGFkdmVydGlzaW5nIHRoZXkgYXJlIHVzaW5nIGl0IC0g
SSB3aXNoIHNvbWUgd291bGQgKEnigJltIHRvbGQgdGhleSBleGlzdCwgYnV0IGNvdWxkbuKAmXQg
bmFtZSBhbnkpLiBBT0RWdjIgKHdoaWNoIG1heSBvciBtYXkgbm90IGJlIGluIHNjb3BlKSBhcHBl
YXJzIG5vdCB0byBoYXZlIGV2ZW4gdXAgdG8gZGF0ZSBleHBlcmltZW50YWwgY29kZSAocGxlYXNl
IGNvcnJlY3QgaWYgd3JvbmcpLg0KLSBIZW5jZSBhbHRob3VnaCB3ZSBtYXkgaGF2ZSBzb21lIGdy
ZWF0IGlkZWFzLCBpdOKAmXMgbm90IHlldCBjbGVhciBwZW9wbGUgd2FudCB0aGVtIGFuZCB3ZSBj
YW4gZGVsaXZlciAtIERMRVAgbWFpbnRlbmFuY2UgYmVpbmcgSSB0aGluayBjbG9zZXN0IHRvIGNv
bnRyYWRpY3RpbmcgdGhhdCwgYXQgbGVhc3QgcHVibGljbHkuDQpXZWxsIEkgS05PVyB0aGF0IGhl
cmUgYXQgTlJMIHdlIGhhdmUgdGhlIHJlYWwgcGVvcGxlIGFuZCBwcm90b3R5cGUgcHJvZHVjdHMg
cmVsYXRpbmcgdG8gdGhlIG11bHRpY2FzdCBpc3N1ZSB0aGF0IGl0IGNhbiBoYXBwZW4uIFRoZSBr
ZXkgaXNzdWUgaXMgbWFraW5nIHN1cmUgdGhlcmUgYXJlIGVub3VnaCBwZW9wbGUgd2lsbGluZyB0
byBjb250cmlidXRlIGFuZCBlbmdpbmVlciBhIHNvbHV0aW9uIHRvIGFuIGlzc3VlIHRoYXQgbmVl
ZHMgc29sdmluZy4NCg0KVGhlcmUgaXMgdGhlIGhvcnJpYmxlIHdhcm5pbmcgb2YgQXV0b2NvbmYg
dGhhdCB3ZW50IHdyb25nIGluIHNldmVyYWwgd2F5cywgYnV0IGF0IHRoZSBlbmQsIGhhZCBubyBv
bmUgd2hvIHdvdWxkIGRvIHRoZSB3b3JrICh3aGljaCBpcyBhIGxvdCBvZiB3b3JrLCB0YWtpbmcg
bG9uZ2VyIHRoYW4geW91IGV4cGVjdCkgdG8gY3JlYXRlIGEgZHJhZnQgYW5kIHRha2UgaXQgYWxs
IHRoZSB3YXkuIEFuZCB0aGF0IG1lYW5zIGEgc21hbGwgdGVhbSBvZiBhY3R1YWwgYXV0aG9ycywg
cGx1cyB3aWRlciBpbnB1dC4NCg0KSW5jaWRlbnRhbGx5IHRoZSBhdXRvY29uZiBwcm9ibGVtIGlz
IHN0aWxsIHJlYWwsIGJ1dCB3YXMgdG9vIG5hcnJvdy4gVGhhdCB3YXMgY29uc2lkZXJpbmcgYWRk
cmVzcyBhdXRvY29uZmlndXJhdGlvbiAodGhvdWdoIHRoZSBXRyBuZXZlciBhY3R1YWxseSBnb3Qg
dGhlcmUpLiBBcyBJIHNlZSBpdCwgdGhlcmXigJlzIGFuIGluc2VwYXJhYmxlIChpbiB0ZXJtcyBv
ZiB0aGlua2luZyBhYm91dCBpdCwgZHJhZnRzIG1heSBvZiBjb3Vyc2Ugc2VwYXJhdGUgb3V0IGRl
dGFpbHMpIGlzc3VlIHRoYXQgaXMgb2YgYWRkcmVzcyBhc3NpZ25tZW50LCBpZGVudGl0eSBhc3Np
Z25tZW50L21hbmFnZW1lbnQsIGNyeXB0b2dyYXBoaWMga2V5IG1hbmFnZW1lbnQsIGFuZCBvdGhl
ciBmb3JtcyBvZiBtYW5hZ2VtZW50IChuZXR3b3JrIG1hbmFnZW1lbnQpLiBBbmQgc2V2ZXJhbCBj
aGlja2VuIGFuZCBlZ2cgcHJvYmxlbXMgdGhhdCBhcmlzZSBpbiB0aGVtLCBlc3BlY2lhbGx5IGlu
IGFkIGhvYyBuZXR3b3Jrcy4NCkkgdGhpbmsgdGhlIGlzc3VlIHdpdGggYXV0b2NvbmYgaXMgdGhh
dCBpdCB3YXMgYXR0ZW1wdGluZyB0byBzb2x2ZSB0byBicm9hZCBhIHByb2JsZW0uICBUaGVyZSB3
ZXJlIGRlbW9uc3RyYXRhYmxlIHNvbHV0aW9ucyB0byB2ZXJ5IHNwZWNpZmljIHByb2JsZW1zIChl
LmcuIG11bHRpaG9wIERIQ1ApIGJ1dCB0aGVuIHRoZXJlIHdlcmUgbW9yZSBleG90aWMgc29sdXRp
b25zIHRvIG1vcmUgY29tcGxleCBwcm9ibGVtcyBsaWtlIERBRCBpbiBkaXNjb25uZWN0ZWQgcGFy
dGl0aW9uaW5nL21lcmdpbmcgbmV0d29ya3MuIElmIHdlIGNhbiBmb2N1cyBvbiBhIHNwZWNpZmlj
IHdlbGwgZGVmaW5lZCBwcm9ibGVtIHNwYWNlIEkgdGhpbmsgd2UnbGwgYmUgZmluZS4NCg0KLS0N
CkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lz
dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIx
OTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVh
cmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl
LCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBF
c3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVt
cy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdp
c3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNl
OiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJv
bTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptYW5ldC1ib3Vu
Y2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFRob21hcyBIZWlkZSBDbGF1c2VuDQpTZW50OiAy
NiBBcHJpbCAyMDE2IDIyOjAxDQpUbzogSnVzdGluIERlYW4NCkNjOiBtYW5ldEBpZXRmLm9yZzxt
YWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21hbmV0XSBSZWNoYXJ0ZXIgRGlz
Y3Vzc2lvbg0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJv
bSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRu
ZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3Vs
ZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9y
IGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZv
ciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5i
YWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVk
JTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVh
c2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29t
L2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUy
MFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCioqKiBXQVJOSU5HICoqKg0KRVhURVJOQUwgRU1B
SUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRp
b24uDQoNCg0KDQpPbiAyNiBhdnIuIDIwMTYsIGF0IDIyOjIxLCBKdXN0aW4gRGVhbiA8YmViZW1h
c3RlckBnbWFpbC5jb208bWFpbHRvOmJlYmVtYXN0ZXJAZ21haWwuY29tPj4gd3JvdGU6DQpUaG9t
YXMgSSB1bmRlcnN0YW5kIHlvdXIgY29uY2VybnMgYnV0IHdlIGhhdmUgbW9zdGx5IGdvbmUgb3Zl
ciB0aGlzIGJlZm9yZSBpbiBwcmV2aW91cyBtZWV0aW5ncy4NCg0KVGhlIElFVEYgY29uZHVjdHMg
aXMgYnVzaW5lc3Mgb24gbWFpbGluZyBsaXN0cy4NCg0KTXkgcmVjb2xsZWN0aW9uIGlzIHRoYXQg
dGhlIHN0cmF3bWFuIGNoYXJ0ZXIgd2FzIHByZXNlbnRlZCBvbmNlIGluIGEgV0cgbWVldGluZywg
dGhlbiB0aGUgY2hhaXJzIGRpZCBub3QgYW5pbWF0ZSBhbnkgY2hhcnRlciBkaXNjdXNzaW9uIGZv
ciBzZXZlcmFsIElFVEZzLCBvbiB0aGUgbGlzdCAobm9yIHdhcyB0aGUgY2hhcnRlciBkaXNjdXNz
ZWQgaW4gc3Vic2VxdWVudCBtZWV0aW5ncykgLSB1bnRpbCB0aGlzIHByZXNlbnQgInVyZ2VuY3ki
IHdhcyBkZWNsYXJlZCAoYnkgdGhlIGNoYWlycykgdG8gdGhlIFdHLg0KDQpUaGUgQUQgd2lsbCBu
b3QgYWxsb3cgdXMgdG8gbWVldCBhdCB0aGUgbmV4dCBJRVRGIG1lZXRpbmcgaWYgd2UgZG8gbm90
IGhhdmUgYSBuZXcgY2hhcnRlciBhbmQgbmV3IHdvcmsgaXRlbXMuDQoNClRoYXQgZG9lcyBub3Qg
bmVnYXRlIG15IHBvaW50LCBob3dldmVyLCB3aGljaCB3YXMgdGhhdDoNCg0KaXQgc2hvdWxkIGJl
IGVzdGFibGlzaGVkIG9uIHRoZSBsaXN0IHRoYXQgdGhlcmUgYXJlIG1lYW5pbmdmdWwgdGhpbmdz
IHRvIGRvLCBhbmQgdGhlcmUncyBhIG1lYW5pbmdmdWwgY3JpdGljYWwgbWFzcyBvZiBwZW9wbGUg
dG8gYmUgZG9pbmcgdGhvc2UgdGhpbmdzLCBiZWZvcmUgYSAodmlydHVhbCkgaW50ZXJpbSBpcyBj
YWxsZWQuIEJyYWluc3Rvcm1pbmcgb24gYSB0ZWxlY29uZmVyZW5jZSBpcyByYXJlbHkgYSBjb25z
dHJ1Y3RpdmUgd2F5IHRvIHNwZW5kIHRpbWUNCg0KDQpUaG9tYXMNCg0KVG8geW91ciBwb2ludCBp
dCdzIGltcGFyYXRpdmUgdGhhdCB0aGUgZGlzY3Vzc2lvbiBjb250aW51ZXMgb24gbGlzdCBhYm91
dCB0aGUgY2hhcnRlci4gIFdpdGggdGhhdCBpbiBtaW5kIGhlcmUgaXMgYSBzdWdnZXN0ZWQgZWRp
dCBvZiB0aGUgcHJldmlvdXNseSBmbG9hdGVkIGNoYXJ0ZXIsIHdpdGggY29tbWVudHMgaW4gKCkg
d2l0aCBKV0QgdGFncy4NCg0KDQpUaGUgcHVycG9zZSBvZiB0aGUgTUFORVQgd29ya2luZyBncm91
cCBpcyB0byBzdGFuZGFyZGl6ZSBJUCByb3V0aW5nIHByb3RvY29sIGZ1bmN0aW9uYWxpdHkgc3Vp
dGFibGUgZm9yIHdpcmVsZXNzIHJvdXRpbmcgYXBwbGljYXRpb24gd2l0aGluIGJvdGggc3RhdGlj
IGFuZCBkeW5hbWljIHRvcG9sb2dpZXMgd2l0aCBpbmNyZWFzZWQgZHluYW1pY3MgZHVlIHRvIG5v
ZGUgbW90aW9uIG9yIG90aGVyIGZhY3RvcnMuDQoNCg0KDQpBcHByb2FjaGVzIGFyZSBpbnRlbmRl
ZCB0byBiZSByZWxhdGl2ZWx5IGxpZ2h0d2VpZ2h0IGluIG5hdHVyZSwgc3VpdGFibGUgZm9yIG11
bHRpcGxlIGhhcmR3YXJlIGFuZCB3aXJlbGVzcyBlbnZpcm9ubWVudHMsIGFuZCBhZGRyZXNzIHNj
ZW5hcmlvcyB3aGVyZSBNQU5FVHMgYXJlIGRlcGxveWVkIGF0IHRoZSBlZGdlcyBvZiBhbiBJUCBp
bmZyYXN0cnVjdHVyZS4gSHlicmlkIG1lc2ggaW5mcmFzdHJ1Y3R1cmVzIChlLmcuLCBhIG1peHR1
cmUgb2YgZml4ZWQgYW5kIG1vYmlsZSByb3V0ZXJzKSBzaG91bGQgYWxzbyBiZSBzdXBwb3J0ZWQg
YnkgTUFORVQgc3BlY2lmaWNhdGlvbnMgYW5kIG1hbmFnZW1lbnQgZmVhdHVyZXMuDQoNCg0KDQpU
aGUgTUFORVQgV0cgaXMgcmVzcG9uc2libGUgZm9yIHRoZSBtYWludGVuYW5jZSBvZiBPTFNSdjIs
IEFPRFZ2MiAoSldEIFRCRCksIERMRVAgYW5kIE5IUEQuIE9mIHBhcnRpY3VsYXIgaW50ZXJlc3Q6
IHNlY3VyaXR5IGVuaGFuY2VtZW50cywgYW5kIGVuY3J5cHRpb24gc2VjdXJpdHkgZXh0ZW5zaW9u
cyBmb3IgUkZDNTQ0NC4gKEpXRCB3ZSBtYXkgd2FudCB0byBicmVhayB0aGlzIG91dCBvZiB0aGUg
V0cgYW5kIG1ha2UgYSBuZXcgTUFORVQgU2VjIHdvcmtpbmcgZ3JvdXAgdG8gZ3JhYiB0aGUgYXR0
ZW50aW9uIG9mIHRob3NlIGludGVyZXN0ZWQgaW4gc2VjdXJpdHkgYW5kIGdldCB0aGVpciBwYXJ0
aWNpcGF0aW9uLikNCg0KDQoNClRoZSBNQU5FVCBXRyB3aWxsIHN0YW5kYXJkaXplIGEgbXVsdGlj
YXN0IE1BTkVUIHByb3RvY29sIGZyYW1ld29yayBiYXNlZCBvbiBwcmV2aW91cyB3b3JrIGFuZCBs
ZXNzb25zIGxlYXJuZWQgZm9yIHNjb3BlZCBmb3J3YXJkaW5nIHdpdGhpbiBNQU5FVCBuZXR3b3Jr
cy4gIEFzIHBhcnQgb2YgdGhpcyBmcmFtZXdvcmsgdGhlIFdHIHdpbGwgcHJvZHVjZSBhIHdlbGwg
ZGVmaW5lZCBNQU5FVCBtdWx0aWNhc3QgZm9yd2FyZGluZyBpbmZvcm1hdGlvbiBiYXNlLg0KDQoN
Cg0KVGhlIFdHIHdpbGwgcHJvZHVjZSBhbiBpbmZvcm1hdGlvbmFsIGRyYWZ0IG91dGxpbmluZyBj
aGFsbGVuZ2VzIGFuZCBiZXN0IHByYWN0aWNlcyBmb3IgZGVwbG95aW5nIGFuZCBtYW5hZ2luZyBN
QU5FVCBuZXR3b3Jrcy4NCg0KDQoNClRoZSBNQU5FVCBXRyB3aWxsIGludGVyYWN0IHdpdGggdGhl
IFBJTSB3b3JraW5nIGdyb3VwIG9uIGlzc3VlcyByZWxhdGluZyB0byB0aGUgbXVsdGljYXN0IHdv
cmsuICBUaGUgV0cgd2lsbCBhbHNvIHBheSBhdHRlbnRpb24gdG8gb3RoZXIgSUVURiBhbmQgSVJU
RiB3b3JrIHRoYXQgaXMgYWRkcmVzc2luZyB0b3BpY3MgcmVsYXRlZCB0byBNQU5FVCBlbnZpcm9u
bWVudHMuDQoNCg0KDQpJbiBzdW1tYXJ5LCB0aGUgV0cgd2lsbCBkZXZlbG9wIHRoZSBmb2xsb3dp
bmcgZHJhZnRzOg0KDQoNCg0KTUFORVQgTWFuYWdlbWVudCBEb2N1bWVudCAoSW5mb3JtYXRpb25h
bCkNCg0KTUFORVQgTWFpbnRlbmFuY2UNCg0KIC0gUkZDNTQ0NCBTZWN1cml0eSBleHRlbnNpb24g
KFN0YW5kYXJkcykgKEpXRCBwb3NzaWJseSBtb3ZlIHRoaXMgdG8gbmV3IHdvcmtpbmcgZ3JvdXAp
DQoNCk1BTkVUIE11bHRpY2FzdA0KDQogLSBNdWx0aWNhc3QgRklCIChTdGFuZGFyZHMpDQoNCg0K
DQpPbiBUdWUsIEFwciAyNiwgMjAxNiBhdCAyOjU1IFBNLCBUaG9tYXMgQ2xhdXNlbiA8aWV0ZkB0
aG9tYXNjbGF1c2VuLm9yZzxtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZz4+IHdyb3RlOg0K
SGksDQoNCkkgYmVsaWV2ZSB0aGF0IGFuIHZpcnR1YWwgaW50ZXJpbSBpcyBwcmVtYXR1cmU6IGEg
dGVsZWNvbmZlcmVuY2UgaXMsIG1lY2hhbmljYWxseSwgbGVzcyBpbmNsdXNpdmUgdGhhbiBhcmUg
bWFpbGluZyBsaXN0IGRpc2N1c3Npb25zICh0aW1lLXpvbmVzLCBvdGhlciBjb21taXRtZW50cywg
cmVxdWlyZW1lbnQgb2Ygc3luY2hyb25pY2l0eSBvZiBwYXJ0aWNpcGF0aW9uLCBldGMuKS4NCg0K
RnVydGhlcm1vcmUuLi4uDQoNClVudGlsIHN1Y2ggdGltZSB0aGF0IGEgc3RyYXdtYW4gY2hhcnRl
ciBpcyBwcm9wb3NlZCwgdXBkYXRlZCB0byByZWZsZWN0IHRoZSByZWFsaXR5IG9mIHRoZSBncm91
cCBhcyBzdGlwdWxhdGVkIGJ5IHRoZSBBRCBhbmQgYnkgTXIuIERlYW4sIGFzIHdlbGwgYXMgYWRk
aXRpb25hbCBjaGFydGVyIGl0ZW1zIGVtZXJnaW5nIG9uIHRoZSBsaXN0LCAgYW5kIHdpdGggcmVs
YXRpdmVseSBicm9hZCBhbmQgZGVlcCBzdXBwb3J0IGZvciB0aGUgaW5jbHVkZWQgaXRlbXMgYnkg
dGhlIHdvcmtpbmcgZ3JvdXAsIGhhdmluZyBhbiBpbnRlcmltIC0gdmlydHVhbCBvciBvdGhlcndp
c2UgLSBpcyBub3QgY29uc3RydWN0aXZlLg0KDQpJbiBvdGhlciB3b3JkcywgaXQgc2hvdWxkIGJl
IGVzdGFibGlzaGVkIG9uIHRoZSBsaXN0IHRoYXQgdGhlcmUgYXJlIG1lYW5pbmdmdWwgdGhpbmdz
IHRvIGRvLCBhbmQgdGhlcmUncyBhIG1lYW5pbmdmdWwgY3JpdGljYWwgbWFzcyBvZiBwZW9wbGUg
dG8gYmUgZG9pbmcgdGhvc2UgdGhpbmdzLCBiZWZvcmUgYSAodmlydHVhbCkgaW50ZXJpbSBpcyBj
YWxsZWQuIEJyYWluc3Rvcm1pbmcgb24gYSB0ZWxlY29uZmVyZW5jZSBpcyByYXJlbHkgYSBjb25z
dHJ1Y3RpdmUgd2F5IHRvIHNwZW5kIHRpbWUuDQoNCkJlc3QsDQoNClRob21hcw0KDQpTZW50IGZy
b20gbXkgaVBhZA0KDQpPbiAyMiBBcHIgMjAxNiwgYXQgMTc6NTAsIFN0YW4gUmF0bGlmZiA8cmF0
bGlmZnN0YW5AZ21haWwuY29tPG1haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb20+PiB3cm90ZToN
CkhlbGxvIFdHLA0KDQpEbyB3ZSBuZWVkIHRvIGhvbGQgYW4gaW50ZXJpbSBtZWV0aW5nICh2aWEg
V2ViRVgpIHRvIGRpc2N1c3M/IEknZCBsaWtlIHRvIGdldCBvcGluaW9ucyBvbiB0aGUgbGlzdCBh
Ym91dCB0aGF0LiBXZSdsbCBuZWVkIGEgY291cGxlIG9mIHdlZWtzIHRvIHNjaGVkdWxlLCBidXQg
d2UgY2FuIGRvIHRoYXQuDQoNCk9uZSBvdGhlciBwb2ludCBpbmxpbmU6DQoNCk9uIEZyaSwgQXBy
IDIyLCAyMDE2IGF0IDExOjQ1IEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMu
ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu
Y29tPj4gd3JvdGU6DQpNdWx0aWNhc3QgaXMgdGhlIG9idmlvdXMgdG9wIGl0ZW0uIExvdHMgb2Yg
cG9zc2libGUgYXBwcm9hY2hlcywgdGltZSB0byBkaXNjdXNzLg0KDQpHYXRld2F5cyBmb3IgQU9E
VnYyIGF0IFN0YW5kYXJkIGlzIG9idmlvdXNseSBub3QgcG9zc2libGUgc2luY2UgQU9EVnYyIGlz
IGdvaW5nIHRvIGJlIEV4cGVyaW1lbnRhbCBhdCBtb3N0Lg0KDQpNYW5hZ2VtZW50IHdlIGRpZCBv
ZiBjb3Vyc2UgaGF2ZSBhbiBOSERQL09MU1J2MiBkcmFmdCBraWxsZWQgYnkgQUQuIFdoaWNoIHNp
bmNlIE5IRFAvT0xTUnYyIHVzIGFsbCB3ZSBoYXZlIChTTUYgZXhjZXB0ZWQpIHRoYXQgd2FzIGEg
Yml0IHRyaWNreS4NCg0KSSB3b3VsZCBoYXZlIHRvIG1ha2UgYW4gSVBSIGRlY2xhcmF0aW9uIHRv
IHNheSBzb21lIG9mIHdoYXQgSSBtaWdodCBoYXZlIHRvIHNheSBhYm91dCBlbmNyeXB0aW9uLiBO
b3QgdG9kYXkuDQoNClVuZGVyc3Rvb2QuIEJ1dCBwbGVhc2UgcmVtZW1iZXIgLSB0aGVyZSdzIG9u
bHkgYWJvdXQgYSA1LXdlZWsgZ2FwIG5vdyBiZWZvcmUgdGhlIGNoYXJ0ZXIgbmVlZHMgdG8gYmUg
Y29tcGxldGUgaW4gb3JkZXIgZm9yIHRoZSBXRyB0byBtZWV0IGluIEJlcmxpbi4NCg0KUmVnYXJk
cywNClN0YW4NCg0KDQoNCg0KTWlzc2luZyBmcm9tIHRoZSBsaXN0IGlzIGFueSB3b3JrIG9uIE9M
U1J2MiAob3IgTkhEUCkuIE1ULU9MU1J2MiBpcyBleHBlcmltZW50YWwuIFRoYXQgd291bGQgbmVl
ZCBpbXBsZW1lbnRhdGlvbiB0ZXN0cyB0byBhZHZhbmNlIHRvIFBTLiBBbnlvbmUgaW50ZXJlc3Rl
ZCBpbiB0aGF0IChJ4oCZbSBub3Qgc2F5aW5nIEkgY2FuKT8NCg0KTW9yZSBicm9hZGx5IG9uIE9M
U1J2MiB0aGVyZSBhcmUgdmFyaW91cyB0aGluZ3MgdGhhdCBjb3VsZCBiZSBkb25lLCBidXQgd2hh
dCBpcyByZWFsbHkgbmVlZGVkIGlzIHBlb3BsZSB3aXRoIGEgcmVhbCBhcHBsaWNhdGlvbi4gQW55
IHRoYXQgZXhpc3Qgd2VyZSBmcmlnaHRlbmVkIGF3YXkgZnJvbSB0aGlzIGdyb3VwLg0KDQotLQ0K
Q2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0
ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5
ND4gIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFy
bG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2Us
IENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVz
c2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1z
LmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lz
dGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6
IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9t
OiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0LWJvdW5j
ZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSnVzdGluIERlYW4NClNlbnQ6IDIyIEFwcmlsIDIw
MTYgMTY6MDcNClRvOiBtYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpTdWJq
ZWN0OiBbbWFuZXRdIFJlY2hhcnRlciBEaXNjdXNzaW9uDQoNCg0KKioqIFdBUk5JTkcgKioqDQpU
aGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0
aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBj
YXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkg
YXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFn
cyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sg
aGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0
eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhl
IGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9p
bnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMv
RG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KKioq
IFdBUk5JTkcgKioqDQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBm
cm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbi4NCg0KSSdsbCBzdGFydCB0aGluZ3Mgb2ZmIGJ5
IGZsb2F0aW5nIHRoZSBkcmFmdCByZS1jaGFydGVyIHdoaWNoIHdhcyBwcmVzZW50ZWQgaW4gUHJh
Z3VlLg0KDQpUaGUgcHVycG9zZSBvZiB0aGUgTUFORVQgd29ya2luZyBncm91cCBpcyB0byBzdGFu
ZGFyZGl6ZSBJUCByb3V0aW5nIHByb3RvY29sIGZ1bmN0aW9uYWxpdHkgc3VpdGFibGUgZm9yIHdp
cmVsZXNzIHJvdXRpbmcgYXBwbGljYXRpb24gd2l0aGluIGJvdGggc3RhdGljIGFuZCBkeW5hbWlj
IHRvcG9sb2dpZXMgd2l0aCBpbmNyZWFzZWQgZHluYW1pY3MgZHVlIHRvIG5vZGUgbW90aW9uIG9y
IG90aGVyIGZhY3RvcnMuDQoNCg0KDQpBcHByb2FjaGVzIGFyZSBpbnRlbmRlZCB0byBiZSByZWxh
dGl2ZWx5IGxpZ2h0d2VpZ2h0IGluIG5hdHVyZSwgc3VpdGFibGUgZm9yIG11bHRpcGxlIGhhcmR3
YXJlIGFuZCB3aXJlbGVzcyBlbnZpcm9ubWVudHMsIGFuZCBhZGRyZXNzIHNjZW5hcmlvcyB3aGVy
ZSBNQU5FVHMgYXJlIGRlcGxveWVkIGF0IHRoZSBlZGdlcyBvZiBhbiBJUCBpbmZyYXN0cnVjdHVy
ZS4gSHlicmlkIG1lc2ggaW5mcmFzdHJ1Y3R1cmVzIChlLmcuLCBhIG1peHR1cmUgb2YgZml4ZWQg
YW5kIG1vYmlsZSByb3V0ZXJzKSBzaG91bGQgYWxzbyBiZSBzdXBwb3J0ZWQgYnkgTUFORVQgc3Bl
Y2lmaWNhdGlvbnMgYW5kIG1hbmFnZW1lbnQgZmVhdHVyZXMuDQoNCg0KDQpUaGUgTUFORVQgV0cg
aXMgcmVzcG9uc2libGUgZm9yIHRoZSBtYWludGVuYW5jZSBvZiBPTFNSdjIsIEFPRFZ2MiwgRExF
UCBhbmQgTkhQRC4gT2YgcGFydGljdWxhciBpbnRlcmVzdDogYm9yZGVyIGJlaGF2aW9yIGJldHdl
ZW4gTUFORVQgbmV0d29ya3MgYW5kIGZpeGVkIElQIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmVzLCBl
bmhhbmNlIEFPRFZ2MiBnYXRld2F5IGZ1bmN0aW9uYWxpdHk7IHNlY3VyaXR5IGVuaGFuY2VtZW50
cywgZW5jcnlwdGlvbiBzZWN1cml0eSBleHRlbnNpb25zIGZvciBSRkM1NDQ0Lg0KDQoNCg0KVGhl
IE1BTkVUIFdHIHdpbGwgc3RhbmRhcmRpemUgYSBtdWx0aWNhc3QgTUFORVQgcHJvdG9jb2wgZnJh
bWV3b3JrIGJhc2VkIG9uIHByZXZpb3VzIHdvcmsgYW5kIGxlc3NvbnMgbGVhcm5lZCBmb3Igc2Nv
cGVkIGZvcndhcmRpbmcgd2l0aGluIE1BTkVUIG5ldHdvcmtzLiAgQXMgcGFydCBvZiB0aGlzIGZy
YW1ld29yayB0aGUgV0cgd2lsbCBwcm9kdWNlIGEgd2VsbCBkZWZpbmVkIE1BTkVUIG11bHRpY2Fz
dCBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIGJhc2UuDQoNCg0KDQpUaGUgV0cgd2lsbCBwcm9kdWNl
IGFuIGluZm9ybWF0aW9uYWwgZHJhZnQgb3V0bGluaW5nIGNoYWxsZW5nZXMgYW5kIGJlc3QgcHJh
Y3RpY2VzIGZvciBkZXBsb3lpbmcgYW5kIG1hbmFnaW5nIE1BTkVUIG5ldHdvcmtzLg0KDQoNCg0K
VGhlIE1BTkVUIFdHIHdpbGwgaW50ZXJhY3Qgd2l0aCB0aGUgUElNIHdvcmtpbmcgZ3JvdXAgb24g
aXNzdWVzIHJlbGF0aW5nIHRvIHRoZSBtdWx0aWNhc3Qgd29yay4gIFRoZSBXRyB3aWxsIGFsc28g
cGF5IGF0dGVudGlvbiB0byBvdGhlciBJRVRGIGFuZCBJUlRGIHdvcmsgdGhhdCBpcyBhZGRyZXNz
aW5nIHRvcGljcyByZWxhdGVkIHRvIE1BTkVUIGVudmlyb25tZW50cy4NCg0KDQoNCkluIHN1bW1h
cnksIHRoZSBXRyB3aWxsIGRldmVsb3AgdGhlIGZvbGxvd2luZyBkcmFmdHM6DQoNCg0KDQpNQU5F
VCBNYW5hZ2VtZW50IERvY3VtZW50IChJbmZvcm1hdGlvbmFsKQ0KDQpNQU5FVCBNYWludGVuYW5j
ZQ0KDQogLSBSRkM1NDQ0IFNlY3VyaXR5IGV4dGVuc2lvbiAoU3RhbmRhcmRzKQ0KDQogLSBFbmhh
bmNlZCBBT0RWdjIgZ2F0ZXdheSBleHRlbnNpb24gKFN0YW5kYXJkcykNCg0KTUFORVQgTXVsdGlj
YXN0DQoNCiAtIE11bHRpY2FzdCBGSUIgKFN0YW5kYXJkcykNCg0KDQoNCg0KDQpUaGlzIHdpbGwg
bGlrZWx5IGJlIGNvbnNpZGVyZWQgdG9vIGJyb2FkIHRvIHBhc3MuICBXZSB3aWxsIGxpa2VseSBu
ZWVkIHRvIGN1dCBzb21lIGFuZCBmb2N1cyB0aGUgd29yay4gIEZvciBtZSBwZXJzb25hbGx5IEkg
a25vdyBJIGhhdmUgdGhlIHRpbWUgYW5kIGJhY2tpbmcgdG8gd29yayBvbiB0aGUgTXVsdGljYXN0
IHBpZWNlLg0KDQoNCg0KSnVzdGluDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpUaGlzIGVtYWlsIGFuZCBhbnkg
YXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCBh
bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQpy
ZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhl
IHNlbmRlci4NCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9z
ZSBub3IgZGlzY2xvc2Ugb3INCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBw
ZXJzb24uDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86
bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21h
bmV0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpt
YW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4N
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlz
dA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQoNCg==

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1E8DGLKXM0002VGREEN_
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
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9L
LCB5b3Uga25vdyB0aGVyZSBhcmUgc29tZSBwZW9wbGUgYXQgTlJMLiBHb29kLiBCdXQgc3RpbGwg
cXVpdGUgYSB3YXkgc2hvcnQgb2Ygd2hhdCB3ZSByZWFsbHkgbmVlZCBpbiB0ZXJtcyBvZiBidXkt
aW4uIChJ4oCZbSBhc3N1bWluZyB0aGUgcGVvcGxlIGF0IE5STCBhcmUNCiByZXByZXNlbnRlZCBi
eSB5b3UgYW5kL29yIEJyaWFuLCBhcyBvdGhlcndpc2UgZXZlbiB0aGV5IGFyZW7igJl0IHNob3dp
bmcgdXAuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w
cHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+
PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3
RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJy
Pg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9z
cGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdE
N0Q3RCI+OiAmbmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wgJm5ic3A7PGI+RToN
CjwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlz
LmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hl
bG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXgg
Q00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3Bh
biBzdHlsZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu
Y2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEz
Mzc0NTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4
QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwg
U3VycmV5LCBHVTIgN1lQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEp1c3RpbiBEZWFuIFttYWlsdG86YmViZW1hc3Rl
ckBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjcgQXByaWwgMjAxNiAxNjo0NTxicj4N
CjxiPlRvOjwvYj4gRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk8YnI+DQo8Yj5DYzo8L2I+IFRo
b21hcyBIZWlkZSBDbGF1c2VuOyBtYW5ldEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS
ZTogW21hbmV0XSBSZWNoYXJ0ZXIgRGlzY3Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2Vu
dGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl
ciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPG86cD48L286
cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs
aWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRl
cjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5p
c2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48
L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxi
cj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBj
bGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48
L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+
DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBl
bWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5i
YWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVk
JTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0
aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0cDovL2lu
dHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9E
b2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiI+DQp0aGlz
IHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXByIDI3LCAyMDE2IGF0IDU6NTYgQU0sIERlYXJs
b3ZlLCBDaHJpc3RvcGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVA
YmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z
LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij5UaGUga2V5IHBvaW50cyBhcyBJIHNlZSBpdCBhcmU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+LSBXZSBzaG91bGRu4oCZdCB3YWl0IGZvciB0ZWxlY29uLCBhbmQgY2Fu4oCZdCBy
ZWx5IG9uIHRlbGVjb24gYW5kIGN1dCBvdXQgbGlzdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUuJm5ic3A7
IFdlIHNob3VsZG4ndCB3YWl0IGZvciB0aGUgdGVsZWNvbi4mbmJzcDsgSSdsbCBjb250aW51ZSB0
byBlbmdhZ2UgZXZlcnlvbmUgb24gdGhpcyBsaXN0IGFib3V0IHdoYXQgcGVvcGxlIGFyZSB3aWxs
aW5nIHRvIHdvcmsgb24uPGJyPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0
O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0
OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0gV2UgYXJlIHZlcnkgc2hvcnQgb2YgY29u
dHJpYnV0b3JzLiBNYW55IHdobyBoYXZlIGNvbnRyaWJ1dGVkIGhhdmUgZHJvcHBlZCBhd2F5LiBB
bmQgdGhvc2Ugd2hvIGhhdmUNCiBiZWVuIG1haW4gY3JlYXRvcnMgb2YgV0cgUkZDcyAobG9va2lu
ZyBhdCBzdGF0aXN0aWNzLCBDbGF1c2VuIGFuZCBEZWFybG92ZSBpbiBwYXJ0aWN1bGFyLCBidXQg
YWxzbyBvdGhlcnMgLSBidXQgbm90IGEgbG90IG9mIG90aGVycywgZXNwZWNpYWxseSBhZnRlciB0
aGUgZmlyc3QgYmF0Y2ggb2YgRXhwZXJpbWVudGFsIFJGQ3MpIG1heSBvciBtYXkgbm90IGJlIGNv
bnRyaWJ1dGluZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFyZSBzaG9ydCBjb250cmli
dXRvcnMgYW5kIHdlIG1heSBiZSBhYmxlIHRvIGdldCBtb3JlIGJ5IGZvY3VzaW5nIHRoZSBncm91
cCBvbiBzcGVjaWZpYyBpc3N1ZXMgYW5kIHBvc3NpYmx5IGNyZWF0aW5nIG5ldyBmb2N1c2VkIGdy
b3VwcyB0byBpbnZpdGUgYSBsYXJnZXIvd2lkZXIgSUVURiBpbnZvbHZlbWVudC4mbmJzcDsgU2Vj
dXJpdHkgYmVpbmcgdGhlIG9uZSBjb21pbmcgdG8gbWluZC4mbmJzcDsgWW91ciBtZW50aW9uDQog
b24gdGhlIGxpc3QgYWJvdXQgc2VjdXJpdHkgc3R1ZmYgdGhhdCB5b3UgYXJlIGludGVyZXN0ZWQg
aW4gaGFzbid0IGJyb3VnaHQgYSBsb3Qgb2YgZGlzY3Vzc2lvbiBvbiB0aGlzIGxpc3QgYnV0IGl0
IHZlcnkgd2VsbCBtYXkgYnJpbmcgYSBsb3Qgb2YgaW50ZXJlc3QgZnJvbSB0aGUgbGFyZ2VyIGll
dGYgY29tbXVuaXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0gQnV0IGV2ZW4gbW9yZSBpbXBvcnRhbnRseSB3ZSBu
ZWVkIHJlYWwgcGVvcGxlIChwcmVmZXJhYmx5IGNvbXBhbmllcyB3aXRoIHByb2R1Y3RzKSB1c2lu
ZyBvdXIgcHJvdG9jb2xzDQogd2l0aCByZWFsIHByb2JsZW1zLiBETEVQIEkgdGhpbmsgaGFzIHNv
bWUgcmVhbCBhZGFwdG9ycywgdGhvdWdoIEkgdGhpbmsgbW9zdCBhcmUgd2FpdGluZyBmb3IgYW4g
UkZDLiBPTFNSdjIgaXMgc2hvcnQgb24gY29tcGFuaWVzIGFkdmVydGlzaW5nIHRoZXkgYXJlIHVz
aW5nIGl0IC0gSSB3aXNoIHNvbWUgd291bGQgKEnigJltIHRvbGQgdGhleSBleGlzdCwgYnV0IGNv
dWxkbuKAmXQgbmFtZSBhbnkpLiBBT0RWdjIgKHdoaWNoIG1heSBvciBtYXkgbm90IGJlDQogaW4g
c2NvcGUpIGFwcGVhcnMgbm90IHRvIGhhdmUgZXZlbiB1cCB0byBkYXRlIGV4cGVyaW1lbnRhbCBj
b2RlIChwbGVhc2UgY29ycmVjdCBpZiB3cm9uZykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+LSBIZW5jZSBhbHRob3VnaCB3ZSBtYXkgaGF2ZSBzb21lIGdyZWF0IGlkZWFzLCBpdOKA
mXMgbm90IHlldCBjbGVhciBwZW9wbGUgd2FudCB0aGVtIGFuZCB3ZSBjYW4gZGVsaXZlcg0KIC0g
RExFUCBtYWludGVuYW5jZSBiZWluZyBJIHRoaW5rIGNsb3Nlc3QgdG8gY29udHJhZGljdGluZyB0
aGF0LCBhdCBsZWFzdCBwdWJsaWNseS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlbGwgSSBL
Tk9XIHRoYXQgaGVyZSBhdCBOUkwgd2UgaGF2ZSB0aGUgcmVhbCBwZW9wbGUgYW5kIHByb3RvdHlw
ZSBwcm9kdWN0cyByZWxhdGluZyB0byB0aGUgbXVsdGljYXN0IGlzc3VlIHRoYXQgaXQgY2FuIGhh
cHBlbi4gVGhlIGtleSBpc3N1ZSBpcyBtYWtpbmcgc3VyZSB0aGVyZSBhcmUgZW5vdWdoIHBlb3Bs
ZSB3aWxsaW5nIHRvIGNvbnRyaWJ1dGUgYW5kIGVuZ2luZWVyIGEgc29sdXRpb24gdG8gYW4gaXNz
dWUNCiB0aGF0IG5lZWRzIHNvbHZpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh
ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj
bSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw
Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5UaGVyZSBpcyB0aGUgaG9ycmlibGUgd2FybmluZyBvZiBBdXRvY29u
ZiB0aGF0IHdlbnQgd3JvbmcgaW4gc2V2ZXJhbCB3YXlzLCBidXQgYXQgdGhlIGVuZCwgaGFkIG5v
DQogb25lIHdobyB3b3VsZCBkbyB0aGUgd29yayAod2hpY2ggaXMgYSBsb3Qgb2Ygd29yaywgdGFr
aW5nIGxvbmdlciB0aGFuIHlvdSBleHBlY3QpIHRvIGNyZWF0ZSBhIGRyYWZ0IGFuZCB0YWtlIGl0
IGFsbCB0aGUgd2F5LiBBbmQgdGhhdCBtZWFucyBhIHNtYWxsIHRlYW0gb2YgYWN0dWFsIGF1dGhv
cnMsIHBsdXMgd2lkZXIgaW5wdXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu
LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluY2lkZW50YWxseSB0aGUgYXV0
b2NvbmYgcHJvYmxlbSBpcyBzdGlsbCByZWFsLCBidXQgd2FzIHRvbyBuYXJyb3cuIFRoYXQgd2Fz
IGNvbnNpZGVyaW5nIGFkZHJlc3MNCiBhdXRvY29uZmlndXJhdGlvbiAodGhvdWdoIHRoZSBXRyBu
ZXZlciBhY3R1YWxseSBnb3QgdGhlcmUpLiBBcyBJIHNlZSBpdCwgdGhlcmXigJlzIGFuIGluc2Vw
YXJhYmxlIChpbiB0ZXJtcyBvZiB0aGlua2luZyBhYm91dCBpdCwgZHJhZnRzIG1heSBvZiBjb3Vy
c2Ugc2VwYXJhdGUgb3V0IGRldGFpbHMpIGlzc3VlIHRoYXQgaXMgb2YgYWRkcmVzcyBhc3NpZ25t
ZW50LCBpZGVudGl0eSBhc3NpZ25tZW50L21hbmFnZW1lbnQsIGNyeXB0b2dyYXBoaWMga2V5DQog
bWFuYWdlbWVudCwgYW5kIG90aGVyIGZvcm1zIG9mIG1hbmFnZW1lbnQgKG5ldHdvcmsgbWFuYWdl
bWVudCkuIEFuZCBzZXZlcmFsIGNoaWNrZW4gYW5kIGVnZyBwcm9ibGVtcyB0aGF0IGFyaXNlIGlu
IHRoZW0sIGVzcGVjaWFsbHkgaW4gYWQgaG9jIG5ldHdvcmtzLjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SSB0aGluayB0aGUgaXNzdWUgd2l0aCBhdXRvY29uZiBpcyB0aGF0IGl0IHdhcyBhdHRl
bXB0aW5nIHRvIHNvbHZlIHRvIGJyb2FkIGEgcHJvYmxlbS4mbmJzcDsgVGhlcmUgd2VyZSBkZW1v
bnN0cmF0YWJsZSBzb2x1dGlvbnMgdG8gdmVyeSBzcGVjaWZpYyBwcm9ibGVtcyAoZS5nLiBtdWx0
aWhvcCBESENQKSBidXQgdGhlbiB0aGVyZSB3ZXJlIG1vcmUgZXhvdGljIHNvbHV0aW9ucyB0byBt
b3JlIGNvbXBsZXggcHJvYmxlbXMNCiBsaWtlIERBRCBpbiBkaXNjb25uZWN0ZWQgcGFydGl0aW9u
aW5nL21lcmdpbmcgbmV0d29ya3MuIElmIHdlIGNhbiBmb2N1cyBvbiBhIHNwZWNpZmljIHdlbGwg
ZGVmaW5lZCBwcm9ibGVtIHNwYWNlIEkgdGhpbmsgd2UnbGwgYmUgZmluZS4gJm5ic3A7Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7
bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjwvc3Bhbj48
L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3Ig
UHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2Ug
TGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAl
MjgwJTI5MTI0NSUyMDI0MjE5NCIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7NDQgKDApMTI0NSAyNDIx
OTQ8L2E+DQogJm5ic3A7fCAmbmJzcDs8Yj5FOiA8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRl
YXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFl
c3lzdGVtcy5jb208L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz
QThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hu
b2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4N
CjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj48
c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwv
YT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs
bGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5v
OiAwMTMzNzQ1MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJy
ZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg
MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1hbmV0DQogW21h
aWx0bzo8YSBocmVmPSJtYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiPm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UaG9t
YXMgSGVpZGUgQ2xhdXNlbjxicj4NCjxiPlNlbnQ6PC9iPiAyNiBBcHJpbCAyMDE2IDIyOjAxPGJy
Pg0KPGI+VG86PC9iPiBKdXN0aW4gRGVhbjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRv
Om1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0K
PGI+U3ViamVjdDo8L2I+IFJlOiBbbWFuZXRdIFJlY2hhcnRlciBEaXNjdXNzaW9uPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xp
ZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5k
OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxp
Z246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
NS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxp
Z246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91
ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGlu
dGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMz
Mzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ug
c2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHku
PC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5n
IDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBvdXQg
Zm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8vaW50cmFu
ZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3Vt
ZW50cy9SZWQlMjBGbGFncy5wZGYiIHRhcmdldD0iX2JsYW5rIj4NCmhlcmU8L2E+Ljwvc3Bhbj48
L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVt
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZv
bGxvdw0KPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdv
cmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNp
b3VzJTIwRW1haWxzLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3Nw
YW4+PC9lbT48L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjEuMHB0
IDQuMHB0IDEuMHB0IDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzt0ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPioqDQo8
L3NwYW4+PC9zdHJvbmc+PC9zcGFuPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
V0FSTklORw0KPC9zcGFuPjwvc3Ryb25nPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPioqKjwvc3Bhbj48L3N0
cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5FWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBm
cm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206
MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy
LjBwdCI+PGJyPg0KT24gMjYgYXZyLiAyMDE2LCBhdCAyMjoyMSwgSnVzdGluIERlYW4gJmx0Ozxh
IGhyZWY9Im1haWx0bzpiZWJlbWFzdGVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJlYmVt
YXN0ZXJAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRob21hcyBJIHVuZGVyc3RhbmQg
eW91ciBjb25jZXJucyBidXQgd2UgaGF2ZSBtb3N0bHkgZ29uZSBvdmVyIHRoaXMgYmVmb3JlIGlu
IHByZXZpb3VzIG1lZXRpbmdzLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIElFVEYgY29uZHVjdHMg
aXMgYnVzaW5lc3Mgb24gbWFpbGluZyBsaXN0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk15IHJlY29sbGVjdGlvbiBpcyB0aGF0IHRo
ZSBzdHJhd21hbiBjaGFydGVyIHdhcyBwcmVzZW50ZWQgb25jZSBpbiBhIFdHIG1lZXRpbmcsIHRo
ZW4gdGhlIGNoYWlycyBkaWQgbm90IGFuaW1hdGUgYW55IGNoYXJ0ZXIgZGlzY3Vzc2lvbiBmb3Ig
c2V2ZXJhbCBJRVRGcywgb24gdGhlIGxpc3QgKG5vciB3YXMgdGhlDQogY2hhcnRlciBkaXNjdXNz
ZWQgaW4gc3Vic2VxdWVudCBtZWV0aW5ncykgLSB1bnRpbCB0aGlzIHByZXNlbnQgJnF1b3Q7dXJn
ZW5jeSZxdW90OyB3YXMgZGVjbGFyZWQgKGJ5IHRoZSBjaGFpcnMpIHRvIHRoZSBXRy48bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBBRCB3aWxsIG5vdCBhbGxv
dyB1cyB0byBtZWV0IGF0IHRoZSBuZXh0IElFVEYgbWVldGluZyBpZiB3ZSBkbyBub3QgaGF2ZSBh
IG5ldyBjaGFydGVyIGFuZCBuZXcgd29yayBpdGVtcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGF0IGRvZXMgbm90IG5l
Z2F0ZSBteSBwb2ludCwgaG93ZXZlciwgd2hpY2ggd2FzIHRoYXQ6PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPml0IHNob3VsZCBiZSBlc3RhYmxpc2hlZCBvbiB0aGUgbGlzdCB0aGF0IHRo
ZXJlIGFyZSZuYnNwOzxiPjx1Pm1lYW5pbmdmdWwgdGhpbmdzIHRvIGRvPC91PjwvYj4sIGFuZCB0
aGVyZSdzIGEmbmJzcDs8Yj48dT5tZWFuaW5nZnVsIGNyaXRpY2FsIG1hc3Mgb2YgcGVvcGxlIHRv
IGJlDQogZG9pbmcgdGhvc2UgdGhpbmdzPC91PjwvYj4sIGJlZm9yZSBhICh2aXJ0dWFsKSBpbnRl
cmltIGlzIGNhbGxlZC4gQnJhaW5zdG9ybWluZyBvbiBhIHRlbGVjb25mZXJlbmNlIGlzIHJhcmVs
eSBhIGNvbnN0cnVjdGl2ZSB3YXkgdG8gc3BlbmQgdGltZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaG9tYXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+VG8geW91ciBwb2ludCBpdCdzIGltcGFyYXRpdmUgdGhh
dCB0aGUgZGlzY3Vzc2lvbiBjb250aW51ZXMgb24gbGlzdCBhYm91dCB0aGUgY2hhcnRlci4mbmJz
cDsgV2l0aCB0aGF0IGluIG1pbmQgaGVyZSBpcyBhIHN1Z2dlc3RlZCBlZGl0IG9mIHRoZSBwcmV2
aW91c2x5IGZsb2F0ZWQgY2hhcnRlciwgd2l0aCBjb21tZW50cyBpbg0KICgpIHdpdGggSldEIHRh
Z3MuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+VGhlIHB1cnBvc2Ugb2YgdGhlIE1BTkVUIHdvcmtpbmcgZ3JvdXAgaXMgdG8gc3RhbmRh
cmRpemUgSVAgcm91dGluZyBwcm90b2NvbCBmdW5jdGlvbmFsaXR5IHN1aXRhYmxlIGZvciB3aXJl
bGVzcyByb3V0aW5nIGFwcGxpY2F0aW9uIHdpdGhpbiBib3RoIHN0YXRpYyBhbmQgZHluYW1pYyB0
b3BvbG9naWVzIHdpdGggaW5jcmVhc2VkIGR5bmFtaWNzIGR1ZSB0byBub2RlIG1vdGlvbiBvciBv
dGhlciBmYWN0b3JzLiZuYnNwOyA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BcHByb2FjaGVzIGFyZSBpbnRlbmRlZCB0byBiZSBy
ZWxhdGl2ZWx5IGxpZ2h0d2VpZ2h0IGluIG5hdHVyZSwgc3VpdGFibGUgZm9yIG11bHRpcGxlIGhh
cmR3YXJlIGFuZCB3aXJlbGVzcyBlbnZpcm9ubWVudHMsIGFuZCBhZGRyZXNzIHNjZW5hcmlvcyB3
aGVyZSBNQU5FVHMgYXJlIGRlcGxveWVkIGF0IHRoZSBlZGdlcyBvZiBhbiBJUCBpbmZyYXN0cnVj
dHVyZS4gSHlicmlkIG1lc2ggaW5mcmFzdHJ1Y3R1cmVzIChlLmcuLCBhIG1peHR1cmUgb2YgZml4
ZWQgYW5kIG1vYmlsZSByb3V0ZXJzKSBzaG91bGQgYWxzbyBiZSBzdXBwb3J0ZWQgYnkgTUFORVQg
c3BlY2lmaWNhdGlvbnMgYW5kIG1hbmFnZW1lbnQgZmVhdHVyZXMuPC9zcGFuPjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIE1BTkVUIFdH
IGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgbWFpbnRlbmFuY2Ugb2YgT0xTUnYyLCBBT0RWdjIgKEpX
RCBUQkQpLCBETEVQIGFuZCBOSFBELiBPZiBwYXJ0aWN1bGFyIGludGVyZXN0OiBzZWN1cml0eSBl
bmhhbmNlbWVudHMsIGFuZCBlbmNyeXB0aW9uIHNlY3VyaXR5IGV4dGVuc2lvbnMgZm9yIFJGQzU0
NDQuIChKV0Qgd2UgbWF5IHdhbnQgdG8gYnJlYWsgdGhpcyBvdXQgb2YgdGhlIFdHIGFuZCBtYWtl
IGEgbmV3IE1BTkVUIFNlYyB3b3JraW5nIGdyb3VwIHRvIGdyYWIgdGhlIGF0dGVudGlvbiBvZiB0
aG9zZSBpbnRlcmVzdGVkIGluIHNlY3VyaXR5IGFuZCBnZXQgdGhlaXIgcGFydGljaXBhdGlvbi4p
PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+VGhlIE1BTkVUIFdHIHdpbGwgc3RhbmRhcmRpemUgYSBtdWx0aWNhc3QgTUFORVQgcHJv
dG9jb2wgZnJhbWV3b3JrIGJhc2VkIG9uIHByZXZpb3VzIHdvcmsgYW5kIGxlc3NvbnMgbGVhcm5l
ZCBmb3Igc2NvcGVkIGZvcndhcmRpbmcgd2l0aGluIE1BTkVUIG5ldHdvcmtzLiZuYnNwOyBBcyBw
YXJ0IG9mIHRoaXMgZnJhbWV3b3JrIHRoZSBXRyB3aWxsIHByb2R1Y2UgYSB3ZWxsIGRlZmluZWQg
TUFORVQgbXVsdGljYXN0IGZvcndhcmRpbmcgaW5mb3JtYXRpb24gYmFzZS48L3NwYW4+PG86cD48
L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgV0cg
d2lsbCBwcm9kdWNlIGFuIGluZm9ybWF0aW9uYWwgZHJhZnQgb3V0bGluaW5nIGNoYWxsZW5nZXMg
YW5kIGJlc3QgcHJhY3RpY2VzIGZvciBkZXBsb3lpbmcgYW5kIG1hbmFnaW5nIE1BTkVUIG5ldHdv
cmtzLiA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIj5UaGUgTUFORVQgV0cgd2lsbCBpbnRlcmFjdCB3aXRoIHRoZSBQSU0gd29ya2lu
ZyBncm91cCBvbiBpc3N1ZXMgcmVsYXRpbmcgdG8gdGhlIG11bHRpY2FzdCB3b3JrLiZuYnNwOyBU
aGUgV0cgd2lsbCBhbHNvIHBheSBhdHRlbnRpb24gdG8gb3RoZXIgSUVURiBhbmQgSVJURiB3b3Jr
IHRoYXQgaXMgYWRkcmVzc2luZyB0b3BpY3MgcmVsYXRlZCB0byBNQU5FVCBlbnZpcm9ubWVudHMu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+SW4gc3VtbWFyeSwgdGhlIFdHIHdpbGwgZGV2ZWxvcCB0aGUgZm9sbG93aW5nIGRyYWZ0
czo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsYWNrIj5NQU5FVCBNYW5hZ2VtZW50IERvY3VtZW50IChJbmZvcm1hdGlvbmFsKTwvc3Bhbj48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1BTkVUIE1h
aW50ZW5hbmNlIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPiZuYnNwOy0gUkZDNTQ0NCBTZWN1cml0eSBleHRlbnNpb24gKFN0YW5kYXJkcykg
KEpXRCBwb3NzaWJseSBtb3ZlIHRoaXMgdG8gbmV3IHdvcmtpbmcgZ3JvdXApPC9zcGFuPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TUFORVQgTXVsdGlj
YXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayI+IC0gTXVsdGljYXN0IEZJQiAoU3RhbmRhcmRzKTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBBcHIgMjYs
IDIwMTYgYXQgMjo1NSBQTSwgVGhvbWFzIENsYXVzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzppZXRm
QHRob21hc2NsYXVzZW4ub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkB0aG9tYXNjbGF1c2VuLm9y
ZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYmVsaWV2ZSB0aGF0IGFuIHZpcnR1YWwgaW50ZXJp
bSBpcyBwcmVtYXR1cmU6IGEgdGVsZWNvbmZlcmVuY2UgaXMsIG1lY2hhbmljYWxseSwgbGVzcyBp
bmNsdXNpdmUgdGhhbiBhcmUgbWFpbGluZyBsaXN0IGRpc2N1c3Npb25zICh0aW1lLXpvbmVzLCBv
dGhlciBjb21taXRtZW50cywgcmVxdWlyZW1lbnQgb2YNCiBzeW5jaHJvbmljaXR5IG9mIHBhcnRp
Y2lwYXRpb24sIGV0Yy4pLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+RnVydGhlcm1vcmUuLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5VbnRpbCBzdWNoIHRpbWUgdGhhdCBh
IHN0cmF3bWFuIGNoYXJ0ZXIgaXMgcHJvcG9zZWQsDQo8Yj48dT51cGRhdGVkIHRvIHJlZmxlY3Qg
dGhlIHJlYWxpdHkgb2YgdGhlIGdyb3VwPC91PjwvYj4gYXMgc3RpcHVsYXRlZCBieSB0aGUgQUQg
YW5kIGJ5IE1yLiBEZWFuLCBhcyB3ZWxsIGFzIGFkZGl0aW9uYWwgY2hhcnRlciBpdGVtcyBlbWVy
Z2luZyBvbiB0aGUgbGlzdCwgJm5ic3A7YW5kDQo8Yj48dT53aXRoIHJlbGF0aXZlbHkgYnJvYWQg
YW5kIGRlZXAgc3VwcG9ydDwvdT48L2I+IGZvciB0aGUgaW5jbHVkZWQgaXRlbXMgYnkgdGhlIHdv
cmtpbmcgZ3JvdXAsIGhhdmluZyBhbiBpbnRlcmltIC0gdmlydHVhbCBvciBvdGhlcndpc2UgLSBp
cyBub3QgY29uc3RydWN0aXZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIG90aGVyIHdvcmRzLCBpdCBzaG91bGQgYmUg
ZXN0YWJsaXNoZWQgb24gdGhlIGxpc3QgdGhhdCB0aGVyZSBhcmUNCjxiPjx1Pm1lYW5pbmdmdWwg
dGhpbmdzIHRvIGRvPC91PjwvYj4sIGFuZCB0aGVyZSdzIGEgPGI+PHU+bWVhbmluZ2Z1bCBjcml0
aWNhbCBtYXNzIG9mIHBlb3BsZSB0byBiZSBkb2luZyB0aG9zZSB0aGluZ3M8L3U+PC9iPiwgYmVm
b3JlIGEgKHZpcnR1YWwpIGludGVyaW0gaXMgY2FsbGVkLiBCcmFpbnN0b3JtaW5nIG9uIGEgdGVs
ZWNvbmZlcmVuY2UgaXMgcmFyZWx5IGEgY29uc3RydWN0aXZlIHdheSB0byBzcGVuZCB0aW1lLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmVzdCw8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRob21h
czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+U2VudCBmcm9tIG15IGlQYWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiAyMiBBcHIgMjAxNiwgYXQg
MTc6NTAsIFN0YW4gUmF0bGlmZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJhdGxpZmZzdGFuQGdtYWls
LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJhdGxpZmZzdGFuQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IZWxsbyBXRywmbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5EbyB3ZSBuZWVk
IHRvIGhvbGQgYW4gaW50ZXJpbSBtZWV0aW5nICh2aWEgV2ViRVgpIHRvIGRpc2N1c3M/IEknZCBs
aWtlIHRvIGdldCBvcGluaW9ucyBvbiB0aGUgbGlzdCBhYm91dCB0aGF0LiBXZSdsbCBuZWVkIGEg
Y291cGxlIG9mIHdlZWtzIHRvIHNjaGVkdWxlLCBidXQgd2UgY2FuIGRvIHRoYXQuJm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P
bmUgb3RoZXIgcG9pbnQgaW5saW5lOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5PbiBGcmksIEFwciAyMiwgMjAxNiBhdCAxMTo0NSBBTSwgRGVhcmxvdmUs
IENocmlzdG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVz
eXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t
PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk11
bHRpY2FzdCBpcyB0aGUgb2J2aW91cyB0b3AgaXRlbS4gTG90cyBvZiBwb3NzaWJsZSBhcHByb2Fj
aGVzLCB0aW1lIHRvIGRpc2N1c3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R2F0ZXdheXMgZm9yIEFPRFZ2MiBh
dCBTdGFuZGFyZCBpcyBvYnZpb3VzbHkgbm90IHBvc3NpYmxlIHNpbmNlIEFPRFZ2MiBpcyBnb2lu
ZyB0byBiZSBFeHBlcmltZW50YWwNCiBhdCBtb3N0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1hbmFnZW1lbnQg
d2UgZGlkIG9mIGNvdXJzZSBoYXZlIGFuIE5IRFAvT0xTUnYyIGRyYWZ0IGtpbGxlZCBieSBBRC4g
V2hpY2ggc2luY2UgTkhEUC9PTFNSdjIgdXMgYWxsDQogd2UgaGF2ZSAoU01GIGV4Y2VwdGVkKSB0
aGF0IHdhcyBhIGJpdCB0cmlja3kuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB3b3VsZCBoYXZlIHRvIG1ha2Ug
YW4gSVBSIGRlY2xhcmF0aW9uIHRvIHNheSBzb21lIG9mIHdoYXQgSSBtaWdodCBoYXZlIHRvIHNh
eSBhYm91dCBlbmNyeXB0aW9uLg0KIE5vdCB0b2RheS48L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlVuZGVyc3Rv
b2QuIEJ1dCBwbGVhc2UgcmVtZW1iZXIgLSB0aGVyZSdzIG9ubHkgYWJvdXQgYSA1LXdlZWsgZ2Fw
IG5vdyBiZWZvcmUgdGhlIGNoYXJ0ZXIgbmVlZHMgdG8gYmUgY29tcGxldGUgaW4gb3JkZXIgZm9y
IHRoZSBXRyB0byBtZWV0IGluIEJlcmxpbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlN0YW48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt
YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pc3NpbmcgZnJvbSB0aGUgbGlzdCBpcyBhbnkgd29yayBv
biBPTFNSdjIgKG9yIE5IRFApLiBNVC1PTFNSdjIgaXMgZXhwZXJpbWVudGFsLiBUaGF0IHdvdWxk
IG5lZWQNCiBpbXBsZW1lbnRhdGlvbiB0ZXN0cyB0byBhZHZhbmNlIHRvIFBTLiBBbnlvbmUgaW50
ZXJlc3RlZCBpbiB0aGF0IChJ4oCZbSBub3Qgc2F5aW5nIEkgY2FuKT88L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5N
b3JlIGJyb2FkbHkgb24gT0xTUnYyIHRoZXJlIGFyZSB2YXJpb3VzIHRoaW5ncyB0aGF0IGNvdWxk
IGJlIGRvbmUsIGJ1dCB3aGF0IGlzIHJlYWxseSBuZWVkZWQgaXMNCiBwZW9wbGUgd2l0aCBhIHJl
YWwgYXBwbGljYXRpb24uIEFueSB0aGF0IGV4aXN0IHdlcmUgZnJpZ2h0ZW5lZCBhd2F5IGZyb20g
dGhpcyBncm91cC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv
dHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+
Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0K
QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFu
PjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
N0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3
RCI+OiAmbmJzcDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5NCIgdGFy
Z2V0PSJfYmxhbmsiPiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8L2E+DQogJm5ic3A7fCAmbmJzcDs8
Yj5FOiA8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0
YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+PGJyPg0KPC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxp
ZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93
LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFl
c3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5
MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
M0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVn
aXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRm
b3JkLCBTdXJyZXksIEdVMiA3WVA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1hbmV0DQogW21haWx0bzo8YSBo
cmVmPSJtYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0
LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gRGVhbjxi
cj4NCjxiPlNlbnQ6PC9iPiAyMiBBcHJpbCAyMDE2IDE2OjA3PGJyPg0KPGI+VG86PC9iPiA8YSBo
cmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9y
ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW21hbmV0XSBSZWNoYXJ0ZXIgRGlzY3Vzc2lvbjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoy
LjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu
dGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG87dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndo
aXRlIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdB
Uk5JTkcgKioqPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndo
aXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMg
bWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIg
ZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlu
a3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48
L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZs
YWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2Vp
dmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9o
b3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIiB0
YXJnZXQ9Il9ibGFuayI+DQpoZXJlPC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwg
dGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9p
bnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMv
RG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiIHRhcmdl
dD0iX2JsYW5rIj4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNv
bGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzoxLjBwdCA0LjBwdCAxLjBwdCA0LjBwdCI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpjZW50ZXIiPg0K
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPio8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qKg0KPC9zcGFuPjwvc3Ryb25nPjwvc3Bhbj48
c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldBUk5JTkcNCjwvc3Bhbj48L3N0cm9u
Zz48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij4qKio8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RVhURVJOQUwg
RU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6
YXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4uPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5JJ2xsIHN0YXJ0IHRoaW5ncyBvZmYg
YnkgZmxvYXRpbmcgdGhlIGRyYWZ0IHJlLWNoYXJ0ZXIgd2hpY2ggd2FzIHByZXNlbnRlZCBpbiBQ
cmFndWUuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh
Y2siPlRoZSBwdXJwb3NlIG9mIHRoZSBNQU5FVCB3b3JraW5nIGdyb3VwIGlzIHRvIHN0YW5kYXJk
aXplIElQIHJvdXRpbmcgcHJvdG9jb2wgZnVuY3Rpb25hbGl0eSBzdWl0YWJsZSBmb3Igd2lyZWxl
c3Mgcm91dGluZyBhcHBsaWNhdGlvbiB3aXRoaW4gYm90aCBzdGF0aWMgYW5kIGR5bmFtaWMgdG9w
b2xvZ2llcyB3aXRoIGluY3JlYXNlZCBkeW5hbWljcyBkdWUgdG8gbm9kZSBtb3Rpb24gb3Igb3Ro
ZXIgZmFjdG9ycy4mbmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QXBwcm9hY2hlcyBhcmUgaW50ZW5kZWQgdG8gYmUgcmVs
YXRpdmVseSBsaWdodHdlaWdodCBpbiBuYXR1cmUsIHN1aXRhYmxlIGZvciBtdWx0aXBsZSBoYXJk
d2FyZSBhbmQgd2lyZWxlc3MgZW52aXJvbm1lbnRzLCBhbmQgYWRkcmVzcyBzY2VuYXJpb3Mgd2hl
cmUgTUFORVRzIGFyZSBkZXBsb3llZCBhdCB0aGUgZWRnZXMgb2YgYW4gSVAgaW5mcmFzdHJ1Y3R1
cmUuIEh5YnJpZCBtZXNoIGluZnJhc3RydWN0dXJlcyAoZS5nLiwgYSBtaXh0dXJlIG9mIGZpeGVk
IGFuZCBtb2JpbGUgcm91dGVycykgc2hvdWxkIGFsc28gYmUgc3VwcG9ydGVkIGJ5IE1BTkVUIHNw
ZWNpZmljYXRpb25zIGFuZCBtYW5hZ2VtZW50IGZlYXR1cmVzLjwvc3Bhbj48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBNQU5FVCBXRyBp
cyByZXNwb25zaWJsZSBmb3IgdGhlIG1haW50ZW5hbmNlIG9mIE9MU1J2MiwgQU9EVnYyLCBETEVQ
IGFuZCBOSFBELiBPZiBwYXJ0aWN1bGFyIGludGVyZXN0OiBib3JkZXIgYmVoYXZpb3IgYmV0d2Vl
biBNQU5FVCBuZXR3b3JrcyBhbmQgZml4ZWQgSVAgbmV0d29yayBpbmZyYXN0cnVjdHVyZXMsIGVu
aGFuY2UgQU9EVnYyIGdhdGV3YXkgZnVuY3Rpb25hbGl0eTsgc2VjdXJpdHkgZW5oYW5jZW1lbnRz
LCBlbmNyeXB0aW9uIHNlY3VyaXR5IGV4dGVuc2lvbnMgZm9yIFJGQzU0NDQuIDwvc3Bhbj48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBN
QU5FVCBXRyB3aWxsIHN0YW5kYXJkaXplIGEgbXVsdGljYXN0IE1BTkVUIHByb3RvY29sIGZyYW1l
d29yayBiYXNlZCBvbiBwcmV2aW91cyB3b3JrIGFuZCBsZXNzb25zIGxlYXJuZWQgZm9yIHNjb3Bl
ZCBmb3J3YXJkaW5nIHdpdGhpbiBNQU5FVCBuZXR3b3Jrcy4mbmJzcDsgQXMgcGFydCBvZiB0aGlz
IGZyYW1ld29yayB0aGUgV0cgd2lsbCBwcm9kdWNlIGEgd2VsbCBkZWZpbmVkIE1BTkVUIG11bHRp
Y2FzdCBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIGJhc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIFdHIHdpbGwgcHJvZHVj
ZSBhbiBpbmZvcm1hdGlvbmFsIGRyYWZ0IG91dGxpbmluZyBjaGFsbGVuZ2VzIGFuZCBiZXN0IHBy
YWN0aWNlcyBmb3IgZGVwbG95aW5nIGFuZCBtYW5hZ2luZyBNQU5FVCBuZXR3b3Jrcy48L3NwYW4+
PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5U
aGUgTUFORVQgV0cgd2lsbCBpbnRlcmFjdCB3aXRoIHRoZSBQSU0gd29ya2luZyBncm91cCBvbiBp
c3N1ZXMgcmVsYXRpbmcgdG8gdGhlIG11bHRpY2FzdCB3b3JrLiZuYnNwOyBUaGUgV0cgd2lsbCBh
bHNvIHBheSBhdHRlbnRpb24gdG8gb3RoZXIgSUVURiBhbmQgSVJURiB3b3JrIHRoYXQgaXMgYWRk
cmVzc2luZyB0b3BpY3MgcmVsYXRlZCB0byBNQU5FVCBlbnZpcm9ubWVudHMuPC9zcGFuPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SW4gc3Vt
bWFyeSwgdGhlIFdHIHdpbGwgZGV2ZWxvcCB0aGUgZm9sbG93aW5nIGRyYWZ0czo8L3NwYW4+PG86
cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5NQU5F
VCBNYW5hZ2VtZW50IERvY3VtZW50IChJbmZvcm1hdGlvbmFsKTwvc3Bhbj48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1BTkVUIE1haW50ZW5hbmNlIDwv
c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu
YnNwOy0gUkZDNTQ0NCBTZWN1cml0eSBleHRlbnNpb24gKFN0YW5kYXJkcyk8L3NwYW4+PG86cD48
L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gLSBFbmhhbmNlZCBB
T0RWdjIgZ2F0ZXdheSBleHRlbnNpb24gKFN0YW5kYXJkcyk8L3NwYW4+PG86cD48L286cD48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5NQU5FVCBNdWx0aWNhc3Q8L3NwYW4+
PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gLSBNdWx0
aWNhc3QgRklCIChTdGFuZGFyZHMpPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhpcyB3aWxsIGxpa2VseSBiZSBjb25z
aWRlcmVkIHRvbyBicm9hZCB0byBwYXNzLiZuYnNwOyBXZSB3aWxsIGxpa2VseSBuZWVkIHRvIGN1
dCBzb21lIGFuZCBmb2N1cyB0aGUgd29yay4mbmJzcDsgRm9yIG1lIHBlcnNvbmFsbHkgSSBrbm93
IEkgaGF2ZSB0aGUgdGltZSBhbmQgYmFja2luZyB0byB3b3JrIG9uIHRoZSBNdWx0aWNhc3QgcGll
Y2UuJm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siPkp1c3Rpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqPGJyPg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz
IGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPg0KcmVjaXBpZW50IGFuZCBtYXkg
YWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNp
cGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNl
bmRlci48YnI+DQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBv
c2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPg0KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90
aGVyIHBlcnNvbi48YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv
dHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1h
bmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg
aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+
PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWls
aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2Js
YW5rIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox
Mi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxh
bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N
CjwvaHRtbD4NCg==

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B1E8DGLKXM0002VGREEN_--


From nobody Wed Apr 27 12:16: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 74B1312D575 for ; Wed, 27 Apr 2016 12:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.143
X-Spam-Level: 
X-Spam-Status: No, score=-1.143 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, TRACKER_ID=1.306] 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 5hg2Ue5APnUX for ; Wed, 27 Apr 2016 12:16:52 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 E965712D571 for ; Wed, 27 Apr 2016 12:16:46 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id u23so5685093vkb.2 for ; Wed, 27 Apr 2016 12:16:46 -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=r/kB9nosjAfIs/v/GkOL80QsfyvGMGVxAsLySgyzLKc=; b=fjZupseyYnuHJz+FaciChA/MV/3iN0iGHcjjbqm00EV+t03rz7Ioj6yd8Y9D3JHj/I t9t+r7apHm9bHphE3nLzyMagHjsknjGZt34OUONxdQLjIpeieZksQCod112uOMHakjsP e25om77Oxns1y2NB9W4Zk49GmE8TjSfSW1wGkSrdA2kFWLsX7PmEGa1YLdpbmUZNzSnL Sldr30Zvd2EAhjFB7AC54/Vf5W9wyPOcJfILGYmppR+V+XXOZVqFmxt6GquDuVV0vaWl ihX3JTyFim6KJoOmAJScGN7RhcqKgNR+DcL8jomWDTBhN0zAgq5UqXntCfDupx9vi7NE yVvw==
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=r/kB9nosjAfIs/v/GkOL80QsfyvGMGVxAsLySgyzLKc=; b=k0gEvrqU6clrUjtAnZust32lVc0Jd61c33SI9Lwo6CjkcvHbch5Jx2DGAAujGzRDu9 jUuIcwdovh99ZnpqTVBkic+mEIfBsT3onEtRMKjt7JfmnoEI0bTH1ifNso8Djv/bVCtL VZTyxYwHVpntL1YrSPF0wGi0iVKgzziwIJry4QbA3cYrMoQkgcBuMz0AcnTBGXHb0w27 R3CQEA9DuKDu/SknPk2PJ/mbPUdrhL6tbNaF71HDeAXHqJVAVZIwQxTNH1M+n6jToXPV oNfhRMQzJ30hh3q+nCwI+0ugXYCnV9eEBanWb1NoAJf2nnU9eL5hU9kALC0KB1UQa+lh kVRg==
X-Gm-Message-State: AOPr4FXIrNIFQfUPGhF5+mLiAJzYHxRB/C7supIhOTO65wBhsb/YatN/03LxT6VyklYDrvtYnpzbLW0G5vt/hg==
MIME-Version: 1.0
X-Received: by 10.31.160.212 with SMTP id j203mr382256vke.10.1461784605900; Wed, 27 Apr 2016 12:16:45 -0700 (PDT)
Received: by 10.176.65.40 with HTTP; Wed, 27 Apr 2016 12:16:45 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>    
Date: Wed, 27 Apr 2016 20:16:45 +0100
Message-ID: 
From: Victoria Mercieca 
To: "Dearlove, Christopher (UK)" 
Content-Type: multipart/alternative; boundary=001a1142e5cc2c474405317c400d
Archived-At: 
Cc: Christopher Dearlove , Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 27 Apr 2016 19:16:55 -0000

--001a1142e5cc2c474405317c400d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Chris,



On Mon, Apr 25, 2016 at 10:20 AM, Dearlove, Christopher (UK) <
chris.dearlove@baesystems.com> wrote:

> With regard to your validity time point, we here have a tradeoff. If you
> allow that feature, it significantly impacts on the approach that was
> coming together on as best you can end to end encryption.
>
>
>
> So the question is, is this a feature that=E2=80=99s really wanted? Unfor=
tunately
> I think we know that the answer to that is, we don=E2=80=99t know because=
 we don=E2=80=99t
> have any experience. My view would be that in the tradeoff of an untested
> feature (unless I=E2=80=99m wrong about that) and the security complicati=
on,
> security wins and drop the feature. If there is some real requirement, th=
en
> there=E2=80=99s a discussion. (Questions like how often the intermediate =
routers
> actually have any knowledge - typically links break for unexpected rather
> than expected reasons. Andan intermediate router could possibly use a
> validity time to influence its behaviour.) Note that dropping the ability
> of intermediate routers to modify/set still allows validity times per rou=
te
> to be set at endpoints.
>
>
In the RREQ, the route contained within the message is the route to
OrigPrefix. Why would RREQ_Gen want to limit that? I can understand
intermediate routers might not want to commit resources for too long, but
can't see why RREQ_Gen would ever want to limit the time the route to its
Router Client is available? Similarly for the route to TargPrefix in the
RREP. Should we remove Validity Times altogether?

Kind regards,
Victoria.


>
With regard to the acknowledgements, the problem (with regard to security)
> comes from trying to do two jobs with the same message - end to end route
> advertisement and hop by hop acknowledgement. I understand the reasons -
> saving bytes and message types. (I would have to study the protocol reall=
y
> hard to identify if any message types can be folded together and recognis=
ed
> by content rather than type efficiently. This I do not expect to do.) Aga=
in
> a tradeoff. This one is in discussion space, though that needs people who
> understand both sides of the issue, including the details of the
> bidirectionality mechanism. Of course, as has been said, we need one of
> those.
>
>
>
> *-- *
>
>
>
>
> *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
> *Sent:* 23 April 2016 10:55
> *To:* Christopher Dearlove
> *Cc:* ietf@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc
> Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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
> .*
>
> Hi Chris,
>
>
>
> These have both been in the draft in some form since before I got
> involved... but I'll do my best to explain.
>
>
>
> - For Validity Time, its a way to advertise that you would only support
> the route contained in the message for a certain period of time. The
> originator might use this, but the draft was written to allow any
> intermediate node to be able to add it or update it too. The route create=
d
> in the Local Route Set has an expiration time associated with it, based o=
n
> the received validity time.
>
> - For the AckReq address, its so that you can add into a RREP a request
> for an acknowledgement, so that you don't have to have a different messag=
e
> type altogether for working out whether links to neighbors are
> bidirectional, and also, since you only care about bidirectionality on
> routes that are being set up, you dont need to constantly monitor all
> neighbors.
>
>
>
>
>
> In order to avoid the potential AckReq-related changes to each message,
> maybe we do need to introduce a different message specifically for this. =
We
> could maybe use RREP_Ack to both request and acknowledge? It means an ext=
ra
> message of control traffic that needs to be sent, maybe one extra message
> per hop on the path of a RREP, but it could still be limited to neighbors
> which have participated in the route discovery rather than monitoring all
> neighbors at all times.
>
>
>
> This message could maybe also include "I'm happy to route anywhere for a
> certain amount of time", sort of like willingness in OLSR/OLSRv2. So
> instead of having a validity time per route, its a validity time per
> neighbor. Then, for RREQ and RREP, only the metric value would change in
> transit, as discussed. However, that leads to some issues with deciding
> what a route's expiration time is. You might know how long the next hop
> router is valid for, but what if a router beyond that, which was also par=
t
> of the route, had a lower validity time? You couldn't determine the real
> validity time. Do we remove the route expiration time altogether to avoid
> this issue? In which case, we would have to rely on RERR messages being
> sent for routes which become invalid when the neighbor's validity time ha=
s
> expired? So neighbor validity time expiration is treated the same as a li=
nk
> break.
>
>
>
> What do you think?
>
>
>
> Kind regards,
>
> Victoria.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
> chris@mnemosyne.demon.co.uk> wrote:
>
> Pretty much all of the discussion has been assuming only a metric value
> change. With multiple things changing many of the ideas go out of the
> window. That reinforces the point about not making specifications now tha=
t
> might turn out to be wrong for ICVs.
>
>
>
> Ignoring how this misunderstanding happened, I'll start by asking why.
> Metric changing I understand. Why the other two? (there's a partial
> explanation of one). What alternatives have people implemented in
> comparable protocols?
>
> --
>
> Christopher Dearlove
>
> christopher.dearlove@gmail.com (iPhone)
>
> chris@mnemosyne.demon.co.uk (home)
>
>
> On 23 Apr 2016, at 00:26, Victoria Mercieca  wrote:
>
> Hi all,
>
>
>
> Continued in this thread because the other one seems to be more about TLV
> types and metric type numbers, whereas this is about
> regeneration/forwarding.
>
>
>
> To recap, in the current draft, there are 3 things that might change at
> each hop:
> - the metric value (happens in RREQ and RREP),
> - adding/changing Validity Time using the Validity Time TLV (can happen i=
n
> RREQ and RREP),
> - adding an address (and corresponding value in the AddressType TLV to
> indicate how to interpret the address) to indicate the address from which
> an RREP_Ack is expected, to accomplish the bidirectionality check (can
> happen in RREP).
>
> If we define a certain portion of the message as immutable and include th=
e
> ICV to verify that part, end to end:
> - The metric value would be excluded from the ICV since it needs changing
> at each hop.
> - Would adding a Validity Time TLV at an intermediate hop be acceptable?
> The whole TLV could be removed in order to calculate the ICV?
>
> - Would adding an address cause issues for the ICV, because it's in the
> address block? Could the rule be "if it contains an AckReq address, remov=
e
> it (and the corresponding value in the AddressType TLV), before checking
> the ICV", is that OK? Or would we need to avoid touching the ICV'ed part =
of
> the message altogether, maybe put the AckReq address in a separate Addres=
s
> Block, with an extra AddressType TLV following that address block? Is the=
re
> a way to accomplish this?
>
>
>
> Also, to be thorough, do we need to consider RERR messages while we
> discuss regeneration vs forwarding?
>
> - RERR (sent when a link breaks) is a way of saying "I've lost my route s=
o
> I'm telling others" and "you were my next hop, so now I've also lost my
> route, I'll tell others", etc. It's going to be tailored at each step to
> include the relevant routes that got deleted, it's not one message being
> sent end-to-end like RREQ and RREP are.
>
> - However, RERR (sent when a source of traffic is sending data on a route
> which comes through you, and you want to tell the Packet Source's router =
to
> delete the route) could be seen as an end-to-end message which all
> intermediate routers learn from, similar to RREQ and RREP. It reports one
> route, and doesn't need changing at intermediate hops, so could be
> protected with ICV.
>
> - Would it be OK to only require a message ICV if a PktSource address was
> included, i.e. when the message needs to go via a number of intermediate
> hops to PktSource's router? All other RERRs are intended to be one-hop
> messages, which may in turn prompt other one-hop messages, etc..., and a
> packet ICV might be more appropriate?
>
>
>
> Kind regards,
>
> Victoria.
>
>
>
> On Thu, Mar 17, 2016 at 5:26 PM,  wrote:
>
>
>
> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>
>
> Yes, I meant AODVv2, thanks for the catch.
>
>
>
> So is your (Thomas) proposed base specification a hop count only metric?
>
>
>
> No, the would be silly as base specification, given that hop count mostly
> is useless.
>
>
>
> As base specification I would simply say =E2=80=9CInclude a Metric Type M=
essage
> TLV with a value field, and a 7182 Message TLV & Timestamp=E2=80=9D as we=
 do in
> OLSRv2 (with the appropriate verbiage as to generation and processing).
>
>
>
> With the message generated by the originator of the RREQ/RREP and *not*
> deconstructed/reconstructed/reordered (as is the risk with =E2=80=9Cregen=
eration)
> allows knowing that it would be *only* that metric field being modified
> (other than hop count/limit) for when eventually writing up the extension=
.
>
>
>
> (Actually doesn=E2=80=99t the current specification only define hop count=
, or has
> that changed in latest draft?)
>
>
>
> No. That is one of the issues I raise in my original. For some reason, it
> cites RFC6551, which is a ROLL document and which has in its abstract tha=
t:
>
>
>
>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>
>    compared with traditional wired and ad hoc networks that require the
>
>    specification of new routing metrics and constraints.
>
>
>
> I.e. this document cites a metric document which clearly claims to be
> inapplicable in ad hoc networks. I note that this is another thing I=E2=
=80=99ve
> raised for years without seeing it attempted resolved.
>
>
>
> Best,
>
>
>
> Thomas
>
>
>
>
>
>
>
> *--*
>
>
>
>
> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
> ]
> *Sent:* 17 March 2016 17:10
> *To:* Dearlove, Christopher (UK)
> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>
>
> OK, so we have a message that mutates by:
>
> - Modifying hop count/limit.
>
> - Modifying a metric value.
>
> Anything else?
>
>
>
> As mutating (other than hop count/limit) messages aren=E2=80=99t covered =
by 5444
> or any derivative document (but only recommended against, not banned) tha=
t
> you may need to make the message otherwise immutable (no deconstruction a=
nd
> rebuilding, other than guaranteed unchanging) that would have to be
> specified by AODVv2. (Easy to say, but needs saying.)
>
>
>
> With you so far.
>
>
>
> Then that information is not in a guaranteed fixed location given by a
> simple offset. So any signature algorithm that finds it and ignores it or
> aggregates on it is specific to OLSRv2.
>
>
>
> Surely you mean AODVv2
>
>
>
> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AODVv2
> specialised variant. Which is the sort of thing that the message specific
> TLV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cbut ig=
nore the value of
> this specific TLV should it occur=E2=80=9D being in the general space. Ho=
wever it
> can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like tha=
t TLV,
> except if an X TLV is present, set its value field to zero=E2=80=9D).
>
>
>
> Messy, but could work.
>
>
>
> Not that messy, actually, although clearly not as nice as =E2=80=9Cfixed =
offset=E2=80=9D.
>
>
>
> That said, I am arguing for the base spec being:
>
>
>
>             =E2=80=9Cmake the message otherwise immutable (no deconstruct=
ion and
> rebuilding, other
>
>              than guaranteed unchanging)=E2=80=9D which is afforded by fo=
rwarding
>
>
>
>                                     +
>
>
>
>             RFC7182 Timestamps and ICVs.
>
>
>
>                                     +
>
>
>
>             RFC7183 style text bringing it all together.
>
>
>
> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would ve=
ry be an
> experimental extension.
>
>
>
> What I object to is, if the base spec specifically renders such extension=
s
> impossible
>
>
>
>
>
>
>
> *--*
>
>
>
>
> *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:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
> ]
> *Sent:* 17 March 2016 16:48
> *To:* Dearlove, Christopher (UK)
> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] Message integrity and message mutability (was RE:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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
> .*
>
> Hi all,
>
>
>
> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com>:
>
>
>
> Good point about whether you just pass on one cost or a set of costs. As =
I
> said, not looked at details - I will, when time permits. One cost is much
> easier, and yes, it reduces the fixed size aggregated signatures problem =
to
> =E2=80=9Cjust=E2=80=9D one of computational load.
>
>
>
> For the record, Thomas=E2=80=99 understanding is correct; the cost is one
> aggregated value.
>
>
>
> Best regards,
>
> Lotte Steenrbink
>
>
>
>
>
> *--*
>
>
>
>
> *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
> ]
> *Sent:* 17 March 2016 16:38
> *To:* Dearlove, Christopher (UK)
> *Cc:* Mobile Ad Hoc Networks mailing list
> *Subject:* Re: Message integrity and message mutability (was RE: [manet]
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
>
>
>
> **** 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 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
>
>
>
> I appreciate Thomas=E2=80=99s comments about the limitations of message
> regeneration, but I would be a bit less absolute.
>
>
>
> The issues over end to end authentication and more advanced signatures ar=
e
> valid. I need to read the given reference on aggregate signatures to
> increase my knowledge (thanks for it), but my understanding of the
> possibilities in this field may offer a solution to the problem, but with
> some other issues (possibly including a new type of TLV).
>
>
>
> But the hop count/limit point I don=E2=80=99t fully agree with, you can r=
egenerate
> with an incremented/decremented count/limit, which leaves the ability to
> prevent messages propagating indefinitely, including expanding ring
> searches, and retains the ability to use RFC 5497 interval and validity
> times that might be useful with an expanding ring search (or might not).
>
>
>
> But the key issue is that AODVv2 wants to accumulate metrics. I still
> haven=E2=80=99t got to the bottom of many details here, but let=E2=80=99s=
 for the moment
> just consider that conceptually.
>
>
>
> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft attempts =
to do an end to
> end of some information, not this information. I=E2=80=99m not sure if th=
at=E2=80=99s
> useful (and the specialised format is better avoided if possible). Other
> approaches are hop by hop (might as well use packet signatures) and share=
d
> key (might as well go hop by hop). Pairwise signatures for each pair of
> routers I=E2=80=99m discounting as scaling terribly. In the interests of
> completeness let=E2=80=99s mention not accumulating metrics, which puts u=
s back to
> hop count and that=E2=80=99s not ideal either.
>
>
>
> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=80=
=99ve seen about
> aggregating, but that has some issues of its own, even apart from
> computational load.) I=E2=80=99d love to be proved wrong - someone with t=
he perfect
> solution to come along.
>
>
>
> Which means that either we make an arbitrary choice - which will be
> disagreed with, but needs discussing first - or create something flexible=
.
> Unfortunately flexible in that regard constrains in others, e.g. some
> (many? most?) aggregating signatures need fixed data sizes (which we can =
do
> by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but tha=
t has a cost too).
>
>
>
> I have been told by people much more well versed in this than I in
> cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>
>
>
> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does th=
at mean that the
> message grows as it is being forwarded, and that the recipient of a
> RREQ/RREP will know the individual costs of each path segment? My
> understanding is, that the recipient will get =E2=80=9Cthe sum the costs =
of each
> path segment=E2=80=9D which should be fitting within a fixed size?
>
>
>
> Thomas
>
>
>
>
>
>
>
>
> Sorry, no answers, just comments. And I=E2=80=99m not addressing Thomas=
=E2=80=99s later
> points here.
>
>
>
> *--*
>
>
>
>
> *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 ] *O=
n
> Behalf Of *ietf@thomasclausen.org
> *Sent:* 17 March 2016 16:00
> *To:* Mobile Ad Hoc Networks mailing list
> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of big
> ticket Items
>
>
>
>
>
> **** 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.
>
>
>
> Dear all,
>
>
>
> Apologies for not having gotten this done sooner - day-job leaving few
> spare cycles.
>
>
>
> I=E2=80=99ve previously offered reviews and comments, and some of those h=
ave been
> addressed in the latest I-D =E2=80=94 others have not, but should be. I r=
ecall that
> there was some mail attempting to rebut parts of the review, and I will d=
ig
> it out and reply to that.
>
>
>
> With that being said, I have reviewed the latest version of the document,
> and full details will be forthcoming. There=E2=80=99re a couple of
> big-ticket/architectural items that I want to address up front, as I
> believe that before we have those hammered out, it will be useless to go
> into details. Note, I do not claim that this is an exhaustive list of =E2=
=80=9Cbig
> ticket items=E2=80=9D, but that=E2=80=99s as far as I have gotten in thin=
king this through.
>
>
>
> I also bring these up as they are items that have been brought up
> repeatedly over the past years, but not resolved nor discussed.
>
>
>
> *Loops*
>
> Just to bring this out: I share Chris=E2=80=99 worry about conflicting an=
d
> concurrent statements from the authors on =E2=80=9CThere are no loops pos=
sible=E2=80=9D and
> =E2=80=9CWe need to fix two situations where loops can occur=E2=80=9D and=
 =E2=80=9Cwe are still
> investigating some loop conditions=E2=80=9D
>
>
>
> I particularly worry that this is not a discussion had in public, but
> apparently in some other forum=E2=80=A6
>
>
>
>
>
> *Intermediate Route Replies, and all of section 10*
>
> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=80=
=9D, which is
> incoherent with the intended status indicated for this document.
>
>
>
> Specifically, and this is not unrelated to the point about loops above,
> intermediate RREPs (section 10.3) are a potential source for loops.
>
>
>
> Expanding Ring Multicast (section 10.1) is not documented in a way that
> can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=E2=
=80=9D below, it is
> in the present form of this protocol impossible), etc.
>
>
>
>
>
> *Forwarding-vs-regeneration*
>
> Recent exchanges on the list made me understand that protocol control
> messages are *not* forwarded, but are consumed at each hop, then a new
> message with (almost-but-not-quite) the same content is generated and
> transmitted.
>
>
>
> I have thought some more on this (& read some of the exchanges on the lis=
t
> on this topic by Chris, Ulrich, and others), and I am convinced that this
> is not the right way to go, *at least* for the following reasons:
>
>
>
>
>
>             o          *It renders the hop-limit/hop-count fields in the
> RFC5444 message header useless.*
>
>                         This would not be bad if the functionality offere=
d
> by those fields was not useful
>
>                         =E2=80=94 sadly, it is. For example, for scope li=
mited
> flooding (expanding ring search, and
>
>                         such) which may be of interest, and which require
> hop-limit.
>
>                         A hop-count field may also provide a =E2=80=9Cche=
ap=E2=80=9D (in
> terms of overhead) additional piece
>
>                         of information to use conjunctively with a =E2=80=
=9Creal=E2=80=9D
> metric.
>
>
>
>                         The only practical solution would be to
> re-introduce these functions by way of inserting a
>
>                         MessageTLV =E2=80=94 which (i) is not specified i=
n this
> document, and (ii) which would just
>
>                         serve to render messages bigger than strictly
> needed.
>
>
>
>                         Scope limited flooding  does seem to be a
> necessary requirement, if for no
>
>                         other reason than to prevent information from
> =E2=80=9Ccirculating forever in the network=E2=80=9D.
>
>
>
>             o          *It makes end-to-end authentication unnecessarily
> hard.*
>
>                         I think Chris called this out already, but it
> bears repeating: S generates a message
>
>                         (say, a RREQ), and includes an ICV calculated ove=
r
> the content of the message.
>
>                         For any recipient to be able to validate the ICV,
> the message has to be exactly
>
>                         the same =E2=80=94 not just in content, but in st=
ructure =E2=80=94
> as what was generated.
>
>
>
>                         =E2=80=9CRegenerating=E2=80=9D rather than =E2=80=
=9Cforwarding=E2=80=9D messages
> means, that the intermediate
>
>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ ma=
y chose a
> different structure (e.g., include TLVs
>
>                         in a different order).
>
>
>
>                         The proposal from
> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>
>                         is to add constraints on (i) the set of elements
> to include in a signature and (ii) the
>
>                         order of these elements.
>
>
>
>                         One problem with that approach is (i): if an
> extension adds a message TLV, or an
>
>                         Address TLV, to a message, then that will not be
> =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>
>                         Rather for *each* extension developed, an =E2=80=
=9Cupdates
> e2esec=E2=80=9D clause needs to be done.
>
>
>
>                         I=E2=80=99d say that this approach would be prone=
 to
> errors =E2=80=94 and add entropy to the process
>
>                         of designing protocol extensions. The alternative=
,
> a message being generated by the
>
>                         source and *forwarded* (as we do in OLSRv2, for
> example) would allow ICV TLVs
>
>                         (even, allow reuse of those specified for OLSRv2)
> for covering a message and
>
>                         extensions.
>
>
>
>                         =E2=80=9CBut what about the metrics value which w=
ill
> change on each hop=E2=80=9D, you may say?
>
>                         Fortunately, that is relatively easy to handle:
> simply zero out the value of that TLV when
>
>                         generating or verifying the ICV MessageTLV. And
> use Packet-TLVs for hop-by-hop
>
>                         authentication, if needed (but, see below).
>
>
>
>             o          *It prevents the use of more clever/advanced
> signature schemes/ICVs*
>
>                         Aggregate signature algorithms (
> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>
>                         exist, and an interesting use-case can be found i=
n
> also reactive protocols, allowing verifying
>
>                         not =E2=80=9Cjust=E2=80=9D the end points, but al=
so the
> intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D
>
>                         discussed above, or something smarter).
>
>                         Regeneration of messages, rather than forwarding,
> renders that impossible (or, if used,
>
>                         updating to
> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>
>
>
> There are other reasons, but the above are those that jump at me as
> immediate show-stoppers.
>
>
>
> I do honestly not see what possible benefit there is from =E2=80=9Cregene=
ration=E2=80=9D =E2=80=94
> but I see very clear inconveniences, and security is not the least of
> these. Insisting on =E2=80=9Cregeneration=E2=80=9D requires development o=
f =E2=80=9Cnon-general
> workarounds=E2=80=9D as pointed out above.
>
>
>
> *Security Considerations*
>
> This is an always thorny subject. When OLSRv2 was going through the
> process we got a thorough education in how little we knew about security
> from the SEC-ADs, and had to spend about a year or so developing RFC7183.
> The bottom line is, that this protocol needs its =E2=80=9CRFC7183  equiva=
lent=E2=80=9D,
> either as part of the main document, or as an independent document.
> currently, that is not the case.
>
>
>
> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration from R=
FC7183
> might be aw good idea, as that was the most recent that went through the
> SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to implement=E2=
=80=9D security
> mechanism most be specified (I think the right term was =E2=80=9CMUST imp=
lement,
> SHOULD use=E2=80=9D), in sufficient detail to ensure interoperable implem=
entations.
>
>
>
> As an example, both [RFC6130] and [RFC7181] set out that that:
>
>
>
>       On receiving a ... message, a router MUST first check if the
>
>       message is invalid for processing by this router
>
>
>
> and then proceed to give a number of conditions that, each, will lead to =
a
> rejection of the message as "badly formed and therefore invalid for
> processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That gav=
e a =E2=80=9Chook=E2=80=9D for
> RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message gener=
ation.
>
>
>
> If I was to do RFC7181/RFC6130 today, I would include that directly into
> the protocol specifications. It turned out to be more overhead (and slow
> down publication anyways) to do it as separate documents.
>
>
>
> Secondly, we need to be a lot more rigid in terms of what ICVs,
> Timestamps, etc. are added/removed, and what that brings.
>
>
>
> For example (with the assumption that messages are *forwarded* and *not*
> regenerated), this could be one option:
>
>
>
>                         o          When a RREQ, RREP message is generated=
,
> add an ICV Message TLV, which is calculated 
>
>                                      =E2=80=A6(take inspiration from RFC7=
183 here)
>
>
>
> ...
>
> [Message clipped]
> _______________________________________________
> 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
>
>
>
> ********************************************************************
> 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.
> ********************************************************************
>

--001a1142e5cc2c474405317c400d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Chris,



On Mon, Apr 25, 2016 at 10:20 AM, De=
arlove, Christopher (UK) <chris.dearlove@baesystems.com>=
; wrote:











With regard to your valid=
ity time point, we here have a tradeoff. If you allow that feature, it sign=
ificantly impacts on the approach that was coming together
 on as best you can end to end encryption.


=C2=A0


So the question is, is th=
is a feature that=E2=80=99s really wanted? Unfortunately I think we know th=
at the answer to that is, we don=E2=80=99t know because we don=E2=80=99t ha=
ve any
 experience. My view would be that in the tradeoff of an untested feature (=
unless I=E2=80=99m wrong about that) and the security complication, securit=
y wins and drop the feature. If there is some real requirement, then there=
=E2=80=99s a discussion. (Questions like how often
 the intermediate routers actually have any knowledge - typically links bre=
ak for unexpected rather than expected reasons. Andan intermediate router c=
ould possibly use a validity time to influence its behaviour.) Note that dr=
opping the ability of intermediate
 routers to modify/set still allows validity times per route to be set at e=
ndpoints.


<=
/div>

In the RREQ, the route contained with=
in the message is the route to OrigPrefix. Why would RREQ_Gen want to limit=
 that? I can understand intermediate routers might not want to commit resou=
rces for too long, but can't see why RREQ_Gen would ever want to limit =
the time the route to its Router Client is available? Similarly for the rou=
te to TargPrefix in the RREP. Should we remove Validity Times altogether?

Kind regards,
Victoria.

=C2=A0=C2=A0
=



With regard to the acknow=
ledgements, the problem (with regard to security) comes from trying to do t=
wo jobs with the same message - end to end route advertisement
 and hop by hop acknowledgement. I understand the reasons - saving bytes an=
d message types. (I would have to study the protocol really hard to identif=
y if any message types can be folded together and recognised by content rat=
her than type efficiently. This
 I do not expect to do.) Again a tradeoff. This one is in discussion space,=
 though that needs people who understand both sides of the issue, including=
 the details of the bidirectionality mechanism. Of course, as has been said=
, we need one of those.


=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: Victoria Mercieca [mailto:vmercieca0@gmail.com]


Sent: 23 April 2016 10:55

To: Christopher Dearlove

Cc: ietf=
@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad Hoc Networks =
mailing list

Subject: Re: [manet] Message integrity and message mutability (was R=
E: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)=



=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.=









Hi Chris,




=C2=A0






These have both been in the draft in some form since=
 before I got involved... but I'll do my best to explain.=





=C2=A0






- For Validity Time, its a way to advertise that you=
 would only support the route contained in the message for a certain period=
 of time. The originator might use this, but the draft was written to allow=
 any intermediate node to be able
 to add it or update it too. The route created in the Local Route Set has a=
n expiration time associated with it, based on the received validity time.<=
u>






- For the AckReq address, its so that you can add in=
to a RREP a request for an acknowledgement, so that you don't have to h=
ave a different message type altogether for working out whether links to ne=
ighbors are bidirectional, and also, since
 you only care about bidirectionality on routes that are being set up, you =
dont need to constantly monitor all neighbors.






=C2=A0






=C2=A0






In order to avoid the potential AckReq-related chang=
es to each message, maybe we do need to introduce a different message speci=
fically for this. We could maybe use RREP_Ack to both request and acknowled=
ge? It means an extra message of control
 traffic that needs to be sent, maybe one extra message per hop on the path=
 of a RREP, but it could still be limited to neighbors which have participa=
ted in the route discovery rather than monitoring all neighbors at all time=
s.=C2=A0






=C2=A0






This message could maybe also include "I'm =
happy to route anywhere for a certain amount of time", sort of like wi=
llingness in OLSR/OLSRv2. So instead of having a validity time per route, i=
ts a validity time per neighbor. Then, for RREQ
 and RREP, only the metric value would change in transit, as discussed. How=
ever, that leads to some issues with deciding what a route's expiration=
 time is. You might know how long the next hop router is valid for, but wha=
t if a router beyond that, which was
 also part of the route, had a lower validity time? You couldn't determ=
ine the real validity time. Do we remove the route expiration time altogeth=
er to avoid this issue? In which case, we would have to rely on RERR messag=
es being sent for routes which become
 invalid when the neighbor's validity time has expired? So neighbor val=
idity time expiration is treated the same as a link break.





=C2=A0






What do you think?






=C2=A0






Kind regards,






Victoria.






=C2=A0






=C2=A0






=C2=A0






=C2=A0






=C2=A0








=C2=A0




On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlov=
e <chri=
s@mnemosyne.demon.co.uk> wrote:






Pretty much all of the discussion has been assuming =
only a metric value change. With multiple things changing many of the ideas=
 go out of the window. That reinforces the point about not making specifica=
tions now that might turn out to be
 wrong for ICVs.






=C2=A0






Ignoring how this misunderstanding happened, I'l=
l start by asking why. Metric changing I understand. Why the other two? (th=
ere's a partial explanation of one). What alternatives have people impl=
emented in comparable protocols?



-- =C2=A0




Christopher Dearlove












On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmail.com> wrote:
















Hi all,






=C2=A0






Continued in this thread because the other one seems=
 to be more about TLV types and metric type numbers, whereas this is about =
regeneration/forwarding.






=C2=A0






To recap, in the current draft, there are 3 things t=
hat might change at each hop:


- the metric value (happens in RREQ and RREP), 

- adding/changing Validity Time using the Validity Time TLV (can happen in =
RREQ and RREP),


- adding an address (and corresponding value in the AddressType TLV to indi=
cate how to interpret the address) to indicate the address from which an RR=
EP_Ack is expected, to accomplish the bidirectionality check (can happen in=
 RREP).



If we define=C2=A0a certain portion of the message as immutable and include=
 the ICV to verify that part, end to end:


- The metric value would be excluded from the ICV since it needs changing a=
t each hop.=C2=A0

- Would adding a Validity Time TLV at an intermediate hop be acceptable? Th=
e whole TLV could be removed in order to calculate the ICV?



- Would adding an address cause issues for the ICV, =
because it's in the address block? Could the rule be "if it contai=
ns an AckReq address, remove it (and the corresponding value in the Address=
Type TLV), before checking the ICV", is that
 OK? Or would we need to avoid touching the ICV'ed part of the message =
altogether, maybe put the AckReq address in a separate Address Block, with =
an extra AddressType TLV following that address block? Is there a way to ac=
complish this?






=C2=A0






Also, to be thorough, do we need to consider RERR me=
ssages while we discuss regeneration vs forwarding?=C2=A0






- RERR (sent when a link breaks) is a way of saying =
"I've lost my route so I'm telling others" and "you =
were my next hop, so=C2=A0now=C2=A0I've also lost my route, I'll te=
ll others", etc. It's going to be tailored at each step to include=
 the relevant
 routes that got deleted, it's not one message being sent end-to-end li=
ke RREQ and RREP are.=C2=A0






- However, RERR (sent when a source of traffic is se=
nding data on a route which comes through you, and you want to tell the Pac=
ket Source's router to delete the route) could be seen as an end-to-end=
 message which all intermediate routers
 learn from, similar to RREQ and RREP. It reports one route, and doesn'=
t need changing at intermediate hops, so could be protected with ICV.






- Would it be OK to only require a message ICV if a =
PktSource address was included, i.e. when the message needs to go via a num=
ber of intermediate hops to PktSource's router? All other RERRs are int=
ended to be one-hop messages, which may
 in turn prompt other one-hop messages, etc..., and a packet ICV might be m=
ore appropriate?






=C2=A0




Kind regards,




Victoria.






=C2=A0




On Thu, Mar 17, 2016 at 5:26 PM, <ietf@thomasclausen.org>=
 wrote:




=C2=A0








On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK)=
 <chr=
is.dearlove@baesystems.com> wrote:




=C2=A0








Yes, I meant AODVv2, than=
ks for the catch.






=C2=A0






So is your (Thomas) propo=
sed base specification a hop count only metric?












=C2=A0




No, the would be silly as base specification, given =
that hop count mostly is useless.






=C2=A0






As base specification I would simply say =E2=80=9CIn=
clude a Metric Type Message TLV with a value field, and a 7182 Message TLV =
& Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage =
as to generation and processing).=C2=A0






=C2=A0






With the message generated by the originator of the =
RREQ/RREP and *not* deconstructed/reconstructed/reordered (as is the risk w=
ith =E2=80=9Cregeneration) allows knowing that it would be *only* that metr=
ic field being modified (other than hop count/limit)
 for when eventually writing up the extension.






=C2=A0












(Actually doesn=E2=80=99t=
 the current specification only define hop count, or has that changed in la=
test draft?)










=C2=A0




No. That is one of the issues I raise in my original=
. For some reason, it cites RFC6551, which is a ROLL document and which has=
 in its abstract that:






=C2=A0






=C2=A0=C2=A0 Low-Power and Lossy Networks (LLNs) have unique character=
istics


=C2=A0=C2=A0 compared with traditional wired and ad hoc networks that =
require the


=C2=A0=C2=A0 specification of new routing metrics and constraints. =





=C2=A0






I.e. this document cites a metric document which cle=
arly claims to be inapplicable in ad hoc networks. I note that this is anot=
her thing I=E2=80=99ve raised for years without seeing it attempted resolve=
d.






=C2=A0






Best,






=C2=A0






Thomas






=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:=C2=A0chris.dearlove@baesystem=
s.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:=C2=A0ietf@thomasclausen.org=
=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 17:10

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Lotte Steenbrink; Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)










=C2=A0






=C2=A0




*** WARNING ***<=
/u>







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=C2=A0Red Flags=C2=A0t=
hat
 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=A0












On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:








=C2=A0










OK, so we have a message =
that mutates by:










- Modifying hop count/lim=
it.










- Modifying a metric valu=
e.










Anything else?<=
/u>










=C2=A0










As mutating (other than h=
op count/limit) messages aren=E2=80=99t covered by 5444 or any derivative d=
ocument (but only recommended against, not banned) that you may
 need to make the message otherwise immutable (no deconstruction and rebuil=
ding, other than guaranteed unchanging) that would have to be specified by =
AODVv2. (Easy to say, but needs saying.)














=C2=A0








With you so far.










=C2=A0<=
/p>







Then that information is =
not in a guaranteed fixed location given by a simple offset. So any signatu=
re algorithm that finds it and ignores it or aggregates
 on it is specific to OLSRv2.










=C2=A0








Surely you mean AODVv2










=C2=A0<=
/p>







So standard 7182 ICVs don=
=E2=80=99t do the job, you would need an AODVv2 specialised variant. Which =
is the sort of thing that the message specific TLV space is there
 for, I=E2=80=99d be strongly against a =E2=80=9Cbut ignore the value of th=
is specific TLV should it occur=E2=80=9D being in the general space. Howeve=
r it can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like =
that TLV, except if an X TLV is present, set its value field to
 zero=E2=80=9D).










=C2=A0










Messy, but could work.










=C2=A0








Not that messy, actually, although clearly not as ni=
ce as =E2=80=9Cfixed offset=E2=80=9D.










=C2=A0










That said, I am arguing for the base spec being:<=
/u>










=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=E2=80=9Cmake the message otherwise immutable (no deco=
nstruction and rebuilding, other=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=A0than guaranteed unchanging)=E2=80=9D which is af=
forded by forwarding










=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7182 Timestamps and ICVs.










=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7183 style text bringing it all together.=











=C2=A0










The =E2=80=9Caggregated signatures around mutable fi=
eld=E2=80=9D would very be an experimental extension.










=C2=A0










What I object to is, if the base spec specifically r=
enders such extensions impossible










=C2=A0










=C2=A0<=
/p>







=C2=A0








--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44 (0)12=
45 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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:=C2=A0Lotte Steenbrink [mailto:lo=
tte.steenbrink@fu-berlin.de]=C2=A0

Sent:=C2=A017 March 2016 16:48

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0ietf@thomasclausen.org; Mobile Ad =
Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=C2=A0








=C2=A0




*** WARNING ***<=
/u>







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=C2=A0Red Flags=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.










Hi all,












=C2=A0
















Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher=
 (UK) <chris.dearlove@baesystems.com>=
:












=C2=A0














Good point about whether =
you just pass on one cost or a set of costs. As I said, not looked at detai=
ls - I will, when time permits. One cost is much easier,
 and yes, it reduces the fixed size aggregated signatures problem to =E2=80=
=9Cjust=E2=80=9D one of computational load.


















=C2=A0














For the record, Thomas=E2=80=99 understanding is cor=
rect; the cost is one aggregated value.=C2=A0














=C2=A0














Best regards,=C2=A0














Lotte Steenrbink































=C2=A0










--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44 (0)12=
45 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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:=C2=A0ietf@thomasclausen.org=
=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 16:38

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: Message integrity and message mutability (was RE: =
[manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)


















=C2=A0










=C2=A0




*** WARNING ***<=
/u>







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=C2=A0Red Flags=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=A0




















On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:
















=C2=A0


















I appreciate Thomas=E2=80=
=99s comments about the limitations of message regeneration, but I would be=
 a bit less absolute.


















=C2=A0


















The issues over end to en=
d authentication and more advanced signatures are valid. I need to read the=
 given reference on aggregate signatures to increase my
 knowledge (thanks for it), but my understanding of the possibilities in th=
is field may offer a solution to the problem, but with some other issues (p=
ossibly including a new type of TLV).


















=C2=A0


















But the hop count/limit p=
oint I don=E2=80=99t fully agree with, you can regenerate with an increment=
ed/decremented count/limit, which leaves the ability to prevent
 messages propagating indefinitely, including expanding ring searches, and =
retains the ability to use RFC 5497 interval and validity times that might =
be useful with an expanding ring search (or might not).


















=C2=A0


















But the key issue is that=
 AODVv2 wants to accumulate metrics. I still haven=E2=80=99t got to the bot=
tom of many details here, but let=E2=80=99s for the moment just consider
 that conceptually.


















=C2=A0


















It=E2=80=99s hard to hand=
le end to end. Charlie=E2=80=99s draft attempts to do an end to end of some=
 information, not this information. I=E2=80=99m not sure if that=E2=80=99s =
useful (and the
 specialised format is better avoided if possible). Other approaches are ho=
p by hop (might as well use packet signatures) and shared key (might as wel=
l go hop by hop). Pairwise signatures for each pair of routers I=E2=80=99m =
discounting as scaling terribly. In the
 interests of completeness let=E2=80=99s mention not accumulating metrics, =
which puts us back to hop count and that=E2=80=99s not ideal either.=



















=C2=A0


















I don=E2=80=99t think the=
re is an ideal solution. (I like ideas I=E2=80=99ve seen about aggregating,=
 but that has some issues of its own, even apart from computational load.)
 I=E2=80=99d love to be proved wrong - someone with the perfect solution to=
 come along.


















=C2=A0


















Which means that either w=
e make an arbitrary choice - which will be disagreed with, but needs discus=
sing first - or create something flexible. Unfortunately
 flexible in that regard constrains in others, e.g. some (many? most?) aggr=
egating signatures need fixed data sizes (which we can do by defining a TLV=
 that =E2=80=9Cfills up=E2=80=9D with hop count, but that has a cost too).<=
/span>






















=C2=A0
















I have been told by people much more well versed in =
this than I in cryptology, that the correct answer is =E2=80=9Csome=E2=80=
=9D.


















=C2=A0


















That said, "AODVv2 wants to accumulate metrics=
=E2=80=9D =E2=80=94 does that mean that the message grows as it is being fo=
rwarded, and that the recipient of a RREQ/RREP will know the individual cos=
ts of each path segment? My understanding is, that the recipient
 will get =E2=80=9Cthe sum the costs of each path segment=E2=80=9D which sh=
ould be fitting within a fixed size?


















=C2=A0


















Thomas


















=C2=A0











































=C2=A0


















Sorry, no answers, just c=
omments. And I=E2=80=99m not addressing Thomas=E2=80=99s later points here.=



















=C2=A0












--


Christopher Dearlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

____________________________________=
______________________________________



T: =C2=
=A0+44 (0)12=
45 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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:=C2=A0manet [mailto:manet-bounces@ietf.o=
rg]=C2=A0On
 Behalf Of=C2=A0ietf@thomasclausen.org

Sent:=C2=A017 March 2016 16:00

To:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0[manet] draft-ietf-manet-aodvv2-13 review - a couple o=
f big ticket Items






















=C2=A0












=C2=A0




*** WARNING ***<=
/u>







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=C2=A0Red Flags=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.








***<=
/strong>=C2=A0WARNING=C2=A0***

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












=C2=A0




















Dear all,




















=C2=A0






















Apologies for not having gotten this done sooner - d=
ay-job leaving few spare cycles.






















=C2=A0






















I=E2=80=99ve previously offered reviews and comments=
, and some of those have been addressed in the latest I-D =E2=80=94 others =
have not, but should be. I recall that there was some mail attempting to re=
but parts of the review, and I will dig it out and
 reply to that.






















=C2=A0






















With that being said, I have reviewed the latest ver=
sion of the document, and full details will be forthcoming. There=E2=80=99r=
e a couple of big-ticket/architectural items that I want to address up fron=
t, as I believe that before we have those
 hammered out, it will be useless to go into details. Note, I do not claim =
that this is an exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D, but =
that=E2=80=99s as far as I have gotten in thinking this through.<=
/u>






















=C2=A0






















I also bring these up as they are items that have be=
en brought up repeatedly over the past years, but not resolved nor discusse=
d.






















=C2=A0






















Loops






















Just to bring this out: I share Chris=E2=80=99 worry=
 about conflicting and concurrent statements from the authors on =E2=80=9CT=
here are no loops possible=E2=80=9D and =E2=80=9CWe need to fix two situati=
ons where loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating =
some loop
 conditions=E2=80=9D






















=C2=A0






















I particularly worry that this is not a discussion h=
ad in public, but apparently in some other forum=E2=80=A6






















=C2=A0






















=C2=A0
























Intermediate Route Replies, and all of section=
 10






















Section 10 contains a set of =E2=80=9Cvaguely specif=
ied extensions=E2=80=9D, which is incoherent with the intended status indic=
ated for this document.=C2=A0






















=C2=A0






















Specifically, and this is not unrelated to the point=
 about loops above, intermediate RREPs (section 10.3) are a potential sourc=
e for loops.






















=C2=A0






















Expanding Ring Multicast (section 10.1) is not docum=
ented in a way that can be implemented (and also, see =E2=80=9CForwarding-v=
s-regeneration=E2=80=9D below, it is in the present form of this protocol i=
mpossible), etc.
























=C2=A0






















=C2=A0






















Forwarding-vs-regeneration






















Recent exchanges on the list made me understand that=
 protocol control messages are *not* forwarded, but are consumed at each ho=
p, then a new message with (almost-but-not-quite) the same content is gener=
ated and transmitted.






















=C2=A0






















I have thought some more on this (& read some of=
 the exchanges on the list on this topic by Chris, Ulrich, and others), and=
 I am convinced that this is not the right way to go,=C2=A0at least=
=C2=A0for the following reasons:






















=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It renders the hop-limit/hop-count fields in the RFC5444 messag=
e header useless.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0This would not be bad if the functionality offered by tho=
se fields was not useful






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=94 sadly, it is. For example, for scope limited fl=
ooding (expanding ring search, and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0such) which may be of interest, and which require hop-lim=
it.=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0A hop-count field may also provide a =E2=80=9Ccheap=E2=80=
=9D (in terms of overhead) additional piece






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of information to use conjunctively with a =E2=80=9Creal=
=E2=80=9D metric.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The only practical solution would be to re-introduce thes=
e functions by way of inserting a






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0MessageTLV =E2=80=94 which (i) is not specified in this d=
ocument, and (ii) which would just






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0serve to render messages bigger than strictly needed.<=
/u>






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Scope limited flooding =C2=A0does seem to be a necessary =
requirement, if for no






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0other reason than to prevent information from =E2=80=9Cci=
rculating forever in the network=E2=80=9D.






















=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It makes end-to-end authentication unnecessarily hard.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I think Chris called this out already, but it bears repea=
ting: S generates a message=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(say, a RREQ), and includes an ICV calculated over the co=
ntent of the message.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0For any recipient to be able to validate the ICV, the mes=
sage has to be exactly






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0the same =E2=80=94 not just in content, but in structure =
=E2=80=94 as what was generated.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforwa=
rding=E2=80=9D messages means, that the intermediate






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose =
a different structure (e.g., include TLVs






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0in a different order).






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The proposal from=C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00=























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0is to add constraints on (i) the set of elements to inclu=
de in a signature and (ii) the






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0order of these elements.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0One=C2=A0problem with that approach is (i): if an extensi=
on adds a message TLV, or an=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Address TLV, to a message, then that will not be =E2=80=
=9Ccovered=E2=80=9D by the proposed e2esec TLV.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Rather for *each* extension developed, an =E2=80=9Cupdate=
s e2esec=E2=80=9D clause needs to be done.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I=E2=80=99d say that this approach would be prone to erro=
rs =E2=80=94 and add entropy to the process






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of designing protocol extensions. The alternative, a mess=
age being generated by the






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0source and *forwarded* (as we do in OLSRv2, for example) =
would allow ICV TLVs=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(even, allow reuse of those specified for OLSRv2) for cov=
ering a message and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0extensions.






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CBut what about the metrics value which will chan=
ge on each hop=E2=80=9D, you may say?






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Fortunately, that is relatively easy to handle: simply ze=
ro out the value of that TLV when






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0generating or verifying the ICV MessageTLV. And use Packe=
t-TLVs for hop-by-hop=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0authentication, if needed (but, see below).=























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It prevents the use of more clever/advanced signature scheme=
s/ICVs






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Aggregate signature algorithms (=C2=A0https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf<=
/span>)






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0exist, and an interesting use-case can be found in also r=
eactive protocols, allowing verifying






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0not =E2=80=9Cjust=E2=80=9D the end points, but also the i=
ntermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0discussed above, or something smarter).






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Regeneration of messages, rather than forwarding, renders=
 that impossible (or, if used,






















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0updating to =C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)






















=C2=A0






















There are other reasons, but the above are those tha=
t jump at me as immediate show-stoppers.






















=C2=A0






















I do honestly not see what possible benefit there is=
 from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inconve=
niences, and security is not the least of these. Insisting on =E2=80=9Crege=
neration=E2=80=9D requires development of =E2=80=9Cnon-general workarounds=
=E2=80=9D as pointed
 out above.






















=C2=A0






















Security Considerations<=
/p>





















This is an always thorny subject. When OLSRv2 was go=
ing through the process we got a thorough education in how little we knew a=
bout security from the SEC-ADs, and had to spend about a year or so develop=
ing RFC7183. The bottom line is, that
 this protocol needs its =E2=80=9CRFC7183 =C2=A0equivalent=E2=80=9D, either=
 as part of the main document, or as an independent document. currently, th=
at is not the case.






















=C2=A0






















A minima, looking at BCP72 and BCP107 =E2=80=94 taki=
ng inspiration from RFC7183 might be aw good idea, as that was the most rec=
ent that went through the SEC AD. Regardless of how, however, a =E2=80=9Cma=
ndatory to implement=E2=80=9D security mechanism most be specified
 (I think the right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D),=
 in sufficient detail to ensure interoperable implementations.






















=C2=A0






















As an example, both [RFC6130] and [RFC7181] set out =
that that:
























=C2=A0






















=C2=A0 =C2=A0 =C2=A0 On receiving a ... message, a r=
outer MUST first check if the






















=C2=A0 =C2=A0 =C2=A0 message is invalid for processi=
ng by this router






















=C2=A0






















and then proceed to give a number of conditions that=
, each, will lead to a rejection of the message as "badly formed and t=
herefore invalid for processing=E2=80=9D =E2=80=94 a list which RFC7183 the=
n amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting
 =E2=80=9Crejection=E2=80=9D. Idem for message generation.





















=C2=A0






















If I was to do RFC7181/RFC6130 today, I would includ=
e that directly into the protocol specifications. It turned out to be more =
overhead (and slow down publication anyways) to do it as separate documents=
.
























=C2=A0






















Secondly, we need to be a lot more rigid in terms of=
 what ICVs, Timestamps, etc. are added/removed, and what that brings.






















=C2=A0






















For example (with the assumption that messages are *=
forwarded* and *not* regenerated), this could be one option:<=
/p>





















=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0When a RREQ, RREP message is generated, add an ICV Message TLV, which=
 is calculated <this way>






















=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=E2=80=A6(take inspiration from RFC7183 here)






















=C2=A0
































...



[Message clipped]=C2=A0=C2=A0

_______________________________________________

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










=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.

********************************************************************






--001a1142e5cc2c474405317c400d--


From nobody Wed Apr 27 13:10:05 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 CB52D12DC23 for ; Wed, 27 Apr 2016 13:10:03 -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 fJWgROoT8oGb for ; Wed, 27 Apr 2016 13:10:02 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 95D6F12DA7F for ; Wed, 27 Apr 2016 13:10:01 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id a17so32075209wme.0 for ; Wed, 27 Apr 2016 13:10:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=6vV/PEpBLwNL+ON8I5jTlsezaSpJv2gHXnbyDZPA4qY=; b=ng2thY78qzluGfa7JD7pjqAcmeQIBqJO8HJisxIDFVK6pfrXTapfFOU+9uyPa2sqF+ PbyDFWFB38mfqgU84FrQyL5Y4sG6tqQ2jCiRKRE7LHyIFPoqsMAhfuvcjekmks/tw6Zr /NfEoGA4H8FuXkx4jy7Td8Mw7HskY+9wxEi94BiD0d2A5tXfUP6XfxYypWoJITxZUdvD znhLy7lKXBQBuUZ5mtxm+e1aBKJy7dH8U0g3ukortk9HY73iIjvPZmRH+sP6M+k7794I U0I3bXp+uAXzfInk+mUmzWTXB+ukaKu8dQNsbEX+sGcpjxNVIlqnVm3/dCco2tfm5qzd efOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=6vV/PEpBLwNL+ON8I5jTlsezaSpJv2gHXnbyDZPA4qY=; b=OeOwnlb9S8ctKnWL78lPy+mJbSivqwL/Cc9r+ibdqWHC8H5k+9NWjUlkWzALzuf40D t3ubmb72NJHj1PmFvDRbRAnyw1laxx3Ot1r/13tzi+h1xHHZwtRuxS+UpMUOKnPzAEAu sxsHRFiXSR1GtGJfXIppsFZEYspXKEQC+6SOfMUjALwthP+mYrFcjWeQTSvQJNq6csjR 5WedNGnmyCObR9rMn+xTAXCsXSLY0Ovg1dLa2JPFkL+KJ5AdjPwEM7B6anqRp2h7mlMg eowpPzkWioN0NqHR6K4E15n/cYRVnE19+rcW6CCdeeXUCSVBIVsqWWRa4lMV6JC6Z2gu McHg==
X-Gm-Message-State: AOPr4FWaLnqR9EHskHTsXVs7vTT/QP3T0jVaEdg5+80F3UZl1ArD9iglZ8kJ4wfNO/IuGw==
X-Received: by 10.28.4.149 with SMTP id 143mr11484138wme.44.1461787800123; Wed, 27 Apr 2016 13:10:00 -0700 (PDT)
Received: from johns-mbp-4.home (host86-151-226-34.range86-151.btcentralplus.com. [86.151.226.34]) by smtp.gmail.com with ESMTPSA id 8sm31116202wms.14.2016.04.27.13.09.58 for  (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Apr 2016 13:09:59 -0700 (PDT)
From: John Dowdell 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <937ABB81-CCD9-4FD0-A7CF-5114384B3B94@gmail.com>
Date: Wed, 27 Apr 2016 21:10:17 +0100
To: manet@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [manet] AODVv2 security: Key Management to BCP107
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, 27 Apr 2016 20:10:04 -0000

Hi all

As an AODVv2 co-author I=E2=80=99d like to propose this position =
regarding key management against BCP107, one of the artefacts we are =
being asked to state a position over. I=E2=80=99d also like to state =
that I=E2=80=99m open to contributions from others knowledgeable on this =
topic or who have been this way previously.

If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka =
BCP107 is the set of guidelines for choosing either automated or manual =
key management for cryptographic purposes. It=E2=80=99s not a long read =
and guides the reader through a set of tests as to whether automated or =
manual key management would be suitable for the application in hand.

The very first question is does AODVv2 need key management at all? I =
would contend that it does, since we require to secure the signalling =
traffic for the routing algorithm. The aim here is therefore to purely =
assist in the security of the signalling traffic; security of user data =
that is forwarded once an AODVv2 route has been established is out of =
scope.

Section 1 of BCP107 states that automated key management SHOULD be used. =
Thus my answer will be in favour of that unless I can contend otherwise.

The guidelines in section 2 outline that automated key management =
derives short-term session keys between two parties. In the case of =
AODVv2, this would correspond to two routers that form or wish to form =
an adjacency.

The guidelines state that the short-term keys may be derived from =
long-term keys, and that the dissemination of long term keys is out of =
scope of BCP107. I would envisage that an AODVv2 router, given that it =
would form ephemeral ad hoc networks with other routers as it went about =
its business, would be supplied with one or more long term keys for a =
period of time, to be determined by the system integrator, and that the =
long term keys would then be used to derive short term keys which are =
used in the forming of adjacencies plural.

Section 2.1 of BCP107 describes the conditions under which automated key =
management MUST be used.

- If a large number of static keys would have to be managed. It is not =
known how many routers could be deployed, but if this is aimed at ad hoc =
applications then the number of routers could quickly become large. I =
consider this condition is met.

- Any stream cipher is used. This is a choice for the system integrator, =
but an AES based cipher is a real possibility. There is more likelihood =
this condition is met than not met.

- An initialisation vector (IV) might be re-used. I am open to advice on =
this point.

- Large amounts of data need to be encrypted in a short time. Even if =
there is no specific guidance on =E2=80=98large=E2=80=99, I do not =
consider this condition to be met, since signalling messages are likely =
to be short relative to the user data that could be exchanged.

- Long-term session keys are used by more than two parties, including =
multicast applications. AODVv2 uses multicast extensively, and therefore =
I consider this condition to be met.

- Device turnover is frequent. This is a certainty in ad hoc networks, =
so I consider this condition to be met.

I believe the outcomes from section 2.1 guidance is more in favour of =
automated key management.

However, to consider the guidance on manual key management in section =
2.2 of BCP107, where such management may be reasonable:

- the environment has very limited bandwidth or high round trip times. =
Some applications for AODVv2 may use very low bandwidths, perhaps for =
low-power sensor networks. The point is made that "public key systems =
require long exchanges and lots of computation=E2=80=9D. The AODVv2 =
author team believe that very low power hardware might be used by some =
implementors, which may give problems when being required to use public =
key exchanges. Such implementors need to carefully consider the tradeoff =
between the need for security and the need for very low power =
consumption. Such implementors should also consider whether some =
functions should be realised in hardware or software, and the resulting =
impact on system performance and power consumption.

- the information being protected is of low value. I do not consider =
this condition to be met; on the contrary, the signalling traffic in =
AODVv2 is of high value to a potential attacker.

- the scale of each deployment is limited. I consider that this is an =
unknown, but I also consider that we should engineer for larger networks =
with ephemeral connections rather than smaller ones.

Discussion welcome.

Regards
John





From nobody Wed Apr 27 13:59:51 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 1DA9D12DA3D for ; Wed, 27 Apr 2016 13:59:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.143
X-Spam-Level: 
X-Spam-Status: No, score=-1.143 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, TRACKER_ID=1.306] 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 tEGGoZwgQs_h for ; Wed, 27 Apr 2016 13:59:44 -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 313E912DB3E for ; Wed, 27 Apr 2016 13:59:43 -0700 (PDT)
Received: by mail-vk0-x22c.google.com with SMTP id o133so8869883vka.3 for ; Wed, 27 Apr 2016 13:59:43 -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=TGgDcA7d1+spMBBo+TWJdx2hKg7NYYkWEX9vimQqTH4=; b=FqSDfAbtQl74Efl66y1DqZ8kpvjb5G+aDDZGU8Xw08ThF/+eUqQwzuBQFWJytbeA8L t23lTSX75MzmPhb86TYlatrcQ4nMXSbb+iz4yuybfvRf+4+ZG90Wnsw3mw3IkNLHvexg tpTQiE8EDSXZgK0zFNNMRR0iYzo01/3naUO1+XGRywLgwaznSVe2vDpqYhkh6OUCtoFI hrel9oyvrlEPKaoekFoxDLp7ZM2MSrKAUnEfBRn3vz3nEoFl4nZEn1UeU4GoRdS3sPR4 sVIHolML25PFRmdqTqtDYWJzMntgr2TvMaLkKUy64droeZHVUOtTnCQrgQeOq4FMVHAJ MIEA==
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=TGgDcA7d1+spMBBo+TWJdx2hKg7NYYkWEX9vimQqTH4=; b=Y/rwACUSyRguhZy2Vkbc7GlFSOH6GX9inixavGDS+0fJsWCpAM9Ku2ImKnZs+9ZEOl M/J3sHhxqmDTM+aSTvXBI4fqxor+F7AauzHedLb0ZwaJJ0bOdA58SkOZsfBlVkJnIEBr HipjtBBsKTzl4r14XBsMUX4nxrxQPEbJCHJVljmkQI3dvnCf2xrFhajCpYSC/DgByiy2 D91alw0hhmfk1BYSU9KIOmKYDcylTyMWlYt7oqM4revW55Xql5DjGbMMC9Ua8FCLPKto ZOezdX+S2JTv1soZjdljVmGSYO5O8BCbm7fkpp4P1Q+FD5k28dnT5xKxi267SNZdf8dg USbg==
X-Gm-Message-State: AOPr4FX/quyl9+0kTE85CjSYQR2V0RZljkzOHRAQks/09k8SdyTFt0dIW4G+3/3O86Wbxj8ouO6TVi+M04gvkw==
MIME-Version: 1.0
X-Received: by 10.159.38.75 with SMTP id 69mr5372984uag.139.1461790781942; Wed, 27 Apr 2016 13:59:41 -0700 (PDT)
Received: by 10.176.65.40 with HTTP; Wed, 27 Apr 2016 13:59:41 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org>     
Date: Wed, 27 Apr 2016 21:59:41 +0100
Message-ID: 
From: Victoria Mercieca 
To: Justin Dean 
Content-Type: multipart/alternative; boundary=001a113e4aa84b35e105317db072
Archived-At: 
Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 27 Apr 2016 20:59:50 -0000

--001a113e4aa84b35e105317db072
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Just quickly, on this note, if we remove the AckReq from the RREP itself,
then because the RREP is multicast, there might be multiple receivers, but
there's no way for them to determine if they were the intended next hop, so
they would all have to forward the RREP. The RREP might then go by multiple
routes to get to RREQ_Gen. This assumes all receivers of the RREP have a
route to OrigAddr anyway (current rules say if they didnt, they would send
a RERR back to RREP_Gen).

So, do we have to install a route to the neighbour, then unicast the RREP
and create a separate message with an AckReq, then if no acknowledgement is
received, blacklist the neighbor and remove the route to the neighbor?
along with the route to OrigAddr which is not available because the link is
not bidirectional...?

Regards,
Victoria.

On Mon, Apr 25, 2016 at 4:34 PM, Justin Dean  wrote:

> On Mon, Apr 25, 2016 at 11:29 AM, Jiazi YI  wrote:
>
>> Hi,
>>
>> Maybe I missed a bit here:
>>
>> If only the desired receiver of the multicast RREP (carrying a
>> destination address) can reply to the multicast RREP, why not using unic=
ast
>> directly?
>>
>> Because the link isn't yet known to be bi-directional and a unicast rout=
e
> can't be installed yet.
>
> Justin
>
>
>> best
>>
>> Jiazi
>>
>> On Mon, Apr 25, 2016 at 4:59 PM, Victoria Mercieca 
>> wrote:
>>
>>> Hi Chris,
>>>
>>>
>>> On Mon, Apr 25, 2016 at 3:51 PM, Dearlove, Christopher (UK) <
>>> chris.dearlove@baesystems.com> wrote:
>>>
>>>> I has to go back to Victoria=E2=80=99s summary here. It says:
>>>>
>>>>
>>>>
>>>> 2) C creates the RREP. Since it doesnt know if the link to B is
>>>> bidirectional, it includes the AckReq (an address to indicate that it
>>>> expects to receive a RREP_Ack from B).
>>>>
>>>>
>>>>
>>>> That doesn=E2=80=99t actually indicate if that=E2=80=99s C=E2=80=99s a=
ddress or B=E2=80=99s address
>>>> being included. I=E2=80=99d assumed it was C=E2=80=99s address. Your c=
omment makes sense if
>>>> it=E2=80=99s B=E2=80=99s address. Reading again, I think you=E2=80=99r=
e probably right. But only
>>>> probably. Can we confirm that.
>>>>
>>>>
>>>>
>>>
>>> C creates the RREP. The included AckReq address is B's address. The RRE=
P
>>> then gets multicast.
>>> B receives it, sees that it own address is marked as the AckReq address=
,
>>> and sends an ack unicast back to C.
>>> Anyone else who receives the multicast RREP from C does not send the
>>> Ack, since the AckReq address does not match any of their interface
>>> addresses.
>>>
>>>
>>>> I assume you meant that the RREP (not RREP_Ack) is multicast. There=E2=
=80=99s a
>>>> bit of a chicken and egg problem here. We do know how we want to unica=
st.
>>>>
>>>
>>> The RREP is multicast (when we dont know if the link is bidirectional),
>>> the RREP_Ack is always unicast.
>>>
>>> Kind regards,
>>> Vicky.
>>>
>>>
>>>>
>>>> *-- *
>>>>
>>>>
>>>>
>>>>
>>>> *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:* 25 April 2016 15:26
>>>> *To:* Thomas Heide Clausen
>>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
>>>> Networks mailing list; Victoria Mercieca
>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** 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
>>>> .*
>>>>
>>>> The address in the RREP_Ack may be required due to the RREP_Ack being
>>>> multicast as there is not yet a verified unicast route installed yet.
>>>> Going to double check if I'm remembering correctly.
>>>>
>>>> Justin
>>>>
>>>>
>>>>
>>>> On Mon, Apr 25, 2016 at 10:18 AM,  wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I must admit that while I have reviewed the protocol several times,
>>>> I=E2=80=99ve not been digging that deep into the protocol functioning =
to catch this
>>>> issue of how invasive the protocol operations are when forwarding a
>>>> message: there were other =E2=80=9Cmajor=E2=80=9D issues to address (a=
nd which obscured the
>>>> details), so as a first order: thank you Victoria, for having called
>>>> attention to this.
>>>>
>>>>
>>>>
>>>> To the substance of these emails.
>>>>
>>>>
>>>>
>>>> I am afraid that I do not understand the use of inserting validity TLV=
s
>>>> while in-flight, into a message. Actually, I am dubious for both the
>>>> originator inserting this (how can the originator of a message know ho=
w
>>>> =E2=80=9Clatter parts of the path=E2=80=9D will be have=E2=80=9D) exce=
pt if we are talking
>>>> duty-cycling of devices and inserting =E2=80=9Cthe remaining time that=
 I am going
>>>> to be up before I suspend=E2=80=9D. Intuitively, that would also assum=
e fairly long
>>>> duty cycles =E2=80=9CI am up for tens of seconds=E2=80=9D, which I am =
not sure are actually
>>>> realistic. And, as Chris says in another email, this is trading off =
=E2=80=9Cthe
>>>> ability to do security=E2=80=9D for an unknown/untested feature =E2=80=
=94 which I think is
>>>> the wrong trade-off.
>>>>
>>>>
>>>>
>>>> On he topic of =E2=80=9Cneeding to put an address in=E2=80=9D for RREP=
-ACK, I must
>>>> admit that this seems roundabout. I can see three issues here:
>>>>
>>>>
>>>>
>>>> o I am not sure that adding an address vs. a flag may not have to do
>>>> with the =E2=80=9Cmultiple interfaces/
>>>>
>>>> multiple addresses=E2=80=9D discrimination mechanics of the protocol? =
I haven=E2=80=99t
>>>> worked it through, though,
>>>>
>>>> but that would be a guess.
>>>>
>>>>
>>>>
>>>> o The end-to-end topology diffusion mechanism should not need to be
>>>> concerned with the
>>>>
>>>> =E2=80=9Cbidirectionally check=E2=80=9D of a local link (in part, as i=
t encumbers
>>>> security, but not only).  In short, a
>>>>
>>>> flag or an address, both are (equally) bad.
>>>>
>>>>
>>>>
>>>> o A cleaner mechanism would be a =E2=80=9Chello mechanism=E2=80=9D, no=
t necessarily as
>>>> NHDP, but a =E2=80=9Cwhen
>>>>
>>>> forwarding a RREQ/RREP, trigger a 3-way hello exchange, if the link is
>>>> estimated to be of a
>>>>
>>>> type which potentially can be unidirectional=E2=80=9D. There is anothe=
r benefit
>>>> to doing that, see the end
>>>>
>>>> of this email.
>>>>
>>>>
>>>>
>>>> Either way, I do not like the notion of fusing
>>>> metrics-and-link-bidirectionality-detection any more than I like fusin=
g
>>>> global-topology-diffusion-and-link-bidirectionality-detection.
>>>>
>>>>
>>>>
>>>> The solution all this is, to me, threefold
>>>>
>>>>
>>>>
>>>> 1) Factor out the bidirectionally check in a (triggered) neighbour
>>>> detection mechanism
>>>>
>>>> (triggered HELLO message)
>>>>
>>>>
>>>>
>>>> 2) Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, since they add com=
plexity for no
>>>> perceivable benefits
>>>>
>>>>
>>>>
>>>> 3) Use the security model that we=E2=80=99ve discussed previously, whe=
re (only)
>>>> the metrics change per hop.
>>>>
>>>>
>>>>
>>>> Since we=E2=80=99re discussing bi-directionality of links here, and th=
e
>>>> 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:
>>>>
>>>>
>>>>
>>>>    ...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 install=
ed
>>>>
>>>>    in the Local Route Set at each router will be correct.  While this
>>>>
>>>>    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. Consequen=
tly, the conclusion
>>>> 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 lin=
k the
>>>> metrics is 4 or 5=E2=80=9D, the protocol must be able to convey and di=
stinguish
>>>> 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 w=
ith the
>>>> bi-directionality check) be in the triggered neighbour detection mecha=
nism:
>>>> that exchange could, if designed carefully, be used to probe for and c=
onvey
>>>> metrics information, also.
>>>>
>>>>
>>>>
>>>> Hope this helps,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thomas
>>>>
>>>>
>>>>
>>>> On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK) <
>>>> chris.dearlove@baesystems.com> wrote:
>>>>
>>>>
>>>>
>>>> Assuming for the moment that everyone will need an RREP-Ack or won=E2=
=80=99t
>>>> (let=E2=80=99s come back to that) why do C and B need to put an addres=
s in as an
>>>> RREQ-Ack request? Why not a flag, because the address will be included=
 as
>>>> the IP sending address - and we know 5444 is required to pass that on.
>>>> (It=E2=80=99s used by NHDP as well.) Then we don=E2=80=99t need to cha=
nge the RREP, it will
>>>> have a flag set or not, and won=E2=80=99t change (in this regard).
>>>>
>>>>
>>>>
>>>> Now let=E2=80=99s consider do we know whether we can set a fixed flag.=
 First
>>>> I=E2=80=99d say there are two cases - you=E2=80=99ve got a firm contro=
l on what=E2=80=99s going on
>>>> in your network, or it=E2=80=99s one of unknown parties and behaviour =
(consistent
>>>> with specification). In the former case you only want one setting, for
>>>> example no-Ack if running NHDP or your MAC layer tells you about
>>>> bidirectionality, Ack otherwise. In the latter case, I think you just
>>>> always want an Ack. So both cases get you to the same place.
>>>>
>>>>
>>>>
>>>> Should that not be an acceptable argument (though I think it=E2=80=99s=
 good for
>>>> where we are - in fact always Ack is close) then at flag is a step bet=
ter,
>>>> it=E2=80=99s a fixed location to change. However it would be better in=
 that case if
>>>> the two things to change (metric and ack flag) were together. But that=
 has
>>>> its own issues, so I won=E2=80=99t go there.
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com
>>>> ]
>>>> *Sent:* 25 April 2016 14:15
>>>> *To:* Jiazi YI
>>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
>>>> Networks mailing list
>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** 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
>>>> .*
>>>>
>>>> Hi Jiazi,
>>>>
>>>>
>>>>
>>>> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI  wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
>>>> chris.dearlove@baesystems.com> wrote:
>>>>
>>>> With regard to your validity time point, we here have a tradeoff. If
>>>> you allow that feature, it significantly impacts on the approach that =
was
>>>> coming together on as best you can end to end encryption.
>>>>
>>>>
>>>>
>>>> So the question is, is this a feature that=E2=80=99s really wanted?
>>>> Unfortunately I think we know that the answer to that is, we don=E2=80=
=99t know
>>>> because we don=E2=80=99t have any experience. My view would be that in=
 the tradeoff
>>>> of an untested feature (unless I=E2=80=99m wrong about that) and the s=
ecurity
>>>> complication, security wins and drop the feature. If there is some rea=
l
>>>> requirement, then there=E2=80=99s a discussion. (Questions like how of=
ten the
>>>> intermediate routers actually have any knowledge - typically links bre=
ak
>>>> for unexpected rather than expected reasons. Andan intermediate router
>>>> could possibly use a validity time to influence its behaviour.) Note t=
hat
>>>> dropping the ability of intermediate routers to modify/set still allow=
s
>>>> validity times per route to be set at endpoints.
>>>>
>>>>
>>>>
>>>> I agree with Chris' concern.
>>>>
>>>> The ValidityTime is optional, which makes the integrity protection
>>>> hard. Furthermore, it gives a potential attack vector: as all the rout=
ers
>>>> in a path will take the shortest validityTime, a compromised router ca=
n set
>>>> the the validityTime to a very short value, which will make the route
>>>> installed along the path became invalid (very soon).
>>>>
>>>>
>>>>
>>>> On the other hand, I'm not sure this option will give us much help.
>>>> Chris mentioned much knowledge intermediate router would have to decid=
e
>>>> this value (and how much sense the value would make).
>>>>
>>>> Another issue is, a route to a destination might be updated by
>>>> different sources. For example, in the network below:
>>>>
>>>>
>>>>
>>>> A----B-----C
>>>>
>>>>
>>>>
>>>> A first establish a route to B with long validity time. Then A
>>>> initiates a route discovery to C. C tends to set a short validity time=
,
>>>> which will make the route between B and A expire earlier than expected=
.
>>>>
>>>> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considered
>>>> or not.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Not sure I follow here.
>>>>
>>>> Currently, the validity time of the route between A and B would not
>>>> affected by a short validity time of a route between A and C. Validity
>>>> times are per-route, and the route A-B and the route A-C are separate.
>>>>
>>>> If we switched to a validity time per neighbor (so that we can keep
>>>> validity time separate from route advertisements) as I mentioned in th=
e
>>>> email below, then the validity of a route between A and C would be aff=
ected
>>>> if there was a short validity time between A and B. But, if B will onl=
y
>>>> route for a certain amount of time, then the route between A and C wil=
l of
>>>> course be affected. Is it best to know in advance that there's a time
>>>> limit, or just deal with RERRs when they happen?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> With regard to the acknowledgements, the problem (with regard to
>>>> security) comes from trying to do two jobs with the same message - end=
 to
>>>> end route advertisement and hop by hop acknowledgement. I understand t=
he
>>>> reasons - saving bytes and message types. (I would have to study the
>>>> protocol really hard to identify if any message types can be folded
>>>> together and recognised by content rather than type efficiently. This =
I do
>>>> not expect to do.) Again a tradeoff. This one is in discussion space,
>>>> though that needs people who understand both sides of the issue, inclu=
ding
>>>> the details of the bidirectionality mechanism. Of course, as has been =
said,
>>>> we need one of those.
>>>>
>>>>
>>>>
>>>> I haven't finished my review of the latest draft, and I don't get the
>>>> necessity of AckReq and the corresponding multicast RREP yet.
>>>>
>>>> If possible, this "optional" field should be avoided.
>>>>
>>>>
>>>>
>>>>
>>>> To give an overview of AckReq and RREP:
>>>>
>>>> Since AODVv2 requires bidirectional links, this is the way to determin=
e
>>>> if a link is bidirectional.
>>>>
>>>> A----B----C
>>>>
>>>>
>>>> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both
>>>> install a route to OrigAddr but they dont yet know if it's valid becau=
se
>>>> they dont know if the link to their next hop is available in the rever=
se
>>>> direction.
>>>>
>>>> 2) C creates the RREP. Since it doesnt know if the link to B is
>>>> bidirectional, it includes the AckReq (an address to indicate that it
>>>> expects to receive a RREP_Ack from B).
>>>>
>>>> 3) B receives the RREP, installs a route to TargAddr and marks it as
>>>> valid, since it knows the link to C is bidirectional, because the RREQ=
 went
>>>> in one direction and the RREP came in the other. B also sends the RREP=
_Ack
>>>> to C and forwards the RREP to A (and might change the message to indic=
ate
>>>> its own AckReq - ie that it requires an ack from A).
>>>>
>>>> 4) C receives the RREP_Ack from B, and therefore knows that B received
>>>> the RREP, therefore the link is bidirectional. C can then mark its rou=
te to
>>>> OrigAddr as valid.
>>>>
>>>> 5) Similarly, A receives the RREP, installs the route to TargAddr and
>>>> sends an RREP_Ack to B.
>>>>
>>>> 6) B receives the RREP_Ack and marks its route to OrigAddr as valid.
>>>>
>>>>
>>>>
>>>> Alternatively, in step 2, if C knows the link to B is bidirectional
>>>> (perhaps from some earlier route discovery), it doesnt need to put the
>>>> AckReq in the RREP. Then in step 3, since B doesnt know if the link to=
 A is
>>>> bidirectional, it changes the message to add the AckReq address, in or=
der
>>>> to get an RREP_Ack from A.
>>>>
>>>> If we want to avoid changing the message, we'll need to look at
>>>> forwarding the RREP as-is, and creating a second message to solicit an
>>>> RREP_Ack, in order to verify that the link is bidirectional before mar=
king
>>>> the route to OrigAddr as valid.
>>>>
>>>> Kind regards,
>>>>
>>>> Victoria.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> regards
>>>>
>>>>
>>>>
>>>> Jiazi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *_____________________________________________________________________=
_____
>>>> *
>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
>>>> *Sent:* 23 April 2016 10:55
>>>> *To:* Christopher Dearlove
>>>> *Cc:* ietf@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad
>>>> Hoc Networks mailing list
>>>>
>>>>
>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** WARNING ****
>>>>
>>>>
>>>>
>>>> *This message originates from outside our organisation, either from an
>>>> external partner or the internet. Consider carefully whether you shoul=
d
>>>> 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
>>>> .*
>>>>
>>>> Hi Chris,
>>>>
>>>>
>>>>
>>>> These have both been in the draft in some form since before I got
>>>> involved... but I'll do my best to explain.
>>>>
>>>>
>>>>
>>>> - For Validity Time, its a way to advertise that you would only suppor=
t
>>>> the route contained in the message for a certain period of time. The
>>>> originator might use this, but the draft was written to allow any
>>>> intermediate node to be able to add it or update it too. The route cre=
ated
>>>> in the Local Route Set has an expiration time associated with it, base=
d on
>>>> the received validity time.
>>>>
>>>> - For the AckReq address, its so that you can add into a RREP a reques=
t
>>>> for an acknowledgement, so that you don't have to have a different mes=
sage
>>>> type altogether for working out whether links to neighbors are
>>>> bidirectional, and also, since you only care about bidirectionality on
>>>> routes that are being set up, you dont need to constantly monitor all
>>>> neighbors.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> In order to avoid the potential AckReq-related changes to each message=
,
>>>> maybe we do need to introduce a different message specifically for thi=
s. We
>>>> could maybe use RREP_Ack to both request and acknowledge? It means an =
extra
>>>> message of control traffic that needs to be sent, maybe one extra mess=
age
>>>> per hop on the path of a RREP, but it could still be limited to neighb=
ors
>>>> which have participated in the route discovery rather than monitoring =
all
>>>> neighbors at all times.
>>>>
>>>>
>>>>
>>>> This message could maybe also include "I'm happy to route anywhere for
>>>> a certain amount of time", sort of like willingness in OLSR/OLSRv2. So
>>>> instead of having a validity time per route, its a validity time per
>>>> neighbor. Then, for RREQ and RREP, only the metric value would change =
in
>>>> transit, as discussed. However, that leads to some issues with decidin=
g
>>>> what a route's expiration time is. You might know how long the next ho=
p
>>>> router is valid for, but what if a router beyond that, which was also =
part
>>>> of the route, had a lower validity time? You couldn't determine the re=
al
>>>> validity time. Do we remove the route expiration time altogether to av=
oid
>>>> this issue? In which case, we would have to rely on RERR messages bein=
g
>>>> sent for routes which become invalid when the neighbor's validity time=
 has
>>>> expired? So neighbor validity time expiration is treated the same as a=
 link
>>>> break.
>>>>
>>>>
>>>>
>>>> What do you think?
>>>>
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Victoria.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
>>>> chris@mnemosyne.demon.co.uk> wrote:
>>>>
>>>> Pretty much all of the discussion has been assuming only a metric valu=
e
>>>> change. With multiple things changing many of the ideas go out of the
>>>> window. That reinforces the point about not making specifications now =
that
>>>> might turn out to be wrong for ICVs.
>>>>
>>>>
>>>>
>>>> Ignoring how this misunderstanding happened, I'll start by asking why.
>>>> Metric changing I understand. Why the other two? (there's a partial
>>>> explanation of one). What alternatives have people implemented in
>>>> comparable protocols?
>>>>
>>>> --
>>>>
>>>> Christopher Dearlove
>>>>
>>>> christopher.dearlove@gmail.com (iPhone)
>>>>
>>>> chris@mnemosyne.demon.co.uk (home)
>>>>
>>>>
>>>> On 23 Apr 2016, at 00:26, Victoria Mercieca 
>>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> Continued in this thread because the other one seems to be more about
>>>> TLV types and metric type numbers, whereas this is about
>>>> regeneration/forwarding.
>>>>
>>>>
>>>>
>>>> To recap, in the current draft, there are 3 things that might change a=
t
>>>> each hop:
>>>> - the metric value (happens in RREQ and RREP),
>>>> - adding/changing Validity Time using the Validity Time TLV (can happe=
n
>>>> in RREQ and RREP),
>>>> - adding an address (and corresponding value in the AddressType TLV to
>>>> indicate how to interpret the address) to indicate the address from wh=
ich
>>>> an RREP_Ack is expected, to accomplish the bidirectionality check (can
>>>> happen in RREP).
>>>>
>>>> If we define a certain portion of the message as immutable and include
>>>> the ICV to verify that part, end to end:
>>>> - The metric value would be excluded from the ICV since it needs
>>>> changing at each hop.
>>>> - Would adding a Validity Time TLV at an intermediate hop be
>>>> acceptable? The whole TLV could be removed in order to calculate the I=
CV?
>>>>
>>>> - Would adding an address cause issues for the ICV, because it's in th=
e
>>>> address block? Could the rule be "if it contains an AckReq address, re=
move
>>>> it (and the corresponding value in the AddressType TLV), before checki=
ng
>>>> the ICV", is that OK? Or would we need to avoid touching the ICV'ed pa=
rt of
>>>> the message altogether, maybe put the AckReq address in a separate Add=
ress
>>>> Block, with an extra AddressType TLV following that address block? Is =
there
>>>> a way to accomplish this?
>>>>
>>>>
>>>>
>>>> Also, to be thorough, do we need to consider RERR messages while we
>>>> discuss regeneration vs forwarding?
>>>>
>>>> - RERR (sent when a link breaks) is a way of saying "I've lost my rout=
e
>>>> so I'm telling others" and "you were my next hop, so now I've also los=
t my
>>>> route, I'll tell others", etc. It's going to be tailored at each step =
to
>>>> include the relevant routes that got deleted, it's not one message bei=
ng
>>>> sent end-to-end like RREQ and RREP are.
>>>>
>>>> - However, RERR (sent when a source of traffic is sending data on a
>>>> route which comes through you, and you want to tell the Packet Source'=
s
>>>> router to delete the route) could be seen as an end-to-end message whi=
ch
>>>> all intermediate routers learn from, similar to RREQ and RREP. It repo=
rts
>>>> one route, and doesn't need changing at intermediate hops, so could be
>>>> protected with ICV.
>>>>
>>>> - Would it be OK to only require a message ICV if a PktSource address
>>>> was included, i.e. when the message needs to go via a number of
>>>> intermediate hops to PktSource's router? All other RERRs are intended =
to be
>>>> one-hop messages, which may in turn prompt other one-hop messages, etc=
...,
>>>> and a packet ICV might be more appropriate?
>>>>
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Victoria.
>>>>
>>>>
>>>>
>>>> On Thu, Mar 17, 2016 at 5:26 PM,  wrote:
>>>>
>>>>
>>>>
>>>> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
>>>> chris.dearlove@baesystems.com> wrote:
>>>>
>>>>
>>>>
>>>> Yes, I meant AODVv2, thanks for the catch.
>>>>
>>>>
>>>>
>>>> So is your (Thomas) proposed base specification a hop count only metri=
c?
>>>>
>>>>
>>>>
>>>> No, the would be silly as base specification, given that hop count
>>>> mostly is useless.
>>>>
>>>>
>>>>
>>>> As base specification I would simply say =E2=80=9CInclude a Metric Typ=
e Message
>>>> TLV with a value field, and a 7182 Message TLV & Timestamp=E2=80=9D as=
 we do in
>>>> OLSRv2 (with the appropriate verbiage as to generation and processing)=
.
>>>>
>>>>
>>>>
>>>> With the message generated by the originator of the RREQ/RREP and *not=
*
>>>> deconstructed/reconstructed/reordered (as is the risk with =E2=80=9Cre=
generation)
>>>> allows knowing that it would be *only* that metric field being modifie=
d
>>>> (other than hop count/limit) for when eventually writing up the extens=
ion.
>>>>
>>>>
>>>>
>>>> (Actually doesn=E2=80=99t the current specification only define hop co=
unt, or
>>>> has that changed in latest draft?)
>>>>
>>>>
>>>>
>>>> No. That is one of the issues I raise in my original. For some reason,
>>>> it cites RFC6551, which is a ROLL document and which has in its abstra=
ct
>>>> that:
>>>>
>>>>
>>>>
>>>>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>>>>
>>>>    compared with traditional wired and ad hoc networks that require th=
e
>>>>
>>>>    specification of new routing metrics and constraints.
>>>>
>>>>
>>>>
>>>> I.e. this document cites a metric document which clearly claims to be
>>>> inapplicable in ad hoc networks. I note that this is another thing I=
=E2=80=99ve
>>>> raised for years without seeing it attempted resolved.
>>>>
>>>>
>>>>
>>>> Best,
>>>>
>>>>
>>>>
>>>> Thomas
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *_____________________________________________________________________=
_____
>>>> *
>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>>>> ]
>>>> *Sent:* 17 March 2016 17:10
>>>> *To:* Dearlove, Christopher (UK)
>>>> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** WARNING ****
>>>>
>>>>
>>>>
>>>> *This message originates from outside our organisation, either from an
>>>> external partner or the internet. Consider carefully whether you shoul=
d
>>>> 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 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
>>>> chris.dearlove@baesystems.com> wrote:
>>>>
>>>>
>>>>
>>>> OK, so we have a message that mutates by:
>>>>
>>>> - Modifying hop count/limit.
>>>>
>>>> - Modifying a metric value.
>>>>
>>>> Anything else?
>>>>
>>>>
>>>>
>>>> As mutating (other than hop count/limit) messages aren=E2=80=99t cover=
ed by
>>>> 5444 or any derivative document (but only recommended against, not ban=
ned)
>>>> that you may need to make the message otherwise immutable (no
>>>> deconstruction and rebuilding, other than guaranteed unchanging) that =
would
>>>> have to be specified by AODVv2. (Easy to say, but needs saying.)
>>>>
>>>>
>>>>
>>>> With you so far.
>>>>
>>>>
>>>>
>>>> Then that information is not in a guaranteed fixed location given by a
>>>> simple offset. So any signature algorithm that finds it and ignores it=
 or
>>>> aggregates on it is specific to OLSRv2.
>>>>
>>>>
>>>>
>>>> Surely you mean AODVv2
>>>>
>>>>
>>>>
>>>> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AODV=
v2
>>>> specialised variant. Which is the sort of thing that the message speci=
fic
>>>> TLV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cbut=
 ignore the value of
>>>> this specific TLV should it occur=E2=80=9D being in the general space.=
 However it
>>>> can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like =
that TLV,
>>>> except if an X TLV is present, set its value field to zero=E2=80=9D).
>>>>
>>>>
>>>>
>>>> Messy, but could work.
>>>>
>>>>
>>>>
>>>> Not that messy, actually, although clearly not as nice as =E2=80=9Cfix=
ed
>>>> offset=E2=80=9D.
>>>>
>>>>
>>>>
>>>> That said, I am arguing for the base spec being:
>>>>
>>>>
>>>>
>>>>             =E2=80=9Cmake the message otherwise immutable (no deconstr=
uction
>>>> and rebuilding, other
>>>>
>>>>              than guaranteed unchanging)=E2=80=9D which is afforded by
>>>> forwarding
>>>>
>>>>
>>>>
>>>>                                     +
>>>>
>>>>
>>>>
>>>>             RFC7182 Timestamps and ICVs.
>>>>
>>>>
>>>>
>>>>                                     +
>>>>
>>>>
>>>>
>>>>             RFC7183 style text bringing it all together.
>>>>
>>>>
>>>>
>>>> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D would=
 very be an
>>>> experimental extension.
>>>>
>>>>
>>>>
>>>> What I object to is, if the base spec specifically renders such
>>>> extensions impossible
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *_____________________________________________________________________=
_____
>>>> *
>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
>>>> ]
>>>> *Sent:* 17 March 2016 16:48
>>>> *To:* Dearlove, Christopher (UK)
>>>> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** WARNING ****
>>>>
>>>>
>>>>
>>>> *This message originates from outside our organisation, either from an
>>>> external partner or the internet. Consider carefully whether you shoul=
d
>>>> 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
>>>> .*
>>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
>>>> chris.dearlove@baesystems.com>:
>>>>
>>>>
>>>>
>>>> Good point about whether you just pass on one cost or a set of costs.
>>>> As I said, not looked at details - I will, when time permits. One cost=
 is
>>>> much easier, and yes, it reduces the fixed size aggregated signatures
>>>> problem to =E2=80=9Cjust=E2=80=9D one of computational load.
>>>>
>>>>
>>>>
>>>> For the record, Thomas=E2=80=99 understanding is correct; the cost is =
one
>>>> aggregated value.
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Lotte Steenrbink
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *_____________________________________________________________________=
_____
>>>> *
>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>>>> ]
>>>> *Sent:* 17 March 2016 16:38
>>>> *To:* Dearlove, Christopher (UK)
>>>> *Cc:* Mobile Ad Hoc Networks mailing list
>>>> *Subject:* Re: Message integrity and message mutability (was RE:
>>>> [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Ite=
ms)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** WARNING ****
>>>>
>>>>
>>>>
>>>> *This message originates from outside our organisation, either from an
>>>> external partner or the internet. Consider carefully whether you shoul=
d
>>>> 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 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
>>>> chris.dearlove@baesystems.com> wrote:
>>>>
>>>>
>>>>
>>>> I appreciate Thomas=E2=80=99s comments about the limitations of messag=
e
>>>> regeneration, but I would be a bit less absolute.
>>>>
>>>>
>>>>
>>>> The issues over end to end authentication and more advanced signatures
>>>> are valid. I need to read the given reference on aggregate signatures =
to
>>>> increase my knowledge (thanks for it), but my understanding of the
>>>> possibilities in this field may offer a solution to the problem, but w=
ith
>>>> some other issues (possibly including a new type of TLV).
>>>>
>>>>
>>>>
>>>> But the hop count/limit point I don=E2=80=99t fully agree with, you ca=
n
>>>> regenerate with an incremented/decremented count/limit, which leaves t=
he
>>>> ability to prevent messages propagating indefinitely, including expand=
ing
>>>> ring searches, and retains the ability to use RFC 5497 interval and
>>>> validity times that might be useful with an expanding ring search (or =
might
>>>> not).
>>>>
>>>>
>>>>
>>>> But the key issue is that AODVv2 wants to accumulate metrics. I still
>>>> haven=E2=80=99t got to the bottom of many details here, but let=E2=80=
=99s for the moment
>>>> just consider that conceptually.
>>>>
>>>>
>>>>
>>>> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft attemp=
ts to do an end
>>>> to end of some information, not this information. I=E2=80=99m not sure=
 if that=E2=80=99s
>>>> useful (and the specialised format is better avoided if possible). Oth=
er
>>>> approaches are hop by hop (might as well use packet signatures) and sh=
ared
>>>> key (might as well go hop by hop). Pairwise signatures for each pair o=
f
>>>> routers I=E2=80=99m discounting as scaling terribly. In the interests =
of
>>>> completeness let=E2=80=99s mention not accumulating metrics, which put=
s us back to
>>>> hop count and that=E2=80=99s not ideal either.
>>>>
>>>>
>>>>
>>>> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=
=80=99ve seen about
>>>> aggregating, but that has some issues of its own, even apart from
>>>> computational load.) I=E2=80=99d love to be proved wrong - someone wit=
h the perfect
>>>> solution to come along.
>>>>
>>>>
>>>>
>>>> Which means that either we make an arbitrary choice - which will be
>>>> disagreed with, but needs discussing first - or create something flexi=
ble.
>>>> Unfortunately flexible in that regard constrains in others, e.g. some
>>>> (many? most?) aggregating signatures need fixed data sizes (which we c=
an do
>>>> by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but =
that has a cost too).
>>>>
>>>>
>>>>
>>>> I have been told by people much more well versed in this than I in
>>>> cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>>>>
>>>>
>>>>
>>>> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 does=
 that mean that
>>>> the message grows as it is being forwarded, and that the recipient of =
a
>>>> RREQ/RREP will know the individual costs of each path segment? My
>>>> understanding is, that the recipient will get =E2=80=9Cthe sum the cos=
ts of each
>>>> path segment=E2=80=9D which should be fitting within a fixed size?
>>>>
>>>>
>>>>
>>>> Thomas
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Sorry, no answers, just comments. And I=E2=80=99m not addressing Thoma=
s=E2=80=99s later
>>>> points here.
>>>>
>>>>
>>>>
>>>> *--*
>>>>
>>>>
>>>>
>>>>
>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>> Intelligence Laboratories *
>>>> *_____________________________________________________________________=
_____
>>>> *
>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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 *ietf@thomasclausen.org
>>>> *Sent:* 17 March 2016 16:00
>>>> *To:* Mobile Ad Hoc Networks mailing list
>>>> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of big
>>>> ticket Items
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> **** WARNING ****
>>>>
>>>>
>>>>
>>>> *This message originates from outside our organisation, either from an
>>>> external partner or the internet. Consider carefully whether you shoul=
d
>>>> 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 organizatio=
n
>>>> .
>>>>
>>>>
>>>>
>>>> Dear all,
>>>>
>>>>
>>>>
>>>> Apologies for not having gotten this done sooner - day-job leaving few
>>>> spare cycles.
>>>>
>>>>
>>>>
>>>> I=E2=80=99ve previously offered reviews and comments, and some of thos=
e have
>>>> been addressed in the latest I-D =E2=80=94 others have not, but should=
 be. I recall
>>>> that there was some mail attempting to rebut parts of the review, and =
I
>>>> will dig it out and reply to that.
>>>>
>>>>
>>>>
>>>> With that being said, I have reviewed the latest version of the
>>>> document, and full details will be forthcoming. There=E2=80=99re a cou=
ple of
>>>> big-ticket/architectural items that I want to address up front, as I
>>>> believe that before we have those hammered out, it will be useless to =
go
>>>> into details. Note, I do not claim that this is an exhaustive list of =
=E2=80=9Cbig
>>>> ticket items=E2=80=9D, but that=E2=80=99s as far as I have gotten in t=
hinking this through.
>>>>
>>>>
>>>>
>>>> I also bring these up as they are items that have been brought up
>>>> repeatedly over the past years, but not resolved nor discussed.
>>>>
>>>>
>>>>
>>>> *Loops*
>>>>
>>>> Just to bring this out: I share Chris=E2=80=99 worry about conflicting=
 and
>>>> concurrent statements from the authors on =E2=80=9CThere are no loops =
possible=E2=80=9D and
>>>> =E2=80=9CWe need to fix two situations where loops can occur=E2=80=9D =
and =E2=80=9Cwe are still
>>>> investigating some loop conditions=E2=80=9D
>>>>
>>>>
>>>>
>>>> I particularly worry that this is not a discussion had in public, but
>>>> apparently in some other forum=E2=80=A6
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Intermediate Route Replies, and all of section 10*
>>>>
>>>> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=
=80=9D, which is
>>>> incoherent with the intended status indicated for this document.
>>>>
>>>>
>>>>
>>>> Specifically, and this is not unrelated to the point about loops above=
,
>>>> intermediate RREPs (section 10.3) are a potential source for loops.
>>>>
>>>>
>>>>
>>>> Expanding Ring Multicast (section 10.1) is not documented in a way tha=
t
>>>> can be implemented (and also, see =E2=80=9CForwarding-vs-regeneration=
=E2=80=9D below, it is
>>>> in the present form of this protocol impossible), etc.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Forwarding-vs-regeneration*
>>>>
>>>> Recent exchanges on the list made me understand that protocol control
>>>> messages are *not* forwarded, but are consumed at each hop, then a new
>>>> message with (almost-but-not-quite) the same content is generated and
>>>> transmitted.
>>>>
>>>>
>>>>
>>>> I have thought some more on this (& read some of the exchanges on the
>>>> list on this topic by Chris, Ulrich, and others), and I am convinced t=
hat
>>>> this is not the right way to go, *at least* for the following reasons:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>             o          *It renders the hop-limit/hop-count fields in
>>>> the RFC5444 message header useless.*
>>>>
>>>>                         This would not be bad if the functionality
>>>> offered by those fields was not useful
>>>>
>>>>                         =E2=80=94 sadly, it is. For example, for scope=
 limited
>>>> flooding (expanding ring search, and
>>>>
>>>>                         such) which may be of interest, and which
>>>> require hop-limit.
>>>>
>>>>                         A hop-count field may also provide a =E2=80=9C=
cheap=E2=80=9D
>>>> (in terms of overhead) additional piece
>>>>
>>>>                         of information to use conjunctively with a
>>>> =E2=80=9Creal=E2=80=9D metric.
>>>>
>>>>
>>>>
>>>>                         The only practical solution would be to
>>>> re-introduce these functions by way of inserting a
>>>>
>>>>                         MessageTLV =E2=80=94 which (i) is not specifie=
d in this
>>>> document, and (ii) which would just
>>>>
>>>>                         serve to render messages bigger than strictly
>>>> needed.
>>>>
>>>>
>>>>
>>>>                         Scope limited flooding  does seem to be a
>>>> necessary requirement, if for no
>>>>
>>>>                         other reason than to prevent information from
>>>> =E2=80=9Ccirculating forever in the network=E2=80=9D.
>>>>
>>>>
>>>>
>>>>             o          *It makes end-to-end authentication
>>>> unnecessarily hard.*
>>>>
>>>>                         I think Chris called this out already, but it
>>>> bears repeating: S generates a message
>>>>
>>>>                         (say, a RREQ), and includes an ICV calculated
>>>> over the content of the message.
>>>>
>>>>                         For any recipient to be able to validate the
>>>> ICV, the message has to be exactly
>>>>
>>>>                         the same =E2=80=94 not just in content, but in
>>>> structure =E2=80=94 as what was generated.
>>>>
>>>>
>>>>
>>>>                         =E2=80=9CRegenerating=E2=80=9D rather than =E2=
=80=9Cforwarding=E2=80=9D
>>>> messages means, that the intermediate
>>>>
>>>>                         router =E2=80=9Cregenerating=E2=80=9D the RREQ=
 may chose a
>>>> different structure (e.g., include TLVs
>>>>
>>>>                         in a different order).
>>>>
>>>>
>>>>
>>>>                         The proposal from
>>>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>>>>
>>>>                         is to add constraints on (i) the set of
>>>> elements to include in a signature and (ii) the
>>>>
>>>>                         order of these elements.
>>>>
>>>>
>>>>
>>>>                         One problem with that approach is (i): if an
>>>> extension adds a message TLV, or an
>>>>
>>>>                         Address TLV, to a message, then that will not
>>>> be =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>>>>
>>>>                         Rather for *each* extension developed, an
>>>> =E2=80=9Cupdates e2esec=E2=80=9D clause needs to be done.
>>>>
>>>>
>>>>
>>>>                         I=E2=80=99d say that this approach would be pr=
one to
>>>> errors =E2=80=94 and add entropy to the process
>>>>
>>>>                         of designing protocol extensions. The
>>>> alternative, a message being generated by the
>>>>
>>>>                         source and *forwarded* (as we do in OLSRv2, fo=
r
>>>> example) would allow ICV TLVs
>>>>
>>>>                         (even, allow reuse of those specified for
>>>> OLSRv2) for covering a message and
>>>>
>>>>                         extensions.
>>>>
>>>>
>>>>
>>>>                         =E2=80=9CBut what about the metrics value whic=
h will
>>>> change on each hop=E2=80=9D, you may say?
>>>>
>>>>                         Fortunately, that is relatively easy to handle=
:
>>>> simply zero out the value of that TLV when
>>>>
>>>>                         generating or verifying the ICV MessageTLV. An=
d
>>>> use Packet-TLVs for hop-by-hop
>>>>
>>>>                         authentication, if needed (but, see below).
>>>>
>>>>
>>>>
>>>>             o          *It prevents the use of more clever/advanced
>>>> signature schemes/ICVs*
>>>>
>>>>                         Aggregate signature algorithms (
>>>> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>>>>
>>>>                         exist, and an interesting use-case can be foun=
d
>>>> in also reactive protocols, allowing verifying
>>>>
>>>>                         not =E2=80=9Cjust=E2=80=9D the end points, but=
 also the
>>>> intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D
>>>>
>>>>                         discussed above, or something smarter).
>>>>
>>>>                         Regeneration of messages, rather than
>>>> forwarding, renders that impossible (or, if used,
>>>>
>>>>                         updating to
>>>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>>>>
>>>>
>>>>
>>>> There are other reasons, but the above are those that jump at me as
>>>> immediate show-stoppers.
>>>>
>>>>
>>>>
>>>> I do honestly not see what possible benefit there is from
>>>> =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inconven=
iences, and security is not
>>>> the least of these. Insisting on =E2=80=9Cregeneration=E2=80=9D requir=
es development of
>>>> =E2=80=9Cnon-general workarounds=E2=80=9D as pointed out above.
>>>>
>>>>
>>>>
>>>> *Security Considerations*
>>>>
>>>> This is an always thorny subject. When OLSRv2 was going through the
>>>> process we got a thorough education in how little we knew about securi=
ty
>>>> from the SEC-ADs, and had to spend about a year or so developing RFC71=
83.
>>>> The bottom line is, that this protocol needs its =E2=80=9CRFC7183  equ=
ivalent=E2=80=9D,
>>>> either as part of the main document, or as an independent document.
>>>> currently, that is not the case.
>>>>
>>>>
>>>>
>>>> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration fro=
m RFC7183
>>>> might be aw good idea, as that was the most recent that went through t=
he
>>>> SEC AD. Regardless of how, however, a =E2=80=9Cmandatory to implement=
=E2=80=9D security
>>>> mechanism most be specified (I think the right term was =E2=80=9CMUST =
implement,
>>>> SHOULD use=E2=80=9D), in sufficient detail to ensure interoperable imp=
lementations.
>>>>
>>>>
>>>>
>>>> As an example, both [RFC6130] and [RFC7181] set out that that:
>>>>
>>>>
>>>>
>>>>       On receiving a ... message, a router MUST first check if the
>>>>
>>>>       message is invalid for processing by this router
>>>>
>>>>
>>>>
>>>> and then proceed to give a number of conditions that, each, will lead
>>>> to a rejection of the message as "badly formed and therefore invalid f=
or
>>>> processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That =
gave a =E2=80=9Chook=E2=80=9D for
>>>> RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message ge=
neration.
>>>>
>>>>
>>>>
>>>> If I was to do RFC7181/RFC6130 today, I would include that directly
>>>> into the protocol specifications. It turned out to be more overhead (a=
nd
>>>> slow down publication anyways) to do it as separate documents.
>>>>
>>>>
>>>>
>>>> Secondly, we need to be a lot more rigid in terms of what ICVs,
>>>> Timestamps, etc. are added/removed, and what that brings.
>>>>
>>>>
>>>>
>>>> For example (with the assumption that messages are *forwarded* and
>>>> *not* regenerated), this could be one option:
>>>>
>>>>
>>>>
>>>>                         o          When a RREQ, RREP message is
>>>> generated, add an ICV Message TLV, which is calculated 
>>>>
>>>>                                      =E2=80=A6(take inspiration from R=
FC7183
>>>> here)
>>>>
>>>>
>>>>
>>>> ...
>>>>
>>>> [Message clipped]
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>>
>>>> ********************************************************************
>>>> 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
>>
>>
>

--001a113e4aa84b35e105317db072
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Just quickly, on this note, if we remove the AckReq from t=
he RREP itself, then because the RREP is multicast, there might be multiple=
 receivers, but there's no way for them to determine if they were the i=
ntended next hop, so they would all have to forward the RREP. The RREP migh=
t then go by multiple routes to get to RREQ_Gen. This assumes all receivers=
 of the RREP have a route to OrigAddr anyway (current rules say if they did=
nt, they would send a RERR back to RREP_Gen).

So, do we =
have to install a route to the neighbour, then unicast the RREP and create =
a separate message with an AckReq, then if no acknowledgement is received, =
blacklist the neighbor and remove the route to the neighbor? along with the=
 route to OrigAddr which is not available because the link is not bidirecti=
onal...?

Regards,
Victoria.

On Mon, Apr 25, 2016 =
at 4:34 PM, Justin Dean <bebemaster@gmail.com> wrote:
=

<=
div>

Jiazi

On Mon, Apr 25, 2016 at 4:5=
9 PM, Victoria Mercieca <vmercieca0@gmail.com> wrote:
=

Hi Chris,


On Mon, Apr 25, 2016 at 3:51 PM, Dearlove=
, Christopher (UK) <chris.dearlove@baesystems.com> wrote:











I has to go back to Victoria=E2=80=99s summa=
ry here. It says:


=C2=A0


2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).


=C2=A0


That doesn=E2=80=99t actually indicate if th=
at=E2=80=99s C=E2=80=99s address or B=E2=80=99s address being included. I=
=E2=80=99d assumed it was C=E2=80=99s address. Your comment makes sense if =
it=E2=80=99s B=E2=80=99s address.
 Reading again, I think you=E2=80=99re probably right. But only probably. C=
an we confirm that.


=C2=A0

C creates the RREP. The included AckReq address is=
 B's address. The RREP then gets multicast.
B receives it=
, sees that it own address is marked as the AckReq address, and sends an ac=
k unicast back to C. 
Anyone else who receives the multicast RREP from C=
 does not send the Ack, since the AckReq address does not match any of thei=
r interface addresses.
=C2=A0
<=
span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73=
,125)">


I assume you meant that the RREP (not RREP_A=
ck) is multicast. There=E2=80=99s a bit of a chicken and egg problem here. =
We do know how we want to unicast.
=
=C2=A0
The RREP is multicast (when we dont know if the link is bi=
directional), the RREP_Ack is always unicast. 

Kind regar=
ds,
Vicky.

=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:
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 Intelligence 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: 25 April 2016 15:26

To: Thomas Heide Clausen

Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc =
Networks mailing list; Victoria Mercieca

Subject: Re: [manet] Message integrity and message mutability (was R=
E: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)=



=C2=A0




=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether =
you should click on any links, open any attachments or reply.
For information regarding <=
/span>
Red Flags that you can look out=
 for in emails you receive,
 click 
here.

If you feel the email is su=
spicious, please follow

this process.








The address in the RREP_Ack may be required due to t=
he RREP_Ack being multicast as there is not yet a verified unicast route in=
stalled yet.=C2=A0 Going to double check if I'm remembering correctly.=
=C2=A0



Justin






=C2=A0




On Mon, Apr 25, 2016 at 10:18 AM, <ietf@thomasclausen.org>=
; wrote:




Hi,




=C2=A0






I must admit that while I have reviewed the protocol=
 several times, I=E2=80=99ve not been digging that deep into the protocol f=
unctioning to catch this issue of how invasive the protocol operations are =
when forwarding a message: there were other
 =E2=80=9Cmajor=E2=80=9D issues to address (and which obscured the details)=
, so as a first order: thank you Victoria, for having called attention to t=
his.






=C2=A0






To the substance of these emails.






=C2=A0






I am afraid that I do not understand the use of inse=
rting validity TLVs while in-flight, into a message. Actually, I am dubious=
 for both the originator inserting this (how can the originator of a messag=
e know how =E2=80=9Clatter parts of the path=E2=80=9D
 will be have=E2=80=9D) except if we are talking duty-cycling of devices an=
d inserting =E2=80=9Cthe remaining time that I am going to be up before I s=
uspend=E2=80=9D. Intuitively, that would also assume fairly long duty cycle=
s =E2=80=9CI am up for tens of seconds=E2=80=9D, which I am not sure are
 actually realistic. And, as Chris says in another email, this is trading o=
ff =E2=80=9Cthe ability to do security=E2=80=9D for an unknown/untested fea=
ture =E2=80=94 which I think is the wrong trade-off.






=C2=A0






On he topic of =E2=80=9Cneeding to put an address in=
=E2=80=9D for RREP-ACK, I must admit that this seems roundabout. I can see =
three issues here:






=C2=A0






o I am not sure that adding an address vs. a flag ma=
y not have to do with the =E2=80=9Cmultiple interfaces/






multiple addresses=E2=80=9D discrimination mechanics=
 of the protocol? I haven=E2=80=99t worked it through, though,=C2=A0=







but that would be a guess.






=C2=A0






o The end-to-end topology diffusion mechanism should=
 not need to be concerned with the=C2=A0






=E2=80=9Cbidirectionally check=E2=80=9D of a local l=
ink (in part, as it encumbers security, but not only).=C2=A0 In short, a=







flag or an address, both are (equally) bad.






=C2=A0






o A cleaner mechanism would be a =E2=80=9Chello mech=
anism=E2=80=9D, not necessarily as NHDP, but a =E2=80=9Cwhen=C2=A0






forwarding a RREQ/RREP, trigger a 3-way hello exchan=
ge, if the link is estimated to be of a=C2=A0






type which potentially can be=C2=A0unidirectional=E2=
=80=9D. There is another benefit to doing that, see the end=C2=A0=







of this email.






=C2=A0






Either way, I do not like the notion of fusing metri=
cs-and-link-bidirectionality-detection any more than I like fusing global-t=
opology-diffusion-and-link-bidirectionality-detection.=C2=A0<=
/p>





=C2=A0






The solution all this is, to me, threefold=







=C2=A0






1) Factor out the bidirectionally check in a (trigge=
red) neighbour detection mechanism=C2=A0






(triggered HELLO message)






=C2=A0






2) Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, =
since they add complexity for no perceivable benefits






=C2=A0






3) Use the security model that we=E2=80=99ve discuss=
ed previously, where (only) the metrics change per hop.






=C2=A0






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 related issue, as I hinted previously.





=C2=A0








The abs=
tract states that the protocol:






=
=C2=A0






=C2=A0=C2=A0 ...is intended for use by mobile routers in wireless, mul=
tihop


=C2=A0=C2=A0 networks.




=
=C2=A0






Section=
 5 paragraph 4 =C2=A0of the document, however, reads:<=
/pre>





=
=C2=A0






=C2=A0=C2=A0 Assuming link metrics are symmetric, the cost of the rout=
es installed


=C2=A0=C2=A0 in the Local Route Set at each router will be correct.=C2=
=A0 While this


=C2=A0=C2=A0 assumption is not always correct, calculating incoming/ou=
tgoing


=C2=A0=C2=A0 metric data is outside of scope of this document. =





=C2=A0








I do not know of any wireless systems,=
 where the assumption that =E2=80=9Clink metrics are symmetric=E2=80=9D act=
ually holds. Consequently, the conclusion in the quoted paragraph:






=C2=A0


=C2=A0=C2=A0 calculating incoming/outgoing


=C2=A0=C2=A0 metric data is outside of scope of this document.<=
u>




=C2=A0








Is not an acceptable design choice.





=C2=A0






While this protocol may not want to =E2=80=9Ccalcula=
te if for this link the metrics is 4 or 5=E2=80=9D, the protocol must be ab=
le to convey and distinguish that =E2=80=9Cthe metric from A to B is 4, and=
 the metric from B to A is 19=E2=80=9D.






=C2=A0






This is a =E2=80=9Crelated issue=E2=80=9D since the =
solution may (as with the bi-directionality check) be in the triggered neig=
hbour detection mechanism: that exchange could, if designed carefully, be u=
sed to probe for and convey metrics information, also.






=C2=A0






Hope this helps,






=C2=A0






=C2=A0






Thomas






=C2=A0












On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK)=
 <chr=
is.dearlove@baesystems.com> wrote:




=C2=A0








Assuming for the moment that everyone will n=
eed an RREP-Ack or won=E2=80=99t (let=E2=80=99s come back to that) why do C=
 and B need to put an address in as an RREQ-Ack request?
 Why not a flag, because the address will be included as the IP sending add=
ress - and we know 5444 is required to pass that on. (It=E2=80=99s used by =
NHDP as well.) Then we don=E2=80=99t need to change the RREP, it will have =
a flag set or not, and won=E2=80=99t change (in this regard).=







=C2=A0






Now let=E2=80=99s consider do we know whethe=
r we can set a fixed flag. First I=E2=80=99d say there are two cases - you=
=E2=80=99ve got a firm control on what=E2=80=99s going on in your network,
 or it=E2=80=99s one of unknown parties and behaviour (consistent with spec=
ification). In the former case you only want one setting, for example no-Ac=
k if running NHDP or your MAC layer tells you about bidirectionality, Ack o=
therwise. In the latter case, I think you
 just always want an Ack. So both cases get you to the same place.






=C2=A0






Should that not be an acceptable argument (t=
hough I think it=E2=80=99s good for where we are - in fact always Ack is cl=
ose) then at flag is a step better, it=E2=80=99s a fixed
 location to change. However it would be better in that case if the two thi=
ngs to change (metric and ack flag) were together. But that has its own iss=
ues, so I won=E2=80=99t go there.






=C2=A0




--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44 (0)1245 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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






From:=C2=A0Victoria Mercieca [mailto:vmercieca0@gmail.com]=C2=A0

Sent:=C2=A025 April 2016 14:15

To:=C2=A0Jiazi YI

Cc:=C2=A0Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad=
 Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)






=C2=A0






=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om 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=C2=A0tha=
t
 you can look out for in emails you receive, click=C2=A0here.

If you feel the email is su=
spicious, please follow=C2=A0this
 process.








Hi Jiazi,










=C2=A0








On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <ietf@jiaziyi.com> wrote:








Hi,=C2=A0








=C2=A0








On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christop=
her (UK) <chris.dearlove@baesystems.com&=
gt; wrote:










With regard to your validity time point, we =
here have a tradeoff. If you allow that feature, it significantly impacts o=
n the approach that was coming together
 on as best you can end to end encryption.






=C2=A0






So the question is, is this a feature that=
=E2=80=99s really wanted? Unfortunately I think we know that the answer to =
that is, we don=E2=80=99t know because we don=E2=80=99t have any
 experience. My view would be that in the tradeoff of an untested feature (=
unless I=E2=80=99m wrong about that) and the security complication, securit=
y wins and drop the feature. If there is some real requirement, then there=
=E2=80=99s a discussion. (Questions like how often
 the intermediate routers actually have any knowledge - typically links bre=
ak for unexpected rather than expected reasons. Andan intermediate router c=
ould possibly use a validity time to influence its behaviour.) Note that dr=
opping the ability of intermediate
 routers to modify/set still allows validity times per route to be set at e=
ndpoints.












=C2=A0










I agree with Chris' concern.










The ValidityTime is optional, which makes the integr=
ity protection hard. Furthermore, it gives a potential attack vector: as al=
l the routers in a path will take the shortest validityTime, a compromised =
router can set the the validityTime
 to a very short value, which will make the route installed along the path =
became invalid (very soon).=C2=A0










=C2=A0










On the other hand, I'm not sure this option will=
 give us much help. Chris mentioned much knowledge intermediate router woul=
d have to decide this value (and how much sense the value would make).=C2=
=A0










Another issue is, a route to a destination might be =
updated by different sources. For example, in the network below:<=
/u>










=C2=A0










A-=
---B-----C










=C2=A0










A first establish a route to B with long validity ti=
me. Then A initiates a route discovery to C. C tends to set a short validit=
y time, which will make the route between B and A expire earlier than expec=
ted.=C2=A0










Is this a problem? Maybe yes, maybe no -- I'm no=
t sure it's considered or not.=C2=A0










=C2=A0
















=C2=A0








Not sure I follow here.=







Currently, the validity=
 time of the route between A and B would not affected by a short validity t=
ime of a route between A and C. Validity times are per-route, and the route=
 A-B and the route A-C are separate.








If we switched to a validity time per neighbor (so t=
hat we can keep validity time separate from route advertisements) as I ment=
ioned in the email below, then the validity of a route between A and C woul=
d be affected if there was a short
 validity time between A and B. But, if B will only route for a certain amo=
unt of time, then the route between A and C will of course be affected. Is =
it best to know in advance that there's a time limit, or just deal with=
 RERRs when they happen?








=C2=A0







=C2=A0






















=C2=A0






With regard to the acknowledgements, the pro=
blem (with regard to security) comes from trying to do two jobs with the sa=
me message - end to end route advertisement
 and hop by hop acknowledgement. I understand the reasons - saving bytes an=
d message types. (I would have to study the protocol really hard to identif=
y if any message types can be folded together and recognised by content rat=
her than type efficiently. This
 I do not expect to do.) Again a tradeoff. This one is in discussion space,=
 though that needs people who understand both sides of the issue, including=
 the details of the bidirectionality mechanism. Of course, as has been said=
, we need one of those.














=C2=A0










I haven't finished my review of the latest draft=
, and I don't get the necessity of AckReq and the corresponding multica=
st RREP yet.=C2=A0










If possible, this "optional" field should =
be avoided.=C2=A0










=C2=A0


















To give an overview of AckReq and RREP:






Since AODVv2 requires b=
idirectional links, this is the way to determine if a link is bidirectional=
.








A----B----C












1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install a=
 route to OrigAddr but they dont yet know if it's valid because they do=
nt know if the link to their next hop is available in the reverse direction=
.










2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).










3) B receives the RREP, installs a route to TargAddr=
 and marks it as valid, since it knows the link to C is bidirectional, beca=
use the RREQ went in one direction and the RREP came in the other. B also s=
ends the RREP_Ack to C and forwards
 the RREP to A (and might change the message to indicate its own AckReq - i=
e that it requires an ack from A).










4) C receives the RREP_Ack from B, and therefore kno=
ws that B received the RREP, therefore the link is bidirectional. C can the=
n mark its route to OrigAddr as valid.










5) Similarly, A receives the RREP, installs the rout=
e to TargAddr and sends an RREP_Ack to B.










6) B receives the RREP_Ack and marks its route to Or=
igAddr as valid.










=C2=A0








Alternatively, in step =
2, if C knows the link to B is bidirectional (perhaps from some earlier rou=
te discovery), it doesnt need to put the AckReq in the RREP. Then in step 3=
, since B doesnt know if the link
 to A is bidirectional, it changes the message to add the AckReq address, i=
n order to get an RREP_Ack from A.






If we want to avoid cha=
nging the message, we'll need to look at forwarding the RREP as-is, and=
 creating a second message to solicit an RREP_Ack, in order to verify that =
the link is bidirectional before marking
 the route to OrigAddr as valid.=C2=A0








Kind regards,










Victoria.








=C2=A0







=C2=A0


















regards










=C2=A0










Jiazi










=C2=A0














=C2=A0




--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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






From:=C2=A0Victoria Mercieca [mailto=
:vmercieca0@gmail.com]=C2=A0

Sent:=C2=A023 April 2016 10:55

To:=C2=A0Christopher Dearlove

Cc:=C2=A0ietf@thomasclausen.org; Dearlove, =
Christopher (UK); Mobile Ad Hoc Networks mailing list<=
/p>











Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=C2=A0






=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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.










Hi Chris,








=C2=A0










These have both been in the draft in some form since=
 before I got involved... but I'll do my best to explain.=









=C2=A0










- For Validity Time, its a way to advertise that you=
 would only support the route contained in the message for a certain period=
 of time. The originator might use this, but the draft was written to allow=
 any intermediate node to be able
 to add it or update it too. The route created in the Local Route Set has a=
n expiration time associated with it, based on the received validity time.<=
u>










- For the AckReq address, its so that you can add in=
to a RREP a request for an acknowledgement, so that you don't have to h=
ave a different message type altogether for working out whether links to ne=
ighbors are bidirectional, and also, since
 you only care about bidirectionality on routes that are being set up, you =
dont need to constantly monitor all neighbors.










=C2=A0










=C2=A0










In order to avoid the potential AckReq-related chang=
es to each message, maybe we do need to introduce a different message speci=
fically for this. We could maybe use RREP_Ack to both request and acknowled=
ge? It means an extra message of control
 traffic that needs to be sent, maybe one extra message per hop on the path=
 of a RREP, but it could still be limited to neighbors which have participa=
ted in the route discovery rather than monitoring all neighbors at all time=
s.=C2=A0










=C2=A0










This message could maybe also include "I'm =
happy to route anywhere for a certain amount of time", sort of like wi=
llingness in OLSR/OLSRv2. So instead of having a validity time per route, i=
ts a validity time per neighbor. Then, for RREQ
 and RREP, only the metric value would change in transit, as discussed. How=
ever, that leads to some issues with deciding what a route's expiration=
 time is. You might know how long the next hop router is valid for, but wha=
t if a router beyond that, which was
 also part of the route, had a lower validity time? You couldn't determ=
ine the real validity time. Do we remove the route expiration time altogeth=
er to avoid this issue? In which case, we would have to rely on RERR messag=
es being sent for routes which become
 invalid when the neighbor's validity time has expired? So neighbor val=
idity time expiration is treated the same as a link break.









=C2=A0










What do you think?










=C2=A0










Kind regards,










Victoria.










=C2=A0










=C2=A0










=C2=A0










=C2=A0










=C2=A0












=C2=A0








On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlov=
e <chris@mnemosyne.demon.co.uk> wrote:<=
u>










Pretty much all of the discussion has been assuming =
only a metric value change. With multiple things changing many of the ideas=
 go out of the window. That reinforces the point about not making specifica=
tions now that might turn out to be
 wrong for ICVs.










=C2=A0










Ignoring how this misunderstanding happened, I'l=
l start by asking why. Metric changing I understand. Why the other two? (th=
ere's a partial explanation of one). What alternatives have people impl=
emented in comparable protocols?



-- =C2=A0








Christopher Dearlove














On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmai=
l.com> wrote:


















Hi all,










=C2=A0










Continued in this thread because the other one seems=
 to be more about TLV types and metric type numbers, whereas this is about =
regeneration/forwarding.










=C2=A0










To recap, in the current draft, there are 3 things t=
hat might change at each hop:=C2=A0

- the metric value (happens in RREQ and RREP),=C2=A0

- adding/changing Validity Time using the Validity Time TLV (can happen in =
RREQ and RREP),=C2=A0

- adding an address (and corresponding value in the AddressType TLV to indi=
cate how to interpret the address) to indicate the address from which an RR=
EP_Ack is expected, to accomplish the bidirectionality check (can happen in=
 RREP).



If we define=C2=A0a certain portion of the message as immutable and include=
 the ICV to verify that part, end to end:=C2=A0

- The metric value would be excluded from the ICV since it needs changing a=
t each hop.=C2=A0

- Would adding a Validity Time TLV at an intermediate hop be acceptable? Th=
e whole TLV could be removed in order to calculate the ICV?







- Would adding an address cause issues for the ICV, =
because it's in the address block? Could the rule be "if it contai=
ns an AckReq address, remove it (and the corresponding value in the Address=
Type TLV), before checking the ICV", is that
 OK? Or would we need to avoid touching the ICV'ed part of the message =
altogether, maybe put the AckReq address in a separate Address Block, with =
an extra AddressType TLV following that address block? Is there a way to ac=
complish this?










=C2=A0










Also, to be thorough, do we need to consider RERR me=
ssages while we discuss regeneration vs forwarding?=C2=A0










- RERR (sent when a link breaks) is a way of saying =
"I've lost my route so I'm telling others" and "you =
were my next hop, so=C2=A0now=C2=A0I've also lost my route, I'll te=
ll others", etc. It's going to be tailored at each step to include=
 the relevant
 routes that got deleted, it's not one message being sent end-to-end li=
ke RREQ and RREP are.=C2=A0










- However, RERR (sent when a source of traffic is se=
nding data on a route which comes through you, and you want to tell the Pac=
ket Source's router to delete the route) could be seen as an end-to-end=
 message which all intermediate routers
 learn from, similar to RREQ and RREP. It reports one route, and doesn'=
t need changing at intermediate hops, so could be protected with ICV.










- Would it be OK to only require a message ICV if a =
PktSource address was included, i.e. when the message needs to go via a num=
ber of intermediate hops to PktSource's router? All other RERRs are int=
ended to be one-hop messages, which may
 in turn prompt other one-hop messages, etc..., and a packet ICV might be m=
ore appropriate?










=C2=A0








Kind regards,








Victoria.










=C2=A0








On Thu, Mar 17, 2016 at 5:26 PM, <i=
etf@thomasclausen.org> wrote:








=C2=A0












On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:








=C2=A0












Yes, I meant AODVv2, thanks for the catch.










=C2=A0










So is your (Thomas) proposed base specificat=
ion a hop count only metric?
















=C2=A0








No, the would be silly as base specification, given =
that hop count mostly is useless.










=C2=A0










As base specification I would simply say =E2=80=9CIn=
clude a Metric Type Message TLV with a value field, and a 7182 Message TLV =
& Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage =
as to generation and processing).=C2=A0










=C2=A0










With the message generated by the originator of the =
RREQ/RREP and *not* deconstructed/reconstructed/reordered (as is the risk w=
ith =E2=80=9Cregeneration) allows knowing that it would be *only* that metr=
ic field being modified (other than hop count/limit)
 for when eventually writing up the extension.










=C2=A0
















(Actually doesn=E2=80=99t the current specif=
ication only define hop count, or has that changed in latest draft?)=















=C2=A0








No. That is one of the issues I raise in my original=
. For some reason, it cites RFC6551, which is a ROLL document and which has=
 in its abstract that:










=C2=A0








=C2=A0=C2=A0 Low-Power and Lossy Networks (LLNs) have unique character=
istics


=C2=A0=C2=A0 compared with traditional wired and ad hoc networks that =
require the


=C2=A0=C2=A0 specification of new routing metrics and constraints. =







=C2=A0










I.e. this document cites a metric document which cle=
arly claims to be inapplicable in ad hoc networks. I note that this is anot=
her thing I=E2=80=99ve raised for years without seeing it attempted resolve=
d.










=C2=A0










Best,










=C2=A0










Thomas










=C2=A0










=C2=A0














=C2=A0








--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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














From:=C2=A0ietf@thomas=
clausen.org=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 17:10

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Lotte Steenbrink; Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=C2=A0








=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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=A0
















On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:












=C2=A0














OK, so we have a message that mutates by:














- Modifying hop count/limit.














- Modifying a metric value.=















Anything else?














=C2=A0














As mutating (other than hop count/limit) mes=
sages aren=E2=80=99t covered by 5444 or any derivative document (but only r=
ecommended against, not banned) that you may
 need to make the message otherwise immutable (no deconstruction and rebuil=
ding, other than guaranteed unchanging) that would have to be specified by =
AODVv2. (Easy to say, but needs saying.)


















=C2=A0












With you so far.












=C2=A0









Then that information is not in a guaranteed=
 fixed location given by a simple offset. So any signature algorithm that f=
inds it and ignores it or aggregates
 on it is specific to OLSRv2.














=C2=A0












Surely you mean AODVv2












=C2=A0









So standard 7182 ICVs don=E2=80=99t do the j=
ob, you would need an AODVv2 specialised variant. Which is the sort of thin=
g that the message specific TLV space is there
 for, I=E2=80=99d be strongly against a =E2=80=9Cbut ignore the value of th=
is specific TLV should it occur=E2=80=9D being in the general space. Howeve=
r it can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like =
that TLV, except if an X TLV is present, set its value field to
 zero=E2=80=9D).














=C2=A0














Messy, but could work.<=
/p>













=C2=A0












Not that messy, actually, although clearly not as ni=
ce as =E2=80=9Cfixed offset=E2=80=9D.














=C2=A0














That said, I am arguing for the base spec being:<=
/u>














=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=E2=80=9Cmake the message otherwise immutable (no deco=
nstruction and rebuilding, other=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=A0than guaranteed unchanging)=E2=80=9D which is af=
forded by forwarding














=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7182 Timestamps and ICVs.














=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7183 style text bringing it all together.=















=C2=A0














The =E2=80=9Caggregated signatures around mutable fi=
eld=E2=80=9D would very be an experimental extension.














=C2=A0














What I object to is, if the base spec specifically r=
enders such extensions impossible














=C2=A0












=C2=A0









=C2=A0










--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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


















From:=C2=A0Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]=C2=A0

Sent:=C2=A017 March 2016 16:48

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0ietf@thomasclausen.org; Mobile Ad =
Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)


















=C2=A0










=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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.












Hi all,
















=C2=A0




















Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher=
 (UK) <chris.dearlove@baesystems.com>=
:
















=C2=A0


















Good point about whether you just pass on on=
e cost or a set of costs. As I said, not looked at details - I will, when t=
ime permits. One cost is much easier,
 and yes, it reduces the fixed size aggregated signatures problem to =E2=80=
=9Cjust=E2=80=9D one of computational load.






















=C2=A0


















For the record, Thomas=E2=80=99 understanding is cor=
rect; the cost is one aggregated value.=C2=A0


















=C2=A0


















Best regards,=C2=A0


















Lotte Steenrbink














=C2=A0















=C2=A0












--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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






















From:=C2=A0ietf@thomas=
clausen.org=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 16:38

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: Message integrity and message mutability (was RE: =
[manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)






















=C2=A0












=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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=A0
























On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:




















=C2=A0






















I appreciate Thomas=E2=80=99s comments about=
 the limitations of message regeneration, but I would be a bit less absolut=
e.






















=C2=A0






















The issues over end to end authentication an=
d more advanced signatures are valid. I need to read the given reference on=
 aggregate signatures to increase my
 knowledge (thanks for it), but my understanding of the possibilities in th=
is field may offer a solution to the problem, but with some other issues (p=
ossibly including a new type of TLV).






















=C2=A0






















But the hop count/limit point I don=E2=80=99=
t fully agree with, you can regenerate with an incremented/decremented coun=
t/limit, which leaves the ability to prevent
 messages propagating indefinitely, including expanding ring searches, and =
retains the ability to use RFC 5497 interval and validity times that might =
be useful with an expanding ring search (or might not).






















=C2=A0






















But the key issue is that AODVv2 wants to ac=
cumulate metrics. I still haven=E2=80=99t got to the bottom of many details=
 here, but let=E2=80=99s for the moment just consider
 that conceptually.






















=C2=A0






















It=E2=80=99s hard to handle end to end. Char=
lie=E2=80=99s draft attempts to do an end to end of some information, not t=
his information. I=E2=80=99m not sure if that=E2=80=99s useful (and the
 specialised format is better avoided if possible). Other approaches are ho=
p by hop (might as well use packet signatures) and shared key (might as wel=
l go hop by hop). Pairwise signatures for each pair of routers I=E2=80=99m =
discounting as scaling terribly. In the
 interests of completeness let=E2=80=99s mention not accumulating metrics, =
which puts us back to hop count and that=E2=80=99s not ideal either.=























=C2=A0






















I don=E2=80=99t think there is an ideal solu=
tion. (I like ideas I=E2=80=99ve seen about aggregating, but that has some =
issues of its own, even apart from computational load.)
 I=E2=80=99d love to be proved wrong - someone with the perfect solution to=
 come along.






















=C2=A0






















Which means that either we make an arbitrary=
 choice - which will be disagreed with, but needs discussing first - or cre=
ate something flexible. Unfortunately
 flexible in that regard constrains in others, e.g. some (many? most?) aggr=
egating signatures need fixed data sizes (which we can do by defining a TLV=
 that =E2=80=9Cfills up=E2=80=9D with hop count, but that has a cost too).<=
/span>


























=C2=A0




















I have been told by people much more well versed in =
this than I in cryptology, that the correct answer is =E2=80=9Csome=E2=80=
=9D.






















=C2=A0






















That said, "AODVv2 wants to accumulate metrics=
=E2=80=9D =E2=80=94 does that mean that the message grows as it is being fo=
rwarded, and that the recipient of a RREQ/RREP will know the individual cos=
ts of each path segment? My understanding is, that the recipient
 will get =E2=80=9Cthe sum the costs of each path segment=E2=80=9D which sh=
ould be fitting within a fixed size?






















=C2=A0






















Thomas






















=C2=A0




















=C2=A0



















=C2=A0






















Sorry, no answers, just comments. And I=E2=
=80=99m not addressing Thomas=E2=80=99s later points here.=























=C2=A0














--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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


























From:=C2=A0manet [mail=
to:manet-bounces@ietf.org]=C2=A0On
 Behalf Of=C2=A0ietf@thomasclausen.org

Sent:=C2=A017 March 2016 16:00

To:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0[manet] draft-ietf-manet-aodvv2-13 review - a couple o=
f big ticket Items


























=C2=A0














=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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***

EXTERNAL=
 EMAIL -- This message originates from outside our organization.<=
/u>














=C2=A0
























Dear all,
























=C2=A0


























Apologies for not having gotten this done sooner - d=
ay-job leaving few spare cycles.


























=C2=A0


























I=E2=80=99ve previously offered reviews and comments=
, and some of those have been addressed in the latest I-D =E2=80=94 others =
have not, but should be. I recall that there was some mail attempting to re=
but parts of the review, and I will dig it out and
 reply to that.


























=C2=A0


























With that being said, I have reviewed the latest ver=
sion of the document, and full details will be forthcoming. There=E2=80=99r=
e a couple of big-ticket/architectural items that I want to address up fron=
t, as I believe that before we have those
 hammered out, it will be useless to go into details. Note, I do not claim =
that this is an exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D, but =
that=E2=80=99s as far as I have gotten in thinking this through.<=
/u>


























=C2=A0


























I also bring these up as they are items that have be=
en brought up repeatedly over the past years, but not resolved nor discusse=
d.


























=C2=A0


























Loops


























Just to bring this out: I share Chris=E2=80=99 worry=
 about conflicting and concurrent statements from the authors on =E2=80=9CT=
here are no loops possible=E2=80=9D and =E2=80=9CWe need to fix two situati=
ons where loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating =
some loop
 conditions=E2=80=9D


























=C2=A0


























I particularly worry that this is not a discussion h=
ad in public, but apparently in some other forum=E2=80=A6


























=C2=A0


























=C2=A0




























Intermediate Route Replies, and all of section=
 10


























Section 10 contains a set of =E2=80=9Cvaguely specif=
ied extensions=E2=80=9D, which is incoherent with the intended status indic=
ated for this document.=C2=A0


























=C2=A0


























Specifically, and this is not unrelated to the point=
 about loops above, intermediate RREPs (section 10.3) are a potential sourc=
e for loops.


























=C2=A0


























Expanding Ring Multicast (section 10.1) is not docum=
ented in a way that can be implemented (and also, see =E2=80=9CForwarding-v=
s-regeneration=E2=80=9D below, it is in the present form of this protocol i=
mpossible), etc.




























=C2=A0


























=C2=A0


























Forwarding-vs-regeneration


























Recent exchanges on the list made me understand that=
 protocol control messages are *not* forwarded, but are consumed at each ho=
p, then a new message with (almost-but-not-quite) the same content is gener=
ated and transmitted.


























=C2=A0


























I have thought some more on this (& read some of=
 the exchanges on the list on this topic by Chris, Ulrich, and others), and=
 I am convinced that this is not the right way to go,=C2=A0at least=
=C2=A0for the following reasons:


























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It renders the hop-limit/hop-count fields in the RFC5444 messag=
e header useless.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0This would not be bad if the functionality offered by tho=
se fields was not useful


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=94 sadly, it is. For example, for scope limited fl=
ooding (expanding ring search, and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0such) which may be of interest, and which require hop-lim=
it.=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0A hop-count field may also provide a =E2=80=9Ccheap=E2=80=
=9D (in terms of overhead) additional piece


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of information to use conjunctively with a =E2=80=9Creal=
=E2=80=9D metric.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The only practical solution would be to re-introduce thes=
e functions by way of inserting a


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0MessageTLV =E2=80=94 which (i) is not specified in this d=
ocument, and (ii) which would just


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0serve to render messages bigger than strictly needed.<=
/u>


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Scope limited flooding =C2=A0does seem to be a necessary =
requirement, if for no


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0other reason than to prevent information from =E2=80=9Cci=
rculating forever in the network=E2=80=9D.


























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It makes end-to-end authentication unnecessarily hard.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I think Chris called this out already, but it bears repea=
ting: S generates a message=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(say, a RREQ), and includes an ICV calculated over the co=
ntent of the message.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0For any recipient to be able to validate the ICV, the mes=
sage has to be exactly


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0the same =E2=80=94 not just in content, but in structure =
=E2=80=94 as what was generated.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforwa=
rding=E2=80=9D messages means, that the intermediate


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose =
a different structure (e.g., include TLVs


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0in a different order).


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The proposal from=C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00=



























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0is to add constraints on (i) the set of elements to inclu=
de in a signature and (ii) the


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0order of these elements.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0One=C2=A0problem with that approach is (i): if an extensi=
on adds a message TLV, or an=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Address TLV, to a message, then that will not be =E2=80=
=9Ccovered=E2=80=9D by the proposed e2esec TLV.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Rather for *each* extension developed, an =E2=80=9Cupdate=
s e2esec=E2=80=9D clause needs to be done.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I=E2=80=99d say that this approach would be prone to erro=
rs =E2=80=94 and add entropy to the process


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of designing protocol extensions. The alternative, a mess=
age being generated by the


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0source and *forwarded* (as we do in OLSRv2, for example) =
would allow ICV TLVs=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(even, allow reuse of those specified for OLSRv2) for cov=
ering a message and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0extensions.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CBut what about the metrics value which will chan=
ge on each hop=E2=80=9D, you may say?


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Fortunately, that is relatively easy to handle: simply ze=
ro out the value of that TLV when


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0generating or verifying the ICV MessageTLV. And use Packe=
t-TLVs for hop-by-hop=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0authentication, if needed (but, see below).=



























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It prevents the use of more clever/advanced signature scheme=
s/ICVs


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Aggregate signature algorithms (=C2=A0https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf<=
/span>)


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0exist, and an interesting use-case can be found in also r=
eactive protocols, allowing verifying


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0not =E2=80=9Cjust=E2=80=9D the end points, but also the i=
ntermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0discussed above, or something smarter).


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Regeneration of messages, rather than forwarding, renders=
 that impossible (or, if used,


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0updating to =C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)


























=C2=A0


























There are other reasons, but the above are those tha=
t jump at me as immediate show-stoppers.


























=C2=A0


























I do honestly not see what possible benefit there is=
 from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inconve=
niences, and security is not the least of these. Insisting on =E2=80=9Crege=
neration=E2=80=9D requires development of =E2=80=9Cnon-general workarounds=
=E2=80=9D as pointed
 out above.


























=C2=A0


























Security Considerations<=
/p>

























This is an always thorny subject. When OLSRv2 was go=
ing through the process we got a thorough education in how little we knew a=
bout security from the SEC-ADs, and had to spend about a year or so develop=
ing RFC7183. The bottom line is, that
 this protocol needs its =E2=80=9CRFC7183 =C2=A0equivalent=E2=80=9D, either=
 as part of the main document, or as an independent document. currently, th=
at is not the case.


























=C2=A0


























A minima, looking at BCP72 and BCP107 =E2=80=94 taki=
ng inspiration from RFC7183 might be aw good idea, as that was the most rec=
ent that went through the SEC AD. Regardless of how, however, a =E2=80=9Cma=
ndatory to implement=E2=80=9D security mechanism most be specified
 (I think the right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D),=
 in sufficient detail to ensure interoperable implementations.


























=C2=A0


























As an example, both [RFC6130] and [RFC7181] set out =
that that:




























=C2=A0


























=C2=A0 =C2=A0 =C2=A0 On receiving a ... message, a r=
outer MUST first check if the


























=C2=A0 =C2=A0 =C2=A0 message is invalid for processi=
ng by this router


























=C2=A0


























and then proceed to give a number of conditions that=
, each, will lead to a rejection of the message as "badly formed and t=
herefore invalid for processing=E2=80=9D =E2=80=94 a list which RFC7183 the=
n amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting
 =E2=80=9Crejection=E2=80=9D. Idem for message generation.

























=C2=A0


























If I was to do RFC7181/RFC6130 today, I would includ=
e that directly into the protocol specifications. It turned out to be more =
overhead (and slow down publication anyways) to do it as separate documents=
.




























=C2=A0


























Secondly, we need to be a lot more rigid in terms of=
 what ICVs, Timestamps, etc. are added/removed, and what that brings.


























=C2=A0


























For example (with the assumption that messages are *=
forwarded* and *not* regenerated), this could be one option:<=
/p>

























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0When a RREQ, RREP message is generated, add an ICV Message TLV, which=
 is calculated <this way>


























=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=E2=80=A6(take inspiration from RFC7183 here)


























=C2=A0


































...



[Message clipped]=C2=A0=C2=A0

_______________________________________________

manet mailing list

manet@ietf.org

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/manet






=C2=A0
















_______________________________________________

manet mailing list

manet@ietf.org

<=
span style=3D"color:purple">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 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

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/manet








=C2=A0














=C2=A0










_______________________________________________

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




=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








--001a113e4aa84b35e105317db072--


From nobody Wed Apr 27 14:38: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 BA11F12D54D for ; Wed, 27 Apr 2016 14:38:33 -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 Jw3yDNOTcLSi for ; Wed, 27 Apr 2016 14:38:31 -0700 (PDT)
Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 56D7212D102 for ; Wed, 27 Apr 2016 14:38:31 -0700 (PDT)
Received: by mail-wm0-x244.google.com with SMTP id r12so17117939wme.0 for ; Wed, 27 Apr 2016 14:38:31 -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 :content-transfer-encoding:message-id:references:to; bh=Ze1GWBWYKHT+fu1nf9Y2mzcHc66IX7jkVLuQE6rPEGE=; b=OLtidMDUprxkcmD7MnpjUMoy33Y40h/RcwGwNwe2Gh1I1/2KUez7kHuWCO+Me8Qup0 yqXfrvEcdJiksFPBMXF9Q0xTNxCZcGdKTkbhDBzbtY/QK0C2TA/uVdjRTTSBJQNdcDwk pMHXBrfc/t15KUI0nR3X9f+PpbZ+wYZPomPWldVbl6I++1o89d9guGoH+n8WL4yP9cYk wzOio3QhhQQbFiQhMX8y9OZEvJBuA0vpdG2jsXXe1pUYu5fZL+6uD+8FN8H7g/t2qgjE Nd3pVp9i6YtFZhAh15f3IGkOqUJuCEE7PNVlQunfnueegoO9nVhRHo33vpgMov0n0bR/ Ksyw==
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 :content-transfer-encoding:message-id:references:to; bh=Ze1GWBWYKHT+fu1nf9Y2mzcHc66IX7jkVLuQE6rPEGE=; b=TBaioQVDfXKBLShNurUVvpk43+n4JAKr7NCNiuorB4bcxZgNJabpCRBAlfj5An6zKr DOCJzWiUivegLp0ZgoXNM3SM5siZ05LShqDahT1S4IaJn0DRLyfm8wlLMCt/JG4NOzSy ezwN7/Y2TYTGe6/dlCFCgB0QhwI7glJALi3EAe1q+nnKtD3bn4LhRqyysWF+M1gW2lfF ehAySIc9GEXHxyI2BShfhmZvQe5UH973EBgLUadkHvlE0VZ83pyUrtK+YeVlEvCdMrz2 utj9KX8Gk+S4U7J5b2/DPzHvl+AlNfV8dnGzAeuQAZ9J2BGHZQYfzQc0TIERAjXpssag NPwA==
X-Gm-Message-State: AOPr4FVMZFBH2vV7hc6AIeeqUz9fcbHCLz+63OXkWe59pJovqUbObCjGOXLabYjk9F5HAw==
X-Received: by 10.194.104.228 with SMTP id gh4mr8565617wjb.134.1461793109888;  Wed, 27 Apr 2016 14:38:29 -0700 (PDT)
Received: from johns-mbp-4.home (host86-151-226-34.range86-151.btcentralplus.com. [86.151.226.34]) by smtp.gmail.com with ESMTPSA id hk7sm6098174wjb.5.2016.04.27.14.38.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Apr 2016 14:38:29 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Dowdell 
In-Reply-To: <8D383418-4CBF-49C6-9871-4E31042E29E5@mnemosyne.demon.co.uk>
Date: Wed, 27 Apr 2016 22:38:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <937ABB81-CCD9-4FD0-A7CF-5114384B3B94@gmail.com> <8D383418-4CBF-49C6-9871-4E31042E29E5@mnemosyne.demon.co.uk>
To: Christopher Dearlove , manet@ietf.org
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [manet] AODVv2 security: Key Management to BCP107
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, 27 Apr 2016 21:38:33 -0000

OK so there=E2=80=99s a really big problem here. We were asked to run =
the guidance. Running the guidance gives the result below. In this case, =
the guidance is not giving a result that makes sense. The routers =
themselves are almost certainly on the move, there is no other reason =
why you would want to only determine the path at send time. You now have =
routers potentially from multiple organisations occasionally conversing =
with other routers. I do not see that a single shared key is going to =
pass muster; I certainly wouldn=E2=80=99t recommend such a use case.

Regards
John

> On 27 Apr 2016, at 21:27, Christopher Dearlove =
 wrote:
>=20
> I really don't know what you are proposing. I think you have a great =
big can of worms here that hasn't been thought through.
>=20
> So AODVv2 is sending, as it's very first message, an RREQ. We want to =
authenticate this. How? You can't negotiate a key, you haven't got a =
route. You don't know who your neighbours are. You plan to multicast to =
them in fact, what's your key plan for that?
>=20
> If you say use long term key, what are you actually going to use the =
short term key for? And if you plan to exchange message with your =
neighbours, that rather preempts a significant part of your protocol =
(why establish bidirectionality when your key negotiation must have done =
that?)
>=20
> And then we've spent some time discussing end to end authentication. =
That doesn't work with short term keys for adjacencies only.
>=20
> We (OLSRv2) went through, more than once, a hard argument why =
automated key management wasn't appropriate here, and why the exceptions =
did apply.
>=20
> But in a nutshell (though this wasn't the argument we used, just why =
we needed it) how can you agree a key without communicating? How do you =
communicate more than one hop without a route? How do you authenticate =
the messages to create that route without a key?
>=20
> Something has to give. And in giving you might end up redesigning your =
whole protocol. Or using something quite clever that there's no hint of =
here. Or using the simplest fallback of a single shared key (our 7183 =
default) which isn't automatically managed.
>=20
> --=20
> Christopher Dearlove
>=20
>> On 27 Apr 2016, at 21:10, John Dowdell  =
wrote:
>>=20
>> Hi all
>>=20
>> As an AODVv2 co-author I=E2=80=99d like to propose this position =
regarding key management against BCP107, one of the artefacts we are =
being asked to state a position over. I=E2=80=99d also like to state =
that I=E2=80=99m open to contributions from others knowledgeable on this =
topic or who have been this way previously.
>>=20
>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka =
BCP107 is the set of guidelines for choosing either automated or manual =
key management for cryptographic purposes. It=E2=80=99s not a long read =
and guides the reader through a set of tests as to whether automated or =
manual key management would be suitable for the application in hand.
>>=20
>> The very first question is does AODVv2 need key management at all? I =
would contend that it does, since we require to secure the signalling =
traffic for the routing algorithm. The aim here is therefore to purely =
assist in the security of the signalling traffic; security of user data =
that is forwarded once an AODVv2 route has been established is out of =
scope.
>>=20
>> Section 1 of BCP107 states that automated key management SHOULD be =
used. Thus my answer will be in favour of that unless I can contend =
otherwise.
>>=20
>> The guidelines in section 2 outline that automated key management =
derives short-term session keys between two parties. In the case of =
AODVv2, this would correspond to two routers that form or wish to form =
an adjacency.
>>=20
>> The guidelines state that the short-term keys may be derived from =
long-term keys, and that the dissemination of long term keys is out of =
scope of BCP107. I would envisage that an AODVv2 router, given that it =
would form ephemeral ad hoc networks with other routers as it went about =
its business, would be supplied with one or more long term keys for a =
period of time, to be determined by the system integrator, and that the =
long term keys would then be used to derive short term keys which are =
used in the forming of adjacencies plural.
>>=20
>> Section 2.1 of BCP107 describes the conditions under which automated =
key management MUST be used.
>>=20
>> - If a large number of static keys would have to be managed. It is =
not known how many routers could be deployed, but if this is aimed at ad =
hoc applications then the number of routers could quickly become large. =
I consider this condition is met.
>>=20
>> - Any stream cipher is used. This is a choice for the system =
integrator, but an AES based cipher is a real possibility. There is more =
likelihood this condition is met than not met.
>>=20
>> - An initialisation vector (IV) might be re-used. I am open to advice =
on this point.
>>=20
>> - Large amounts of data need to be encrypted in a short time. Even if =
there is no specific guidance on =E2=80=98large=E2=80=99, I do not =
consider this condition to be met, since signalling messages are likely =
to be short relative to the user data that could be exchanged.
>>=20
>> - Long-term session keys are used by more than two parties, including =
multicast applications. AODVv2 uses multicast extensively, and therefore =
I consider this condition to be met.
>>=20
>> - Device turnover is frequent. This is a certainty in ad hoc =
networks, so I consider this condition to be met.
>>=20
>> I believe the outcomes from section 2.1 guidance is more in favour of =
automated key management.
>>=20
>> However, to consider the guidance on manual key management in section =
2.2 of BCP107, where such management may be reasonable:
>>=20
>> - the environment has very limited bandwidth or high round trip =
times. Some applications for AODVv2 may use very low bandwidths, perhaps =
for low-power sensor networks. The point is made that "public key =
systems require long exchanges and lots of computation=E2=80=9D. The =
AODVv2 author team believe that very low power hardware might be used by =
some implementors, which may give problems when being required to use =
public key exchanges. Such implementors need to carefully consider the =
tradeoff between the need for security and the need for very low power =
consumption. Such implementors should also consider whether some =
functions should be realised in hardware or software, and the resulting =
impact on system performance and power consumption.
>>=20
>> - the information being protected is of low value. I do not consider =
this condition to be met; on the contrary, the signalling traffic in =
AODVv2 is of high value to a potential attacker.
>>=20
>> - the scale of each deployment is limited. I consider that this is an =
unknown, but I also consider that we should engineer for larger networks =
with ephemeral connections rather than smaller ones.
>>=20
>> Discussion welcome.
>>=20
>> Regards
>> John
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>=20


From nobody Wed Apr 27 14:46: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 70BB312D1C8 for ; Wed, 27 Apr 2016 14:46:15 -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 14medyt8E7p0 for ; Wed, 27 Apr 2016 14:46:12 -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 D822012B018 for ; Wed, 27 Apr 2016 14:46:11 -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 <1avXHe-0047ER-DZ>; Wed, 27 Apr 2016 23:46:10 +0200
Received: from x4e3337bf.dyn.telefonica.de ([78.51.55.191] helo=[192.168.1.2]) by inpost2.zedat.fu-berlin.de (Exim 4.85) for manet@ietf.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id <1avXHd-0020Ev-QH>; Wed, 27 Apr 2016 23:46:10 +0200
From: Lotte Steenbrink 
Content-Type: multipart/alternative; boundary="Apple-Mail=_213AA0AA-98F5-41E0-A126-A9AEECDAC517"
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Date: Wed, 27 Apr 2016 23:46:09 +0200
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org>    
To: Mobile Ad Hoc Networks mailing list 
In-Reply-To: 
X-Mailer: Apple Mail (2.3112)
X-Originating-IP: 78.51.55.191
X-ZEDAT-Hint: A
Archived-At: 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 27 Apr 2016 21:46:15 -0000

--Apple-Mail=_213AA0AA-98F5-41E0-A126-A9AEECDAC517
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,
I=E2=80=99m currently revising the security considerations with regards =
to the move from regeneration to forwarding, which depends on a decision =
being made on how/where we want to mention the possibility of zeroing =
out TLVs to calculate the ICV for the rest of a message=E2=80=99s =
contents (see second * of my last e-mail). I=E2=80=99ve not found a =
decision on this in other thread (please pardon me if I overlooked =
something), so I=E2=80=99ll bump this thread and ask the WG for its =
opinions. (again, personally, the 2nd option outlined by Christopher =
seems more appealing to me)

Regards,
Lotte

> Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink =
:
>=20
> Hi all,
> to summarize:
>=20
> * AODVv2 message Type numbers should be in the Experimental type space =
and the AODVv2 TLV Types should be message type-specific. This also =
means changing the text regarding IANA actions and changing the text =
regarding what the experiment is to something along the lines of =E2=80=9C=
we want to gather experience on how to make generic metric TLVs and ICVs =
that work with changing metric TV values happen with reactive =
protocols=E2=80=9D
> * we=E2=80=99re undecided on (to quote Christopher) the "here's a =
mechanism we haven't really thought through in detail, but at least =
we've defined one", or "we know the sort of thing we want, and we'll =
describe it, but rather than produce something not quite right, we'll =
not go further=E2=80=9C decision on temporarily setting the metric value =
to 0 (i.e. the who and how). (personally, I think I=E2=80=99d prefer the =
latter approach, but that=E2=80=99s an entirely gut feeling-based =
preference)
>=20
> Did I catch that correctly? If so, I=E2=80=99ll put together and =
suggest some text for the first point as soon as I get home and in case =
there has been a decision on the second by then, I=E2=80=99ll try to =
tackle that one too. :)
>=20
> Best regards, Lotte
>=20
>> Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) =
>:
>>=20
>> I have no problem with that. I was trying to lay out the issues =
without muddying the water with my preference.
>> =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: Justin Dean [mailto:bebemaster@gmail.com =
]=20
>> Sent: 22 April 2016 15:35
>> To: Dearlove, Christopher (UK)
>> Cc: Thomas Heide Clausen; Mobile Ad Hoc Networks mailing list
>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>> =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
>> Speaking as participant.
>>=20
>> I kind of like the idea of using the experimental message type space. =
 We only have a limited amount of these message types.  The TLV =
assignments could just use the message type specific space and there =
isn't an issue there.  IANA wouldn't assign a number but I don't see why =
the document couldn't specify the experimental numbers it was going to =
use so other future near term experiential protocols could do the same =
and generally avoid conflict.  If the experiment is successful IANA =
assignments could be made.  Functionally no real difference with =
protections vs long term usage of limited space.
>> =20
>> Justin
>> =20
>> On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) =
> =
wrote:
>> There's rather a contradiction between the concepts of a definition =
of a protocol, even Experimental, and experimental space, which usually =
assumes that the user can do what he or she likes in it.
>>=20
>> But chewing up messages types (how many, 3?) of which there are =
relatively few for experimental is long term a problem, although short =
term not.
>>=20
>> TLV space is easier in two regards. It's bigger (though the prime =
real estate of type extension zero isn't) and can have message type =
specific TLVs.
>>=20
>> So TLVS can actually be invisible, if that option is chosen. For =
messages something has to give. Least bad option is again one of those =
we should discuss, but time ...
>>=20
>> (To be precise, messages types from 224 are defined in RFC 5444 as " =
Experimental Use", of which BCP 26 says "Similar to private or local use =
only, with the  purpose being to facilitate experimentation." The =
alternative 0-223 space is Expert Review. IANA still thinks the experts =
are Joe Macker and the recused Stan Ratliff. But that's a soluble nit.)
>>=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
>> -----Original Message-----
>> From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org =
]
>> Sent: 22 April 2016 14:21
>> To: Dearlove, Christopher (UK)
>> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>=20
>> ----------------------! WARNING ! ---------------------- This message =
originates from outside our organisation, either from an external =
partner or from the internet.
>> Consider carefully whether you should click on any links, open any =
attachments or reply.
>> Follow the 'Report Suspicious Emails' link on IT matters for =
instructions on reporting suspicious email messages.
>> --------------------------------------------------------
>>=20
>>=20
>> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) =
> =
wrote:
>> >
>> > Once you're entirely in AODV2's own space, and AODVv2 is =
experimental (working assumption for this discussion) you have more =
liberty.
>> >
>>=20
>> Yep.
>>=20
>> Taken somewhat by surprise both by the sudden "rush" and the =
experimental maturity level, I am wondering (and haven't thought =
through) about experimental space vs non-experimental (for message =
types, and consequently for message type specific TLV types).
>>=20
>> I think that if the AODVv2 experiment specifies the use of Message =
types from the Experimental message type space without making actual =
registrations in the IANA registry, AND the use of type specific TLV =
types, this becomes a non-issue entirely (by design, this is precisely =
what that experimental space is for)
>>=20
>> Whereas, as you point out, the alternative is a "can open - worms =
everywhere" situation that I think time is too short to solve?
>>=20
>> Thomas
>>=20
>>=20
>> > Then you could try specifying it. But with a very good chance of =
producing something you later decide you should have done differently.
>> >
>> > I honestly don't know which would go down better (or less badly) - =
"here's a mechanism we haven't really thought through in detail, but at =
least we've defined one", or "we know the sort of thing we want, and =
we'll describe it, but rather than produce something not quite right, =
we'll not go further".
>> >
>> > --
>> > 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
>> >
>> >
>> > -----Original Message-----
>> > From: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de =
]
>> > Sent: 22 April 2016 13:59
>> > To: Mobile Ad Hoc Networks mailing list
>> > Cc: Henning Rogge; Dearlove, Christopher (UK)
>> > Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>> >
>> > ----------------------! WARNING ! ---------------------- This =
message originates from outside our organisation, either from an =
external partner or from the internet.
>> > Consider carefully whether you should click on any links, open any =
attachments or reply.
>> > Follow the 'Report Suspicious Emails' link on IT matters for =
instructions on reporting suspicious email messages.
>> > --------------------------------------------------------
>> >
>> > Hello Christopher,
>> >
>> >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) =
>:
>> >>
>> >> Just be careful to note that this concept is as currently being =
discussed (a) specific to AODVv2, and (b) not an application of 7182, =
which has no knowledge of special TLVs.
>> >>
>> >> This is something we'd want to get right, and need to get right if =
in any space not specific to ADODVv2, because getting it wrong produces =
future problems.
>> >
>> > Makes sense.
>> >
>> >> I can see some possible approaches, none is ideal and we're rather =
out
>> >> of time to specify. But this is experimental, so I think we might =
be
>> >> able to indicate the shape of the solution without specifying it,
>> >> which would be a different RFC, under a bit less time pressure.
>> >> (Extensions to existing protocols like 7182 would naturally be in
>> >> scope rechartered I think.)
>> >>
>> >> To indicate the range that's open, here are two possible ideas, =
one of which has an impact now, so needs to be agreed. Note that I'm not =
suggesting (in fact quite the opposite) defining an extension to 7182 =
here, rather enabling such an extension, if written, to "do the right =
thing".
>> >> - We have an extension to 7182 that says "zero out all value =
octets in protocol specific TLVs. That requires now putting the AODVv2 =
metric TLV in that space.
>> >
>> > Just to make sure that I understood you correctly=E2=80=93 =E2=80=9Ct=
hat space=E2=80=9D meaning making the AODVv2 metric TLV protocol =
specific? (By =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m =
referring to the generic TLV we=E2=80=99ve been talking about on this =
list earlier this week).
>> >
>> >> - We have an extension to 7182 that adds extra material to the =
value field that indicates (TBD how, by position with sanity check that =
this is TLV value perhaps?) which octets are to be zeroed out before the =
ICV is calculated.
>> >
>> > The way I understand that approach, it wouldn=E2=80=99t warrant any =
action from AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set =
the Metric value to zero=E2=80=9D (leaving the nitty gritty of how this =
would be done in detail to future work)=E2=80=A6 Is that correct?
>> >
>> >>
>> >> We do not have the time to specify this in an acceptable manner =
within two weeks though. But the security consideration section could =
say something along the lines of "this enables the use of an ICV defined =
to zero out these octets=E2=80=9C.
>> >
>> > Okay. :)
>> >
>> > Best regards,
>> > Lotte
>> >
>> >>
>> >> --
>> >> 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
>> >>
>> >> -----Original Message-----
>> >> From: manet [mailto:manet-bounces@ietf.org =
] On Behalf Of Lotte
>> >> Steenbrink
>> >> Sent: 22 April 2016 10:28
>> >> To: Henning Rogge
>> >> Cc: Mobile Ad Hoc Networks mailing list
>> >> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>> >> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>> >>
>> >> ----------------------! WARNING ! ---------------------- This =
message originates from outside our organisation, either from an =
external partner or from the internet.
>> >> Consider carefully whether you should click on any links, open any =
attachments or reply.
>> >> Follow the 'Report Suspicious Emails' link on IT matters for =
instructions on reporting suspicious email messages.
>> >> --------------------------------------------------------
>> >>
>> >> *** WARNING ***
>> >> EXTERNAL EMAIL -- This message originates from outside our =
organization.
>> >>
>> >>
>> >> Hi Henning,
>> >>
>> >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge >:
>> >>>
>> >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>> >>> > wrote:
>> >>>> Hi Thomas,
>> >>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=
=E2=80=9D language
>> >>>> in the first place is that we=E2=80=99ve been told that whenever =
one bit in
>> >>>> the message (apart from its header) is changed, the entire thing =
has to be regenerated.
>> >>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been =
misunderstanding
>> >>>> each other for more than a year. :( Anyway, it seems like =
we=E2=80=99re
>> >>>> getting close now, so yay.
>> >>>
>> >>> "Modifying" the binary message instead of parsing and generating =
a
>> >>> new one will be difficult as soon someone writes an extension to
>> >>> AODVv2 that adds more TLVs to the message.
>> >>
>> >> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99=
s what you explained to me when I got confused about the topic last =
spring=E2=80=A6 But=E2=80=93 even if a message contains TLVs that the =
AODVv2 implementation handling it doesn=E2=80=99t understand, it will =
still be able to recognize the Metric TLV, right? Isn=E2=80=99t that the =
nifty thing about RFC5444? So, while we really shouldn=E2=80=99t write =
=E2=80=9Cbefore calculating the ICV, set the n-th 4 octets to 0=E2=80=9D, =
we might say =E2=80=9Cidentify the octets that make up the metric value =
and set those to 0=E2=80=9D?
>> >>
>> >> Best regards,
>> >> Lotte
>> >>
>> >>> Henning Rogge
>> >>
>> >> _______________________________________________
>> >> 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 =

>>=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=_213AA0AA-98F5-41E0-A126-A9AEECDAC517
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi all,
I=E2=80=99m currently revising the =
security considerations with regards to the move from regeneration to =
forwarding, which depends on a decision being made on how/where we want =
to mention the possibility of zeroing out TLVs to calculate the ICV for =
the rest of a message=E2=80=99s contents (see second * of my last =
e-mail). I=E2=80=99ve not found a decision on this in other thread =
(please pardon me if I overlooked something), so I=E2=80=99ll bump this =
thread and ask the WG for its opinions. (again, personally, the 2nd =
option outlined by Christopher seems more appealing to me)

Regards,
Lotte
=

--Apple-Mail=_213AA0AA-98F5-41E0-A126-A9AEECDAC517--


From nobody Wed Apr 27 15:11: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 620CA12D895 for ; Wed, 27 Apr 2016 15:11:32 -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 Ohbnsc1cDLmP for ; Wed, 27 Apr 2016 15:11:29 -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 2EB0812D5A4 for ; Wed, 27 Apr 2016 15:11:28 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id a17so36067239wme.0 for ; Wed, 27 Apr 2016 15:11:28 -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=g/bHLrwrhbKd8+ibY6KPQkk0BrepdX53NrB54Kh8C2w=; b=VWQzzKUTcVZWpcQV5OnVp72VLs54O7LrH2WGtQ66qgKKB2vNWO8A5EEcWMDegFjpva aWJmEl+nKLbDKbLh4HvJsH3CVQyUkibA+S6EDgsyPDvp6DKK46arVsGv+LLm2vaLMpOq sEQYFvbZiE/uvZ0mo//8KvJy+9zJJwa/lx3NR0ovXyNkvlmbg31o5F40pyGKOKdSEXKl +pfgHgU59idJFEst/TcrWrNqCiW6bveUGaiQVLP0epmiXSeyKtJB4KVguZwAWYPlHTPj H5ZZ5Q0+80DQqBLJ/Ra9a9zhrc1FrbrqNU+1jzbwY9dAZBX8CU2woaEL4vAoMKcpNJ7k 1RbQ==
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=g/bHLrwrhbKd8+ibY6KPQkk0BrepdX53NrB54Kh8C2w=; b=Kd84BdBUiPgaYVGEcIdGFHyLC2qTd2dyn/VEGP0EEinF7Zg4hS6eJ7TLS/9VZ0JkVH ytKajEckyXHtM7LItrZ5m82STLZvgU9/YvQQ5X0v1fuqYCFAqEjvd1PKlhi4MljPW3k0 VbG1SYRqciVN8d7zPojSw2fC+bKb/7TJqBxOsRVOMcjuFR3FczbiBSjxEyXxOGOUO461 FpYLzTXmdjm6SrdTKZNy0DYJabgMhhzgOHGjZEAs4Pps3eDXMefsIz+/KtPtpONasqyU WE8vb4tlckV4VUMxOgK/jK57UKxY6Bn2wE9LN3uP8H6Op4zO+K0c6KTFbg/HiiQeVFRV tRAg==
X-Gm-Message-State: AOPr4FUe4lJOUpQ0vcyTqE+KkMYUVqWNrlNHjTRd7u0wGDdxxfGCryXxYZPUyierAPzbog==
X-Received: by 10.194.26.41 with SMTP id i9mr12965391wjg.114.1461795086686; Wed, 27 Apr 2016 15:11:26 -0700 (PDT)
Received: from [10.4.56.45] (82-132-225-45.dab.02.net. [82.132.225.45]) by smtp.gmail.com with ESMTPSA id jh2sm6172579wjb.39.2016.04.27.15.11.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 15:11:25 -0700 (PDT)
References: <937ABB81-CCD9-4FD0-A7CF-5114384B3B94@gmail.com> <8D383418-4CBF-49C6-9871-4E31042E29E5@mnemosyne.demon.co.uk> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPhone Mail (13E238)
From: Christopher Dearlove 
Date: Wed, 27 Apr 2016 23:11:21 +0100
To: John Dowdell 
Archived-At: 
Cc: Christopher Dearlove , manet@ietf.org
Subject: Re: [manet] AODVv2 security: Key Management to BCP107
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, 27 Apr 2016 22:11:32 -0000

Neither would I. Single shared key was what we were able to get 7181 passed r=
eferring to (7183) as a lowest common denominator "must implement, don't hav=
e to use". And I'm not certain it would pass again today. And not what I'd w=
ant to use.

(I should note that I slightly oversimplified when I said single shared secr=
et key. The actual mechanism is more than one key, with IDs. But with no mec=
hanism to choose among them.)

Beyond that, key management in an ad hoc network is hard because of the chic=
ken and egg problem of finding routes securely and using routes to exchange m=
aterial. Plus additional complications of multicast. And reactive is probabl=
y worse than proactive.

Do I think it's an impossible problem? No. But I don't think there's anythin=
g convincing that can be simply said "do this, it works". I'd like to be wro=
ng, something simple that solves all your problems would be great. But at th=
is point I don't think I am.

What I do think is that this is a suitable problem for future work. (Subject=
 to all the comments I've made about people, interest etc.) But I don't know=
 how you handle it now. The shared secret key I've noted was how we broke ou=
r logjam - and it took a lot longer than the time you've got. A real solutio=
n, longer still.

You could try just saying something about automatic key management without h=
aving an actual approach, let alone a defined interoperable one. If it passe=
d the IESG I'd be flabbergasted. I'd not even be happy for it to pass WGLC.

Solution? Sorry, don't have one beyond what I've said above.

--=20
Christopher Dearlove

> On 27 Apr 2016, at 22:38, John Dowdell  wrote=
:
>=20
> OK so there=E2=80=99s a really big problem here. We were asked to run the g=
uidance. Running the guidance gives the result below. In this case, the guid=
ance is not giving a result that makes sense. The routers themselves are alm=
ost certainly on the move, there is no other reason why you would want to on=
ly determine the path at send time. You now have routers potentially from mu=
ltiple organisations occasionally conversing with other routers. I do not se=
e that a single shared key is going to pass muster; I certainly wouldn=E2=80=
=99t recommend such a use case.
>=20
> Regards
> John
>=20
>> On 27 Apr 2016, at 21:27, Christopher Dearlove  wrote:
>>=20
>> I really don't know what you are proposing. I think you have a great big c=
an of worms here that hasn't been thought through.
>>=20
>> So AODVv2 is sending, as it's very first message, an RREQ. We want to aut=
henticate this. How? You can't negotiate a key, you haven't got a route. You=
 don't know who your neighbours are. You plan to multicast to them in fact, w=
hat's your key plan for that?
>>=20
>> If you say use long term key, what are you actually going to use the shor=
t term key for? And if you plan to exchange message with your neighbours, th=
at rather preempts a significant part of your protocol (why establish bidire=
ctionality when your key negotiation must have done that?)
>>=20
>> And then we've spent some time discussing end to end authentication. That=
 doesn't work with short term keys for adjacencies only.
>>=20
>> We (OLSRv2) went through, more than once, a hard argument why automated k=
ey management wasn't appropriate here, and why the exceptions did apply.
>>=20
>> But in a nutshell (though this wasn't the argument we used, just why we n=
eeded it) how can you agree a key without communicating? How do you communic=
ate more than one hop without a route? How do you authenticate the messages t=
o create that route without a key?
>>=20
>> Something has to give. And in giving you might end up redesigning your wh=
ole protocol. Or using something quite clever that there's no hint of here. O=
r using the simplest fallback of a single shared key (our 7183 default) whic=
h isn't automatically managed.
>>=20
>> --=20
>> Christopher Dearlove
>>=20
>>> On 27 Apr 2016, at 21:10, John Dowdell  wro=
te:
>>>=20
>>> Hi all
>>>=20
>>> As an AODVv2 co-author I=E2=80=99d like to propose this position regardi=
ng key management against BCP107, one of the artefacts we are being asked to=
 state a position over. I=E2=80=99d also like to state that I=E2=80=99m open=
 to contributions from others knowledgeable on this topic or who have been t=
his way previously.
>>>=20
>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka BCP10=
7 is the set of guidelines for choosing either automated or manual key manag=
ement for cryptographic purposes. It=E2=80=99s not a long read and guides th=
e reader through a set of tests as to whether automated or manual key manage=
ment would be suitable for the application in hand.
>>>=20
>>> The very first question is does AODVv2 need key management at all? I wou=
ld contend that it does, since we require to secure the signalling traffic f=
or the routing algorithm. The aim here is therefore to purely assist in the s=
ecurity of the signalling traffic; security of user data that is forwarded o=
nce an AODVv2 route has been established is out of scope.
>>>=20
>>> Section 1 of BCP107 states that automated key management SHOULD be used.=
 Thus my answer will be in favour of that unless I can contend otherwise.
>>>=20
>>> The guidelines in section 2 outline that automated key management derive=
s short-term session keys between two parties. In the case of AODVv2, this w=
ould correspond to two routers that form or wish to form an adjacency.
>>>=20
>>> The guidelines state that the short-term keys may be derived from long-t=
erm keys, and that the dissemination of long term keys is out of scope of BC=
P107. I would envisage that an AODVv2 router, given that it would form ephem=
eral ad hoc networks with other routers as it went about its business, would=
 be supplied with one or more long term keys for a period of time, to be det=
ermined by the system integrator, and that the long term keys would then be u=
sed to derive short term keys which are used in the forming of adjacencies p=
lural.
>>>=20
>>> Section 2.1 of BCP107 describes the conditions under which automated key=
 management MUST be used.
>>>=20
>>> - If a large number of static keys would have to be managed. It is not k=
nown how many routers could be deployed, but if this is aimed at ad hoc appl=
ications then the number of routers could quickly become large. I consider t=
his condition is met.
>>>=20
>>> - Any stream cipher is used. This is a choice for the system integrator,=
 but an AES based cipher is a real possibility. There is more likelihood thi=
s condition is met than not met.
>>>=20
>>> - An initialisation vector (IV) might be re-used. I am open to advice on=
 this point.
>>>=20
>>> - Large amounts of data need to be encrypted in a short time. Even if th=
ere is no specific guidance on =E2=80=98large=E2=80=99, I do not consider th=
is condition to be met, since signalling messages are likely to be short rel=
ative to the user data that could be exchanged.
>>>=20
>>> - Long-term session keys are used by more than two parties, including mu=
lticast applications. AODVv2 uses multicast extensively, and therefore I con=
sider this condition to be met.
>>>=20
>>> - Device turnover is frequent. This is a certainty in ad hoc networks, s=
o I consider this condition to be met.
>>>=20
>>> I believe the outcomes from section 2.1 guidance is more in favour of au=
tomated key management.
>>>=20
>>> However, to consider the guidance on manual key management in section 2.=
2 of BCP107, where such management may be reasonable:
>>>=20
>>> - the environment has very limited bandwidth or high round trip times. S=
ome applications for AODVv2 may use very low bandwidths, perhaps for low-pow=
er sensor networks. The point is made that "public key systems require long e=
xchanges and lots of computation=E2=80=9D. The AODVv2 author team believe th=
at very low power hardware might be used by some implementors, which may giv=
e problems when being required to use public key exchanges. Such implementor=
s need to carefully consider the tradeoff between the need for security and t=
he need for very low power consumption. Such implementors should also consid=
er whether some functions should be realised in hardware or software, and th=
e resulting impact on system performance and power consumption.
>>>=20
>>> - the information being protected is of low value. I do not consider thi=
s condition to be met; on the contrary, the signalling traffic in AODVv2 is o=
f high value to a potential attacker.
>>>=20
>>> - the scale of each deployment is limited. I consider that this is an un=
known, but I also consider that we should engineer for larger networks with e=
phemeral connections rather than smaller ones.
>>>=20
>>> Discussion welcome.
>>>=20
>>> Regards
>>> John
>>>=20
>>>=20
>>>=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


From nobody Wed Apr 27 15:16: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 4A2AF12B048 for ; Wed, 27 Apr 2016 15:16:13 -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 FpYanWfLbtxi for ; Wed, 27 Apr 2016 15:16:11 -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 05BC812B03F for ; Wed, 27 Apr 2016 15:16:11 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id g17so12287135wme.1 for ; Wed, 27 Apr 2016 15:16:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=386UY2pxI9pA5mvYQ3+/KJaXD0oemUDAWrqee5X3znU=; b=ODnU3jP6igi6R8Iv5Hujw32lcFrA0nGhHIJBMn1dgByeqKTTQXt3wm7GWOaKjropgD GIcckHAPLUiunfmfMn57DjxGODhUbnQDhqCQ7jk1JVmeruRQw/+5GTo6+3FAwVrKLNrO 6YVDEAqn8eKrQ/nhncA60JlK7vlyxzPCJ53QV+vNXGkpU2CMGdjZvsxepHaL6lT3/miD 6QEgqweBZ/tBsTliwrSeiOwHPNwxeJKXLj3M75LwcLHbID+w5rbbIO//5EtEe5xiFCpd WV5b+FEU09GN53JBCMdqZEFjshC1+zKtZ9+hrFV7MVaW8k/ebENwbx6MMjFyEWDIcxMH sutg==
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 :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=386UY2pxI9pA5mvYQ3+/KJaXD0oemUDAWrqee5X3znU=; b=ClgNt/Zmcqb8u5KJgRMJQm/B5bI9azP7JO1ZMzms6NuoPqTTug4PZ7OZR2/qbOV8g/ Z0BG/icz5L7VIZaEXi3XAcW5tXZ2DSkE0CCydE26HPtmiwlFg+AyYd7uKs19RzHRNzRG P7ETyGAfEXuymiF/N4o8y+jhzXT+dsKoftbPZE6eTrmb/h/cybJC1poHTlXptX4Azifz qojPaVUb7+NVNt56o3PcvG8rnXH8KgDVOH063NIxCIFSVShnbz26B7zXIccxAk61BbPd YtetPpTn3DpNt+dcfMG3CxYvYAiZGsqht+FN1fqt6xNN6WrSdH7lT0PwwyipR+epGK/g Excg==
X-Gm-Message-State: AOPr4FUEEu4h5iKRxtMVD3ZgshLRvi4XfLMms4rwh+u0p5PEQw8yFmkVRG10UoKT6f2O0Q==
X-Received: by 10.194.133.135 with SMTP id pc7mr11792986wjb.49.1461795369581;  Wed, 27 Apr 2016 15:16:09 -0700 (PDT)
Received: from [10.4.56.45] (82-132-225-45.dab.02.net. [82.132.225.45]) by smtp.gmail.com with ESMTPSA id c4sm6213197wjm.24.2016.04.27.15.16.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 15:16:08 -0700 (PDT)
References: <937ABB81-CCD9-4FD0-A7CF-5114384B3B94@gmail.com>
In-Reply-To: <937ABB81-CCD9-4FD0-A7CF-5114384B3B94@gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Message-Id: <46C9AA5C-083A-4A1E-88FC-5F7AC67A5ECC@gmail.com>
X-Mailer: iPhone Mail (13E238)
From: Christopher Dearlove 
Date: Wed, 27 Apr 2016 23:16:04 +0100
To: John Dowdell 
Archived-At: 
Cc: manet@ietf.org
Subject: Re: [manet] AODVv2 security: Key Management to BCP107
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, 27 Apr 2016 22:16:13 -0000

I should have said that this might be an area to discuss in a rechartered pi=
ece of work on security/encryption. But unless there's something I definitel=
y missed, I don't think there's a worked out solution here.

-- =20
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)



-- =20
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)
> On 27 Apr 2016, at 21:10, John Dowdell  wrote=
:
>=20
> Hi all
>=20
> As an AODVv2 co-author I=E2=80=99d like to propose this position regarding=
 key management against BCP107, one of the artefacts we are being asked to s=
tate a position over. I=E2=80=99d also like to state that I=E2=80=99m open t=
o contributions from others knowledgeable on this topic or who have been thi=
s way previously.
>=20
> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka BCP107 i=
s the set of guidelines for choosing either automated or manual key manageme=
nt for cryptographic purposes. It=E2=80=99s not a long read and guides the r=
eader through a set of tests as to whether automated or manual key managemen=
t would be suitable for the application in hand.
>=20
> The very first question is does AODVv2 need key management at all? I would=
 contend that it does, since we require to secure the signalling traffic for=
 the routing algorithm. The aim here is therefore to purely assist in the se=
curity of the signalling traffic; security of user data that is forwarded on=
ce an AODVv2 route has been established is out of scope.
>=20
> Section 1 of BCP107 states that automated key management SHOULD be used. T=
hus my answer will be in favour of that unless I can contend otherwise.
>=20
> The guidelines in section 2 outline that automated key management derives s=
hort-term session keys between two parties. In the case of AODVv2, this woul=
d correspond to two routers that form or wish to form an adjacency.
>=20
> The guidelines state that the short-term keys may be derived from long-ter=
m keys, and that the dissemination of long term keys is out of scope of BCP1=
07. I would envisage that an AODVv2 router, given that it would form ephemer=
al ad hoc networks with other routers as it went about its business, would b=
e supplied with one or more long term keys for a period of time, to be deter=
mined by the system integrator, and that the long term keys would then be us=
ed to derive short term keys which are used in the forming of adjacencies pl=
ural.
>=20
> Section 2.1 of BCP107 describes the conditions under which automated key m=
anagement MUST be used.
>=20
> - If a large number of static keys would have to be managed. It is not kno=
wn how many routers could be deployed, but if this is aimed at ad hoc applic=
ations then the number of routers could quickly become large. I consider thi=
s condition is met.
>=20
> - Any stream cipher is used. This is a choice for the system integrator, b=
ut an AES based cipher is a real possibility. There is more likelihood this c=
ondition is met than not met.
>=20
> - An initialisation vector (IV) might be re-used. I am open to advice on t=
his point.
>=20
> - Large amounts of data need to be encrypted in a short time. Even if ther=
e is no specific guidance on =E2=80=98large=E2=80=99, I do not consider this=
 condition to be met, since signalling messages are likely to be short relat=
ive to the user data that could be exchanged.
>=20
> - Long-term session keys are used by more than two parties, including mult=
icast applications. AODVv2 uses multicast extensively, and therefore I consi=
der this condition to be met.
>=20
> - Device turnover is frequent. This is a certainty in ad hoc networks, so I=
 consider this condition to be met.
>=20
> I believe the outcomes from section 2.1 guidance is more in favour of auto=
mated key management.
>=20
> However, to consider the guidance on manual key management in section 2.2 o=
f BCP107, where such management may be reasonable:
>=20
> - the environment has very limited bandwidth or high round trip times. Som=
e applications for AODVv2 may use very low bandwidths, perhaps for low-power=
 sensor networks. The point is made that "public key systems require long ex=
changes and lots of computation=E2=80=9D. The AODVv2 author team believe tha=
t very low power hardware might be used by some implementors, which may give=
 problems when being required to use public key exchanges. Such implementors=
 need to carefully consider the tradeoff between the need for security and t=
he need for very low power consumption. Such implementors should also consid=
er whether some functions should be realised in hardware or software, and th=
e resulting impact on system performance and power consumption.
>=20
> - the information being protected is of low value. I do not consider this c=
ondition to be met; on the contrary, the signalling traffic in AODVv2 is of h=
igh value to a potential attacker.
>=20
> - the scale of each deployment is limited. I consider that this is an unkn=
own, but I also consider that we should engineer for larger networks with ep=
hemeral connections rather than smaller ones.
>=20
> Discussion welcome.
>=20
> Regards
> John
>=20
>=20
>=20
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From nobody Wed Apr 27 15:16: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 E068412D8EE for ; Wed, 27 Apr 2016 15:16:32 -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 ir2uC8-kpQwg for ; Wed, 27 Apr 2016 15:16:30 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 A72D112D986 for ; Wed, 27 Apr 2016 15:16:23 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id a17so36201845wme.0 for ; Wed, 27 Apr 2016 15:16:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=QYnFDnf+GZzOouVhsr/pKVNK+TIsqOb/r0ZZlbfVlbo=; b=WSPiqCRSD9aXg7aA788nPB0g62yJlLAwwajeICbh6CclO/PjLwbFELCGbB4uI/Didf 2SCef+qZQQ9J3yr9t9Ak2sTd1MrdQNK2Z42SE93L8dARsyJkz6N2N6rddpSY5by/14XG 8U6JF4io6GhldSlh9GYLC6yB2yem2Tq43/vZFdHiQXnqrf/PxlIYcIdVySaT+iJwGVuf 1KjeyeFGYo9t0NoNLkSotJelY5CSyoVro5qbgoFx+m81FMe4Ankde8qodNEi613ugyFc fUfDXHNqKd6xl2sZd/VXTELo9T2BEQ4w/pB1B7M2CDpnwdVaYlMg/MKOerh+IQIN/MhO 92mQ==
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 :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=QYnFDnf+GZzOouVhsr/pKVNK+TIsqOb/r0ZZlbfVlbo=; b=FklG2Y4x0DznaQWucHNwtGCvjrGVvaxxpQ3cI0aJNfzjxQJNagw3EKPLRdv60POCbG ZcSu7PFUG/QqfW4+M4AP0F2D/Y8TIHa4PHa0jiA9m8E31cVk9htw/gXbKy/JXcsFGamU Qx/aYQOa8xzo9G1z6/wwDR6/o349Ho72XIOY+ziu88fYWRXt90q3xa5m4q4OGPRjrxzE P5/fifVOsNyYUWDrWbzmxpXIz6dMM1/N406iHU6SdefpHTCbayl6dr2gD4hIFrvceT1y OWQiVvuDcjudiF35Elsm28FU6fzZqan43Fy7vqPQU33dAc5+6oSxaFeTTkdwxCFCaIEy 1SiQ==
X-Gm-Message-State: AOPr4FUnRu2VMrEK//OPQqAMNi1bKBn871DXuIosnxKAGjjMG5WGyyiqJHW1Yd7R+tqlIQ==
X-Received: by 10.28.141.141 with SMTP id p135mr26158718wmd.8.1461795382221; Wed, 27 Apr 2016 15:16:22 -0700 (PDT)
Received: from [10.4.56.45] (82-132-225-45.dab.02.net. [82.132.225.45]) by smtp.gmail.com with ESMTPSA id i194sm31459018wmf.6.2016.04.27.15.16.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 15:16:21 -0700 (PDT)
References: <937ABB81-CCD9-4FD0-A7CF-5114384B3B94@gmail.com>
In-Reply-To: <937ABB81-CCD9-4FD0-A7CF-5114384B3B94@gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Message-Id: <4A4BA15A-11F7-4DF0-A13F-7DF3CE711C7F@gmail.com>
X-Mailer: iPhone Mail (13E238)
From: Christopher Dearlove 
Date: Wed, 27 Apr 2016 23:16:17 +0100
To: John Dowdell 
Archived-At: 
Cc: manet@ietf.org
Subject: Re: [manet] AODVv2 security: Key Management to BCP107
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, 27 Apr 2016 22:16:33 -0000

I really don't know what you are proposing. I think you have a great big can=
 of worms here that hasn't been thought through.

So AODVv2 is sending, as it's very first message, an RREQ. We want to authen=
ticate this. How? You can't negotiate a key, you haven't got a route. You do=
n't know who your neighbours are. You plan to multicast to them in fact, wha=
t's your key plan for that?

If you say use long term key, what are you actually going to use the short t=
erm key for? And if you plan to exchange message with your neighbours, that r=
ather preempts a significant part of your protocol (why establish bidirectio=
nality when your key negotiation must have done that?)

And then we've spent some time discussing end to end authentication. That do=
esn't work with short term keys for adjacencies only.

We (OLSRv2) went through, more than once, a hard argument why automated key m=
anagement wasn't appropriate here, and why the exceptions did apply.

But in a nutshell (though this wasn't the argument we used, just why we need=
ed it) how can you agree a key without communicating? How do you communicate=
 more than one hop without a route? How do you authenticate the messages to c=
reate that route without a key?

Something has to give. And in giving you might end up redesigning your whole=
 protocol. Or using something quite clever that there's no hint of here. Or u=
sing the simplest fallback of a single shared key (our 7183 default) which i=
sn't automatically managed.

--=20
Christopher Dearlove



-- =20
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)
> On 27 Apr 2016, at 21:10, John Dowdell  wrote=
:
>=20
> Hi all
>=20
> As an AODVv2 co-author I=E2=80=99d like to propose this position regarding=
 key management against BCP107, one of the artefacts we are being asked to s=
tate a position over. I=E2=80=99d also like to state that I=E2=80=99m open t=
o contributions from others knowledgeable on this topic or who have been thi=
s way previously.
>=20
> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka BCP107 i=
s the set of guidelines for choosing either automated or manual key manageme=
nt for cryptographic purposes. It=E2=80=99s not a long read and guides the r=
eader through a set of tests as to whether automated or manual key managemen=
t would be suitable for the application in hand.
>=20
> The very first question is does AODVv2 need key management at all? I would=
 contend that it does, since we require to secure the signalling traffic for=
 the routing algorithm. The aim here is therefore to purely assist in the se=
curity of the signalling traffic; security of user data that is forwarded on=
ce an AODVv2 route has been established is out of scope.
>=20
> Section 1 of BCP107 states that automated key management SHOULD be used. T=
hus my answer will be in favour of that unless I can contend otherwise.
>=20
> The guidelines in section 2 outline that automated key management derives s=
hort-term session keys between two parties. In the case of AODVv2, this woul=
d correspond to two routers that form or wish to form an adjacency.
>=20
> The guidelines state that the short-term keys may be derived from long-ter=
m keys, and that the dissemination of long term keys is out of scope of BCP1=
07. I would envisage that an AODVv2 router, given that it would form ephemer=
al ad hoc networks with other routers as it went about its business, would b=
e supplied with one or more long term keys for a period of time, to be deter=
mined by the system integrator, and that the long term keys would then be us=
ed to derive short term keys which are used in the forming of adjacencies pl=
ural.
>=20
> Section 2.1 of BCP107 describes the conditions under which automated key m=
anagement MUST be used.
>=20
> - If a large number of static keys would have to be managed. It is not kno=
wn how many routers could be deployed, but if this is aimed at ad hoc applic=
ations then the number of routers could quickly become large. I consider thi=
s condition is met.
>=20
> - Any stream cipher is used. This is a choice for the system integrator, b=
ut an AES based cipher is a real possibility. There is more likelihood this c=
ondition is met than not met.
>=20
> - An initialisation vector (IV) might be re-used. I am open to advice on t=
his point.
>=20
> - Large amounts of data need to be encrypted in a short time. Even if ther=
e is no specific guidance on =E2=80=98large=E2=80=99, I do not consider this=
 condition to be met, since signalling messages are likely to be short relat=
ive to the user data that could be exchanged.
>=20
> - Long-term session keys are used by more than two parties, including mult=
icast applications. AODVv2 uses multicast extensively, and therefore I consi=
der this condition to be met.
>=20
> - Device turnover is frequent. This is a certainty in ad hoc networks, so I=
 consider this condition to be met.
>=20
> I believe the outcomes from section 2.1 guidance is more in favour of auto=
mated key management.
>=20
> However, to consider the guidance on manual key management in section 2.2 o=
f BCP107, where such management may be reasonable:
>=20
> - the environment has very limited bandwidth or high round trip times. Som=
e applications for AODVv2 may use very low bandwidths, perhaps for low-power=
 sensor networks. The point is made that "public key systems require long ex=
changes and lots of computation=E2=80=9D. The AODVv2 author team believe tha=
t very low power hardware might be used by some implementors, which may give=
 problems when being required to use public key exchanges. Such implementors=
 need to carefully consider the tradeoff between the need for security and t=
he need for very low power consumption. Such implementors should also consid=
er whether some functions should be realised in hardware or software, and th=
e resulting impact on system performance and power consumption.
>=20
> - the information being protected is of low value. I do not consider this c=
ondition to be met; on the contrary, the signalling traffic in AODVv2 is of h=
igh value to a potential attacker.
>=20
> - the scale of each deployment is limited. I consider that this is an unkn=
own, but I also consider that we should engineer for larger networks with ep=
hemeral connections rather than smaller ones.
>=20
> Discussion welcome.
>=20
> Regards
> John
>=20
>=20
>=20
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From nobody Wed Apr 27 15:16:54 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 9E97312D56C for ; Wed, 27 Apr 2016 15:16:52 -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 LYUtlnFhEA3u for ; Wed, 27 Apr 2016 15:16:48 -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 1BD3C12D963 for ; Wed, 27 Apr 2016 15:16:39 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id a17so36208884wme.0 for ; Wed, 27 Apr 2016 15:16:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=m7IJTMnnJkoPTUkyDnj0FUSbxMfqSKF6eb/v8bygtEY=; b=D4GdAMxnn2cFuFGGjmGCHo6OdwGt/nti1faVrW8Uo+tt1PxN70Z/qJ42l4x0N2nTyu c0AnK6ws+vm9aHk2EJVEt3x2f2zWUQTM4ROdk2jEKo/Oeag3fIrgd55GsJDxlr24ciVl hcK3ZNcXorcJEFiQ/ZQzqQjGUkWDWxWBhnK0dai0kT+PF/D4W2AyugqHINi3pQQhpG7m j0C1YR+PE0AeKMhyYse35kd37FcUf5fX1+aQTOQy9o1M68vqAy9uo6lyr/5rekVabZ/z WTBaoL0IHIt7LunvRRo+tcHRJh9jY0Vc0VD+b0mWgUw9YBdru/RWkwyBoRrtz+4wcIbp gVtA==
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 :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=m7IJTMnnJkoPTUkyDnj0FUSbxMfqSKF6eb/v8bygtEY=; b=C2hNLr0lMoRG9FhTqALMT2nDOnveiOSiwW1S6y6+NDx4oevR8gKCYAu7chTnmU/gk1 acuGhGYOYhnmOP1kXw1LfJ0CzM362X5Ud0BGYj9oVc1dEDcIbhS8KH3itLRRPpK35dim EPPMZwYRVzULk5VsnNQZUpwYJzScdVM+y1KE8ThW5uH8hw45dDduVm5p0e+wtLCF3EUI SQZU9heJk6kNnUmofLotgKjOJwOM7yHfcZgOzDVrU6tvcmltkrKHTfkylKSwqsf5sV83 nEIxl/gexTnvNOnhUJw+9s+ZI2A39DrfgCBZgoYCJ/g5IUxv0amcrwhViSLSlZS6SCUv /tXg==
X-Gm-Message-State: AOPr4FVdUO0ZQlaPWNq5yZ8Xy3rELmR/B+bDuwq0JowE5W6vI4OYwdsUzY2cBimghqz9qg==
X-Received: by 10.194.14.6 with SMTP id l6mr13254358wjc.48.1461795397588; Wed, 27 Apr 2016 15:16:37 -0700 (PDT)
Received: from [10.4.56.45] (82-132-225-45.dab.02.net. [82.132.225.45]) by smtp.gmail.com with ESMTPSA id on2sm6197339wjc.32.2016.04.27.15.16.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 15:16:36 -0700 (PDT)
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org>     
In-Reply-To: 
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary=Apple-Mail-A42F52A8-7015-4AC6-A9B8-2806091A100F
Message-Id: <60BD2E9C-64D7-4444-B3A9-8D207EB4A86F@gmail.com>
X-Mailer: iPhone Mail (13E238)
From: Christopher Dearlove 
Date: Wed, 27 Apr 2016 23:16:32 +0100
To: Lotte Steenbrink 
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 27 Apr 2016 22:16:52 -0000

--Apple-Mail-A42F52A8-7015-4AC6-A9B8-2806091A100F
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

The more you have to zero out, the messier it gets, and the less secure it g=
ets (more things can be spoofed). I think that's about all I've got to add.

--=20
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)



-- =20
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)
> On 27 Apr 2016, at 22:46, Lotte Steenbrink =
 wrote:
>=20
> Hi all,
> I=E2=80=99m currently revising the security considerations with regards to=
 the move from regeneration to forwarding, which depends on a decision being=
 made on how/where we want to mention the possibility of zeroing out TLVs to=
 calculate the ICV for the rest of a message=E2=80=99s contents (see second *=
 of my last e-mail). I=E2=80=99ve not found a decision on this in other thre=
ad (please pardon me if I overlooked something), so I=E2=80=99ll bump this t=
hread and ask the WG for its opinions. (again, personally, the 2nd option ou=
tlined by Christopher seems more appealing to me)
>=20
> Regards,
> Lotte
>=20
>> Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink :
>>=20
>> Hi all,
>> to summarize:
>>=20
>> * AODVv2 message Type numbers should be in the Experimental type space an=
d the AODVv2 TLV Types should be message type-specific. This also means chan=
ging the text regarding IANA actions and changing the text regarding what th=
e experiment is to something along the lines of =E2=80=9Cwe want to gather e=
xperience on how to make generic metric TLVs and ICVs that work with changin=
g metric TV values happen with reactive protocols=E2=80=9D
>> * we=E2=80=99re undecided on (to quote Christopher) the "here's a mechani=
sm we haven't really thought through in detail, but at least we've defined o=
ne", or "we know the sort of thing we want, and we'll describe it, but rathe=
r than produce something not quite right, we'll not go further=E2=80=9C deci=
sion on temporarily setting the metric value to 0 (i.e. the who and how). (p=
ersonally, I think I=E2=80=99d prefer the latter approach, but that=E2=80=99=
s an entirely gut feeling-based preference)
>>=20
>> Did I catch that correctly? If so, I=E2=80=99ll put together and suggest s=
ome text for the first point as soon as I get home and in case there has bee=
n a decision on the second by then, I=E2=80=99ll try to tackle that one too.=
 :)
>>=20
>> Best regards, Lotte
>>=20
>>> Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) :
>>>=20
>>> I have no problem with that. I was trying to lay out the issues without m=
uddying the water with my preference.
>>> =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
>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>>>=20
>>> =20
>>> From: Justin Dean [mailto:bebemaster@gmail.com]=20
>>> Sent: 22 April 2016 15:35
>>> To: Dearlove, Christopher (UK)
>>> Cc: Thomas Heide Clausen; Mobile Ad Hoc Networks mailing list
>>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf=
-manet-aodvv2-13 review - a couple of big ticket Items)
>>> =20
>>> =20
>>> *** WARNING ***
>>> 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
>>> Speaking as participant.
>>>=20
>>> I kind of like the idea of using the experimental message type space.  W=
e only have a limited amount of these message types.  The TLV assignments co=
uld just use the message type specific space and there isn't an issue there.=
  IANA wouldn't assign a number but I don't see why the document couldn't sp=
ecify the experimental numbers it was going to use so other future near term=
 experiential protocols could do the same and generally avoid conflict.  If t=
he experiment is successful IANA assignments could be made.  Functionally no=
 real difference with protections vs long term usage of limited space.
>>> =20
>>> Justin
>>> =20
>>> On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK)  wrote:
>>> There's rather a contradiction between the concepts of a definition of a=
 protocol, even Experimental, and experimental space, which usually assumes t=
hat the user can do what he or she likes in it.
>>>=20
>>> But chewing up messages types (how many, 3?) of which there are relative=
ly few for experimental is long term a problem, although short term not.
>>>=20
>>> TLV space is easier in two regards. It's bigger (though the prime real e=
state of type extension zero isn't) and can have message type specific TLVs.=

>>>=20
>>> So TLVS can actually be invisible, if that option is chosen. For message=
s something has to give. Least bad option is again one of those we should di=
scuss, but time ...
>>>=20
>>> (To be precise, messages types from 224 are defined in RFC 5444 as " Exp=
erimental Use", of which BCP 26 says "Similar to private or local use only, w=
ith the  purpose being to facilitate experimentation." The alternative 0-223=
 space is Expert Review. IANA still thinks the experts are Joe Macker and th=
e recused Stan Ratliff. But that's a soluble nit.)
>>>=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
>>>=20
>>> -----Original Message-----
>>> From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org]
>>> Sent: 22 April 2016 14:21
>>> To: Dearlove, Christopher (UK)
>>> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf=
-manet-aodvv2-13 review - a couple of big ticket Items)
>>>=20
>>> ----------------------! WARNING ! ---------------------- This message or=
iginates from outside our organisation, either from an external partner or f=
rom the internet.
>>> Consider carefully whether you should click on any links, open any attac=
hments or reply.
>>> Follow the 'Report Suspicious Emails' link on IT matters for instruction=
s on reporting suspicious email messages.
>>> --------------------------------------------------------
>>>=20
>>>=20
>>> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK)  wrote:
>>> >
>>> > Once you're entirely in AODV2's own space, and AODVv2 is experimental (=
working assumption for this discussion) you have more liberty.
>>> >
>>>=20
>>> Yep.
>>>=20
>>> Taken somewhat by surprise both by the sudden "rush" and the experimenta=
l maturity level, I am wondering (and haven't thought through) about experim=
ental space vs non-experimental (for message types, and consequently for mes=
sage type specific TLV types).
>>>=20
>>> I think that if the AODVv2 experiment specifies the use of Message types=
 from the Experimental message type space without making actual registration=
s in the IANA registry, AND the use of type specific TLV types, this becomes=
 a non-issue entirely (by design, this is precisely what that experimental s=
pace is for)
>>>=20
>>> Whereas, as you point out, the alternative is a "can open - worms everyw=
here" situation that I think time is too short to solve?
>>>=20
>>> Thomas
>>>=20
>>>=20
>>> > Then you could try specifying it. But with a very good chance of produ=
cing something you later decide you should have done differently.
>>> >
>>> > I honestly don't know which would go down better (or less badly) - "he=
re's a mechanism we haven't really thought through in detail, but at least w=
e've defined one", or "we know the sort of thing we want, and we'll describe=
 it, but rather than produce something not quite right, we'll not go further=
".
>>> >
>>> > --
>>> > 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 Ba=
ddow, 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: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]
>>> > Sent: 22 April 2016 13:59
>>> > To: Mobile Ad Hoc Networks mailing list
>>> > Cc: Henning Rogge; Dearlove, Christopher (UK)
>>> > Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ie=
tf-manet-aodvv2-13 review - a couple of big ticket Items)
>>> >
>>> > ----------------------! WARNING ! ---------------------- This message o=
riginates from outside our organisation, either from an external partner or f=
rom the internet.
>>> > Consider carefully whether you should click on any links, open any att=
achments or reply.
>>> > Follow the 'Report Suspicious Emails' link on IT matters for instructi=
ons on reporting suspicious email messages.
>>> > --------------------------------------------------------
>>> >
>>> > Hello Christopher,
>>> >
>>> >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) :
>>> >>
>>> >> Just be careful to note that this concept is as currently being discu=
ssed (a) specific to AODVv2, and (b) not an application of 7182, which has n=
o knowledge of special TLVs.
>>> >>
>>> >> This is something we'd want to get right, and need to get right if in=
 any space not specific to ADODVv2, because getting it wrong produces future=
 problems.
>>> >
>>> > Makes sense.
>>> >
>>> >> I can see some possible approaches, none is ideal and we're rather ou=
t
>>> >> of time to specify. But this is experimental, so I think we might be
>>> >> able to indicate the shape of the solution without specifying it,
>>> >> which would be a different RFC, under a bit less time pressure.
>>> >> (Extensions to existing protocols like 7182 would naturally be in
>>> >> scope rechartered I think.)
>>> >>
>>> >> To indicate the range that's open, here are two possible ideas, one o=
f which has an impact now, so needs to be agreed. Note that I'm not suggesti=
ng (in fact quite the opposite) defining an extension to 7182 here, rather e=
nabling such an extension, if written, to "do the right thing".
>>> >> - We have an extension to 7182 that says "zero out all value octets i=
n protocol specific TLVs. That requires now putting the AODVv2 metric TLV in=
 that space.
>>> >
>>> > Just to make sure that I understood you correctly=E2=80=93 =E2=80=9Cth=
at space=E2=80=9D meaning making the AODVv2 metric TLV protocol specific? (B=
y =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m referring to the gener=
ic TLV we=E2=80=99ve been talking about on this list earlier this week).
>>> >
>>> >> - We have an extension to 7182 that adds extra material to the value f=
ield that indicates (TBD how, by position with sanity check that this is TLV=
 value perhaps?) which octets are to be zeroed out before the ICV is calcula=
ted.
>>> >
>>> > The way I understand that approach, it wouldn=E2=80=99t warrant any ac=
tion from AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set the M=
etric value to zero=E2=80=9D (leaving the nitty gritty of how this would be d=
one in detail to future work)=E2=80=A6 Is that correct?
>>> >
>>> >>
>>> >> We do not have the time to specify this in an acceptable manner withi=
n two weeks though. But the security consideration section could say somethi=
ng along the lines of "this enables the use of an ICV defined to zero out th=
ese octets=E2=80=9C.
>>> >
>>> > Okay. :)
>>> >
>>> > Best regards,
>>> > Lotte
>>> >
>>> >>
>>> >> --
>>> >> 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 B=
addow, Chelmsford, Essex CM2 8HN.
>>> >> www.baesystems.com/ai
>>> >> BAE Systems Applied Intelligence Limited Registered in England & Wale=
s
>>> >> No: 01337451 Registered Office: Surrey Research Park, Guildford,
>>> >> Surrey, GU2 7YP
>>> >>
>>> >> -----Original Message-----
>>> >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte
>>> >> Steenbrink
>>> >> Sent: 22 April 2016 10:28
>>> >> To: Henning Rogge
>>> >> Cc: Mobile Ad Hoc Networks mailing list
>>> >> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>>> >> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>> >>
>>> >> ----------------------! WARNING ! ---------------------- This message=
 originates from outside our organisation, either from an external partner o=
r from the internet.
>>> >> Consider carefully whether you should click on any links, open any at=
tachments or reply.
>>> >> Follow the 'Report Suspicious Emails' link on IT matters for instruct=
ions on reporting suspicious email messages.
>>> >> --------------------------------------------------------
>>> >>
>>> >> *** WARNING ***
>>> >> EXTERNAL EMAIL -- This message originates from outside our organizati=
on.
>>> >>
>>> >>
>>> >> Hi Henning,
>>> >>
>>> >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge :
>>> >>>
>>> >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>>> >>>  wrote:
>>> >>>> Hi Thomas,
>>> >>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=E2=
=80=9D language
>>> >>>> in the first place is that we=E2=80=99ve been told that whenever on=
e bit in
>>> >>>> the message (apart from its header) is changed, the entire thing ha=
s to be regenerated.
>>> >>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been mis=
understanding
>>> >>>> each other for more than a year. :( Anyway, it seems like we=E2=80=99=
re
>>> >>>> getting close now, so yay.
>>> >>>
>>> >>> "Modifying" the binary message instead of parsing and generating a
>>> >>> new one will be difficult as soon someone writes an extension to
>>> >>> AODVv2 that adds more TLVs to the message.
>>> >>
>>> >> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s=
 what you explained to me when I got confused about the topic last spring=E2=
=80=A6 But=E2=80=93 even if a message contains TLVs that the AODVv2 implemen=
tation handling it doesn=E2=80=99t understand, it will still be able to reco=
gnize the Metric TLV, right? Isn=E2=80=99t that the nifty thing about RFC544=
4? So, while we really shouldn=E2=80=99t write =E2=80=9Cbefore calculating t=
he ICV, set the n-th 4 octets to 0=E2=80=9D, we might say =E2=80=9Cidentify t=
he octets that make up the metric value and set those to 0=E2=80=9D?
>>> >>
>>> >> Best regards,
>>> >> Lotte
>>> >>
>>> >>> Henning Rogge
>>> >>
>>> >> _______________________________________________
>>> >> 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
>>>=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
>> _______________________________________________
>> 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-A42F52A8-7015-4AC6-A9B8-2806091A100F
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


The more you=
 have to zero out, the messier it gets, and the less secure it gets (more th=
ings can be spoofed). I think that's about all I've got to add.

--&nb=
sp;
Christopher Dearlove



--  
Christopher Dearlove
christopher.dearlove@gma=
il.com (iPhone)
On 27 Apr 2016, at 22:46,=
 Lotte Steenbrink <lotte=
.steenbrink@fu-berlin.de> wrote:


Hi a=
ll,
I=E2=80=99m currently revising the security consideration=
s with regards to the move from regeneration to forwarding, which depends on=
 a decision being made on how/where we want to mention the possibility of ze=
roing out TLVs to calculate the ICV for the rest of a message=E2=80=99s cont=
ents (see second * of my last e-mail). I=E2=80=99ve not found a decision on t=
his in other thread (please pardon me if I overlooked something), so I=E2=80=
=99ll bump this thread and ask the WG for its opinions. (again, personally, t=
he 2nd option outlined by Christopher seems more appealing to me)

Regards,
Lotte

Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink <=
;lotte.steenbrin=
k@fu-berlin.de>:

Hi all,
to sum=
marize:

* AODVv2 m=
essage Type numbers should be in the Experimental type space and the AODVv2 T=
LV Types should be message type-specific. This also means changing the text r=
egarding IANA actions and changing the text regarding what the experiment is=
 to something along the lines of =E2=80=9Cwe want to gather experience on ho=
w to make generic metric TLVs and ICVs that work with changing metric TV val=
ues happen with reactive protocols=E2=80=9D
* we=E2=80=99=
re undecided on (to quote Christopher) the "here's a mechanism we haven't re=
ally thought through in detail, but at least we've defined one", or "we know=
 the sort of thing we want, and we'll describe it, but rather than produce s=
omething not quite right, we'll not go further=E2=80=9C decision on temporar=
ily setting the metric value to 0 (i.e. the who and how). (personally, I thi=
nk I=E2=80=99d prefer the latter approach, but that=E2=80=99s an entirely gu=
t feeling-based preference)

Did I catch that correctly? If so, I=E2=80=99ll put together and s=
uggest some text for the first point as soon as I get home and in case there=
 has been a decision on the second by then, I=E2=80=99ll try to tackle that o=
ne too. :)

Best re=
gards, Lotte

Am 22.04.2016 um 16:41 schri=
eb Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>:

I have no pr=
oblem with that. I was trying to lay out the issues without muddying the wat=
er with my preference.
 <=
/div>
--
=
Christopher Dearlove
Se=
nior Principal Engineer
BAE Systems Applied Intelligence Labor=
atories
__=
________________________________________________________________________

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

BAE Systems Applied Intelligence, Chelmsf=
ord Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
=
www.baesystems.com/ai
BAE Systems Applied Intel=
ligence Limited
Registered in England & Wales No: 01337451=

Registered Office: Surrey Research Park, Guildford, Surrey,=
 GU2 7YP
 
From: Justin Dean [mailto:bebemaster@gmail.com] 
Sent: 22 April 2016 15:35
To: Dearlove,=
 Christopher (UK)
Cc: Thomas Heide Clausen; Mobile Ad Hoc Networks mai=
ling list
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re=
: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
&n=
bsp;
 
*** WARNING ***
This mes=
sage originates from outside our organisation, either from an external partn=
er or the internet.
Consider carefully whether you should click on any links, open any a=
ttachments 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 su=
spicious, please follow this process.
Speaking as participant.

I kind of like the idea of using the experimental me=
ssage type space.  We only have a limited amount of these message types=
.  The TLV assignments could just use the message type specific space a=
nd there isn't an issue there.  IANA wouldn't assign a number but I don=
't see why the document couldn't specify the experimental numbers it was goi=
ng to use so other future near term experiential protocols could do the same=
 and generally avoid conflict.  If the experiment is successful IANA as=
signments could be made.  Functionally no real difference with protecti=
ons vs long term usage of limited space.
 
Justin
&n=
bsp;
On Fri, Apr 2=
2, 2016 at 9:35 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
There's rather a c=
ontradiction between the concepts of a definition of a protocol, even Experi=
mental, and experimental space, which usually assumes that the user can do w=
hat he or she likes in it.

But chewing up messa=
ges types (how many, 3?) of which there are relatively few for experimental i=
s long term a problem, although short term not.

TLV space is easier in two regards. It's bigger (though the prime real esta=
te of type extension zero isn't) and can have message type specific TLVs.
So TLVS can actually be invisible, if that option=
 is chosen. For messages something has to give. Least bad option is again on=
e of those we should discuss, but time ...

(To b=
e precise, messages types from 224 are defined in RFC 5444 as " Experimental=
 Use", of which BCP 26 says "Similar to private or local use only, with the&=
nbsp; purpose being to facilitate experimentation." The alternative 0-223 sp=
ace is Expert Review. IANA still thinks the experts are Joe Macker and the r=
ecused Stan Ratliff. But that's a soluble nit.)

--
Christopher D=
earlove
Senior Principal Engineer
BAE Systems Applied Intelligence Labor=
atories
____________________________=
______________________________________________

T:  +44 (0)1=
245 242194  | &nb=
sp;E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Te=
chnology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesy=
stems.com/ai
BAE Systems Applied=
 Intelligence Limited
Registered in E=
ngland & Wales No: 01337451
Regi=
stered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP


-----Original Mess=
age-----
From: Thomas Heide Clausen [=
mailto:ietf@thomasclausen.org]
Sent: 22 April 2016 14:21
=
To: Dearlove, Christopher (UK)
Cc: L=
otte Steenbrink; Mobile Ad Hoc Networks mailing list
Subject: R=
e: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-=
13 review - a couple of big ticket Items)

-----=
-----------------! WARNING ! ---------------------- This message originates f=
rom outside our organisation, either from an external partner or from the in=
ternet.
Consider carefully whether you should click on any lin=
ks, open any attachments or reply.
Follow the 'Report Suspicio=
us Emails' link on IT matters for instructions on reporting suspicious email=
 messages.
---------------------------------------------------=
-----


> On 22 avr. 2016, at 1=
5:05, Dearlove, Christopher (UK) <ch=
ris.dearlove@baesystems.com> wrote:
>
=
> Once you're entirely in AODV2's own space, and AODVv2 is experimental (=
working assumption for this discussion) you have more liberty.
>

Yep.

Taken s=
omewhat by surprise both by the sudden "rush" and the experimental maturity l=
evel, I am wondering (and haven't thought through) about experimental space v=
s non-experimental (for message types, and consequently for message type spe=
cific TLV types).

I think that if the AODVv2 ex=
periment specifies the use of Message types from the Experimental message ty=
pe space without making actual registrations in the IANA registry, AND the u=
se of type specific TLV types, this becomes a non-issue entirely (by design,=
 this is precisely what that experimental space is for)

Whereas, as you point out, the alternative is a "can open - worms e=
verywhere" situation that I think time is too short to solve?
=

Thomas


> Then y=
ou could try specifying it. But with a very good chance of producing somethi=
ng you later decide you should have done differently.
>
> I honestly don't know which would go down better (or less bad=
ly) - "here's a mechanism we haven't really thought through in detail, but a=
t least we've defined one", or "we know the sort of thing we want, and we'll=
 describe it, but rather than produce something not quite right, we'll not g=
o further".
>
> --
> Chri=
stopher 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 Par=
k, Great Baddow, Chelmsford, Essex CM2 8HN.
> www.baesystems.com/ai
> BAE Systems Applied Int=
elligence Limited
> Registered in England & Wales No: 0=
1337451
> Registered Office: Surrey Research Park, Guildfor=
d, Surrey, GU2 7YP
>
>
> -=
----Original Message-----
> From: Lotte Steenbrink [mailto:=
lotte.steenbrink@fu-berlin.de]
> Sent: 22 April 2016 13:59
> To: Mobile Ad Ho=
c Networks mailing list
> Cc: Henning Rogge; Dearlove, Chri=
stopher (UK)
> Subject: Re: [manet] On Forwarding-and-regen=
eration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket=
 Items)
>
> ----------------------! WARNIN=
G ! ---------------------- This message originates from outside our organisa=
tion, either from an external partner or from the internet.
&g=
t; Consider carefully whether you should click on any links, open any attach=
ments or reply.
> Follow the 'Report Suspicious Emails' lin=
k on IT matters for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> Hello Christopher,
>
>> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com&=
gt;:
>>
>> Just be careful to note t=
hat this concept is as currently being discussed (a) specific to AODVv2, and=
 (b) not an application of 7182, which has no knowledge of special TLVs.
>>
>> This is something we'd want to get=
 right, and need to get right if in any space not specific to ADODVv2, becau=
se getting it wrong produces future problems.
>
> Makes sense.
>
>> I can see som=
e possible approaches, none is ideal and we're rather out
>=
> of time to specify. But this is experimental, so I think we might be>> able to indicate the shape of the solution without spec=
ifying it,
>> which would be a different RFC, under a bi=
t less time pressure.
>> (Extensions to existing protoco=
ls like 7182 would naturally be in
>> scope rechartered I=
 think.)
>>
>> To indicate the range=
 that's open, here are two possible ideas, one of which has an impact now, s=
o needs to be agreed. Note that I'm not suggesting (in fact quite the opposi=
te) defining an extension to 7182 here, rather enabling such an extension, i=
f written, to "do the right thing".
>> - We have an exte=
nsion to 7182 that says "zero out all value octets in protocol specific TLVs=
. That requires now putting the AODVv2 metric TLV in that space.
>
> Just to make sure that I understood you correctly=
=E2=80=93 =E2=80=9Cthat space=E2=80=9D meaning making the AODVv2 metric TLV p=
rotocol specific? (By =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m re=
ferring to the generic TLV we=E2=80=99ve been talking about on this list ear=
lier this week).
>
>> - We have an exte=
nsion to 7182 that adds extra material to the value field that indicates (TB=
D how, by position with sanity check that this is TLV value perhaps?) which o=
ctets are to be zeroed out before the ICV is calculated.
><=
br class=3D"">> The way I understand that approach, it wouldn=E2=80=99t w=
arrant any action from AODVv2 besides saying =E2=80=9Cif you calculate the I=
CV, set the Metric value to zero=E2=80=9D (leaving the nitty gritty of how t=
his would be done in detail to future work)=E2=80=A6 Is that correct?
>
>>
>> We do not have th=
e time to specify this in an acceptable manner within two weeks though. But t=
he security consideration section could say something along the lines of "th=
is enables the use of an ICV defined to zero out these octets=E2=80=9C.
>
> Okay. :)
>
=
> Best regards,
> Lotte
>
>>
>> --
>> Christopher Dearl=
ove
>> Senior Principal Engineer
>> B=
AE Systems Applied Intelligence Laboratories
>> ________=
______________________________________________________________
>> ____
>>
>> T:  +44 (0=
)1245 242194  |  E: chris.dearlove@baesystems.com>>
>> BAE Systems Applied Intelligenc=
e, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
>> www.baesystems.com/ai
>> BAE Systems Applied Intelligence Limited Registered in England &=
amp; Wales
>> No: 01337451 Registered Office: Surrey Res=
earch Park, Guildford,
>> Surrey, GU2 7YP
=
>>
>> -----Original Message-----
>=
;> From: manet [mailto:manet-bounces@ietf.o=
rg] On Behalf Of Lotte
>> Steenbrink
&=
gt;> Sent: 22 April 2016 10:28
>> To: Henning Rogge>> Cc: Mobile Ad Hoc Networks mailing list
=
>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket=
 Items)
>>
>> ----------------------=
! WARNING ! ---------------------- This message originates from outside our o=
rganisation, either from an external partner or from the internet.
>> Consider carefully whether you should click on any links, open a=
ny attachments or reply.
>> Follow the 'Report Suspiciou=
s Emails' link on IT matters for instructions on reporting suspicious email m=
essages.
>> --------------------------------------------=
------------
>>
>> *** WARNING ***>> EXTERNAL EMAIL -- This message originates from outside=
 our organization.
>>
>>
>> Hi Henning,
>>
>>> Am=
 22.04.2016 um 11:08 schrieb Henning Rogge <hrogg=
e@gmail.com>:
>>>
>>> O=
n Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>>>=
 <lotte.steenbrink@fu-berlin.de&=
gt; wrote:
>>>> Hi Thomas,
>>&=
gt;> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=E2=
=80=9D language
>>>> in the first place is that we=
=E2=80=99ve been told that whenever one bit in
>>>>=
; the message (apart from its header) is changed, the entire thing has to be=
 regenerated.
>>>> I=E2=80=99m starting to get the=
 feeling we=E2=80=99ve just been misunderstanding
>>>=
> each other for more than a year. :( Anyway, it seems like we=E2=80=99re=

>>>> getting close now, so yay.
>=
;>>
>>> "Modifying" the binary message instead o=
f parsing and generating a
>>> new one will be diffic=
ult as soon someone writes an extension to
>>> AODVv2=
 that adds more TLVs to the message.
>>
&g=
t;> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s=
 what you explained to me when I got confused about the topic last spring=E2=
=80=A6 But=E2=80=93 even if a message contains TLVs that the AODVv2 implemen=
tation handling it doesn=E2=80=99t understand, it will still be able to reco=
gnize the Metric TLV, right? Isn=E2=80=99t that the nifty thing about RFC544=
4? So, while we really shouldn=E2=80=99t write =E2=80=9Cbefore calculating t=
he ICV, set the n-th 4 octets to 0=E2=80=9D, we might say =E2=80=9Cidentify t=
he octets that make up the metric value and set those to 0=E2=80=9D?
>>
>> Best regards,
>> L=
otte
>>
>>> Henning Rogge
>>
>> _____________________________________=
__________
>> manet mailing list
>><=
span class=3D"Apple-converted-space"> mane=
t@ietf.org
>>&=
nbsp;htt=
ps://www.ietf.org/mailman/listinfo/manet
>> ********=
************************************************************
&=
gt;> This email and any attachments are confidential to the intended
>> recipient and may also be privileged. If you are not the i=
ntended
>> recipient please delete it from your system a=
nd notify the sender.
>> You should not copy it or use i=
t for any purpose nor disclose or
>> distribute its cont=
ents to any other person.
>> ***************************=
*****************************************
>
&=
gt; _______________________________________________
> manet=
 mailing list
> =
manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________<=
br class=3D"">manet mailing list
manet@i=
etf.org
https://www.ietf.org/mailman/listinfo/manet<=
/o:p>
 
_______________________________________________manet mailing list<=
/span>
manet@ietf.org
https://www.ietf.org/mailman/listinfo/man=
et

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

_____=
__________________________________________
manet mailing lis=
t
manet@ietf.org
https://w=
ww.ietf.org/mailman/listinfo/manet
=

--Apple-Mail-A42F52A8-7015-4AC6-A9B8-2806091A100F--


From nobody Wed Apr 27 15:18:32 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 CD9A612D0F1 for ; Wed, 27 Apr 2016 15:18:30 -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 3iIj9_kVSs7L for ; Wed, 27 Apr 2016 15:18:29 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 6FECF12D0CF for ; Wed, 27 Apr 2016 15:18:29 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id g17so12347678wme.1 for ; Wed, 27 Apr 2016 15:18:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:from:message-id:date:to:content-transfer-encoding :mime-version; bh=ufQ/PPjtIRUkGZGhOvjRV+fTaEDn2b+emKqNNJuRgzk=; b=pKhzbh1wchZg9gzomBjpzfcFTW3anNgzO5MCxrktzqlmlxJYlfpWSXgD5Z8qrPGZ/p /5B1VhS7ti25hLSM2of9fmemkz2DBQD4CnQ81iNvZUULS1LCOyjU5qYicAZvEwWUNP6E DMoEePPAS9og0OUlPiMWKhRNfWkceVluJ9cW1FF0t20xQV1C8Y86B3KUNEP4fEMLU6yJ osxhiIHv9jEp8dpAAtdzK8nWJCBAlMGu0GSjzwxB+E5fMEDBzcSH+XgW95Z7bz9G1RR1 KrfKcI5ZV5AuyyhEFaxyc8aq0AVFjkEWolHxujvPtzLFWD1FVQkR/p8CeSbuiuvIvlUO GsSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:from:message-id:date:to :content-transfer-encoding:mime-version; bh=ufQ/PPjtIRUkGZGhOvjRV+fTaEDn2b+emKqNNJuRgzk=; b=Itd9rdV0MNbY/6XGZvZ2M/2/r7cbaeqfbXr3BG2ZeNImrTjOmX7cUUAkT0IV75La9q wx8UERFXRlfLsha4InxG0ueMZbYEifLyFrXi5k00WBbpJ1txe5btFLYxR8juwTfoTkPN i4QBYnR0s4r7eMjH66q42dWAwTb5hwQWDXI6uRistlIVMFryCGudAQibb23AymHQKz5f 9z0gfS1REHhii23yNZFX/E6O7u9YLgfH7qdLmmSnLTGTi9bxD2ikxgG/Im3ddpf3jVKW q5AJ1Qk8f20VkeB0DmUfyQQyiE7Eos+P/tYQnxWovRhEp4V/7zmMuyr0acFbizdgDyPC 6S7A==
X-Gm-Message-State: AOPr4FWGDpvmqycYPGlc/yaR6TEw7xXhRFgWbm3OL7wU/L0g5nsVjcb5bcqj7cVtgwDG0w==
X-Received: by 10.194.246.3 with SMTP id xs3mr13116715wjc.66.1461795508049; Wed, 27 Apr 2016 15:18:28 -0700 (PDT)
Received: from [10.4.56.45] (82-132-225-45.dab.02.net. [82.132.225.45]) by smtp.gmail.com with ESMTPSA id q127sm10610402wmd.13.2016.04.27.15.18.27 for  (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 15:18:27 -0700 (PDT)
From: Christopher Dearlove 
Content-Type: text/plain; charset=us-ascii
X-Mailer: iPhone Mail (13E238)
Message-Id: <279B055B-B0B4-43B0-B439-09B8C0CE65A6@gmail.com>
Date: Wed, 27 Apr 2016 23:18:24 +0100
To: manet@ietf.org
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Archived-At: 
Subject: [manet] Apologies
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, 27 Apr 2016 22:18:31 -0000

Sent emails from wrong address, so John replied to a message that never got h=
ere. I've resent (out of order) messages, if chairs get messages to approve t=
hey can dump them. Causes a bit of a threading hiccup, but best I can do.

-- =20
Christopher Dearlove=


From nobody Wed Apr 27 15:20: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 81D4D12D0CF for ; Wed, 27 Apr 2016 15:20:06 -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 dU1JKdL4GrMw for ; Wed, 27 Apr 2016 15:19:54 -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 34B6712D8D9 for ; Wed, 27 Apr 2016 15:19:54 -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 <1avXoG-0002RG-P1>; Thu, 28 Apr 2016 00:19:52 +0200
Received: from x4e3337bf.dyn.telefonica.de ([78.51.55.191] helo=[192.168.1.2]) by inpost2.zedat.fu-berlin.de (Exim 4.85) for manet@ietf.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id <1avXoG-0022pU-5K>; Thu, 28 Apr 2016 00:19:52 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_EA3172EB-57AA-4844-9E67-45732EAE9832"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Lotte Steenbrink 
In-Reply-To: <60BD2E9C-64D7-4444-B3A9-8D207EB4A86F@gmail.com>
Date: Thu, 28 Apr 2016 00:19:51 +0200
Cc: Mobile Ad Hoc Networks mailing list 
Message-Id: <144C7397-F19E-4FB0-959A-B5A030BD7A8A@fu-berlin.de>
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org>      <60BD2E9C-64D7-4444-B3A9-8D207EB4A86F@gmail.com>
To: Mobile Ad Hoc Networks mailing list 
X-Mailer: Apple Mail (2.3112)
X-Originating-IP: 78.51.55.191
X-ZEDAT-Hint: A
Archived-At: 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 27 Apr 2016 22:20:06 -0000

--Apple-Mail=_EA3172EB-57AA-4844-9E67-45732EAE9832
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> Am 28.04.2016 um 00:16 schrieb Christopher Dearlove =
:
>=20
> The more you have to zero out, the messier it gets, and the less =
secure it gets (more things can be spoofed). I think that's about all =
I've got to add.
>=20

Of course. My question was just:
* Do we want to come up with an exact description of how the zeroing out =
should work now, with the short time we have left?
or
* Do we mention in the draft that zeroing out has to happen somehow and =
leave the nitty gritty to future work?

At least that=E2=80=99s how I understood the options you laid out...

> --=20
> Christopher Dearlove
> christopher.dearlove@gmail.com  =
(iPhone)
> chris@mnemosyne.demon.co.uk  =
(home)
>=20
>=20
>=20
> -- =20
> Christopher Dearlove
> christopher.dearlove@gmail.com  =
(iPhone)
> chris@mnemosyne.demon.co.uk  =
(home)
> On 27 Apr 2016, at 22:46, Lotte Steenbrink =
> =
wrote:
>=20
>> Hi all,
>> I=E2=80=99m currently revising the security considerations with =
regards to the move from regeneration to forwarding, which depends on a =
decision being made on how/where we want to mention the possibility of =
zeroing out TLVs to calculate the ICV for the rest of a message=E2=80=99s =
contents (see second * of my last e-mail). I=E2=80=99ve not found a =
decision on this in other thread (please pardon me if I overlooked =
something), so I=E2=80=99ll bump this thread and ask the WG for its =
opinions. (again, personally, the 2nd option outlined by Christopher =
seems more appealing to me)
>>=20
>> Regards,
>> Lotte
>>=20
>>> Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink =
>:
>>>=20
>>> Hi all,
>>> to summarize:
>>>=20
>>> * AODVv2 message Type numbers should be in the Experimental type =
space and the AODVv2 TLV Types should be message type-specific. This =
also means changing the text regarding IANA actions and changing the =
text regarding what the experiment is to something along the lines of =
=E2=80=9Cwe want to gather experience on how to make generic metric TLVs =
and ICVs that work with changing metric TV values happen with reactive =
protocols=E2=80=9D
>>> * we=E2=80=99re undecided on (to quote Christopher) the "here's a =
mechanism we haven't really thought through in detail, but at least =
we've defined one", or "we know the sort of thing we want, and we'll =
describe it, but rather than produce something not quite right, we'll =
not go further=E2=80=9C decision on temporarily setting the metric value =
to 0 (i.e. the who and how). (personally, I think I=E2=80=99d prefer the =
latter approach, but that=E2=80=99s an entirely gut feeling-based =
preference)
>>>=20
>>> Did I catch that correctly? If so, I=E2=80=99ll put together and =
suggest some text for the first point as soon as I get home and in case =
there has been a decision on the second by then, I=E2=80=99ll try to =
tackle that one too. :)
>>>=20
>>> Best regards, Lotte
>>>=20
>>>> Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) =
>:
>>>>=20
>>>> I have no problem with that. I was trying to lay out the issues =
without muddying the water with my preference.
>>>> =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: Justin Dean [mailto:bebemaster@gmail.com =
]=20
>>>> Sent: 22 April 2016 15:35
>>>> To: Dearlove, Christopher (UK)
>>>> Cc: Thomas Heide Clausen; Mobile Ad Hoc Networks mailing list
>>>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>> =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
>>>> Speaking as participant.
>>>>=20
>>>> I kind of like the idea of using the experimental message type =
space.  We only have a limited amount of these message types.  The TLV =
assignments could just use the message type specific space and there =
isn't an issue there.  IANA wouldn't assign a number but I don't see why =
the document couldn't specify the experimental numbers it was going to =
use so other future near term experiential protocols could do the same =
and generally avoid conflict.  If the experiment is successful IANA =
assignments could be made.  Functionally no real difference with =
protections vs long term usage of limited space.
>>>> =20
>>>> Justin
>>>> =20
>>>> On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) =
> =
wrote:
>>>> There's rather a contradiction between the concepts of a definition =
of a protocol, even Experimental, and experimental space, which usually =
assumes that the user can do what he or she likes in it.
>>>>=20
>>>> But chewing up messages types (how many, 3?) of which there are =
relatively few for experimental is long term a problem, although short =
term not.
>>>>=20
>>>> TLV space is easier in two regards. It's bigger (though the prime =
real estate of type extension zero isn't) and can have message type =
specific TLVs.
>>>>=20
>>>> So TLVS can actually be invisible, if that option is chosen. For =
messages something has to give. Least bad option is again one of those =
we should discuss, but time ...
>>>>=20
>>>> (To be precise, messages types from 224 are defined in RFC 5444 as =
" Experimental Use", of which BCP 26 says "Similar to private or local =
use only, with the  purpose being to facilitate experimentation." The =
alternative 0-223 space is Expert Review. IANA still thinks the experts =
are Joe Macker and the recused Stan Ratliff. But that's a soluble nit.)
>>>>=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
>>>> -----Original Message-----
>>>> From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org =
]
>>>> Sent: 22 April 2016 14:21
>>>> To: Dearlove, Christopher (UK)
>>>> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>>>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>=20
>>>> ----------------------! WARNING ! ---------------------- This =
message originates from outside our organisation, either from an =
external partner or from the internet.
>>>> Consider carefully whether you should click on any links, open any =
attachments or reply.
>>>> Follow the 'Report Suspicious Emails' link on IT matters for =
instructions on reporting suspicious email messages.
>>>> --------------------------------------------------------
>>>>=20
>>>>=20
>>>> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) =
> =
wrote:
>>>> >
>>>> > Once you're entirely in AODV2's own space, and AODVv2 is =
experimental (working assumption for this discussion) you have more =
liberty.
>>>> >
>>>>=20
>>>> Yep.
>>>>=20
>>>> Taken somewhat by surprise both by the sudden "rush" and the =
experimental maturity level, I am wondering (and haven't thought =
through) about experimental space vs non-experimental (for message =
types, and consequently for message type specific TLV types).
>>>>=20
>>>> I think that if the AODVv2 experiment specifies the use of Message =
types from the Experimental message type space without making actual =
registrations in the IANA registry, AND the use of type specific TLV =
types, this becomes a non-issue entirely (by design, this is precisely =
what that experimental space is for)
>>>>=20
>>>> Whereas, as you point out, the alternative is a "can open - worms =
everywhere" situation that I think time is too short to solve?
>>>>=20
>>>> Thomas
>>>>=20
>>>>=20
>>>> > Then you could try specifying it. But with a very good chance of =
producing something you later decide you should have done differently.
>>>> >
>>>> > I honestly don't know which would go down better (or less badly) =
- "here's a mechanism we haven't really thought through in detail, but =
at least we've defined one", or "we know the sort of thing we want, and =
we'll describe it, but rather than produce something not quite right, =
we'll not go further".
>>>> >
>>>> > --
>>>> > 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
>>>> >
>>>> >
>>>> > -----Original Message-----
>>>> > From: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de =
]
>>>> > Sent: 22 April 2016 13:59
>>>> > To: Mobile Ad Hoc Networks mailing list
>>>> > Cc: Henning Rogge; Dearlove, Christopher (UK)
>>>> > Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: =
draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>> >
>>>> > ----------------------! WARNING ! ---------------------- This =
message originates from outside our organisation, either from an =
external partner or from the internet.
>>>> > Consider carefully whether you should click on any links, open =
any attachments or reply.
>>>> > Follow the 'Report Suspicious Emails' link on IT matters for =
instructions on reporting suspicious email messages.
>>>> > --------------------------------------------------------
>>>> >
>>>> > Hello Christopher,
>>>> >
>>>> >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) =
>:
>>>> >>
>>>> >> Just be careful to note that this concept is as currently being =
discussed (a) specific to AODVv2, and (b) not an application of 7182, =
which has no knowledge of special TLVs.
>>>> >>
>>>> >> This is something we'd want to get right, and need to get right =
if in any space not specific to ADODVv2, because getting it wrong =
produces future problems.
>>>> >
>>>> > Makes sense.
>>>> >
>>>> >> I can see some possible approaches, none is ideal and we're =
rather out
>>>> >> of time to specify. But this is experimental, so I think we =
might be
>>>> >> able to indicate the shape of the solution without specifying =
it,
>>>> >> which would be a different RFC, under a bit less time pressure.
>>>> >> (Extensions to existing protocols like 7182 would naturally be =
in
>>>> >> scope rechartered I think.)
>>>> >>
>>>> >> To indicate the range that's open, here are two possible ideas, =
one of which has an impact now, so needs to be agreed. Note that I'm not =
suggesting (in fact quite the opposite) defining an extension to 7182 =
here, rather enabling such an extension, if written, to "do the right =
thing".
>>>> >> - We have an extension to 7182 that says "zero out all value =
octets in protocol specific TLVs. That requires now putting the AODVv2 =
metric TLV in that space.
>>>> >
>>>> > Just to make sure that I understood you correctly=E2=80=93 =
=E2=80=9Cthat space=E2=80=9D meaning making the AODVv2 metric TLV =
protocol specific? (By =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m=
 referring to the generic TLV we=E2=80=99ve been talking about on this =
list earlier this week).
>>>> >
>>>> >> - We have an extension to 7182 that adds extra material to the =
value field that indicates (TBD how, by position with sanity check that =
this is TLV value perhaps?) which octets are to be zeroed out before the =
ICV is calculated.
>>>> >
>>>> > The way I understand that approach, it wouldn=E2=80=99t warrant =
any action from AODVv2 besides saying =E2=80=9Cif you calculate the ICV, =
set the Metric value to zero=E2=80=9D (leaving the nitty gritty of how =
this would be done in detail to future work)=E2=80=A6 Is that correct?
>>>> >
>>>> >>
>>>> >> We do not have the time to specify this in an acceptable manner =
within two weeks though. But the security consideration section could =
say something along the lines of "this enables the use of an ICV defined =
to zero out these octets=E2=80=9C.
>>>> >
>>>> > Okay. :)
>>>> >
>>>> > Best regards,
>>>> > Lotte
>>>> >
>>>> >>
>>>> >> --
>>>> >> 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
>>>> >>
>>>> >> -----Original Message-----
>>>> >> From: manet [mailto:manet-bounces@ietf.org =
] On Behalf Of Lotte
>>>> >> Steenbrink
>>>> >> Sent: 22 April 2016 10:28
>>>> >> To: Henning Rogge
>>>> >> Cc: Mobile Ad Hoc Networks mailing list
>>>> >> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>>>> >> draft-ietf-manet-aodvv2-13 review - a couple of big ticket =
Items)
>>>> >>
>>>> >> ----------------------! WARNING ! ---------------------- This =
message originates from outside our organisation, either from an =
external partner or from the internet.
>>>> >> Consider carefully whether you should click on any links, open =
any attachments or reply.
>>>> >> Follow the 'Report Suspicious Emails' link on IT matters for =
instructions on reporting suspicious email messages.
>>>> >> --------------------------------------------------------
>>>> >>
>>>> >> *** WARNING ***
>>>> >> EXTERNAL EMAIL -- This message originates from outside our =
organization.
>>>> >>
>>>> >>
>>>> >> Hi Henning,
>>>> >>
>>>> >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge >:
>>>> >>>
>>>> >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>>>> >>> > wrote:
>>>> >>>> Hi Thomas,
>>>> >>>> Can it?! Iirc, the reason why we adopted the =
=E2=80=9Cregeneration=E2=80=9D language
>>>> >>>> in the first place is that we=E2=80=99ve been told that =
whenever one bit in
>>>> >>>> the message (apart from its header) is changed, the entire =
thing has to be regenerated.
>>>> >>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just =
been misunderstanding
>>>> >>>> each other for more than a year. :( Anyway, it seems like =
we=E2=80=99re
>>>> >>>> getting close now, so yay.
>>>> >>>
>>>> >>> "Modifying" the binary message instead of parsing and =
generating a
>>>> >>> new one will be difficult as soon someone writes an extension =
to
>>>> >>> AODVv2 that adds more TLVs to the message.
>>>> >>
>>>> >> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99=
s what you explained to me when I got confused about the topic last =
spring=E2=80=A6 But=E2=80=93 even if a message contains TLVs that the =
AODVv2 implementation handling it doesn=E2=80=99t understand, it will =
still be able to recognize the Metric TLV, right? Isn=E2=80=99t that the =
nifty thing about RFC5444? So, while we really shouldn=E2=80=99t write =
=E2=80=9Cbefore calculating the ICV, set the n-th 4 octets to 0=E2=80=9D, =
we might say =E2=80=9Cidentify the octets that make up the metric value =
and set those to 0=E2=80=9D?
>>>> >>
>>>> >> Best regards,
>>>> >> Lotte
>>>> >>
>>>> >>> Henning Rogge
>>>> >>
>>>> >> _______________________________________________
>>>> >> 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 =

>>>>=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 =

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



--Apple-Mail=_EA3172EB-57AA-4844-9E67-45732EAE9832
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



=

--Apple-Mail=_EA3172EB-57AA-4844-9E67-45732EAE9832--


From nobody Wed Apr 27 15:35:09 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 5DA0312B071 for ; Wed, 27 Apr 2016 15:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.093
X-Spam-Level: 
X-Spam-Status: No, score=-1.093 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, TRACKER_ID=1.306] 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 mdp7F7B2BCho for ; Wed, 27 Apr 2016 15:35:00 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 DF79C12B03F for ; Wed, 27 Apr 2016 15:34:57 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id j11so74118870lfb.1 for ; Wed, 27 Apr 2016 15:34:57 -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=lnx8MWUV8j/P844mjaKw11la9SojPNNl3gqAR4pAinE=; b=z8T3c7NoFo92sbotyy6mSQiyKnIRMk5yCTk0Vug31Sql0zkOMqMwemw9GyOnwcVgEm Ub1I9/prvO/s0K/Ocx4X+un0NiCryQmXE0Vh6bhJX809xS7S62kq4Ch1p6bpODRvixVd b+qTA3UX6KxDSUusABI70KYdA6dkagFmDWk+08rNKkz8PtDpdSY/ZKGR9GzVgxjqhnKI K7BIaTod2MKTZiUik+HPP56mP5zG8aQS63rGj36C97B63/Tf9Q/L53YJEvZooM8CHhQK PZ8co8Pb/3S4oqebV+RjIxpdb/NWiCuP23U/DRNLWV0HEIGrHnftCR8JeMUHIEfjoXkn 6tOA==
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=lnx8MWUV8j/P844mjaKw11la9SojPNNl3gqAR4pAinE=; b=YTxKSnqKOCSY1YVuSnyDeSwrIv4vo28hrDZNVQz7WoHrtGaR3iKs33dmJ1p01Sw1IO qvmC1/Aljc4CnC7pGH2iO6FpZxdEj8FXqxgFnu+kRI4OF7JJptoM8wVs6HOydyHLrzPL RWgt9cnnQHMfJfEV/q69H6IcOOzoQ+lIc+FTqdtuwpMJsYTC6UoCr+vWiERp+xUzFOoO VHdcL+UskYgXu5ltmHeKa/EPQvINTqqVn2H7onPMdf/1tdby4ruyCfBIkgtTIjRrtUCj SawBBkQmJXdf+h3rdNr0q6iOPtu1wjaoTMxSWWZ18j1T3bEzyrd1EohI171pOScuJVB7 FH5A==
X-Gm-Message-State: AOPr4FVuK9CcBvSrgPQ9614EkAAG3G/mQSyQWpUyICxhOAZKqGPsQo3ss4zqjoBb8P6xt1QLaOFROYkGkHrfjg==
MIME-Version: 1.0
X-Received: by 10.25.38.69 with SMTP id m66mr4612572lfm.64.1461796495912; Wed, 27 Apr 2016 15:34:55 -0700 (PDT)
Sender: yi.jiazi@gmail.com
Received: by 10.114.77.4 with HTTP; Wed, 27 Apr 2016 15:34:55 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org>      
Date: Thu, 28 Apr 2016 00:34:55 +0200
X-Google-Sender-Auth: tevlwfm8f_FjB2-RbUB2GGwM2cc
Message-ID: 
From: Jiazi YI 
To: Victoria Mercieca 
Content-Type: multipart/alternative; boundary=001a113db104df789105317f0448
Archived-At: 
Cc: Christopher Dearlove , Mobile Ad Hoc Networks mailing list , "Dearlove, Christopher \(UK\)" 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 27 Apr 2016 22:35:06 -0000

--001a113db104df789105317f0448
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 27, 2016 at 10:59 PM, Victoria Mercieca 
wrote:

> Just quickly, on this note, if we remove the AckReq from the RREP itself,
> then because the RREP is multicast, there might be multiple receivers, bu=
t
> there's no way for them to determine if they were the intended next hop, =
so
> they would all have to forward the RREP. The RREP might then go by multip=
le
> routes to get to RREQ_Gen. This assumes all receivers of the RREP have a
> route to OrigAddr anyway (current rules say if they didnt, they would sen=
d
> a RERR back to RREP_Gen).
>
> So, do we have to install a route to the neighbour, then unicast the RREP
> and create a separate message with an AckReq, then if no acknowledgement =
is
> received, blacklist the neighbor and remove the route to the neighbor?
> along with the route to OrigAddr which is not available because the link =
is
> not bidirectional...?
>

My opinion is, if we have a neighbor address and the interface through
which the neighbor can be (possibly) reached, then we can send an unicast
to it.
The others are more implementation details: for example, if a route to the
neighbor is required, we can setup a temporary route entry to the neighbor,
and remove it after the unicast is finished. As it's more implementation, I
don't think it's necessary to go to the specification.

Another related question: when I was reading the specification, a router
only sets up routes to the source/destination, but not to its direct
neighbors?

best

Jiazi


>
> Regards,
> Victoria.
>
> On Mon, Apr 25, 2016 at 4:34 PM, Justin Dean  wrote=
:
>
>> On Mon, Apr 25, 2016 at 11:29 AM, Jiazi YI  wrote:
>>
>>> Hi,
>>>
>>> Maybe I missed a bit here:
>>>
>>> If only the desired receiver of the multicast RREP (carrying a
>>> destination address) can reply to the multicast RREP, why not using uni=
cast
>>> directly?
>>>
>>> Because the link isn't yet known to be bi-directional and a unicast
>> route can't be installed yet.
>>
>> Justin
>>
>>
>>> best
>>>
>>> Jiazi
>>>
>>> On Mon, Apr 25, 2016 at 4:59 PM, Victoria Mercieca >> > wrote:
>>>
>>>> Hi Chris,
>>>>
>>>>
>>>> On Mon, Apr 25, 2016 at 3:51 PM, Dearlove, Christopher (UK) <
>>>> chris.dearlove@baesystems.com> wrote:
>>>>
>>>>> I has to go back to Victoria=E2=80=99s summary here. It says:
>>>>>
>>>>>
>>>>>
>>>>> 2) C creates the RREP. Since it doesnt know if the link to B is
>>>>> bidirectional, it includes the AckReq (an address to indicate that it
>>>>> expects to receive a RREP_Ack from B).
>>>>>
>>>>>
>>>>>
>>>>> That doesn=E2=80=99t actually indicate if that=E2=80=99s C=E2=80=99s =
address or B=E2=80=99s address
>>>>> being included. I=E2=80=99d assumed it was C=E2=80=99s address. Your =
comment makes sense if
>>>>> it=E2=80=99s B=E2=80=99s address. Reading again, I think you=E2=80=99=
re probably right. But only
>>>>> probably. Can we confirm that.
>>>>>
>>>>>
>>>>>
>>>>
>>>> C creates the RREP. The included AckReq address is B's address. The
>>>> RREP then gets multicast.
>>>> B receives it, sees that it own address is marked as the AckReq
>>>> address, and sends an ack unicast back to C.
>>>> Anyone else who receives the multicast RREP from C does not send the
>>>> Ack, since the AckReq address does not match any of their interface
>>>> addresses.
>>>>
>>>>
>>>>> I assume you meant that the RREP (not RREP_Ack) is multicast. There=
=E2=80=99s
>>>>> a bit of a chicken and egg problem here. We do know how we want to un=
icast.
>>>>>
>>>>
>>>> The RREP is multicast (when we dont know if the link is bidirectional)=
,
>>>> the RREP_Ack is always unicast.
>>>>
>>>> Kind regards,
>>>> Vicky.
>>>>
>>>>
>>>>>
>>>>> *-- *
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *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:* 25 April 2016 15:26
>>>>> *To:* Thomas Heide Clausen
>>>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
>>>>> Networks mailing list; Victoria Mercieca
>>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **** WARNING ****
>>>>>
>>>>> *This message originates from outside our organisation, either from a=
n
>>>>> 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
>>>>> .*
>>>>>
>>>>> The address in the RREP_Ack may be required due to the RREP_Ack being
>>>>> multicast as there is not yet a verified unicast route installed yet.
>>>>> Going to double check if I'm remembering correctly.
>>>>>
>>>>> Justin
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 25, 2016 at 10:18 AM,  wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> I must admit that while I have reviewed the protocol several times,
>>>>> I=E2=80=99ve not been digging that deep into the protocol functioning=
 to catch this
>>>>> issue of how invasive the protocol operations are when forwarding a
>>>>> message: there were other =E2=80=9Cmajor=E2=80=9D issues to address (=
and which obscured the
>>>>> details), so as a first order: thank you Victoria, for having called
>>>>> attention to this.
>>>>>
>>>>>
>>>>>
>>>>> To the substance of these emails.
>>>>>
>>>>>
>>>>>
>>>>> I am afraid that I do not understand the use of inserting validity
>>>>> TLVs while in-flight, into a message. Actually, I am dubious for both=
 the
>>>>> originator inserting this (how can the originator of a message know h=
ow
>>>>> =E2=80=9Clatter parts of the path=E2=80=9D will be have=E2=80=9D) exc=
ept if we are talking
>>>>> duty-cycling of devices and inserting =E2=80=9Cthe remaining time tha=
t I am going
>>>>> to be up before I suspend=E2=80=9D. Intuitively, that would also assu=
me fairly long
>>>>> duty cycles =E2=80=9CI am up for tens of seconds=E2=80=9D, which I am=
 not sure are actually
>>>>> realistic. And, as Chris says in another email, this is trading off =
=E2=80=9Cthe
>>>>> ability to do security=E2=80=9D for an unknown/untested feature =E2=
=80=94 which I think is
>>>>> the wrong trade-off.
>>>>>
>>>>>
>>>>>
>>>>> On he topic of =E2=80=9Cneeding to put an address in=E2=80=9D for RRE=
P-ACK, I must
>>>>> admit that this seems roundabout. I can see three issues here:
>>>>>
>>>>>
>>>>>
>>>>> o I am not sure that adding an address vs. a flag may not have to do
>>>>> with the =E2=80=9Cmultiple interfaces/
>>>>>
>>>>> multiple addresses=E2=80=9D discrimination mechanics of the protocol?=
 I
>>>>> haven=E2=80=99t worked it through, though,
>>>>>
>>>>> but that would be a guess.
>>>>>
>>>>>
>>>>>
>>>>> o The end-to-end topology diffusion mechanism should not need to be
>>>>> concerned with the
>>>>>
>>>>> =E2=80=9Cbidirectionally check=E2=80=9D of a local link (in part, as =
it encumbers
>>>>> security, but not only).  In short, a
>>>>>
>>>>> flag or an address, both are (equally) bad.
>>>>>
>>>>>
>>>>>
>>>>> o A cleaner mechanism would be a =E2=80=9Chello mechanism=E2=80=9D, n=
ot necessarily as
>>>>> NHDP, but a =E2=80=9Cwhen
>>>>>
>>>>> forwarding a RREQ/RREP, trigger a 3-way hello exchange, if the link i=
s
>>>>> estimated to be of a
>>>>>
>>>>> type which potentially can be unidirectional=E2=80=9D. There is anoth=
er
>>>>> benefit to doing that, see the end
>>>>>
>>>>> of this email.
>>>>>
>>>>>
>>>>>
>>>>> Either way, I do not like the notion of fusing
>>>>> metrics-and-link-bidirectionality-detection any more than I like fusi=
ng
>>>>> global-topology-diffusion-and-link-bidirectionality-detection.
>>>>>
>>>>>
>>>>>
>>>>> The solution all this is, to me, threefold
>>>>>
>>>>>
>>>>>
>>>>> 1) Factor out the bidirectionally check in a (triggered) neighbour
>>>>> detection mechanism
>>>>>
>>>>> (triggered HELLO message)
>>>>>
>>>>>
>>>>>
>>>>> 2) Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, since they add co=
mplexity for no
>>>>> perceivable benefits
>>>>>
>>>>>
>>>>>
>>>>> 3) Use the security model that we=E2=80=99ve discussed previously, wh=
ere
>>>>> (only) the metrics change per hop.
>>>>>
>>>>>
>>>>>
>>>>> Since we=E2=80=99re discussing bi-directionality of links here, and t=
he
>>>>> 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:
>>>>>
>>>>>
>>>>>
>>>>>    ...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 instal=
led
>>>>>
>>>>>    in the Local Route Set at each router will be correct.  While this
>>>>>
>>>>>    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. Conseque=
ntly, the conclusion
>>>>> 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 li=
nk 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 detection mech=
anism:
>>>>> that exchange could, if designed carefully, be used to probe for and =
convey
>>>>> metrics information, also.
>>>>>
>>>>>
>>>>>
>>>>> Hope this helps,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>> On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK) <
>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Assuming for the moment that everyone will need an RREP-Ack or won=E2=
=80=99t
>>>>> (let=E2=80=99s come back to that) why do C and B need to put an addre=
ss in as an
>>>>> RREQ-Ack request? Why not a flag, because the address will be include=
d as
>>>>> the IP sending address - and we know 5444 is required to pass that on=
.
>>>>> (It=E2=80=99s used by NHDP as well.) Then we don=E2=80=99t need to ch=
ange the RREP, it will
>>>>> have a flag set or not, and won=E2=80=99t change (in this regard).
>>>>>
>>>>>
>>>>>
>>>>> Now let=E2=80=99s consider do we know whether we can set a fixed flag=
. First
>>>>> I=E2=80=99d say there are two cases - you=E2=80=99ve got a firm contr=
ol on what=E2=80=99s going on
>>>>> in your network, or it=E2=80=99s one of unknown parties and behaviour=
 (consistent
>>>>> with specification). In the former case you only want one setting, fo=
r
>>>>> example no-Ack if running NHDP or your MAC layer tells you about
>>>>> bidirectionality, Ack otherwise. In the latter case, I think you just
>>>>> always want an Ack. So both cases get you to the same place.
>>>>>
>>>>>
>>>>>
>>>>> Should that not be an acceptable argument (though I think it=E2=80=99=
s good
>>>>> for where we are - in fact always Ack is close) then at flag is a ste=
p
>>>>> better, it=E2=80=99s a fixed location to change. However it would be =
better in that
>>>>> case if the two things to change (metric and ack flag) were together.=
 But
>>>>> that has its own issues, so I won=E2=80=99t go there.
>>>>>
>>>>>
>>>>>
>>>>> *--*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com
>>>>> ]
>>>>> *Sent:* 25 April 2016 14:15
>>>>> *To:* Jiazi YI
>>>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc
>>>>> Networks mailing list
>>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **** WARNING ****
>>>>>
>>>>> *This message originates from outside our organisation, either from a=
n
>>>>> 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
>>>>> .*
>>>>>
>>>>> Hi Jiazi,
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI  wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>
>>>>> With regard to your validity time point, we here have a tradeoff. If
>>>>> you allow that feature, it significantly impacts on the approach that=
 was
>>>>> coming together on as best you can end to end encryption.
>>>>>
>>>>>
>>>>>
>>>>> So the question is, is this a feature that=E2=80=99s really wanted?
>>>>> Unfortunately I think we know that the answer to that is, we don=E2=
=80=99t know
>>>>> because we don=E2=80=99t have any experience. My view would be that i=
n the tradeoff
>>>>> of an untested feature (unless I=E2=80=99m wrong about that) and the =
security
>>>>> complication, security wins and drop the feature. If there is some re=
al
>>>>> requirement, then there=E2=80=99s a discussion. (Questions like how o=
ften the
>>>>> intermediate routers actually have any knowledge - typically links br=
eak
>>>>> for unexpected rather than expected reasons. Andan intermediate route=
r
>>>>> could possibly use a validity time to influence its behaviour.) Note =
that
>>>>> dropping the ability of intermediate routers to modify/set still allo=
ws
>>>>> validity times per route to be set at endpoints.
>>>>>
>>>>>
>>>>>
>>>>> I agree with Chris' concern.
>>>>>
>>>>> The ValidityTime is optional, which makes the integrity protection
>>>>> hard. Furthermore, it gives a potential attack vector: as all the rou=
ters
>>>>> in a path will take the shortest validityTime, a compromised router c=
an set
>>>>> the the validityTime to a very short value, which will make the route
>>>>> installed along the path became invalid (very soon).
>>>>>
>>>>>
>>>>>
>>>>> On the other hand, I'm not sure this option will give us much help.
>>>>> Chris mentioned much knowledge intermediate router would have to deci=
de
>>>>> this value (and how much sense the value would make).
>>>>>
>>>>> Another issue is, a route to a destination might be updated by
>>>>> different sources. For example, in the network below:
>>>>>
>>>>>
>>>>>
>>>>> A----B-----C
>>>>>
>>>>>
>>>>>
>>>>> A first establish a route to B with long validity time. Then A
>>>>> initiates a route discovery to C. C tends to set a short validity tim=
e,
>>>>> which will make the route between B and A expire earlier than expecte=
d.
>>>>>
>>>>> Is this a problem? Maybe yes, maybe no -- I'm not sure it's considere=
d
>>>>> or not.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Not sure I follow here.
>>>>>
>>>>> Currently, the validity time of the route between A and B would not
>>>>> affected by a short validity time of a route between A and C. Validit=
y
>>>>> times are per-route, and the route A-B and the route A-C are separate=
.
>>>>>
>>>>> If we switched to a validity time per neighbor (so that we can keep
>>>>> validity time separate from route advertisements) as I mentioned in t=
he
>>>>> email below, then the validity of a route between A and C would be af=
fected
>>>>> if there was a short validity time between A and B. But, if B will on=
ly
>>>>> route for a certain amount of time, then the route between A and C wi=
ll of
>>>>> course be affected. Is it best to know in advance that there's a time
>>>>> limit, or just deal with RERRs when they happen?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> With regard to the acknowledgements, the problem (with regard to
>>>>> security) comes from trying to do two jobs with the same message - en=
d to
>>>>> end route advertisement and hop by hop acknowledgement. I understand =
the
>>>>> reasons - saving bytes and message types. (I would have to study the
>>>>> protocol really hard to identify if any message types can be folded
>>>>> together and recognised by content rather than type efficiently. This=
 I do
>>>>> not expect to do.) Again a tradeoff. This one is in discussion space,
>>>>> though that needs people who understand both sides of the issue, incl=
uding
>>>>> the details of the bidirectionality mechanism. Of course, as has been=
 said,
>>>>> we need one of those.
>>>>>
>>>>>
>>>>>
>>>>> I haven't finished my review of the latest draft, and I don't get the
>>>>> necessity of AckReq and the corresponding multicast RREP yet.
>>>>>
>>>>> If possible, this "optional" field should be avoided.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> To give an overview of AckReq and RREP:
>>>>>
>>>>> Since AODVv2 requires bidirectional links, this is the way to
>>>>> determine if a link is bidirectional.
>>>>>
>>>>> A----B----C
>>>>>
>>>>>
>>>>> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both
>>>>> install a route to OrigAddr but they dont yet know if it's valid beca=
use
>>>>> they dont know if the link to their next hop is available in the reve=
rse
>>>>> direction.
>>>>>
>>>>> 2) C creates the RREP. Since it doesnt know if the link to B is
>>>>> bidirectional, it includes the AckReq (an address to indicate that it
>>>>> expects to receive a RREP_Ack from B).
>>>>>
>>>>> 3) B receives the RREP, installs a route to TargAddr and marks it as
>>>>> valid, since it knows the link to C is bidirectional, because the RRE=
Q went
>>>>> in one direction and the RREP came in the other. B also sends the RRE=
P_Ack
>>>>> to C and forwards the RREP to A (and might change the message to indi=
cate
>>>>> its own AckReq - ie that it requires an ack from A).
>>>>>
>>>>> 4) C receives the RREP_Ack from B, and therefore knows that B receive=
d
>>>>> the RREP, therefore the link is bidirectional. C can then mark its ro=
ute to
>>>>> OrigAddr as valid.
>>>>>
>>>>> 5) Similarly, A receives the RREP, installs the route to TargAddr and
>>>>> sends an RREP_Ack to B.
>>>>>
>>>>> 6) B receives the RREP_Ack and marks its route to OrigAddr as valid.
>>>>>
>>>>>
>>>>>
>>>>> Alternatively, in step 2, if C knows the link to B is bidirectional
>>>>> (perhaps from some earlier route discovery), it doesnt need to put th=
e
>>>>> AckReq in the RREP. Then in step 3, since B doesnt know if the link t=
o A is
>>>>> bidirectional, it changes the message to add the AckReq address, in o=
rder
>>>>> to get an RREP_Ack from A.
>>>>>
>>>>> If we want to avoid changing the message, we'll need to look at
>>>>> forwarding the RREP as-is, and creating a second message to solicit a=
n
>>>>> RREP_Ack, in order to verify that the link is bidirectional before ma=
rking
>>>>> the route to OrigAddr as valid.
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Victoria.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> regards
>>>>>
>>>>>
>>>>>
>>>>> Jiazi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *--*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>> Intelligence Laboratories *
>>>>> *____________________________________________________________________=
______
>>>>> *
>>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
>>>>> *Sent:* 23 April 2016 10:55
>>>>> *To:* Christopher Dearlove
>>>>> *Cc:* ietf@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad
>>>>> Hoc Networks mailing list
>>>>>
>>>>>
>>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **** WARNING ****
>>>>>
>>>>>
>>>>>
>>>>> *This message originates from outside our organisation, either from a=
n
>>>>> external partner or the internet. Consider carefully whether you shou=
ld
>>>>> 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
>>>>> .*
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>>
>>>>>
>>>>> These have both been in the draft in some form since before I got
>>>>> involved... but I'll do my best to explain.
>>>>>
>>>>>
>>>>>
>>>>> - For Validity Time, its a way to advertise that you would only
>>>>> support the route contained in the message for a certain period of ti=
me.
>>>>> The originator might use this, but the draft was written to allow any
>>>>> intermediate node to be able to add it or update it too. The route cr=
eated
>>>>> in the Local Route Set has an expiration time associated with it, bas=
ed on
>>>>> the received validity time.
>>>>>
>>>>> - For the AckReq address, its so that you can add into a RREP a
>>>>> request for an acknowledgement, so that you don't have to have a diff=
erent
>>>>> message type altogether for working out whether links to neighbors ar=
e
>>>>> bidirectional, and also, since you only care about bidirectionality o=
n
>>>>> routes that are being set up, you dont need to constantly monitor all
>>>>> neighbors.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> In order to avoid the potential AckReq-related changes to each
>>>>> message, maybe we do need to introduce a different message specifical=
ly for
>>>>> this. We could maybe use RREP_Ack to both request and acknowledge? It=
 means
>>>>> an extra message of control traffic that needs to be sent, maybe one =
extra
>>>>> message per hop on the path of a RREP, but it could still be limited =
to
>>>>> neighbors which have participated in the route discovery rather than
>>>>> monitoring all neighbors at all times.
>>>>>
>>>>>
>>>>>
>>>>> This message could maybe also include "I'm happy to route anywhere fo=
r
>>>>> a certain amount of time", sort of like willingness in OLSR/OLSRv2. S=
o
>>>>> instead of having a validity time per route, its a validity time per
>>>>> neighbor. Then, for RREQ and RREP, only the metric value would change=
 in
>>>>> transit, as discussed. However, that leads to some issues with decidi=
ng
>>>>> what a route's expiration time is. You might know how long the next h=
op
>>>>> router is valid for, but what if a router beyond that, which was also=
 part
>>>>> of the route, had a lower validity time? You couldn't determine the r=
eal
>>>>> validity time. Do we remove the route expiration time altogether to a=
void
>>>>> this issue? In which case, we would have to rely on RERR messages bei=
ng
>>>>> sent for routes which become invalid when the neighbor's validity tim=
e has
>>>>> expired? So neighbor validity time expiration is treated the same as =
a link
>>>>> break.
>>>>>
>>>>>
>>>>>
>>>>> What do you think?
>>>>>
>>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Victoria.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
>>>>> chris@mnemosyne.demon.co.uk> wrote:
>>>>>
>>>>> Pretty much all of the discussion has been assuming only a metric
>>>>> value change. With multiple things changing many of the ideas go out =
of the
>>>>> window. That reinforces the point about not making specifications now=
 that
>>>>> might turn out to be wrong for ICVs.
>>>>>
>>>>>
>>>>>
>>>>> Ignoring how this misunderstanding happened, I'll start by asking why=
.
>>>>> Metric changing I understand. Why the other two? (there's a partial
>>>>> explanation of one). What alternatives have people implemented in
>>>>> comparable protocols?
>>>>>
>>>>> --
>>>>>
>>>>> Christopher Dearlove
>>>>>
>>>>> christopher.dearlove@gmail.com (iPhone)
>>>>>
>>>>> chris@mnemosyne.demon.co.uk (home)
>>>>>
>>>>>
>>>>> On 23 Apr 2016, at 00:26, Victoria Mercieca 
>>>>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>>
>>>>> Continued in this thread because the other one seems to be more about
>>>>> TLV types and metric type numbers, whereas this is about
>>>>> regeneration/forwarding.
>>>>>
>>>>>
>>>>>
>>>>> To recap, in the current draft, there are 3 things that might change
>>>>> at each hop:
>>>>> - the metric value (happens in RREQ and RREP),
>>>>> - adding/changing Validity Time using the Validity Time TLV (can
>>>>> happen in RREQ and RREP),
>>>>> - adding an address (and corresponding value in the AddressType TLV t=
o
>>>>> indicate how to interpret the address) to indicate the address from w=
hich
>>>>> an RREP_Ack is expected, to accomplish the bidirectionality check (ca=
n
>>>>> happen in RREP).
>>>>>
>>>>> If we define a certain portion of the message as immutable and includ=
e
>>>>> the ICV to verify that part, end to end:
>>>>> - The metric value would be excluded from the ICV since it needs
>>>>> changing at each hop.
>>>>> - Would adding a Validity Time TLV at an intermediate hop be
>>>>> acceptable? The whole TLV could be removed in order to calculate the =
ICV?
>>>>>
>>>>> - Would adding an address cause issues for the ICV, because it's in
>>>>> the address block? Could the rule be "if it contains an AckReq addres=
s,
>>>>> remove it (and the corresponding value in the AddressType TLV), befor=
e
>>>>> checking the ICV", is that OK? Or would we need to avoid touching the
>>>>> ICV'ed part of the message altogether, maybe put the AckReq address i=
n a
>>>>> separate Address Block, with an extra AddressType TLV following that
>>>>> address block? Is there a way to accomplish this?
>>>>>
>>>>>
>>>>>
>>>>> Also, to be thorough, do we need to consider RERR messages while we
>>>>> discuss regeneration vs forwarding?
>>>>>
>>>>> - RERR (sent when a link breaks) is a way of saying "I've lost my
>>>>> route so I'm telling others" and "you were my next hop, so now I've a=
lso
>>>>> lost my route, I'll tell others", etc. It's going to be tailored at e=
ach
>>>>> step to include the relevant routes that got deleted, it's not one me=
ssage
>>>>> being sent end-to-end like RREQ and RREP are.
>>>>>
>>>>> - However, RERR (sent when a source of traffic is sending data on a
>>>>> route which comes through you, and you want to tell the Packet Source=
's
>>>>> router to delete the route) could be seen as an end-to-end message wh=
ich
>>>>> all intermediate routers learn from, similar to RREQ and RREP. It rep=
orts
>>>>> one route, and doesn't need changing at intermediate hops, so could b=
e
>>>>> protected with ICV.
>>>>>
>>>>> - Would it be OK to only require a message ICV if a PktSource address
>>>>> was included, i.e. when the message needs to go via a number of
>>>>> intermediate hops to PktSource's router? All other RERRs are intended=
 to be
>>>>> one-hop messages, which may in turn prompt other one-hop messages, et=
c...,
>>>>> and a packet ICV might be more appropriate?
>>>>>
>>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Victoria.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 17, 2016 at 5:26 PM,  wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Yes, I meant AODVv2, thanks for the catch.
>>>>>
>>>>>
>>>>>
>>>>> So is your (Thomas) proposed base specification a hop count only
>>>>> metric?
>>>>>
>>>>>
>>>>>
>>>>> No, the would be silly as base specification, given that hop count
>>>>> mostly is useless.
>>>>>
>>>>>
>>>>>
>>>>> As base specification I would simply say =E2=80=9CInclude a Metric Ty=
pe
>>>>> Message TLV with a value field, and a 7182 Message TLV & Timestamp=E2=
=80=9D as we
>>>>> do in OLSRv2 (with the appropriate verbiage as to generation and
>>>>> processing).
>>>>>
>>>>>
>>>>>
>>>>> With the message generated by the originator of the RREQ/RREP and
>>>>> *not* deconstructed/reconstructed/reordered (as is the risk with
>>>>> =E2=80=9Cregeneration) allows knowing that it would be *only* that me=
tric field
>>>>> being modified (other than hop count/limit) for when eventually writi=
ng up
>>>>> the extension.
>>>>>
>>>>>
>>>>>
>>>>> (Actually doesn=E2=80=99t the current specification only define hop c=
ount, or
>>>>> has that changed in latest draft?)
>>>>>
>>>>>
>>>>>
>>>>> No. That is one of the issues I raise in my original. For some reason=
,
>>>>> it cites RFC6551, which is a ROLL document and which has in its abstr=
act
>>>>> that:
>>>>>
>>>>>
>>>>>
>>>>>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>>>>>
>>>>>    compared with traditional wired and ad hoc networks that require t=
he
>>>>>
>>>>>    specification of new routing metrics and constraints.
>>>>>
>>>>>
>>>>>
>>>>> I.e. this document cites a metric document which clearly claims to be
>>>>> inapplicable in ad hoc networks. I note that this is another thing I=
=E2=80=99ve
>>>>> raised for years without seeing it attempted resolved.
>>>>>
>>>>>
>>>>>
>>>>> Best,
>>>>>
>>>>>
>>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *--*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>> Intelligence Laboratories *
>>>>> *____________________________________________________________________=
______
>>>>> *
>>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>>>>> ]
>>>>> *Sent:* 17 March 2016 17:10
>>>>> *To:* Dearlove, Christopher (UK)
>>>>> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **** WARNING ****
>>>>>
>>>>>
>>>>>
>>>>> *This message originates from outside our organisation, either from a=
n
>>>>> external partner or the internet. Consider carefully whether you shou=
ld
>>>>> 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 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> OK, so we have a message that mutates by:
>>>>>
>>>>> - Modifying hop count/limit.
>>>>>
>>>>> - Modifying a metric value.
>>>>>
>>>>> Anything else?
>>>>>
>>>>>
>>>>>
>>>>> As mutating (other than hop count/limit) messages aren=E2=80=99t cove=
red by
>>>>> 5444 or any derivative document (but only recommended against, not ba=
nned)
>>>>> that you may need to make the message otherwise immutable (no
>>>>> deconstruction and rebuilding, other than guaranteed unchanging) that=
 would
>>>>> have to be specified by AODVv2. (Easy to say, but needs saying.)
>>>>>
>>>>>
>>>>>
>>>>> With you so far.
>>>>>
>>>>>
>>>>>
>>>>> Then that information is not in a guaranteed fixed location given by =
a
>>>>> simple offset. So any signature algorithm that finds it and ignores i=
t or
>>>>> aggregates on it is specific to OLSRv2.
>>>>>
>>>>>
>>>>>
>>>>> Surely you mean AODVv2
>>>>>
>>>>>
>>>>>
>>>>> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AOD=
Vv2
>>>>> specialised variant. Which is the sort of thing that the message spec=
ific
>>>>> TLV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cbu=
t ignore the value of
>>>>> this specific TLV should it occur=E2=80=9D being in the general space=
. However it
>>>>> can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like=
 that TLV,
>>>>> except if an X TLV is present, set its value field to zero=E2=80=9D).
>>>>>
>>>>>
>>>>>
>>>>> Messy, but could work.
>>>>>
>>>>>
>>>>>
>>>>> Not that messy, actually, although clearly not as nice as =E2=80=9Cfi=
xed
>>>>> offset=E2=80=9D.
>>>>>
>>>>>
>>>>>
>>>>> That said, I am arguing for the base spec being:
>>>>>
>>>>>
>>>>>
>>>>>             =E2=80=9Cmake the message otherwise immutable (no deconst=
ruction
>>>>> and rebuilding, other
>>>>>
>>>>>              than guaranteed unchanging)=E2=80=9D which is afforded b=
y
>>>>> forwarding
>>>>>
>>>>>
>>>>>
>>>>>                                     +
>>>>>
>>>>>
>>>>>
>>>>>             RFC7182 Timestamps and ICVs.
>>>>>
>>>>>
>>>>>
>>>>>                                     +
>>>>>
>>>>>
>>>>>
>>>>>             RFC7183 style text bringing it all together.
>>>>>
>>>>>
>>>>>
>>>>> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D woul=
d very be an
>>>>> experimental extension.
>>>>>
>>>>>
>>>>>
>>>>> What I object to is, if the base spec specifically renders such
>>>>> extensions impossible
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *--*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>> Intelligence Laboratories *
>>>>> *____________________________________________________________________=
______
>>>>> *
>>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
>>>>> ]
>>>>> *Sent:* 17 March 2016 16:48
>>>>> *To:* Dearlove, Christopher (UK)
>>>>> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
>>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **** WARNING ****
>>>>>
>>>>>
>>>>>
>>>>> *This message originates from outside our organisation, either from a=
n
>>>>> external partner or the internet. Consider carefully whether you shou=
ld
>>>>> 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
>>>>> .*
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>>
>>>>> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
>>>>> chris.dearlove@baesystems.com>:
>>>>>
>>>>>
>>>>>
>>>>> Good point about whether you just pass on one cost or a set of costs.
>>>>> As I said, not looked at details - I will, when time permits. One cos=
t is
>>>>> much easier, and yes, it reduces the fixed size aggregated signatures
>>>>> problem to =E2=80=9Cjust=E2=80=9D one of computational load.
>>>>>
>>>>>
>>>>>
>>>>> For the record, Thomas=E2=80=99 understanding is correct; the cost is=
 one
>>>>> aggregated value.
>>>>>
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Lotte Steenrbink
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *--*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>> Intelligence Laboratories *
>>>>> *____________________________________________________________________=
______
>>>>> *
>>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>>>>> ]
>>>>> *Sent:* 17 March 2016 16:38
>>>>> *To:* Dearlove, Christopher (UK)
>>>>> *Cc:* Mobile Ad Hoc Networks mailing list
>>>>> *Subject:* Re: Message integrity and message mutability (was RE:
>>>>> [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket It=
ems)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **** WARNING ****
>>>>>
>>>>>
>>>>>
>>>>> *This message originates from outside our organisation, either from a=
n
>>>>> external partner or the internet. Consider carefully whether you shou=
ld
>>>>> 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 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> I appreciate Thomas=E2=80=99s comments about the limitations of messa=
ge
>>>>> regeneration, but I would be a bit less absolute.
>>>>>
>>>>>
>>>>>
>>>>> The issues over end to end authentication and more advanced signature=
s
>>>>> are valid. I need to read the given reference on aggregate signatures=
 to
>>>>> increase my knowledge (thanks for it), but my understanding of the
>>>>> possibilities in this field may offer a solution to the problem, but =
with
>>>>> some other issues (possibly including a new type of TLV).
>>>>>
>>>>>
>>>>>
>>>>> But the hop count/limit point I don=E2=80=99t fully agree with, you c=
an
>>>>> regenerate with an incremented/decremented count/limit, which leaves =
the
>>>>> ability to prevent messages propagating indefinitely, including expan=
ding
>>>>> ring searches, and retains the ability to use RFC 5497 interval and
>>>>> validity times that might be useful with an expanding ring search (or=
 might
>>>>> not).
>>>>>
>>>>>
>>>>>
>>>>> But the key issue is that AODVv2 wants to accumulate metrics. I still
>>>>> haven=E2=80=99t got to the bottom of many details here, but let=E2=80=
=99s for the moment
>>>>> just consider that conceptually.
>>>>>
>>>>>
>>>>>
>>>>> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft attem=
pts to do an end
>>>>> to end of some information, not this information. I=E2=80=99m not sur=
e if that=E2=80=99s
>>>>> useful (and the specialised format is better avoided if possible). Ot=
her
>>>>> approaches are hop by hop (might as well use packet signatures) and s=
hared
>>>>> key (might as well go hop by hop). Pairwise signatures for each pair =
of
>>>>> routers I=E2=80=99m discounting as scaling terribly. In the interests=
 of
>>>>> completeness let=E2=80=99s mention not accumulating metrics, which pu=
ts us back to
>>>>> hop count and that=E2=80=99s not ideal either.
>>>>>
>>>>>
>>>>>
>>>>> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=
=80=99ve seen
>>>>> about aggregating, but that has some issues of its own, even apart fr=
om
>>>>> computational load.) I=E2=80=99d love to be proved wrong - someone wi=
th the perfect
>>>>> solution to come along.
>>>>>
>>>>>
>>>>>
>>>>> Which means that either we make an arbitrary choice - which will be
>>>>> disagreed with, but needs discussing first - or create something flex=
ible.
>>>>> Unfortunately flexible in that regard constrains in others, e.g. some
>>>>> (many? most?) aggregating signatures need fixed data sizes (which we =
can do
>>>>> by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, but=
 that has a cost too).
>>>>>
>>>>>
>>>>>
>>>>> I have been told by people much more well versed in this than I in
>>>>> cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>>>>>
>>>>>
>>>>>
>>>>> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 doe=
s that mean that
>>>>> the message grows as it is being forwarded, and that the recipient of=
 a
>>>>> RREQ/RREP will know the individual costs of each path segment? My
>>>>> understanding is, that the recipient will get =E2=80=9Cthe sum the co=
sts of each
>>>>> path segment=E2=80=9D which should be fitting within a fixed size?
>>>>>
>>>>>
>>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Sorry, no answers, just comments. And I=E2=80=99m not addressing Thom=
as=E2=80=99s
>>>>> later points here.
>>>>>
>>>>>
>>>>>
>>>>> *--*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>> Intelligence Laboratories *
>>>>> *____________________________________________________________________=
______
>>>>> *
>>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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 *ietf@thomasclausen.org
>>>>> *Sent:* 17 March 2016 16:00
>>>>> *To:* Mobile Ad Hoc Networks mailing list
>>>>> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of
>>>>> big ticket Items
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **** WARNING ****
>>>>>
>>>>>
>>>>>
>>>>> *This message originates from outside our organisation, either from a=
n
>>>>> external partner or the internet. Consider carefully whether you shou=
ld
>>>>> 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 organizati=
on
>>>>> .
>>>>>
>>>>>
>>>>>
>>>>> Dear all,
>>>>>
>>>>>
>>>>>
>>>>> Apologies for not having gotten this done sooner - day-job leaving fe=
w
>>>>> spare cycles.
>>>>>
>>>>>
>>>>>
>>>>> I=E2=80=99ve previously offered reviews and comments, and some of tho=
se have
>>>>> been addressed in the latest I-D =E2=80=94 others have not, but shoul=
d be. I recall
>>>>> that there was some mail attempting to rebut parts of the review, and=
 I
>>>>> will dig it out and reply to that.
>>>>>
>>>>>
>>>>>
>>>>> With that being said, I have reviewed the latest version of the
>>>>> document, and full details will be forthcoming. There=E2=80=99re a co=
uple of
>>>>> big-ticket/architectural items that I want to address up front, as I
>>>>> believe that before we have those hammered out, it will be useless to=
 go
>>>>> into details. Note, I do not claim that this is an exhaustive list of=
 =E2=80=9Cbig
>>>>> ticket items=E2=80=9D, but that=E2=80=99s as far as I have gotten in =
thinking this through.
>>>>>
>>>>>
>>>>>
>>>>> I also bring these up as they are items that have been brought up
>>>>> repeatedly over the past years, but not resolved nor discussed.
>>>>>
>>>>>
>>>>>
>>>>> *Loops*
>>>>>
>>>>> Just to bring this out: I share Chris=E2=80=99 worry about conflictin=
g and
>>>>> concurrent statements from the authors on =E2=80=9CThere are no loops=
 possible=E2=80=9D and
>>>>> =E2=80=9CWe need to fix two situations where loops can occur=E2=80=9D=
 and =E2=80=9Cwe are still
>>>>> investigating some loop conditions=E2=80=9D
>>>>>
>>>>>
>>>>>
>>>>> I particularly worry that this is not a discussion had in public, but
>>>>> apparently in some other forum=E2=80=A6
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Intermediate Route Replies, and all of section 10*
>>>>>
>>>>> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=E2=
=80=9D, which is
>>>>> incoherent with the intended status indicated for this document.
>>>>>
>>>>>
>>>>>
>>>>> Specifically, and this is not unrelated to the point about loops
>>>>> above, intermediate RREPs (section 10.3) are a potential source for l=
oops.
>>>>>
>>>>>
>>>>>
>>>>> Expanding Ring Multicast (section 10.1) is not documented in a way
>>>>> that can be implemented (and also, see =E2=80=9CForwarding-vs-regener=
ation=E2=80=9D below,
>>>>> it is in the present form of this protocol impossible), etc.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Forwarding-vs-regeneration*
>>>>>
>>>>> Recent exchanges on the list made me understand that protocol control
>>>>> messages are *not* forwarded, but are consumed at each hop, then a ne=
w
>>>>> message with (almost-but-not-quite) the same content is generated and
>>>>> transmitted.
>>>>>
>>>>>
>>>>>
>>>>> I have thought some more on this (& read some of the exchanges on the
>>>>> list on this topic by Chris, Ulrich, and others), and I am convinced =
that
>>>>> this is not the right way to go, *at least* for the following reasons=
:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>             o          *It renders the hop-limit/hop-count fields in
>>>>> the RFC5444 message header useless.*
>>>>>
>>>>>                         This would not be bad if the functionality
>>>>> offered by those fields was not useful
>>>>>
>>>>>                         =E2=80=94 sadly, it is. For example, for scop=
e limited
>>>>> flooding (expanding ring search, and
>>>>>
>>>>>                         such) which may be of interest, and which
>>>>> require hop-limit.
>>>>>
>>>>>                         A hop-count field may also provide a =E2=80=
=9Ccheap=E2=80=9D
>>>>> (in terms of overhead) additional piece
>>>>>
>>>>>                         of information to use conjunctively with a
>>>>> =E2=80=9Creal=E2=80=9D metric.
>>>>>
>>>>>
>>>>>
>>>>>                         The only practical solution would be to
>>>>> re-introduce these functions by way of inserting a
>>>>>
>>>>>                         MessageTLV =E2=80=94 which (i) is not specifi=
ed in
>>>>> this document, and (ii) which would just
>>>>>
>>>>>                         serve to render messages bigger than strictly
>>>>> needed.
>>>>>
>>>>>
>>>>>
>>>>>                         Scope limited flooding  does seem to be a
>>>>> necessary requirement, if for no
>>>>>
>>>>>                         other reason than to prevent information from
>>>>> =E2=80=9Ccirculating forever in the network=E2=80=9D.
>>>>>
>>>>>
>>>>>
>>>>>             o          *It makes end-to-end authentication
>>>>> unnecessarily hard.*
>>>>>
>>>>>                         I think Chris called this out already, but it
>>>>> bears repeating: S generates a message
>>>>>
>>>>>                         (say, a RREQ), and includes an ICV calculated
>>>>> over the content of the message.
>>>>>
>>>>>                         For any recipient to be able to validate the
>>>>> ICV, the message has to be exactly
>>>>>
>>>>>                         the same =E2=80=94 not just in content, but i=
n
>>>>> structure =E2=80=94 as what was generated.
>>>>>
>>>>>
>>>>>
>>>>>                         =E2=80=9CRegenerating=E2=80=9D rather than =
=E2=80=9Cforwarding=E2=80=9D
>>>>> messages means, that the intermediate
>>>>>
>>>>>                         router =E2=80=9Cregenerating=E2=80=9D the RRE=
Q may chose a
>>>>> different structure (e.g., include TLVs
>>>>>
>>>>>                         in a different order).
>>>>>
>>>>>
>>>>>
>>>>>                         The proposal from
>>>>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>>>>>
>>>>>                         is to add constraints on (i) the set of
>>>>> elements to include in a signature and (ii) the
>>>>>
>>>>>                         order of these elements.
>>>>>
>>>>>
>>>>>
>>>>>                         One problem with that approach is (i): if an
>>>>> extension adds a message TLV, or an
>>>>>
>>>>>                         Address TLV, to a message, then that will not
>>>>> be =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>>>>>
>>>>>                         Rather for *each* extension developed, an
>>>>> =E2=80=9Cupdates e2esec=E2=80=9D clause needs to be done.
>>>>>
>>>>>
>>>>>
>>>>>                         I=E2=80=99d say that this approach would be p=
rone to
>>>>> errors =E2=80=94 and add entropy to the process
>>>>>
>>>>>                         of designing protocol extensions. The
>>>>> alternative, a message being generated by the
>>>>>
>>>>>                         source and *forwarded* (as we do in OLSRv2,
>>>>> for example) would allow ICV TLVs
>>>>>
>>>>>                         (even, allow reuse of those specified for
>>>>> OLSRv2) for covering a message and
>>>>>
>>>>>                         extensions.
>>>>>
>>>>>
>>>>>
>>>>>                         =E2=80=9CBut what about the metrics value whi=
ch will
>>>>> change on each hop=E2=80=9D, you may say?
>>>>>
>>>>>                         Fortunately, that is relatively easy to
>>>>> handle: simply zero out the value of that TLV when
>>>>>
>>>>>                         generating or verifying the ICV MessageTLV.
>>>>> And use Packet-TLVs for hop-by-hop
>>>>>
>>>>>                         authentication, if needed (but, see below).
>>>>>
>>>>>
>>>>>
>>>>>             o          *It prevents the use of more clever/advanced
>>>>> signature schemes/ICVs*
>>>>>
>>>>>                         Aggregate signature algorithms (
>>>>> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>>>>>
>>>>>                         exist, and an interesting use-case can be
>>>>> found in also reactive protocols, allowing verifying
>>>>>
>>>>>                         not =E2=80=9Cjust=E2=80=9D the end points, bu=
t also the
>>>>> intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=
=9D
>>>>>
>>>>>                         discussed above, or something smarter).
>>>>>
>>>>>                         Regeneration of messages, rather than
>>>>> forwarding, renders that impossible (or, if used,
>>>>>
>>>>>                         updating to
>>>>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>>>>>
>>>>>
>>>>>
>>>>> There are other reasons, but the above are those that jump at me as
>>>>> immediate show-stoppers.
>>>>>
>>>>>
>>>>>
>>>>> I do honestly not see what possible benefit there is from
>>>>> =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inconve=
niences, and security is not
>>>>> the least of these. Insisting on =E2=80=9Cregeneration=E2=80=9D requi=
res development of
>>>>> =E2=80=9Cnon-general workarounds=E2=80=9D as pointed out above.
>>>>>
>>>>>
>>>>>
>>>>> *Security Considerations*
>>>>>
>>>>> This is an always thorny subject. When OLSRv2 was going through the
>>>>> process we got a thorough education in how little we knew about secur=
ity
>>>>> from the SEC-ADs, and had to spend about a year or so developing RFC7=
183.
>>>>> The bottom line is, that this protocol needs its =E2=80=9CRFC7183  eq=
uivalent=E2=80=9D,
>>>>> either as part of the main document, or as an independent document.
>>>>> currently, that is not the case.
>>>>>
>>>>>
>>>>>
>>>>> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration fr=
om
>>>>> RFC7183 might be aw good idea, as that was the most recent that went
>>>>> through the SEC AD. Regardless of how, however, a =E2=80=9Cmandatory =
to implement=E2=80=9D
>>>>> security mechanism most be specified (I think the right term was =E2=
=80=9CMUST
>>>>> implement, SHOULD use=E2=80=9D), in sufficient detail to ensure inter=
operable
>>>>> implementations.
>>>>>
>>>>>
>>>>>
>>>>> As an example, both [RFC6130] and [RFC7181] set out that that:
>>>>>
>>>>>
>>>>>
>>>>>       On receiving a ... message, a router MUST first check if the
>>>>>
>>>>>       message is invalid for processing by this router
>>>>>
>>>>>
>>>>>
>>>>> and then proceed to give a number of conditions that, each, will lead
>>>>> to a rejection of the message as "badly formed and therefore invalid =
for
>>>>> processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. That=
 gave a =E2=80=9Chook=E2=80=9D for
>>>>> RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message g=
eneration.
>>>>>
>>>>>
>>>>>
>>>>> If I was to do RFC7181/RFC6130 today, I would include that directly
>>>>> into the protocol specifications. It turned out to be more overhead (=
and
>>>>> slow down publication anyways) to do it as separate documents.
>>>>>
>>>>>
>>>>>
>>>>> Secondly, we need to be a lot more rigid in terms of what ICVs,
>>>>> Timestamps, etc. are added/removed, and what that brings.
>>>>>
>>>>>
>>>>>
>>>>> For example (with the assumption that messages are *forwarded* and
>>>>> *not* regenerated), this could be one option:
>>>>>
>>>>>
>>>>>
>>>>>                         o          When a RREQ, RREP message is
>>>>> generated, add an ICV Message TLV, which is calculated 
>>>>>
>>>>>                                      =E2=80=A6(take inspiration from =
RFC7183
>>>>> here)
>>>>>
>>>>>
>>>>>
>>>>> ...
>>>>>
>>>>> [Message clipped]
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> ********************************************************************
>>>>> 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
>>>
>>>
>>
>

--001a113db104df789105317f0448
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Apr 27, 2016 at 10:59 PM, Victoria Mercieca &=
lt;vmercieca0@gma=
il.com> wrote:
Just quickly, on this note, if we remove the AckReq from the RREP itse=
lf, then because the RREP is multicast, there might be multiple receivers, =
but there's no way for them to determine if they were the intended next=
 hop, so they would all have to forward the RREP. The RREP might then go by=
 multiple routes to get to RREQ_Gen. This assumes all receivers of the RREP=
 have a route to OrigAddr anyway (current rules say if they didnt, they wou=
ld send a RERR back to RREP_Gen).

So, do we have to inst=
all a route to the neighbour, then unicast the RREP and create a separate m=
essage with an AckReq, then if no acknowledgement is received, blacklist th=
e neighbor and remove the route to the neighbor? along with the route to Or=
igAddr which is not available because the link is not bidirectional...?

My opinion is, if we have a neighb=
or address and the interface through which the neighbor can be (possibly) r=
eached, then we can send an unicast to it.=C2=A0
The others are m=
ore implementation details: for example, if a route to the neighbor is requ=
ired, we can setup a temporary route entry to the neighbor, and remove it a=
fter the unicast is finished. As it's more implementation, I don't =
think it's necessary to go to the specification.=C2=A0

Another related question: when I was reading the specification, a =
router only sets up routes to the source/destination, but not to its direct=
 neighbors?=C2=A0

best

Ji=
azi
=C2=A0
<=
div>

Regards,
Victoria.

On Mon, Apr 25, 2016 at 4:34 PM, Jus=
tin Dean <bebemaster@gmail.com> wrote:
On=
 Mon, Apr 25, 2016 at 11:29 AM, Jiazi YI <ietf@jiaziyi.com> w=
rote:
Hi,=C2=A0

May=
be I missed a bit here:=C2=A0

If only the desired =
receiver of the multicast RREP (carrying a destination address) can reply t=
o the multicast RREP, why not using unicast directly?

<=
/div>
Because the link isn't yet known to be bi-direct=
ional and a unicast route can't be installed yet.

<=
div>Justin
=C2=A0
best

Jiazi
<=
br>
On Mon, Apr 25, 2016 at 4:59 PM, Victoria Mer=
cieca <vmercieca0@gmail.com> wrote:
=

Hi Chris,


On Mon, Apr 25, 2016 at 3:51 PM, Dearlove, Christopher (UK=
) <chris.dearlove@baesystems.com> wrote:











I has to go back to Victoria=E2=80=99s summa=
ry here. It says:


=C2=A0


2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).


=C2=A0


That doesn=E2=80=99t actually indicate if th=
at=E2=80=99s C=E2=80=99s address or B=E2=80=99s address being included. I=
=E2=80=99d assumed it was C=E2=80=99s address. Your comment makes sense if =
it=E2=80=99s B=E2=80=99s address.
 Reading again, I think you=E2=80=99re probably right. But only probably. C=
an we confirm that.


=C2=A0

C creates the RREP. The included AckReq address is=
 B's address. The RREP then gets multicast.
B receives it=
, sees that it own address is marked as the AckReq address, and sends an ac=
k unicast back to C. 
Anyone else who receives the multicast RREP from C=
 does not send the Ack, since the AckReq address does not match any of thei=
r interface addresses.
=C2=A0
<=
span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73=
,125)">


I assume you meant that the RREP (not RREP_A=
ck) is multicast. There=E2=80=99s a bit of a chicken and egg problem here. =
We do know how we want to unicast.
=
=C2=A0
The RREP is multicast (when we dont know if the link is bi=
directional), the RREP_Ack is always unicast. 

Kind regar=
ds,
Vicky.

=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:
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 Intelligence 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: 25 April 2016 15:26

To: Thomas Heide Clausen

Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc =
Networks mailing list; Victoria Mercieca

Subject: Re: [manet] Message integrity and message mutability (was R=
E: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)=



=C2=A0




=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether =
you should click on any links, open any attachments or reply.
For information regarding <=
/span>
Red Flags that you can look out=
 for in emails you receive,
 click 
here.

If you feel the email is su=
spicious, please follow

this process.








The address in the RREP_Ack may be required due to t=
he RREP_Ack being multicast as there is not yet a verified unicast route in=
stalled yet.=C2=A0 Going to double check if I'm remembering correctly.=
=C2=A0



Justin






=C2=A0




On Mon, Apr 25, 2016 at 10:18 AM, <ietf@thomasclausen.org>=
; wrote:




Hi,




=C2=A0






I must admit that while I have reviewed the protocol=
 several times, I=E2=80=99ve not been digging that deep into the protocol f=
unctioning to catch this issue of how invasive the protocol operations are =
when forwarding a message: there were other
 =E2=80=9Cmajor=E2=80=9D issues to address (and which obscured the details)=
, so as a first order: thank you Victoria, for having called attention to t=
his.






=C2=A0






To the substance of these emails.






=C2=A0






I am afraid that I do not understand the use of inse=
rting validity TLVs while in-flight, into a message. Actually, I am dubious=
 for both the originator inserting this (how can the originator of a messag=
e know how =E2=80=9Clatter parts of the path=E2=80=9D
 will be have=E2=80=9D) except if we are talking duty-cycling of devices an=
d inserting =E2=80=9Cthe remaining time that I am going to be up before I s=
uspend=E2=80=9D. Intuitively, that would also assume fairly long duty cycle=
s =E2=80=9CI am up for tens of seconds=E2=80=9D, which I am not sure are
 actually realistic. And, as Chris says in another email, this is trading o=
ff =E2=80=9Cthe ability to do security=E2=80=9D for an unknown/untested fea=
ture =E2=80=94 which I think is the wrong trade-off.






=C2=A0






On he topic of =E2=80=9Cneeding to put an address in=
=E2=80=9D for RREP-ACK, I must admit that this seems roundabout. I can see =
three issues here:






=C2=A0






o I am not sure that adding an address vs. a flag ma=
y not have to do with the =E2=80=9Cmultiple interfaces/






multiple addresses=E2=80=9D discrimination mechanics=
 of the protocol? I haven=E2=80=99t worked it through, though,=C2=A0=







but that would be a guess.






=C2=A0






o The end-to-end topology diffusion mechanism should=
 not need to be concerned with the=C2=A0






=E2=80=9Cbidirectionally check=E2=80=9D of a local l=
ink (in part, as it encumbers security, but not only).=C2=A0 In short, a=







flag or an address, both are (equally) bad.






=C2=A0






o A cleaner mechanism would be a =E2=80=9Chello mech=
anism=E2=80=9D, not necessarily as NHDP, but a =E2=80=9Cwhen=C2=A0






forwarding a RREQ/RREP, trigger a 3-way hello exchan=
ge, if the link is estimated to be of a=C2=A0






type which potentially can be=C2=A0unidirectional=E2=
=80=9D. There is another benefit to doing that, see the end=C2=A0=







of this email.






=C2=A0






Either way, I do not like the notion of fusing metri=
cs-and-link-bidirectionality-detection any more than I like fusing global-t=
opology-diffusion-and-link-bidirectionality-detection.=C2=A0<=
/p>





=C2=A0






The solution all this is, to me, threefold=







=C2=A0






1) Factor out the bidirectionally check in a (trigge=
red) neighbour detection mechanism=C2=A0






(triggered HELLO message)






=C2=A0






2) Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, =
since they add complexity for no perceivable benefits






=C2=A0






3) Use the security model that we=E2=80=99ve discuss=
ed previously, where (only) the metrics change per hop.






=C2=A0






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 related issue, as I hinted previously.





=C2=A0








The abs=
tract states that the protocol:






=
=C2=A0






=C2=A0=C2=A0 ...is intended for use by mobile routers in wireless, mul=
tihop


=C2=A0=C2=A0 networks.




=
=C2=A0






Section=
 5 paragraph 4 =C2=A0of the document, however, reads:<=
/pre>





=
=C2=A0






=C2=A0=C2=A0 Assuming link metrics are symmetric, the cost of the rout=
es installed


=C2=A0=C2=A0 in the Local Route Set at each router will be correct.=C2=
=A0 While this


=C2=A0=C2=A0 assumption is not always correct, calculating incoming/ou=
tgoing


=C2=A0=C2=A0 metric data is outside of scope of this document. =





=C2=A0








I do not know of any wireless systems,=
 where the assumption that =E2=80=9Clink metrics are symmetric=E2=80=9D act=
ually holds. Consequently, the conclusion in the quoted paragraph:






=C2=A0


=C2=A0=C2=A0 calculating incoming/outgoing


=C2=A0=C2=A0 metric data is outside of scope of this document.<=
u>




=C2=A0








Is not an acceptable design choice.





=C2=A0






While this protocol may not want to =E2=80=9Ccalcula=
te if for this link the metrics is 4 or 5=E2=80=9D, the protocol must be ab=
le to convey and distinguish that =E2=80=9Cthe metric from A to B is 4, and=
 the metric from B to A is 19=E2=80=9D.






=C2=A0






This is a =E2=80=9Crelated issue=E2=80=9D since the =
solution may (as with the bi-directionality check) be in the triggered neig=
hbour detection mechanism: that exchange could, if designed carefully, be u=
sed to probe for and convey metrics information, also.






=C2=A0






Hope this helps,






=C2=A0






=C2=A0






Thomas






=C2=A0












On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK)=
 <chr=
is.dearlove@baesystems.com> wrote:




=C2=A0








Assuming for the moment that everyone will n=
eed an RREP-Ack or won=E2=80=99t (let=E2=80=99s come back to that) why do C=
 and B need to put an address in as an RREQ-Ack request?
 Why not a flag, because the address will be included as the IP sending add=
ress - and we know 5444 is required to pass that on. (It=E2=80=99s used by =
NHDP as well.) Then we don=E2=80=99t need to change the RREP, it will have =
a flag set or not, and won=E2=80=99t change (in this regard).=







=C2=A0






Now let=E2=80=99s consider do we know whethe=
r we can set a fixed flag. First I=E2=80=99d say there are two cases - you=
=E2=80=99ve got a firm control on what=E2=80=99s going on in your network,
 or it=E2=80=99s one of unknown parties and behaviour (consistent with spec=
ification). In the former case you only want one setting, for example no-Ac=
k if running NHDP or your MAC layer tells you about bidirectionality, Ack o=
therwise. In the latter case, I think you
 just always want an Ack. So both cases get you to the same place.






=C2=A0






Should that not be an acceptable argument (t=
hough I think it=E2=80=99s good for where we are - in fact always Ack is cl=
ose) then at flag is a step better, it=E2=80=99s a fixed
 location to change. However it would be better in that case if the two thi=
ngs to change (metric and ack flag) were together. But that has its own iss=
ues, so I won=E2=80=99t go there.






=C2=A0




--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44 (0)1245 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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






From:=C2=A0Victoria Mercieca [mailto:vmercieca0@gmail.com]=C2=A0

Sent:=C2=A025 April 2016 14:15

To:=C2=A0Jiazi YI

Cc:=C2=A0Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad=
 Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)






=C2=A0






=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om 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=C2=A0tha=
t
 you can look out for in emails you receive, click=C2=A0here.

If you feel the email is su=
spicious, please follow=C2=A0this
 process.








Hi Jiazi,










=C2=A0








On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <ietf@jiaziyi.com> wrote:








Hi,=C2=A0








=C2=A0








On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christop=
her (UK) <chris.dearlove@baesystems.com&=
gt; wrote:










With regard to your validity time point, we =
here have a tradeoff. If you allow that feature, it significantly impacts o=
n the approach that was coming together
 on as best you can end to end encryption.






=C2=A0






So the question is, is this a feature that=
=E2=80=99s really wanted? Unfortunately I think we know that the answer to =
that is, we don=E2=80=99t know because we don=E2=80=99t have any
 experience. My view would be that in the tradeoff of an untested feature (=
unless I=E2=80=99m wrong about that) and the security complication, securit=
y wins and drop the feature. If there is some real requirement, then there=
=E2=80=99s a discussion. (Questions like how often
 the intermediate routers actually have any knowledge - typically links bre=
ak for unexpected rather than expected reasons. Andan intermediate router c=
ould possibly use a validity time to influence its behaviour.) Note that dr=
opping the ability of intermediate
 routers to modify/set still allows validity times per route to be set at e=
ndpoints.












=C2=A0










I agree with Chris' concern.










The ValidityTime is optional, which makes the integr=
ity protection hard. Furthermore, it gives a potential attack vector: as al=
l the routers in a path will take the shortest validityTime, a compromised =
router can set the the validityTime
 to a very short value, which will make the route installed along the path =
became invalid (very soon).=C2=A0










=C2=A0










On the other hand, I'm not sure this option will=
 give us much help. Chris mentioned much knowledge intermediate router woul=
d have to decide this value (and how much sense the value would make).=C2=
=A0










Another issue is, a route to a destination might be =
updated by different sources. For example, in the network below:<=
/u>










=C2=A0










A-=
---B-----C










=C2=A0










A first establish a route to B with long validity ti=
me. Then A initiates a route discovery to C. C tends to set a short validit=
y time, which will make the route between B and A expire earlier than expec=
ted.=C2=A0










Is this a problem? Maybe yes, maybe no -- I'm no=
t sure it's considered or not.=C2=A0










=C2=A0
















=C2=A0








Not sure I follow here.=







Currently, the validity=
 time of the route between A and B would not affected by a short validity t=
ime of a route between A and C. Validity times are per-route, and the route=
 A-B and the route A-C are separate.








If we switched to a validity time per neighbor (so t=
hat we can keep validity time separate from route advertisements) as I ment=
ioned in the email below, then the validity of a route between A and C woul=
d be affected if there was a short
 validity time between A and B. But, if B will only route for a certain amo=
unt of time, then the route between A and C will of course be affected. Is =
it best to know in advance that there's a time limit, or just deal with=
 RERRs when they happen?








=C2=A0







=C2=A0






















=C2=A0






With regard to the acknowledgements, the pro=
blem (with regard to security) comes from trying to do two jobs with the sa=
me message - end to end route advertisement
 and hop by hop acknowledgement. I understand the reasons - saving bytes an=
d message types. (I would have to study the protocol really hard to identif=
y if any message types can be folded together and recognised by content rat=
her than type efficiently. This
 I do not expect to do.) Again a tradeoff. This one is in discussion space,=
 though that needs people who understand both sides of the issue, including=
 the details of the bidirectionality mechanism. Of course, as has been said=
, we need one of those.














=C2=A0










I haven't finished my review of the latest draft=
, and I don't get the necessity of AckReq and the corresponding multica=
st RREP yet.=C2=A0










If possible, this "optional" field should =
be avoided.=C2=A0










=C2=A0


















To give an overview of AckReq and RREP:






Since AODVv2 requires b=
idirectional links, this is the way to determine if a link is bidirectional=
.








A----B----C












1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install a=
 route to OrigAddr but they dont yet know if it's valid because they do=
nt know if the link to their next hop is available in the reverse direction=
.










2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).










3) B receives the RREP, installs a route to TargAddr=
 and marks it as valid, since it knows the link to C is bidirectional, beca=
use the RREQ went in one direction and the RREP came in the other. B also s=
ends the RREP_Ack to C and forwards
 the RREP to A (and might change the message to indicate its own AckReq - i=
e that it requires an ack from A).










4) C receives the RREP_Ack from B, and therefore kno=
ws that B received the RREP, therefore the link is bidirectional. C can the=
n mark its route to OrigAddr as valid.










5) Similarly, A receives the RREP, installs the rout=
e to TargAddr and sends an RREP_Ack to B.










6) B receives the RREP_Ack and marks its route to Or=
igAddr as valid.










=C2=A0








Alternatively, in step =
2, if C knows the link to B is bidirectional (perhaps from some earlier rou=
te discovery), it doesnt need to put the AckReq in the RREP. Then in step 3=
, since B doesnt know if the link
 to A is bidirectional, it changes the message to add the AckReq address, i=
n order to get an RREP_Ack from A.






If we want to avoid cha=
nging the message, we'll need to look at forwarding the RREP as-is, and=
 creating a second message to solicit an RREP_Ack, in order to verify that =
the link is bidirectional before marking
 the route to OrigAddr as valid.=C2=A0








Kind regards,










Victoria.








=C2=A0







=C2=A0


















regards










=C2=A0










Jiazi










=C2=A0














=C2=A0




--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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






From:=C2=A0Victoria Mercieca [mailto=
:vmercieca0@gmail.com]=C2=A0

Sent:=C2=A023 April 2016 10:55

To:=C2=A0Christopher Dearlove

Cc:=C2=A0ietf@thomasclausen.org; Dearlove, =
Christopher (UK); Mobile Ad Hoc Networks mailing list<=
/p>











Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=C2=A0






=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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.










Hi Chris,








=C2=A0










These have both been in the draft in some form since=
 before I got involved... but I'll do my best to explain.=









=C2=A0










- For Validity Time, its a way to advertise that you=
 would only support the route contained in the message for a certain period=
 of time. The originator might use this, but the draft was written to allow=
 any intermediate node to be able
 to add it or update it too. The route created in the Local Route Set has a=
n expiration time associated with it, based on the received validity time.<=
u>










- For the AckReq address, its so that you can add in=
to a RREP a request for an acknowledgement, so that you don't have to h=
ave a different message type altogether for working out whether links to ne=
ighbors are bidirectional, and also, since
 you only care about bidirectionality on routes that are being set up, you =
dont need to constantly monitor all neighbors.










=C2=A0










=C2=A0










In order to avoid the potential AckReq-related chang=
es to each message, maybe we do need to introduce a different message speci=
fically for this. We could maybe use RREP_Ack to both request and acknowled=
ge? It means an extra message of control
 traffic that needs to be sent, maybe one extra message per hop on the path=
 of a RREP, but it could still be limited to neighbors which have participa=
ted in the route discovery rather than monitoring all neighbors at all time=
s.=C2=A0










=C2=A0










This message could maybe also include "I'm =
happy to route anywhere for a certain amount of time", sort of like wi=
llingness in OLSR/OLSRv2. So instead of having a validity time per route, i=
ts a validity time per neighbor. Then, for RREQ
 and RREP, only the metric value would change in transit, as discussed. How=
ever, that leads to some issues with deciding what a route's expiration=
 time is. You might know how long the next hop router is valid for, but wha=
t if a router beyond that, which was
 also part of the route, had a lower validity time? You couldn't determ=
ine the real validity time. Do we remove the route expiration time altogeth=
er to avoid this issue? In which case, we would have to rely on RERR messag=
es being sent for routes which become
 invalid when the neighbor's validity time has expired? So neighbor val=
idity time expiration is treated the same as a link break.









=C2=A0










What do you think?










=C2=A0










Kind regards,










Victoria.










=C2=A0










=C2=A0










=C2=A0










=C2=A0










=C2=A0












=C2=A0








On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlov=
e <chris@mnemosyne.demon.co.uk> wrote:<=
u>










Pretty much all of the discussion has been assuming =
only a metric value change. With multiple things changing many of the ideas=
 go out of the window. That reinforces the point about not making specifica=
tions now that might turn out to be
 wrong for ICVs.










=C2=A0










Ignoring how this misunderstanding happened, I'l=
l start by asking why. Metric changing I understand. Why the other two? (th=
ere's a partial explanation of one). What alternatives have people impl=
emented in comparable protocols?



-- =C2=A0








Christopher Dearlove














On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmai=
l.com> wrote:


















Hi all,










=C2=A0










Continued in this thread because the other one seems=
 to be more about TLV types and metric type numbers, whereas this is about =
regeneration/forwarding.










=C2=A0










To recap, in the current draft, there are 3 things t=
hat might change at each hop:=C2=A0

- the metric value (happens in RREQ and RREP),=C2=A0

- adding/changing Validity Time using the Validity Time TLV (can happen in =
RREQ and RREP),=C2=A0

- adding an address (and corresponding value in the AddressType TLV to indi=
cate how to interpret the address) to indicate the address from which an RR=
EP_Ack is expected, to accomplish the bidirectionality check (can happen in=
 RREP).



If we define=C2=A0a certain portion of the message as immutable and include=
 the ICV to verify that part, end to end:=C2=A0

- The metric value would be excluded from the ICV since it needs changing a=
t each hop.=C2=A0

- Would adding a Validity Time TLV at an intermediate hop be acceptable? Th=
e whole TLV could be removed in order to calculate the ICV?







- Would adding an address cause issues for the ICV, =
because it's in the address block? Could the rule be "if it contai=
ns an AckReq address, remove it (and the corresponding value in the Address=
Type TLV), before checking the ICV", is that
 OK? Or would we need to avoid touching the ICV'ed part of the message =
altogether, maybe put the AckReq address in a separate Address Block, with =
an extra AddressType TLV following that address block? Is there a way to ac=
complish this?










=C2=A0










Also, to be thorough, do we need to consider RERR me=
ssages while we discuss regeneration vs forwarding?=C2=A0










- RERR (sent when a link breaks) is a way of saying =
"I've lost my route so I'm telling others" and "you =
were my next hop, so=C2=A0now=C2=A0I've also lost my route, I'll te=
ll others", etc. It's going to be tailored at each step to include=
 the relevant
 routes that got deleted, it's not one message being sent end-to-end li=
ke RREQ and RREP are.=C2=A0










- However, RERR (sent when a source of traffic is se=
nding data on a route which comes through you, and you want to tell the Pac=
ket Source's router to delete the route) could be seen as an end-to-end=
 message which all intermediate routers
 learn from, similar to RREQ and RREP. It reports one route, and doesn'=
t need changing at intermediate hops, so could be protected with ICV.










- Would it be OK to only require a message ICV if a =
PktSource address was included, i.e. when the message needs to go via a num=
ber of intermediate hops to PktSource's router? All other RERRs are int=
ended to be one-hop messages, which may
 in turn prompt other one-hop messages, etc..., and a packet ICV might be m=
ore appropriate?










=C2=A0








Kind regards,








Victoria.










=C2=A0








On Thu, Mar 17, 2016 at 5:26 PM, <i=
etf@thomasclausen.org> wrote:








=C2=A0












On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:








=C2=A0












Yes, I meant AODVv2, thanks for the catch.










=C2=A0










So is your (Thomas) proposed base specificat=
ion a hop count only metric?
















=C2=A0








No, the would be silly as base specification, given =
that hop count mostly is useless.










=C2=A0










As base specification I would simply say =E2=80=9CIn=
clude a Metric Type Message TLV with a value field, and a 7182 Message TLV =
& Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage =
as to generation and processing).=C2=A0










=C2=A0










With the message generated by the originator of the =
RREQ/RREP and *not* deconstructed/reconstructed/reordered (as is the risk w=
ith =E2=80=9Cregeneration) allows knowing that it would be *only* that metr=
ic field being modified (other than hop count/limit)
 for when eventually writing up the extension.










=C2=A0
















(Actually doesn=E2=80=99t the current specif=
ication only define hop count, or has that changed in latest draft?)=















=C2=A0








No. That is one of the issues I raise in my original=
. For some reason, it cites RFC6551, which is a ROLL document and which has=
 in its abstract that:










=C2=A0








=C2=A0=C2=A0 Low-Power and Lossy Networks (LLNs) have unique character=
istics


=C2=A0=C2=A0 compared with traditional wired and ad hoc networks that =
require the


=C2=A0=C2=A0 specification of new routing metrics and constraints. =







=C2=A0










I.e. this document cites a metric document which cle=
arly claims to be inapplicable in ad hoc networks. I note that this is anot=
her thing I=E2=80=99ve raised for years without seeing it attempted resolve=
d.










=C2=A0










Best,










=C2=A0










Thomas










=C2=A0










=C2=A0














=C2=A0








--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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














From:=C2=A0ietf@thomas=
clausen.org=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 17:10

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Lotte Steenbrink; Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=C2=A0








=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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=A0
















On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:












=C2=A0














OK, so we have a message that mutates by:














- Modifying hop count/limit.














- Modifying a metric value.=















Anything else?














=C2=A0














As mutating (other than hop count/limit) mes=
sages aren=E2=80=99t covered by 5444 or any derivative document (but only r=
ecommended against, not banned) that you may
 need to make the message otherwise immutable (no deconstruction and rebuil=
ding, other than guaranteed unchanging) that would have to be specified by =
AODVv2. (Easy to say, but needs saying.)


















=C2=A0












With you so far.












=C2=A0









Then that information is not in a guaranteed=
 fixed location given by a simple offset. So any signature algorithm that f=
inds it and ignores it or aggregates
 on it is specific to OLSRv2.














=C2=A0












Surely you mean AODVv2












=C2=A0









So standard 7182 ICVs don=E2=80=99t do the j=
ob, you would need an AODVv2 specialised variant. Which is the sort of thin=
g that the message specific TLV space is there
 for, I=E2=80=99d be strongly against a =E2=80=9Cbut ignore the value of th=
is specific TLV should it occur=E2=80=9D being in the general space. Howeve=
r it can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like =
that TLV, except if an X TLV is present, set its value field to
 zero=E2=80=9D).














=C2=A0














Messy, but could work.<=
/p>













=C2=A0












Not that messy, actually, although clearly not as ni=
ce as =E2=80=9Cfixed offset=E2=80=9D.














=C2=A0














That said, I am arguing for the base spec being:<=
/u>














=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=E2=80=9Cmake the message otherwise immutable (no deco=
nstruction and rebuilding, other=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=A0than guaranteed unchanging)=E2=80=9D which is af=
forded by forwarding














=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7182 Timestamps and ICVs.














=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7183 style text bringing it all together.=















=C2=A0














The =E2=80=9Caggregated signatures around mutable fi=
eld=E2=80=9D would very be an experimental extension.














=C2=A0














What I object to is, if the base spec specifically r=
enders such extensions impossible














=C2=A0












=C2=A0









=C2=A0










--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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


















From:=C2=A0Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]=C2=A0

Sent:=C2=A017 March 2016 16:48

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0ietf@thomasclausen.org; Mobile Ad =
Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)


















=C2=A0










=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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.












Hi all,
















=C2=A0




















Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher=
 (UK) <chris.dearlove@baesystems.com>=
:
















=C2=A0


















Good point about whether you just pass on on=
e cost or a set of costs. As I said, not looked at details - I will, when t=
ime permits. One cost is much easier,
 and yes, it reduces the fixed size aggregated signatures problem to =E2=80=
=9Cjust=E2=80=9D one of computational load.






















=C2=A0


















For the record, Thomas=E2=80=99 understanding is cor=
rect; the cost is one aggregated value.=C2=A0


















=C2=A0


















Best regards,=C2=A0


















Lotte Steenrbink














=C2=A0















=C2=A0












--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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






















From:=C2=A0ietf@thomas=
clausen.org=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 16:38

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: Message integrity and message mutability (was RE: =
[manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)






















=C2=A0












=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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=A0
























On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:




















=C2=A0






















I appreciate Thomas=E2=80=99s comments about=
 the limitations of message regeneration, but I would be a bit less absolut=
e.






















=C2=A0






















The issues over end to end authentication an=
d more advanced signatures are valid. I need to read the given reference on=
 aggregate signatures to increase my
 knowledge (thanks for it), but my understanding of the possibilities in th=
is field may offer a solution to the problem, but with some other issues (p=
ossibly including a new type of TLV).






















=C2=A0






















But the hop count/limit point I don=E2=80=99=
t fully agree with, you can regenerate with an incremented/decremented coun=
t/limit, which leaves the ability to prevent
 messages propagating indefinitely, including expanding ring searches, and =
retains the ability to use RFC 5497 interval and validity times that might =
be useful with an expanding ring search (or might not).






















=C2=A0






















But the key issue is that AODVv2 wants to ac=
cumulate metrics. I still haven=E2=80=99t got to the bottom of many details=
 here, but let=E2=80=99s for the moment just consider
 that conceptually.






















=C2=A0






















It=E2=80=99s hard to handle end to end. Char=
lie=E2=80=99s draft attempts to do an end to end of some information, not t=
his information. I=E2=80=99m not sure if that=E2=80=99s useful (and the
 specialised format is better avoided if possible). Other approaches are ho=
p by hop (might as well use packet signatures) and shared key (might as wel=
l go hop by hop). Pairwise signatures for each pair of routers I=E2=80=99m =
discounting as scaling terribly. In the
 interests of completeness let=E2=80=99s mention not accumulating metrics, =
which puts us back to hop count and that=E2=80=99s not ideal either.=























=C2=A0






















I don=E2=80=99t think there is an ideal solu=
tion. (I like ideas I=E2=80=99ve seen about aggregating, but that has some =
issues of its own, even apart from computational load.)
 I=E2=80=99d love to be proved wrong - someone with the perfect solution to=
 come along.






















=C2=A0






















Which means that either we make an arbitrary=
 choice - which will be disagreed with, but needs discussing first - or cre=
ate something flexible. Unfortunately
 flexible in that regard constrains in others, e.g. some (many? most?) aggr=
egating signatures need fixed data sizes (which we can do by defining a TLV=
 that =E2=80=9Cfills up=E2=80=9D with hop count, but that has a cost too).<=
/span>


























=C2=A0




















I have been told by people much more well versed in =
this than I in cryptology, that the correct answer is =E2=80=9Csome=E2=80=
=9D.






















=C2=A0






















That said, "AODVv2 wants to accumulate metrics=
=E2=80=9D =E2=80=94 does that mean that the message grows as it is being fo=
rwarded, and that the recipient of a RREQ/RREP will know the individual cos=
ts of each path segment? My understanding is, that the recipient
 will get =E2=80=9Cthe sum the costs of each path segment=E2=80=9D which sh=
ould be fitting within a fixed size?






















=C2=A0






















Thomas






















=C2=A0




















=C2=A0



















=C2=A0






















Sorry, no answers, just comments. And I=E2=
=80=99m not addressing Thomas=E2=80=99s later points here.=























=C2=A0














--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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


























From:=C2=A0manet [mail=
to:manet-bounces@ietf.org]=C2=A0On
 Behalf Of=C2=A0ietf@thomasclausen.org

Sent:=C2=A017 March 2016 16:00

To:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0[manet] draft-ietf-manet-aodvv2-13 review - a couple o=
f big ticket Items


























=C2=A0














=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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***

EXTERNAL=
 EMAIL -- This message originates from outside our organization.<=
/u>














=C2=A0
























Dear all,
























=C2=A0


























Apologies for not having gotten this done sooner - d=
ay-job leaving few spare cycles.


























=C2=A0


























I=E2=80=99ve previously offered reviews and comments=
, and some of those have been addressed in the latest I-D =E2=80=94 others =
have not, but should be. I recall that there was some mail attempting to re=
but parts of the review, and I will dig it out and
 reply to that.


























=C2=A0


























With that being said, I have reviewed the latest ver=
sion of the document, and full details will be forthcoming. There=E2=80=99r=
e a couple of big-ticket/architectural items that I want to address up fron=
t, as I believe that before we have those
 hammered out, it will be useless to go into details. Note, I do not claim =
that this is an exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D, but =
that=E2=80=99s as far as I have gotten in thinking this through.<=
/u>


























=C2=A0


























I also bring these up as they are items that have be=
en brought up repeatedly over the past years, but not resolved nor discusse=
d.


























=C2=A0


























Loops


























Just to bring this out: I share Chris=E2=80=99 worry=
 about conflicting and concurrent statements from the authors on =E2=80=9CT=
here are no loops possible=E2=80=9D and =E2=80=9CWe need to fix two situati=
ons where loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating =
some loop
 conditions=E2=80=9D


























=C2=A0


























I particularly worry that this is not a discussion h=
ad in public, but apparently in some other forum=E2=80=A6


























=C2=A0


























=C2=A0




























Intermediate Route Replies, and all of section=
 10


























Section 10 contains a set of =E2=80=9Cvaguely specif=
ied extensions=E2=80=9D, which is incoherent with the intended status indic=
ated for this document.=C2=A0


























=C2=A0


























Specifically, and this is not unrelated to the point=
 about loops above, intermediate RREPs (section 10.3) are a potential sourc=
e for loops.


























=C2=A0


























Expanding Ring Multicast (section 10.1) is not docum=
ented in a way that can be implemented (and also, see =E2=80=9CForwarding-v=
s-regeneration=E2=80=9D below, it is in the present form of this protocol i=
mpossible), etc.




























=C2=A0


























=C2=A0


























Forwarding-vs-regeneration


























Recent exchanges on the list made me understand that=
 protocol control messages are *not* forwarded, but are consumed at each ho=
p, then a new message with (almost-but-not-quite) the same content is gener=
ated and transmitted.


























=C2=A0


























I have thought some more on this (& read some of=
 the exchanges on the list on this topic by Chris, Ulrich, and others), and=
 I am convinced that this is not the right way to go,=C2=A0at least=
=C2=A0for the following reasons:


























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It renders the hop-limit/hop-count fields in the RFC5444 messag=
e header useless.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0This would not be bad if the functionality offered by tho=
se fields was not useful


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=94 sadly, it is. For example, for scope limited fl=
ooding (expanding ring search, and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0such) which may be of interest, and which require hop-lim=
it.=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0A hop-count field may also provide a =E2=80=9Ccheap=E2=80=
=9D (in terms of overhead) additional piece


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of information to use conjunctively with a =E2=80=9Creal=
=E2=80=9D metric.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The only practical solution would be to re-introduce thes=
e functions by way of inserting a


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0MessageTLV =E2=80=94 which (i) is not specified in this d=
ocument, and (ii) which would just


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0serve to render messages bigger than strictly needed.<=
/u>


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Scope limited flooding =C2=A0does seem to be a necessary =
requirement, if for no


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0other reason than to prevent information from =E2=80=9Cci=
rculating forever in the network=E2=80=9D.


























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It makes end-to-end authentication unnecessarily hard.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I think Chris called this out already, but it bears repea=
ting: S generates a message=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(say, a RREQ), and includes an ICV calculated over the co=
ntent of the message.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0For any recipient to be able to validate the ICV, the mes=
sage has to be exactly


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0the same =E2=80=94 not just in content, but in structure =
=E2=80=94 as what was generated.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforwa=
rding=E2=80=9D messages means, that the intermediate


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose =
a different structure (e.g., include TLVs


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0in a different order).


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The proposal from=C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00=



























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0is to add constraints on (i) the set of elements to inclu=
de in a signature and (ii) the


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0order of these elements.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0One=C2=A0problem with that approach is (i): if an extensi=
on adds a message TLV, or an=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Address TLV, to a message, then that will not be =E2=80=
=9Ccovered=E2=80=9D by the proposed e2esec TLV.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Rather for *each* extension developed, an =E2=80=9Cupdate=
s e2esec=E2=80=9D clause needs to be done.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I=E2=80=99d say that this approach would be prone to erro=
rs =E2=80=94 and add entropy to the process


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of designing protocol extensions. The alternative, a mess=
age being generated by the


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0source and *forwarded* (as we do in OLSRv2, for example) =
would allow ICV TLVs=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(even, allow reuse of those specified for OLSRv2) for cov=
ering a message and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0extensions.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CBut what about the metrics value which will chan=
ge on each hop=E2=80=9D, you may say?


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Fortunately, that is relatively easy to handle: simply ze=
ro out the value of that TLV when


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0generating or verifying the ICV MessageTLV. And use Packe=
t-TLVs for hop-by-hop=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0authentication, if needed (but, see below).=



























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It prevents the use of more clever/advanced signature scheme=
s/ICVs


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Aggregate signature algorithms (=C2=A0https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf<=
/span>)


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0exist, and an interesting use-case can be found in also r=
eactive protocols, allowing verifying


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0not =E2=80=9Cjust=E2=80=9D the end points, but also the i=
ntermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0discussed above, or something smarter).


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Regeneration of messages, rather than forwarding, renders=
 that impossible (or, if used,


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0updating to =C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)


























=C2=A0


























There are other reasons, but the above are those tha=
t jump at me as immediate show-stoppers.


























=C2=A0


























I do honestly not see what possible benefit there is=
 from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inconve=
niences, and security is not the least of these. Insisting on =E2=80=9Crege=
neration=E2=80=9D requires development of =E2=80=9Cnon-general workarounds=
=E2=80=9D as pointed
 out above.


























=C2=A0


























Security Considerations<=
/p>

























This is an always thorny subject. When OLSRv2 was go=
ing through the process we got a thorough education in how little we knew a=
bout security from the SEC-ADs, and had to spend about a year or so develop=
ing RFC7183. The bottom line is, that
 this protocol needs its =E2=80=9CRFC7183 =C2=A0equivalent=E2=80=9D, either=
 as part of the main document, or as an independent document. currently, th=
at is not the case.


























=C2=A0


























A minima, looking at BCP72 and BCP107 =E2=80=94 taki=
ng inspiration from RFC7183 might be aw good idea, as that was the most rec=
ent that went through the SEC AD. Regardless of how, however, a =E2=80=9Cma=
ndatory to implement=E2=80=9D security mechanism most be specified
 (I think the right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D),=
 in sufficient detail to ensure interoperable implementations.


























=C2=A0


























As an example, both [RFC6130] and [RFC7181] set out =
that that:




























=C2=A0


























=C2=A0 =C2=A0 =C2=A0 On receiving a ... message, a r=
outer MUST first check if the


























=C2=A0 =C2=A0 =C2=A0 message is invalid for processi=
ng by this router


























=C2=A0


























and then proceed to give a number of conditions that=
, each, will lead to a rejection of the message as "badly formed and t=
herefore invalid for processing=E2=80=9D =E2=80=94 a list which RFC7183 the=
n amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting
 =E2=80=9Crejection=E2=80=9D. Idem for message generation.

























=C2=A0


























If I was to do RFC7181/RFC6130 today, I would includ=
e that directly into the protocol specifications. It turned out to be more =
overhead (and slow down publication anyways) to do it as separate documents=
.




























=C2=A0


























Secondly, we need to be a lot more rigid in terms of=
 what ICVs, Timestamps, etc. are added/removed, and what that brings.


























=C2=A0


























For example (with the assumption that messages are *=
forwarded* and *not* regenerated), this could be one option:<=
/p>

























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0When a RREQ, RREP message is generated, add an ICV Message TLV, which=
 is calculated <this way>


























=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=E2=80=A6(take inspiration from RFC7183 here)


























=C2=A0


































...



[Message clipped]=C2=A0=C2=A0

_______________________________________________

manet mailing list

manet@ietf.org

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/manet






=C2=A0
















_______________________________________________

manet mailing list

manet@ietf.org

<=
span style=3D"color:purple">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 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

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/manet








=C2=A0














=C2=A0










_______________________________________________

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




=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










--001a113db104df789105317f0448--


From nobody Wed Apr 27 15:43: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 52C5D12D104 for ; Wed, 27 Apr 2016 15:43: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=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 iFO0yzE_oddG for ; Wed, 27 Apr 2016 15:43:28 -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 1D48B12B048 for ; Wed, 27 Apr 2016 15:43:28 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id j11so74295555lfb.1 for ; Wed, 27 Apr 2016 15:43:28 -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=+zK2RRTHKN6Em4DF5lTLQWvZ/tk+fjFRjw+A/nZXvEM=; b=XZdxRNlWUssbaz0vOB6bImzhiX9wrOrJMs1SeBukmBWnc3zjFeu4Pa2SesHfrekxWt JZEV1hFOCot8AtHGvrhwlH8Xg4J09xO1pFiM7oqYLIwoueS6HxwVlUXVz422NYaxQHse x4C6rrvRjysw4MqT6Vk8Pyp9/ia/X/+6DedtfJdt75WO63bvE2Gp+v+cOtH8Qx0rARqI RCCi08lW+TIuiX+bY6omhVhHF/L5nXgvvKjBLKZGM/BWJyxppf/7Mx7kO9d/ZVuMm3AM 9Ge8QN86HQ0AISdyAfoJzrdfUvlnp7j5D7MxRmLrKRsiODZt4Uzhpwmc4B4J/yFS7eMP RkvQ==
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=+zK2RRTHKN6Em4DF5lTLQWvZ/tk+fjFRjw+A/nZXvEM=; b=IrXzfAOYRIB3WKLIreLXJeNz+NTHElwZIVBLoACmo+QD0aStNZr9/sT2Gao0gXWqMy edbE/ST9cU6mZuhdWDLtIXjNpKWM4E03N7vwpM0a9FRzQTfiDoOmU3HQB8nz34zurEz4 OMibOws2qYBkYtgRUlNciWXMrha3QUc8nLIwMr8g/hXicsCQsMTalJKQb4+8hnJPpMfL Vq33Q2jvKPPsHQ3TeHvCJtd4lfRUDiu79ylPbvKJ9BIi966cooFfTDM5LC8cfIOrI4hx iNbnrphuQ7G1yxR8NR498+nbL0ilETwuD1Jq/6QFtX0ExOr61HHaDpBfDJrXclaZaOIK 91ww==
X-Gm-Message-State: AOPr4FVHqdMeospsFkOyxpVCm4fCJnT3kdD3gkyOp02ZC830jIlYzjyMHq4czSqxENgLsIGjCtEdg5qG3KoltQ==
MIME-Version: 1.0
X-Received: by 10.25.20.155 with SMTP id 27mr3835332lfu.90.1461797006118; Wed, 27 Apr 2016 15:43:26 -0700 (PDT)
Sender: yi.jiazi@gmail.com
Received: by 10.114.77.4 with HTTP; Wed, 27 Apr 2016 15:43:25 -0700 (PDT)
In-Reply-To: <144C7397-F19E-4FB0-959A-B5A030BD7A8A@fu-berlin.de>
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org>      <60BD2E9C-64D7-4444-B3A9-8D207EB4A86F@gmail.com> <144C7397-F19E-4FB0-959A-B5A030BD7A8A@fu-berlin.de>
Date: Thu, 28 Apr 2016 00:43:25 +0200
X-Google-Sender-Auth: 8s3fKMRHYVaWXOYLHaXHETz7M7U
Message-ID: 
From: Jiazi YI 
To: Lotte Steenbrink 
Content-Type: multipart/alternative; boundary=001a113f1fe4489d6005317f2399
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 27 Apr 2016 22:43:32 -0000

--001a113f1fe4489d6005317f2399
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 28, 2016 at 12:19 AM, Lotte Steenbrink <
lotte.steenbrink@fu-berlin.de> wrote:

>
> Am 28.04.2016 um 00:16 schrieb Christopher Dearlove <
> christopher.dearlove@gmail.com>:
>
> The more you have to zero out, the messier it gets, and the less secure i=
t
> gets (more things can be spoofed). I think that's about all I've got to a=
dd.
>
>
> Of course. My question was just:
> * Do we want to come up with an exact description of how the zeroing out
> should work now, with the short time we have left?
>

If a meaningful security mechanism is required, yes.
I think the first thing to do is to cut as many mutable fields and optional
fields as possible.

best

Jiazi


> or
> * Do we mention in the draft that zeroing out has to happen somehow and
> leave the nitty gritty to future work?
>
> At least that=E2=80=99s how I understood the options you laid out...
>
> --
> Christopher Dearlove
> christopher.dearlove@gmail.com (iPhone)
> chris@mnemosyne.demon.co.uk (home)
>
>
>
> --
> Christopher Dearlove
> christopher.dearlove@gmail.com (iPhone)
> chris@mnemosyne.demon.co.uk (home)
> On 27 Apr 2016, at 22:46, Lotte Steenbrink 
> wrote:
>
> Hi all,
> I=E2=80=99m currently revising the security considerations with regards t=
o the
> move from regeneration to forwarding, which depends on a decision being
> made on how/where we want to mention the possibility of zeroing out TLVs =
to
> calculate the ICV for the rest of a message=E2=80=99s contents (see secon=
d * of my
> last e-mail). I=E2=80=99ve not found a decision on this in other thread (=
please
> pardon me if I overlooked something), so I=E2=80=99ll bump this thread an=
d ask the
> WG for its opinions. (again, personally, the 2nd option outlined by
> Christopher seems more appealing to me)
>
> Regards,
> Lotte
>
> Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink <
> lotte.steenbrink@fu-berlin.de>:
>
> Hi all,
> to summarize:
>
> * AODVv2 message Type numbers should be in the Experimental type space an=
d
> the AODVv2 TLV Types should be message type-specific. This also means
> changing the text regarding IANA actions and changing the text regarding
> what the experiment is to something along the lines of =E2=80=9Cwe want t=
o gather
> experience on how to make generic metric TLVs and ICVs that work with
> changing metric TV values happen with reactive protocols=E2=80=9D
> * we=E2=80=99re undecided on (to quote Christopher) the "here's a mechani=
sm we
> haven't really thought through in detail, but at least we've defined one"=
,
> or "we know the sort of thing we want, and we'll describe it, but rather
> than produce something not quite right, we'll not go further=E2=80=9C dec=
ision on
> temporarily setting the metric value to 0 (i.e. the who and how).
> (personally, I think I=E2=80=99d prefer the latter approach, but that=E2=
=80=99s an entirely
> gut feeling-based preference)
>
> Did I catch that correctly? If so, I=E2=80=99ll put together and suggest =
some text
> for the first point as soon as I get home and in case there has been a
> decision on the second by then, I=E2=80=99ll try to tackle that one too. =
:)
>
> Best regards, Lotte
>
> Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com>:
>
> I have no problem with that. I was trying to lay out the issues without
> muddying the water with my preference.
>
>
> *--*
>
>
>
>
> *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:* Justin Dean [mailto:bebemaster@gmail.com ]
> *Sent:* 22 April 2016 15:35
> *To:* Dearlove, Christopher (UK)
> *Cc:* Thomas Heide Clausen; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] On Forwarding-and-regeneration (was: Re:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
>
> **** 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
> .*
> Speaking as participant.
>
> I kind of like the idea of using the experimental message type space.  We
> only have a limited amount of these message types.  The TLV assignments
> could just use the message type specific space and there isn't an issue
> there.  IANA wouldn't assign a number but I don't see why the document
> couldn't specify the experimental numbers it was going to use so other
> future near term experiential protocols could do the same and generally
> avoid conflict.  If the experiment is successful IANA assignments could b=
e
> made.  Functionally no real difference with protections vs long term usag=
e
> of limited space.
>
> Justin
>
> On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
> There's rather a contradiction between the concepts of a definition of a
> protocol, even Experimental, and experimental space, which usually assume=
s
> that the user can do what he or she likes in it.
>
> But chewing up messages types (how many, 3?) of which there are relativel=
y
> few for experimental is long term a problem, although short term not.
>
> TLV space is easier in two regards. It's bigger (though the prime real
> estate of type extension zero isn't) and can have message type specific
> TLVs.
>
> So TLVS can actually be invisible, if that option is chosen. For messages
> something has to give. Least bad option is again one of those we should
> discuss, but time ...
>
> (To be precise, messages types from 224 are defined in RFC 5444 as "
> Experimental Use", of which BCP 26 says "Similar to private or local use
> only, with the  purpose being to facilitate experimentation." The
> alternative 0-223 space is Expert Review. IANA still thinks the experts a=
re
> Joe Macker and the recused Stan Ratliff. But that's a soluble nit.)
>
> --
> 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
>
>
> -----Original Message-----
> From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org]
> Sent: 22 April 2016 14:21
> To: Dearlove, Christopher (UK)
> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>
> ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner
> or from the internet.
> Consider carefully whether you should click on any links, open any
> attachments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters for instructions
> on reporting suspicious email messages.
> --------------------------------------------------------
>
>
> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com> wrote:
> >
> > Once you're entirely in AODV2's own space, and AODVv2 is experimental
> (working assumption for this discussion) you have more liberty.
> >
>
> Yep.
>
> Taken somewhat by surprise both by the sudden "rush" and the experimental
> maturity level, I am wondering (and haven't thought through) about
> experimental space vs non-experimental (for message types, and consequent=
ly
> for message type specific TLV types).
>
> I think that if the AODVv2 experiment specifies the use of Message types
> from the Experimental message type space without making actual
> registrations in the IANA registry, AND the use of type specific TLV type=
s,
> this becomes a non-issue entirely (by design, this is precisely what that
> experimental space is for)
>
> Whereas, as you point out, the alternative is a "can open - worms
> everywhere" situation that I think time is too short to solve?
>
> Thomas
>
>
> > Then you could try specifying it. But with a very good chance of
> producing something you later decide you should have done differently.
> >
> > I honestly don't know which would go down better (or less badly) -
> "here's a mechanism we haven't really thought through in detail, but at
> least we've defined one", or "we know the sort of thing we want, and we'l=
l
> describe it, but rather than produce something not quite right, we'll not
> go further".
> >
> > --
> > 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
> >
> >
> > -----Original Message-----
> > From: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]
> > Sent: 22 April 2016 13:59
> > To: Mobile Ad Hoc Networks mailing list
> > Cc: Henning Rogge; Dearlove, Christopher (UK)
> > Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
> >
> > ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner
> or from the internet.
> > Consider carefully whether you should click on any links, open any
> attachments or reply.
> > Follow the 'Report Suspicious Emails' link on IT matters for
> instructions on reporting suspicious email messages.
> > --------------------------------------------------------
> >
> > Hello Christopher,
> >
> >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <
> chris.dearlove@baesystems.com>:
> >>
> >> Just be careful to note that this concept is as currently being
> discussed (a) specific to AODVv2, and (b) not an application of 7182, whi=
ch
> has no knowledge of special TLVs.
> >>
> >> This is something we'd want to get right, and need to get right if in
> any space not specific to ADODVv2, because getting it wrong produces futu=
re
> problems.
> >
> > Makes sense.
> >
> >> I can see some possible approaches, none is ideal and we're rather out
> >> of time to specify. But this is experimental, so I think we might be
> >> able to indicate the shape of the solution without specifying it,
> >> which would be a different RFC, under a bit less time pressure.
> >> (Extensions to existing protocols like 7182 would naturally be in
> >> scope rechartered I think.)
> >>
> >> To indicate the range that's open, here are two possible ideas, one of
> which has an impact now, so needs to be agreed. Note that I'm not
> suggesting (in fact quite the opposite) defining an extension to 7182 her=
e,
> rather enabling such an extension, if written, to "do the right thing".
> >> - We have an extension to 7182 that says "zero out all value octets in
> protocol specific TLVs. That requires now putting the AODVv2 metric TLV i=
n
> that space.
> >
> > Just to make sure that I understood you correctly=E2=80=93 =E2=80=9Ctha=
t space=E2=80=9D meaning
> making the AODVv2 metric TLV protocol specific? (By =E2=80=9Cthe aodvv2 m=
etric tlv=E2=80=9D
> I=E2=80=99m referring to the generic TLV we=E2=80=99ve been talking about=
 on this list
> earlier this week).
> >
> >> - We have an extension to 7182 that adds extra material to the value
> field that indicates (TBD how, by position with sanity check that this is
> TLV value perhaps?) which octets are to be zeroed out before the ICV is
> calculated.
> >
> > The way I understand that approach, it wouldn=E2=80=99t warrant any act=
ion from
> AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set the Metric v=
alue to
> zero=E2=80=9D (leaving the nitty gritty of how this would be done in deta=
il to
> future work)=E2=80=A6 Is that correct?
> >
> >>
> >> We do not have the time to specify this in an acceptable manner within
> two weeks though. But the security consideration section could say
> something along the lines of "this enables the use of an ICV defined to
> zero out these octets=E2=80=9C.
> >
> > Okay. :)
> >
> > Best regards,
> > Lotte
> >
> >>
> >> --
> >> 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
> >>
> >> -----Original Message-----
> >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte
> >> Steenbrink
> >> Sent: 22 April 2016 10:28
> >> To: Henning Rogge
> >> Cc: Mobile Ad Hoc Networks mailing list
> >> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
> >> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
> >>
> >> ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner
> or from the internet.
> >> Consider carefully whether you should click on any links, open any
> attachments or reply.
> >> Follow the 'Report Suspicious Emails' link on IT matters for
> instructions on reporting suspicious email messages.
> >> --------------------------------------------------------
> >>
> >> *** WARNING ***
> >> EXTERNAL EMAIL -- This message originates from outside our organizatio=
n.
> >>
> >>
> >> Hi Henning,
> >>
> >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge :
> >>>
> >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
> >>>  wrote:
> >>>> Hi Thomas,
> >>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=
=E2=80=9D language
> >>>> in the first place is that we=E2=80=99ve been told that whenever one=
 bit in
> >>>> the message (apart from its header) is changed, the entire thing has
> to be regenerated.
> >>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been misu=
nderstanding
> >>>> each other for more than a year. :( Anyway, it seems like we=E2=80=
=99re
> >>>> getting close now, so yay.
> >>>
> >>> "Modifying" the binary message instead of parsing and generating a
> >>> new one will be difficult as soon someone writes an extension to
> >>> AODVv2 that adds more TLVs to the message.
> >>
> >> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s =
what you
> explained to me when I got confused about the topic last spring=E2=80=A6 =
But=E2=80=93 even
> if a message contains TLVs that the AODVv2 implementation handling it
> doesn=E2=80=99t understand, it will still be able to recognize the Metric=
 TLV,
> right? Isn=E2=80=99t that the nifty thing about RFC5444? So, while we rea=
lly
> shouldn=E2=80=99t write =E2=80=9Cbefore calculating the ICV, set the n-th=
 4 octets to 0=E2=80=9D,
> we might say =E2=80=9Cidentify the octets that make up the metric value a=
nd set
> those to 0=E2=80=9D?
> >>
> >> Best regards,
> >> Lotte
> >>
> >>> Henning Rogge
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> 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
>
>

--001a113f1fe4489d6005317f2399
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Apr 28, 2016 at 12:19 AM, Lotte Steenbrink &l=
t;lotte.=
steenbrink@fu-berlin.de> wrote:

Am 28.04.2016 um 00:16 schrieb Christopher Dearlove =
<chr=
istopher.dearlove@gmail.com>:

<=
span>
The more you have to zero out, the messier it g=
ets, and the less secure it gets (more things can be spoofed). I think that=
's about all I've got to add.


Of course. My question was just:
* Do we want to come up with an exact description of how the zeroing=
 out should work now, with the short time we have left?

If a meaningful security mechanism is =
required, yes.=C2=A0
I think the first thing to do is to cut as m=
any mutable fields and optional fields as possible.=C2=A0

best

Jiazi
=C2=A0
or=

* Do we mention in the draft that zeroing out has to happen some=
how and leave the nitty gritty to future work?

At =
least that=E2=80=99s how I understood the options you laid out...

--=C2=A0
Christopher Dearlove
<=
br>


-- =C2=A0
Christopher Dearlove
On=
 27 Apr 2016, at 22:46, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> =
wrote:


Hi all,
I=E2=80=99m currently revising the security considerations with=
 regards to the move from regeneration to forwarding, which depends on a de=
cision being made on how/where we want to mention the possibility of zeroin=
g out TLVs to calculate the ICV for the rest of a message=E2=80=99s content=
s (see second * of my last e-mail). I=E2=80=99ve not found a decision on th=
is in other thread (please pardon me if I overlooked something), so I=E2=80=
=99ll bump this thread and ask the WG for its opinions. (again, personally,=
 the 2nd option outlined by Christopher seems more appealing to me)

Regards,
Lotte

Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink <lotte.steenbr=
ink@fu-berlin.de>:

Hi all,
to summarize:

* AODVv2 message Type n=
umbers should be in the Experimental type space and the AODVv2 TLV Types sh=
ould be message type-specific. This also means changing the text regarding =
IANA actions and changing the text regarding what the experiment is to some=
thing along the lines of =E2=80=9Cwe want to gather experience on how to ma=
ke generic metric TLVs and ICVs that work with changing metric TV values ha=
ppen with reactive protocols=E2=80=9D
* we=E2=80=99re undecided o=
n (to quote Christopher) the "here's a mechanism we haven't re=
ally thought through in detail, but at least we've defined one", o=
r "we know the sort of thing we want, and we'll describe it, but r=
ather than produce something not quite right, we'll not go further=E2=
=80=9C decision on temporarily setting the metric value to 0 (i.e. the who =
and how). (personally, I think I=E2=80=99d prefer the latter approach, but =
that=E2=80=99s an entirely gut feeling-based preference)

Did I catch that correctly? If so, I=E2=80=99ll put together and sug=
gest some text for the first point as soon as I get home and in case there =
has been a decision on the second by then, I=E2=80=99ll try to tackle that =
one too. :)

Best regards, Lotte

Am 22.04.2016 um 16:41 schrieb Dearlo=
ve, Christopher (UK) <chris.dearlove@baesystems.com>:

I have no problem with that. I was trying to lay out t=
he issues without muddying the water with my preference.
=C2=A0
--
<=
p class=3D"MsoNormal" style=3D"margin:0cm 0cm 12pt;font-size:12pt;font-fami=
ly:'Times New Roman',serif">Christopher Dearlove
Senior=
 Principal Engineer
BAE Systems Applied Intelligence Laboratories
________________________________________________________=
__________________

T: =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E:=C2=A0=
chris.dearlove@baesyste=
ms.com

BAE Systems Applied Intelligence, =
Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.bae=
systems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England &=
 Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, =
GU2 7YP
=C2=
=A0
From:=
=C2=A0Justin Dean [mailto:bebemaster=
@gmail.com]=C2=A0
Sent:=C2=A022 Apr=
il 2016 15:35
To:=C2=A0Dearlove, Christopher (UK)Cc:=C2=A0Thomas Heide Clausen; Mobile Ad Hoc Networks =
mailing list
Subject:=C2=A0Re: [manet] On Forwarding=
-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of=
 big ticket Items)
=
=C2=A0
=C2=A0
*** WARNING=
 ***
T=
his message originates from outside our organisation, either from an extern=
al partner or the internet.
Consider carefully whether you should click on =
any links, open any attachments or reply.
For information regarding=C2=A0=
Red Flags=C2=A0that you can look out for in emails you receive, click=C2=A0here.
<=
span style=3D"font-family:Arial,sans-serif">If you feel the email is suspic=
ious, please follow=C2=A0this process.
Speaking as participant.
<=
br>I kind of like the idea of using the experimental message type space.=C2=
=A0 We only have a limited amount of these message types.=C2=A0 The TLV ass=
ignments could just use the message type specific space and there isn't=
 an issue there.=C2=A0 IANA wouldn't assign a number but I don't se=
e why the document couldn't specify the experimental numbers it was goi=
ng to use so other future near term experiential protocols could do the sam=
e and generally avoid conflict.=C2=A0 If the experiment is successful IANA =
assignments could be made.=C2=A0 Functionally no real difference with prote=
ctions vs long term usage of limited space.
=C2=A0
Justin
=C2=A0=

On Fri, Apr 22, 2016 at 9:35 AM, Dearlove=
, Christopher (UK) <chris.dearl=
ove@baesystems.com> wrote:
There's rather a contradiction between the concepts of a definition of=
 a protocol, even Experimental, and experimental space, which usually assum=
es that the user can do what he or she likes in it.

But chewing up m=
essages types (how many, 3?) of which there are relatively few for experime=
ntal is long term a problem, although short term not.

TLV space is e=
asier in two regards. It's bigger (though the prime real estate of type=
 extension zero isn't) and can have message type specific TLVs.

=
So TLVS can actually be invisible, if that option is chosen. For messages s=
omething has to give. Least bad option is again one of those we should disc=
uss, but time ...

(To be precise, messages types from 224 are define=
d in RFC 5444 as " Experimental Use", of which BCP 26 says "=
Similar to private or local use only, with the=C2=A0 purpose being to facil=
itate experimentation." The alternative 0-223 space is Expert Review. =
IANA still thinks the experts are Joe Macker and the recused Stan Ratliff. =
But that's a soluble nit.)

--
Christopher =
Dearlove
Senior Principal Engineer
BAE Syst=
ems Applied Intelligence Laboratories
_____________________=
_____________________________________________________

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

BAE Sys=
tems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelms=
ford, Essex CM2 8HN.
www.b=
aesystems.com/ai
BAE Systems Applied Intelligence Limit=
ed
Registered in England & Wales No: 01337451Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<=
/span>


-----Original Message-----
From: Th=
omas Heide Clausen [mailto:ietf@thomascl=
ausen.org]
Sent: 22 April 2016 14:21
To=
: Dearlove, Christopher (UK)
Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
S=
ubject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-man=
et-aodvv2-13 review - a couple of big ticket Items)

----------------=
------! WARNING ! ---------------------- This message originates from outsi=
de our organisation, either from an external partner or from the internet.<=
br>Consider carefully whether you should click on any links, open any attac=
hments or reply.
Follow the 'Report Suspicious Emails' link on I=
T matters for instructions on reporting suspicious email messages.
-----=
---------------------------------------------------


> On 22 a=
vr. 2016, at 15:05, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
>
&g=
t; Once you're entirely in AODV2's own space, and AODVv2 is experim=
ental (working assumption for this discussion) you have more liberty.
&g=
t;

Yep.

Taken somewhat by surprise both by the sudden "r=
ush" and the experimental maturity level, I am wondering (and haven=
9;t thought through) about experimental space vs non-experimental (for mess=
age types, and consequently for message type specific TLV types).

I =
think that if the AODVv2 experiment specifies the use of Message types from=
 the Experimental message type space without making actual registrations in=
 the IANA registry, AND the use of type specific TLV types, this becomes a =
non-issue entirely (by design, this is precisely what that experimental spa=
ce is for)

Whereas, as you point out, the alternative is a "can=
 open - worms everywhere" situation that I think time is too short to =
solve?

Thomas


> Then you could try specifying it. But =
with a very good chance of producing something you later decide you should =
have done differently.
>
> I honestly don't know which woul=
d go down better (or less badly) - "here's a mechanism we haven=
9;t really thought through in detail, but at least we've defined one&qu=
ot;, or "we know the sort of thing we want, and we'll describe it,=
 but rather than produce something not quite right, we'll not go furthe=
r".
>
> --
> Christopher Dearlove
> Senior Pri=
ncipal Engineer
> BAE Systems Applied Intelligence Laboratories
&g=
t; ________________________________________________________________________=
__
>
> T:=C2=A0=C2=A0+44 (0)1245 242194=C2=A0 |=C2=A0 E:=C2=A0chris.dearlove@baesystems.com
>=

> BAE Systems Applied Intelligence, Chelmsford Technology Park, Grea=
t Baddow, Chelmsford, Essex CM2 8HN.
>=C2=A0www.baesystems.com/ai
> BAE Systems Applied =
Intelligence Limited
> Registered in England & Wales No: 01337451=

> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7Y=
P
>
>
> -----Original Message-----
> From: Lotte St=
eenbrink [mailto:lotte.steenbrink@=
fu-berlin.de]
> Sent: 22 April 2016 13:59
> To: Mobile Ad H=
oc Networks mailing list
> Cc: Henning Rogge; Dearlove, Christopher (=
UK)
> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: d=
raft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>> ----------------------! WARNING ! ---------------------- This message=
 originates from outside our organisation, either from an external partner =
or from the internet.
> Consider carefully whether you should click o=
n any links, open any attachments or reply.
> Follow the 'Report =
Suspicious Emails' link on IT matters for instructions on reporting sus=
picious email messages.
> -------------------------------------------=
-------------
>
> Hello Christopher,
>
>> Am 22.=
04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>:
>>>> Just be careful to note that this concept is as currently being d=
iscussed (a) specific to AODVv2, and (b) not an application of 7182, which =
has no knowledge of special TLVs.
>>
>> This is something=
 we'd want to get right, and need to get right if in any space not spec=
ific to ADODVv2, because getting it wrong produces future problems.
>=

> Makes sense.
>
>> I can see some possible approache=
s, none is ideal and we're rather out
>> of time to specify. B=
ut this is experimental, so I think we might be
>> able to indicat=
e the shape of the solution without specifying it,
>> which would =
be a different RFC, under a bit less time pressure.
>> (Extensions=
 to existing protocols like 7182 would naturally be in
>> scope re=
chartered I think.)
>>
>> To indicate the range that'=
s open, here are two possible ideas, one of which has an impact now, so nee=
ds to be agreed. Note that I'm not suggesting (in fact quite the opposi=
te) defining an extension to 7182 here, rather enabling such an extension, =
if written, to "do the right thing".
>> - We have an ext=
ension to 7182 that says "zero out all value octets in protocol specif=
ic TLVs. That requires now putting the AODVv2 metric TLV in that space.
=
>
> Just to make sure that I understood you correctly=E2=80=93 =E2=
=80=9Cthat space=E2=80=9D meaning making the AODVv2 metric TLV protocol spe=
cific? (By =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m referring to=
 the generic TLV we=E2=80=99ve been talking about on this list earlier this=
 week).
>
>> - We have an extension to 7182 that adds extra =
material to the value field that indicates (TBD how, by position with sanit=
y check that this is TLV value perhaps?) which octets are to be zeroed out =
before the ICV is calculated.
>
> The way I understand that app=
roach, it wouldn=E2=80=99t warrant any action from AODVv2 besides saying =
=E2=80=9Cif you calculate the ICV, set the Metric value to zero=E2=80=9D (l=
eaving the nitty gritty of how this would be done in detail to future work)=
=E2=80=A6 Is that correct?
>
>>
>> We do not have t=
he time to specify this in an acceptable manner within two weeks though. Bu=
t the security consideration section could say something along the lines of=
 "this enables the use of an ICV defined to zero out these octets=E2=
=80=9C.
>
> Okay. :)
>
> Best regards,
> Lott=
e
>
>>
>> --
>> Christopher Dearlove
&g=
t;> Senior Principal Engineer
>> BAE Systems Applied Intelligen=
ce Laboratories
>> _______________________________________________=
_______________________
>> ____
>>
>> T:=C2=A0 <=
a href=3D"tel:%2B44%20%280%291245%20242194" value=3D"+441245242194" target=
=3D"_blank">+44 (0)1245 242194=C2=A0 |=C2=A0 E:=C2=A0chris.dearlove@baesystems.com
&g=
t;>
>> BAE Systems Applied Intelligence, Chelmsford Technology =
Park, Great Baddow, Chelmsford, Essex CM2 8HN.
>>=C2=A0www.baesystems.com/ai
>> BA=
E Systems Applied Intelligence Limited Registered in England & Wales>> No: 01337451 Registered Office: Surrey Research Park, Guildford,<=
br>>> Surrey, GU2 7YP
>>
>> -----Original Message--=
---
>> From: manet [mailto:manet=
-bounces@ietf.org] On Behalf Of Lotte
>> Steenbrink
>>=
; Sent: 22 April 2016 10:28
>> To: Henning Rogge
>> Cc: M=
obile Ad Hoc Networks mailing list
>> Subject: Re: [manet] On Forw=
arding-and-regeneration (was: Re:
>> draft-ietf-manet-aodvv2-13 re=
view - a couple of big ticket Items)
>>
>> --------------=
--------! WARNING ! ---------------------- This message originates from out=
side our organisation, either from an external partner or from the internet=
.
>> Consider carefully whether you should click on any links, ope=
n any attachments or reply.
>> Follow the 'Report Suspicious E=
mails' link on IT matters for instructions on reporting suspicious emai=
l messages.
>> ---------------------------------------------------=
-----
>>
>> *** WARNING ***
>> EXTERNAL EMAIL --=
 This message originates from outside our organization.
>>
>=
>
>> Hi Henning,
>>
>>> Am 22.04.2016 um 1=
1:08 schrieb Henning Rogge <hrogge@gmail.com=
>:
>>>
>>> On Fri, Apr 22, 2016 at 11:05 AM,=
 Lotte Steenbrink
>>> <lotte.steenbrink@fu-berlin.de> wrote:
>>>> Hi Tho=
mas,
>>>> Can it?! Iirc, the reason why we adopted the =E2=
=80=9Cregeneration=E2=80=9D language
>>>> in the first place=
 is that we=E2=80=99ve been told that whenever one bit in
>>>&g=
t; the message (apart from its header) is changed, the entire thing has to =
be regenerated.
>>>> I=E2=80=99m starting to get the feeling=
 we=E2=80=99ve just been misunderstanding
>>>> each other fo=
r more than a year. :( Anyway, it seems like we=E2=80=99re
>>>&=
gt; getting close now, so yay.
>>>
>>> "Modify=
ing" the binary message instead of parsing and generating a
>>=
;> new one will be difficult as soon someone writes an extension to
&=
gt;>> AODVv2 that adds more TLVs to the message.
>>
>&=
gt; D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s w=
hat you explained to me when I got confused about the topic last spring=E2=
=80=A6 But=E2=80=93 even if a message contains TLVs that the AODVv2 impleme=
ntation handling it doesn=E2=80=99t understand, it will still be able to re=
cognize the Metric TLV, right? Isn=E2=80=99t that the nifty thing about RFC=
5444? So, while we really shouldn=E2=80=99t write =E2=80=9Cbefore calculati=
ng the ICV, set the n-th 4 octets to 0=E2=80=9D, we might say =E2=80=9Ciden=
tify the octets that make up the metric value and set those to 0=E2=80=9D?<=
br>>>
>> Best regards,
>> Lotte
>>
>=
>> Henning Rogge
>>
>> ____________________________=
___________________
>> manet mailing list
>>=C2=A0<=
/span>manet@ietf.org
>>=C2=A0<=
/span>https://www.ietf.org/=
mailman/listinfo/manet
>> ************************************=
********************************
>> This email and any attachments=
 are confidential to the intended
>> recipient and may also be pri=
vileged. 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 conte=
nts to any other person.
>> **************************************=
******************************
>
> ____________________________=
___________________
> manet mailing list
>=C2=A0manet@ietf.org
>=C2=A0https://www.ietf.org/mailman/list=
info/manet

_______________________________________________
ma=
net mailing list
manet@ietf.org
https://www.ietf.org/mailman/listi=
nfo/manet
<=
u>=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

_______________________________________________manet mailing list
manet@ietf.org
https://www.ietf.org/m=
ailman/listinfo/manet


________________________________=
_______________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet





--001a113f1fe4489d6005317f2399--


From nobody Wed Apr 27 16:25: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 2E96212B02B for ; Wed, 27 Apr 2016 16:25:15 -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 bGnTbE9gPyvC for ; Wed, 27 Apr 2016 16:25:11 -0700 (PDT)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 89FE5126FDC for ; Wed, 27 Apr 2016 16:25:10 -0700 (PDT)
Received: by mail-vk0-x232.google.com with SMTP id m188so12419022vka.1 for ; Wed, 27 Apr 2016 16:25:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1Lb5uHx/GIioiAEvX6uFxe5DIfi8QHfPt5WAeYETPQc=; b=1JfLTAervgPA0fMABIa03vuM9frjiAmawEkWfhDcaQORAzV//pULm7cuiKNeDHwQKp g47vUoBxuK3rJ6MF1CQV6UG1nNA/SHJT0bSQUjyRlXE5LIfIbNHvBJUccrgRMUT3q6ap IPubLV8wMlTuzJMzRsVJV/E4O9JmzB8edEeh0C0jMnTpyf2PBjg3M0h3tZxHW6c+TGnH gPW1UzqD0PQ9V+1pgmVNh5hVc9x/sA3sSHMIa+XuH7nwxeK98oCvThaHGQwVV9Ie5AaT X0QOCdaG71RkJCjd3numVGZU3FAhWQx2D7VtXHVpAzGht43T+tzU9tmmX0/h6JNvupW0 epQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1Lb5uHx/GIioiAEvX6uFxe5DIfi8QHfPt5WAeYETPQc=; b=kqE0o19epq76TkCD4v3patcCFoDfQtrakE398VAN7xBkt9hsI51XloZB250octvAnf IE2G/K9NMIiL/3waBwMp/0Yi2b18yUAw7omsNdwSJGlkJTDPM4PcS0XRcAg5V9rP8CYQ 1VQJgDJceTxzmIzKv38cN5vHWP7cojrqCoRedNEGrKI2jkvn2QDxGSQBfEeIzrVnGweg eoxlSQgVzQCXftFgJNZu6hnhvyp5GskXwmGleZI9VUC2ZrnVRJualj8fvhTAbTjPP94d kTysFiaYG3mvHLJ3igFX0vI9q7PtDOb+iLupw8tnzJIy+bxXYobAyYOi3SoQAHOC7OxD HC1g==
X-Gm-Message-State: AOPr4FXqJRoPIHooy3FU48Cb975I3254doB+mSR2tZj8VbJ2cdEywPrQeT1DbqdEcl+/TOa9SwgGFF3wcXt2bg==
X-Received: by 10.159.37.245 with SMTP id 108mr5910215uaf.140.1461799509475; Wed, 27 Apr 2016 16:25:09 -0700 (PDT)
MIME-Version: 1.0
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org>      <60BD2E9C-64D7-4444-B3A9-8D207EB4A86F@gmail.com> <144C7397-F19E-4FB0-959A-B5A030BD7A8A@fu-berlin.de> 
In-Reply-To: 
From: Justin Dean 
Date: Wed, 27 Apr 2016 23:24:59 +0000
Message-ID: 
To: Jiazi YI , Lotte Steenbrink 
Content-Type: multipart/alternative; boundary=001a113ad63c7ec81605317fb8f5
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 27 Apr 2016 23:25:15 -0000

--001a113ad63c7ec81605317fb8f5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

An alternative solution to checking integrity. The current icv draft is
good at validating messages from an original source. OLSRV2 and NHDP use
this to good effect. AODVV2 doesn't because the messages are regenerated; I
belive this to be the correct term as the message contains local
information, path information, and originator information. Getting the icv
draft to work on forwarded packets is ugly as they really are regenerated
and should be. What we want to do is secure the original source of
information which is OrigAddr/target address and sequence number. Why not
just attach a new aodv specific icv TLV which uses THAT info and nothing
else? The current icv TLV would/could still be used over the whole message
hop by hop by each router, as the messages are regenerated.

Justin

On Wed, Apr 27, 2016, 6:43 PM Jiazi YI  wrote:

> On Thu, Apr 28, 2016 at 12:19 AM, Lotte Steenbrink <
> lotte.steenbrink@fu-berlin.de> wrote:
>
>>
>> Am 28.04.2016 um 00:16 schrieb Christopher Dearlove <
>> christopher.dearlove@gmail.com>:
>>
>> The more you have to zero out, the messier it gets, and the less secure
>> it gets (more things can be spoofed). I think that's about all I've got =
to
>> add.
>>
>>
>> Of course. My question was just:
>> * Do we want to come up with an exact description of how the zeroing out
>> should work now, with the short time we have left?
>>
>
> If a meaningful security mechanism is required, yes.
> I think the first thing to do is to cut as many mutable fields and
> optional fields as possible.
>
> best
>
> Jiazi
>
>
>> or
>> * Do we mention in the draft that zeroing out has to happen somehow and
>> leave the nitty gritty to future work?
>>
>> At least that=E2=80=99s how I understood the options you laid out...
>>
>> --
>> Christopher Dearlove
>> christopher.dearlove@gmail.com (iPhone)
>> chris@mnemosyne.demon.co.uk (home)
>>
>>
>>
>> --
>> Christopher Dearlove
>> christopher.dearlove@gmail.com (iPhone)
>> chris@mnemosyne.demon.co.uk (home)
>> On 27 Apr 2016, at 22:46, Lotte Steenbrink 
>> wrote:
>>
>> Hi all,
>> I=E2=80=99m currently revising the security considerations with regards =
to the
>> move from regeneration to forwarding, which depends on a decision being
>> made on how/where we want to mention the possibility of zeroing out TLVs=
 to
>> calculate the ICV for the rest of a message=E2=80=99s contents (see seco=
nd * of my
>> last e-mail). I=E2=80=99ve not found a decision on this in other thread =
(please
>> pardon me if I overlooked something), so I=E2=80=99ll bump this thread a=
nd ask the
>> WG for its opinions. (again, personally, the 2nd option outlined by
>> Christopher seems more appealing to me)
>>
>> Regards,
>> Lotte
>>
>> Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink <
>> lotte.steenbrink@fu-berlin.de>:
>>
>> Hi all,
>> to summarize:
>>
>> * AODVv2 message Type numbers should be in the Experimental type space
>> and the AODVv2 TLV Types should be message type-specific. This also mean=
s
>> changing the text regarding IANA actions and changing the text regarding
>> what the experiment is to something along the lines of =E2=80=9Cwe want =
to gather
>> experience on how to make generic metric TLVs and ICVs that work with
>> changing metric TV values happen with reactive protocols=E2=80=9D
>> * we=E2=80=99re undecided on (to quote Christopher) the "here's a mechan=
ism we
>> haven't really thought through in detail, but at least we've defined one=
",
>> or "we know the sort of thing we want, and we'll describe it, but rather
>> than produce something not quite right, we'll not go further=E2=80=9C de=
cision on
>> temporarily setting the metric value to 0 (i.e. the who and how).
>> (personally, I think I=E2=80=99d prefer the latter approach, but that=E2=
=80=99s an entirely
>> gut feeling-based preference)
>>
>> Did I catch that correctly? If so, I=E2=80=99ll put together and suggest=
 some
>> text for the first point as soon as I get home and in case there has bee=
n a
>> decision on the second by then, I=E2=80=99ll try to tackle that one too.=
 :)
>>
>> Best regards, Lotte
>>
>> Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com>:
>>
>> I have no problem with that. I was trying to lay out the issues without
>> muddying the water with my preference.
>>
>>
>> *--*
>>
>>
>>
>>
>> *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:* Justin Dean [mailto:bebemaster@gmail.com ]
>> *Sent:* 22 April 2016 15:35
>> *To:* Dearlove, Christopher (UK)
>> *Cc:* Thomas Heide Clausen; Mobile Ad Hoc Networks mailing list
>> *Subject:* Re: [manet] On Forwarding-and-regeneration (was: Re:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>>
>> **** 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
>> .*
>> Speaking as participant.
>>
>> I kind of like the idea of using the experimental message type space.  W=
e
>> only have a limited amount of these message types.  The TLV assignments
>> could just use the message type specific space and there isn't an issue
>> there.  IANA wouldn't assign a number but I don't see why the document
>> couldn't specify the experimental numbers it was going to use so other
>> future near term experiential protocols could do the same and generally
>> avoid conflict.  If the experiment is successful IANA assignments could =
be
>> made.  Functionally no real difference with protections vs long term usa=
ge
>> of limited space.
>>
>> Justin
>>
>> On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>> There's rather a contradiction between the concepts of a definition of a
>> protocol, even Experimental, and experimental space, which usually assum=
es
>> that the user can do what he or she likes in it.
>>
>> But chewing up messages types (how many, 3?) of which there are
>> relatively few for experimental is long term a problem, although short t=
erm
>> not.
>>
>> TLV space is easier in two regards. It's bigger (though the prime real
>> estate of type extension zero isn't) and can have message type specific
>> TLVs.
>>
>> So TLVS can actually be invisible, if that option is chosen. For message=
s
>> something has to give. Least bad option is again one of those we should
>> discuss, but time ...
>>
>> (To be precise, messages types from 224 are defined in RFC 5444 as "
>> Experimental Use", of which BCP 26 says "Similar to private or local use
>> only, with the  purpose being to facilitate experimentation." The
>> alternative 0-223 space is Expert Review. IANA still thinks the experts =
are
>> Joe Macker and the recused Stan Ratliff. But that's a soluble nit.)
>>
>> --
>> 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
>>
>>
>> -----Original Message-----
>> From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org]
>> Sent: 22 April 2016 14:21
>> To: Dearlove, Christopher (UK)
>> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>> ----------------------! WARNING ! ---------------------- This message
>> originates from outside our organisation, either from an external partne=
r
>> or from the internet.
>> Consider carefully whether you should click on any links, open any
>> attachments or reply.
>> Follow the 'Report Suspicious Emails' link on IT matters for instruction=
s
>> on reporting suspicious email messages.
>> --------------------------------------------------------
>>
>>
>> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com> wrote:
>> >
>> > Once you're entirely in AODV2's own space, and AODVv2 is experimental
>> (working assumption for this discussion) you have more liberty.
>> >
>>
>> Yep.
>>
>> Taken somewhat by surprise both by the sudden "rush" and the experimenta=
l
>> maturity level, I am wondering (and haven't thought through) about
>> experimental space vs non-experimental (for message types, and consequen=
tly
>> for message type specific TLV types).
>>
>> I think that if the AODVv2 experiment specifies the use of Message types
>> from the Experimental message type space without making actual
>> registrations in the IANA registry, AND the use of type specific TLV typ=
es,
>> this becomes a non-issue entirely (by design, this is precisely what tha=
t
>> experimental space is for)
>>
>> Whereas, as you point out, the alternative is a "can open - worms
>> everywhere" situation that I think time is too short to solve?
>>
>> Thomas
>>
>>
>> > Then you could try specifying it. But with a very good chance of
>> producing something you later decide you should have done differently.
>> >
>> > I honestly don't know which would go down better (or less badly) -
>> "here's a mechanism we haven't really thought through in detail, but at
>> least we've defined one", or "we know the sort of thing we want, and we'=
ll
>> describe it, but rather than produce something not quite right, we'll no=
t
>> go further".
>> >
>> > --
>> > 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
>> >
>> >
>> > -----Original Message-----
>> > From: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]
>> > Sent: 22 April 2016 13:59
>> > To: Mobile Ad Hoc Networks mailing list
>> > Cc: Henning Rogge; Dearlove, Christopher (UK)
>> > Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>> >
>> > ----------------------! WARNING ! ---------------------- This message
>> originates from outside our organisation, either from an external partne=
r
>> or from the internet.
>> > Consider carefully whether you should click on any links, open any
>> attachments or reply.
>> > Follow the 'Report Suspicious Emails' link on IT matters for
>> instructions on reporting suspicious email messages.
>> > --------------------------------------------------------
>> >
>> > Hello Christopher,
>> >
>> >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <
>> chris.dearlove@baesystems.com>:
>> >>
>> >> Just be careful to note that this concept is as currently being
>> discussed (a) specific to AODVv2, and (b) not an application of 7182, wh=
ich
>> has no knowledge of special TLVs.
>> >>
>> >> This is something we'd want to get right, and need to get right if in
>> any space not specific to ADODVv2, because getting it wrong produces fut=
ure
>> problems.
>> >
>> > Makes sense.
>> >
>> >> I can see some possible approaches, none is ideal and we're rather ou=
t
>> >> of time to specify. But this is experimental, so I think we might be
>> >> able to indicate the shape of the solution without specifying it,
>> >> which would be a different RFC, under a bit less time pressure.
>> >> (Extensions to existing protocols like 7182 would naturally be in
>> >> scope rechartered I think.)
>> >>
>> >> To indicate the range that's open, here are two possible ideas, one o=
f
>> which has an impact now, so needs to be agreed. Note that I'm not
>> suggesting (in fact quite the opposite) defining an extension to 7182 he=
re,
>> rather enabling such an extension, if written, to "do the right thing".
>> >> - We have an extension to 7182 that says "zero out all value octets i=
n
>> protocol specific TLVs. That requires now putting the AODVv2 metric TLV =
in
>> that space.
>> >
>> > Just to make sure that I understood you correctly=E2=80=93 =E2=80=9Cth=
at space=E2=80=9D meaning
>> making the AODVv2 metric TLV protocol specific? (By =E2=80=9Cthe aodvv2 =
metric tlv=E2=80=9D
>> I=E2=80=99m referring to the generic TLV we=E2=80=99ve been talking abou=
t on this list
>> earlier this week).
>> >
>> >> - We have an extension to 7182 that adds extra material to the value
>> field that indicates (TBD how, by position with sanity check that this i=
s
>> TLV value perhaps?) which octets are to be zeroed out before the ICV is
>> calculated.
>> >
>> > The way I understand that approach, it wouldn=E2=80=99t warrant any ac=
tion from
>> AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set the Metric =
value to
>> zero=E2=80=9D (leaving the nitty gritty of how this would be done in det=
ail to
>> future work)=E2=80=A6 Is that correct?
>> >
>> >>
>> >> We do not have the time to specify this in an acceptable manner withi=
n
>> two weeks though. But the security consideration section could say
>> something along the lines of "this enables the use of an ICV defined to
>> zero out these octets=E2=80=9C.
>> >
>> > Okay. :)
>> >
>> > Best regards,
>> > Lotte
>> >
>> >>
>> >> --
>> >> 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 & Wale=
s
>> >> No: 01337451 Registered Office: Surrey Research Park, Guildford,
>> >> Surrey, GU2 7YP
>> >>
>> >> -----Original Message-----
>> >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte
>> >> Steenbrink
>> >> Sent: 22 April 2016 10:28
>> >> To: Henning Rogge
>> >> Cc: Mobile Ad Hoc Networks mailing list
>> >> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>> >> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>> >>
>> >> ----------------------! WARNING ! ---------------------- This message
>> originates from outside our organisation, either from an external partne=
r
>> or from the internet.
>> >> Consider carefully whether you should click on any links, open any
>> attachments or reply.
>> >> Follow the 'Report Suspicious Emails' link on IT matters for
>> instructions on reporting suspicious email messages.
>> >> --------------------------------------------------------
>> >>
>> >> *** WARNING ***
>> >> EXTERNAL EMAIL -- This message originates from outside our
>> organization.
>> >>
>> >>
>> >> Hi Henning,
>> >>
>> >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge :
>> >>>
>> >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>> >>>  wrote:
>> >>>> Hi Thomas,
>> >>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=
=E2=80=9D language
>> >>>> in the first place is that we=E2=80=99ve been told that whenever on=
e bit in
>> >>>> the message (apart from its header) is changed, the entire thing ha=
s
>> to be regenerated.
>> >>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been mis=
understanding
>> >>>> each other for more than a year. :( Anyway, it seems like we=E2=80=
=99re
>> >>>> getting close now, so yay.
>> >>>
>> >>> "Modifying" the binary message instead of parsing and generating a
>> >>> new one will be difficult as soon someone writes an extension to
>> >>> AODVv2 that adds more TLVs to the message.
>> >>
>> >> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s=
 what you
>> explained to me when I got confused about the topic last spring=E2=80=A6=
 But=E2=80=93 even
>> if a message contains TLVs that the AODVv2 implementation handling it
>> doesn=E2=80=99t understand, it will still be able to recognize the Metri=
c TLV,
>> right? Isn=E2=80=99t that the nifty thing about RFC5444? So, while we re=
ally
>> shouldn=E2=80=99t write =E2=80=9Cbefore calculating the ICV, set the n-t=
h 4 octets to 0=E2=80=9D,
>> we might say =E2=80=9Cidentify the octets that make up the metric value =
and set
>> those to 0=E2=80=9D?
>> >>
>> >> Best regards,
>> >> Lotte
>> >>
>> >>> Henning Rogge
>> >>
>> >> _______________________________________________
>> >> 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
>>
>> _______________________________________________
>> 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
>

--001a113ad63c7ec81605317fb8f5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


An alternative solution to checking integrity. The current i=
cv draft is good at validating messages from an original source. OLSRV2 and=
 NHDP use this to good effect. AODVV2 doesn't because the messages are =
regenerated; I belive this to be the correct term as the message contains l=
ocal information, path information, and originator information. Getting the=
 icv draft to work on forwarded packets is ugly as they really are regenera=
ted and should be. What we want to do is secure the original source of info=
rmation which is OrigAddr/target address and sequence number. Why not just =
attach a new aodv specific icv TLV which uses THAT info and nothing else? T=
he current icv TLV would/could still be used over the whole message hop by =
hop by each router, as the messages are regenerated.


Justin


On Wed, Apr 27, 2016, 6:43 =
PM Jiazi YI <ietf@jiaziyi.com>=
; wrote:
On Thu, Apr 28, 2016 at 12:19 =
AM, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:

Am 28.04.2016 um 00:16=
 schrieb Christopher Dearlove <christopher.dearlove@gmail.com>:
The more you have=
 to zero out, the messier it gets, and the less secure it gets (more things=
 can be spoofed). I think that's about all I've got to add.

=


Of cou=
rse. My question was just:
* Do we want to come up with an exact =
description of how the zeroing out should work now, with the short time we =
have left?

<=
/div>
If a meaningful security mechanism is required, yes.=C2=A0
=
I think the first thing to do is to cut as many mutable fields and optional=
 fields as possible.=C2=A0

best
<=
/div>

Jiazi
=C2=A0
or
* Do we mention in the draft that zeroing out has to happen somehow=
 and leave the nitty gritty to future work?

At lea=
st that=E2=80=99s how I understood the options you laid out...
<=
div>

--=
=C2=A0
Christopher Dearlove


-- =C2=A0
Christopher Dearlove
On 27 Apr 2016, a=
t 22:46, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:

<=
/div>

Hi all,
I=E2=80=99m currently revising the security considerations with=
 regards to the move from regeneration to forwarding, which depends on a de=
cision being made on how/where we want to mention the possibility of zeroin=
g out TLVs to calculate the ICV for the rest of a message=E2=80=99s content=
s (see second * of my last e-mail). I=E2=80=99ve not found a decision on th=
is in other thread (please pardon me if I overlooked something), so I=E2=80=
=99ll bump this thread and ask the WG for its opinions. (again, personally,=
 the 2nd option outlined by Christopher seems more appealing to me)

Regards,
Lotte

Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink <lotte.steenbr=
ink@fu-berlin.de>:

Hi all,
to summarize:

* AODVv2 message Type n=
umbers should be in the Experimental type space and the AODVv2 TLV Types sh=
ould be message type-specific. This also means changing the text regarding =
IANA actions and changing the text regarding what the experiment is to some=
thing along the lines of =E2=80=9Cwe want to gather experience on how to ma=
ke generic metric TLVs and ICVs that work with changing metric TV values ha=
ppen with reactive protocols=E2=80=9D
* we=E2=80=99re undecided o=
n (to quote Christopher) the "here's a mechanism we haven't re=
ally thought through in detail, but at least we've defined one", o=
r "we know the sort of thing we want, and we'll describe it, but r=
ather than produce something not quite right, we'll not go further=E2=
=80=9C decision on temporarily setting the metric value to 0 (i.e. the who =
and how). (personally, I think I=E2=80=99d prefer the latter approach, but =
that=E2=80=99s an entirely gut feeling-based preference)

Did I catch that correctly? If so, I=E2=80=99ll put together and sug=
gest some text for the first point as soon as I get home and in case there =
has been a decision on the second by then, I=E2=80=99ll try to tackle that =
one too. :)

Best regards, Lotte

Am 22.04.2016 um 16:41 schrieb Dearlo=
ve, Christopher (UK) <chris.dearlove@baesystems.com>:

I have no problem with that. I was trying to lay out t=
he issues without muddying the water with my preference.
=C2=A0
--
<=
p class=3D"MsoNormal" style=3D"margin:0cm 0cm 12pt;font-size:12pt;font-fami=
ly:'Times New Roman',serif">Christopher Dearlove
Senior=
 Principal Engineer
BAE Systems Applied Intelligence Laboratories
________________________________________________________=
__________________

T: =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E:=C2=A0=
chris.dearlove@baesyste=
ms.com

BAE Systems Applied Intelligence, =
Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.bae=
systems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England &=
 Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, =
GU2 7YP
=C2=
=A0
From:=
=C2=A0Justin Dean [mailto:bebemaster=
@gmail.com]=C2=A0
Sent:=C2=A022 Apr=
il 2016 15:35
To:=C2=A0Dearlove, Christopher (UK)Cc:=C2=A0Thomas Heide Clausen; Mobile Ad Hoc Networks =
mailing list
Subject:=C2=A0Re: [manet] On Forwarding=
-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of=
 big ticket Items)
=
=C2=A0
=C2=A0
*** WARNING=
 ***
T=
his message originates from outside our organisation, either from an extern=
al partner or the internet.
Consider carefully whether you should click on =
any links, open any attachments or reply.
For information regarding=C2=A0=
Red Flags=C2=A0that you can look out for in emails you receive, click=C2=A0here.
<=
span style=3D"font-family:Arial,sans-serif">If you feel the email is suspic=
ious, please follow=C2=A0this process.
Speaking as participant.
<=
br>I kind of like the idea of using the experimental message type space.=C2=
=A0 We only have a limited amount of these message types.=C2=A0 The TLV ass=
ignments could just use the message type specific space and there isn't=
 an issue there.=C2=A0 IANA wouldn't assign a number but I don't se=
e why the document couldn't specify the experimental numbers it was goi=
ng to use so other future near term experiential protocols could do the sam=
e and generally avoid conflict.=C2=A0 If the experiment is successful IANA =
assignments could be made.=C2=A0 Functionally no real difference with prote=
ctions vs long term usage of limited space.
=C2=A0
Justin
=C2=A0=

On Fri, Apr 22, 2016 at 9:35 AM, Dearlove=
, Christopher (UK) <chris.dearl=
ove@baesystems.com> wrote:
There's rather a contradiction between the concepts of a definition of=
 a protocol, even Experimental, and experimental space, which usually assum=
es that the user can do what he or she likes in it.

But chewing up m=
essages types (how many, 3?) of which there are relatively few for experime=
ntal is long term a problem, although short term not.

TLV space is e=
asier in two regards. It's bigger (though the prime real estate of type=
 extension zero isn't) and can have message type specific TLVs.

=
So TLVS can actually be invisible, if that option is chosen. For messages s=
omething has to give. Least bad option is again one of those we should disc=
uss, but time ...

(To be precise, messages types from 224 are define=
d in RFC 5444 as " Experimental Use", of which BCP 26 says "=
Similar to private or local use only, with the=C2=A0 purpose being to facil=
itate experimentation." The alternative 0-223 space is Expert Review. =
IANA still thinks the experts are Joe Macker and the recused Stan Ratliff. =
But that's a soluble nit.)

--
Christopher =
Dearlove
Senior Principal Engineer
BAE Syst=
ems Applied Intelligence Laboratories
_____________________=
_____________________________________________________

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

BAE Sys=
tems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelms=
ford, Essex CM2 8HN.
www.b=
aesystems.com/ai
BAE Systems Applied Intelligence Limit=
ed
Registered in England & Wales No: 01337451Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<=
/span>


-----Original Message-----
From: Th=
omas Heide Clausen [mailto:ietf@thomascl=
ausen.org]
Sent: 22 April 2016 14:21
To=
: Dearlove, Christopher (UK)
Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
S=
ubject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-man=
et-aodvv2-13 review - a couple of big ticket Items)

----------------=
------! WARNING ! ---------------------- This message originates from outsi=
de our organisation, either from an external partner or from the internet.<=
br>Consider carefully whether you should click on any links, open any attac=
hments or reply.
Follow the 'Report Suspicious Emails' link on I=
T matters for instructions on reporting suspicious email messages.
-----=
---------------------------------------------------


> On 22 a=
vr. 2016, at 15:05, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
>
&g=
t; Once you're entirely in AODV2's own space, and AODVv2 is experim=
ental (working assumption for this discussion) you have more liberty.
&g=
t;

Yep.

Taken somewhat by surprise both by the sudden "r=
ush" and the experimental maturity level, I am wondering (and haven=
9;t thought through) about experimental space vs non-experimental (for mess=
age types, and consequently for message type specific TLV types).

I =
think that if the AODVv2 experiment specifies the use of Message types from=
 the Experimental message type space without making actual registrations in=
 the IANA registry, AND the use of type specific TLV types, this becomes a =
non-issue entirely (by design, this is precisely what that experimental spa=
ce is for)

Whereas, as you point out, the alternative is a "can=
 open - worms everywhere" situation that I think time is too short to =
solve?

Thomas


> Then you could try specifying it. But =
with a very good chance of producing something you later decide you should =
have done differently.
>
> I honestly don't know which woul=
d go down better (or less badly) - "here's a mechanism we haven=
9;t really thought through in detail, but at least we've defined one&qu=
ot;, or "we know the sort of thing we want, and we'll describe it,=
 but rather than produce something not quite right, we'll not go furthe=
r".
>
> --
> Christopher Dearlove
> Senior Pri=
ncipal Engineer
> BAE Systems Applied Intelligence Laboratories
&g=
t; ________________________________________________________________________=
__
>
> T:=C2=A0=C2=A0+44 (0)1245 242194=C2=A0 |=C2=A0 E:=C2=A0chris.dearlove@baesystems.com
>=

> BAE Systems Applied Intelligence, Chelmsford Technology Park, Grea=
t Baddow, Chelmsford, Essex CM2 8HN.
>=C2=A0www.baesystems.com/ai
> BAE Systems Applied =
Intelligence Limited
> Registered in England & Wales No: 01337451=

> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7Y=
P
>
>
> -----Original Message-----
> From: Lotte St=
eenbrink [mailto:lotte.steenbrink@=
fu-berlin.de]
> Sent: 22 April 2016 13:59
> To: Mobile Ad H=
oc Networks mailing list
> Cc: Henning Rogge; Dearlove, Christopher (=
UK)
> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: d=
raft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>> ----------------------! WARNING ! ---------------------- This message=
 originates from outside our organisation, either from an external partner =
or from the internet.
> Consider carefully whether you should click o=
n any links, open any attachments or reply.
> Follow the 'Report =
Suspicious Emails' link on IT matters for instructions on reporting sus=
picious email messages.
> -------------------------------------------=
-------------
>
> Hello Christopher,
>
>> Am 22.=
04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>:
>>>> Just be careful to note that this concept is as currently being d=
iscussed (a) specific to AODVv2, and (b) not an application of 7182, which =
has no knowledge of special TLVs.
>>
>> This is something=
 we'd want to get right, and need to get right if in any space not spec=
ific to ADODVv2, because getting it wrong produces future problems.
>=

> Makes sense.
>
>> I can see some possible approache=
s, none is ideal and we're rather out
>> of time to specify. B=
ut this is experimental, so I think we might be
>> able to indicat=
e the shape of the solution without specifying it,
>> which would =
be a different RFC, under a bit less time pressure.
>> (Extensions=
 to existing protocols like 7182 would naturally be in
>> scope re=
chartered I think.)
>>
>> To indicate the range that'=
s open, here are two possible ideas, one of which has an impact now, so nee=
ds to be agreed. Note that I'm not suggesting (in fact quite the opposi=
te) defining an extension to 7182 here, rather enabling such an extension, =
if written, to "do the right thing".
>> - We have an ext=
ension to 7182 that says "zero out all value octets in protocol specif=
ic TLVs. That requires now putting the AODVv2 metric TLV in that space.
=
>
> Just to make sure that I understood you correctly=E2=80=93 =E2=
=80=9Cthat space=E2=80=9D meaning making the AODVv2 metric TLV protocol spe=
cific? (By =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m referring to=
 the generic TLV we=E2=80=99ve been talking about on this list earlier this=
 week).
>
>> - We have an extension to 7182 that adds extra =
material to the value field that indicates (TBD how, by position with sanit=
y check that this is TLV value perhaps?) which octets are to be zeroed out =
before the ICV is calculated.
>
> The way I understand that app=
roach, it wouldn=E2=80=99t warrant any action from AODVv2 besides saying =
=E2=80=9Cif you calculate the ICV, set the Metric value to zero=E2=80=9D (l=
eaving the nitty gritty of how this would be done in detail to future work)=
=E2=80=A6 Is that correct?
>
>>
>> We do not have t=
he time to specify this in an acceptable manner within two weeks though. Bu=
t the security consideration section could say something along the lines of=
 "this enables the use of an ICV defined to zero out these octets=E2=
=80=9C.
>
> Okay. :)
>
> Best regards,
> Lott=
e
>
>>
>> --
>> Christopher Dearlove
&g=
t;> Senior Principal Engineer
>> BAE Systems Applied Intelligen=
ce Laboratories
>> _______________________________________________=
_______________________
>> ____
>>
>> T:=C2=A0 <=
a href=3D"tel:%2B44%20%280%291245%20242194" value=3D"+441245242194" target=
=3D"_blank">+44 (0)1245 242194=C2=A0 |=C2=A0 E:=C2=A0chris.dearlove@baesystems.com
&g=
t;>
>> BAE Systems Applied Intelligence, Chelmsford Technology =
Park, Great Baddow, Chelmsford, Essex CM2 8HN.
>>=C2=A0www.baesystems.com/ai
>> BA=
E Systems Applied Intelligence Limited Registered in England & Wales>> No: 01337451 Registered Office: Surrey Research Park, Guildford,<=
br>>> Surrey, GU2 7YP
>>
>> -----Original Message--=
---
>> From: manet [mailto:manet=
-bounces@ietf.org] On Behalf Of Lotte
>> Steenbrink
>>=
; Sent: 22 April 2016 10:28
>> To: Henning Rogge
>> Cc: M=
obile Ad Hoc Networks mailing list
>> Subject: Re: [manet] On Forw=
arding-and-regeneration (was: Re:
>> draft-ietf-manet-aodvv2-13 re=
view - a couple of big ticket Items)
>>
>> --------------=
--------! WARNING ! ---------------------- This message originates from out=
side our organisation, either from an external partner or from the internet=
.
>> Consider carefully whether you should click on any links, ope=
n any attachments or reply.
>> Follow the 'Report Suspicious E=
mails' link on IT matters for instructions on reporting suspicious emai=
l messages.
>> ---------------------------------------------------=
-----
>>
>> *** WARNING ***
>> EXTERNAL EMAIL --=
 This message originates from outside our organization.
>>
>=
>
>> Hi Henning,
>>
>>> Am 22.04.2016 um 1=
1:08 schrieb Henning Rogge <hrogge@gmail.com=
>:
>>>
>>> On Fri, Apr 22, 2016 at 11:05 AM,=
 Lotte Steenbrink
>>> <lotte.steenbrink@fu-berlin.de> wrote:
>>>> Hi Tho=
mas,
>>>> Can it?! Iirc, the reason why we adopted the =E2=
=80=9Cregeneration=E2=80=9D language
>>>> in the first place=
 is that we=E2=80=99ve been told that whenever one bit in
>>>&g=
t; the message (apart from its header) is changed, the entire thing has to =
be regenerated.
>>>> I=E2=80=99m starting to get the feeling=
 we=E2=80=99ve just been misunderstanding
>>>> each other fo=
r more than a year. :( Anyway, it seems like we=E2=80=99re
>>>&=
gt; getting close now, so yay.
>>>
>>> "Modify=
ing" the binary message instead of parsing and generating a
>>=
;> new one will be difficult as soon someone writes an extension to
&=
gt;>> AODVv2 that adds more TLVs to the message.
>>
>&=
gt; D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s w=
hat you explained to me when I got confused about the topic last spring=E2=
=80=A6 But=E2=80=93 even if a message contains TLVs that the AODVv2 impleme=
ntation handling it doesn=E2=80=99t understand, it will still be able to re=
cognize the Metric TLV, right? Isn=E2=80=99t that the nifty thing about RFC=
5444? So, while we really shouldn=E2=80=99t write =E2=80=9Cbefore calculati=
ng the ICV, set the n-th 4 octets to 0=E2=80=9D, we might say =E2=80=9Ciden=
tify the octets that make up the metric value and set those to 0=E2=80=9D?<=
br>>>
>> Best regards,
>> Lotte
>>
>=
>> Henning Rogge
>>
>> ____________________________=
___________________
>> manet mailing list
>>=C2=A0<=
/span>manet@ietf.org
>>=C2=A0<=
/span>https://www.ietf.org/=
mailman/listinfo/manet
>> ************************************=
********************************
>> This email and any attachments=
 are confidential to the intended
>> recipient and may also be pri=
vileged. 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 conte=
nts to any other person.
>> **************************************=
******************************
>
> ____________________________=
___________________
> manet mailing list
>=C2=A0manet@ietf.org
>=C2=A0https://www.ietf.org/mailman/list=
info/manet

_______________________________________________
ma=
net mailing list
manet@ietf.org
https://www.ietf.org/mailman/listi=
nfo/manet
<=
u>=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

_______________________________________________manet mailing list
manet@ietf.org
https://www.ietf.org/m=
ailman/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



--001a113ad63c7ec81605317fb8f5--


From nobody Wed Apr 27 16:38: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 2E33012D588 for ; Wed, 27 Apr 2016 16:38:11 -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 IYrafYz3rhIE for ; Wed, 27 Apr 2016 16:38:08 -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 E65BD12D57A for ; Wed, 27 Apr 2016 16:38:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id AE31E24020A; Wed, 27 Apr 2016 16:38:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461800287; bh=YBwhSX85+fAQ0vvDANqf7T15d7Lh/SxW05mfiqiO5bA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=lMFtCxPutzcLq9HK8hoTI54lAGJdzxuJUf8TbBRIoLszRkStaNwUZzX1JNBKap6if OwqqYPyFEsa1ux9SK+tqqE5gwNrigdu7aQJttbx0xkCxC9zHZ9lNNv5FvuuidOdGkl 8prR/7ZEQPWpMFAEyxZiBrkf5dxybFTkkiokMKSM=
X-Virus-Scanned: Debian amavisd-new at maila2.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 maila2.tigertech.net (Postfix) with ESMTPSA id 65FD5240207; Wed, 27 Apr 2016 16:38:06 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-4AF5FCCA-3CF2-4DE4-AEEC-AA46D1161309
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPad Mail (13F51a)
In-Reply-To: 
Date: Thu, 28 Apr 2016 01:38:03 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <386D7A98-17E4-45A5-AB02-EA31152CE3AB@thomasclausen.org>
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org>      <60BD2E9C-64D7-4444-B3A9-8D207EB4A86F@gmail.com> <144C7397-F19E-4FB0-959A-B5A030BD7A8A@fu-berlin. de>  
To: Justin Dean 
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 27 Apr 2016 23:38:11 -0000

--Apple-Mail-4AF5FCCA-3CF2-4DE4-AEEC-AA46D1161309
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I've argued in a few emails why that is a very bad idea:

1) any experiment developing extensions  will require to also update the spe=
cification for how to calculating the ICV, throwing backwards/forwards inter=
operability out the window.

2) the simple solution is to *not* "regenerate" messages (it is simply not n=
ecessary) but forward unmodified (preserving lay out, strictly) messages wit=
h "well defined mutable fields" (such as "a value of a TLV") which would (si=
nce we are not regenerating) be at the same place in the byte stream: at the=
 sender, at the recipient, and at all intermediaries. That allows for extens=
ions (as added by the source) to be covered by the ICV, *and* enables experi=
ments also with advanced stuff such as aggregate signatures, etc.

The whole "regeneration" approach doesn't bring anything, and complicates se=
curity considerably.

Sent from my iPad

> On 28 Apr 2016, at 01:24, Justin Dean  wrote:
>=20
> An alternative solution to checking integrity. The current icv draft is go=
od at validating messages from an original source. OLSRV2 and NHDP use this t=
o good effect. AODVV2 doesn't because the messages are regenerated; I belive=
 this to be the correct term as the message contains local information, path=
 information, and originator information. Getting the icv draft to work on f=
orwarded packets is ugly as they really are regenerated and should be. What w=
e want to do is secure the original source of information which is OrigAddr/=
target address and sequence number. Why not just attach a new aodv specific i=
cv TLV which uses THAT info and nothing else? The current icv TLV would/coul=
d still be used over the whole message hop by hop by each router, as the mes=
sages are regenerated.
>=20
> Justin
>=20
>=20
>> On Wed, Apr 27, 2016, 6:43 PM Jiazi YI  wrote:
>>> On Thu, Apr 28, 2016 at 12:19 AM, Lotte Steenbrink  wrote:
>>>=20
>>>> Am 28.04.2016 um 00:16 schrieb Christopher Dearlove :
>>>>=20
>>>> The more you have to zero out, the messier it gets, and the less secure=
 it gets (more things can be spoofed). I think that's about all I've got to a=
dd.
>>>>=20
>>>=20
>>> Of course. My question was just:
>>> * Do we want to come up with an exact description of how the zeroing out=
 should work now, with the short time we have left?
>>=20
>> If a meaningful security mechanism is required, yes.=20
>> I think the first thing to do is to cut as many mutable fields and option=
al fields as possible.=20
>>=20
>> best
>>=20
>> Jiazi
>> =20
>>> or
>>> * Do we mention in the draft that zeroing out has to happen somehow and l=
eave the nitty gritty to future work?
>>>=20
>>> At least that=E2=80=99s how I understood the options you laid out...
>>>=20
>>>> --=20
>>>> Christopher Dearlove
>>>> christopher.dearlove@gmail.com (iPhone)
>>>> chris@mnemosyne.demon.co.uk (home)
>>>>=20
>>>>=20
>>>>=20
>>>> -- =20
>>>> Christopher Dearlove
>>>> christopher.dearlove@gmail.com (iPhone)
>>>> chris@mnemosyne.demon.co.uk (home)
>>>> On 27 Apr 2016, at 22:46, Lotte Steenbrink  wrote:
>>>>=20
>>>>> Hi all,
>>>>> I=E2=80=99m currently revising the security considerations with regard=
s to the move from regeneration to forwarding, which depends on a decision b=
eing made on how/where we want to mention the possibility of zeroing out TLV=
s to calculate the ICV for the rest of a message=E2=80=99s contents (see sec=
ond * of my last e-mail). I=E2=80=99ve not found a decision on this in other=
 thread (please pardon me if I overlooked something), so I=E2=80=99ll bump t=
his thread and ask the WG for its opinions. (again, personally, the 2nd opti=
on outlined by Christopher seems more appealing to me)
>>>>>=20
>>>>> Regards,
>>>>> Lotte
>>>>>=20
>>>>>> Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink :
>>>>>>=20
>>>>>> Hi all,
>>>>>> to summarize:
>>>>>>=20
>>>>>> * AODVv2 message Type numbers should be in the Experimental type spac=
e and the AODVv2 TLV Types should be message type-specific. This also means c=
hanging the text regarding IANA actions and changing the text regarding what=
 the experiment is to something along the lines of =E2=80=9Cwe want to gathe=
r experience on how to make generic metric TLVs and ICVs that work with chan=
ging metric TV values happen with reactive protocols=E2=80=9D
>>>>>> * we=E2=80=99re undecided on (to quote Christopher) the "here's a mec=
hanism we haven't really thought through in detail, but at least we've defin=
ed one", or "we know the sort of thing we want, and we'll describe it, but r=
ather than produce something not quite right, we'll not go further=E2=80=9C d=
ecision on temporarily setting the metric value to 0 (i.e. the who and how).=
 (personally, I think I=E2=80=99d prefer the latter approach, but that=E2=80=
=99s an entirely gut feeling-based preference)
>>>>>>=20
>>>>>> Did I catch that correctly? If so, I=E2=80=99ll put together and sugg=
est some text for the first point as soon as I get home and in case there ha=
s been a decision on the second by then, I=E2=80=99ll try to tackle that one=
 too. :)
>>>>>>=20
>>>>>> Best regards, Lotte
>>>>>>=20
>>>>>>> Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) :
>>>>>>>=20
>>>>>>> I have no problem with that. I was trying to lay out the issues with=
out muddying the water with my preference.
>>>>>>> =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 B=
addow, Chelmsford, Essex CM2 8HN.
>>>>>>> www.baesystems.com/ai
>>>>>>>=20
>>>>>>> BAE Systems Applied Intelligence Limited
>>>>>>> Registered in England & Wales No: 01337451
>>>>>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>>>>>>>=20
>>>>>>> =20
>>>>>>> From: Justin Dean [mailto:bebemaster@gmail.com]=20
>>>>>>> Sent: 22 April 2016 15:35
>>>>>>> To: Dearlove, Christopher (UK)
>>>>>>> Cc: Thomas Heide Clausen; Mobile Ad Hoc Networks mailing list
>>>>>>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-=
ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>>>> =20
>>>>>>> =20
>>>>>>> *** WARNING ***
>>>>>>> This message originates from outside our organisation, either from a=
n external partner or the internet.
>>>>>>> Consider carefully whether you should click on any links, open any a=
ttachments or reply.
>>>>>>> For information regarding Red Flags that you can look out for in ema=
ils you receive, click here.
>>>>>>> If you feel the email is suspicious, please follow this process.
>>>>>>>=20
>>>>>>> Speaking as participant.
>>>>>>>=20
>>>>>>> I kind of like the idea of using the experimental message type space=
.  We only have a limited amount of these message types.  The TLV assignment=
s could just use the message type specific space and there isn't an issue th=
ere.  IANA wouldn't assign a number but I don't see why the document couldn'=
t specify the experimental numbers it was going to use so other future near t=
erm experiential protocols could do the same and generally avoid conflict.  I=
f the experiment is successful IANA assignments could be made.  Functionally=
 no real difference with protections vs long term usage of limited space.
>>>>>>> =20
>>>>>>> Justin
>>>>>>> =20
>>>>>>> On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK)  wrote:
>>>>>>> There's rather a contradiction between the concepts of a definition o=
f a protocol, even Experimental, and experimental space, which usually assum=
es that the user can do what he or she likes in it.
>>>>>>>=20
>>>>>>> But chewing up messages types (how many, 3?) of which there are rela=
tively few for experimental is long term a problem, although short term not.=

>>>>>>>=20
>>>>>>> TLV space is easier in two regards. It's bigger (though the prime re=
al estate of type extension zero isn't) and can have message type specific T=
LVs.
>>>>>>>=20
>>>>>>> So TLVS can actually be invisible, if that option is chosen. For mes=
sages something has to give. Least bad option is again one of those we shoul=
d discuss, but time ...
>>>>>>>=20
>>>>>>> (To be precise, messages types from 224 are defined in RFC 5444 as "=
 Experimental Use", of which BCP 26 says "Similar to private or local use on=
ly, with the  purpose being to facilitate experimentation." The alternative 0=
-223 space is Expert Review. IANA still thinks the experts are Joe Macker an=
d the recused Stan Ratliff. But that's a soluble nit.)
>>>>>>>=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 B=
addow, 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
>>>>>>> -----Original Message-----
>>>>>>> From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org]
>>>>>>> Sent: 22 April 2016 14:21
>>>>>>> To: Dearlove, Christopher (UK)
>>>>>>> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>>>>>>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-=
ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>>>>=20
>>>>>>> ----------------------! WARNING ! ---------------------- This messag=
e originates from outside our organisation, either from an external partner o=
r from the internet.
>>>>>>> Consider carefully whether you should click on any links, open any a=
ttachments or reply.
>>>>>>> Follow the 'Report Suspicious Emails' link on IT matters for instruc=
tions on reporting suspicious email messages.
>>>>>>> --------------------------------------------------------
>>>>>>>=20
>>>>>>>=20
>>>>>>> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK)  wrote:
>>>>>>> >
>>>>>>> > Once you're entirely in AODV2's own space, and AODVv2 is experimen=
tal (working assumption for this discussion) you have more liberty.
>>>>>>> >
>>>>>>>=20
>>>>>>> Yep.
>>>>>>>=20
>>>>>>> Taken somewhat by surprise both by the sudden "rush" and the experim=
ental maturity level, I am wondering (and haven't thought through) about exp=
erimental space vs non-experimental (for message types, and consequently for=
 message type specific TLV types).
>>>>>>>=20
>>>>>>> I think that if the AODVv2 experiment specifies the use of Message t=
ypes from the Experimental message type space without making actual registra=
tions in the IANA registry, AND the use of type specific TLV types, this bec=
omes a non-issue entirely (by design, this is precisely what that experiment=
al space is for)
>>>>>>>=20
>>>>>>> Whereas, as you point out, the alternative is a "can open - worms ev=
erywhere" situation that I think time is too short to solve?
>>>>>>>=20
>>>>>>> Thomas
>>>>>>>=20
>>>>>>>=20
>>>>>>> > Then you could try specifying it. But with a very good chance of p=
roducing something you later decide you should have done differently.
>>>>>>> >
>>>>>>> > I honestly don't know which would go down better (or less badly) -=
 "here's a mechanism we haven't really thought through in detail, but at lea=
st we've defined one", or "we know the sort of thing we want, and we'll desc=
ribe it, but rather than produce something not quite right, we'll not go fur=
ther".
>>>>>>> >
>>>>>>> > --
>>>>>>> > 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, Grea=
t 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 7Y=
P
>>>>>>> >
>>>>>>> >
>>>>>>> > -----Original Message-----
>>>>>>> > From: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]
>>>>>>> > Sent: 22 April 2016 13:59
>>>>>>> > To: Mobile Ad Hoc Networks mailing list
>>>>>>> > Cc: Henning Rogge; Dearlove, Christopher (UK)
>>>>>>> > Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draf=
t-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>>>> >
>>>>>>> > ----------------------! WARNING ! ---------------------- This mess=
age originates from outside our organisation, either from an external partne=
r or from the internet.
>>>>>>> > Consider carefully whether you should click on any links, open any=
 attachments or reply.
>>>>>>> > Follow the 'Report Suspicious Emails' link on IT matters for instr=
uctions on reporting suspicious email messages.
>>>>>>> > --------------------------------------------------------
>>>>>>> >
>>>>>>> > Hello Christopher,
>>>>>>> >
>>>>>>> >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) :
>>>>>>> >>
>>>>>>> >> Just be careful to note that this concept is as currently being d=
iscussed (a) specific to AODVv2, and (b) not an application of 7182, which h=
as no knowledge of special TLVs.
>>>>>>> >>
>>>>>>> >> This is something we'd want to get right, and need to get right i=
f in any space not specific to ADODVv2, because getting it wrong produces fu=
ture problems.
>>>>>>> >
>>>>>>> > Makes sense.
>>>>>>> >
>>>>>>> >> I can see some possible approaches, none is ideal and we're rathe=
r out
>>>>>>> >> of time to specify. But this is experimental, so I think we might=
 be
>>>>>>> >> able to indicate the shape of the solution without specifying it,=

>>>>>>> >> which would be a different RFC, under a bit less time pressure.
>>>>>>> >> (Extensions to existing protocols like 7182 would naturally be in=

>>>>>>> >> scope rechartered I think.)
>>>>>>> >>
>>>>>>> >> To indicate the range that's open, here are two possible ideas, o=
ne of which has an impact now, so needs to be agreed. Note that I'm not sugg=
esting (in fact quite the opposite) defining an extension to 7182 here, rath=
er enabling such an extension, if written, to "do the right thing".
>>>>>>> >> - We have an extension to 7182 that says "zero out all value octe=
ts in protocol specific TLVs. That requires now putting the AODVv2 metric TL=
V in that space.
>>>>>>> >
>>>>>>> > Just to make sure that I understood you correctly=E2=80=93 =E2=80=9C=
that space=E2=80=9D meaning making the AODVv2 metric TLV protocol specific? (=
By =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m referring to the gene=
ric TLV we=E2=80=99ve been talking about on this list earlier this week).
>>>>>>> >
>>>>>>> >> - We have an extension to 7182 that adds extra material to the va=
lue field that indicates (TBD how, by position with sanity check that this i=
s TLV value perhaps?) which octets are to be zeroed out before the ICV is ca=
lculated.
>>>>>>> >
>>>>>>> > The way I understand that approach, it wouldn=E2=80=99t warrant an=
y action from AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set t=
he Metric value to zero=E2=80=9D (leaving the nitty gritty of how this would=
 be done in detail to future work)=E2=80=A6 Is that correct?
>>>>>>> >
>>>>>>> >>
>>>>>>> >> We do not have the time to specify this in an acceptable manner w=
ithin two weeks though. But the security consideration section could say som=
ething along the lines of "this enables the use of an ICV defined to zero ou=
t these octets=E2=80=9C.
>>>>>>> >
>>>>>>> > Okay. :)
>>>>>>> >
>>>>>>> > Best regards,
>>>>>>> > Lotte
>>>>>>> >
>>>>>>> >>
>>>>>>> >> --
>>>>>>> >> 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, Gre=
at Baddow, Chelmsford, Essex CM2 8HN.
>>>>>>> >> www.baesystems.com/ai
>>>>>>> >> BAE Systems Applied Intelligence Limited Registered in England & W=
ales
>>>>>>> >> No: 01337451 Registered Office: Surrey Research Park, Guildford,
>>>>>>> >> Surrey, GU2 7YP
>>>>>>> >>
>>>>>>> >> -----Original Message-----
>>>>>>> >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte
>>>>>>> >> Steenbrink
>>>>>>> >> Sent: 22 April 2016 10:28
>>>>>>> >> To: Henning Rogge
>>>>>>> >> Cc: Mobile Ad Hoc Networks mailing list
>>>>>>> >> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>>>>>>> >> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)=

>>>>>>> >>
>>>>>>> >> ----------------------! WARNING ! ---------------------- This mes=
sage originates from outside our organisation, either from an external partn=
er or from the internet.
>>>>>>> >> Consider carefully whether you should click on any links, open an=
y attachments or reply.
>>>>>>> >> Follow the 'Report Suspicious Emails' link on IT matters for inst=
ructions on reporting suspicious email messages.
>>>>>>> >> --------------------------------------------------------
>>>>>>> >>
>>>>>>> >> *** WARNING ***
>>>>>>> >> EXTERNAL EMAIL -- This message originates from outside our organi=
zation.
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> Hi Henning,
>>>>>>> >>
>>>>>>> >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge :=

>>>>>>> >>>
>>>>>>> >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>>>>>>> >>>  wrote:
>>>>>>> >>>> Hi Thomas,
>>>>>>> >>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregenerat=
ion=E2=80=9D language
>>>>>>> >>>> in the first place is that we=E2=80=99ve been told that wheneve=
r one bit in
>>>>>>> >>>> the message (apart from its header) is changed, the entire thin=
g has to be regenerated.
>>>>>>> >>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been=
 misunderstanding
>>>>>>> >>>> each other for more than a year. :( Anyway, it seems like we=E2=
=80=99re
>>>>>>> >>>> getting close now, so yay.
>>>>>>> >>>
>>>>>>> >>> "Modifying" the binary message instead of parsing and generating=
 a
>>>>>>> >>> new one will be difficult as soon someone writes an extension to=

>>>>>>> >>> AODVv2 that adds more TLVs to the message.
>>>>>>> >>
>>>>>>> >> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=
=99s what you explained to me when I got confused about the topic last sprin=
g=E2=80=A6 But=E2=80=93 even if a message contains TLVs that the AODVv2 impl=
ementation handling it doesn=E2=80=99t understand, it will still be able to r=
ecognize the Metric TLV, right? Isn=E2=80=99t that the nifty thing about RFC=
5444? So, while we really shouldn=E2=80=99t write =E2=80=9Cbefore calculatin=
g the ICV, set the n-th 4 octets to 0=E2=80=9D, we might say =E2=80=9Cidenti=
fy the octets that make up the metric value and set those to 0=E2=80=9D?
>>>>>>> >>
>>>>>>> >> Best regards,
>>>>>>> >> Lotte
>>>>>>> >>
>>>>>>> >>> Henning Rogge
>>>>>>> >>
>>>>>>> >> _______________________________________________
>>>>>>> >> 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
>>>>>>>=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
>>>>>> _______________________________________________
>>>>>> 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
>>> _______________________________________________
>>> 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-4AF5FCCA-3CF2-4DE4-AEEC-AA46D1161309
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I've argued in a few emails why that i=
s a very bad idea:

1) any experiment developing ext=
ensions  will require to also update the specification for how to calcu=
lating the ICV, throwing backwards/forwards interoperability out the window.=


2) the simple solution is to *not* "regenerate" me=
ssages (it is simply not necessary) but forward unmodified (preserving lay o=
ut, strictly) messages with "well defined mutable fields" (such as "a value o=
f a TLV") which would (since we are not regenerating) be at the same place i=
n the byte stream: at the sender, at the recipient, and at all intermediarie=
s. That allows for extensions (as added by the source) to be covered by the I=
CV, *and* enables experiments also with advanced stuff such as aggregate sig=
natures, etc.

The whole "regeneration" approach doesn't bring anythin=
g, and complicates security considerably.

Sent from my iP=
ad
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
=

--Apple-Mail-B8995991-87BC-464C-979F-04C752C98BC8--


From nobody Wed Apr 27 17:04: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 12D82120047 for ; Wed, 27 Apr 2016 17:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.715
X-Spam-Level: 
X-Spam-Status: No, score=-3.715 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, 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 dQNrWo3w8akz for ; Wed, 27 Apr 2016 17:04:51 -0700 (PDT)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 19EBB12D509 for ; Wed, 27 Apr 2016 17:04:50 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=iV7ybnLzL4BgzwWfLt28oDFaAVcDbhYfKsYv9x9CG7SyFfHApBUdp49s9WdS08l5; h=Received:Subject:To:References:Cc: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-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1avZRj-0005WJ-MY; Wed, 27 Apr 2016 20:04:44 -0400
To: Justin Dean 
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org>      <60BD2E9C-64D7-4444-B3A9-8D207EB4A86F@gmail.com> <144C7397-F19E-4FB0-959A-B5A030BD7A8A@fu-berlin.de>  
From: Charlie Perkins 
Message-ID: <883f2cf1-ffc7-9910-d80b-e3b610353273@earthlink.net>
Date: Wed, 27 Apr 2016 17:04:40 -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="------------17117D229B04BAA25E984EC9"
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7e874cf94df1ac40b0232fa76bcf751fd350badd9bab72f9c350badd9bab72f9c
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: Thu, 28 Apr 2016 00:04:56 -0000

This is a multi-part message in MIME format.
--------------17117D229B04BAA25E984EC9
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hello Justin,

I think a new AODV-specific ICV is probably the right answer.  It would 
be nice to get some help generating the proper settings for all of the 
RFC 7182 fields to support this approach.  If not that, could we fall 
back on RFC 4868, which seems pretty straightforward?

Regards,
Charlie P.

On 4/27/2016 4:24 PM, Justin Dean wrote:
>
> An alternative solution to checking integrity. The current icv draft 
> is good at validating messages from an original source. OLSRV2 and 
> NHDP use this to good effect. AODVV2 doesn't because the messages are 
> regenerated; I belive this to be the correct term as the message 
> contains local information, path information, and originator 
> information. Getting the icv draft to work on forwarded packets is 
> ugly as they really are regenerated and should be. What we want to do 
> is secure the original source of information which is OrigAddr/target 
> address and sequence number. Why not just attach a new aodv specific 
> icv TLV which uses THAT info and nothing else? The current icv TLV 
> would/could still be used over the whole message hop by hop by each 
> router, as the messages are regenerated.
>
> Justin
>
>
> On Wed, Apr 27, 2016, 6:43 PM Jiazi YI  > wrote:
>
>     On Thu, Apr 28, 2016 at 12:19 AM, Lotte Steenbrink
>          > wrote:
>
>
>>         Am 28.04.2016 um 00:16 schrieb Christopher Dearlove
>>         >         >:
>>
>>         The more you have to zero out, the messier it gets, and the
>>         less secure it gets (more things can be spoofed). I think
>>         that's about all I've got to add.
>>
>
>         Of course. My question was just:
>         * Do we want to come up with an exact description of how the
>         zeroing out should work now, with the short time we have left?
>
>
>     If a meaningful security mechanism is required, yes.
>     I think the first thing to do is to cut as many mutable fields and
>     optional fields as possible.
>
>     best
>
>     Jiazi
>
>         or
>         * Do we mention in the draft that zeroing out has to happen
>         somehow and leave the nitty gritty to future work?
>
>         At least that’s how I understood the options you laid out...
>
>>         -- 
>>         Christopher Dearlove
>>         christopher.dearlove@gmail.com
>>          (iPhone)
>>         chris@mnemosyne.demon.co.uk
>>          (home)
>>
>>
>>
>>         -- 
>>         Christopher Dearlove
>>         christopher.dearlove@gmail.com
>>          (iPhone)
>>         chris@mnemosyne.demon.co.uk
>>          (home)
>>         On 27 Apr 2016, at 22:46, Lotte Steenbrink
>>         >         > wrote:
>>
>>>         Hi all,
>>>         I’m currently revising the security considerations with
>>>         regards to the move from regeneration to forwarding, which
>>>         depends on a decision being made on how/where we want to
>>>         mention the possibility of zeroing out TLVs to calculate the
>>>         ICV for the rest of a message’s contents (see second * of my
>>>         last e-mail). I’ve not found a decision on this in other
>>>         thread (please pardon me if I overlooked something), so I’ll
>>>         bump this thread and ask the WG for its opinions. (again,
>>>         personally, the 2nd option outlined by Christopher seems
>>>         more appealing to me)
>>>
>>>         Regards,
>>>         Lotte
>>>
>>>>         Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink
>>>>         >>>         >:
>>>>
>>>>         Hi all,
>>>>         to summarize:
>>>>
>>>>         * AODVv2 message Type numbers should be in the Experimental
>>>>         type space and the AODVv2 TLV Types should be message
>>>>         type-specific. This also means changing the text regarding
>>>>         IANA actions and changing the text regarding what the
>>>>         experiment is to something along the lines of “we want to
>>>>         gather experience on how to make generic metric TLVs and
>>>>         ICVs that work with changing metric TV values happen with
>>>>         reactive protocols”
>>>>         * we’re undecided on (to quote Christopher) the "here's a
>>>>         mechanism we haven't really thought through in detail, but
>>>>         at least we've defined one", or "we know the sort of thing
>>>>         we want, and we'll describe it, but rather than produce
>>>>         something not quite right, we'll not go further“ decision
>>>>         on temporarily setting the metric value to 0 (i.e. the who
>>>>         and how). (personally, I think I’d prefer the latter
>>>>         approach, but that’s an entirely gut feeling-based preference)
>>>>
>>>>         Did I catch that correctly? If so, I’ll put together and
>>>>         suggest some text for the first point as soon as I get home
>>>>         and in case there has been a decision on the second by
>>>>         then, I’ll try to tackle that one too. :)
>>>>
>>>>         Best regards, Lotte
>>>>
>>>>>         Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK)
>>>>>         >>>>         >:
>>>>>
>>>>>         I have no problem with that. I was trying to lay out the
>>>>>         issues without muddying the water with my preference.
>>>>>
>>>>>         *--*
>>>>>
>>>>>         *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:*22 April 2016 15:35
>>>>>         *To:*Dearlove, Christopher (UK)
>>>>>         *Cc:*Thomas Heide Clausen; Mobile Ad Hoc Networks mailing list
>>>>>         *Subject:*Re: [manet] On Forwarding-and-regeneration (was:
>>>>>         Re: draft-ietf-manet-aodvv2-13 review - a couple of big
>>>>>         ticket Items)
>>>>>         **** 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, clickhere
>>>>>         .//
>>>>>         /If you feel the email is suspicious, please followthis
>>>>>         process
>>>>>         .//
>>>>>
>>>>>         Speaking as participant.
>>>>>
>>>>>         I kind of like the idea of using the experimental message
>>>>>         type space.  We only have a limited amount of these
>>>>>         message types.  The TLV assignments could just use the
>>>>>         message type specific space and there isn't an issue
>>>>>         there. IANA wouldn't assign a number but I don't see why
>>>>>         the document couldn't specify the experimental numbers it
>>>>>         was going to use so other future near term experiential
>>>>>         protocols could do the same and generally avoid conflict. 
>>>>>         If the experiment is successful IANA assignments could be
>>>>>         made. Functionally no real difference with protections vs
>>>>>         long term usage of limited space.
>>>>>         Justin
>>>>>         On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher
>>>>>         (UK) >>>>         > wrote:
>>>>>         There's rather a contradiction between the concepts of a
>>>>>         definition of a protocol, even Experimental, and
>>>>>         experimental space, which usually assumes that the user
>>>>>         can do what he or she likes in it.
>>>>>
>>>>>         But chewing up messages types (how many, 3?) of which
>>>>>         there are relatively few for experimental is long term a
>>>>>         problem, although short term not.
>>>>>
>>>>>         TLV space is easier in two regards. It's bigger (though
>>>>>         the prime real estate of type extension zero isn't) and
>>>>>         can have message type specific TLVs.
>>>>>
>>>>>         So TLVS can actually be invisible, if that option is
>>>>>         chosen. For messages something has to give. Least bad
>>>>>         option is again one of those we should discuss, but time ...
>>>>>
>>>>>         (To be precise, messages types from 224 are defined in RFC
>>>>>         5444 as " Experimental Use", of which BCP 26 says "Similar
>>>>>         to private or local use only, with the  purpose being to
>>>>>         facilitate experimentation." The alternative 0-223 space
>>>>>         is Expert Review. IANA still thinks the experts are Joe
>>>>>         Macker and the recused Stan Ratliff. But that's a soluble
>>>>>         nit.)
>>>>>
>>>>>         --
>>>>>         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
>>>>>
>>>>>
>>>>>         -----Original Message-----
>>>>>         From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org
>>>>>         ]
>>>>>         Sent: 22 April 2016 14:21
>>>>>         To: Dearlove, Christopher (UK)
>>>>>         Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>>>>>         Subject: Re: [manet] On Forwarding-and-regeneration (was:
>>>>>         Re: draft-ietf-manet-aodvv2-13 review - a couple of big
>>>>>         ticket Items)
>>>>>
>>>>>         ----------------------! WARNING ! ----------------------
>>>>>         This message originates from outside our organisation,
>>>>>         either from an external partner or from the internet.
>>>>>         Consider carefully whether you should click on any links,
>>>>>         open any attachments or reply.
>>>>>         Follow the 'Report Suspicious Emails' link on IT matters
>>>>>         for instructions on reporting suspicious email messages.
>>>>>         --------------------------------------------------------
>>>>>
>>>>>
>>>>>         > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK)
>>>>>         >>>>         > wrote:
>>>>>         >
>>>>>         > Once you're entirely in AODV2's own space, and AODVv2 is
>>>>>         experimental (working assumption for this discussion) you
>>>>>         have more liberty.
>>>>>         >
>>>>>
>>>>>         Yep.
>>>>>
>>>>>         Taken somewhat by surprise both by the sudden "rush" and
>>>>>         the experimental maturity level, I am wondering (and
>>>>>         haven't thought through) about experimental space vs
>>>>>         non-experimental (for message types, and consequently for
>>>>>         message type specific TLV types).
>>>>>
>>>>>         I think that if the AODVv2 experiment specifies the use of
>>>>>         Message types from the Experimental message type space
>>>>>         without making actual registrations in the IANA registry,
>>>>>         AND the use of type specific TLV types, this becomes a
>>>>>         non-issue entirely (by design, this is precisely what that
>>>>>         experimental space is for)
>>>>>
>>>>>         Whereas, as you point out, the alternative is a "can open
>>>>>         - worms everywhere" situation that I think time is too
>>>>>         short to solve?
>>>>>
>>>>>         Thomas
>>>>>
>>>>>
>>>>>         > Then you could try specifying it. But with a very good
>>>>>         chance of producing something you later decide you should
>>>>>         have done differently.
>>>>>         >
>>>>>         > I honestly don't know which would go down better (or
>>>>>         less badly) - "here's a mechanism we haven't really
>>>>>         thought through in detail, but at least we've defined
>>>>>         one", or "we know the sort of thing we want, and we'll
>>>>>         describe it, but rather than produce something not quite
>>>>>         right, we'll not go further".
>>>>>         >
>>>>>         > --
>>>>>         > 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
>>>>>         >
>>>>>         >
>>>>>         > -----Original Message-----
>>>>>         > From: Lotte Steenbrink
>>>>>         [mailto:lotte.steenbrink@fu-berlin.de
>>>>>         ]
>>>>>         > Sent: 22 April 2016 13:59
>>>>>         > To: Mobile Ad Hoc Networks mailing list
>>>>>         > Cc: Henning Rogge; Dearlove, Christopher (UK)
>>>>>         > Subject: Re: [manet] On Forwarding-and-regeneration
>>>>>         (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of
>>>>>         big ticket Items)
>>>>>         >
>>>>>         > ----------------------! WARNING ! ----------------------
>>>>>         This message originates from outside our organisation,
>>>>>         either from an external partner or from the internet.
>>>>>         > Consider carefully whether you should click on any
>>>>>         links, open any attachments or reply.
>>>>>         > Follow the 'Report Suspicious Emails' link on IT matters
>>>>>         for instructions on reporting suspicious email messages.
>>>>>         > --------------------------------------------------------
>>>>>         >
>>>>>         > Hello Christopher,
>>>>>         >
>>>>>         >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher
>>>>>         (UK) >>>>         >:
>>>>>         >>
>>>>>         >> Just be careful to note that this concept is as
>>>>>         currently being discussed (a) specific to AODVv2, and (b)
>>>>>         not an application of 7182, which has no knowledge of
>>>>>         special TLVs.
>>>>>         >>
>>>>>         >> This is something we'd want to get right, and need to
>>>>>         get right if in any space not specific to ADODVv2, because
>>>>>         getting it wrong produces future problems.
>>>>>         >
>>>>>         > Makes sense.
>>>>>         >
>>>>>         >> I can see some possible approaches, none is ideal and
>>>>>         we're rather out
>>>>>         >> of time to specify. But this is experimental, so I
>>>>>         think we might be
>>>>>         >> able to indicate the shape of the solution without
>>>>>         specifying it,
>>>>>         >> which would be a different RFC, under a bit less time
>>>>>         pressure.
>>>>>         >> (Extensions to existing protocols like 7182 would
>>>>>         naturally be in
>>>>>         >> scope rechartered I think.)
>>>>>         >>
>>>>>         >> To indicate the range that's open, here are two
>>>>>         possible ideas, one of which has an impact now, so needs
>>>>>         to be agreed. Note that I'm not suggesting (in fact quite
>>>>>         the opposite) defining an extension to 7182 here, rather
>>>>>         enabling such an extension, if written, to "do the right
>>>>>         thing".
>>>>>         >> - We have an extension to 7182 that says "zero out all
>>>>>         value octets in protocol specific TLVs. That requires now
>>>>>         putting the AODVv2 metric TLV in that space.
>>>>>         >
>>>>>         > Just to make sure that I understood you correctly– “that
>>>>>         space” meaning making the AODVv2 metric TLV protocol
>>>>>         specific? (By “the aodvv2 metric tlv” I’m referring to the
>>>>>         generic TLV we’ve been talking about on this list earlier
>>>>>         this week).
>>>>>         >
>>>>>         >> - We have an extension to 7182 that adds extra material
>>>>>         to the value field that indicates (TBD how, by position
>>>>>         with sanity check that this is TLV value perhaps?) which
>>>>>         octets are to be zeroed out before the ICV is calculated.
>>>>>         >
>>>>>         > The way I understand that approach, it wouldn’t warrant
>>>>>         any action from AODVv2 besides saying “if you calculate
>>>>>         the ICV, set the Metric value to zero” (leaving the nitty
>>>>>         gritty of how this would be done in detail to future
>>>>>         work)… Is that correct?
>>>>>         >
>>>>>         >>
>>>>>         >> We do not have the time to specify this in an
>>>>>         acceptable manner within two weeks though. But the
>>>>>         security consideration section could say something along
>>>>>         the lines of "this enables the use of an ICV defined to
>>>>>         zero out these octets“.
>>>>>         >
>>>>>         > Okay. :)
>>>>>         >
>>>>>         > Best regards,
>>>>>         > Lotte
>>>>>         >
>>>>>         >>
>>>>>         >> --
>>>>>         >> 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
>>>>>         >>
>>>>>         >> -----Original Message-----
>>>>>         >> From: manet [mailto:manet-bounces@ietf.org
>>>>>         ] On Behalf Of Lotte
>>>>>         >> Steenbrink
>>>>>         >> Sent: 22 April 2016 10:28
>>>>>         >> To: Henning Rogge
>>>>>         >> Cc: Mobile Ad Hoc Networks mailing list
>>>>>         >> Subject: Re: [manet] On Forwarding-and-regeneration
>>>>>         (was: Re:
>>>>>         >> draft-ietf-manet-aodvv2-13 review - a couple of big
>>>>>         ticket Items)
>>>>>         >>
>>>>>         >> ----------------------! WARNING !
>>>>>         ---------------------- This message originates from
>>>>>         outside our organisation, either from an external partner
>>>>>         or from the internet.
>>>>>         >> Consider carefully whether you should click on any
>>>>>         links, open any attachments or reply.
>>>>>         >> Follow the 'Report Suspicious Emails' link on IT
>>>>>         matters for instructions on reporting suspicious email
>>>>>         messages.
>>>>>         >> --------------------------------------------------------
>>>>>         >>
>>>>>         >> *** WARNING ***
>>>>>         >> EXTERNAL EMAIL -- This message originates from outside
>>>>>         our organization.
>>>>>         >>
>>>>>         >>
>>>>>         >> Hi Henning,
>>>>>         >>
>>>>>         >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge
>>>>>         >:
>>>>>         >>>
>>>>>         >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>>>>>         >>> >>>>         > wrote:
>>>>>         >>>> Hi Thomas,
>>>>>         >>>> Can it?! Iirc, the reason why we adopted the
>>>>>         “regeneration” language
>>>>>         >>>> in the first place is that we’ve been told that
>>>>>         whenever one bit in
>>>>>         >>>> the message (apart from its header) is changed, the
>>>>>         entire thing has to be regenerated.
>>>>>         >>>> I’m starting to get the feeling we’ve just been
>>>>>         misunderstanding
>>>>>         >>>> each other for more than a year. :( Anyway, it seems
>>>>>         like we’re
>>>>>         >>>> getting close now, so yay.
>>>>>         >>>
>>>>>         >>> "Modifying" the binary message instead of parsing and
>>>>>         generating a
>>>>>         >>> new one will be difficult as soon someone writes an
>>>>>         extension to
>>>>>         >>> AODVv2 that adds more TLVs to the message.
>>>>>         >>
>>>>>         >> D’oh, right. Yeah, if I remember it correctly, that’s
>>>>>         what you explained to me when I got confused about the
>>>>>         topic last spring… But– even if a message contains TLVs
>>>>>         that the AODVv2 implementation handling it doesn’t
>>>>>         understand, it will still be able to recognize the Metric
>>>>>         TLV, right? Isn’t that the nifty thing about RFC5444? So,
>>>>>         while we really shouldn’t write “before calculating the
>>>>>         ICV, set the n-th 4 octets to 0”, we might say “identify
>>>>>         the octets that make up the metric value and set those to 0”?
>>>>>         >>
>>>>>         >> Best regards,
>>>>>         >> Lotte
>>>>>         >>
>>>>>         >>> Henning Rogge
>>>>>         >>
>>>>>         >> _______________________________________________
>>>>>         >> 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
>>>>>         _______________________________________________
>>>>>         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
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


--------------17117D229B04BAA25E984EC9
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello Justin,

    
I think a new AODV-specific ICV is probably the right answer.  It
      would be nice to get some help generating the proper settings for
      all of the RFC 7182 fields to support this approach.  If not that,
      could we fall back on RFC 4868, which seems pretty
      straightforward?

    

    
Regards,

      Charlie P.

    

    
On 4/27/2016 4:24 PM, Justin Dean
      wrote:

    

    

      
      
An alternative solution to checking integrity. The
        current icv draft is good at validating messages from an
        original source. OLSRV2 and NHDP use this to good effect. AODVV2
        doesn't because the messages are regenerated; I belive this to
        be the correct term as the message contains local information,
        path information, and originator information. Getting the icv
        draft to work on forwarded packets is ugly as they really are
        regenerated and should be. What we want to do is secure the
        original source of information which is OrigAddr/target address
        and sequence number. Why not just attach a new aodv specific icv
        TLV which uses THAT info and nothing else? The current icv TLV
        would/could still be used over the whole message hop by hop by
        each router, as the messages are regenerated.

      
Justin

      

      

        
On Wed, Apr 27, 2016, 6:43 PM Jiazi YI <ietf@jiaziyi.com>
          wrote:

        

        

          

            

              
On Thu, Apr 28, 2016 at 12:19 AM,
                Lotte Steenbrink <lotte.steenbrink@fu-berlin.de>
                wrote:

                

                  


                    

                        

                          
Am 28.04.2016 um 00:16 schrieb
                            Christopher Dearlove <christopher.dearlove@gmail.com>:

                          

                          

                            

                              

                              

                                
The more you have to zero out, the
                                  messier it gets, and the less secure
                                  it gets (more things can be spoofed).
                                  I think that's about all I've got to
                                  add.

                                  

                                

                              

                            

                          

                        

                        


                        

                      
                      

                        
Of course. My question was just:

                        
* Do we want to come up with an exact
                          description of how the zeroing out should work
                          now, with the short time we have left?

                      

                    

                  

                

                


                

              

            

          

          

            

              

                
If a meaningful security mechanism is required,
                  yes. 

                
I think the first thing to do is to cut as many
                  mutable fields and optional fields as possible. 

                


                

                
best

              

            

          

          

            

              

                


                

                
Jiazi

              

            

          

          

            

              

                
 

                

                  

                    

                      

                        
or

                        
* Do we mention in the draft that zeroing
                          out has to happen somehow and leave the nitty
                          gritty to future work?

                        


                        

                        
At least that’s how I understood the
                          options you laid out...

                      

                      

                        


                          

                            

                              

                                

                                  
-- 
                                    
Christopher Dearlove

                                    
                                    
                                  

                                  


                                    


                                      

                                      --  
                                      
Christopher Dearlove

                                      
                                      
                                    

                                    On 27 Apr 2016, at 22:46, Lotte
                                    Steenbrink <lotte.steenbrink@fu-berlin.de>
                                    wrote:

                                    

                                  

                                  

                                    

                                      Hi all,
                                      
I’m currently revising the
                                        security considerations with
                                        regards to the move from
                                        regeneration to forwarding,
                                        which depends on a decision
                                        being made on how/where we want
                                        to mention the possibility of
                                        zeroing out TLVs to calculate
                                        the ICV for the rest of a
                                        message’s contents (see second *
                                        of my last e-mail). I’ve not
                                        found a decision on this in
                                        other thread (please pardon me
                                        if I overlooked something), so
                                        I’ll bump this thread and ask
                                        the WG for its opinions. (again,
                                        personally, the 2nd option
                                        outlined by Christopher seems
                                        more appealing to me)

                                      


                                      

                                      
Regards,

                                      
Lotte

                                      


                                        

                                          

                                            
Am 22.04.2016 um 18:26
                                              schrieb Lotte Steenbrink
                                              <lotte.steenbrink@fu-berlin.de>:

                                            

                                            

                                              
Hi all,
                                                
to summarize:

                                                


                                                

                                                
* AODVv2 message
                                                  Type numbers should be
                                                  in the Experimental
                                                  type space and the
                                                  AODVv2 TLV Types
                                                  should be message
                                                  type-specific. This
                                                  also means changing
                                                  the text regarding
                                                  IANA actions and
                                                  changing the text
                                                  regarding what the
                                                  experiment is to
                                                  something along the
                                                  lines of “we want to
                                                  gather experience on
                                                  how to make generic
                                                  metric TLVs and ICVs
                                                  that work with
                                                  changing metric TV
                                                  values happen with
                                                  reactive protocols”

                                                
* we’re undecided
                                                  on (to quote
                                                  Christopher) the
                                                  "here's a mechanism we
                                                  haven't really thought
                                                  through in detail, but
                                                  at least we've defined
                                                  one", or "we know the
                                                  sort of thing we want,
                                                  and we'll describe it,
                                                  but rather than
                                                  produce something not
                                                  quite right, we'll not
                                                  go further“ decision
                                                  on temporarily setting
                                                  the metric value to 0
                                                  (i.e. the who and
                                                  how). (personally, I
                                                  think I’d prefer the
                                                  latter approach, but
                                                  that’s an entirely gut
                                                  feeling-based
                                                  preference)

                                                


                                                

                                                
Did I catch that
                                                  correctly? If so, I’ll
                                                  put together and
                                                  suggest some text for
                                                  the first point as
                                                  soon as I get home and
                                                  in case there has been
                                                  a decision on the
                                                  second by then, I’ll
                                                  try to tackle that one
                                                  too. :)

                                                


                                                

                                                
Best regards, Lotte

                                                


                                                

                                                

                                                  

                                                    
Am 22.04.2016
                                                      um 16:41 schrieb
                                                      Dearlove,
                                                      Christopher (UK)
                                                      <chris.dearlove@baesystems.com>:

                                                    

                                                    

                                                      

                                                        
I
                                                          have no
                                                          problem with
                                                          that. I was
                                                          trying to lay
                                                          out the issues
                                                          without
                                                          muddying the
                                                          water with my
                                                          preference.

                                                        
 

                                                        
--

                                                        
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: 22
                                                          April 2016
                                                          15:35

                                                          To: Dearlove,
                                                          Christopher
                                                          (UK)

                                                          Cc: Thomas
                                                          Heide Clausen;
                                                          Mobile Ad Hoc
                                                          Networks
                                                          mailing list

                                                          Subject: Re:
                                                          [manet] On
                                                          Forwarding-and-regeneration
                                                          (was: Re:
                                                          draft-ietf-manet-aodvv2-13
                                                          review - a
                                                          couple of big
                                                          ticket Items)

                                                        
 

                                                        

                                                          
 

                                                          

                                                          
***
                                                          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.

                                                          

                                                        

                                                        

                                                          
Speaking
                                                          as
                                                          participant.

                                                          

                                                          I kind of like
                                                          the idea of
                                                          using the
                                                          experimental
                                                          message type
                                                          space.  We
                                                          only have a
                                                          limited amount
                                                          of these
                                                          message
                                                          types.  The
                                                          TLV
                                                          assignments
                                                          could just use
                                                          the message
                                                          type specific
                                                          space and
                                                          there isn't an
                                                          issue there. 
                                                          IANA wouldn't
                                                          assign a
                                                          number but I
                                                          don't see why
                                                          the document
                                                          couldn't
                                                          specify the
                                                          experimental
                                                          numbers it was
                                                          going to use
                                                          so other
                                                          future near
                                                          term
                                                          experiential
                                                          protocols
                                                          could do the
                                                          same and
                                                          generally
                                                          avoid
                                                          conflict.  If
                                                          the experiment
                                                          is successful
                                                          IANA
                                                          assignments
                                                          could be
                                                          made. 
                                                          Functionally
                                                          no real
                                                          difference
                                                          with
                                                          protections vs
                                                          long term
                                                          usage of
                                                          limited space.

                                                          

                                                          
 

                                                          

                                                          

                                                          
Justin

                                                          

                                                          
 

                                                          

                                                          
On Fri,
                                                          Apr 22, 2016
                                                          at 9:35 AM,
                                                          Dearlove,
                                                          Christopher
                                                          (UK) <chris.dearlove@baesystems.com>
                                                          wrote:

                                                          
There's
                                                          rather a
                                                          contradiction
                                                          between the
                                                          concepts of a
                                                          definition of
                                                          a protocol,
                                                          even
                                                          Experimental,
                                                          and
                                                          experimental
                                                          space, which
                                                          usually
                                                          assumes that
                                                          the user can
                                                          do what he or
                                                          she likes in
                                                          it.

                                                          

                                                          But chewing up
                                                          messages types
                                                          (how many, 3?)
                                                          of which there
                                                          are relatively
                                                          few for
                                                          experimental
                                                          is long term a
                                                          problem,
                                                          although short
                                                          term not.

                                                          

                                                          TLV space is
                                                          easier in two
                                                          regards. It's
                                                          bigger (though
                                                          the prime real
                                                          estate of type
                                                          extension zero
                                                          isn't) and can
                                                          have message
                                                          type specific
                                                          TLVs.

                                                          

                                                          So TLVS can
                                                          actually be
                                                          invisible, if
                                                          that option is
                                                          chosen. For
                                                          messages
                                                          something has
                                                          to give. Least
                                                          bad option is
                                                          again one of
                                                          those we
                                                          should
                                                          discuss, but
                                                          time ...

                                                          

                                                          (To be
                                                          precise,
                                                          messages types
                                                          from 224 are
                                                          defined in RFC
                                                          5444 as "
                                                          Experimental
                                                          Use", of which
                                                          BCP 26 says
                                                          "Similar to
                                                          private or
                                                          local use
                                                          only, with
                                                          the  purpose
                                                          being to
                                                          facilitate
                                                          experimentation."
                                                          The
                                                          alternative
                                                          0-223 space is
                                                          Expert Review.
                                                          IANA still
                                                          thinks the
                                                          experts are
                                                          Joe Macker and
                                                          the recused
                                                          Stan Ratliff.
                                                          But that's a
                                                          soluble nit.)

                                                          

                                                          --

                                                          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

                                                          

                                                          

                                                          -----Original
                                                          Message-----

                                                          From:
                                                          Thomas Heide
                                                          Clausen
                                                          [mailto:ietf@thomasclausen.org]

                                                          Sent: 22
                                                          April 2016
                                                          14:21

                                                          To:
                                                          Dearlove,
                                                          Christopher
                                                          (UK)

                                                          

                                                          

                                                          
Cc: Lotte
                                                          Steenbrink;
                                                          Mobile Ad Hoc
                                                          Networks
                                                          mailing list

                                                          Subject: Re:
                                                          [manet] On
                                                          Forwarding-and-regeneration
                                                          (was: Re:
                                                          draft-ietf-manet-aodvv2-13
                                                          review - a
                                                          couple of big
                                                          ticket Items)

                                                          

----------------------! WARNING ! ---------------------- This message
                                                          originates
                                                          from outside
                                                          our
                                                          organisation,
                                                          either from an
                                                          external
                                                          partner or
                                                          from the
                                                          internet.

                                                          Consider
                                                          carefully
                                                          whether you
                                                          should click
                                                          on any links,
                                                          open any
                                                          attachments or
                                                          reply.

                                                          Follow the
                                                          'Report
                                                          Suspicious
                                                          Emails' link
                                                          on IT matters
                                                          for
                                                          instructions
                                                          on reporting
                                                          suspicious
                                                          email
                                                          messages.

--------------------------------------------------------

                                                          

                                                          

                                                          > On 22
                                                          avr. 2016, at
                                                          15:05,
                                                          Dearlove,
                                                          Christopher
                                                          (UK) <chris.dearlove@baesystems.com>
                                                          wrote:

                                                          >

                                                          > Once
                                                          you're
                                                          entirely in
                                                          AODV2's own
                                                          space, and
                                                          AODVv2 is
                                                          experimental
                                                          (working
                                                          assumption for
                                                          this
                                                          discussion)
                                                          you have more
                                                          liberty.

                                                          >

                                                          

                                                          Yep.

                                                          

                                                          Taken somewhat
                                                          by surprise
                                                          both by the
                                                          sudden "rush"
                                                          and the
                                                          experimental
                                                          maturity
                                                          level, I am
                                                          wondering (and
                                                          haven't
                                                          thought
                                                          through) about
                                                          experimental
                                                          space vs
                                                          non-experimental
                                                          (for message
                                                          types, and
                                                          consequently
                                                          for message
                                                          type specific
                                                          TLV types).

                                                          

                                                          I think that
                                                          if the AODVv2
                                                          experiment
                                                          specifies the
                                                          use of Message
                                                          types from the
                                                          Experimental
                                                          message type
                                                          space without
                                                          making actual
                                                          registrations
                                                          in the IANA
                                                          registry, AND
                                                          the use of
                                                          type specific
                                                          TLV types,
                                                          this becomes a
                                                          non-issue
                                                          entirely (by
                                                          design, this
                                                          is precisely
                                                          what that
                                                          experimental
                                                          space is for)

                                                          

                                                          Whereas, as
                                                          you point out,
                                                          the
                                                          alternative is
                                                          a "can open -
                                                          worms
                                                          everywhere"
                                                          situation that
                                                          I think time
                                                          is too short
                                                          to solve?

                                                          

                                                          Thomas

                                                          

                                                          

                                                          > Then you
                                                          could try
                                                          specifying it.
                                                          But with a
                                                          very good
                                                          chance of
                                                          producing
                                                          something you
                                                          later decide
                                                          you should
                                                          have done
                                                          differently.

                                                          >

                                                          > I
                                                          honestly don't
                                                          know which
                                                          would go down
                                                          better (or
                                                          less badly) -
                                                          "here's a
                                                          mechanism we
                                                          haven't really
                                                          thought
                                                          through in
                                                          detail, but at
                                                          least we've
                                                          defined one",
                                                          or "we know
                                                          the sort of
                                                          thing we want,
                                                          and we'll
                                                          describe it,
                                                          but rather
                                                          than produce
                                                          something not
                                                          quite right,
                                                          we'll not go
                                                          further".

                                                          >

                                                          > --

                                                          >
                                                          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

                                                          >

                                                          >

                                                          >
                                                          -----Original
                                                          Message-----

                                                          > From:
                                                          Lotte
                                                          Steenbrink
                                                          [mailto:lotte.steenbrink@fu-berlin.de]

                                                          > Sent: 22
                                                          April 2016
                                                          13:59

                                                          > To:
                                                          Mobile Ad Hoc
                                                          Networks
                                                          mailing list

                                                          > Cc:
                                                          Henning Rogge;
                                                          Dearlove,
                                                          Christopher
                                                          (UK)

                                                          > Subject:
                                                          Re: [manet] On
Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review
                                                          - a couple of
                                                          big ticket
                                                          Items)

                                                          >

                                                          >
                                                          ----------------------!
                                                          WARNING !
                                                          ----------------------
                                                          This message
                                                          originates
                                                          from outside
                                                          our
                                                          organisation,
                                                          either from an
                                                          external
                                                          partner or
                                                          from the
                                                          internet.

                                                          > Consider
                                                          carefully
                                                          whether you
                                                          should click
                                                          on any links,
                                                          open any
                                                          attachments or
                                                          reply.

                                                          > Follow
                                                          the 'Report
                                                          Suspicious
                                                          Emails' link
                                                          on IT matters
                                                          for
                                                          instructions
                                                          on reporting
                                                          suspicious
                                                          email
                                                          messages.

                                                          >
                                                          --------------------------------------------------------

                                                          >

                                                          > Hello
                                                          Christopher,

                                                          >

                                                          >> Am
                                                          22.04.2016 um
                                                          11:57 schrieb
                                                          Dearlove,
                                                          Christopher
                                                          (UK) <chris.dearlove@baesystems.com>:

                                                          >>

                                                          >> Just
                                                          be careful to
                                                          note that this
                                                          concept is as
                                                          currently
                                                          being
                                                          discussed (a)
                                                          specific to
                                                          AODVv2, and
                                                          (b) not an
                                                          application of
                                                          7182, which
                                                          has no
                                                          knowledge of
                                                          special TLVs.

                                                          >>

                                                          >> This
                                                          is something
                                                          we'd want to
                                                          get right, and
                                                          need to get
                                                          right if in
                                                          any space not
                                                          specific to
                                                          ADODVv2,
                                                          because
                                                          getting it
                                                          wrong produces
                                                          future
                                                          problems.

                                                          >

                                                          > Makes
                                                          sense.

                                                          >

                                                          >> I can
                                                          see some
                                                          possible
                                                          approaches,
                                                          none is ideal
                                                          and we're
                                                          rather out

                                                          >> of
                                                          time to
                                                          specify. But
                                                          this is
                                                          experimental,
                                                          so I think we
                                                          might be

                                                          >> able
                                                          to indicate
                                                          the shape of
                                                          the solution
                                                          without
                                                          specifying it,

                                                          >> which
                                                          would be a
                                                          different RFC,
                                                          under a bit
                                                          less time
                                                          pressure.

                                                          >>
                                                          (Extensions to
                                                          existing
                                                          protocols like
                                                          7182 would
                                                          naturally be
                                                          in

                                                          >> scope
                                                          rechartered I
                                                          think.)

                                                          >>

                                                          >> To
                                                          indicate the
                                                          range that's
                                                          open, here are
                                                          two possible
                                                          ideas, one of
                                                          which has an
                                                          impact now, so
                                                          needs to be
                                                          agreed. Note
                                                          that I'm not
                                                          suggesting (in
                                                          fact quite the
                                                          opposite)
                                                          defining an
                                                          extension to
                                                          7182 here,
                                                          rather
                                                          enabling such
                                                          an extension,
                                                          if written, to
                                                          "do the right
                                                          thing".

                                                          >> - We
                                                          have an
                                                          extension to
                                                          7182 that says
                                                          "zero out all
                                                          value octets
                                                          in protocol
                                                          specific TLVs.
                                                          That requires
                                                          now putting
                                                          the AODVv2
                                                          metric TLV in
                                                          that space.

                                                          >

                                                          > Just to
                                                          make sure that
                                                          I understood
                                                          you correctly–
                                                          “that space”
                                                          meaning making
                                                          the AODVv2
                                                          metric TLV
                                                          protocol
                                                          specific? (By
                                                          “the aodvv2
                                                          metric tlv”
                                                          I’m referring
                                                          to the generic
                                                          TLV we’ve been
                                                          talking about
                                                          on this list
                                                          earlier this
                                                          week).

                                                          >

                                                          >> - We
                                                          have an
                                                          extension to
                                                          7182 that adds
                                                          extra material
                                                          to the value
                                                          field that
                                                          indicates (TBD
                                                          how, by
                                                          position with
                                                          sanity check
                                                          that this is
                                                          TLV value
                                                          perhaps?)
                                                          which octets
                                                          are to be
                                                          zeroed out
                                                          before the ICV
                                                          is calculated.

                                                          >

                                                          > The way I
                                                          understand
                                                          that approach,
                                                          it wouldn’t
                                                          warrant any
                                                          action from
                                                          AODVv2 besides
                                                          saying “if you
                                                          calculate the
                                                          ICV, set the
                                                          Metric value
                                                          to zero”
                                                          (leaving the
                                                          nitty gritty
                                                          of how this
                                                          would be done
                                                          in detail to
                                                          future work)…
                                                          Is that
                                                          correct?

                                                          >

                                                          >>

                                                          >> We do
                                                          not have the
                                                          time to
                                                          specify this
                                                          in an
                                                          acceptable
                                                          manner within
                                                          two weeks
                                                          though. But
                                                          the security
                                                          consideration
                                                          section could
                                                          say something
                                                          along the
                                                          lines of "this
                                                          enables the
                                                          use of an ICV
                                                          defined to
                                                          zero out these
                                                          octets“.

                                                          >

                                                          > Okay. :)

                                                          >

                                                          > Best
                                                          regards,

                                                          > Lotte

                                                          >

                                                          >>

                                                          >> --

                                                          >>
                                                          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

                                                          >>

                                                          >>
                                                          -----Original
                                                          Message-----

                                                          >> From:
                                                          manet [mailto:manet-bounces@ietf.org]
                                                          On Behalf Of
                                                          Lotte

                                                          >>
                                                          Steenbrink

                                                          >> Sent:
                                                          22 April 2016
                                                          10:28

                                                          >> To:
                                                          Henning Rogge

                                                          >> Cc:
                                                          Mobile Ad Hoc
                                                          Networks
                                                          mailing list

                                                          >>
                                                          Subject: Re:
                                                          [manet] On
                                                          Forwarding-and-regeneration
                                                          (was: Re:

                                                          >>
                                                          draft-ietf-manet-aodvv2-13
                                                          review - a
                                                          couple of big
                                                          ticket Items)

                                                          >>

                                                          >>
                                                          ----------------------!
                                                          WARNING !
                                                          ----------------------
                                                          This message
                                                          originates
                                                          from outside
                                                          our
                                                          organisation,
                                                          either from an
                                                          external
                                                          partner or
                                                          from the
                                                          internet.

                                                          >>
                                                          Consider
                                                          carefully
                                                          whether you
                                                          should click
                                                          on any links,
                                                          open any
                                                          attachments or
                                                          reply.

                                                          >>
                                                          Follow the
                                                          'Report
                                                          Suspicious
                                                          Emails' link
                                                          on IT matters
                                                          for
                                                          instructions
                                                          on reporting
                                                          suspicious
                                                          email
                                                          messages.

                                                          >>
                                                          --------------------------------------------------------

                                                          >>

                                                          >> ***
                                                          WARNING ***

                                                          >>
                                                          EXTERNAL EMAIL
                                                          -- This
                                                          message
                                                          originates
                                                          from outside
                                                          our
                                                          organization.

                                                          >>

                                                          >>

                                                          >> Hi
                                                          Henning,

                                                          >>

                                                          >>>
                                                          Am 22.04.2016
                                                          um 11:08
                                                          schrieb
                                                          Henning Rogge
                                                          <hrogge@gmail.com>:

                                                          >>>

                                                          >>>
                                                          On Fri, Apr
                                                          22, 2016 at
                                                          11:05 AM,
                                                          Lotte
                                                          Steenbrink

                                                          >>>
                                                          <lotte.steenbrink@fu-berlin.de>
                                                          wrote:

>>>> Hi Thomas,

>>>> Can it?! Iirc, the reason why we adopted the
                                                          “regeneration”
                                                          language

>>>> in the first place is that we’ve been told that
                                                          whenever one
                                                          bit in

>>>> the message (apart from its header) is changed, the
                                                          entire thing
                                                          has to be
                                                          regenerated.

>>>> I’m starting to get the feeling we’ve just been
                                                          misunderstanding

>>>> each other for more than a year. :( Anyway, it seems
                                                          like we’re

>>>> getting close now, so yay.

                                                          >>>

                                                          >>>
                                                          "Modifying"
                                                          the binary
                                                          message
                                                          instead of
                                                          parsing and
                                                          generating a

                                                          >>>
                                                          new one will
                                                          be difficult
                                                          as soon
                                                          someone writes
                                                          an extension
                                                          to

                                                          >>>
                                                          AODVv2 that
                                                          adds more TLVs
                                                          to the
                                                          message.

                                                          >>

                                                          >> D’oh,
                                                          right. Yeah,
                                                          if I remember
                                                          it correctly,
                                                          that’s what
                                                          you explained
                                                          to me when I
                                                          got confused
                                                          about the
                                                          topic last
                                                          spring… But–
                                                          even if a
                                                          message
                                                          contains TLVs
                                                          that the
                                                          AODVv2
                                                          implementation
                                                          handling it
                                                          doesn’t
                                                          understand, it
                                                          will still be
                                                          able to
                                                          recognize the
                                                          Metric TLV,
                                                          right? Isn’t
                                                          that the nifty
                                                          thing about
                                                          RFC5444? So,
                                                          while we
                                                          really
                                                          shouldn’t
                                                          write “before
                                                          calculating
                                                          the ICV, set
                                                          the n-th 4
                                                          octets to 0”,
                                                          we might say
                                                          “identify the
                                                          octets that
                                                          make up the
                                                          metric value
                                                          and set those
                                                          to 0”?

                                                          >>

                                                          >> Best
                                                          regards,

                                                          >> Lotte

                                                          >>

                                                          >>>
                                                          Henning Rogge

                                                          >>

                                                          >>
                                                          _______________________________________________

                                                          >> 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

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                        

                                                      

                                                      _______________________________________________

                                                      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

        

      

      

      

      

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


    

    

  


--------------17117D229B04BAA25E984EC9--


From nobody Thu Apr 28 05:14:32 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 D6CB712D113 for ; Thu, 28 Apr 2016 05:14:30 -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 gBLV07hJSRAn for ; Thu, 28 Apr 2016 05:14:27 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 5D10A12D12A for ; Thu, 28 Apr 2016 05:14:25 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id u64so81735882lff.3 for ; Thu, 28 Apr 2016 05:14:25 -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=tOb+qNO3Z41UUzmybRk/1CR5dKfYWCpwuTiqXSuwrdY=; b=pwC/pvqPVlwnpQLVzPmMiv9iPptQB3UIOrtFnRf8mMabbknkmPAz2S5O2CXWdhlzRq X3Y3QReRVnMcaWupAZg7lfq3mG5V+6BWnmJk5P+fsfh00ixbBWymzWtH8EoKEr9BKGIT DkMgYnliZ7Mu6TQJpUQTo2S0QxIPrxUrLZZVjwff0lD76Yl0jh/MfVzQDR0bWFVLcXlF E6CpOdqZhwcZmQAlEzhaGvhJ3Ce+Bi+830im3/lJoFBNK+4Z071pOFNPV5G1J5Zrf0ep UZZ6rSc2tOLcrhhjrLceWXnqL+Bv8c2/3X6D97fkH+j2QVBlYttENiuggQLWVMcBUCST 2xMQ==
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=tOb+qNO3Z41UUzmybRk/1CR5dKfYWCpwuTiqXSuwrdY=; b=IpGLmCSO53t2xrWqh6Ilmy/JBVmtKhBpMO0Ht+IvWtgC3Egn4t2BI/tVJ4T5GlEgkO lPYyeq0wPUtwk0EnRcwlOIySJ14eRS9HQbQVbGP/k2LCDsa+q2LXladgJhx2YzTZRJDV X4Rcv0yDzWfkdR7RWV6iSlQGpTyW02o+tGSv2JZAIRFCr9SeeuRQtfVbhK8andwzv/Rh aj0nnwXUjhMHRU1KiKa34QpTZe7TNHgPkUNxAK+xm3A2Y0v9Vn1dwWN/xW+Kg30ntU1m t4W8JziPy0M/aF/lxUIN90Ft2roxdIEj9whLBdm5LVXHyl9EnOkvUzj3BF1r3eOhw0S1 m0rA==
X-Gm-Message-State: AOPr4FUBBSf7Vs0wusep82LrzmakdyfUrFjnO8KJkW6NDeYf2QExrr9Qg8aX6hnawCWLDZApBNdwBN0mLbXWNA==
MIME-Version: 1.0
X-Received: by 10.112.209.73 with SMTP id mk9mr5939003lbc.121.1461845663422; Thu, 28 Apr 2016 05:14:23 -0700 (PDT)
Sender: yi.jiazi@gmail.com
Received: by 10.114.77.4 with HTTP; Thu, 28 Apr 2016 05:14:23 -0700 (PDT)
In-Reply-To: <883f2cf1-ffc7-9910-d80b-e3b610353273@earthlink.net>
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <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>
Date: Thu, 28 Apr 2016 14:14:23 +0200
X-Google-Sender-Auth: tqJx9kMPfoXHtW5kRw6x1nyjrYI
Message-ID: 
From: Jiazi YI 
To: Charlie Perkins 
Content-Type: multipart/alternative; boundary=001a11c335367c22ea05318a7780
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: Thu, 28 Apr 2016 12:14:31 -0000

--001a11c335367c22ea05318a7780
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

Jiazi

On Thu, Apr 28, 2016 at 2:04 AM, Charlie Perkins <
charles.perkins@earthlink.net> wrote:

> Hello Justin,
>
> I think a new AODV-specific ICV is probably the right answer.  It would b=
e
> nice to get some help generating the proper settings for all of the RFC
> 7182 fields to support this approach.  If not that, could we fall back on
> RFC 4868, which seems pretty straightforward?
>
> Regards,
> Charlie P.
> On 4/27/2016 4:24 PM, Justin Dean wrote:
>
> An alternative solution to checking integrity. The current icv draft is
> good at validating messages from an original source. OLSRV2 and NHDP use
> this to good effect. AODVV2 doesn't because the messages are regenerated;=
 I
> belive this to be the correct term as the message contains local
> information, path information, and originator information. Getting the ic=
v
> draft to work on forwarded packets is ugly as they really are regenerated
> and should be. What we want to do is secure the original source of
> information which is OrigAddr/target address and sequence number. Why not
> just attach a new aodv specific icv TLV which uses THAT info and nothing
> else? The current icv TLV would/could still be used over the whole messag=
e
> hop by hop by each router, as the messages are regenerated.
>
> Justin
>
> On Wed, Apr 27, 2016, 6:43 PM Jiazi YI < 
> ietf@jiaziyi.com> wrote:
>
>> On Thu, Apr 28, 2016 at 12:19 AM, Lotte Steenbrink <
>> lotte.steenbrink@fu-berlin.de> wrote:
>>
>>>
>>> Am 28.04.2016 um 00:16 schrieb Christopher Dearlove <
>>> christopher.dearlove@gmail.com>:
>>>
>>> The more you have to zero out, the messier it gets, and the less secure
>>> it gets (more things can be spoofed). I think that's about all I've got=
 to
>>> add.
>>>
>>>
>>> Of course. My question was just:
>>> * Do we want to come up with an exact description of how the zeroing ou=
t
>>> should work now, with the short time we have left?
>>>
>>
>> If a meaningful security mechanism is required, yes.
>> I think the first thing to do is to cut as many mutable fields and
>> optional fields as possible.
>>
>> best
>>
>> Jiazi
>>
>>
>>> or
>>> * Do we mention in the draft that zeroing out has to happen somehow and
>>> leave the nitty gritty to future work?
>>>
>>> At least that=E2=80=99s how I understood the options you laid out...
>>>
>>> --
>>> Christopher Dearlove
>>> christopher.dearlove@gmail.com (iPhone)
>>> chris@mnemosyne.demon.co.uk (home)
>>>
>>>
>>>
>>> --
>>> Christopher Dearlove
>>> christopher.dearlove@gmail.com (iPhone)
>>> chris@mnemosyne.demon.co.uk (home)
>>> On 27 Apr 2016, at 22:46, Lotte Steenbrink <
>>> lotte.steenbrink@fu-berlin.de> wrote:
>>>
>>> Hi all,
>>> I=E2=80=99m currently revising the security considerations with regards=
 to the
>>> move from regeneration to forwarding, which depends on a decision being
>>> made on how/where we want to mention the possibility of zeroing out TLV=
s to
>>> calculate the ICV for the rest of a message=E2=80=99s contents (see sec=
ond * of my
>>> last e-mail). I=E2=80=99ve not found a decision on this in other thread=
 (please
>>> pardon me if I overlooked something), so I=E2=80=99ll bump this thread =
and ask the
>>> WG for its opinions. (again, personally, the 2nd option outlined by
>>> Christopher seems more appealing to me)
>>>
>>> Regards,
>>> Lotte
>>>
>>> Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink <
>>> lotte.steenbrink@fu-berlin.de>:
>>>
>>> Hi all,
>>> to summarize:
>>>
>>> * AODVv2 message Type numbers should be in the Experimental type space
>>> and the AODVv2 TLV Types should be message type-specific. This also mea=
ns
>>> changing the text regarding IANA actions and changing the text regardin=
g
>>> what the experiment is to something along the lines of =E2=80=9Cwe want=
 to gather
>>> experience on how to make generic metric TLVs and ICVs that work with
>>> changing metric TV values happen with reactive protocols=E2=80=9D
>>> * we=E2=80=99re undecided on (to quote Christopher) the "here's a mecha=
nism we
>>> haven't really thought through in detail, but at least we've defined on=
e",
>>> or "we know the sort of thing we want, and we'll describe it, but rathe=
r
>>> than produce something not quite right, we'll not go further=E2=80=9C d=
ecision on
>>> temporarily setting the metric value to 0 (i.e. the who and how).
>>> (personally, I think I=E2=80=99d prefer the latter approach, but that=
=E2=80=99s an entirely
>>> gut feeling-based preference)
>>>
>>> Did I catch that correctly? If so, I=E2=80=99ll put together and sugges=
t some
>>> text for the first point as soon as I get home and in case there has be=
en a
>>> decision on the second by then, I=E2=80=99ll try to tackle that one too=
. :)
>>>
>>> Best regards, Lotte
>>>
>>> Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) <
>>> chris.dearlove@baesystems.com>:
>>>
>>> I have no problem with that. I was trying to lay out the issues without
>>> muddying the water with my preference.
>>>
>>>
>>> *--*
>>>
>>>
>>>
>>>
>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>> Intelligence Laboratories *
>>> *______________________________________________________________________=
____
>>> *
>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* 22 April 2016 15:35
>>> *To:* Dearlove, Christopher (UK)
>>> *Cc:* Thomas Heide Clausen; Mobile Ad Hoc Networks mailing list
>>> *Subject:* Re: [manet] On Forwarding-and-regeneration (was: Re:
>>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>
>>>
>>> **** 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
>>> .*
>>> Speaking as participant.
>>>
>>> I kind of like the idea of using the experimental message type space.
>>> We only have a limited amount of these message types.  The TLV assignme=
nts
>>> could just use the message type specific space and there isn't an issue
>>> there.  IANA wouldn't assign a number but I don't see why the document
>>> couldn't specify the experimental numbers it was going to use so other
>>> future near term experiential protocols could do the same and generally
>>> avoid conflict.  If the experiment is successful IANA assignments could=
 be
>>> made.  Functionally no real difference with protections vs long term us=
age
>>> of limited space.
>>>
>>> Justin
>>>
>>> On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) <
>>> chris.dearlove@baesystems.com> wrote:
>>> There's rather a contradiction between the concepts of a definition of =
a
>>> protocol, even Experimental, and experimental space, which usually assu=
mes
>>> that the user can do what he or she likes in it.
>>>
>>> But chewing up messages types (how many, 3?) of which there are
>>> relatively few for experimental is long term a problem, although short =
term
>>> not.
>>>
>>> TLV space is easier in two regards. It's bigger (though the prime real
>>> estate of type extension zero isn't) and can have message type specific
>>> TLVs.
>>>
>>> So TLVS can actually be invisible, if that option is chosen. For
>>> messages something has to give. Least bad option is again one of those =
we
>>> should discuss, but time ...
>>>
>>> (To be precise, messages types from 224 are defined in RFC 5444 as "
>>> Experimental Use", of which BCP 26 says "Similar to private or local us=
e
>>> only, with the  purpose being to facilitate experimentation." The
>>> alternative 0-223 space is Expert Review. IANA still thinks the experts=
 are
>>> Joe Macker and the recused Stan Ratliff. But that's a soluble nit.)
>>>
>>> --
>>> Christopher Dearlove
>>> Senior Principal Engineer
>>> BAE Systems Applied Intelligence Laboratories
>>>
>>> _______________________________________________________________________=
___
>>>
>>> T:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  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
>>>
>>>
>>> -----Original Message-----
>>> From: Thomas Heide Clausen [mailto: 
>>> ietf@thomasclausen.org]
>>> Sent: 22 April 2016 14:21
>>> To: Dearlove, Christopher (UK)
>>> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>
>>> ----------------------! WARNING ! ---------------------- This message
>>> originates from outside our organisation, either from an external partn=
er
>>> or from the internet.
>>> Consider carefully whether you should click on any links, open any
>>> attachments or reply.
>>> Follow the 'Report Suspicious Emails' link on IT matters for
>>> instructions on reporting suspicious email messages.
>>> --------------------------------------------------------
>>>
>>>
>>> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <
>>> chris.dearlove@baesystems.com> wrote:
>>> >
>>> > Once you're entirely in AODV2's own space, and AODVv2 is experimental
>>> (working assumption for this discussion) you have more liberty.
>>> >
>>>
>>> Yep.
>>>
>>> Taken somewhat by surprise both by the sudden "rush" and the
>>> experimental maturity level, I am wondering (and haven't thought throug=
h)
>>> about experimental space vs non-experimental (for message types, and
>>> consequently for message type specific TLV types).
>>>
>>> I think that if the AODVv2 experiment specifies the use of Message type=
s
>>> from the Experimental message type space without making actual
>>> registrations in the IANA registry, AND the use of type specific TLV ty=
pes,
>>> this becomes a non-issue entirely (by design, this is precisely what th=
at
>>> experimental space is for)
>>>
>>> Whereas, as you point out, the alternative is a "can open - worms
>>> everywhere" situation that I think time is too short to solve?
>>>
>>> Thomas
>>>
>>>
>>> > Then you could try specifying it. But with a very good chance of
>>> producing something you later decide you should have done differently.
>>> >
>>> > I honestly don't know which would go down better (or less badly) -
>>> "here's a mechanism we haven't really thought through in detail, but at
>>> least we've defined one", or "we know the sort of thing we want, and we=
'll
>>> describe it, but rather than produce something not quite right, we'll n=
ot
>>> go further".
>>> >
>>> > --
>>> > Christopher Dearlove
>>> > Senior Principal Engineer
>>> > BAE Systems Applied Intelligence Laboratories
>>> >
>>> _______________________________________________________________________=
___
>>> >
>>> > T:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  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
>>> >
>>> >
>>> > -----Original Message-----
>>> > From: Lotte Steenbrink [mailto: 
>>> lotte.steenbrink@fu-berlin.de]
>>> > Sent: 22 April 2016 13:59
>>> > To: Mobile Ad Hoc Networks mailing list
>>> > Cc: Henning Rogge; Dearlove, Christopher (UK)
>>> > Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>> >
>>> > ----------------------! WARNING ! ---------------------- This message
>>> originates from outside our organisation, either from an external partn=
er
>>> or from the internet.
>>> > Consider carefully whether you should click on any links, open any
>>> attachments or reply.
>>> > Follow the 'Report Suspicious Emails' link on IT matters for
>>> instructions on reporting suspicious email messages.
>>> > --------------------------------------------------------
>>> >
>>> > Hello Christopher,
>>> >
>>> >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <
>>> chris.dearlove@baesystems.com>:
>>> >>
>>> >> Just be careful to note that this concept is as currently being
>>> discussed (a) specific to AODVv2, and (b) not an application of 7182, w=
hich
>>> has no knowledge of special TLVs.
>>> >>
>>> >> This is something we'd want to get right, and need to get right if i=
n
>>> any space not specific to ADODVv2, because getting it wrong produces fu=
ture
>>> problems.
>>> >
>>> > Makes sense.
>>> >
>>> >> I can see some possible approaches, none is ideal and we're rather o=
ut
>>> >> of time to specify. But this is experimental, so I think we might be
>>> >> able to indicate the shape of the solution without specifying it,
>>> >> which would be a different RFC, under a bit less time pressure.
>>> >> (Extensions to existing protocols like 7182 would naturally be in
>>> >> scope rechartered I think.)
>>> >>
>>> >> To indicate the range that's open, here are two possible ideas, one
>>> of which has an impact now, so needs to be agreed. Note that I'm not
>>> suggesting (in fact quite the opposite) defining an extension to 7182 h=
ere,
>>> rather enabling such an extension, if written, to "do the right thing".
>>> >> - We have an extension to 7182 that says "zero out all value octets
>>> in protocol specific TLVs. That requires now putting the AODVv2 metric =
TLV
>>> in that space.
>>> >
>>> > Just to make sure that I understood you correctly=E2=80=93 =E2=80=9Ct=
hat space=E2=80=9D
>>> meaning making the AODVv2 metric TLV protocol specific? (By =E2=80=9Cth=
e aodvv2
>>> metric tlv=E2=80=9D I=E2=80=99m referring to the generic TLV we=E2=80=
=99ve been talking about on
>>> this list earlier this week).
>>> >
>>> >> - We have an extension to 7182 that adds extra material to the value
>>> field that indicates (TBD how, by position with sanity check that this =
is
>>> TLV value perhaps?) which octets are to be zeroed out before the ICV is
>>> calculated.
>>> >
>>> > The way I understand that approach, it wouldn=E2=80=99t warrant any a=
ction
>>> from AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set the M=
etric value
>>> to zero=E2=80=9D (leaving the nitty gritty of how this would be done in=
 detail to
>>> future work)=E2=80=A6 Is that correct?
>>> >
>>> >>
>>> >> We do not have the time to specify this in an acceptable manner
>>> within two weeks though. But the security consideration section could s=
ay
>>> something along the lines of "this enables the use of an ICV defined to
>>> zero out these octets=E2=80=9C.
>>> >
>>> > Okay. :)
>>> >
>>> > Best regards,
>>> > Lotte
>>> >
>>> >>
>>> >> --
>>> >> 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 & Wal=
es
>>> >> No: 01337451 Registered Office: Surrey Research Park, Guildford,
>>> >> Surrey, GU2 7YP
>>> >>
>>> >> -----Original Message-----
>>> >> From: manet [mailto: manet-bounces@ietf.org]
>>> On Behalf Of Lotte
>>> >> Steenbrink
>>> >> Sent: 22 April 2016 10:28
>>> >> To: Henning Rogge
>>> >> Cc: Mobile Ad Hoc Networks mailing list
>>> >> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>>> >> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>> >>
>>> >> ----------------------! WARNING ! ---------------------- This messag=
e
>>> originates from outside our organisation, either from an external partn=
er
>>> or from the internet.
>>> >> Consider carefully whether you should click on any links, open any
>>> attachments or reply.
>>> >> Follow the 'Report Suspicious Emails' link on IT matters for
>>> instructions on reporting suspicious email messages.
>>> >> --------------------------------------------------------
>>> >>
>>> >> *** WARNING ***
>>> >> EXTERNAL EMAIL -- This message originates from outside our
>>> organization.
>>> >>
>>> >>
>>> >> Hi Henning,
>>> >>
>>> >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge < 
>>> hrogge@gmail.com>:
>>> >>>
>>> >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>>> >>> < lotte.steenbrink@fu-berlin.de>
>>> wrote:
>>> >>>> Hi Thomas,
>>> >>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=
=E2=80=9D language
>>> >>>> in the first place is that we=E2=80=99ve been told that whenever o=
ne bit in
>>> >>>> the message (apart from its header) is changed, the entire thing
>>> has to be regenerated.
>>> >>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been mi=
sunderstanding
>>> >>>> each other for more than a year. :( Anyway, it seems like we=E2=80=
=99re
>>> >>>> getting close now, so yay.
>>> >>>
>>> >>> "Modifying" the binary message instead of parsing and generating a
>>> >>> new one will be difficult as soon someone writes an extension to
>>> >>> AODVv2 that adds more TLVs to the message.
>>> >>
>>> >> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99=
s what you
>>> explained to me when I got confused about the topic last spring=E2=80=
=A6 But=E2=80=93 even
>>> if a message contains TLVs that the AODVv2 implementation handling it
>>> doesn=E2=80=99t understand, it will still be able to recognize the Metr=
ic TLV,
>>> right? Isn=E2=80=99t that the nifty thing about RFC5444? So, while we r=
eally
>>> shouldn=E2=80=99t write =E2=80=9Cbefore calculating the ICV, set the n-=
th 4 octets to 0=E2=80=9D,
>>> we might say =E2=80=9Cidentify the octets that make up the metric value=
 and set
>>> those to 0=E2=80=9D?
>>> >>
>>> >> Best regards,
>>> >> Lotte
>>> >>
>>> >>> Henning Rogge
>>> >>
>>> >> _______________________________________________
>>> >> 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
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> _______________________________________________
> manet mailing listmanet@ietf.orghttps://www.ietf.org/mailman/listinfo/man=
et
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>

--001a11c335367c22ea05318a7780
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I think it will make the specification complex, and hard t=
o extend.=C2=A0

What about if I need to define a new TLV=
 field for my extension? The field would either be unprotected, or the exte=
nsion won't be interoperable with old implementations.=C2=A0
=

Jiazi

On Thu, Apr 28, 2016 at 2:04 AM, Charlie Perkins &=
lt;charl=
es.perkins@earthlink.net> wrote:

 =20
   =20
 =20
  

    
Hello Justin,

    
I think a new AODV-specific ICV is probably the right answer.=C2=A0 =
It
      would be nice to get some help generating the proper settings for
      all of the RFC 7182 fields to support this approach.=C2=A0 If not tha=
t,
      could we fall back on RFC 4868, which seems pretty
      straightforward?

    

    
Regards,

      Charlie P.

    

    
On 4/27/2016 4:24 PM, Justin Dean
      wrote:

    

    

     =20
      
An alternative solution to checking integrity. The
        current icv draft is good at validating messages from an
        original source. OLSRV2 and NHDP use this to good effect. AODVV2
        doesn't because the messages are regenerated; I belive this to
        be the correct term as the message contains local information,
        path information, and originator information. Getting the icv
        draft to work on forwarded packets is ugly as they really are
        regenerated and should be. What we want to do is secure the
        original source of information which is OrigAddr/target address
        and sequence number. Why not just attach a new aodv specific icv
        TLV which uses THAT info and nothing else? The current icv TLV
        would/could still be used over the whole message hop by hop by
        each router, as the messages are regenerated.

      
Justin

      

      

        
On Wed, Apr 27, 2016, 6:43 PM Jiazi YI <ietf@jiaziyi.com>
          wrote:

        

        

          
          

            

              

                
If a meaningful security mechanism is required,
                  yes.=C2=A0

                
I think the first thing to do is to cut as many
                  mutable fields and optional fields as possible.=C2=A0
                


                

                
best

              

            

          

          

            

              

                


                

                
Jiazi

              

            

          

          

            

              

                
=C2=A0

                

                  

                    

                      

                        
or

                        
* Do we mention in the draft that zeroing
                          out has to happen somehow and leave the nitty
                          gritty to future work?

                        


                        

                        
At least that=E2=80=99s how I understood the
                          options you laid out...

                      

                      

                        


                          

                            

                              

                                

                                  
                                  


                                    


                                      

                                      -- =C2=A0
                                      
Christopher Dearlove

                                      
                                      
                                    

                                    On 27 Apr 2016, at 22:46, Lotte
                                    Steenbrink <lotte.steenbrink@fu-berlin.de>=
;
                                    wrote:

                                    

                                  

                                  

                                    

                                      Hi all,
                                      
I=E2=80=99m currently revising t=
he
                                        security considerations with
                                        regards to the move from
                                        regeneration to forwarding,
                                        which depends on a decision
                                        being made on how/where we want
                                        to mention the possibility of
                                        zeroing out TLVs to calculate
                                        the ICV for the rest of a
                                        message=E2=80=99s contents (see sec=
ond *
                                        of my last e-mail). I=E2=80=99ve no=
t
                                        found a decision on this in
                                        other thread (please pardon me
                                        if I overlooked something), so
                                        I=E2=80=99ll bump this thread and a=
sk
                                        the WG for its opinions. (again,
                                        personally, the 2nd option
                                        outlined by Christopher seems
                                        more appealing to me)

                                      


                                      

                                      
Regards,

                                      
Lotte

                                      


                                        

                                          

                                            
Am 22.04.2016 um 18:26
                                              schrieb Lotte Steenbrink
                                              <lotte.steenbrink@fu-berlin.de>=
:

                                            

                                            

                                              
Hi all,
                                                
to summarize:

                                                


                                                

                                                
* AODVv2 message
                                                  Type numbers should be
                                                  in the Experimental
                                                  type space and the
                                                  AODVv2 TLV Types
                                                  should be message
                                                  type-specific. This
                                                  also means changing
                                                  the text regarding
                                                  IANA actions and
                                                  changing the text
                                                  regarding what the
                                                  experiment is to
                                                  something along the
                                                  lines of =E2=80=9Cwe want=
 to
                                                  gather experience on
                                                  how to make generic
                                                  metric TLVs and ICVs
                                                  that work with
                                                  changing metric TV
                                                  values happen with
                                                  reactive protocols=E2=80=
=9D

                                                
* we=E2=80=99re undeci=
ded
                                                  on (to quote
                                                  Christopher) the
                                                  "here's a mechan=
ism we
                                                  haven't really though=
t
                                                  through in detail, but
                                                  at least we've define=
d
                                                  one", or "we kn=
ow the
                                                  sort of thing we want,
                                                  and we'll describe it=
,
                                                  but rather than
                                                  produce something not
                                                  quite right, we'll no=
t
                                                  go further=E2=80=9C decis=
ion
                                                  on temporarily setting
                                                  the metric value to 0
                                                  (i.e. the who and
                                                  how). (personally, I
                                                  think I=E2=80=99d prefer =
the
                                                  latter approach, but
                                                  that=E2=80=99s an entirel=
y gut
                                                  feeling-based
                                                  preference)

                                                


                                                

                                                
Did I catch that
                                                  correctly? If so, I=E2=80=
=99ll
                                                  put together and
                                                  suggest some text for
                                                  the first point as
                                                  soon as I get home and
                                                  in case there has been
                                                  a decision on the
                                                  second by then, I=E2=80=
=99ll
                                                  try to tackle that one
                                                  too. :)

                                                


                                                

                                                
Best regards, Lotte
                                                


                                                

                                                

                                                  

                                                    
Am 22.04.2016
                                                      um 16:41 schrieb
                                                      Dearlove,
                                                      Christopher (UK)
                                                      <chris.dearlove@baesystems.com=
>:

                                                    

                                                    

                                                      

                                                        
I
                                                          have no
                                                          problem with
                                                          that. I was
                                                          trying to lay
                                                          out the issues
                                                          without
                                                          muddying the
                                                          water with my
                                                          preference.

                                                        
=C2=A0

                                                        
--

                                                        
Christopher
                                                          Dearlove

                                                          Senior
                                                          Principal
                                                          Engineer

                                                          BAE Systems
                                                          Applied
                                                          Intelligence
                                                          Laboratories

                                                          ________________________________________________________________________=
__

                                                          =


                                                          T=
:
                                                          =C2=A0+44
                                                          (0)1245 242194
                                                          =C2=A0| =C2=A0=
E:=C2=A0chris.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

                                                        
From:=C2=A0Justin
                                                          Dean [mailto:bebemaster@gmail.com]=C2=
=A0

                                                          Sent:=C2=A022
                                                          April 2016
                                                          15:35

                                                          To:=
=C2=A0Dearlove,
                                                          Christopher
                                                          (UK)

                                                          Cc:=
=C2=A0Thomas
                                                          Heide Clausen;
                                                          Mobile Ad Hoc
                                                          Networks
                                                          mailing list

                                                          Subject:=C2=A0Re:
                                                          [manet] On
                                                          Forwarding-and-re=
generation
                                                          (was: Re:
                                                          draft-ietf-manet-=
aodvv2-13
                                                          review - a
                                                          couple of big
                                                          ticket Items)

                                                        
=C2=A0

                                                        

                                                          
=C2=A0=


                                                          

                                                          
***
                                                          WARNING ***

                                                          

                                                          

                                                          
This
                                                          message
                                                          originates
                                                          from outside
                                                          our
                                                          organisation,
                                                          either from an
                                                          external
                                                          partner or the
                                                          internet.<=
/em>

                                                          Conside=
r
                                                          carefully
                                                          whether you
                                                          should click
                                                          on any links,
                                                          open any
                                                          attachments or
                                                          reply.

                                                          For
                                                          information
                                                          regarding=
=C2=A0Red
                                                          Flags<=
/strong>=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.

                                                          

                                                        

                                                        

                                                          
Speaking
                                                          as
                                                          participant.

                                                          

                                                          I kind of like
                                                          the idea of
                                                          using the
                                                          experimental
                                                          message type
                                                          space.=C2=A0 We
                                                          only have a
                                                          limited amount
                                                          of these
                                                          message
                                                          types.=C2=A0 The
                                                          TLV
                                                          assignments
                                                          could just use
                                                          the message
                                                          type specific
                                                          space and
                                                          there isn't a=
n
                                                          issue there.=C2=
=A0
                                                          IANA wouldn't
                                                          assign a
                                                          number but I
                                                          don't see why
                                                          the document
                                                          couldn't
                                                          specify the
                                                          experimental
                                                          numbers it was
                                                          going to use
                                                          so other
                                                          future near
                                                          term
                                                          experiential
                                                          protocols
                                                          could do the
                                                          same and
                                                          generally
                                                          avoid
                                                          conflict.=C2=A0 I=
f
                                                          the experiment
                                                          is successful
                                                          IANA
                                                          assignments
                                                          could be
                                                          made.=C2=A0
                                                          Functionally
                                                          no real
                                                          difference
                                                          with
                                                          protections vs
                                                          long term
                                                          usage of
                                                          limited space.
                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
Justin

                                                          

                                                          
=C2=A0

                                                          

                                                          
On Fri,
                                                          Apr 22, 2016
                                                          at 9:35 AM,
                                                          Dearlove,
                                                          Christopher
                                                          (UK) <chris.dearlove@baes=
ystems.com>
                                                          wrote:

                                                          
There's
                                                          rather a
                                                          contradiction
                                                          between the
                                                          concepts of a
                                                          definition of
                                                          a protocol,
                                                          even
                                                          Experimental,
                                                          and
                                                          experimental
                                                          space, which
                                                          usually
                                                          assumes that
                                                          the user can
                                                          do what he or
                                                          she likes in
                                                          it.

                                                          

                                                          But chewing up
                                                          messages types
                                                          (how many, 3?)
                                                          of which there
                                                          are relatively
                                                          few for
                                                          experimental
                                                          is long term a
                                                          problem,
                                                          although short
                                                          term not.

                                                          

                                                          TLV space is
                                                          easier in two
                                                          regards. It's
                                                          bigger (though
                                                          the prime real
                                                          estate of type
                                                          extension zero
                                                          isn't) and ca=
n
                                                          have message
                                                          type specific
                                                          TLVs.

                                                          

                                                          So TLVS can
                                                          actually be
                                                          invisible, if
                                                          that option is
                                                          chosen. For
                                                          messages
                                                          something has
                                                          to give. Least
                                                          bad option is
                                                          again one of
                                                          those we
                                                          should
                                                          discuss, but
                                                          time ...

                                                          

                                                          (To be
                                                          precise,
                                                          messages types
                                                          from 224 are
                                                          defined in RFC
                                                          5444 as "
                                                          Experimental
                                                          Use", of whi=
ch
                                                          BCP 26 says
                                                          "Similar to
                                                          private or
                                                          local use
                                                          only, with
                                                          the=C2=A0 purpose
                                                          being to
                                                          facilitate
                                                          experimentation.&=
quot;
                                                          The
                                                          alternative
                                                          0-223 space is
                                                          Expert Review.
                                                          IANA still
                                                          thinks the
                                                          experts are
                                                          Joe Macker and
                                                          the recused
                                                          Stan Ratliff.
                                                          But that's a
                                                          soluble nit.)

                                                          

                                                          --
                                                          Christopher
                                                          Dearlove
                                                          Senior
                                                          Principal
                                                          Engineer
                                                          BAE
                                                          Systems
                                                          Applied
                                                          Intelligence
                                                          Laboratories

                                                          ___________=
_______________________________________________________________

                                                          

                                                          T: =C2=A0+44 (0)1245
                                                          242194=
=C2=A0=C2=A0|
                                                          =C2=A0E:=C2=
=A0ch=
ris.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

                                                          

                                                          

                                                          -----Origin=
al
                                                          Message-----

                                                          From:
                                                          Thomas Heide
                                                          Clausen
                                                          [mailto:ietf@thomasclausen.org]

                                                          Sent: 22
                                                          April 2016
                                                          14:21

                                                          To:
                                                          Dearlove,
                                                          Christopher
                                                          (UK)

                                                          

                                                          

                                                          
Cc: Lotte
                                                          Steenbrink;
                                                          Mobile Ad Hoc
                                                          Networks
                                                          mailing list

                                                          Subject: Re:
                                                          [manet] On
                                                          Forwarding-and-re=
generation
                                                          (was: Re:
                                                          draft-ietf-manet-=
aodvv2-13
                                                          review - a
                                                          couple of big
                                                          ticket Items)

                                                          

----------------------! WARNING ! ---------------------- This message
                                                          originates
                                                          from outside
                                                          our
                                                          organisation,
                                                          either from an
                                                          external
                                                          partner or
                                                          from the
                                                          internet.

                                                          Consider
                                                          carefully
                                                          whether you
                                                          should click
                                                          on any links,
                                                          open any
                                                          attachments or
                                                          reply.

                                                          Follow the
                                                          'Report
                                                          Suspicious
                                                          Emails' link
                                                          on IT matters
                                                          for
                                                          instructions
                                                          on reporting
                                                          suspicious
                                                          email
                                                          messages.

--------------------------------------------------------

                                                          

                                                          

                                                          > On 22
                                                          avr. 2016, at
                                                          15:05,
                                                          Dearlove,
                                                          Christopher
                                                          (UK) <chris.dearlove@baes=
ystems.com>
                                                          wrote:

                                                          >

                                                          > Once
                                                          you're
                                                          entirely in
                                                          AODV2's own
                                                          space, and
                                                          AODVv2 is
                                                          experimental
                                                          (working
                                                          assumption for
                                                          this
                                                          discussion)
                                                          you have more
                                                          liberty.

                                                          >

                                                          

                                                          Yep.

                                                          

                                                          Taken somewhat
                                                          by surprise
                                                          both by the
                                                          sudden "rush=
"
                                                          and the
                                                          experimental
                                                          maturity
                                                          level, I am
                                                          wondering (and
                                                          haven't
                                                          thought
                                                          through) about
                                                          experimental
                                                          space vs
                                                          non-experimental
                                                          (for message
                                                          types, and
                                                          consequently
                                                          for message
                                                          type specific
                                                          TLV types).

                                                          

                                                          I think that
                                                          if the AODVv2
                                                          experiment
                                                          specifies the
                                                          use of Message
                                                          types from the
                                                          Experimental
                                                          message type
                                                          space without
                                                          making actual
                                                          registrations
                                                          in the IANA
                                                          registry, AND
                                                          the use of
                                                          type specific
                                                          TLV types,
                                                          this becomes a
                                                          non-issue
                                                          entirely (by
                                                          design, this
                                                          is precisely
                                                          what that
                                                          experimental
                                                          space is for)

                                                          

                                                          Whereas, as
                                                          you point out,
                                                          the
                                                          alternative is
                                                          a "can open =
-
                                                          worms
                                                          everywhere"
                                                          situation that
                                                          I think time
                                                          is too short
                                                          to solve?

                                                          

                                                          Thomas

                                                          

                                                          

                                                          > Then you
                                                          could try
                                                          specifying it.
                                                          But with a
                                                          very good
                                                          chance of
                                                          producing
                                                          something you
                                                          later decide
                                                          you should
                                                          have done
                                                          differently.

                                                          >

                                                          > I
                                                          honestly don'=
t
                                                          know which
                                                          would go down
                                                          better (or
                                                          less badly) -
                                                          "here's =
a
                                                          mechanism we
                                                          haven't reall=
y
                                                          thought
                                                          through in
                                                          detail, but at
                                                          least we've
                                                          defined one"=
,
                                                          or "we know
                                                          the sort of
                                                          thing we want,
                                                          and we'll
                                                          describe it,
                                                          but rather
                                                          than produce
                                                          something not
                                                          quite right,
                                                          we'll not go
                                                          further".
                                                          >

                                                          > --

                                                          >
                                                          Christopher
                                                          Dearlove

                                                          > Senior
                                                          Principal
                                                          Engineer

                                                          > BAE
                                                          Systems
                                                          Applied
                                                          Intelligence
                                                          Laboratories

                                                          >
__________________________________________________________________________<=
br>
                                                          >

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

                                                          >

                                                          > BAE
                                                          Systems
                                                          Applied
                                                          Intelligence,
                                                          Chelmsford
                                                          Technology
                                                          Park, Great
                                                          Baddow,
                                                          Chelmsford,
                                                          Essex CM2 8HN.
                                                          >=C2=A0<=
/span>www.baesystems.com/ai<=
/a>

                                                          > BAE
                                                          Systems
                                                          Applied
                                                          Intelligence
                                                          Limited

                                                          >
                                                          Registered in
                                                          England &
                                                          Wales No:
                                                          01337451

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

                                                          >

                                                          >

                                                          >
                                                          -----Original
                                                          Message-----

                                                          > From:
                                                          Lotte
                                                          Steenbrink
                                                          [mailto:lotte.steenbrink@fu=
-berlin.de]

                                                          > Sent: 22
                                                          April 2016
                                                          13:59

                                                          > To:
                                                          Mobile Ad Hoc
                                                          Networks
                                                          mailing list

                                                          > Cc:
                                                          Henning Rogge;
                                                          Dearlove,
                                                          Christopher
                                                          (UK)

                                                          > Subject:
                                                          Re: [manet] On
Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review
                                                          - a couple of
                                                          big ticket
                                                          Items)

                                                          >

                                                          >
                                                          -----------------=
-----!
                                                          WARNING !
                                                          -----------------=
-----
                                                          This message
                                                          originates
                                                          from outside
                                                          our
                                                          organisation,
                                                          either from an
                                                          external
                                                          partner or
                                                          from the
                                                          internet.

                                                          > Consider
                                                          carefully
                                                          whether you
                                                          should click
                                                          on any links,
                                                          open any
                                                          attachments or
                                                          reply.

                                                          > Follow
                                                          the 'Report
                                                          Suspicious
                                                          Emails' link
                                                          on IT matters
                                                          for
                                                          instructions
                                                          on reporting
                                                          suspicious
                                                          email
                                                          messages.

                                                          >
                                                          -----------------=
---------------------------------------

                                                          >

                                                          > Hello
                                                          Christopher,

                                                          >

                                                          >> Am
                                                          22.04.2016 um
                                                          11:57 schrieb
                                                          Dearlove,
                                                          Christopher
                                                          (UK) <chris.dearlove@baes=
ystems.com>:

                                                          >>

                                                          >> Just
                                                          be careful to
                                                          note that this
                                                          concept is as
                                                          currently
                                                          being
                                                          discussed (a)
                                                          specific to
                                                          AODVv2, and
                                                          (b) not an
                                                          application of
                                                          7182, which
                                                          has no
                                                          knowledge of
                                                          special TLVs.

                                                          >>

                                                          >> This
                                                          is something
                                                          we'd want to
                                                          get right, and
                                                          need to get
                                                          right if in
                                                          any space not
                                                          specific to
                                                          ADODVv2,
                                                          because
                                                          getting it
                                                          wrong produces
                                                          future
                                                          problems.

                                                          >

                                                          > Makes
                                                          sense.

                                                          >

                                                          >> I can
                                                          see some
                                                          possible
                                                          approaches,
                                                          none is ideal
                                                          and we're
                                                          rather out

                                                          >> of
                                                          time to
                                                          specify. But
                                                          this is
                                                          experimental,
                                                          so I think we
                                                          might be

                                                          >> able
                                                          to indicate
                                                          the shape of
                                                          the solution
                                                          without
                                                          specifying it,
                                                          >> which
                                                          would be a
                                                          different RFC,
                                                          under a bit
                                                          less time
                                                          pressure.

                                                          >>
                                                          (Extensions to
                                                          existing
                                                          protocols like
                                                          7182 would
                                                          naturally be
                                                          in

                                                          >> scope
                                                          rechartered I
                                                          think.)

                                                          >>

                                                          >> To
                                                          indicate the
                                                          range that's
                                                          open, here are
                                                          two possible
                                                          ideas, one of
                                                          which has an
                                                          impact now, so
                                                          needs to be
                                                          agreed. Note
                                                          that I'm not
                                                          suggesting (in
                                                          fact quite the
                                                          opposite)
                                                          defining an
                                                          extension to
                                                          7182 here,
                                                          rather
                                                          enabling such
                                                          an extension,
                                                          if written, to
                                                          "do the righ=
t
                                                          thing".

                                                          >> - We
                                                          have an
                                                          extension to
                                                          7182 that says
                                                          "zero out al=
l
                                                          value octets
                                                          in protocol
                                                          specific TLVs.
                                                          That requires
                                                          now putting
                                                          the AODVv2
                                                          metric TLV in
                                                          that space.

                                                          >

                                                          > Just to
                                                          make sure that
                                                          I understood
                                                          you correctly=E2=
=80=93
                                                          =E2=80=9Cthat spa=
ce=E2=80=9D
                                                          meaning making
                                                          the AODVv2
                                                          metric TLV
                                                          protocol
                                                          specific? (By
                                                          =E2=80=9Cthe aodv=
v2
                                                          metric tlv=E2=80=
=9D
                                                          I=E2=80=99m refer=
ring
                                                          to the generic
                                                          TLV we=E2=80=99ve=
 been
                                                          talking about
                                                          on this list
                                                          earlier this
                                                          week).

                                                          >

                                                          >> - We
                                                          have an
                                                          extension to
                                                          7182 that adds
                                                          extra material
                                                          to the value
                                                          field that
                                                          indicates (TBD
                                                          how, by
                                                          position with
                                                          sanity check
                                                          that this is
                                                          TLV value
                                                          perhaps?)
                                                          which octets
                                                          are to be
                                                          zeroed out
                                                          before the ICV
                                                          is calculated.
                                                          >

                                                          > The way I
                                                          understand
                                                          that approach,
                                                          it wouldn=E2=80=
=99t
                                                          warrant any
                                                          action from
                                                          AODVv2 besides
                                                          saying =E2=80=9Ci=
f you
                                                          calculate the
                                                          ICV, set the
                                                          Metric value
                                                          to zero=E2=80=9D
                                                          (leaving the
                                                          nitty gritty
                                                          of how this
                                                          would be done
                                                          in detail to
                                                          future work)=E2=
=80=A6
                                                          Is that
                                                          correct?

                                                          >

                                                          >>

                                                          >> We do
                                                          not have the
                                                          time to
                                                          specify this
                                                          in an
                                                          acceptable
                                                          manner within
                                                          two weeks
                                                          though. But
                                                          the security
                                                          consideration
                                                          section could
                                                          say something
                                                          along the
                                                          lines of "th=
is
                                                          enables the
                                                          use of an ICV
                                                          defined to
                                                          zero out these
                                                          octets=E2=80=9C.<=
br>
                                                          >

                                                          > Okay. :)

                                                          >

                                                          > Best
                                                          regards,

                                                          > Lotte

                                                          >

                                                          >>

                                                          >> --

                                                          >>
                                                          Christopher
                                                          Dearlove

                                                          >>
                                                          Senior
                                                          Principal
                                                          Engineer

                                                          >> BAE
                                                          Systems
                                                          Applied
                                                          Intelligence
                                                          Laboratories

                                                          >>
                                                          _________________=
_____________________________________________________

                                                          >> ____

                                                          >>

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

                                                          >>

                                                          >> BAE
                                                          Systems
                                                          Applied
                                                          Intelligence,
                                                          Chelmsford
                                                          Technology
                                                          Park, Great
                                                          Baddow,
                                                          Chelmsford,
                                                          Essex CM2 8HN.
                                                          >>=C2=
=A0www.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
                                                          Lotte

                                                          >>
                                                          Steenbrink

                                                          >> Sent:
                                                          22 April 2016
                                                          10:28

                                                          >> To:
                                                          Henning Rogge

                                                          >> Cc:
                                                          Mobile Ad Hoc
                                                          Networks
                                                          mailing list

                                                          >>
                                                          Subject: Re:
                                                          [manet] On
                                                          Forwarding-and-re=
generation
                                                          (was: Re:

                                                          >>
                                                          draft-ietf-manet-=
aodvv2-13
                                                          review - a
                                                          couple of big
                                                          ticket Items)

                                                          >>

                                                          >>
                                                          -----------------=
-----!
                                                          WARNING !
                                                          -----------------=
-----
                                                          This message
                                                          originates
                                                          from outside
                                                          our
                                                          organisation,
                                                          either from an
                                                          external
                                                          partner or
                                                          from the
                                                          internet.

                                                          >>
                                                          Consider
                                                          carefully
                                                          whether you
                                                          should click
                                                          on any links,
                                                          open any
                                                          attachments or
                                                          reply.

                                                          >>
                                                          Follow the
                                                          'Report
                                                          Suspicious
                                                          Emails' link
                                                          on IT matters
                                                          for
                                                          instructions
                                                          on reporting
                                                          suspicious
                                                          email
                                                          messages.

                                                          >>
                                                          -----------------=
---------------------------------------

                                                          >>

                                                          >> ***
                                                          WARNING ***

                                                          >>
                                                          EXTERNAL EMAIL
                                                          -- This
                                                          message
                                                          originates
                                                          from outside
                                                          our
                                                          organization.

                                                          >>

                                                          >>

                                                          >> Hi
                                                          Henning,

                                                          >>

                                                          >>>
                                                          Am 22.04.2016
                                                          um 11:08
                                                          schrieb
                                                          Henning Rogge
                                                          <hrogge@gmail.com>:

                                                          >>>

                                                          >>>
                                                          On Fri, Apr
                                                          22, 2016 at
                                                          11:05 AM,
                                                          Lotte
                                                          Steenbrink

                                                          >>>
                                                          <lotte.steenbrink@fu-berli=
n.de>
                                                          wrote:

>>>> Hi Thomas,

>>>> Can it?! Iirc, the reason why we adopted the
                                                          =E2=80=9Cregenera=
tion=E2=80=9D
                                                          language

>>>> in the first place is that we=E2=80=99ve been told that
                                                          whenever one
                                                          bit in

>>>> the message (apart from its header) is changed, the
                                                          entire thing
                                                          has to be
                                                          regenerated.

>>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just=
 been
                                                          misunderstanding<=
br>
>>>> each other for more than a year. :( Anyway, it seems
                                                          like we=E2=80=99r=
e

>>>> getting close now, so yay.

                                                          >>>

                                                          >>>
                                                          "Modifying&q=
uot;
                                                          the binary
                                                          message
                                                          instead of
                                                          parsing and
                                                          generating a

                                                          >>>
                                                          new one will
                                                          be difficult
                                                          as soon
                                                          someone writes
                                                          an extension
                                                          to

                                                          >>>
                                                          AODVv2 that
                                                          adds more TLVs
                                                          to the
                                                          message.

                                                          >>

                                                          >> D=E2=80=
=99oh,
                                                          right. Yeah,
                                                          if I remember
                                                          it correctly,
                                                          that=E2=80=99s wh=
at
                                                          you explained
                                                          to me when I
                                                          got confused
                                                          about the
                                                          topic last
                                                          spring=E2=80=A6 B=
ut=E2=80=93
                                                          even if a
                                                          message
                                                          contains TLVs
                                                          that the
                                                          AODVv2
                                                          implementation
                                                          handling it
                                                          doesn=E2=80=99t
                                                          understand, it
                                                          will still be
                                                          able to
                                                          recognize the
                                                          Metric TLV,
                                                          right? Isn=E2=80=
=99t
                                                          that the nifty
                                                          thing about
                                                          RFC5444? So,
                                                          while we
                                                          really
                                                          shouldn=E2=80=99t
                                                          write =E2=80=9Cbe=
fore
                                                          calculating
                                                          the ICV, set
                                                          the n-th 4
                                                          octets to 0=E2=80=
=9D,
                                                          we might say
                                                          =E2=80=9Cidentify=
 the
                                                          octets that
                                                          make up the
                                                          metric value
                                                          and set those
                                                          to 0=E2=80=9D?
                                                          >>

                                                          >> Best
                                                          regards,

                                                          >> Lotte
                                                          >>

                                                          >>>
                                                          Henning Rogge

                                                          >>

                                                          >>
                                                          _________________=
______________________________

                                                          >> manet
                                                          mailing list

                                                          >>=C2=
=A0manet@ietf.org

                                                          >>=C2=
=A0https://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

                                                          >=C2=A0<=
/span>manet@ietf.org

                                                          >=C2=A0<=
/span>https://www.ietf.org/mailman/listinfo/manet

                                                          

_______________________________________________

                                                          manet mailing
                                                          list

                                                          manet@ietf.org

                                                          https://www.iet=
f.org/mailman/listinfo/manet

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                        

                                                      

                                                      _______________=
________________________________

                                                      manet
                                                        mailing list=


                                                      manet@ietf.org

                                                      https://www.i=
etf.org/mailman/listinfo/manet

                                                  

                                                

                                                

                                              

_______________________________________________

                                              manet mailing list

                                              manet@ietf.org

                                              https://www.ietf.org/mailman/l=
istinfo/manet

                                            

                                          

                                        

                                        

                                      

                                    

                                  

                                  

                                    
____________________________=
___________________

                                      manet mailing list

                                      manet@ietf.org

                                      https://www.ietf.org/mailman/lis=
tinfo/manet

                                    

                                  

                                

                              

                            

                          

                        

                      

                    

                    

                  

                  

                  _______________________________________________

                  manet mailing list

                  manet=
@ietf.org

                  https://www.ietf.org/mailman/listinfo/m=
anet

                  

                

              

            

          

          _______________________________________________

          manet mailing list

          manet@ietf.or=
g

          https://www.ietf.org/mailman/listinfo/manet=


        

      

      

      

      

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


    

    

  



_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet





--001a11c335367c22ea05318a7780--


From nobody Thu Apr 28 07:32: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 B2E7712D1A4 for ; Thu, 28 Apr 2016 07:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.915
X-Spam-Level: 
X-Spam-Status: No, score=-7.915 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] 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 JqMzdUfEQ5Xi for ; Thu, 28 Apr 2016 07:32:50 -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 82EFD12B04F for ; Thu, 28 Apr 2016 07:32:42 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,547,1454976000"; d="scan'208,217"; a="65210470"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 28 Apr 2016 15:32:40 +0100
X-IronPort-AV: E=Sophos;i="5.24,547,1454976000";  d="scan'208,217";a="115946350"
Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 28 Apr 2016 15:32:39 +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; Thu, 28 Apr 2016 15:32:40 +0100
From: "Dearlove, Christopher (UK)" 
To: Jiazi YI , Charlie Perkins 
Thread-Topic: [manet] On Forwarding-and-regeneration
Thread-Index: AQHRoOGgsLDvZsE37kmsOhbisZWFTp+fPHiAgAA0ngA=
Date: Thu, 28 Apr 2016 14:32:39 +0000
Message-ID: 
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <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> 
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B230CGLKXM0002VGREEN_"
MIME-Version: 1.0
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: Thu, 28 Apr 2016 14:32:56 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B230CGLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UGxheWluZyBkZXZpbOKAmXMgYWR2b2NhdGUgKGJlY2F1c2UgSSBkb27igJl0IHJlYWxseSBsaWtl
IHRoZSBpZGVhKSBJIHRoaW5rIHdoYXQgeW914oCZZCB3YW50IGlzIHR3byBUTFZzLiBUaGUgZmly
c3QgaXMgc29tZXRoaW5nIGxpa2UgNzE4MiBJQ1YgLSBwb3RlbnRpYWxseSBuZXcgSUNWIHR5cGUg
ZXh0ZW5zaW9uKHMpIC0gdGhhdCBkaWZmZXJzIGZyb20gZXhpc3Rpbmcgb25lcyBieSBoYXZpbmcg
dGhlIGluc3RydWN0aW9uIOKAnGZpbmQgdGhlIHNlY29uZCBUTFYsIGlmIGFueSwgYW5kIHJlbW92
ZSBpdCAoYXMgd2VsbCBhcyB0aGUgSUNWIFRMVikgdGhlbiB1c2UgaXRzIHZhbHVlIGZpZWxkIHRo
YXQgc3BlY2lmaWVzIHdoaWNoIGJ5dGVzIHRvIHplcm8gb3V0LCB0aGVuIGNoZWNrIHRoZSBJQ1Yu
IEkgdGhpbmsgeW914oCZZCB3YW50IHRvIHNwZWNpZnkgYnl0ZXMgdG8gemVybyBvdXQgYnkgbG9j
YXRpb24sIGJ1dCBjb25zdHJhaW4gd2hhdCB0aGV5IHdlcmUgYWxsb3dlZCB0byB6ZXJvIG91dCAt
IGp1c3QgVExWIHZhbHVlIGZpZWxkcyBJIHRoaW5rIHdvdWxkIGJlIGJlc3QuDQoNClRoaXMgdGhl
cmUgY291bGQsIGlmIHlvdSB3ZW50IGRvd24gdGhlIHNpZ25hdHVyZSBhZ2dyZWdhdGlvbiByb3V0
ZSBUaG9tYXMgaGFzIHN1Z2dlc3RlZCBiZSBhIGRpZmZlcmVudCBmaXJzdCBUTFYsIHVzaW5nIHRo
ZSBzYW1lIHNlY29uZCBUTFYsIHdoaWNoIGFnZ3JlZ2F0ZXMgcmF0aGVyIHRoYW4gemVyb3MuDQoN
Ckl0IHdvdWxkIGJlIG11Y2ggbW9yZSBwb3dlcmZ1bCAoZm9yIG9wdGlvbnMgbGlrZSBhZ2dyZWdh
dGlvbikgaWYgdGhlcmUgd2FzIG9ubHkgZXZlciBvbmUgemVyb2VkIG91dCBwYXJ0Lg0KDQpCdXQg
dHdvIHRoaW5ncy4gT25lIGlzIHRoYXQgdGhlIG1vcmUgeW91IGNhbiB6ZXJvIG91dCwgdGhlIG1v
cmUgYXR0YWNrcyB5b3Ugb3BlbiB1cC4gVGhvbWFzIHBvaW50ZWQgb3V0IHRoZSDigJxzZXQgYSB2
ZXJ5IHNtYWxsIGV4cGlyeSB0aW1l4oCdIG9uZS4gQWxzbyB3aGlsZSB0aGUgYWJvdmUgaGFzIGJl
ZW4gdGhvdWdodCB0aHJvdWdoIGEgYml0LCBpdCBpcyBub3QgY29tcGxldGUsIG5vdCByZWFkeSBm
b3IgcHJpbWUgdGltZS4gSXQgY291bGQgYmUgcGFydCBvZiByZWNoYXJ0ZXJlZCB3b3JrLCBidXQg
bm90IG5vdy4gQW5kIHRoZSBtb3JlIGZsZXhpYmxlIGl0IGlzIChtb3JlIHBhcnRzIHplcm9lZCBv
dXQsIGVzcGVjaWFsbHkgaWYgbm90IGNvbnN0cmFpbmVkKSB0aGUgbW9yZSB0aGUgc2VjdXJpdHkg
cGVvcGxlIHdpbGwgbm90IGxpa2UgaXQuDQoNCldoYXQgeW91IGNvdWxkIGdldCBhd2F5IHdpdGgg
aW4gdGVybXMgb2YgaGFuZHdhdmluZyB0byB0aGUgZnV0dXJlIG5vdywgSSBkb27igJl0IGtub3cu
DQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0K
QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBi
YWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJB
RSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFy
aywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3Rl
bXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBs
aWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBO
bzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3Vp
bGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3Vu
Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmlhemkgWUkNClNlbnQ6IDI4IEFwcmlsIDIwMTYg
MTM6MTQNClRvOiBDaGFybGllIFBlcmtpbnMNCkNjOiBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1h
aWxpbmcgbGlzdA0KU3ViamVjdDogUmU6IFttYW5ldF0gT24gRm9yd2FyZGluZy1hbmQtcmVnZW5l
cmF0aW9uDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9t
IG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5l
ciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxk
IGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3Ig
aW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9y
IGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJh
ZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQl
MjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFz
ZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20v
aG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIw
U3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KKioqIFdBUk5JTkcgKioqDQpFWFRFUk5BTCBFTUFJ
TCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlv
bi4NCg0KSSB0aGluayBpdCB3aWxsIG1ha2UgdGhlIHNwZWNpZmljYXRpb24gY29tcGxleCwgYW5k
IGhhcmQgdG8gZXh0ZW5kLg0KDQpXaGF0IGFib3V0IGlmIEkgbmVlZCB0byBkZWZpbmUgYSBuZXcg
VExWIGZpZWxkIGZvciBteSBleHRlbnNpb24/IFRoZSBmaWVsZCB3b3VsZCBlaXRoZXIgYmUgdW5w
cm90ZWN0ZWQsIG9yIHRoZSBleHRlbnNpb24gd29uJ3QgYmUgaW50ZXJvcGVyYWJsZSB3aXRoIG9s
ZCBpbXBsZW1lbnRhdGlvbnMuDQoNCkppYXppDQoNCk9uIFRodSwgQXByIDI4LCAyMDE2IGF0IDI6
MDQgQU0sIENoYXJsaWUgUGVya2lucyA8Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ8bWFp
bHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Pj4gd3JvdGU6DQoNCkhlbGxvIEp1c3Rp
biwNCg0KSSB0aGluayBhIG5ldyBBT0RWLXNwZWNpZmljIElDViBpcyBwcm9iYWJseSB0aGUgcmln
aHQgYW5zd2VyLiAgSXQgd291bGQgYmUgbmljZSB0byBnZXQgc29tZSBoZWxwIGdlbmVyYXRpbmcg
dGhlIHByb3BlciBzZXR0aW5ncyBmb3IgYWxsIG9mIHRoZSBSRkMgNzE4MiBmaWVsZHMgdG8gc3Vw
cG9ydCB0aGlzIGFwcHJvYWNoLiAgSWYgbm90IHRoYXQsIGNvdWxkIHdlIGZhbGwgYmFjayBvbiBS
RkMgNDg2OCwgd2hpY2ggc2VlbXMgcHJldHR5IHN0cmFpZ2h0Zm9yd2FyZD8NCg0KUmVnYXJkcywN
CkNoYXJsaWUgUC4NCk9uIDQvMjcvMjAxNiA0OjI0IFBNLCBKdXN0aW4gRGVhbiB3cm90ZToNCg0K
QW4gYWx0ZXJuYXRpdmUgc29sdXRpb24gdG8gY2hlY2tpbmcgaW50ZWdyaXR5LiBUaGUgY3VycmVu
dCBpY3YgZHJhZnQgaXMgZ29vZCBhdCB2YWxpZGF0aW5nIG1lc3NhZ2VzIGZyb20gYW4gb3JpZ2lu
YWwgc291cmNlLiBPTFNSVjIgYW5kIE5IRFAgdXNlIHRoaXMgdG8gZ29vZCBlZmZlY3QuIEFPRFZW
MiBkb2Vzbid0IGJlY2F1c2UgdGhlIG1lc3NhZ2VzIGFyZSByZWdlbmVyYXRlZDsgSSBiZWxpdmUg
dGhpcyB0byBiZSB0aGUgY29ycmVjdCB0ZXJtIGFzIHRoZSBtZXNzYWdlIGNvbnRhaW5zIGxvY2Fs
IGluZm9ybWF0aW9uLCBwYXRoIGluZm9ybWF0aW9uLCBhbmQgb3JpZ2luYXRvciBpbmZvcm1hdGlv
bi4gR2V0dGluZyB0aGUgaWN2IGRyYWZ0IHRvIHdvcmsgb24gZm9yd2FyZGVkIHBhY2tldHMgaXMg
dWdseSBhcyB0aGV5IHJlYWxseSBhcmUgcmVnZW5lcmF0ZWQgYW5kIHNob3VsZCBiZS4gV2hhdCB3
ZSB3YW50IHRvIGRvIGlzIHNlY3VyZSB0aGUgb3JpZ2luYWwgc291cmNlIG9mIGluZm9ybWF0aW9u
IHdoaWNoIGlzIE9yaWdBZGRyL3RhcmdldCBhZGRyZXNzIGFuZCBzZXF1ZW5jZSBudW1iZXIuIFdo
eSBub3QganVzdCBhdHRhY2ggYSBuZXcgYW9kdiBzcGVjaWZpYyBpY3YgVExWIHdoaWNoIHVzZXMg
VEhBVCBpbmZvIGFuZCBub3RoaW5nIGVsc2U/IFRoZSBjdXJyZW50IGljdiBUTFYgd291bGQvY291
bGQgc3RpbGwgYmUgdXNlZCBvdmVyIHRoZSB3aG9sZSBtZXNzYWdlIGhvcCBieSBob3AgYnkgZWFj
aCByb3V0ZXIsIGFzIHRoZSBtZXNzYWdlcyBhcmUgcmVnZW5lcmF0ZWQuDQoNCkp1c3Rpbg0KDQpP
biBXZWQsIEFwciAyNywgMjAxNiwgNjo0MyBQTSBKaWF6aSBZSSA8aWV0ZkBqaWF6aXlpLmNvbTxt
YWlsdG86aWV0ZkBqaWF6aXlpLmNvbT4+IHdyb3RlOg0KT24gVGh1LCBBcHIgMjgsIDIwMTYgYXQg
MTI6MTkgQU0sIExvdHRlIFN0ZWVuYnJpbmsgPGxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRl
PG1haWx0bzpsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZT4+IHdyb3RlOg0KDQpBbSAyOC4w
NC4yMDE2IHVtIDAwOjE2IHNjaHJpZWIgQ2hyaXN0b3BoZXIgRGVhcmxvdmUgPGNocmlzdG9waGVy
LmRlYXJsb3ZlQGdtYWlsLmNvbTxtYWlsdG86Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29t
Pj46DQoNClRoZSBtb3JlIHlvdSBoYXZlIHRvIHplcm8gb3V0LCB0aGUgbWVzc2llciBpdCBnZXRz
LCBhbmQgdGhlIGxlc3Mgc2VjdXJlIGl0IGdldHMgKG1vcmUgdGhpbmdzIGNhbiBiZSBzcG9vZmVk
KS4gSSB0aGluayB0aGF0J3MgYWJvdXQgYWxsIEkndmUgZ290IHRvIGFkZC4NCg0KT2YgY291cnNl
LiBNeSBxdWVzdGlvbiB3YXMganVzdDoNCiogRG8gd2Ugd2FudCB0byBjb21lIHVwIHdpdGggYW4g
ZXhhY3QgZGVzY3JpcHRpb24gb2YgaG93IHRoZSB6ZXJvaW5nIG91dCBzaG91bGQgd29yayBub3cs
IHdpdGggdGhlIHNob3J0IHRpbWUgd2UgaGF2ZSBsZWZ0Pw0KDQpJZiBhIG1lYW5pbmdmdWwgc2Vj
dXJpdHkgbWVjaGFuaXNtIGlzIHJlcXVpcmVkLCB5ZXMuDQpJIHRoaW5rIHRoZSBmaXJzdCB0aGlu
ZyB0byBkbyBpcyB0byBjdXQgYXMgbWFueSBtdXRhYmxlIGZpZWxkcyBhbmQgb3B0aW9uYWwgZmll
bGRzIGFzIHBvc3NpYmxlLg0KDQpiZXN0DQoNCkppYXppDQoNCm9yDQoqIERvIHdlIG1lbnRpb24g
aW4gdGhlIGRyYWZ0IHRoYXQgemVyb2luZyBvdXQgaGFzIHRvIGhhcHBlbiBzb21laG93IGFuZCBs
ZWF2ZSB0aGUgbml0dHkgZ3JpdHR5IHRvIGZ1dHVyZSB3b3JrPw0KDQpBdCBsZWFzdCB0aGF04oCZ
cyBob3cgSSB1bmRlcnN0b29kIHRoZSBvcHRpb25zIHlvdSBsYWlkIG91dC4uLg0KDQoNCi0tDQpD
aHJpc3RvcGhlciBEZWFybG92ZQ0KY2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tPG1haWx0
bzpjaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb20+IChpUGhvbmUpDQpjaHJpc0BtbmVtb3N5
bmUuZGVtb24uY28udWs8bWFpbHRvOmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51az4gKGhvbWUp
DQoNCg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNCmNocmlzdG9waGVyLmRlYXJsb3ZlQGdt
YWlsLmNvbTxtYWlsdG86Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tPiAoaVBob25lKQ0K
Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrPG1haWx0bzpjaHJpc0BtbmVtb3N5bmUuZGVtb24u
Y28udWs+IChob21lKQ0KT24gMjcgQXByIDIwMTYsIGF0IDIyOjQ2LCBMb3R0ZSBTdGVlbmJyaW5r
IDxsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZTxtYWlsdG86bG90dGUuc3RlZW5icmlua0Bm
dS1iZXJsaW4uZGU+PiB3cm90ZToNCkhpIGFsbCwNCknigJltIGN1cnJlbnRseSByZXZpc2luZyB0
aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd2l0aCByZWdhcmRzIHRvIHRoZSBtb3ZlIGZyb20g
cmVnZW5lcmF0aW9uIHRvIGZvcndhcmRpbmcsIHdoaWNoIGRlcGVuZHMgb24gYSBkZWNpc2lvbiBi
ZWluZyBtYWRlIG9uIGhvdy93aGVyZSB3ZSB3YW50IHRvIG1lbnRpb24gdGhlIHBvc3NpYmlsaXR5
IG9mIHplcm9pbmcgb3V0IFRMVnMgdG8gY2FsY3VsYXRlIHRoZSBJQ1YgZm9yIHRoZSByZXN0IG9m
IGEgbWVzc2FnZeKAmXMgY29udGVudHMgKHNlZSBzZWNvbmQgKiBvZiBteSBsYXN0IGUtbWFpbCku
IEnigJl2ZSBub3QgZm91bmQgYSBkZWNpc2lvbiBvbiB0aGlzIGluIG90aGVyIHRocmVhZCAocGxl
YXNlIHBhcmRvbiBtZSBpZiBJIG92ZXJsb29rZWQgc29tZXRoaW5nKSwgc28gSeKAmWxsIGJ1bXAg
dGhpcyB0aHJlYWQgYW5kIGFzayB0aGUgV0cgZm9yIGl0cyBvcGluaW9ucy4gKGFnYWluLCBwZXJz
b25hbGx5LCB0aGUgMm5kIG9wdGlvbiBvdXRsaW5lZCBieSBDaHJpc3RvcGhlciBzZWVtcyBtb3Jl
IGFwcGVhbGluZyB0byBtZSkNCg0KUmVnYXJkcywNCkxvdHRlDQoNCkFtIDIyLjA0LjIwMTYgdW0g
MTg6MjYgc2NocmllYiBMb3R0ZSBTdGVlbmJyaW5rIDxsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxp
bi5kZTxtYWlsdG86bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4uZGU+PjoNCg0KSGkgYWxsLA0K
dG8gc3VtbWFyaXplOg0KDQoqIEFPRFZ2MiBtZXNzYWdlIFR5cGUgbnVtYmVycyBzaG91bGQgYmUg
aW4gdGhlIEV4cGVyaW1lbnRhbCB0eXBlIHNwYWNlIGFuZCB0aGUgQU9EVnYyIFRMViBUeXBlcyBz
aG91bGQgYmUgbWVzc2FnZSB0eXBlLXNwZWNpZmljLiBUaGlzIGFsc28gbWVhbnMgY2hhbmdpbmcg
dGhlIHRleHQgcmVnYXJkaW5nIElBTkEgYWN0aW9ucyBhbmQgY2hhbmdpbmcgdGhlIHRleHQgcmVn
YXJkaW5nIHdoYXQgdGhlIGV4cGVyaW1lbnQgaXMgdG8gc29tZXRoaW5nIGFsb25nIHRoZSBsaW5l
cyBvZiDigJx3ZSB3YW50IHRvIGdhdGhlciBleHBlcmllbmNlIG9uIGhvdyB0byBtYWtlIGdlbmVy
aWMgbWV0cmljIFRMVnMgYW5kIElDVnMgdGhhdCB3b3JrIHdpdGggY2hhbmdpbmcgbWV0cmljIFRW
IHZhbHVlcyBoYXBwZW4gd2l0aCByZWFjdGl2ZSBwcm90b2NvbHPigJ0NCiogd2XigJlyZSB1bmRl
Y2lkZWQgb24gKHRvIHF1b3RlIENocmlzdG9waGVyKSB0aGUgImhlcmUncyBhIG1lY2hhbmlzbSB3
ZSBoYXZlbid0IHJlYWxseSB0aG91Z2h0IHRocm91Z2ggaW4gZGV0YWlsLCBidXQgYXQgbGVhc3Qg
d2UndmUgZGVmaW5lZCBvbmUiLCBvciAid2Uga25vdyB0aGUgc29ydCBvZiB0aGluZyB3ZSB3YW50
LCBhbmQgd2UnbGwgZGVzY3JpYmUgaXQsIGJ1dCByYXRoZXIgdGhhbiBwcm9kdWNlIHNvbWV0aGlu
ZyBub3QgcXVpdGUgcmlnaHQsIHdlJ2xsIG5vdCBnbyBmdXJ0aGVy4oCcIGRlY2lzaW9uIG9uIHRl
bXBvcmFyaWx5IHNldHRpbmcgdGhlIG1ldHJpYyB2YWx1ZSB0byAwIChpLmUuIHRoZSB3aG8gYW5k
IGhvdykuIChwZXJzb25hbGx5LCBJIHRoaW5rIEnigJlkIHByZWZlciB0aGUgbGF0dGVyIGFwcHJv
YWNoLCBidXQgdGhhdOKAmXMgYW4gZW50aXJlbHkgZ3V0IGZlZWxpbmctYmFzZWQgcHJlZmVyZW5j
ZSkNCg0KRGlkIEkgY2F0Y2ggdGhhdCBjb3JyZWN0bHk/IElmIHNvLCBJ4oCZbGwgcHV0IHRvZ2V0
aGVyIGFuZCBzdWdnZXN0IHNvbWUgdGV4dCBmb3IgdGhlIGZpcnN0IHBvaW50IGFzIHNvb24gYXMg
SSBnZXQgaG9tZSBhbmQgaW4gY2FzZSB0aGVyZSBoYXMgYmVlbiBhIGRlY2lzaW9uIG9uIHRoZSBz
ZWNvbmQgYnkgdGhlbiwgSeKAmWxsIHRyeSB0byB0YWNrbGUgdGhhdCBvbmUgdG9vLiA6KQ0KDQpC
ZXN0IHJlZ2FyZHMsIExvdHRlDQoNCkFtIDIyLjA0LjIwMTYgdW0gMTY6NDEgc2NocmllYiBEZWFy
bG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFp
bHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj46DQoNCkkgaGF2ZSBubyBwcm9ibGVt
IHdpdGggdGhhdC4gSSB3YXMgdHJ5aW5nIHRvIGxheSBvdXQgdGhlIGlzc3VlcyB3aXRob3V0IG11
ZGR5aW5nIHRoZSB3YXRlciB3aXRoIG15IHByZWZlcmVuY2UuDQoNCi0tDQpDaHJpc3RvcGhlciBE
ZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJ
bnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0ICgw
KTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0PiAgfCAgRTogY2hy
aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl
bXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBU
ZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4N
Cnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFF
IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmds
YW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2Vh
cmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IEp1c3RpbiBEZWFu
IFttYWlsdG86YmViZW1hc3RlckBnbWFpbC5jb21dDQpTZW50OiAyMiBBcHJpbCAyMDE2IDE1OjM1
DQpUbzogRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNCkNjOiBUaG9tYXMgSGVpZGUgQ2xhdXNl
bjsgTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3QNClN1YmplY3Q6IFJlOiBbbWFu
ZXRdIE9uIEZvcndhcmRpbmctYW5kLXJlZ2VuZXJhdGlvbiAod2FzOiBSZTogZHJhZnQtaWV0Zi1t
YW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tldCBJdGVtcykNCg0K
DQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBv
dXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBp
bnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24g
YW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlv
biByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxz
IHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5j
b20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBk
Zj4uDQpJZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0
aGlzIHByb2Nlc3M8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsv
c2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3Vz
JTIwRW1haWxzLnBkZj4uDQpTcGVha2luZyBhcyBwYXJ0aWNpcGFudC4NCg0KSSBraW5kIG9mIGxp
a2UgdGhlIGlkZWEgb2YgdXNpbmcgdGhlIGV4cGVyaW1lbnRhbCBtZXNzYWdlIHR5cGUgc3BhY2Uu
ICBXZSBvbmx5IGhhdmUgYSBsaW1pdGVkIGFtb3VudCBvZiB0aGVzZSBtZXNzYWdlIHR5cGVzLiAg
VGhlIFRMViBhc3NpZ25tZW50cyBjb3VsZCBqdXN0IHVzZSB0aGUgbWVzc2FnZSB0eXBlIHNwZWNp
ZmljIHNwYWNlIGFuZCB0aGVyZSBpc24ndCBhbiBpc3N1ZSB0aGVyZS4gIElBTkEgd291bGRuJ3Qg
YXNzaWduIGEgbnVtYmVyIGJ1dCBJIGRvbid0IHNlZSB3aHkgdGhlIGRvY3VtZW50IGNvdWxkbid0
IHNwZWNpZnkgdGhlIGV4cGVyaW1lbnRhbCBudW1iZXJzIGl0IHdhcyBnb2luZyB0byB1c2Ugc28g
b3RoZXIgZnV0dXJlIG5lYXIgdGVybSBleHBlcmllbnRpYWwgcHJvdG9jb2xzIGNvdWxkIGRvIHRo
ZSBzYW1lIGFuZCBnZW5lcmFsbHkgYXZvaWQgY29uZmxpY3QuICBJZiB0aGUgZXhwZXJpbWVudCBp
cyBzdWNjZXNzZnVsIElBTkEgYXNzaWdubWVudHMgY291bGQgYmUgbWFkZS4gIEZ1bmN0aW9uYWxs
eSBubyByZWFsIGRpZmZlcmVuY2Ugd2l0aCBwcm90ZWN0aW9ucyB2cyBsb25nIHRlcm0gdXNhZ2Ug
b2YgbGltaXRlZCBzcGFjZS4NCg0KSnVzdGluDQoNCk9uIEZyaSwgQXByIDIyLCAyMDE2IGF0IDk6
MzUgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0
ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PiB3cm90ZToNClRo
ZXJlJ3MgcmF0aGVyIGEgY29udHJhZGljdGlvbiBiZXR3ZWVuIHRoZSBjb25jZXB0cyBvZiBhIGRl
ZmluaXRpb24gb2YgYSBwcm90b2NvbCwgZXZlbiBFeHBlcmltZW50YWwsIGFuZCBleHBlcmltZW50
YWwgc3BhY2UsIHdoaWNoIHVzdWFsbHkgYXNzdW1lcyB0aGF0IHRoZSB1c2VyIGNhbiBkbyB3aGF0
IGhlIG9yIHNoZSBsaWtlcyBpbiBpdC4NCg0KQnV0IGNoZXdpbmcgdXAgbWVzc2FnZXMgdHlwZXMg
KGhvdyBtYW55LCAzPykgb2Ygd2hpY2ggdGhlcmUgYXJlIHJlbGF0aXZlbHkgZmV3IGZvciBleHBl
cmltZW50YWwgaXMgbG9uZyB0ZXJtIGEgcHJvYmxlbSwgYWx0aG91Z2ggc2hvcnQgdGVybSBub3Qu
DQoNClRMViBzcGFjZSBpcyBlYXNpZXIgaW4gdHdvIHJlZ2FyZHMuIEl0J3MgYmlnZ2VyICh0aG91
Z2ggdGhlIHByaW1lIHJlYWwgZXN0YXRlIG9mIHR5cGUgZXh0ZW5zaW9uIHplcm8gaXNuJ3QpIGFu
ZCBjYW4gaGF2ZSBtZXNzYWdlIHR5cGUgc3BlY2lmaWMgVExWcy4NCg0KU28gVExWUyBjYW4gYWN0
dWFsbHkgYmUgaW52aXNpYmxlLCBpZiB0aGF0IG9wdGlvbiBpcyBjaG9zZW4uIEZvciBtZXNzYWdl
cyBzb21ldGhpbmcgaGFzIHRvIGdpdmUuIExlYXN0IGJhZCBvcHRpb24gaXMgYWdhaW4gb25lIG9m
IHRob3NlIHdlIHNob3VsZCBkaXNjdXNzLCBidXQgdGltZSAuLi4NCg0KKFRvIGJlIHByZWNpc2Us
IG1lc3NhZ2VzIHR5cGVzIGZyb20gMjI0IGFyZSBkZWZpbmVkIGluIFJGQyA1NDQ0IGFzICIgRXhw
ZXJpbWVudGFsIFVzZSIsIG9mIHdoaWNoIEJDUCAyNiBzYXlzICJTaW1pbGFyIHRvIHByaXZhdGUg
b3IgbG9jYWwgdXNlIG9ubHksIHdpdGggdGhlICBwdXJwb3NlIGJlaW5nIHRvIGZhY2lsaXRhdGUg
ZXhwZXJpbWVudGF0aW9uLiIgVGhlIGFsdGVybmF0aXZlIDAtMjIzIHNwYWNlIGlzIEV4cGVydCBS
ZXZpZXcuIElBTkEgc3RpbGwgdGhpbmtzIHRoZSBleHBlcnRzIGFyZSBKb2UgTWFja2VyIGFuZCB0
aGUgcmVjdXNlZCBTdGFuIFJhdGxpZmYuIEJ1dCB0aGF0J3MgYSBzb2x1YmxlIG5pdC4pDQoNCi0t
DQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5
c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQy
MTk0PiAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRl
YXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j
ZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwg
RXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3Rl
bXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVn
aXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmlj
ZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRob21hcyBIZWlkZSBDbGF1c2VuIFtt
YWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzxtYWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9y
Zz5dDQpTZW50OiAyMiBBcHJpbCAyMDE2IDE0OjIxDQpUbzogRGVhcmxvdmUsIENocmlzdG9waGVy
IChVSykNCkNjOiBMb3R0ZSBTdGVlbmJyaW5rOyBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxp
bmcgbGlzdA0KU3ViamVjdDogUmU6IFttYW5ldF0gT24gRm9yd2FyZGluZy1hbmQtcmVnZW5lcmF0
aW9uICh3YXM6IFJlOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBs
ZSBvZiBiaWcgdGlja2V0IEl0ZW1zKQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5H
ICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91
dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBv
ciBmcm9tIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91
bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZv
bGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZv
ciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQot
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
DQoNCj4gT24gMjIgYXZyLiAyMDE2LCBhdCAxNTowNSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChV
SykgPGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBi
YWVzeXN0ZW1zLmNvbT4+IHdyb3RlOg0KPg0KPiBPbmNlIHlvdSdyZSBlbnRpcmVseSBpbiBBT0RW
MidzIG93biBzcGFjZSwgYW5kIEFPRFZ2MiBpcyBleHBlcmltZW50YWwgKHdvcmtpbmcgYXNzdW1w
dGlvbiBmb3IgdGhpcyBkaXNjdXNzaW9uKSB5b3UgaGF2ZSBtb3JlIGxpYmVydHkuDQo+DQoNClll
cC4NCg0KVGFrZW4gc29tZXdoYXQgYnkgc3VycHJpc2UgYm90aCBieSB0aGUgc3VkZGVuICJydXNo
IiBhbmQgdGhlIGV4cGVyaW1lbnRhbCBtYXR1cml0eSBsZXZlbCwgSSBhbSB3b25kZXJpbmcgKGFu
ZCBoYXZlbid0IHRob3VnaHQgdGhyb3VnaCkgYWJvdXQgZXhwZXJpbWVudGFsIHNwYWNlIHZzIG5v
bi1leHBlcmltZW50YWwgKGZvciBtZXNzYWdlIHR5cGVzLCBhbmQgY29uc2VxdWVudGx5IGZvciBt
ZXNzYWdlIHR5cGUgc3BlY2lmaWMgVExWIHR5cGVzKS4NCg0KSSB0aGluayB0aGF0IGlmIHRoZSBB
T0RWdjIgZXhwZXJpbWVudCBzcGVjaWZpZXMgdGhlIHVzZSBvZiBNZXNzYWdlIHR5cGVzIGZyb20g
dGhlIEV4cGVyaW1lbnRhbCBtZXNzYWdlIHR5cGUgc3BhY2Ugd2l0aG91dCBtYWtpbmcgYWN0dWFs
IHJlZ2lzdHJhdGlvbnMgaW4gdGhlIElBTkEgcmVnaXN0cnksIEFORCB0aGUgdXNlIG9mIHR5cGUg
c3BlY2lmaWMgVExWIHR5cGVzLCB0aGlzIGJlY29tZXMgYSBub24taXNzdWUgZW50aXJlbHkgKGJ5
IGRlc2lnbiwgdGhpcyBpcyBwcmVjaXNlbHkgd2hhdCB0aGF0IGV4cGVyaW1lbnRhbCBzcGFjZSBp
cyBmb3IpDQoNCldoZXJlYXMsIGFzIHlvdSBwb2ludCBvdXQsIHRoZSBhbHRlcm5hdGl2ZSBpcyBh
ICJjYW4gb3BlbiAtIHdvcm1zIGV2ZXJ5d2hlcmUiIHNpdHVhdGlvbiB0aGF0IEkgdGhpbmsgdGlt
ZSBpcyB0b28gc2hvcnQgdG8gc29sdmU/DQoNClRob21hcw0KDQoNCj4gVGhlbiB5b3UgY291bGQg
dHJ5IHNwZWNpZnlpbmcgaXQuIEJ1dCB3aXRoIGEgdmVyeSBnb29kIGNoYW5jZSBvZiBwcm9kdWNp
bmcgc29tZXRoaW5nIHlvdSBsYXRlciBkZWNpZGUgeW91IHNob3VsZCBoYXZlIGRvbmUgZGlmZmVy
ZW50bHkuDQo+DQo+IEkgaG9uZXN0bHkgZG9uJ3Qga25vdyB3aGljaCB3b3VsZCBnbyBkb3duIGJl
dHRlciAob3IgbGVzcyBiYWRseSkgLSAiaGVyZSdzIGEgbWVjaGFuaXNtIHdlIGhhdmVuJ3QgcmVh
bGx5IHRob3VnaHQgdGhyb3VnaCBpbiBkZXRhaWwsIGJ1dCBhdCBsZWFzdCB3ZSd2ZSBkZWZpbmVk
IG9uZSIsIG9yICJ3ZSBrbm93IHRoZSBzb3J0IG9mIHRoaW5nIHdlIHdhbnQsIGFuZCB3ZSdsbCBk
ZXNjcmliZSBpdCwgYnV0IHJhdGhlciB0aGFuIHByb2R1Y2Ugc29tZXRoaW5nIG5vdCBxdWl0ZSBy
aWdodCwgd2UnbGwgbm90IGdvIGZ1cnRoZXIiLg0KPg0KPiAtLQ0KPiBDaHJpc3RvcGhlciBEZWFy
bG92ZQ0KPiBTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQo+IEJBRSBTeXN0ZW1zIEFwcGxpZWQg
SW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPiBUOiAg
KzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0PiAgfCAg
RTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh
ZXN5c3RlbXMuY29tPg0KPg0KPiBCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hl
bG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXgg
Q00yIDhITi4NCj4gd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5j
b20vYWk+DQo+IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNCj4gUmVn
aXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQo+IFJlZ2lzdGVyZWQgT2Zm
aWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCj4N
Cj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTG90dGUgU3RlZW5icmlu
ayBbbWFpbHRvOmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRlPG1haWx0bzpsb3R0ZS5zdGVl
bmJyaW5rQGZ1LWJlcmxpbi5kZT5dDQo+IFNlbnQ6IDIyIEFwcmlsIDIwMTYgMTM6NTkNCj4gVG86
IE1vYmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0DQo+IENjOiBIZW5uaW5nIFJvZ2dl
OyBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KPiBTdWJqZWN0OiBSZTogW21hbmV0XSBPbiBG
b3J3YXJkaW5nLWFuZC1yZWdlbmVyYXRpb24gKHdhczogUmU6IGRyYWZ0LWlldGYtbWFuZXQtYW9k
dnYyLTEzIHJldmlldyAtIGEgY291cGxlIG9mIGJpZyB0aWNrZXQgSXRlbXMpDQo+DQo+IC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMg
bWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIg
ZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVybmV0Lg0KPiBDb25zaWRl
ciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBh
bnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQo+IEZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3Vz
IEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5n
IHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IEhlbGxvIENocmlzdG9waGVyLA0K
Pg0KPj4gQW0gMjIuMDQuMjAxNiB1bSAxMTo1NyBzY2hyaWViIERlYXJsb3ZlLCBDaHJpc3RvcGhl
ciAoVUspIDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxv
dmVAYmFlc3lzdGVtcy5jb20+PjoNCj4+DQo+PiBKdXN0IGJlIGNhcmVmdWwgdG8gbm90ZSB0aGF0
IHRoaXMgY29uY2VwdCBpcyBhcyBjdXJyZW50bHkgYmVpbmcgZGlzY3Vzc2VkIChhKSBzcGVjaWZp
YyB0byBBT0RWdjIsIGFuZCAoYikgbm90IGFuIGFwcGxpY2F0aW9uIG9mIDcxODIsIHdoaWNoIGhh
cyBubyBrbm93bGVkZ2Ugb2Ygc3BlY2lhbCBUTFZzLg0KPj4NCj4+IFRoaXMgaXMgc29tZXRoaW5n
IHdlJ2Qgd2FudCB0byBnZXQgcmlnaHQsIGFuZCBuZWVkIHRvIGdldCByaWdodCBpZiBpbiBhbnkg
c3BhY2Ugbm90IHNwZWNpZmljIHRvIEFET0RWdjIsIGJlY2F1c2UgZ2V0dGluZyBpdCB3cm9uZyBw
cm9kdWNlcyBmdXR1cmUgcHJvYmxlbXMuDQo+DQo+IE1ha2VzIHNlbnNlLg0KPg0KPj4gSSBjYW4g
c2VlIHNvbWUgcG9zc2libGUgYXBwcm9hY2hlcywgbm9uZSBpcyBpZGVhbCBhbmQgd2UncmUgcmF0
aGVyIG91dA0KPj4gb2YgdGltZSB0byBzcGVjaWZ5LiBCdXQgdGhpcyBpcyBleHBlcmltZW50YWws
IHNvIEkgdGhpbmsgd2UgbWlnaHQgYmUNCj4+IGFibGUgdG8gaW5kaWNhdGUgdGhlIHNoYXBlIG9m
IHRoZSBzb2x1dGlvbiB3aXRob3V0IHNwZWNpZnlpbmcgaXQsDQo+PiB3aGljaCB3b3VsZCBiZSBh
IGRpZmZlcmVudCBSRkMsIHVuZGVyIGEgYml0IGxlc3MgdGltZSBwcmVzc3VyZS4NCj4+IChFeHRl
bnNpb25zIHRvIGV4aXN0aW5nIHByb3RvY29scyBsaWtlIDcxODIgd291bGQgbmF0dXJhbGx5IGJl
IGluDQo+PiBzY29wZSByZWNoYXJ0ZXJlZCBJIHRoaW5rLikNCj4+DQo+PiBUbyBpbmRpY2F0ZSB0
aGUgcmFuZ2UgdGhhdCdzIG9wZW4sIGhlcmUgYXJlIHR3byBwb3NzaWJsZSBpZGVhcywgb25lIG9m
IHdoaWNoIGhhcyBhbiBpbXBhY3Qgbm93LCBzbyBuZWVkcyB0byBiZSBhZ3JlZWQuIE5vdGUgdGhh
dCBJJ20gbm90IHN1Z2dlc3RpbmcgKGluIGZhY3QgcXVpdGUgdGhlIG9wcG9zaXRlKSBkZWZpbmlu
ZyBhbiBleHRlbnNpb24gdG8gNzE4MiBoZXJlLCByYXRoZXIgZW5hYmxpbmcgc3VjaCBhbiBleHRl
bnNpb24sIGlmIHdyaXR0ZW4sIHRvICJkbyB0aGUgcmlnaHQgdGhpbmciLg0KPj4gLSBXZSBoYXZl
IGFuIGV4dGVuc2lvbiB0byA3MTgyIHRoYXQgc2F5cyAiemVybyBvdXQgYWxsIHZhbHVlIG9jdGV0
cyBpbiBwcm90b2NvbCBzcGVjaWZpYyBUTFZzLiBUaGF0IHJlcXVpcmVzIG5vdyBwdXR0aW5nIHRo
ZSBBT0RWdjIgbWV0cmljIFRMViBpbiB0aGF0IHNwYWNlLg0KPg0KPiBKdXN0IHRvIG1ha2Ugc3Vy
ZSB0aGF0IEkgdW5kZXJzdG9vZCB5b3UgY29ycmVjdGx54oCTIOKAnHRoYXQgc3BhY2XigJ0gbWVh
bmluZyBtYWtpbmcgdGhlIEFPRFZ2MiBtZXRyaWMgVExWIHByb3RvY29sIHNwZWNpZmljPyAoQnkg
4oCcdGhlIGFvZHZ2MiBtZXRyaWMgdGx24oCdIEnigJltIHJlZmVycmluZyB0byB0aGUgZ2VuZXJp
YyBUTFYgd2XigJl2ZSBiZWVuIHRhbGtpbmcgYWJvdXQgb24gdGhpcyBsaXN0IGVhcmxpZXIgdGhp
cyB3ZWVrKS4NCj4NCj4+IC0gV2UgaGF2ZSBhbiBleHRlbnNpb24gdG8gNzE4MiB0aGF0IGFkZHMg
ZXh0cmEgbWF0ZXJpYWwgdG8gdGhlIHZhbHVlIGZpZWxkIHRoYXQgaW5kaWNhdGVzIChUQkQgaG93
LCBieSBwb3NpdGlvbiB3aXRoIHNhbml0eSBjaGVjayB0aGF0IHRoaXMgaXMgVExWIHZhbHVlIHBl
cmhhcHM/KSB3aGljaCBvY3RldHMgYXJlIHRvIGJlIHplcm9lZCBvdXQgYmVmb3JlIHRoZSBJQ1Yg
aXMgY2FsY3VsYXRlZC4NCj4NCj4gVGhlIHdheSBJIHVuZGVyc3RhbmQgdGhhdCBhcHByb2FjaCwg
aXQgd291bGRu4oCZdCB3YXJyYW50IGFueSBhY3Rpb24gZnJvbSBBT0RWdjIgYmVzaWRlcyBzYXlp
bmcg4oCcaWYgeW91IGNhbGN1bGF0ZSB0aGUgSUNWLCBzZXQgdGhlIE1ldHJpYyB2YWx1ZSB0byB6
ZXJv4oCdIChsZWF2aW5nIHRoZSBuaXR0eSBncml0dHkgb2YgaG93IHRoaXMgd291bGQgYmUgZG9u
ZSBpbiBkZXRhaWwgdG8gZnV0dXJlIHdvcmsp4oCmIElzIHRoYXQgY29ycmVjdD8NCj4NCj4+DQo+
PiBXZSBkbyBub3QgaGF2ZSB0aGUgdGltZSB0byBzcGVjaWZ5IHRoaXMgaW4gYW4gYWNjZXB0YWJs
ZSBtYW5uZXIgd2l0aGluIHR3byB3ZWVrcyB0aG91Z2guIEJ1dCB0aGUgc2VjdXJpdHkgY29uc2lk
ZXJhdGlvbiBzZWN0aW9uIGNvdWxkIHNheSBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mICJ0
aGlzIGVuYWJsZXMgdGhlIHVzZSBvZiBhbiBJQ1YgZGVmaW5lZCB0byB6ZXJvIG91dCB0aGVzZSBv
Y3RldHPigJwuDQo+DQo+IE9rYXkuIDopDQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gTG90dGUNCj4N
Cj4+DQo+PiAtLQ0KPj4gQ2hyaXN0b3BoZXIgRGVhcmxvdmUNCj4+IFNlbmlvciBQcmluY2lwYWwg
RW5naW5lZXINCj4+IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmll
cw0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPj4gX19fXw0KPj4NCj4+IFQ6ICArNDQgKDApMTI0NSAyNDIx
OTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92
ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQo+
Pg0KPj4gQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5v
bG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQo+PiB3
d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCj4+IEJB
RSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQgUmVnaXN0ZXJlZCBpbiBFbmds
YW5kICYgV2FsZXMNCj4+IE5vOiAwMTMzNzQ1MSBSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJl
c2VhcmNoIFBhcmssIEd1aWxkZm9yZCwNCj4+IFN1cnJleSwgR1UyIDdZUA0KPj4NCj4+IC0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5j
ZXNAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2Yg
TG90dGUNCj4+IFN0ZWVuYnJpbmsNCj4+IFNlbnQ6IDIyIEFwcmlsIDIwMTYgMTA6MjgNCj4+IFRv
OiBIZW5uaW5nIFJvZ2dlDQo+PiBDYzogTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxp
c3QNCj4+IFN1YmplY3Q6IFJlOiBbbWFuZXRdIE9uIEZvcndhcmRpbmctYW5kLXJlZ2VuZXJhdGlv
biAod2FzOiBSZToNCj4+IGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTEzIHJldmlldyAtIGEgY291
cGxlIG9mIGJpZyB0aWNrZXQgSXRlbXMpDQo+Pg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEg
V0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMg
ZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBh
cnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuDQo+PiBDb25zaWRlciBjYXJlZnVsbHkgd2hldGhl
ciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3Ig
cmVwbHkuDQo+PiBGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24g
SVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWls
IG1lc3NhZ2VzLg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCj4+DQo+PiAqKiogV0FSTklORyAqKioNCj4+IEVYVEVSTkFMIEVNQUlM
IC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9u
Lg0KPj4NCj4+DQo+PiBIaSBIZW5uaW5nLA0KPj4NCj4+PiBBbSAyMi4wNC4yMDE2IHVtIDExOjA4
IHNjaHJpZWIgSGVubmluZyBSb2dnZSA8aHJvZ2dlQGdtYWlsLmNvbTxtYWlsdG86aHJvZ2dlQGdt
YWlsLmNvbT4+Og0KPj4+DQo+Pj4gT24gRnJpLCBBcHIgMjIsIDIwMTYgYXQgMTE6MDUgQU0sIExv
dHRlIFN0ZWVuYnJpbmsNCj4+PiA8bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4uZGU8bWFpbHRv
OmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRlPj4gd3JvdGU6DQo+Pj4+IEhpIFRob21hcywN
Cj4+Pj4gQ2FuIGl0PyEgSWlyYywgdGhlIHJlYXNvbiB3aHkgd2UgYWRvcHRlZCB0aGUg4oCccmVn
ZW5lcmF0aW9u4oCdIGxhbmd1YWdlDQo+Pj4+IGluIHRoZSBmaXJzdCBwbGFjZSBpcyB0aGF0IHdl
4oCZdmUgYmVlbiB0b2xkIHRoYXQgd2hlbmV2ZXIgb25lIGJpdCBpbg0KPj4+PiB0aGUgbWVzc2Fn
ZSAoYXBhcnQgZnJvbSBpdHMgaGVhZGVyKSBpcyBjaGFuZ2VkLCB0aGUgZW50aXJlIHRoaW5nIGhh
cyB0byBiZSByZWdlbmVyYXRlZC4NCj4+Pj4gSeKAmW0gc3RhcnRpbmcgdG8gZ2V0IHRoZSBmZWVs
aW5nIHdl4oCZdmUganVzdCBiZWVuIG1pc3VuZGVyc3RhbmRpbmcNCj4+Pj4gZWFjaCBvdGhlciBm
b3IgbW9yZSB0aGFuIGEgeWVhci4gOiggQW55d2F5LCBpdCBzZWVtcyBsaWtlIHdl4oCZcmUNCj4+
Pj4gZ2V0dGluZyBjbG9zZSBub3csIHNvIHlheS4NCj4+Pg0KPj4+ICJNb2RpZnlpbmciIHRoZSBi
aW5hcnkgbWVzc2FnZSBpbnN0ZWFkIG9mIHBhcnNpbmcgYW5kIGdlbmVyYXRpbmcgYQ0KPj4+IG5l
dyBvbmUgd2lsbCBiZSBkaWZmaWN1bHQgYXMgc29vbiBzb21lb25lIHdyaXRlcyBhbiBleHRlbnNp
b24gdG8NCj4+PiBBT0RWdjIgdGhhdCBhZGRzIG1vcmUgVExWcyB0byB0aGUgbWVzc2FnZS4NCj4+
DQo+PiBE4oCZb2gsIHJpZ2h0LiBZZWFoLCBpZiBJIHJlbWVtYmVyIGl0IGNvcnJlY3RseSwgdGhh
dOKAmXMgd2hhdCB5b3UgZXhwbGFpbmVkIHRvIG1lIHdoZW4gSSBnb3QgY29uZnVzZWQgYWJvdXQg
dGhlIHRvcGljIGxhc3Qgc3ByaW5n4oCmIEJ1dOKAkyBldmVuIGlmIGEgbWVzc2FnZSBjb250YWlu
cyBUTFZzIHRoYXQgdGhlIEFPRFZ2MiBpbXBsZW1lbnRhdGlvbiBoYW5kbGluZyBpdCBkb2VzbuKA
mXQgdW5kZXJzdGFuZCwgaXQgd2lsbCBzdGlsbCBiZSBhYmxlIHRvIHJlY29nbml6ZSB0aGUgTWV0
cmljIFRMViwgcmlnaHQ/IElzbuKAmXQgdGhhdCB0aGUgbmlmdHkgdGhpbmcgYWJvdXQgUkZDNTQ0
ND8gU28sIHdoaWxlIHdlIHJlYWxseSBzaG91bGRu4oCZdCB3cml0ZSDigJxiZWZvcmUgY2FsY3Vs
YXRpbmcgdGhlIElDViwgc2V0IHRoZSBuLXRoIDQgb2N0ZXRzIHRvIDDigJ0sIHdlIG1pZ2h0IHNh
eSDigJxpZGVudGlmeSB0aGUgb2N0ZXRzIHRoYXQgbWFrZSB1cCB0aGUgbWV0cmljIHZhbHVlIGFu
ZCBzZXQgdGhvc2UgdG8gMOKAnT8NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBMb3R0ZQ0KPj4N
Cj4+PiBIZW5uaW5nIFJvZ2dlDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4+IG1hbmV0IG1haWxpbmcgbGlzdA0KPj4gbWFuZXRAaWV0Zi5v
cmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9tYW5ldA0KPj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+IFRoaXMgZW1haWwgYW5kIGFueSBh
dHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZA0KPj4gcmVjaXBpZW50
IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQN
Cj4+IHJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlm
eSB0aGUgc2VuZGVyLg0KPj4gWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFu
eSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcg0KPj4gZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8g
YW55IG90aGVyIHBlcnNvbi4NCj4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+DQo+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1hbmV0IG1haWxpbmcgbGlzdA0KPiBt
YW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8
bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9tYW5ldA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0
Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWls
aW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRA
aWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9tYW5ldA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0
bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bWFuZXQNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpt
YW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4N
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQptYW5ldCBtYWlsaW5n
IGxpc3QNCg0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KDQpodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFu
ZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B230CGLKXM0002VGREEN_
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
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBs
YXlpbmcgZGV2aWzigJlzIGFkdm9jYXRlIChiZWNhdXNlIEkgZG9u4oCZdCByZWFsbHkgbGlrZSB0
aGUgaWRlYSkgSSB0aGluayB3aGF0IHlvdeKAmWQgd2FudCBpcyB0d28gVExWcy4gVGhlIGZpcnN0
IGlzIHNvbWV0aGluZyBsaWtlIDcxODIgSUNWIC0gcG90ZW50aWFsbHkgbmV3DQogSUNWIHR5cGUg
ZXh0ZW5zaW9uKHMpIC0gdGhhdCBkaWZmZXJzIGZyb20gZXhpc3Rpbmcgb25lcyBieSBoYXZpbmcg
dGhlIGluc3RydWN0aW9uIOKAnGZpbmQgdGhlIHNlY29uZCBUTFYsIGlmIGFueSwgYW5kIHJlbW92
ZSBpdCAoYXMgd2VsbCBhcyB0aGUgSUNWIFRMVikgdGhlbiB1c2UgaXRzIHZhbHVlIGZpZWxkIHRo
YXQgc3BlY2lmaWVzIHdoaWNoIGJ5dGVzIHRvIHplcm8gb3V0LCB0aGVuIGNoZWNrIHRoZSBJQ1Yu
IEkgdGhpbmsgeW914oCZZCB3YW50IHRvDQogc3BlY2lmeSBieXRlcyB0byB6ZXJvIG91dCBieSBs
b2NhdGlvbiwgYnV0IGNvbnN0cmFpbiB3aGF0IHRoZXkgd2VyZSBhbGxvd2VkIHRvIHplcm8gb3V0
IC0ganVzdCBUTFYgdmFsdWUgZmllbGRzIEkgdGhpbmsgd291bGQgYmUgYmVzdC48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PlRoaXMgdGhlcmUgY291bGQsIGlmIHlvdSB3ZW50IGRvd24gdGhlIHNpZ25hdHVyZSBhZ2dyZWdh
dGlvbiByb3V0ZSBUaG9tYXMgaGFzIHN1Z2dlc3RlZCBiZSBhIGRpZmZlcmVudCBmaXJzdCBUTFYs
IHVzaW5nIHRoZSBzYW1lIHNlY29uZCBUTFYsIHdoaWNoIGFnZ3JlZ2F0ZXMNCiByYXRoZXIgdGhh
biB6ZXJvcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0IHdvdWxkIGJlIG11Y2ggbW9yZSBwb3dlcmZ1bCAoZm9yIG9w
dGlvbnMgbGlrZSBhZ2dyZWdhdGlvbikgaWYgdGhlcmUgd2FzIG9ubHkgZXZlciBvbmUgemVyb2Vk
IG91dCBwYXJ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0IHR3byB0aGluZ3MuIE9uZSBpcyB0aGF0IHRoZSBtb3Jl
IHlvdSBjYW4gemVybyBvdXQsIHRoZSBtb3JlIGF0dGFja3MgeW91IG9wZW4gdXAuIFRob21hcyBw
b2ludGVkIG91dCB0aGUg4oCcc2V0IGEgdmVyeSBzbWFsbCBleHBpcnkgdGltZeKAnSBvbmUuIEFs
c28gd2hpbGUgdGhlDQogYWJvdmUgaGFzIGJlZW4gdGhvdWdodCB0aHJvdWdoIGEgYml0LCBpdCBp
cyBub3QgY29tcGxldGUsIG5vdCByZWFkeSBmb3IgcHJpbWUgdGltZS4gSXQgY291bGQgYmUgcGFy
dCBvZiByZWNoYXJ0ZXJlZCB3b3JrLCBidXQgbm90IG5vdy4gQW5kIHRoZSBtb3JlIGZsZXhpYmxl
IGl0IGlzIChtb3JlIHBhcnRzIHplcm9lZCBvdXQsIGVzcGVjaWFsbHkgaWYgbm90IGNvbnN0cmFp
bmVkKSB0aGUgbW9yZSB0aGUgc2VjdXJpdHkgcGVvcGxlIHdpbGwgbm90DQogbGlrZSBpdC48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPldoYXQgeW91IGNvdWxkIGdldCBhd2F5IHdpdGggaW4gdGVybXMgb2YgaGFuZHdhdmlu
ZyB0byB0aGUgZnV0dXJlIG5vdywgSSBkb27igJl0IGtub3cuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
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+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G
cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g
bWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv
Yj5KaWF6aSBZSTxicj4NCjxiPlNlbnQ6PC9iPiAyOCBBcHJpbCAyMDE2IDEzOjE0PGJyPg0KPGI+
VG86PC9iPiBDaGFybGllIFBlcmtpbnM8YnI+DQo8Yj5DYzo8L2I+IE1vYmlsZSBBZCBIb2MgTmV0
d29ya3MgbWFpbGluZyBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFuZXRdIE9uIEZv
cndhcmRpbmctYW5kLXJlZ2VuZXJhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
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
bWFsIj5JIHRoaW5rIGl0IHdpbGwgbWFrZSB0aGUgc3BlY2lmaWNhdGlvbiBjb21wbGV4LCBhbmQg
aGFyZCB0byBleHRlbmQuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5XaGF0IGFib3V0IGlmIEkgbmVlZCB0byBkZWZpbmUgYSBuZXcgVExWIGZpZWxk
IGZvciBteSBleHRlbnNpb24/IFRoZSBmaWVsZCB3b3VsZCBlaXRoZXIgYmUgdW5wcm90ZWN0ZWQs
IG9yIHRoZSBleHRlbnNpb24gd29uJ3QgYmUgaW50ZXJvcGVyYWJsZSB3aXRoIG9sZCBpbXBsZW1l
bnRhdGlvbnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkppYXppPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
T24gVGh1LCBBcHIgMjgsIDIwMTYgYXQgMjowNCBBTSwgQ2hhcmxpZSBQZXJraW5zICZsdDs8YSBo
cmVmPSJtYWlsdG86Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQiIHRhcmdldD0iX2JsYW5r
Ij5jaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxwPkhlbGxvIEp1c3Rpbiw8bzpwPjwvbzpwPjwvcD4NCjxwPkkgdGhpbmsg
YSBuZXcgQU9EVi1zcGVjaWZpYyBJQ1YgaXMgcHJvYmFibHkgdGhlIHJpZ2h0IGFuc3dlci4mbmJz
cDsgSXQgd291bGQgYmUgbmljZSB0byBnZXQgc29tZSBoZWxwIGdlbmVyYXRpbmcgdGhlIHByb3Bl
ciBzZXR0aW5ncyBmb3IgYWxsIG9mIHRoZSBSRkMgNzE4MiBmaWVsZHMgdG8gc3VwcG9ydCB0aGlz
IGFwcHJvYWNoLiZuYnNwOyBJZiBub3QgdGhhdCwgY291bGQgd2UgZmFsbCBiYWNrIG9uIFJGQyA0
ODY4LCB3aGljaCBzZWVtcyBwcmV0dHkgc3RyYWlnaHRmb3J3YXJkPzxvOnA+PC9vOnA+PC9wPg0K
PHA+UmVnYXJkcyw8YnI+DQpDaGFybGllIFAuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+T24gNC8yNy8yMDE2IDQ6MjQgUE0sIEp1c3RpbiBEZWFuIHdyb3RlOjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwPkFuIGFsdGVybmF0aXZlIHNvbHV0aW9uIHRvIGNo
ZWNraW5nIGludGVncml0eS4gVGhlIGN1cnJlbnQgaWN2IGRyYWZ0IGlzIGdvb2QgYXQgdmFsaWRh
dGluZyBtZXNzYWdlcyBmcm9tIGFuIG9yaWdpbmFsIHNvdXJjZS4gT0xTUlYyIGFuZCBOSERQIHVz
ZSB0aGlzIHRvIGdvb2QgZWZmZWN0LiBBT0RWVjIgZG9lc24ndCBiZWNhdXNlIHRoZSBtZXNzYWdl
cyBhcmUgcmVnZW5lcmF0ZWQ7IEkgYmVsaXZlIHRoaXMgdG8gYmUgdGhlIGNvcnJlY3QgdGVybQ0K
IGFzIHRoZSBtZXNzYWdlIGNvbnRhaW5zIGxvY2FsIGluZm9ybWF0aW9uLCBwYXRoIGluZm9ybWF0
aW9uLCBhbmQgb3JpZ2luYXRvciBpbmZvcm1hdGlvbi4gR2V0dGluZyB0aGUgaWN2IGRyYWZ0IHRv
IHdvcmsgb24gZm9yd2FyZGVkIHBhY2tldHMgaXMgdWdseSBhcyB0aGV5IHJlYWxseSBhcmUgcmVn
ZW5lcmF0ZWQgYW5kIHNob3VsZCBiZS4gV2hhdCB3ZSB3YW50IHRvIGRvIGlzIHNlY3VyZSB0aGUg
b3JpZ2luYWwgc291cmNlIG9mIGluZm9ybWF0aW9uDQogd2hpY2ggaXMgT3JpZ0FkZHIvdGFyZ2V0
IGFkZHJlc3MgYW5kIHNlcXVlbmNlIG51bWJlci4gV2h5IG5vdCBqdXN0IGF0dGFjaCBhIG5ldyBh
b2R2IHNwZWNpZmljIGljdiBUTFYgd2hpY2ggdXNlcyBUSEFUIGluZm8gYW5kIG5vdGhpbmcgZWxz
ZT8gVGhlIGN1cnJlbnQgaWN2IFRMViB3b3VsZC9jb3VsZCBzdGlsbCBiZSB1c2VkIG92ZXIgdGhl
IHdob2xlIG1lc3NhZ2UgaG9wIGJ5IGhvcCBieSBlYWNoIHJvdXRlciwgYXMgdGhlIG1lc3NhZ2Vz
IGFyZQ0KIHJlZ2VuZXJhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHA+SnVzdGluPG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBcHIgMjcsIDIwMTYsIDY6NDMgUE0g
SmlhemkgWUkgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGppYXppeWkuY29tIiB0YXJnZXQ9Il9i
bGFuayI+aWV0ZkBqaWF6aXlpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwg
QXByIDI4LCAyMDE2IGF0IDEyOjE5IEFNLCBMb3R0ZSBTdGVlbmJyaW5rICZsdDs8YSBocmVmPSJt
YWlsdG86bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4uZGUiIHRhcmdldD0iX2JsYW5rIj5sb3R0
ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFtIDI4LjA0LjIwMTYgdW0gMDA6MTYgc2No
cmllYiBDaHJpc3RvcGhlciBEZWFybG92ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdG9waGVy
LmRlYXJsb3ZlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdG9waGVyLmRlYXJsb3Zl
QGdtYWlsLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoZSBt
b3JlIHlvdSBoYXZlIHRvIHplcm8gb3V0LCB0aGUgbWVzc2llciBpdCBnZXRzLCBhbmQgdGhlIGxl
c3Mgc2VjdXJlIGl0IGdldHMgKG1vcmUgdGhpbmdzIGNhbiBiZSBzcG9vZmVkKS4gSSB0aGluayB0
aGF0J3MgYWJvdXQgYWxsIEkndmUgZ290IHRvIGFkZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPk9mIGNvdXJzZS4gTXkgcXVlc3Rpb24gd2FzIGp1c3Q6PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIERvIHdlIHdh
bnQgdG8gY29tZSB1cCB3aXRoIGFuIGV4YWN0IGRlc2NyaXB0aW9uIG9mIGhvdyB0aGUgemVyb2lu
ZyBvdXQgc2hvdWxkIHdvcmsgbm93LCB3aXRoIHRoZSBzaG9ydCB0aW1lIHdlIGhhdmUgbGVmdD88
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+SWYgYSBtZWFuaW5nZnVsIHNlY3VyaXR5IG1lY2hhbmlzbSBpcyByZXF1aXJlZCwg
eWVzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SSB0aGluayB0aGUgZmlyc3QgdGhpbmcgdG8gZG8gaXMgdG8gY3V0IGFzIG1hbnkgbXV0
YWJsZSBmaWVsZHMgYW5kIG9wdGlvbmFsIGZpZWxkcyBhcyBwb3NzaWJsZS4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YmVzdDxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaWF6aTxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9yPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIERvIHdl
IG1lbnRpb24gaW4gdGhlIGRyYWZ0IHRoYXQgemVyb2luZyBvdXQgaGFzIHRvIGhhcHBlbiBzb21l
aG93IGFuZCBsZWF2ZSB0aGUgbml0dHkgZ3JpdHR5IHRvIGZ1dHVyZSB3b3JrPzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCBsZWFzdCB0aGF0
4oCZcyBob3cgSSB1bmRlcnN0b29kIHRoZSBvcHRpb25zIHlvdSBsYWlkIG91dC4uLjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0mbmJzcDsgPG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzpjaHJp
c3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3RvcGhlci5k
ZWFybG92ZUBnbWFpbC5jb208L2E+IChpUGhvbmUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86Y2hyaXNAbW5lbW9zeW5l
LmRlbW9uLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVr
PC9hPiAoaG9tZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGJyPg0KPGJyPg0KLS0gJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkNocmlzdG9waGVyIERlYXJsb3ZlPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86Y2hyaXN0
b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0b3BoZXIuZGVh
cmxvdmVAZ21haWwuY29tPC9hPiAoaVBob25lKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOmNocmlzQG1uZW1vc3luZS5k
ZW1vbi5jby51ayIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzQG1uZW1vc3luZS5kZW1vbi5jby51azwv
YT4gKGhvbWUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiAyNyBBcHIgMjAxNiwgYXQgMjI6
NDYsIExvdHRlIFN0ZWVuYnJpbmsgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3R0ZS5zdGVlbmJyaW5r
QGZ1LWJlcmxpbi5kZSIgdGFyZ2V0PSJfYmxhbmsiPmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGlu
LmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkhpIGFsbCwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SeKAmW0gY3VycmVudGx5IHJldmlzaW5nIHRoZSBzZWN1cml0eSBjb25zaWRl
cmF0aW9ucyB3aXRoIHJlZ2FyZHMgdG8gdGhlIG1vdmUgZnJvbSByZWdlbmVyYXRpb24gdG8gZm9y
d2FyZGluZywgd2hpY2ggZGVwZW5kcyBvbiBhIGRlY2lzaW9uIGJlaW5nIG1hZGUgb24gaG93L3do
ZXJlIHdlIHdhbnQgdG8gbWVudGlvbiB0aGUgcG9zc2liaWxpdHkgb2YgemVyb2luZyBvdXQgVExW
cyB0byBjYWxjdWxhdGUgdGhlIElDVg0KIGZvciB0aGUgcmVzdCBvZiBhIG1lc3NhZ2XigJlzIGNv
bnRlbnRzIChzZWUgc2Vjb25kICogb2YgbXkgbGFzdCBlLW1haWwpLiBJ4oCZdmUgbm90IGZvdW5k
IGEgZGVjaXNpb24gb24gdGhpcyBpbiBvdGhlciB0aHJlYWQgKHBsZWFzZSBwYXJkb24gbWUgaWYg
SSBvdmVybG9va2VkIHNvbWV0aGluZyksIHNvIEnigJlsbCBidW1wIHRoaXMgdGhyZWFkIGFuZCBh
c2sgdGhlIFdHIGZvciBpdHMgb3BpbmlvbnMuIChhZ2FpbiwgcGVyc29uYWxseSwgdGhlIDJuZCBv
cHRpb24NCiBvdXRsaW5lZCBieSBDaHJpc3RvcGhlciBzZWVtcyBtb3JlIGFwcGVhbGluZyB0byBt
ZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkxvdHRlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5BbSAyMi4wNC4yMDE2IHVtIDE4OjI2IHNjaHJpZWIgTG90dGUgU3RlZW5icmluayAm
bHQ7PGEgaHJlZj0ibWFpbHRvOmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRlIiB0YXJnZXQ9
Il9ibGFuayI+bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4uZGU8L2E+Jmd0Ozo8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCwgPG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG8gc3VtbWFyaXplOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIEFPRFZ2MiBtZXNz
YWdlIFR5cGUgbnVtYmVycyBzaG91bGQgYmUgaW4gdGhlIEV4cGVyaW1lbnRhbCB0eXBlIHNwYWNl
IGFuZCB0aGUgQU9EVnYyIFRMViBUeXBlcyBzaG91bGQgYmUgbWVzc2FnZSB0eXBlLXNwZWNpZmlj
LiBUaGlzIGFsc28gbWVhbnMgY2hhbmdpbmcgdGhlIHRleHQgcmVnYXJkaW5nIElBTkEgYWN0aW9u
cyBhbmQgY2hhbmdpbmcgdGhlIHRleHQgcmVnYXJkaW5nIHdoYXQgdGhlIGV4cGVyaW1lbnQNCiBp
cyB0byBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mIOKAnHdlIHdhbnQgdG8gZ2F0aGVyIGV4
cGVyaWVuY2Ugb24gaG93IHRvIG1ha2UgZ2VuZXJpYyBtZXRyaWMgVExWcyBhbmQgSUNWcyB0aGF0
IHdvcmsgd2l0aCBjaGFuZ2luZyBtZXRyaWMgVFYgdmFsdWVzIGhhcHBlbiB3aXRoIHJlYWN0aXZl
IHByb3RvY29sc+KAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+KiB3ZeKAmXJlIHVuZGVjaWRlZCBvbiAodG8gcXVvdGUgQ2hyaXN0b3BoZXIpIHRo
ZSAmcXVvdDtoZXJlJ3MgYSBtZWNoYW5pc20gd2UgaGF2ZW4ndCByZWFsbHkgdGhvdWdodCB0aHJv
dWdoIGluIGRldGFpbCwgYnV0IGF0IGxlYXN0IHdlJ3ZlIGRlZmluZWQgb25lJnF1b3Q7LCBvciAm
cXVvdDt3ZSBrbm93IHRoZSBzb3J0IG9mIHRoaW5nIHdlIHdhbnQsIGFuZCB3ZSdsbCBkZXNjcmli
ZSBpdCwgYnV0IHJhdGhlciB0aGFuIHByb2R1Y2Ugc29tZXRoaW5nDQogbm90IHF1aXRlIHJpZ2h0
LCB3ZSdsbCBub3QgZ28gZnVydGhlcuKAnCBkZWNpc2lvbiBvbiB0ZW1wb3JhcmlseSBzZXR0aW5n
IHRoZSBtZXRyaWMgdmFsdWUgdG8gMCAoaS5lLiB0aGUgd2hvIGFuZCBob3cpLiAocGVyc29uYWxs
eSwgSSB0aGluayBJ4oCZZCBwcmVmZXIgdGhlIGxhdHRlciBhcHByb2FjaCwgYnV0IHRoYXTigJlz
IGFuIGVudGlyZWx5IGd1dCBmZWVsaW5nLWJhc2VkIHByZWZlcmVuY2UpPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRpZCBJIGNhdGNoIHRoYXQg
Y29ycmVjdGx5PyBJZiBzbywgSeKAmWxsIHB1dCB0b2dldGhlciBhbmQgc3VnZ2VzdCBzb21lIHRl
eHQgZm9yIHRoZSBmaXJzdCBwb2ludCBhcyBzb29uIGFzIEkgZ2V0IGhvbWUgYW5kIGluIGNhc2Ug
dGhlcmUgaGFzIGJlZW4gYSBkZWNpc2lvbiBvbiB0aGUgc2Vjb25kIGJ5IHRoZW4sIEnigJlsbCB0
cnkgdG8gdGFja2xlIHRoYXQgb25lIHRvby4gOik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCByZWdhcmRzLCBMb3R0ZTxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbSAy
Mi4wNC4yMDE2IHVtIDE2OjQxIHNjaHJpZWIgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgJmx0
OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPiZndDs6PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIG5vIHByb2Js
ZW0gd2l0aCB0aGF0LiBJIHdhcyB0cnlpbmcgdG8gbGF5IG91dCB0aGUgaXNzdWVzIHdpdGhvdXQg
bXVkZHlpbmcgdGhlIHdhdGVyIHdpdGggbXkgcHJlZmVyZW5jZS48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPi0tPC9iPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlv
ciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j
ZSBMYWJvcmF0b3JpZXM8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvYj48YnI+DQo8Yj5U
PC9iPjogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQiIHRh
cmdldD0iX2JsYW5rIj4mIzQzOzQ0ICgwKTEyNDUgMjQyMTk0PC9hPiAmbmJzcDt8ICZuYnNwOzxi
PkU6Jm5ic3A7PC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4N
Cjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hu
b2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4N
CjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj53
d3cuYmFlc3lzdGVtcy5jb20vYWk8L2E+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4N
ClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdpc3RlcmVkIE9mZmljZTog
U3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V
UyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDtKdXN0aW4gRGVhbiBb
PGEgaHJlZj0ibWFpbHRvOmJlYmVtYXN0ZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFp
bHRvOmJlYmVtYXN0ZXJAZ21haWwuY29tPC9hPl0mbmJzcDs8YnI+DQo8Yj5TZW50OjwvYj4mbmJz
cDsyMiBBcHJpbCAyMDE2IDE1OjM1PGJyPg0KPGI+VG86PC9iPiZuYnNwO0RlYXJsb3ZlLCBDaHJp
c3RvcGhlciAoVUspPGJyPg0KPGI+Q2M6PC9iPiZuYnNwO1Rob21hcyBIZWlkZSBDbGF1c2VuOyBN
b2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiZu
YnNwO1JlOiBbbWFuZXRdIE9uIEZvcndhcmRpbmctYW5kLXJlZ2VuZXJhdGlvbiAod2FzOiBSZTog
ZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djItMTMgcmV2aWV3IC0gYSBjb3VwbGUgb2YgYmlnIHRpY2tl
dCBJdGVtcyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj4qKiogV0FSTklORyAqKio8L2I+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PGVtPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9u
LCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L2VtPjxp
Pjxicj4NCjxlbT5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9u
IGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPC9lbT48YnI+DQo8ZW0+
Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyZuYnNwOzwvZW0+PHN0cm9uZz5SZWQgRmxhZ3M8L3N0
cm9uZz48ZW0+Jm5ic3A7dGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJl
Y2VpdmUsIGNsaWNrJm5ic3A7PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1z
LmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3Mu
cGRmIiB0YXJnZXQ9Il9ibGFuayI+aGVyZTwvYT4uPC9lbT48YnI+DQo8ZW0+SWYgeW91IGZlZWwg
dGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cmbmJzcDs8YSBocmVmPSJodHRw
Oi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGln
aHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIiB0
YXJnZXQ9Il9ibGFuayI+dGhpcyBwcm9jZXNzPC9hPi48L2VtPjwvaT48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZWFr
aW5nIGFzIHBhcnRpY2lwYW50Ljxicj4NCjxicj4NCkkga2luZCBvZiBsaWtlIHRoZSBpZGVhIG9m
IHVzaW5nIHRoZSBleHBlcmltZW50YWwgbWVzc2FnZSB0eXBlIHNwYWNlLiZuYnNwOyBXZSBvbmx5
IGhhdmUgYSBsaW1pdGVkIGFtb3VudCBvZiB0aGVzZSBtZXNzYWdlIHR5cGVzLiZuYnNwOyBUaGUg
VExWIGFzc2lnbm1lbnRzIGNvdWxkIGp1c3QgdXNlIHRoZSBtZXNzYWdlIHR5cGUgc3BlY2lmaWMg
c3BhY2UgYW5kIHRoZXJlIGlzbid0IGFuIGlzc3VlIHRoZXJlLiZuYnNwOyBJQU5BIHdvdWxkbid0
IGFzc2lnbiBhIG51bWJlciBidXQNCiBJIGRvbid0IHNlZSB3aHkgdGhlIGRvY3VtZW50IGNvdWxk
bid0IHNwZWNpZnkgdGhlIGV4cGVyaW1lbnRhbCBudW1iZXJzIGl0IHdhcyBnb2luZyB0byB1c2Ug
c28gb3RoZXIgZnV0dXJlIG5lYXIgdGVybSBleHBlcmllbnRpYWwgcHJvdG9jb2xzIGNvdWxkIGRv
IHRoZSBzYW1lIGFuZCBnZW5lcmFsbHkgYXZvaWQgY29uZmxpY3QuJm5ic3A7IElmIHRoZSBleHBl
cmltZW50IGlzIHN1Y2Nlc3NmdWwgSUFOQSBhc3NpZ25tZW50cyBjb3VsZCBiZSBtYWRlLiZuYnNw
OyBGdW5jdGlvbmFsbHkNCiBubyByZWFsIGRpZmZlcmVuY2Ugd2l0aCBwcm90ZWN0aW9ucyB2cyBs
b25nIHRlcm0gdXNhZ2Ugb2YgbGltaXRlZCBzcGFjZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3Rp
bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk9uIEZyaSwgQXByIDIyLCAyMDE2IGF0IDk6MzUgQU0sIERlYXJsb3ZlLCBD
aHJpc3RvcGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lz
dGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwv
YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+VGhlcmUncyByYXRoZXIgYSBjb250cmFkaWN0aW9uIGJldHdlZW4gdGhlIGNvbmNl
cHRzIG9mIGEgZGVmaW5pdGlvbiBvZiBhIHByb3RvY29sLCBldmVuIEV4cGVyaW1lbnRhbCwgYW5k
IGV4cGVyaW1lbnRhbCBzcGFjZSwgd2hpY2ggdXN1YWxseSBhc3N1bWVzIHRoYXQgdGhlIHVzZXIg
Y2FuIGRvIHdoYXQgaGUgb3Igc2hlIGxpa2VzIGluIGl0Ljxicj4NCjxicj4NCkJ1dCBjaGV3aW5n
IHVwIG1lc3NhZ2VzIHR5cGVzIChob3cgbWFueSwgMz8pIG9mIHdoaWNoIHRoZXJlIGFyZSByZWxh
dGl2ZWx5IGZldyBmb3IgZXhwZXJpbWVudGFsIGlzIGxvbmcgdGVybSBhIHByb2JsZW0sIGFsdGhv
dWdoIHNob3J0IHRlcm0gbm90Ljxicj4NCjxicj4NClRMViBzcGFjZSBpcyBlYXNpZXIgaW4gdHdv
IHJlZ2FyZHMuIEl0J3MgYmlnZ2VyICh0aG91Z2ggdGhlIHByaW1lIHJlYWwgZXN0YXRlIG9mIHR5
cGUgZXh0ZW5zaW9uIHplcm8gaXNuJ3QpIGFuZCBjYW4gaGF2ZSBtZXNzYWdlIHR5cGUgc3BlY2lm
aWMgVExWcy48YnI+DQo8YnI+DQpTbyBUTFZTIGNhbiBhY3R1YWxseSBiZSBpbnZpc2libGUsIGlm
IHRoYXQgb3B0aW9uIGlzIGNob3Nlbi4gRm9yIG1lc3NhZ2VzIHNvbWV0aGluZyBoYXMgdG8gZ2l2
ZS4gTGVhc3QgYmFkIG9wdGlvbiBpcyBhZ2FpbiBvbmUgb2YgdGhvc2Ugd2Ugc2hvdWxkIGRpc2N1
c3MsIGJ1dCB0aW1lIC4uLjxicj4NCjxicj4NCihUbyBiZSBwcmVjaXNlLCBtZXNzYWdlcyB0eXBl
cyBmcm9tIDIyNCBhcmUgZGVmaW5lZCBpbiBSRkMgNTQ0NCBhcyAmcXVvdDsgRXhwZXJpbWVudGFs
IFVzZSZxdW90Oywgb2Ygd2hpY2ggQkNQIDI2IHNheXMgJnF1b3Q7U2ltaWxhciB0byBwcml2YXRl
IG9yIGxvY2FsIHVzZSBvbmx5LCB3aXRoIHRoZSZuYnNwOyBwdXJwb3NlIGJlaW5nIHRvIGZhY2ls
aXRhdGUgZXhwZXJpbWVudGF0aW9uLiZxdW90OyBUaGUgYWx0ZXJuYXRpdmUgMC0yMjMgc3BhY2Ug
aXMgRXhwZXJ0IFJldmlldy4gSUFOQSBzdGlsbA0KIHRoaW5rcyB0aGUgZXhwZXJ0cyBhcmUgSm9l
IE1hY2tlciBhbmQgdGhlIHJlY3VzZWQgU3RhbiBSYXRsaWZmLiBCdXQgdGhhdCdzIGEgc29sdWJs
ZSBuaXQuKTxicj4NCjxicj4NCi0tPGJyPg0KQ2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5p
b3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu
Y2UgTGFib3JhdG9yaWVzPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+DQpUOiAmbmJz
cDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5NCIgdGFyZ2V0PSJfYmxh
bmsiPiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8L2E+Jm5ic3A7Jm5ic3A7fCAmbmJzcDtFOiZuYnNw
OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjxicj4NCkJBRSBT
eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywg
R3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0
dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj53d3cuYmFlc3lzdGVt
cy5jb20vYWk8L2E+PGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRl
ZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8YnI+
DQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3Vy
cmV5LCBHVTIgN1lQPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08
YnI+DQpGcm9tOiBUaG9tYXMgSGVpZGUgQ2xhdXNlbiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpp
ZXRmQHRob21hc2NsYXVzZW4ub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkB0aG9tYXNjbGF1c2Vu
Lm9yZzwvYT5dPGJyPg0KU2VudDogMjIgQXByaWwgMjAxNiAxNDoyMTxicj4NClRvOiBEZWFybG92
ZSwgQ2hyaXN0b3BoZXIgKFVLKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYzogTG90dGUgU3RlZW5icmluazsgTW9iaWxl
IEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3Q8YnI+DQpTdWJqZWN0OiBSZTogW21hbmV0XSBP
biBGb3J3YXJkaW5nLWFuZC1yZWdlbmVyYXRpb24gKHdhczogUmU6IGRyYWZ0LWlldGYtbWFuZXQt
YW9kdnYyLTEzIHJldmlldyAtIGEgY291cGxlIG9mIGJpZyB0aWNrZXQgSXRlbXMpPGJyPg0KPGJy
Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24s
IGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuPGJy
Pg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlu
a3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljxicj4NCkZvbGxvdyB0aGUgJ1JlcG9y
dCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMg
b24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuPGJyPg0KLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQo8
YnI+DQomZ3Q7IE9uIDIyIGF2ci4gMjAxNiwgYXQgMTU6MDUsIERlYXJsb3ZlLCBDaHJpc3RvcGhl
ciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20i
IHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7IHdy
b3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IE9uY2UgeW91J3JlIGVudGlyZWx5IGluIEFPRFYyJ3Mg
b3duIHNwYWNlLCBhbmQgQU9EVnYyIGlzIGV4cGVyaW1lbnRhbCAod29ya2luZyBhc3N1bXB0aW9u
IGZvciB0aGlzIGRpc2N1c3Npb24pIHlvdSBoYXZlIG1vcmUgbGliZXJ0eS48YnI+DQomZ3Q7PGJy
Pg0KPGJyPg0KWWVwLjxicj4NCjxicj4NClRha2VuIHNvbWV3aGF0IGJ5IHN1cnByaXNlIGJvdGgg
YnkgdGhlIHN1ZGRlbiAmcXVvdDtydXNoJnF1b3Q7IGFuZCB0aGUgZXhwZXJpbWVudGFsIG1hdHVy
aXR5IGxldmVsLCBJIGFtIHdvbmRlcmluZyAoYW5kIGhhdmVuJ3QgdGhvdWdodCB0aHJvdWdoKSBh
Ym91dCBleHBlcmltZW50YWwgc3BhY2UgdnMgbm9uLWV4cGVyaW1lbnRhbCAoZm9yIG1lc3NhZ2Ug
dHlwZXMsIGFuZCBjb25zZXF1ZW50bHkgZm9yIG1lc3NhZ2UgdHlwZSBzcGVjaWZpYyBUTFYgdHlw
ZXMpLjxicj4NCjxicj4NCkkgdGhpbmsgdGhhdCBpZiB0aGUgQU9EVnYyIGV4cGVyaW1lbnQgc3Bl
Y2lmaWVzIHRoZSB1c2Ugb2YgTWVzc2FnZSB0eXBlcyBmcm9tIHRoZSBFeHBlcmltZW50YWwgbWVz
c2FnZSB0eXBlIHNwYWNlIHdpdGhvdXQgbWFraW5nIGFjdHVhbCByZWdpc3RyYXRpb25zIGluIHRo
ZSBJQU5BIHJlZ2lzdHJ5LCBBTkQgdGhlIHVzZSBvZiB0eXBlIHNwZWNpZmljIFRMViB0eXBlcywg
dGhpcyBiZWNvbWVzIGEgbm9uLWlzc3VlIGVudGlyZWx5IChieSBkZXNpZ24sDQogdGhpcyBpcyBw
cmVjaXNlbHkgd2hhdCB0aGF0IGV4cGVyaW1lbnRhbCBzcGFjZSBpcyBmb3IpPGJyPg0KPGJyPg0K
V2hlcmVhcywgYXMgeW91IHBvaW50IG91dCwgdGhlIGFsdGVybmF0aXZlIGlzIGEgJnF1b3Q7Y2Fu
IG9wZW4gLSB3b3JtcyBldmVyeXdoZXJlJnF1b3Q7IHNpdHVhdGlvbiB0aGF0IEkgdGhpbmsgdGlt
ZSBpcyB0b28gc2hvcnQgdG8gc29sdmU/PGJyPg0KPGJyPg0KVGhvbWFzPGJyPg0KPGJyPg0KPGJy
Pg0KJmd0OyBUaGVuIHlvdSBjb3VsZCB0cnkgc3BlY2lmeWluZyBpdC4gQnV0IHdpdGggYSB2ZXJ5
IGdvb2QgY2hhbmNlIG9mIHByb2R1Y2luZyBzb21ldGhpbmcgeW91IGxhdGVyIGRlY2lkZSB5b3Ug
c2hvdWxkIGhhdmUgZG9uZSBkaWZmZXJlbnRseS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGhvbmVz
dGx5IGRvbid0IGtub3cgd2hpY2ggd291bGQgZ28gZG93biBiZXR0ZXIgKG9yIGxlc3MgYmFkbHkp
IC0gJnF1b3Q7aGVyZSdzIGEgbWVjaGFuaXNtIHdlIGhhdmVuJ3QgcmVhbGx5IHRob3VnaHQgdGhy
b3VnaCBpbiBkZXRhaWwsIGJ1dCBhdCBsZWFzdCB3ZSd2ZSBkZWZpbmVkIG9uZSZxdW90Oywgb3Ig
JnF1b3Q7d2Uga25vdyB0aGUgc29ydCBvZiB0aGluZyB3ZSB3YW50LCBhbmQgd2UnbGwgZGVzY3Jp
YmUgaXQsIGJ1dCByYXRoZXIgdGhhbiBwcm9kdWNlIHNvbWV0aGluZw0KIG5vdCBxdWl0ZSByaWdo
dCwgd2UnbGwgbm90IGdvIGZ1cnRoZXImcXVvdDsuPGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+
DQomZ3Q7IENocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KJmd0OyBTZW5pb3IgUHJpbmNpcGFsIEVu
Z2luZWVyPGJyPg0KJmd0OyBCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0
b3JpZXM8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0Ozxicj4NCiZndDsgVDom
bmJzcDsmbmJzcDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5NCIgdGFy
Z2V0PSJfYmxhbmsiPiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8L2E+Jm5ic3A7IHwmbmJzcDsgRTom
bmJzcDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdl
dD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQomZ3Q7PGJy
Pg0KJmd0OyBCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNo
bm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+
DQomZ3Q7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0
PSJfYmxhbmsiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvYT48YnI+DQomZ3Q7IEJBRSBTeXN0ZW1z
IEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQomZ3Q7IFJlZ2lzdGVyZWQgaW4gRW5n
bGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8YnI+DQomZ3Q7IFJlZ2lzdGVyZWQgT2ZmaWNl
OiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8YnI+DQom
Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQom
Z3Q7IEZyb206IExvdHRlIFN0ZWVuYnJpbmsgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bG90dGUu
c3RlZW5icmlua0BmdS1iZXJsaW4uZGUiIHRhcmdldD0iX2JsYW5rIj5sb3R0ZS5zdGVlbmJyaW5r
QGZ1LWJlcmxpbi5kZTwvYT5dPGJyPg0KJmd0OyBTZW50OiAyMiBBcHJpbCAyMDE2IDEzOjU5PGJy
Pg0KJmd0OyBUbzogTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7
IENjOiBIZW5uaW5nIFJvZ2dlOyBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4NCiZndDsg
U3ViamVjdDogUmU6IFttYW5ldF0gT24gRm9yd2FyZGluZy1hbmQtcmVnZW5lcmF0aW9uICh3YXM6
IFJlOiBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBhIGNvdXBsZSBvZiBiaWcg
dGlja2V0IEl0ZW1zKTxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0h
IFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVz
IGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBw
YXJ0bmVyIG9yIGZyb20gdGhlIGludGVybmV0Ljxicj4NCiZndDsgQ29uc2lkZXIgY2FyZWZ1bGx5
IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1l
bnRzIG9yIHJlcGx5Ljxicj4NCiZndDsgRm9sbG93IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1h
aWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3Vz
cGljaW91cyBlbWFpbCBtZXNzYWdlcy48YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0Ozxicj4NCiZndDsgSGVs
bG8gQ2hyaXN0b3BoZXIsPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IEFtIDIyLjA0LjIwMTYgdW0g
MTE6NTcgc2NocmllYiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFp
bHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMu
ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0Ozo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7IEp1c3QgYmUgY2FyZWZ1bCB0byBub3RlIHRoYXQgdGhpcyBjb25jZXB0IGlzIGFzIGN1cnJl
bnRseSBiZWluZyBkaXNjdXNzZWQgKGEpIHNwZWNpZmljIHRvIEFPRFZ2MiwgYW5kIChiKSBub3Qg
YW4gYXBwbGljYXRpb24gb2YgNzE4Miwgd2hpY2ggaGFzIG5vIGtub3dsZWRnZSBvZiBzcGVjaWFs
IFRMVnMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGlzIGlzIHNvbWV0aGluZyB3ZSdk
IHdhbnQgdG8gZ2V0IHJpZ2h0LCBhbmQgbmVlZCB0byBnZXQgcmlnaHQgaWYgaW4gYW55IHNwYWNl
IG5vdCBzcGVjaWZpYyB0byBBRE9EVnYyLCBiZWNhdXNlIGdldHRpbmcgaXQgd3JvbmcgcHJvZHVj
ZXMgZnV0dXJlIHByb2JsZW1zLjxicj4NCiZndDs8YnI+DQomZ3Q7IE1ha2VzIHNlbnNlLjxicj4N
CiZndDs8YnI+DQomZ3Q7Jmd0OyBJIGNhbiBzZWUgc29tZSBwb3NzaWJsZSBhcHByb2FjaGVzLCBu
b25lIGlzIGlkZWFsIGFuZCB3ZSdyZSByYXRoZXIgb3V0PGJyPg0KJmd0OyZndDsgb2YgdGltZSB0
byBzcGVjaWZ5LiBCdXQgdGhpcyBpcyBleHBlcmltZW50YWwsIHNvIEkgdGhpbmsgd2UgbWlnaHQg
YmU8YnI+DQomZ3Q7Jmd0OyBhYmxlIHRvIGluZGljYXRlIHRoZSBzaGFwZSBvZiB0aGUgc29sdXRp
b24gd2l0aG91dCBzcGVjaWZ5aW5nIGl0LDxicj4NCiZndDsmZ3Q7IHdoaWNoIHdvdWxkIGJlIGEg
ZGlmZmVyZW50IFJGQywgdW5kZXIgYSBiaXQgbGVzcyB0aW1lIHByZXNzdXJlLjxicj4NCiZndDsm
Z3Q7IChFeHRlbnNpb25zIHRvIGV4aXN0aW5nIHByb3RvY29scyBsaWtlIDcxODIgd291bGQgbmF0
dXJhbGx5IGJlIGluPGJyPg0KJmd0OyZndDsgc2NvcGUgcmVjaGFydGVyZWQgSSB0aGluay4pPGJy
Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUbyBpbmRpY2F0ZSB0aGUgcmFuZ2UgdGhhdCdzIG9w
ZW4sIGhlcmUgYXJlIHR3byBwb3NzaWJsZSBpZGVhcywgb25lIG9mIHdoaWNoIGhhcyBhbiBpbXBh
Y3Qgbm93LCBzbyBuZWVkcyB0byBiZSBhZ3JlZWQuIE5vdGUgdGhhdCBJJ20gbm90IHN1Z2dlc3Rp
bmcgKGluIGZhY3QgcXVpdGUgdGhlIG9wcG9zaXRlKSBkZWZpbmluZyBhbiBleHRlbnNpb24gdG8g
NzE4MiBoZXJlLCByYXRoZXIgZW5hYmxpbmcgc3VjaCBhbiBleHRlbnNpb24sIGlmIHdyaXR0ZW4s
DQogdG8gJnF1b3Q7ZG8gdGhlIHJpZ2h0IHRoaW5nJnF1b3Q7Ljxicj4NCiZndDsmZ3Q7IC0gV2Ug
aGF2ZSBhbiBleHRlbnNpb24gdG8gNzE4MiB0aGF0IHNheXMgJnF1b3Q7emVybyBvdXQgYWxsIHZh
bHVlIG9jdGV0cyBpbiBwcm90b2NvbCBzcGVjaWZpYyBUTFZzLiBUaGF0IHJlcXVpcmVzIG5vdyBw
dXR0aW5nIHRoZSBBT0RWdjIgbWV0cmljIFRMViBpbiB0aGF0IHNwYWNlLjxicj4NCiZndDs8YnI+
DQomZ3Q7IEp1c3QgdG8gbWFrZSBzdXJlIHRoYXQgSSB1bmRlcnN0b29kIHlvdSBjb3JyZWN0bHni
gJMg4oCcdGhhdCBzcGFjZeKAnSBtZWFuaW5nIG1ha2luZyB0aGUgQU9EVnYyIG1ldHJpYyBUTFYg
cHJvdG9jb2wgc3BlY2lmaWM/IChCeSDigJx0aGUgYW9kdnYyIG1ldHJpYyB0bHbigJ0gSeKAmW0g
cmVmZXJyaW5nIHRvIHRoZSBnZW5lcmljIFRMViB3ZeKAmXZlIGJlZW4gdGFsa2luZyBhYm91dCBv
biB0aGlzIGxpc3QgZWFybGllciB0aGlzIHdlZWspLjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyAt
IFdlIGhhdmUgYW4gZXh0ZW5zaW9uIHRvIDcxODIgdGhhdCBhZGRzIGV4dHJhIG1hdGVyaWFsIHRv
IHRoZSB2YWx1ZSBmaWVsZCB0aGF0IGluZGljYXRlcyAoVEJEIGhvdywgYnkgcG9zaXRpb24gd2l0
aCBzYW5pdHkgY2hlY2sgdGhhdCB0aGlzIGlzIFRMViB2YWx1ZSBwZXJoYXBzPykgd2hpY2ggb2N0
ZXRzIGFyZSB0byBiZSB6ZXJvZWQgb3V0IGJlZm9yZSB0aGUgSUNWIGlzIGNhbGN1bGF0ZWQuPGJy
Pg0KJmd0Ozxicj4NCiZndDsgVGhlIHdheSBJIHVuZGVyc3RhbmQgdGhhdCBhcHByb2FjaCwgaXQg
d291bGRu4oCZdCB3YXJyYW50IGFueSBhY3Rpb24gZnJvbSBBT0RWdjIgYmVzaWRlcyBzYXlpbmcg
4oCcaWYgeW91IGNhbGN1bGF0ZSB0aGUgSUNWLCBzZXQgdGhlIE1ldHJpYyB2YWx1ZSB0byB6ZXJv
4oCdIChsZWF2aW5nIHRoZSBuaXR0eSBncml0dHkgb2YgaG93IHRoaXMgd291bGQgYmUgZG9uZSBp
biBkZXRhaWwgdG8gZnV0dXJlIHdvcmsp4oCmIElzIHRoYXQgY29ycmVjdD88YnI+DQomZ3Q7PGJy
Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBXZSBkbyBub3QgaGF2ZSB0aGUgdGltZSB0byBzcGVj
aWZ5IHRoaXMgaW4gYW4gYWNjZXB0YWJsZSBtYW5uZXIgd2l0aGluIHR3byB3ZWVrcyB0aG91Z2gu
IEJ1dCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGNvdWxkIHNheSBzb21ldGhp
bmcgYWxvbmcgdGhlIGxpbmVzIG9mICZxdW90O3RoaXMgZW5hYmxlcyB0aGUgdXNlIG9mIGFuIElD
ViBkZWZpbmVkIHRvIHplcm8gb3V0IHRoZXNlIG9jdGV0c+KAnC48YnI+DQomZ3Q7PGJyPg0KJmd0
OyBPa2F5LiA6KTxicj4NCiZndDs8YnI+DQomZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7IExv
dHRlPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLS08YnI+DQomZ3Q7Jmd0
OyBDaHJpc3RvcGhlciBEZWFybG92ZTxicj4NCiZndDsmZ3Q7IFNlbmlvciBQcmluY2lwYWwgRW5n
aW5lZXI8YnI+DQomZ3Q7Jmd0OyBCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJv
cmF0b3JpZXM8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgX19fXzxi
cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVDombmJzcDsgPGEgaHJlZj0idGVsOiUyQjQ0JTIw
JTI4MCUyOTEyNDUlMjAyNDIxOTQiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzQ0ICgwKTEyNDUgMjQy
MTk0PC9hPiZuYnNwOyB8Jm5ic3A7IEU6Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJs
b3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lz
dGVtcy5jb208L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBCQUUgU3lzdGVtcyBBcHBs
aWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRv
dywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQomZ3Q7Jmd0OyZuYnNwOzxhIGhyZWY9
Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj53d3cuYmFlc3lz
dGVtcy5jb20vYWk8L2E+PGJyPg0KJmd0OyZndDsgQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxp
Z2VuY2UgTGltaXRlZCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXM8YnI+DQomZ3Q7
Jmd0OyBObzogMDEzMzc0NTEgUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJr
LCBHdWlsZGZvcmQsPGJyPg0KJmd0OyZndDsgU3VycmV5LCBHVTIgN1lQPGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7IEZy
b206IG1hbmV0IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj5tYW5ldC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9m
IExvdHRlPGJyPg0KJmd0OyZndDsgU3RlZW5icmluazxicj4NCiZndDsmZ3Q7IFNlbnQ6IDIyIEFw
cmlsIDIwMTYgMTA6Mjg8YnI+DQomZ3Q7Jmd0OyBUbzogSGVubmluZyBSb2dnZTxicj4NCiZndDsm
Z3Q7IENjOiBNb2JpbGUgQWQgSG9jIE5ldHdvcmtzIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7
IFN1YmplY3Q6IFJlOiBbbWFuZXRdIE9uIEZvcndhcmRpbmctYW5kLXJlZ2VuZXJhdGlvbiAod2Fz
OiBSZTo8YnI+DQomZ3Q7Jmd0OyBkcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0xMyByZXZpZXcgLSBh
IGNvdXBsZSBvZiBiaWcgdGlja2V0IEl0ZW1zKTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g
VGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVp
dGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuPGJyPg0K
Jmd0OyZndDsgQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBh
bnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljxicj4NCiZndDsmZ3Q7IEZv
bGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZv
ciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuPGJy
Pg0KJmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICoqKiBXQVJOSU5HICoqKjxi
cj4NCiZndDsmZ3Q7IEVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZy
b20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyBIaSBIZW5uaW5nLDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7
IEFtIDIyLjA0LjIwMTYgdW0gMTE6MDggc2NocmllYiBIZW5uaW5nIFJvZ2dlICZsdDs8YSBocmVm
PSJtYWlsdG86aHJvZ2dlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmhyb2dnZUBnbWFpbC5j
b208L2E+Jmd0Ozo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT24gRnJpLCBB
cHIgMjIsIDIwMTYgYXQgMTE6MDUgQU0sIExvdHRlIFN0ZWVuYnJpbms8YnI+DQomZ3Q7Jmd0OyZn
dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZSIgdGFy
Z2V0PSJfYmxhbmsiPmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRlPC9hPiZndDsgd3JvdGU6
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBIaSBUaG9tYXMsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBD
YW4gaXQ/ISBJaXJjLCB0aGUgcmVhc29uIHdoeSB3ZSBhZG9wdGVkIHRoZSDigJxyZWdlbmVyYXRp
b27igJ0gbGFuZ3VhZ2U8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGluIHRoZSBmaXJzdCBwbGFjZSBp
cyB0aGF0IHdl4oCZdmUgYmVlbiB0b2xkIHRoYXQgd2hlbmV2ZXIgb25lIGJpdCBpbjxicj4NCiZn
dDsmZ3Q7Jmd0OyZndDsgdGhlIG1lc3NhZ2UgKGFwYXJ0IGZyb20gaXRzIGhlYWRlcikgaXMgY2hh
bmdlZCwgdGhlIGVudGlyZSB0aGluZyBoYXMgdG8gYmUgcmVnZW5lcmF0ZWQuPGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyBJ4oCZbSBzdGFydGluZyB0byBnZXQgdGhlIGZlZWxpbmcgd2XigJl2ZSBqdXN0
IGJlZW4gbWlzdW5kZXJzdGFuZGluZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgZWFjaCBvdGhlciBm
b3IgbW9yZSB0aGFuIGEgeWVhci4gOiggQW55d2F5LCBpdCBzZWVtcyBsaWtlIHdl4oCZcmU8YnI+
DQomZ3Q7Jmd0OyZndDsmZ3Q7IGdldHRpbmcgY2xvc2Ugbm93LCBzbyB5YXkuPGJyPg0KJmd0OyZn
dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZxdW90O01vZGlmeWluZyZxdW90OyB0aGUgYmluYXJ5
IG1lc3NhZ2UgaW5zdGVhZCBvZiBwYXJzaW5nIGFuZCBnZW5lcmF0aW5nIGE8YnI+DQomZ3Q7Jmd0
OyZndDsgbmV3IG9uZSB3aWxsIGJlIGRpZmZpY3VsdCBhcyBzb29uIHNvbWVvbmUgd3JpdGVzIGFu
IGV4dGVuc2lvbiB0bzxicj4NCiZndDsmZ3Q7Jmd0OyBBT0RWdjIgdGhhdCBhZGRzIG1vcmUgVExW
cyB0byB0aGUgbWVzc2FnZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IETigJlvaCwgcmln
aHQuIFllYWgsIGlmIEkgcmVtZW1iZXIgaXQgY29ycmVjdGx5LCB0aGF04oCZcyB3aGF0IHlvdSBl
eHBsYWluZWQgdG8gbWUgd2hlbiBJIGdvdCBjb25mdXNlZCBhYm91dCB0aGUgdG9waWMgbGFzdCBz
cHJpbmfigKYgQnV04oCTIGV2ZW4gaWYgYSBtZXNzYWdlIGNvbnRhaW5zIFRMVnMgdGhhdCB0aGUg
QU9EVnYyIGltcGxlbWVudGF0aW9uIGhhbmRsaW5nIGl0IGRvZXNu4oCZdCB1bmRlcnN0YW5kLCBp
dCB3aWxsIHN0aWxsIGJlIGFibGUgdG8gcmVjb2duaXplDQogdGhlIE1ldHJpYyBUTFYsIHJpZ2h0
PyBJc27igJl0IHRoYXQgdGhlIG5pZnR5IHRoaW5nIGFib3V0IFJGQzU0NDQ/IFNvLCB3aGlsZSB3
ZSByZWFsbHkgc2hvdWxkbuKAmXQgd3JpdGUg4oCcYmVmb3JlIGNhbGN1bGF0aW5nIHRoZSBJQ1Ys
IHNldCB0aGUgbi10aCA0IG9jdGV0cyB0byAw4oCdLCB3ZSBtaWdodCBzYXkg4oCcaWRlbnRpZnkg
dGhlIG9jdGV0cyB0aGF0IG1ha2UgdXAgdGhlIG1ldHJpYyB2YWx1ZSBhbmQgc2V0IHRob3NlIHRv
IDDigJ0/PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0
OyZndDsgTG90dGU8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBIZW5uaW5nIFJvZ2dl
PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IG1hbmV0IG1haWxpbmcgbGlzdDxicj4N
CiZndDsmZ3Q7Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmbmJzcDs8YSBocmVmPSJodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48YnI+DQomZ3Q7
Jmd0OyAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKjxicj4NCiZndDsmZ3Q7IFRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2ht
ZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZDxicj4NCiZndDsmZ3Q7IHJlY2lw
aWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu
ZGVkPGJyPg0KJmd0OyZndDsgcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5
c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPg0KJmd0OyZndDsgWW91IHNob3VsZCBub3Qg
Y29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcjxicj4NCiZn
dDsmZ3Q7IGRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uPGJyPg0K
Jmd0OyZndDsgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKio8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbWFuZXQgbWFpbGluZyBs
aXN0PGJyPg0KJmd0OyZuYnNwOzxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCiZndDsmbmJzcDs8YSBocmVmPSJodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48YnI+DQo8YnI+
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1h
bmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm
PSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9yZzwv
YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21h
bmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFu
ZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBo
cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9
Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4N
CjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0QGll
dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL21hbmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlz
dDxicj4NCjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1h
bmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxp
c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5t
YW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5tYW5ldCBtYWlsaW5n
IGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0
IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t
YW5ldDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8
YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxh
IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdl
dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9h
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B230CGLKXM0002VGREEN_--


From nobody Thu Apr 28 07:53: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 A085812D641 for ; Thu, 28 Apr 2016 07:53:34 -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 DI21A_7zUvWb for ; Thu, 28 Apr 2016 07:53:30 -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 DA43212D61A for ; Thu, 28 Apr 2016 07:53:29 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id j11so98461882lfb.1 for ; Thu, 28 Apr 2016 07:53:29 -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=LpnLMxgThJEDofItNJEHpa/oeuLW+EfwQwww9b9658g=; b=s3lo58ZvHEw72AYtphJ8McNKPz+3q4cBDmoqLdamcILhi4YroFk8Wygf7IJwmgjOpF cnQaDhOqAZ8OgeWqdSbkKHyf45ndna1SsFYRQa90Af9v5jjXDte2hu7cdhlFaGAPJdBo 3Dy9xn4m/vkX7hjZW+DB4gL0NswE+kygq/PCh2J6dHcQSC5b8suorihY5RZil/8UQi2D ylLndb9KpxPqbDh0q/axLXsGXepaznaFj3w29N3guGUYjHVZuAGxB5oLcSg9mpQXj6Gc YZ69+CuU9470jJtJwxhQxdFpvYhXfiRhwhYgA794sxYE+N1oQ2hzUEXCf72txnM5VJOK p5oA==
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=LpnLMxgThJEDofItNJEHpa/oeuLW+EfwQwww9b9658g=; b=bVBCZth7JShNbK6a6nEsuaKBUdvzKlfIWUO/Yo8O2ER5O6mtdqNnnd4DwV2aX+K28b /iXvYSVs27mpnCTYv4x/4EJcqRDMVg/pq5ONiAW4jjY+GpyRWGx8IEnHYYrh1lvW7+dv PY0chvlvQfj5FGCLKQPR8kHECdQFufvCZFbAcVwhgcq82c0HaYwHtGz3ZjgZ7LgObbEu wjeLcTyN66qYo1BblQfQ/IoGbCjuMV+mZ4gN7hnPyUV0hNvQjPhMFrF5e4qbS2sHLBuS 8zIqmvOx6UGhG4hhSiTK/0nmv0hv294tx3wesrTqJqfaXbiJn8pAh18FxCAqaK3S0e6B b7hQ==
X-Gm-Message-State: AOPr4FVGKgstyQz/ZNQCWdUsD/GIgi0HZfeb9CLTFLQNLoSFINphy9bos01S/hwCQAXV1qH1NePfnNdzLa7fPg==
MIME-Version: 1.0
X-Received: by 10.112.198.6 with SMTP id iy6mr5256919lbc.43.1461855207937; Thu, 28 Apr 2016 07:53:27 -0700 (PDT)
Sender: yi.jiazi@gmail.com
Received: by 10.114.77.4 with HTTP; Thu, 28 Apr 2016 07:53:27 -0700 (PDT)
Date: Thu, 28 Apr 2016 16:53:27 +0200
X-Google-Sender-Auth: _6iLK82mY1QNRvCpWiSvt7A4URo
Message-ID: 
From: Jiazi YI 
To: manet 
Content-Type: multipart/alternative; boundary=001a11c2b75a61dc5905318cb083
Archived-At: 
Subject: [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: Thu, 28 Apr 2016 14:53:34 -0000

--001a11c2b75a61dc5905318cb083
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

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 and
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 RREQ
is inevitable, the necessity of multicast RREP/RERR is not clear. It bring
issues related to control message overhead and security.

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.

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.  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.

  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..

   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.

*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.

*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).


>    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 can
participate in routing operations.


>    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?

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.


> 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.

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

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.



>    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.

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.

*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.


*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 example:

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 differently
for RREQ/RREP? Need to check the consistency in the whole draft.

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 call
it out in the applicability statement.

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

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 function=
 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.


>    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 in
user space (which is true in most cases), this normally means context
switch. This is inevitable for reactive protocols, but doing so per packet
seems to be expensive.


*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
  - the tradeoff of using multicast RREP and RERR need to be carefully
considered.
  - the tradeoff of using ValidityTime needs to be carefully considered

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 the
link is actually broken. 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.

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?

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 the
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

--001a11c2b75a61dc5905318cb083
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,=C2=A0

Here is my prelimi=
nary 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 sec=
tions can be reorganized a bit to improve the readability. For example, wit=
h the current structure, the readers need to reach section 6.6 (Route disco=
very) before they can 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 informatio=
n must be provided:
=C2=A0 =C2=A0 =C2=A0 =C2=A0- The motivation o=
f this experimental document=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0- T=
he experiments 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. Some=
times 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 implementation, or the implementation experience is not report=
ed to the author team?

4. The specification uses l=
ots of multicast messages. While multicast RREQ is inevitable, the necessit=
y of multicast RREP/RERR is not clear. It bring issues related to control m=
essage overhead and security.=C2=A0

5. The interac=
tion with RIB: The=C2=A0route state maintenance=C2=A0requires "Loca=
lRoute.State MUST be checked before IP packet forwarding and before any ope=
ration based on LocalRoute.State.". Having such check for each dat=
a packet might be heavy load for the system if the routing daemon runs in u=
serspace (because of context switch). While interaction with RIB is inevita=
ble, we want to reduce it as much as possible -- per data packet operation =
is too much.=C2=A0

6. There are too many "MAY=
" and "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 differen=
t threads, so I won't repeat them here. I think the current regeneratio=
n-based approach is complex to secure and hard for future extensions.=C2=A0=
 I haven't checked the security considerations section in detail yet. I=
t's important to get the big direction right first.=C2=A0

Please check the details inline:


=C2=A0 =
=C2=A0The Ad hoc On-Demand Distance Vector Version 2 (AODVv2) protocol
=
=C2=A0 =C2=A0enables 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 kin=
d of feature is supported. I would avoid using it.=C2=A0
=C2=A0   AODVv2 is an Experimental protocol.
=C2=A0...
=C2=A0
I think much more information is requ=
ired here:

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

2) The motivation and exper=
iments to be conducted need to be elaborated. It's even necessary to ha=
ve a separate section/subsection for it. Some experiment points that come t=
o my mind without much thinking: support of multiple interfaces, support of=
 gateways, use of different metrics, the security model, etc..
=C2=A0 =C2=A0The basic operations of the AODV=
v2 protocol are route discovery and
=C2=A0 =C2=A0route maintenance...

It's necessary to give an overview =
of the basic functioning of the protocol, rather than simply saying "u=
se RREQ/RREP to carry information and build routes". Because after thi=
s, the draft jumps directly into the protocol details.=C2=A0
It&#=
39;s extremely important for the readers who are not familiar with reactive=
 protocol.=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 RERR_Gen is used.=C2=
=A0
Good to be consistent.=C2=A0

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

need to explain wh=
at's the address for exactly, rather than giving a pointer to a big sec=
tion.=C2=A0

section 3, applicability statement<=
/b>

=C2=A0 =C2=A0AODVv2 ha=
ndles a wide variety of mobility and traffic patterns by
=C2=A0 =C2=A0de=
termining routes on-demand...

It necessary =
to explicitly call out what kind of traffic patterns that reactive protocol=
s are not suitable for, such as lots of routers send data packets to instan=
taneous and multiple destinations. If that happens, what's the conseque=
nce (broadcasting storm, etc).=C2=A0
=C2=A0
=C2=A0 =C2=A0AODVv2 provides for message integrity and security against re=
play
=C2=A0 =C2=A0attacks by using integrity check values, timestamps an=
d sequence
=C2=A0 =C2=A0numbers, as described in Section 12.=C2=A0 If se=
curity associations can be
=C2=A0 =C2=A0established, encryption can be u=
sed for AODVv2 messages to ensure
=C2=A0 =C2=A0that only trusted routers=
 participate in routing operations.=C2=A0

=

We need to call out the hop-by-hop security model used, and the networ=
k MUST apply necessary mechanisms to make sure that only trusted routers ca=
n participate in routing operations.=C2=A0
=C2=A0
=C2=A0 =C2=A0The routing algorithm in AODVv2 MAY be operated at laye=
rs other than
=C2=A0 =C2=A0the network layer, using layer-appropriate ad=
dresses.

Considering the deep coupling betw=
een AODVv2 and IP, I don't see how it can work. This should be removed.=
=C2=A0

section 4 data structures
=

4.1 Interface set

The Inter=
faceSet is a conceptual data structure which contains
=C2=A0 =C2=A0infor=
mation about all interfaces available to AODVv2.
...
Otherwise the In=
terfaceSet MAY be empty.

I'm not sure t=
he sec MAY be empty -- a router contains at least one interface, no?=C2=A0<=
/div>

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
=C2=
=A0
The AODVv2 router adding the Router Client MU=
ST wait for
=C2=A0 =C2=A0any existing routing information about this Rou=
ter Client to be
=C2=A0 =C2=A0purged from the network, i.e., at least MA=
X_SEQNUM_LIFETIME since the
=C2=A0 =C2=A0last SeqNum update on the route=
r which is removing this Router
=C2=A0 =C2=A0Client.=C2=A0
<=
div>
I'm not sure that I parsed this sentence correctly, =
but the adding/removing of router client seems to be more an external opera=
tion and out of the control of routing protocol itself.=C2=A0
4.3 neighbor set

=C2=A0Neighbor.Sta=
te ... There are three possible states: Confirmed, Unknown, and
=C2=A0 =
=C2=A0 =C2=A0 Blacklisted.=C2=A0 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 hear=
d from that node, but bi-directionality is not confirmed".=C2=A0
=

I think "Heard" is a more appropriate term to be used here.=
=C2=A0

4.4 sequence numbers

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

Tod determine staleness,

typo

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 condition, how we=
 can modify the RIB?), or be removed. =C2=A0

=C2=
=A0
=C2=A0 =C2=A0Multiple valid routes for the same a=
ddress 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 the scope of
=C2=A0 =C2=A0AODVv2.

It's OK, but maybe some rules must be specifie=
d 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&=
#39;s a obvious source of loops.=C2=A0

4.6.=C2=A0 =
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 or=
iginator's address and sequence number, why 6 fields (OrigAddr, OrigFpr=
efixLen, OrigSeqNum, TargAddr, TargPrefixLen, TargSeqNum) are necessary her=
e.=C2=A0

section 5 Metrics
=C2=A0 =C2=A0In Route Request messages, th=
e metric describes the cost of the route
=C2=A0 =C2=A0from OrigAddr (and=
 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 Route=
r Client to the RREQ_Gen plus the metric from RREQ_Gen to the intermediate =
router.=C2=A0
In the Router Client Set, we have only o=
ne field for RouterClient.Cost. On the other hand, "AODVv2 supports di=
fferent metrics".=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rou=
terClient.cost =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AODVv2 metric=C2=
=A0
client-=
----------------------RREQ_gen---------------
<=
br>
What if those two metrics are of different types? =
This is quite possible because the two links might use different medium.=C2=
=A0


section 6 AODVv2 protocol Operations

<=
/b>
General comments:=C2=A0

I think this section is hard to read and needs =
some reconstruction. Generally speaking, people prefer begin from the impor=
tant operations to have a big picture/general idea of the protocol function=
ing, and then the details.=C2=A0
With the current orga=
nization, one needs to read till section 6.6 (Route discovery, retries and =
buffering) before he/she could reach the core functioning of the protocol.=
=C2=A0

I don't quite get=
 the current organization of sections either. For example:

section 6.2 (Next hop monitoring) and secti=
on 6.3 (Neighbor set update) are very related. One is about the function, a=
nd 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 s=
et) seem to have some overlapped operations. They all need to check the uni=
queness of the messages, compare the metrics and stop processing when dupli=
cation is detected. Although they are applied to different information base=
s, they are doing the same thing.=C2=A0

section 6.9 (suppressing redundant RERR messages using the Rout=
e Error set) should obviously a part of section 6.10.2 (reporting invalid r=
outes), but it's a separate section with higher hierarchy.=C2=A0
<=
div style=3D"">
more details 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

section 6.4.=C2=A0 Interaction with the Forwarding P=
lane

=C2=A0 =C2=A0o =C2=A0A rout=
e has been updated: update the corresponding route in the
=C2=A0 =C2=A0 =
=C2=A0 Routing Information Base.

Do we need to pay attention to the "multi-metrics&qu=
ot; issue here? To support multi-metrics, do we need special fields in the =
RIB? If so, we need to call it out in the applicability statement.=C2=A0

section 6.5.=C2=A0 Message Tra=
nsmission

=C2=A0 =C2=A0To implement the conge=
stion control, a queue length 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=A0=
priority must be removed from the queue.=C2=A0 If this is not possible,
=
=C2=A0 =C2=A0the new message MUST be discarded.=C2=A0 The queue should be s=
orted in
=C2=A0 =C2=A0order of message priority.=C2=A0
=

I think it's more implementation details rather than spe=
cification. =C2=A0

section 6.6=C2=A0

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

misplaced refe=
rence

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 SHO=
ULD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be used to update 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 Set,
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 the existing non-optimal LocalRoute will continue to b=
e used,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 causing data traffic to use a=
 non-optimal route.

If some route=
rs made the update, and some routers choose not updating, I'm afraid th=
ere will be loops in the network.=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 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 improvem=
ent.
=C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0If AdvRte is not better (i.e., i=
t is worse or equal) but
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 LocalRoute i=
s 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 Lo=
opFree function in the previous step 3?

sectio=
n 6.7.2.=C2=A0 Applying Route Updates
If the=
re is no existing matching route,
=C2=A0 =C2=A0AdvRte allows a correspon=
ding RREP to be sent.=C2=A0

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

=C2=A0 =C2=A07.=C2=A0 If an existing LocalRoute.Stat=
e changed from Invalid or
=C2=A0 =C2=A0 =C2=A0 =C2=A0Unconfirmed to beco=
me Idle, any matching Unconfirmed LocalRoute
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
with 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 valu=
e
=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 in progre=
ss, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0associated route request retry timers=
 SHOULD be cancelled.

why "SHOULD"=
;, not "MUST" here?=C2=A0

6.8.=C2=
=A0 Suppressing Redundant Messages Using the Multicast Route Message
<=
div>=C2=A0 =C2=A0 =C2=A0 Set

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

section 6.10 Local route set maintenance
=C2=A0<=
/div>
=C2=A0 =C2=A0During normal operation, AODVv2 does not=
 require 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 an=
d updated according to the rules below.
=C2=A0 =C2=A0If timers are not u=
sed to prompt updates of LocalRoute.State, the
=C2=A0 =C2=A0LocalRout=
e.State MUST be checked before IP packet forwarding and
=C2=A0 =C2=A0bef=
ore any operation based on LocalRoute.State.

<=
/div>
I don't think this is an efficient approach. If the routing d=
aemon runs in user space (which is true in most cases), this normally means=
 context switch. This is inevitable for reactive protocols, but doing so pe=
r packet seems to be expensive.=C2=A0


section 7 AODVv2 Protocol Messages

gener=
al comments:
=C2=A0 - the message regeneration, rather than the m=
essage forwarding, plus different optional fields make the protocol hard to=
 secure=C2=A0
=C2=A0 - the tradeoff of using multicast RREP and R=
ERR need to be carefully considered.=C2=A0
=C2=A0 - the tradeoff =
of using ValidityTime needs to be carefully considered

=

section 7.1
=C2=A0
=C2=A0 =C2=A0Prefix=
LengthList
=C2=A0 =C2=A0 =C2=A0 Contains OrigPrefixLen, i.e., the length=
, in bits, 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 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 T=
he 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 th=
e
=C2=A0 =C2=A0 =C2=A0 given prefix length).=C2=A0 Omitted if no time li=
mit is imposed.

the necessity of using Vali=
dityTime 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 RouterClient.Cost for the Router =
Client entry
=C2=A0 =C2=A0 =C2=A0 =C2=A0which includes OrigAddr
=C2=A0
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 o=
f medium.=C2=A0

=C2=A0However, th=
e regenerated RREQ can
=C2=A0 =C2=A0be unicast to the next hop address o=
f the LocalRoute toward TargAddr,
=C2=A0 =C2=A0if known.

This can be a problem if the TargAddr is known to th=
e routing set, but the link is actually broken. 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<=
/div>

I don't quite understand the purpose of =
multicast RREP. There are, however, lots of disadvantages of using an optio=
nal AckReq field.=C2=A0
This has been discussed in another thread=
=C2=A0https://www.ietf.org/mail-archive/web/manet/current/msg18864.html<=
/a>
=C2=A0 =C2=A0Before creating an =
RREP, the router SHOULD check if the corresponding
=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 reached.=C2=A0 If so, the RREP SHO=
ULD NOT be
=C2=A0 =C2=A0created.




7.4.1 RERR generation

Is it necessary to generate RERR for RREP failure?

=C2=A0
If there is no rou=
te to PktSource, the RERR SHOULD be
=C2=A0 =C2=A0multicast to LL-MANET-R=
outers.=C2=A0 If the RERR is sent in response to a
=C2=A0 =C2=A0broken l=
ink, i.e., PktSource is not included, the RERR is, by
=C2=A0 =C2=A0defau=
lt, multicast to LL-MANET-Routers.

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

=C2=A0 =C2=A02.=C2=A0 For each LocalRoute that needs to be report=
ed 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 AddressList.=


The AddressList can changed on every=
 RERR regeneration. On the other hand, in section 6.9 (suppressing redundan=
t 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 c=
orrectly?

One more note:

=
Jitter is not mentioned in the draft, which is important because the multic=
ast messages used.=C2=A0 I can see RFC5148 in the reference section, but di=
dn't find where it is used.=C2=A0

best




--001a11c2b75a61dc5905318cb083--


From nobody Thu Apr 28 08: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 B5C3212D1C9 for ; Thu, 28 Apr 2016 08:43:43 -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 WlcH2eYVzq3X for ; Thu, 28 Apr 2016 08:43:42 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c: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 39F1312D980 for ; Thu, 28 Apr 2016 08:40:19 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id o133so36167538vka.3 for ; Thu, 28 Apr 2016 08:40:19 -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=88DU09ce79maO9QPP6MTjZM0T0nBUG/rMAVfu7T5+H8=; b=aTaPbr4+2KwO6xtJWCze4CTrZIVzK+P3q4FLQ4H4Ef4iq9KcAZ+wjRPZoIjGr8l+u4 z5BvXv+uzoA5/jI2btX/E4LhwGvUejS2lr8apN8OXAKfgToHyTrCnFvSx3t+THjP5AIq gQjULUwy8F+0PBIgDNY3PVRRAPwXTnOoVZpHtHww9d840V9gwajpCJ/1Wk5IeWhwU08x tdYGtIKgiezRANrZgGuMV+CndjqSt734Bv8PclSG3UPq7znnt521lM8Xn9UxdE4XechB kUcnlpaUtpoIZ6hi69eEMIXK6bgLv52Rnt3S70RHn7cjryo5CA4nkAaRuFsEt9rnRtOE 29BA==
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=88DU09ce79maO9QPP6MTjZM0T0nBUG/rMAVfu7T5+H8=; b=hp6BTd3j3OoOAeI0obRUnd+C9xcMn1q0OvFaDfUhOt02qiJ0o54lxm7n7sqdt12oXf eVt/oZ9xvAiR0/GbpFnkIzBeo2BO78a3fZtJPtZP/OJiu2reu8N0wgqDHAO4ouKKsWC0 s82oQjYB0QejpICL73B1RiEl6N11XMYZ1nWcc9ky/4GsIK4DsamoKopXDM3XD+rxdNpV zl54+ffcN+Ex8+IMSNjwuixq3zFsSzN3A3wjC/lXcnIjwNtzie6LE8iKvH2Ny+ZPecCW 9rS4A6hnPwzJ9M+Moicortt6nH3oLWsaDd0ctqh8zgaz2DV8t8QyaudBet2QqwHTBGMU /DLw==
X-Gm-Message-State: AOPr4FXnlEMjyD9iYVEepIuy5lw2z7NtbJxmSXJi12qpKMNP8JJwlMFu2wNC9Vcm2xRwrwUmxH7gR8v0aJYagQ==
MIME-Version: 1.0
X-Received: by 10.176.1.45 with SMTP id 42mr7901772uak.65.1461858018266; Thu, 28 Apr 2016 08:40:18 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Thu, 28 Apr 2016 08:40:18 -0700 (PDT)
Date: Thu, 28 Apr 2016 11:40:18 -0400
Message-ID: 
From: Justin Dean 
To: "manet@ietf.org" 
Content-Type: multipart/mixed; boundary=001a11351d9ee48de605318d5727
Archived-At: 
Subject: [manet] WebEx meeting: MANET
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, 28 Apr 2016 15:43:43 -0000

--001a11351d9ee48de605318d5727
Content-Type: multipart/alternative; boundary=001a11351d9ee48de005318d5725

--001a11351d9ee48de005318d5725
Content-Type: text/plain; charset=UTF-8

*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.

--001a11351d9ee48de005318d5725
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




						

							

								
									MANET
								
							

							

								Thursday, May 12, 2016
								
							

							

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

						



=C2=
=A0

						

							

								
									
										Join WebEx meeting
									
								
							

						

						

							

								
									Meeting number:
								
								646 870 685
								
							

							

								Meeting password:
								GSwbmUQu
							

						




=09

	
=C2=
=A0
=

Join by phone
1-877-668-4493<=
/a>=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
Add this meeting to your calendar. (Cannot add from=
 mobile devices.)


=C2=
=A0



    

       
        Can't join the meeting?
     	
        	Contact support.
		
    




=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 joining 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.
							

						

						
			

		

	
   






--001a11351d9ee48de005318d5725--

--001a11351d9ee48de605318d5727
Content-Type: application/octet-stream; name="WebEx_Meeting.ics"
Content-Disposition: attachment; filename="WebEx_Meeting.ics"
Content-Transfer-Encoding: base64
X-Attachment-Id: 610950f46dd1ec33_0.1

QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg
MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP
TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDE0MTEwMVQwMjAw
MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G
RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6
U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE0MDMwMVQwMjAwMDAKUlJVTEU6RlJF
UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw
MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ
R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB
UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86YmViZW1hc3RlckBnbWFpbC5jb20KT1JHQU5JWkVS
O0NOPSJNYWRkeSBDb25uZXIiOk1BSUxUTzptY29ubmVyQGFtc2wuY29tCkRUU1RBUlQ7VFpJRD0i
RWFzdGVybiBUaW1lIjoyMDE2MDUxMlQxMDAwMDAKRFRFTkQ7VFpJRD0iRWFzdGVybiBUaW1lIjoy
MDE2MDUxMlQxMjAwMDAKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmClRSQU5T
UDpPUEFRVUUKU0VRVUVOQ0U6MTQ2MTc4ODk0MwpVSUQ6ZTMxY2M4NjctZWZhNy00NjM3LTgzMzEt
NWUzMzc1ODI1ZmY1CkRUU1RBTVA6MjAxNjA1MTJUMTQwMDAwWgpERVNDUklQVElPTjpcblxuXG5K
T0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElE
PW1kMDc3NDAyZjljZmUzNDUxMmJlYjUwZTBjYjk1NzNlZlxuTWVldGluZyBudW1iZXI6IDY0NiA4
NzAgNjg1XG5NZWV0aW5nIHBhc3N3b3JkOiBHU3dibVVRdVxuXG5cbkpPSU4gQlkgUEhPTkVcbjEt
ODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKSBcbjEtNjUw
LTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcbkFjY2VzcyBjb2RlOiA2
NDYgODcwIDY4NVxuXG5Ub2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IFxuaHR0cHM6Ly93
d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmXG5cblxuXG5DYW4ndCBq
b2luIHRoZSBtZWV0aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZTpcbmh0dHBzOi8vaWV0Zi53ZWJl
eC5jb20vaWV0Zi9tY1xuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhp
cyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBk
dXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFi
bGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21h
dGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50
IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBv
ciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbgpYLUFMVC1ERVNDO0ZNVFRZUEU9dGV4dC9odG1s
Ogk8Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiA8Rk9OVCBTSVpFPSI0IiBG
QUNFPSJBUklBTCI+CQk8YQkJCQkJaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou
cGhwP01USUQ9bWQwNzc0MDJmOWNmZTM0NTEyYmViNTBlMGNiOTU3M2VmIj48Rk9OVCBTSVpFPSIz
IiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iQXJpYWwiPkpvaW4gV2ViRXggbWVldGluZzwvRk9OVD48
L2E+CQkJPHRhYmxlPgkJCQk8dHI+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9
IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlcjo8L0ZPTlQ+CQkJCQk8L3RkPgkJ
CQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+
NjQ2IDg3MCA2ODU8L0ZPTlQ+CQkJCQk8L3RkPgkJCQk8L3RyPgkJCTwvdGFibGU+CQkJPHRhYmxl
Pjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0
aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9IiM2NjY2
NjYiIEZBQ0U9ImFyaWFsIj5HU3dibVVRdTwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT4JCTwvRk9O
VD48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48L0ZPTlQ+
PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2
IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9
IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4xLTg3Ny02NjgtNDQ5Mzwv
c3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4m
bmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0
cm9uZz4xLTY1MC00NzktMzIwODwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVT
L0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg
RkFDRT0iYXJpYWwiPkFjY2VzcyBjb2RlOiA2NDYgODcwIDY4NTwvRk9OVD4mbmJzcDsgPEJSPjxh
IGhyZWY9Imh0dHBzOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBk
ZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFsIj5Ub2xsLWZyZWUg
Y2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJSPjwvRk9OVD48QlI+PEJS
PgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+
CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVmPSJodHRwczovL2lldGYu
d2ViZXguY29tL2lldGYvbWMiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0i
QXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48L0ZPTlQ+PC9hPgkmbmJzcDs8QlI+Jm5ic3A7PEJSPjxG
T05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJhcmlhbCI+SU1QT1JUQU5UIE5PVElD
RTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBv
dGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwg
d2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0
aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdz
LiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBj
b25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLjwvRk9OVD48
L0ZPTlQ+ClNVTU1BUlk6TUFORVQKUFJJT1JJVFk6NQpDTEFTUzpQVUJMSUMKQkVHSU46VkFMQVJN
ClRSSUdHRVI6LVBUMTVNCkFDVElPTjpESVNQTEFZCkRFU0NSSVBUSU9OOlJlbWluZGVyCkVORDpW
QUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg==
--001a11351d9ee48de605318d5727--


From nobody Thu Apr 28 08:58:00 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 BBAF912D9BA for ; Thu, 28 Apr 2016 08:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.915
X-Spam-Level: 
X-Spam-Status: No, score=-7.915 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] 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 Fm40ShoAs0kt for ; Thu, 28 Apr 2016 08:57:57 -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 3AE4112D92F for ; Thu, 28 Apr 2016 08:51:21 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,547,1454976000"; d="scan'208,217"; a="65249607"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 28 Apr 2016 16:51:18 +0100
X-IronPort-AV: E=Sophos;i="5.24,547,1454976000";  d="scan'208,217";a="115963858"
Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 28 Apr 2016 16:51:18 +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; Thu, 28 Apr 2016 16:51:18 +0100
From: "Dearlove, Christopher (UK)" 
To: Justin Dean , "manet@ietf.org" 
Thread-Topic: [manet] WebEx meeting: MANET
Thread-Index: AQHRoWTD9GpU38PLQ0O7UQGDdK4nJZ+fiE7w
Date: Thu, 28 Apr 2016 15:51:16 +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_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2376GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [manet] WebEx meeting: MANET
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, 28 Apr 2016 15:57:58 -0000

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2376GLKXM0002VGREEN_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

Tm90ZSB0aGF04oCZcyBhIGNoYW5nZSBhZ2FpbiBmcm9tIHRoZSBsYXN0IGFubm91bmNlZCAxMCBF
U1QsIHRoaXMgaXMgMTAgRURULg0KDQoxNDowMCBVVEMsIHllcz8NCg0KLS0NCkNocmlzdG9waGVy
IERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVk
IEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQg
KDApMTI0NSAyNDIxOTQgIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0
bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJ
bnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENo
ZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3
dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExp
bWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0
ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1Uy
IDdZUA0KDQpGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBKdXN0aW4gRGVhbg0KU2VudDogMjggQXByaWwgMjAxNiAxNjo0MA0KVG86IG1hbmV0
QGlldGYub3JnDQpTdWJqZWN0OiBbbWFuZXRdIFdlYkV4IG1lZXRpbmc6IE1BTkVUDQoNCg0KKioq
IFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9y
Z2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJu
ZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBs
aW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVn
YXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3Ug
cmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hv
d3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0K
SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBw
cm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3Vy
aXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVt
YWlscy5wZGY+Lg0KKioqIFdBUk5JTkcgKioqDQpFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3Nh
Z2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbi4NCg0KDQpNQU5FVA0K
DQpUaHVyc2RheSwgTWF5IDEyLCAyMDE2DQoNCjEwOjAwIGFtICB8ICBFYXN0ZXJuIERheWxpZ2h0
IFRpbWUgKE5ldyBZb3JrLCBHTVQtMDQ6MDApICB8ICAyIGhycw0KDQoNCg0KDQoNCkpvaW4gV2Vi
RXggbWVldGluZyA8aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWQwZDgw
ODVlMGMzMWRlOGZkMmU2YjVkY2JiMzc5OWM1Pg0KDQoNCk1lZXRpbmcgbnVtYmVyOg0KDQo2NDYg
ODcwIDY4NQ0KDQpNZWV0aW5nIHBhc3N3b3JkOg0KDQpHU3dibVVRdQ0KDQoNCg0KDQoNCkpvaW4g
YnkgcGhvbmUNCg0KMS04NzctNjY4LTQ0OTM8dGVsOjEtODc3LTY2OC00NDkzPiBDYWxsLWluIHRv
bGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkNCg0KMS02NTAtNDc5LTMyMDg8dGVsOjEtNjUwLTQ3
OS0zMjA4PiBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpDQoNCkFjY2VzcyBjb2RlOiA2
NDYgODcwIDY4NQ0KDQpUb2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8aHR0cHM6Ly93d3cu
d2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmPg0KDQoNCg0KDQoNCkFkZCB0
aGlzIG1lZXRpbmc8aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWY0NzMx
MTVhMDY2ZDJlNDU5YTUwZjYzNzU2NmQ5YzI1PiB0byB5b3VyIGNhbGVuZGFyLiAoQ2Fubm90IGFk
ZCBmcm9tIG1vYmlsZSBkZXZpY2VzLikNCg0KDQoNCg0KDQpDYW4ndCBqb2luIHRoZSBtZWV0aW5n
PyBDb250YWN0IHN1cHBvcnQuPGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYz4NCg0KDQoN
Cg0KDQpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2Vydmlj
ZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNz
aW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwg
bWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2Vu
dCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNv
cmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4g
dGhlIHNlc3Npb24uDQoNCg0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRh
Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1h
eSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGll
bnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRl
ci4KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBk
aXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKgo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2376GLKXM0002VGREEN_
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
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K
ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h
eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9
IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k
eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX
b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vdGUgdGhhdOKAmXMgYSBjaGFuZ2UgYWdhaW4gZnJvbSB0
aGUgbGFzdCBhbm5vdW5jZWQgMTAgRVNULCB0aGlzIGlzIDEwIEVEVC48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjE0OjAw
IFVUQywgeWVzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox
Mi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjxv
OnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAw
N0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVy
PGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0K
PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzdEN0Q3RCI+OiAmbmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wgJm5ic3A7PGI+
RToNCjwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNo
cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwg
Q2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNz
ZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48
c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwv
YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxp
Z2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzog
MDEzMzc0NTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
M0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9y
ZCwgU3VycmV5LCBHVTIgN1lQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNl
c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIERlYW48YnI+DQo8Yj5TZW50
OjwvYj4gMjggQXByaWwgMjAxNiAxNjo0MDxicj4NCjxiPlRvOjwvYj4gbWFuZXRAaWV0Zi5vcmc8
YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW21hbmV0XSBXZWJFeCBtZWV0aW5nOiBNQU5FVDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4w
cHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5
bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs
YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6
d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdB
Uk5JTkcgKioqPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20g
b3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVy
IG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdo
ZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRz
IG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9u
IHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48
ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2Fu
IGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0
cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxp
Z2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxp
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0K
PGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2Vj
dXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIw
RW1haWxzLnBkZiI+DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5k
b3d0ZXh0IDEuMHB0O3BhZGRpbmc6MS4wcHQgNC4wcHQgMS4wcHQgNC4wcHQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyIj4NCjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij4qPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+KioNCjwvc3Bhbj48L3N0cm9uZz48L3NwYW4+PHN0cm9uZz48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XQVJOSU5HDQo8L3NwYW4+PC9zdHJvbmc+PHN0cm9u
Zz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+KioqPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkVYVEVSTkFMIEVNQUlMIC0t
IFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uPC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi
IGFsaWduPSJsZWZ0IiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+
DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6My43NXB0IDBjbSAwY20gMGNtIj4NCjx0YWJsZSBj
bGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGFsaWduPSJs
ZWZ0IiB3aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQ7bWFyZ2luLWxlZnQ6My43NXB0
Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQg
Ljc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVt
ZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3Jh
cDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVu
dC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPG86
cD4mbmJzcDs8L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9
IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8
dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVt
ZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1l
bnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRh
bDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImNvbG9y
OiM0RDRENEQiPk1BTkVUPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6IzRENEQ0RCI+IDxv
OnA+DQo8L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBh
ZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNv
LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw
aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4
YWN0bHkiPg0KVGh1cnNkYXksIE1heSAxMiwgMjAxNiA8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8
L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVu
dC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50
LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6
Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjEwOjAwIGFtJm5ic3A7Jm5ic3A7fCZu
YnNwOyZuYnNwO0Vhc3Rlcm4gRGF5bGlnaHQgVGltZSAoTmV3IFlvcmssIEdNVC0wNDowMCkmbmJz
cDsmbmJzcDt8Jm5ic3A7Jm5ic3A7MiBocnMgPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4N
CjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVt
ZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3Jh
cDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVu
dC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNw
YW4gc3R5bGU9ImRpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRh
YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8
dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43
NXB0IC43NXB0IC43NXB0IC43NXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVu
dC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50
LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6
Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21z
by1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3Jh
cGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpl
eGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBh
ZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MGNtO3dpZHRoOmF1dG8haW1wb3J0YW50
Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAu
NzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNv
LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t
ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp
em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iY29s
b3I6IzAwQUZGOSI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01U
SUQ9bWQwZDgwODVlMGMzMWRlOGZkMmU2YjVkY2JiMzc5OWM1IiB0YXJnZXQ9Il9ibGFuayI+PGI+
PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFGRjk7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPkpvaW4gV2Vi
RXggbWVldGluZzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFGRjk7dGV4dC1kZWNv
cmF0aW9uOm5vbmUiPg0KPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K
PC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1l
bnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28t
ZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHki
Pg0KPHNwYW4gc3R5bGU9ImRpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0i
MCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY207d2lkdGg6YXV0byFpbXBvcnRhbnQiPg0KPHRi
b2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IDMuNzVwdCAuNzVwdCAuNzVwdCI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1l
bnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVu
dC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFs
OmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQpNZWV0aW5nIG51bWJlcjogPG86cD48
L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43
NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28t
ZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1l
bGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6
b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjY0NiA4NzAgNjg1IDxvOnA+
PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQg
My43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxl
bWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdy
YXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1l
bnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCk1l
ZXRpbmcgcGFzc3dvcmQ6PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5n
Oi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVt
ZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNv
LWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5
Ij4NCkdTd2JtVVF1PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3Rh
YmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1l
bGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVs
ZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpv
bnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImRpc3Bs
YXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29O
b3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHIgc3R5
bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0
IC43NXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt
aGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6
Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNh
bDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWln
aHQtcnVsZTpleGFjdGx5Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8
L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVu
dDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6
YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt
YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu
IHN0eWxlPSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJs
ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRi
b2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVu
dC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50
LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6
Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPkpvaW4gYnkgcGhvbmU8L2I+PG86
cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVw
dCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVs
ZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13
cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVt
ZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8
Yj48YSBocmVmPSJ0ZWw6MS04NzctNjY4LTQ0OTMiIHRhcmdldD0iX2JsYW5rIj4xLTg3Ny02Njgt
NDQ5MzwvYT48L2I+Jm5ic3A7Q2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpPG86
cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVw
dCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVs
ZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13
cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVt
ZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8
Yj48YSBocmVmPSJ0ZWw6MS02NTAtNDc5LTMyMDgiIHRhcmdldD0iX2JsYW5rIj4xLTY1MC00Nzkt
MzIwODwvYT48L2I+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1
cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50
OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDph
cm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1h
bmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KQWNjZXNz
IGNvZGU6Jm5ic3A7NjQ2IDg3MCA2ODU8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRy
Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1o
c3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12
ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21z
by1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LndlYmV4LmNvbS9w
ZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMwMEFGRjk7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPlRv
bGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8
L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNv
LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw
aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4
YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImRpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFk
ZGluZz0iMCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxl
PSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFt
ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k
O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y
LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3Bh
Y2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0
aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1o
ZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRl
cj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5n
Oi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVt
ZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNv
LWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5
Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YSBocmVmPSJodHRwczovL2lldGYu
d2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tZjQ3MzExNWEwNjZkMmU0NTlhNTBmNjM3NTY2ZDlj
MjUiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRlY29y
YXRpb246bm9uZSI+QWRkIHRoaXMgbWVldGluZzwvc3Bhbj48L2E+IHRvIHlvdXIgY2FsZW5kYXIu
IChDYW5ub3QgYWRkIGZyb20gbW9iaWxlIGRldmljZXMuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDtt
c28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdy
YXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6
ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxw
YWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5
bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZy
YW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91
bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNo
b3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KJm5ic3A7PG86
cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhz
cGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZl
cnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNv
LWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImRpc3BsYXk6bm9uZSI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9y
ZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRp
bmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVs
ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt
c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0
bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2Ij5DYW4ndCBqb2lu
IHRoZSBtZWV0aW5nPw0KPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIiB0
YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFGRjk7dGV4dC1kZWNvcmF0aW9u
Om5vbmUiPkNvbnRhY3Qgc3VwcG9ydC48L3NwYW4+PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0
O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh
Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs
ZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2Vs
bHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6Ny41cHQiPg0KPHRkIHN0
eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0O2hlaWdodDo3LjVwdCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDo3LjVwdDttc28tZWxl
bWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdy
YXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1l
bnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1m
cmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFu
Y2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29s
dW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJkaXNwbGF5Om5vbmUi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFi
bGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxl
PSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0
O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh
Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs
ZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6I0EwQTBBMCI+
SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxs
b3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0
byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRl
ci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5DQogY29uc2VudCB0
byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRl
ZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhl
IHNlc3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K
PC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4N
CjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxwPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0
YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQ8YnI+CnJlY2lwaWVudCBh
bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJy
PgpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkg
dGhlIHNlbmRlci48YnI+CllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkg
cHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+CmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFu
eSBvdGhlciBwZXJzb24uPGJyPgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvcD48L2JvZHk+DQo8L2h0bWw+DQo=

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B2376GLKXM0002VGREEN_--


From nobody Thu Apr 28 09:14: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 DCB7B12D918 for ; Thu, 28 Apr 2016 09:14:45 -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 6sKIPLlP_-yi for ; Thu, 28 Apr 2016 09:14:43 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 DD94D12D7D6 for ; Thu, 28 Apr 2016 09:08:07 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id c126so101419640lfb.2 for ; Thu, 28 Apr 2016 09:08:07 -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=YGT43ShTmbkytJ0UNiihKTP/qBA7JCNqmGOetqDqaUc=; b=oFyXYjdtOkc2SlQ0jJUNLv0CVXVN4FMwg3cVFPcPY9fGbz1kwz33xhYUhK2z/RYiui XF83PgsS6t+7UClWWUP/76WXsv3OkHMyUZzdrPLcsVpvQZr7PeHlYoOQCmfQ4zh5ioj7 XhPdScwzgPdy4okdZ79DIXtyqa1yiCKBt+Q2ga64cE1JGma7v6wotnUjAz4d/pmHQgQk RMctrqxf2NF8FehdxXUHoxUrFD20WKUK3WJgZecRhDVtH331PVpXKMVp14DX+sCvHR5L 060+NOwjzVv8gOTRHMjIUAP558zYVDfJy3tDfgXj7SiXeiM95shPlP6u3fSRypcm+Zgb Dvyw==
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=YGT43ShTmbkytJ0UNiihKTP/qBA7JCNqmGOetqDqaUc=; b=YZEQGD+8DJU7yRdN+zToKjtroo6c/R5P61g6G94gPD30XQT/w4mY3BRHhyNUTrt6li QBppHhcJ7KPjTVqySDyE8sEzB3IEQxdavKMnwls28nuS0mzklgmhfRwftHlfVezxqGsF FNJM7RzW2BvLyE/Sbw8WNdTnffNYqhIU6S94PaIDJK5L7Y76keGnhXMKSXhM+oGXLuAr Kwh5zflu/5CRyaE2xJV1WD7kyZWvxZ5Oh/i828z+B4lSKmURsIuhsJildzLA+AFYE9gb h6TLXBSw4NVjBLpuRXMJRsvwE/VyTvJOIos0gwg6CPadUyJfRCy0WwxKCb+o074WEdV6 WZdg==
X-Gm-Message-State: AOPr4FXcyjniu2a8zAongFL1i6gQ/FyfUOYSZ4uV4IM5ROeOJJQxC/RsmHKq1E1DKx0WQNn1RUvYfriTqTKlyg==
X-Received: by 10.112.168.65 with SMTP id zu1mr6343067lbb.66.1461859686088; Thu, 28 Apr 2016 09:08:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.24.42 with HTTP; Thu, 28 Apr 2016 09:07:36 -0700 (PDT)
In-Reply-To: 
References:  
From: Henning Rogge 
Date: Thu, 28 Apr 2016 18:07:36 +0200
Message-ID: 
To: "Dearlove, Christopher (UK)" 
Content-Type: multipart/alternative; boundary=001a11c343784d067f05318dbb81
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] WebEx meeting: MANET
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, 28 Apr 2016 16:14:46 -0000

--001a11c343784d067f05318dbb81
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes...

16:00 MET.

Henning Rogge

On Thu, Apr 28, 2016 at 5:51 PM, Dearlove, Christopher (UK) <
chris.dearlove@baesystems.com> wrote:

> Note that=E2=80=99s a change again from the last announced 10 EST, this i=
s 10 EDT.
>
>
>
> 14:00 UTC, yes?
>
>
>
> *-- *
>
>
>
>
> *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:* 28 April 2016 16:40
> *To:* manet@ietf.org
> *Subject:* [manet] WebEx meeting: MANET
>
>
>
>
>
> **** 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.
>
>
>
>
>
> *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 automaticall=
y
> consent to such recordings. If you do not consent to being recorded,
> discuss your concerns with the host or do not join the session.
>
>
>
> ********************************************************************
> 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
>
>

--001a11c343784d067f05318dbb81
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Yes...

16:00 MET.

Henning Rogge

On Thu, Apr 28, 2016 at 5:51 PM, Dearlove, Christopher (UK=
) <chris.dearlove@baesystems.com> wrote:











Note that=E2=80=99s a cha=
nge again from the last announced 10 EST, this is 10 EDT.


=C2=A0


14:00 UTC, yes?=



=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: manet [mailto:manet-bounces@ietf.org]
On Behalf Of Justin Dean

Sent: 28 April 2016 16:40

To: manet@ietf.o=
rg

Subject: [manet] WebEx meeting: MANET


=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.=










***
WARNING
***

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




=C2=A0

















=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




********************************************************************

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





--001a11c343784d067f05318dbb81--


From nobody Thu Apr 28 09:15: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 A620412D958 for ; Thu, 28 Apr 2016 09:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 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, MISSING_HEADERS=1.021, 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 tBdL7GHlMscB for ; Thu, 28 Apr 2016 09:15:15 -0700 (PDT)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 447DF12D9AE for ; Thu, 28 Apr 2016 09:08:55 -0700 (PDT)
Received: by mail-vk0-x22b.google.com with SMTP id o133so37238422vka.3 for ; Thu, 28 Apr 2016 09:08:55 -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:cc;  bh=rBYm1I4KQOpVFw3UftOjg+X1gJ7O/5LzpFlDB2CVbzM=; b=tgxhcWHuGftsZaKGlRNG/ZuIyrP1aWh6XuYlE4Do+/QbSwerUY0RZ2mzbH757ywau8 rz+M1WRKBOG99QWj/pceOJV6W9HAApZvNP04TXYV+AkFdMBO0leTx9onQFYwBHDUMWoN 9Mz704p2XpY0YDh2m/WnlxHbuYDOVAePn9OovL85Z3/fnMfj7u0WPmVatB6ByX7xvOOd 31/+UhP9VGj02Fp2I7P2B1BNk1igj/Nwo38ht7ZuC7pGPDquLXhwX9UcP7FFL+tTFK6f SVfRQtAMmiPuqmwMJtHVkTHm6zCf+eEAMDKaVgqzWYwqFDFO6XjKIYF02LhC8SZpLiCX bDrQ==
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:cc; bh=rBYm1I4KQOpVFw3UftOjg+X1gJ7O/5LzpFlDB2CVbzM=; b=hU4yXMVqgNKfQgjoj/oXBHLNuSlKxQ2AR2DTxZiQecDnY2ujkISUK6ChHM5yqKfu0R qsdxz/OOBLwwe8dP8o6UcxoocyvUnDJG2gNNzySCCmYUjjG5cLdzVsO8Pe5CaHPzgtqj 7tLz5GTkDyz54jzgYHmY8pEQ0z+DY6l/RWtfVyHvJM5vd+RIgv+xH6MJhptocttYdWJJ G0NfP6jxb7gVdoZnoaUJzQqqipz+SjtPWkPg3UhiBafpnhF5ImBZyE7/f5brBpEep1DF aMWOt7r14mXcVYfHaAELGvarUHy7a+IRsNn9XJ6E4k3Fw4n8pEjDXlRZGovRRSJ8dc8P R9+w==
X-Gm-Message-State: AOPr4FWkiifBUENX/IjrZxzSxTbqiGsYKTRdDQp3y6o0/GA7vo1RsxwsqkKyg/pQEgrgQwaiQoEw9E8IR1ewBg==
MIME-Version: 1.0
X-Received: by 10.31.178.130 with SMTP id b124mr2866379vkf.52.1461859734400; Thu, 28 Apr 2016 09:08:54 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Thu, 28 Apr 2016 09:08:54 -0700 (PDT)
In-Reply-To: 
References:  
Date: Thu, 28 Apr 2016 12:08:54 -0400
Message-ID: 
From: Justin Dean 
Cc: "manet@ietf.org" 
Content-Type: multipart/alternative; boundary=001a114305202e3be805318dbe03
Archived-At: 
Subject: Re: [manet] WebEx meeting: MANET
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, 28 Apr 2016 16:15:17 -0000

--001a114305202e3be805318dbe03
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The WebEx time is correct.  I have found a new hatred for the people who
thought up daylight savings time.

Justin

On Thu, Apr 28, 2016 at 11:51 AM, Dearlove, Christopher (UK) <
chris.dearlove@baesystems.com> wrote:

> Note that=E2=80=99s a change again from the last announced 10 EST, this i=
s 10 EDT.
>
>
>
> 14:00 UTC, yes?
>
>
>
> *-- *
>
>
>
>
> *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:* 28 April 2016 16:40
> *To:* manet@ietf.org
> *Subject:* [manet] WebEx meeting: MANET
>
>
>
>
>
> **** 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.
>
>
>
>
>
> *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 automaticall=
y
> consent to such recordings. If you do not consent to being recorded,
> discuss your concerns with the host or do not join the session.
>
>
>
> ********************************************************************
> 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.
> ********************************************************************
>

--001a114305202e3be805318dbe03
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The WebEx time is correct=
.=C2=A0 I have found a new hatred for the people who thought up daylight sa=
vings time.

Justin

On Thu, Apr 28, 2016 at 11:51 AM, Dearlove, Christophe=
r (UK) <chris.dearlove@baesystems.com> wrote:











Note that=E2=80=99s a cha=
nge again from the last announced 10 EST, this is 10 EDT.


=C2=A0


14:00 UTC, yes?=



=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: manet [mailto:manet-bounces@ietf.org]
On Behalf Of Justin Dean

Sent: 28 April 2016 16:40

To: manet@ietf.o=
rg

Subject: [manet] WebEx meeting: MANET


=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.=










***
WARNING
***

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




=C2=A0

















=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




********************************************************************

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.

********************************************************************






--001a114305202e3be805318dbe03--


From nobody Thu Apr 28 09:21: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 7D86612D90F for ; Thu, 28 Apr 2016 09:21:47 -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 QA14YkkJzPJk for ; Thu, 28 Apr 2016 09:21:44 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 D8D7912D94D for ; Thu, 28 Apr 2016 09:17:50 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id c126so101771984lfb.2 for ; Thu, 28 Apr 2016 09:17: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:from:date:message-id:subject:to :cc; bh=8f4u4CUoh0JNGJkrMR/1EgSFd5dsQAjW86TpB636wLY=; b=Q4Jc2yW4DMnO5pY5rWLckiEij9U8cKvafl5RvtQCOc5W6a4ARk+vezCHCT7FlqsygI mA31n+LDFSW6yWiLp28RMMOIqOh46IhFdwB4kkRflFOeYd6UUlcRDibB4jfVIEOGslMB 5dpqNtO8QC0tgBtkgpqnio6mQbUMNyF9nDvP64OKX8a9mFJC2j8I1QEJftwVjzMJZyYZ L1qgG7Q+9UERzX98ZEaiSN9UH8dBKC1oLuWNASdpgeg32o0xxT+9YDbA6mKfYH3FrFwE yd7g7FFEkSu6+UdFj3Qre+x2QZw8fOm6yEKvI/xkLwwGLgqQ6fZJAH6ISqcsU9zeU7bt KoNw==
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=8f4u4CUoh0JNGJkrMR/1EgSFd5dsQAjW86TpB636wLY=; b=kO2pDl3sL//5sbY8wjpbFqVjP66VPy4n1pWCVQVao+HKM41+DAWOE2GH5v6VHC7zcB iA1lpez6nca9U77eXUGVJuZtgxXL0lL0MXdnkQvnfbBAYrhROboTrjO0AOJtQAPFBTdk mffPcDFYuo9S7lC0oqh7JyBchXv23wefCM4G47gJbf+AkxLtgGee6Yzyjw/uCkLu4RaV FA+v5UnjxrjcpV93PWGMMxDvi9dADOTHpXD3aXHnFKajHeHGOxSgsmfEmbDFFccLfc3O xxGf5qzLLGAdHlfqH9cK4oMukmlFXs9KawUYQCotjK93MjC5rw0dWZHQEe4yVSpBLKqu NCpw==
X-Gm-Message-State: AOPr4FW85l+bBasPWe/o2OOqYhcaatNgTnBgrmkJJlq9k/YbDff6hVoHz+OaTnXgZXNeFUnylp/Ea0dJRqP/ZA==
X-Received: by 10.25.205.12 with SMTP id d12mr5880896lfg.128.1461860269066; Thu, 28 Apr 2016 09:17:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.24.42 with HTTP; Thu, 28 Apr 2016 09:17:19 -0700 (PDT)
In-Reply-To: 
References:   
From: Henning Rogge 
Date: Thu, 28 Apr 2016 18:17:19 +0200
Message-ID: 
To: Justin Dean 
Content-Type: multipart/alternative; boundary=001a1141222a0c908105318dde96
Archived-At: 
Cc: "manet@ietf.org" 
Subject: Re: [manet] WebEx meeting: MANET
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, 28 Apr 2016 16:21:47 -0000

--001a1141222a0c908105318dde96
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 28, 2016 at 6:08 PM, Justin Dean  wrote:

> The WebEx time is correct.  I have found a new hatred for the people who
> thought up daylight savings time.
>

You too? Can we please make the UN/EU/US/whoever stop everyone doing this
stupid thing?

Henning

--001a1141222a0c908105318dde96
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
hu, Apr 28, 2016 at 6:08 PM, Justin Dean <bebemaster@gmail.com><=
/span> wrote:
The WebEx time is correct.=C2=A0 I have found a new =
hatred for the people who thought up daylight savings time.

You too? Can we please make the UN/EU/US/whoe=
ver stop everyone doing this stupid thing?

Henning=



--001a1141222a0c908105318dde96--


From nobody Thu Apr 28 09:55: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 A0A6812D1E2 for ; Thu, 28 Apr 2016 09:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.143
X-Spam-Level: 
X-Spam-Status: No, score=-1.143 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, TRACKER_ID=1.306] 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 dE55aFP4wQOY for ; Thu, 28 Apr 2016 09:55:50 -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 C350A12D1C1 for ; Thu, 28 Apr 2016 09:55:49 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id j74so114249951ywg.1 for ; Thu, 28 Apr 2016 09:55:49 -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=Mod6L38X1l4pgkWr9TQKkJQv3hdTbKCYFi7O15HGLg4=; b=pRngEEQwu8lqnIgfYqAGF0/qF3mjor1kEXW8RHL2NwJJymelkLp268oqr14tUcxBqA NLmgG9lmTrZItnXcGLRLpIqHrvLHOxXmC2MnlKqPSTnfqLWUFO6xCd6oAxrOFw6viWKu dObLthzpsz9JeLSD+Zgvoyn2ZrO9L1wKCCN3qRY2jXsc2GAfzEKdxx/4fEh86GShEnUZ cDAAqacvpqbUTQIDnNtO0x83pEgdZVcMH6Faco1lD/TYr59AR0JCZdZpInfgLO1QJYfk KA01pijxepoA4dQqG0J/9UIssrffpNCc9g1QiClSRMKXsG9jsnWGXOJV2aRoAivl30w7 x4tA==
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=Mod6L38X1l4pgkWr9TQKkJQv3hdTbKCYFi7O15HGLg4=; b=BO6tYpo93mdq+zsgUbrHUT9kDVktIK+1eXCsS0ujjM7n9EdAXILClytijkiJ/Mhzl8 pwjEeIqI6PsmkHQmEfZUBn7PEnsBeOXhNgkQStRNSLycun1wN51kDY7h1Abf9J2EQYGw 6ADKu1MRSaPBwv/X0iQOL0dTzVZ7sZ4/kVe2YVnWM7SjVbzYyEKrujyp3Am7gDgz7yGb fHxr4K+TYtnrevzf5DwLrLuRVqm/LHAgeJ+EJ61UCX63A6ZON1TULmerXzJqNEKIcLcx pdo8GTmLp9rfQcmz3FDN5riKc8OxhDfNAGiKeuF1aNMVxRtj0ZIkFTNCHhYAJIxYDao6 B/kw==
X-Gm-Message-State: AOPr4FXMk84IobSWXAbJmmlp/vxCxGcgZRQrWR4c3LeXvzDs23lGOUe4je/bDt8oLr9rq6O1eNwMuTe0APDfGw==
MIME-Version: 1.0
X-Received: by 10.159.40.133 with SMTP id d5mr8330969uad.13.1461862548836; Thu, 28 Apr 2016 09:55:48 -0700 (PDT)
Received: by 10.176.65.40 with HTTP; Thu, 28 Apr 2016 09:55:48 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org>       
Date: Thu, 28 Apr 2016 17:55:48 +0100
Message-ID: 
From: Victoria Mercieca 
To: Jiazi YI 
Content-Type: multipart/alternative; boundary=94eb2c1228d0ef1bef05318e654b
Archived-At: 
Cc: Christopher Dearlove , Mobile Ad Hoc Networks mailing list , "Dearlove, Christopher \(UK\)" 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 28 Apr 2016 16:55:56 -0000

--94eb2c1228d0ef1bef05318e654b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Jiazi,

Thanks for your response. So you think we could change back to sending RREP
by unicast (letting an implementation handle whether this requires a route
to the neighbor to be installed temporarily)? We would have to also send a
separate message to request an acknowledgement, but this could also be
unicast and could therefore potentially be sent in the same RFC5444 packet.

Anyone have any objections?

Kind regards,
Victoria.

On Wed, Apr 27, 2016 at 11:34 PM, Jiazi YI  wrote:

>
>
> On Wed, Apr 27, 2016 at 10:59 PM, Victoria Mercieca 
> wrote:
>
>> Just quickly, on this note, if we remove the AckReq from the RREP itself=
,
>> then because the RREP is multicast, there might be multiple receivers, b=
ut
>> there's no way for them to determine if they were the intended next hop,=
 so
>> they would all have to forward the RREP. The RREP might then go by multi=
ple
>> routes to get to RREQ_Gen. This assumes all receivers of the RREP have a
>> route to OrigAddr anyway (current rules say if they didnt, they would se=
nd
>> a RERR back to RREP_Gen).
>>
>> So, do we have to install a route to the neighbour, then unicast the RRE=
P
>> and create a separate message with an AckReq, then if no acknowledgement=
 is
>> received, blacklist the neighbor and remove the route to the neighbor?
>> along with the route to OrigAddr which is not available because the link=
 is
>> not bidirectional...?
>>
>
> My opinion is, if we have a neighbor address and the interface through
> which the neighbor can be (possibly) reached, then we can send an unicast
> to it.
> The others are more implementation details: for example, if a route to th=
e
> neighbor is required, we can setup a temporary route entry to the neighbo=
r,
> and remove it after the unicast is finished. As it's more implementation,=
 I
> don't think it's necessary to go to the specification.
>
> Another related question: when I was reading the specification, a router
> only sets up routes to the source/destination, but not to its direct
> neighbors?
>
> best
>
> Jiazi
>
>
>>
>> Regards,
>> Victoria.
>>
>> On Mon, Apr 25, 2016 at 4:34 PM, Justin Dean 
>> wrote:
>>
>>> On Mon, Apr 25, 2016 at 11:29 AM, Jiazi YI  wrote:
>>>
>>>> Hi,
>>>>
>>>> Maybe I missed a bit here:
>>>>
>>>> If only the desired receiver of the multicast RREP (carrying a
>>>> destination address) can reply to the multicast RREP, why not using un=
icast
>>>> directly?
>>>>
>>>> Because the link isn't yet known to be bi-directional and a unicast
>>> route can't be installed yet.
>>>
>>> Justin
>>>
>>>
>>>> best
>>>>
>>>> Jiazi
>>>>
>>>> On Mon, Apr 25, 2016 at 4:59 PM, Victoria Mercieca <
>>>> vmercieca0@gmail.com> wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>>
>>>>> On Mon, Apr 25, 2016 at 3:51 PM, Dearlove, Christopher (UK) <
>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>
>>>>>> I has to go back to Victoria=E2=80=99s summary here. It says:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2) C creates the RREP. Since it doesnt know if the link to B is
>>>>>> bidirectional, it includes the AckReq (an address to indicate that i=
t
>>>>>> expects to receive a RREP_Ack from B).
>>>>>>
>>>>>>
>>>>>>
>>>>>> That doesn=E2=80=99t actually indicate if that=E2=80=99s C=E2=80=99s=
 address or B=E2=80=99s address
>>>>>> being included. I=E2=80=99d assumed it was C=E2=80=99s address. Your=
 comment makes sense if
>>>>>> it=E2=80=99s B=E2=80=99s address. Reading again, I think you=E2=80=
=99re probably right. But only
>>>>>> probably. Can we confirm that.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> C creates the RREP. The included AckReq address is B's address. The
>>>>> RREP then gets multicast.
>>>>> B receives it, sees that it own address is marked as the AckReq
>>>>> address, and sends an ack unicast back to C.
>>>>> Anyone else who receives the multicast RREP from C does not send the
>>>>> Ack, since the AckReq address does not match any of their interface
>>>>> addresses.
>>>>>
>>>>>
>>>>>> I assume you meant that the RREP (not RREP_Ack) is multicast. There=
=E2=80=99s
>>>>>> a bit of a chicken and egg problem here. We do know how we want to u=
nicast.
>>>>>>
>>>>>
>>>>> The RREP is multicast (when we dont know if the link is
>>>>> bidirectional), the RREP_Ack is always unicast.
>>>>>
>>>>> Kind regards,
>>>>> Vicky.
>>>>>
>>>>>
>>>>>>
>>>>>> *-- *
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *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:* 25 April 2016 15:26
>>>>>> *To:* Thomas Heide Clausen
>>>>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad
>>>>>> Hoc Networks mailing list; Victoria Mercieca
>>>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items=
)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> **** 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
>>>>>> .*
>>>>>>
>>>>>> The address in the RREP_Ack may be required due to the RREP_Ack bein=
g
>>>>>> multicast as there is not yet a verified unicast route installed yet=
.
>>>>>> Going to double check if I'm remembering correctly.
>>>>>>
>>>>>> Justin
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 25, 2016 at 10:18 AM,  wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I must admit that while I have reviewed the protocol several times,
>>>>>> I=E2=80=99ve not been digging that deep into the protocol functionin=
g to catch this
>>>>>> issue of how invasive the protocol operations are when forwarding a
>>>>>> message: there were other =E2=80=9Cmajor=E2=80=9D issues to address =
(and which obscured the
>>>>>> details), so as a first order: thank you Victoria, for having called
>>>>>> attention to this.
>>>>>>
>>>>>>
>>>>>>
>>>>>> To the substance of these emails.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I am afraid that I do not understand the use of inserting validity
>>>>>> TLVs while in-flight, into a message. Actually, I am dubious for bot=
h the
>>>>>> originator inserting this (how can the originator of a message know =
how
>>>>>> =E2=80=9Clatter parts of the path=E2=80=9D will be have=E2=80=9D) ex=
cept if we are talking
>>>>>> duty-cycling of devices and inserting =E2=80=9Cthe remaining time th=
at I am going
>>>>>> to be up before I suspend=E2=80=9D. Intuitively, that would also ass=
ume fairly long
>>>>>> duty cycles =E2=80=9CI am up for tens of seconds=E2=80=9D, which I a=
m not sure are actually
>>>>>> realistic. And, as Chris says in another email, this is trading off =
=E2=80=9Cthe
>>>>>> ability to do security=E2=80=9D for an unknown/untested feature =E2=
=80=94 which I think is
>>>>>> the wrong trade-off.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On he topic of =E2=80=9Cneeding to put an address in=E2=80=9D for RR=
EP-ACK, I must
>>>>>> admit that this seems roundabout. I can see three issues here:
>>>>>>
>>>>>>
>>>>>>
>>>>>> o I am not sure that adding an address vs. a flag may not have to do
>>>>>> with the =E2=80=9Cmultiple interfaces/
>>>>>>
>>>>>> multiple addresses=E2=80=9D discrimination mechanics of the protocol=
? I
>>>>>> haven=E2=80=99t worked it through, though,
>>>>>>
>>>>>> but that would be a guess.
>>>>>>
>>>>>>
>>>>>>
>>>>>> o The end-to-end topology diffusion mechanism should not need to be
>>>>>> concerned with the
>>>>>>
>>>>>> =E2=80=9Cbidirectionally check=E2=80=9D of a local link (in part, as=
 it encumbers
>>>>>> security, but not only).  In short, a
>>>>>>
>>>>>> flag or an address, both are (equally) bad.
>>>>>>
>>>>>>
>>>>>>
>>>>>> o A cleaner mechanism would be a =E2=80=9Chello mechanism=E2=80=9D, =
not necessarily
>>>>>> as NHDP, but a =E2=80=9Cwhen
>>>>>>
>>>>>> forwarding a RREQ/RREP, trigger a 3-way hello exchange, if the link
>>>>>> is estimated to be of a
>>>>>>
>>>>>> type which potentially can be unidirectional=E2=80=9D. There is anot=
her
>>>>>> benefit to doing that, see the end
>>>>>>
>>>>>> of this email.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Either way, I do not like the notion of fusing
>>>>>> metrics-and-link-bidirectionality-detection any more than I like fus=
ing
>>>>>> global-topology-diffusion-and-link-bidirectionality-detection.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The solution all this is, to me, threefold
>>>>>>
>>>>>>
>>>>>>
>>>>>> 1) Factor out the bidirectionally check in a (triggered) neighbour
>>>>>> detection mechanism
>>>>>>
>>>>>> (triggered HELLO message)
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2) Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, since they add c=
omplexity for no
>>>>>> perceivable benefits
>>>>>>
>>>>>>
>>>>>>
>>>>>> 3) Use the security model that we=E2=80=99ve discussed previously, w=
here
>>>>>> (only) the metrics change per hop.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Since we=E2=80=99re discussing bi-directionality of links here, and =
the
>>>>>> necessity of a mechanism for handling these, I want to call attentio=
n to a
>>>>>> related 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 insta=
lled
>>>>>>
>>>>>>    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. Consequ=
ently, the conclusion
>>>>>> 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 =
distinguish
>>>>>> 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 mec=
hanism:
>>>>>> that exchange could, if designed carefully, be used to probe for and=
 convey
>>>>>> metrics information, also.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hope this helps,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK) <
>>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Assuming for the moment that everyone will need an RREP-Ack or won=
=E2=80=99t
>>>>>> (let=E2=80=99s come back to that) why do C and B need to put an addr=
ess in as an
>>>>>> RREQ-Ack request? Why not a flag, because the address will be includ=
ed as
>>>>>> the IP sending address - and we know 5444 is required to pass that o=
n.
>>>>>> (It=E2=80=99s used by NHDP as well.) Then we don=E2=80=99t need to c=
hange the RREP, it will
>>>>>> have a flag set or not, and won=E2=80=99t change (in this regard).
>>>>>>
>>>>>>
>>>>>>
>>>>>> Now let=E2=80=99s consider do we know whether we can set a fixed fla=
g. First
>>>>>> I=E2=80=99d say there are two cases - you=E2=80=99ve got a firm cont=
rol on what=E2=80=99s going on
>>>>>> in your network, or it=E2=80=99s one of unknown parties and behaviou=
r (consistent
>>>>>> with specification). In the former case you only want one setting, f=
or
>>>>>> example no-Ack if running NHDP or your MAC layer tells you about
>>>>>> bidirectionality, Ack otherwise. In the latter case, I think you jus=
t
>>>>>> always want an Ack. So both cases get you to the same place.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Should that not be an acceptable argument (though I think it=E2=80=
=99s good
>>>>>> for where we are - in fact always Ack is close) then at flag is a st=
ep
>>>>>> better, it=E2=80=99s a fixed location to change. However it would be=
 better in that
>>>>>> case if the two things to change (metric and ack flag) were together=
. But
>>>>>> that has its own issues, so I won=E2=80=99t go there.
>>>>>>
>>>>>>
>>>>>>
>>>>>> *--*
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com
>>>>>> ]
>>>>>> *Sent:* 25 April 2016 14:15
>>>>>> *To:* Jiazi YI
>>>>>> *Cc:* Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad
>>>>>> Hoc Networks mailing list
>>>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items=
)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> **** 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
>>>>>> .*
>>>>>>
>>>>>> Hi Jiazi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI  wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christopher (UK) <
>>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>>
>>>>>> With regard to your validity time point, we here have a tradeoff. If
>>>>>> you allow that feature, it significantly impacts on the approach tha=
t was
>>>>>> coming together on as best you can end to end encryption.
>>>>>>
>>>>>>
>>>>>>
>>>>>> So the question is, is this a feature that=E2=80=99s really wanted?
>>>>>> Unfortunately I think we know that the answer to that is, we don=E2=
=80=99t know
>>>>>> because we don=E2=80=99t have any experience. My view would be that =
in the tradeoff
>>>>>> of an untested feature (unless I=E2=80=99m wrong about that) and the=
 security
>>>>>> complication, security wins and drop the feature. If there is some r=
eal
>>>>>> requirement, then there=E2=80=99s a discussion. (Questions like how =
often the
>>>>>> intermediate routers actually have any knowledge - typically links b=
reak
>>>>>> for unexpected rather than expected reasons. Andan intermediate rout=
er
>>>>>> could possibly use a validity time to influence its behaviour.) Note=
 that
>>>>>> dropping the ability of intermediate routers to modify/set still all=
ows
>>>>>> validity times per route to be set at endpoints.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I agree with Chris' concern.
>>>>>>
>>>>>> The ValidityTime is optional, which makes the integrity protection
>>>>>> hard. Furthermore, it gives a potential attack vector: as all the ro=
uters
>>>>>> in a path will take the shortest validityTime, a compromised router =
can set
>>>>>> the the validityTime to a very short value, which will make the rout=
e
>>>>>> installed along the path became invalid (very soon).
>>>>>>
>>>>>>
>>>>>>
>>>>>> On the other hand, I'm not sure this option will give us much help.
>>>>>> Chris mentioned much knowledge intermediate router would have to dec=
ide
>>>>>> this value (and how much sense the value would make).
>>>>>>
>>>>>> Another issue is, a route to a destination might be updated by
>>>>>> different sources. For example, in the network below:
>>>>>>
>>>>>>
>>>>>>
>>>>>> A----B-----C
>>>>>>
>>>>>>
>>>>>>
>>>>>> A first establish a route to B with long validity time. Then A
>>>>>> initiates a route discovery to C. C tends to set a short validity ti=
me,
>>>>>> which will make the route between B and A expire earlier than expect=
ed.
>>>>>>
>>>>>> Is this a problem? Maybe yes, maybe no -- I'm not sure it's
>>>>>> considered or not.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Not sure I follow here.
>>>>>>
>>>>>> Currently, the validity time of the route between A and B would not
>>>>>> affected by a short validity time of a route between A and C. Validi=
ty
>>>>>> times are per-route, and the route A-B and the route A-C are separat=
e.
>>>>>>
>>>>>> If we switched to a validity time per neighbor (so that we can keep
>>>>>> validity time separate from route advertisements) as I mentioned in =
the
>>>>>> email below, then the validity of a route between A and C would be a=
ffected
>>>>>> if there was a short validity time between A and B. But, if B will o=
nly
>>>>>> route for a certain amount of time, then the route between A and C w=
ill of
>>>>>> course be affected. Is it best to know in advance that there's a tim=
e
>>>>>> limit, or just deal with RERRs when they happen?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> With regard to the acknowledgements, the problem (with regard to
>>>>>> security) comes from trying to do two jobs with the same message - e=
nd to
>>>>>> end route advertisement and hop by hop acknowledgement. I understand=
 the
>>>>>> reasons - saving bytes and message types. (I would have to study the
>>>>>> protocol really hard to identify if any message types can be folded
>>>>>> together and recognised by content rather than type efficiently. Thi=
s I do
>>>>>> not expect to do.) Again a tradeoff. This one is in discussion space=
,
>>>>>> though that needs people who understand both sides of the issue, inc=
luding
>>>>>> the details of the bidirectionality mechanism. Of course, as has bee=
n said,
>>>>>> we need one of those.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I haven't finished my review of the latest draft, and I don't get th=
e
>>>>>> necessity of AckReq and the corresponding multicast RREP yet.
>>>>>>
>>>>>> If possible, this "optional" field should be avoided.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> To give an overview of AckReq and RREP:
>>>>>>
>>>>>> Since AODVv2 requires bidirectional links, this is the way to
>>>>>> determine if a link is bidirectional.
>>>>>>
>>>>>> A----B----C
>>>>>>
>>>>>>
>>>>>> 1) A sends RREQ, B forwards it, C receives the RREQ. B and C both
>>>>>> install a route to OrigAddr but they dont yet know if it's valid bec=
ause
>>>>>> they dont know if the link to their next hop is available in the rev=
erse
>>>>>> direction.
>>>>>>
>>>>>> 2) C creates the RREP. Since it doesnt know if the link to B is
>>>>>> bidirectional, it includes the AckReq (an address to indicate that i=
t
>>>>>> expects to receive a RREP_Ack from B).
>>>>>>
>>>>>> 3) B receives the RREP, installs a route to TargAddr and marks it as
>>>>>> valid, since it knows the link to C is bidirectional, because the RR=
EQ went
>>>>>> in one direction and the RREP came in the other. B also sends the RR=
EP_Ack
>>>>>> to C and forwards the RREP to A (and might change the message to ind=
icate
>>>>>> its own AckReq - ie that it requires an ack from A).
>>>>>>
>>>>>> 4) C receives the RREP_Ack from B, and therefore knows that B
>>>>>> received the RREP, therefore the link is bidirectional. C can then m=
ark its
>>>>>> route to OrigAddr as valid.
>>>>>>
>>>>>> 5) Similarly, A receives the RREP, installs the route to TargAddr an=
d
>>>>>> sends an RREP_Ack to B.
>>>>>>
>>>>>> 6) B receives the RREP_Ack and marks its route to OrigAddr as valid.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Alternatively, in step 2, if C knows the link to B is bidirectional
>>>>>> (perhaps from some earlier route discovery), it doesnt need to put t=
he
>>>>>> AckReq in the RREP. Then in step 3, since B doesnt know if the link =
to A is
>>>>>> bidirectional, it changes the message to add the AckReq address, in =
order
>>>>>> to get an RREP_Ack from A.
>>>>>>
>>>>>> If we want to avoid changing the message, we'll need to look at
>>>>>> forwarding the RREP as-is, and creating a second message to solicit =
an
>>>>>> RREP_Ack, in order to verify that the link is bidirectional before m=
arking
>>>>>> the route to OrigAddr as valid.
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Victoria.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> regards
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jiazi
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *--*
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>>> Intelligence Laboratories *
>>>>>> *___________________________________________________________________=
_______
>>>>>> *
>>>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* Victoria Mercieca [mailto:vmercieca0@gmail.com]
>>>>>> *Sent:* 23 April 2016 10:55
>>>>>> *To:* Christopher Dearlove
>>>>>> *Cc:* ietf@thomasclausen.org; Dearlove, Christopher (UK); Mobile Ad
>>>>>> Hoc Networks mailing list
>>>>>>
>>>>>>
>>>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items=
)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> **** 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
>>>>>> .*
>>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>>
>>>>>>
>>>>>> These have both been in the draft in some form since before I got
>>>>>> involved... but I'll do my best to explain.
>>>>>>
>>>>>>
>>>>>>
>>>>>> - For Validity Time, its a way to advertise that you would only
>>>>>> support the route contained in the message for a certain period of t=
ime.
>>>>>> The originator might use this, but the draft was written to allow an=
y
>>>>>> intermediate node to be able to add it or update it too. The route c=
reated
>>>>>> in the Local Route Set has an expiration time associated with it, ba=
sed on
>>>>>> the received validity time.
>>>>>>
>>>>>> - For the AckReq address, its so that you can add into a RREP a
>>>>>> request for an acknowledgement, so that you don't have to have a dif=
ferent
>>>>>> message type altogether for working out whether links to neighbors a=
re
>>>>>> bidirectional, and also, since you only care about bidirectionality =
on
>>>>>> routes that are being set up, you dont need to constantly monitor al=
l
>>>>>> neighbors.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> In order to avoid the potential AckReq-related changes to each
>>>>>> message, maybe we do need to introduce a different message specifica=
lly for
>>>>>> this. We could maybe use RREP_Ack to both request and acknowledge? I=
t means
>>>>>> an extra message of control traffic that needs to be sent, maybe one=
 extra
>>>>>> message per hop on the path of a RREP, but it could still be limited=
 to
>>>>>> neighbors which have participated in the route discovery rather than
>>>>>> monitoring all neighbors at all times.
>>>>>>
>>>>>>
>>>>>>
>>>>>> This message could maybe also include "I'm happy to route anywhere
>>>>>> for a certain amount of time", sort of like willingness in OLSR/OLSR=
v2. So
>>>>>> instead of having a validity time per route, its a validity time per
>>>>>> neighbor. Then, for RREQ and RREP, only the metric value would chang=
e in
>>>>>> transit, as discussed. However, that leads to some issues with decid=
ing
>>>>>> what a route's expiration time is. You might know how long the next =
hop
>>>>>> router is valid for, but what if a router beyond that, which was als=
o part
>>>>>> of the route, had a lower validity time? You couldn't determine the =
real
>>>>>> validity time. Do we remove the route expiration time altogether to =
avoid
>>>>>> this issue? In which case, we would have to rely on RERR messages be=
ing
>>>>>> sent for routes which become invalid when the neighbor's validity ti=
me has
>>>>>> expired? So neighbor validity time expiration is treated the same as=
 a link
>>>>>> break.
>>>>>>
>>>>>>
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Victoria.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlove <
>>>>>> chris@mnemosyne.demon.co.uk> wrote:
>>>>>>
>>>>>> Pretty much all of the discussion has been assuming only a metric
>>>>>> value change. With multiple things changing many of the ideas go out=
 of the
>>>>>> window. That reinforces the point about not making specifications no=
w that
>>>>>> might turn out to be wrong for ICVs.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ignoring how this misunderstanding happened, I'll start by asking
>>>>>> why. Metric changing I understand. Why the other two? (there's a par=
tial
>>>>>> explanation of one). What alternatives have people implemented in
>>>>>> comparable protocols?
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Christopher Dearlove
>>>>>>
>>>>>> christopher.dearlove@gmail.com (iPhone)
>>>>>>
>>>>>> chris@mnemosyne.demon.co.uk (home)
>>>>>>
>>>>>>
>>>>>> On 23 Apr 2016, at 00:26, Victoria Mercieca 
>>>>>> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Continued in this thread because the other one seems to be more abou=
t
>>>>>> TLV types and metric type numbers, whereas this is about
>>>>>> regeneration/forwarding.
>>>>>>
>>>>>>
>>>>>>
>>>>>> To recap, in the current draft, there are 3 things that might change
>>>>>> at each hop:
>>>>>> - the metric value (happens in RREQ and RREP),
>>>>>> - adding/changing Validity Time using the Validity Time TLV (can
>>>>>> happen in RREQ and RREP),
>>>>>> - adding an address (and corresponding value in the AddressType TLV
>>>>>> to indicate how to interpret the address) to indicate the address fr=
om
>>>>>> which an RREP_Ack is expected, to accomplish the bidirectionality ch=
eck
>>>>>> (can happen in RREP).
>>>>>>
>>>>>> If we define a certain portion of the message as immutable and
>>>>>> include the ICV to verify that part, end to end:
>>>>>> - The metric value would be excluded from the ICV since it needs
>>>>>> changing at each hop.
>>>>>> - Would adding a Validity Time TLV at an intermediate hop be
>>>>>> acceptable? The whole TLV could be removed in order to calculate the=
 ICV?
>>>>>>
>>>>>> - Would adding an address cause issues for the ICV, because it's in
>>>>>> the address block? Could the rule be "if it contains an AckReq addre=
ss,
>>>>>> remove it (and the corresponding value in the AddressType TLV), befo=
re
>>>>>> checking the ICV", is that OK? Or would we need to avoid touching th=
e
>>>>>> ICV'ed part of the message altogether, maybe put the AckReq address =
in a
>>>>>> separate Address Block, with an extra AddressType TLV following that
>>>>>> address block? Is there a way to accomplish this?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Also, to be thorough, do we need to consider RERR messages while we
>>>>>> discuss regeneration vs forwarding?
>>>>>>
>>>>>> - RERR (sent when a link breaks) is a way of saying "I've lost my
>>>>>> route so I'm telling others" and "you were my next hop, so now I've =
also
>>>>>> lost my route, I'll tell others", etc. It's going to be tailored at =
each
>>>>>> step to include the relevant routes that got deleted, it's not one m=
essage
>>>>>> being sent end-to-end like RREQ and RREP are.
>>>>>>
>>>>>> - However, RERR (sent when a source of traffic is sending data on a
>>>>>> route which comes through you, and you want to tell the Packet Sourc=
e's
>>>>>> router to delete the route) could be seen as an end-to-end message w=
hich
>>>>>> all intermediate routers learn from, similar to RREQ and RREP. It re=
ports
>>>>>> one route, and doesn't need changing at intermediate hops, so could =
be
>>>>>> protected with ICV.
>>>>>>
>>>>>> - Would it be OK to only require a message ICV if a PktSource addres=
s
>>>>>> was included, i.e. when the message needs to go via a number of
>>>>>> intermediate hops to PktSource's router? All other RERRs are intende=
d to be
>>>>>> one-hop messages, which may in turn prompt other one-hop messages, e=
tc...,
>>>>>> and a packet ICV might be more appropriate?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Victoria.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 17, 2016 at 5:26 PM,  wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK) <
>>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, I meant AODVv2, thanks for the catch.
>>>>>>
>>>>>>
>>>>>>
>>>>>> So is your (Thomas) proposed base specification a hop count only
>>>>>> metric?
>>>>>>
>>>>>>
>>>>>>
>>>>>> No, the would be silly as base specification, given that hop count
>>>>>> mostly is useless.
>>>>>>
>>>>>>
>>>>>>
>>>>>> As base specification I would simply say =E2=80=9CInclude a Metric T=
ype
>>>>>> Message TLV with a value field, and a 7182 Message TLV & Timestamp=
=E2=80=9D as we
>>>>>> do in OLSRv2 (with the appropriate verbiage as to generation and
>>>>>> processing).
>>>>>>
>>>>>>
>>>>>>
>>>>>> With the message generated by the originator of the RREQ/RREP and
>>>>>> *not* deconstructed/reconstructed/reordered (as is the risk with
>>>>>> =E2=80=9Cregeneration) allows knowing that it would be *only* that m=
etric field
>>>>>> being modified (other than hop count/limit) for when eventually writ=
ing up
>>>>>> the extension.
>>>>>>
>>>>>>
>>>>>>
>>>>>> (Actually doesn=E2=80=99t the current specification only define hop =
count, or
>>>>>> has that changed in latest draft?)
>>>>>>
>>>>>>
>>>>>>
>>>>>> No. That is one of the issues I raise in my original. For some
>>>>>> reason, it cites RFC6551, which is a ROLL document and which has in =
its
>>>>>> abstract that:
>>>>>>
>>>>>>
>>>>>>
>>>>>>    Low-Power and Lossy Networks (LLNs) have unique characteristics
>>>>>>
>>>>>>    compared with traditional wired and ad hoc networks that require =
the
>>>>>>
>>>>>>    specification of new routing metrics and constraints.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I.e. this document cites a metric document which clearly claims to b=
e
>>>>>> inapplicable in ad hoc networks. I note that this is another thing I=
=E2=80=99ve
>>>>>> raised for years without seeing it attempted resolved.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *--*
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>>> Intelligence Laboratories *
>>>>>> *___________________________________________________________________=
_______
>>>>>> *
>>>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>>>>>> ]
>>>>>> *Sent:* 17 March 2016 17:10
>>>>>> *To:* Dearlove, Christopher (UK)
>>>>>> *Cc:* Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>>>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items=
)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> **** 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 17 Mar 2016, at 18:04, Dearlove, Christopher (UK) <
>>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> OK, so we have a message that mutates by:
>>>>>>
>>>>>> - Modifying hop count/limit.
>>>>>>
>>>>>> - Modifying a metric value.
>>>>>>
>>>>>> Anything else?
>>>>>>
>>>>>>
>>>>>>
>>>>>> As mutating (other than hop count/limit) messages aren=E2=80=99t cov=
ered by
>>>>>> 5444 or any derivative document (but only recommended against, not b=
anned)
>>>>>> that you may need to make the message otherwise immutable (no
>>>>>> deconstruction and rebuilding, other than guaranteed unchanging) tha=
t would
>>>>>> have to be specified by AODVv2. (Easy to say, but needs saying.)
>>>>>>
>>>>>>
>>>>>>
>>>>>> With you so far.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Then that information is not in a guaranteed fixed location given by
>>>>>> a simple offset. So any signature algorithm that finds it and ignore=
s it or
>>>>>> aggregates on it is specific to OLSRv2.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Surely you mean AODVv2
>>>>>>
>>>>>>
>>>>>>
>>>>>> So standard 7182 ICVs don=E2=80=99t do the job, you would need an AO=
DVv2
>>>>>> specialised variant. Which is the sort of thing that the message spe=
cific
>>>>>> TLV space is there for, I=E2=80=99d be strongly against a =E2=80=9Cb=
ut ignore the value of
>>>>>> this specific TLV should it occur=E2=80=9D being in the general spac=
e. However it
>>>>>> can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is lik=
e that TLV,
>>>>>> except if an X TLV is present, set its value field to zero=E2=80=9D)=
.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Messy, but could work.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Not that messy, actually, although clearly not as nice as =E2=80=9Cf=
ixed
>>>>>> offset=E2=80=9D.
>>>>>>
>>>>>>
>>>>>>
>>>>>> That said, I am arguing for the base spec being:
>>>>>>
>>>>>>
>>>>>>
>>>>>>             =E2=80=9Cmake the message otherwise immutable (no decons=
truction
>>>>>> and rebuilding, other
>>>>>>
>>>>>>              than guaranteed unchanging)=E2=80=9D which is afforded =
by
>>>>>> forwarding
>>>>>>
>>>>>>
>>>>>>
>>>>>>                                     +
>>>>>>
>>>>>>
>>>>>>
>>>>>>             RFC7182 Timestamps and ICVs.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                                     +
>>>>>>
>>>>>>
>>>>>>
>>>>>>             RFC7183 style text bringing it all together.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The =E2=80=9Caggregated signatures around mutable field=E2=80=9D wou=
ld very be an
>>>>>> experimental extension.
>>>>>>
>>>>>>
>>>>>>
>>>>>> What I object to is, if the base spec specifically renders such
>>>>>> extensions impossible
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *--*
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>>> Intelligence Laboratories *
>>>>>> *___________________________________________________________________=
_______
>>>>>> *
>>>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de
>>>>>> ]
>>>>>> *Sent:* 17 March 2016 16:48
>>>>>> *To:* Dearlove, Christopher (UK)
>>>>>> *Cc:* ietf@thomasclausen.org; Mobile Ad Hoc Networks mailing list
>>>>>> *Subject:* Re: [manet] Message integrity and message mutability (was
>>>>>> RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items=
)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> **** 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
>>>>>> .*
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher (UK) <
>>>>>> chris.dearlove@baesystems.com>:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Good point about whether you just pass on one cost or a set of costs=
.
>>>>>> As I said, not looked at details - I will, when time permits. One co=
st is
>>>>>> much easier, and yes, it reduces the fixed size aggregated signature=
s
>>>>>> problem to =E2=80=9Cjust=E2=80=9D one of computational load.
>>>>>>
>>>>>>
>>>>>>
>>>>>> For the record, Thomas=E2=80=99 understanding is correct; the cost i=
s one
>>>>>> aggregated value.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Lotte Steenrbink
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *--*
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>>> Intelligence Laboratories *
>>>>>> *___________________________________________________________________=
_______
>>>>>> *
>>>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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:* ietf@thomasclausen.org [mailto:ietf@thomasclausen.org
>>>>>> ]
>>>>>> *Sent:* 17 March 2016 16:38
>>>>>> *To:* Dearlove, Christopher (UK)
>>>>>> *Cc:* Mobile Ad Hoc Networks mailing list
>>>>>> *Subject:* Re: Message integrity and message mutability (was RE:
>>>>>> [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket I=
tems)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> **** 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 17 Mar 2016, at 17:30, Dearlove, Christopher (UK) <
>>>>>> chris.dearlove@baesystems.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> I appreciate Thomas=E2=80=99s comments about the limitations of mess=
age
>>>>>> regeneration, but I would be a bit less absolute.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The issues over end to end authentication and more advanced
>>>>>> signatures are valid. I need to read the given reference on aggregat=
e
>>>>>> signatures to increase my knowledge (thanks for it), but my understa=
nding
>>>>>> of the possibilities in this field may offer a solution to the probl=
em, but
>>>>>> with some other issues (possibly including a new type of TLV).
>>>>>>
>>>>>>
>>>>>>
>>>>>> But the hop count/limit point I don=E2=80=99t fully agree with, you =
can
>>>>>> regenerate with an incremented/decremented count/limit, which leaves=
 the
>>>>>> ability to prevent messages propagating indefinitely, including expa=
nding
>>>>>> ring searches, and retains the ability to use RFC 5497 interval and
>>>>>> validity times that might be useful with an expanding ring search (o=
r might
>>>>>> not).
>>>>>>
>>>>>>
>>>>>>
>>>>>> But the key issue is that AODVv2 wants to accumulate metrics. I stil=
l
>>>>>> haven=E2=80=99t got to the bottom of many details here, but let=E2=
=80=99s for the moment
>>>>>> just consider that conceptually.
>>>>>>
>>>>>>
>>>>>>
>>>>>> It=E2=80=99s hard to handle end to end. Charlie=E2=80=99s draft atte=
mpts to do an end
>>>>>> to end of some information, not this information. I=E2=80=99m not su=
re if that=E2=80=99s
>>>>>> useful (and the specialised format is better avoided if possible). O=
ther
>>>>>> approaches are hop by hop (might as well use packet signatures) and =
shared
>>>>>> key (might as well go hop by hop). Pairwise signatures for each pair=
 of
>>>>>> routers I=E2=80=99m discounting as scaling terribly. In the interest=
s of
>>>>>> completeness let=E2=80=99s mention not accumulating metrics, which p=
uts us back to
>>>>>> hop count and that=E2=80=99s not ideal either.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I don=E2=80=99t think there is an ideal solution. (I like ideas I=E2=
=80=99ve seen
>>>>>> about aggregating, but that has some issues of its own, even apart f=
rom
>>>>>> computational load.) I=E2=80=99d love to be proved wrong - someone w=
ith the perfect
>>>>>> solution to come along.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Which means that either we make an arbitrary choice - which will be
>>>>>> disagreed with, but needs discussing first - or create something fle=
xible.
>>>>>> Unfortunately flexible in that regard constrains in others, e.g. som=
e
>>>>>> (many? most?) aggregating signatures need fixed data sizes (which we=
 can do
>>>>>> by defining a TLV that =E2=80=9Cfills up=E2=80=9D with hop count, bu=
t that has a cost too).
>>>>>>
>>>>>>
>>>>>>
>>>>>> I have been told by people much more well versed in this than I in
>>>>>> cryptology, that the correct answer is =E2=80=9Csome=E2=80=9D.
>>>>>>
>>>>>>
>>>>>>
>>>>>> That said, "AODVv2 wants to accumulate metrics=E2=80=9D =E2=80=94 do=
es that mean that
>>>>>> the message grows as it is being forwarded, and that the recipient o=
f a
>>>>>> RREQ/RREP will know the individual costs of each path segment? My
>>>>>> understanding is, that the recipient will get =E2=80=9Cthe sum the c=
osts of each
>>>>>> path segment=E2=80=9D which should be fitting within a fixed size?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sorry, no answers, just comments. And I=E2=80=99m not addressing Tho=
mas=E2=80=99s
>>>>>> later points here.
>>>>>>
>>>>>>
>>>>>>
>>>>>> *--*
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>>>>> Intelligence Laboratories *
>>>>>> *___________________________________________________________________=
_______
>>>>>> *
>>>>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *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 *ietf@thomasclausen.org
>>>>>> *Sent:* 17 March 2016 16:00
>>>>>> *To:* Mobile Ad Hoc Networks mailing list
>>>>>> *Subject:* [manet] draft-ietf-manet-aodvv2-13 review - a couple of
>>>>>> big ticket Items
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> **** 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Apologies for not having gotten this done sooner - day-job leaving
>>>>>> few spare cycles.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I=E2=80=99ve previously offered reviews and comments, and some of th=
ose have
>>>>>> been addressed in the latest I-D =E2=80=94 others have not, but shou=
ld be. I recall
>>>>>> that there was some mail attempting to rebut parts of the review, an=
d I
>>>>>> will dig it out and reply to that.
>>>>>>
>>>>>>
>>>>>>
>>>>>> With that being said, I have reviewed the latest version of the
>>>>>> document, and full details will be forthcoming. There=E2=80=99re a c=
ouple of
>>>>>> big-ticket/architectural items that I want to address up front, as I
>>>>>> believe that before we have those hammered out, it will be useless t=
o go
>>>>>> into details. Note, I do not claim that this is an exhaustive list o=
f =E2=80=9Cbig
>>>>>> ticket items=E2=80=9D, but that=E2=80=99s as far as I have gotten in=
 thinking this through.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I also bring these up as they are items that have been brought up
>>>>>> repeatedly over the past years, but not resolved nor discussed.
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Loops*
>>>>>>
>>>>>> Just to bring this out: I share Chris=E2=80=99 worry about conflicti=
ng and
>>>>>> concurrent statements from the authors on =E2=80=9CThere are no loop=
s possible=E2=80=9D and
>>>>>> =E2=80=9CWe need to fix two situations where loops can occur=E2=80=
=9D and =E2=80=9Cwe are still
>>>>>> investigating some loop conditions=E2=80=9D
>>>>>>
>>>>>>
>>>>>>
>>>>>> I particularly worry that this is not a discussion had in public, bu=
t
>>>>>> apparently in some other forum=E2=80=A6
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Intermediate Route Replies, and all of section 10*
>>>>>>
>>>>>> Section 10 contains a set of =E2=80=9Cvaguely specified extensions=
=E2=80=9D, which is
>>>>>> incoherent with the intended status indicated for this document.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Specifically, and this is not unrelated to the point about loops
>>>>>> above, intermediate RREPs (section 10.3) are a potential source for =
loops.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Expanding Ring Multicast (section 10.1) is not documented in a way
>>>>>> that can be implemented (and also, see =E2=80=9CForwarding-vs-regene=
ration=E2=80=9D below,
>>>>>> it is in the present form of this protocol impossible), etc.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Forwarding-vs-regeneration*
>>>>>>
>>>>>> Recent exchanges on the list made me understand that protocol contro=
l
>>>>>> messages are *not* forwarded, but are consumed at each hop, then a n=
ew
>>>>>> message with (almost-but-not-quite) the same content is generated an=
d
>>>>>> transmitted.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I have thought some more on this (& read some of the exchanges on th=
e
>>>>>> list on this topic by Chris, Ulrich, and others), and I am convinced=
 that
>>>>>> this is not the right way to go, *at least* for the following
>>>>>> reasons:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             o          *It renders the hop-limit/hop-count fields in
>>>>>> the RFC5444 message header useless.*
>>>>>>
>>>>>>                         This would not be bad if the functionality
>>>>>> offered by those fields was not useful
>>>>>>
>>>>>>                         =E2=80=94 sadly, it is. For example, for sco=
pe
>>>>>> limited flooding (expanding ring search, and
>>>>>>
>>>>>>                         such) which may be of interest, and which
>>>>>> require hop-limit.
>>>>>>
>>>>>>                         A hop-count field may also provide a =E2=80=
=9Ccheap=E2=80=9D
>>>>>> (in terms of overhead) additional piece
>>>>>>
>>>>>>                         of information to use conjunctively with a
>>>>>> =E2=80=9Creal=E2=80=9D metric.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         The only practical solution would be to
>>>>>> re-introduce these functions by way of inserting a
>>>>>>
>>>>>>                         MessageTLV =E2=80=94 which (i) is not specif=
ied in
>>>>>> this document, and (ii) which would just
>>>>>>
>>>>>>                         serve to render messages bigger than strictl=
y
>>>>>> needed.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         Scope limited flooding  does seem to be a
>>>>>> necessary requirement, if for no
>>>>>>
>>>>>>                         other reason than to prevent information fro=
m
>>>>>> =E2=80=9Ccirculating forever in the network=E2=80=9D.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             o          *It makes end-to-end authentication
>>>>>> unnecessarily hard.*
>>>>>>
>>>>>>                         I think Chris called this out already, but i=
t
>>>>>> bears repeating: S generates a message
>>>>>>
>>>>>>                         (say, a RREQ), and includes an ICV calculate=
d
>>>>>> over the content of the message.
>>>>>>
>>>>>>                         For any recipient to be able to validate the
>>>>>> ICV, the message has to be exactly
>>>>>>
>>>>>>                         the same =E2=80=94 not just in content, but =
in
>>>>>> structure =E2=80=94 as what was generated.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         =E2=80=9CRegenerating=E2=80=9D rather than =
=E2=80=9Cforwarding=E2=80=9D
>>>>>> messages means, that the intermediate
>>>>>>
>>>>>>                         router =E2=80=9Cregenerating=E2=80=9D the RR=
EQ may chose a
>>>>>> different structure (e.g., include TLVs
>>>>>>
>>>>>>                         in a different order).
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         The proposal from
>>>>>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
>>>>>>
>>>>>>                         is to add constraints on (i) the set of
>>>>>> elements to include in a signature and (ii) the
>>>>>>
>>>>>>                         order of these elements.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         One problem with that approach is (i): if an
>>>>>> extension adds a message TLV, or an
>>>>>>
>>>>>>                         Address TLV, to a message, then that will no=
t
>>>>>> be =E2=80=9Ccovered=E2=80=9D by the proposed e2esec TLV.
>>>>>>
>>>>>>                         Rather for *each* extension developed, an
>>>>>> =E2=80=9Cupdates e2esec=E2=80=9D clause needs to be done.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         I=E2=80=99d say that this approach would be =
prone to
>>>>>> errors =E2=80=94 and add entropy to the process
>>>>>>
>>>>>>                         of designing protocol extensions. The
>>>>>> alternative, a message being generated by the
>>>>>>
>>>>>>                         source and *forwarded* (as we do in OLSRv2,
>>>>>> for example) would allow ICV TLVs
>>>>>>
>>>>>>                         (even, allow reuse of those specified for
>>>>>> OLSRv2) for covering a message and
>>>>>>
>>>>>>                         extensions.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         =E2=80=9CBut what about the metrics value wh=
ich will
>>>>>> change on each hop=E2=80=9D, you may say?
>>>>>>
>>>>>>                         Fortunately, that is relatively easy to
>>>>>> handle: simply zero out the value of that TLV when
>>>>>>
>>>>>>                         generating or verifying the ICV MessageTLV.
>>>>>> And use Packet-TLVs for hop-by-hop
>>>>>>
>>>>>>                         authentication, if needed (but, see below).
>>>>>>
>>>>>>
>>>>>>
>>>>>>             o          *It prevents the use of more clever/advanced
>>>>>> signature schemes/ICVs*
>>>>>>
>>>>>>                         Aggregate signature algorithms (
>>>>>> https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
>>>>>>
>>>>>>                         exist, and an interesting use-case can be
>>>>>> found in also reactive protocols, allowing verifying
>>>>>>
>>>>>>                         not =E2=80=9Cjust=E2=80=9D the end points, b=
ut also the
>>>>>> intermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=
=9D
>>>>>>
>>>>>>                         discussed above, or something smarter).
>>>>>>
>>>>>>                         Regeneration of messages, rather than
>>>>>> forwarding, renders that impossible (or, if used,
>>>>>>
>>>>>>                         updating to
>>>>>> https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
>>>>>>
>>>>>>
>>>>>>
>>>>>> There are other reasons, but the above are those that jump at me as
>>>>>> immediate show-stoppers.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I do honestly not see what possible benefit there is from
>>>>>> =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inconv=
eniences, and security is not
>>>>>> the least of these. Insisting on =E2=80=9Cregeneration=E2=80=9D requ=
ires development of
>>>>>> =E2=80=9Cnon-general workarounds=E2=80=9D as pointed out above.
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Security Considerations*
>>>>>>
>>>>>> This is an always thorny subject. When OLSRv2 was going through the
>>>>>> process we got a thorough education in how little we knew about secu=
rity
>>>>>> from the SEC-ADs, and had to spend about a year or so developing RFC=
7183.
>>>>>> The bottom line is, that this protocol needs its =E2=80=9CRFC7183  e=
quivalent=E2=80=9D,
>>>>>> either as part of the main document, or as an independent document.
>>>>>> currently, that is not the case.
>>>>>>
>>>>>>
>>>>>>
>>>>>> A minima, looking at BCP72 and BCP107 =E2=80=94 taking inspiration f=
rom
>>>>>> RFC7183 might be aw good idea, as that was the most recent that went
>>>>>> through the SEC AD. Regardless of how, however, a =E2=80=9Cmandatory=
 to implement=E2=80=9D
>>>>>> security mechanism most be specified (I think the right term was =E2=
=80=9CMUST
>>>>>> implement, SHOULD use=E2=80=9D), in sufficient detail to ensure inte=
roperable
>>>>>> implementations.
>>>>>>
>>>>>>
>>>>>>
>>>>>> As an example, both [RFC6130] and [RFC7181] set out that that:
>>>>>>
>>>>>>
>>>>>>
>>>>>>       On receiving a ... message, a router MUST first check if the
>>>>>>
>>>>>>       message is invalid for processing by this router
>>>>>>
>>>>>>
>>>>>>
>>>>>> and then proceed to give a number of conditions that, each, will lea=
d
>>>>>> to a rejection of the message as "badly formed and therefore invalid=
 for
>>>>>> processing=E2=80=9D =E2=80=94 a list which RFC7183 then amended. Tha=
t gave a =E2=80=9Chook=E2=80=9D for
>>>>>> RFC7183 for inserting =E2=80=9Crejection=E2=80=9D. Idem for message =
generation.
>>>>>>
>>>>>>
>>>>>>
>>>>>> If I was to do RFC7181/RFC6130 today, I would include that directly
>>>>>> into the protocol specifications. It turned out to be more overhead =
(and
>>>>>> slow down publication anyways) to do it as separate documents.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Secondly, we need to be a lot more rigid in terms of what ICVs,
>>>>>> Timestamps, etc. are added/removed, and what that brings.
>>>>>>
>>>>>>
>>>>>>
>>>>>> For example (with the assumption that messages are *forwarded* and
>>>>>> *not* regenerated), this could be one option:
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         o          When a RREQ, RREP message is
>>>>>> generated, add an ICV Message TLV, which is calculated 
>>>>>>
>>>>>>                                      =E2=80=A6(take inspiration from=
 RFC7183
>>>>>> here)
>>>>>>
>>>>>>
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> [Message clipped]
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> ********************************************************************
>>>>>> 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
>>>>
>>>>
>>>
>>
>

--94eb2c1228d0ef1bef05318e654b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Jiazi,

Thanks for your response. So =
you think we could change back to sending RREP by unicast (letting an imple=
mentation handle whether this requires a route to the neighbor to be instal=
led temporarily)? We would have to also send a separate message to request =
an acknowledgement, but this could also be unicast and could therefore pote=
ntially be sent in the same RFC5444 packet.=C2=A0

=
Anyone have any objections?

Kind regards,
Victoria.

On Wed, Apr 27, 2016 at 11:34 PM, Jiazi YI <ietf@jiaziyi.com><=
/span> wrote:


On Wed, Apr 27, 2016 at=
 10:59 PM, Victoria Mercieca <vmercieca0@gmail.com> wrote=
:
Just quickly, on this =
note, if we remove the AckReq from the RREP itself, then because the RREP i=
s multicast, there might be multiple receivers, but there's no way for =
them to determine if they were the intended next hop, so they would all hav=
e to forward the RREP. The RREP might then go by multiple routes to get to =
RREQ_Gen. This assumes all receivers of the RREP have a route to OrigAddr a=
nyway (current rules say if they didnt, they would send a RERR back to RREP=
_Gen).

So, do we have to install a route to the neighbou=
r, then unicast the RREP and create a separate message with an AckReq, then=
 if no acknowledgement is received, blacklist the neighbor and remove the r=
oute to the neighbor? along with the route to OrigAddr which is not availab=
le because the link is not bidirectional...?
<=
br>
My opinion is, if we have a neighbor address and the interfac=
e through which the neighbor can be (possibly) reached, then we can send an=
 unicast to it.=C2=A0
The others are more implementation details:=
 for example, if a route to the neighbor is required, we can setup a tempor=
ary route entry to the neighbor, and remove it after the unicast is finishe=
d. As it's more implementation, I don't think it's necessary to=
 go to the specification.=C2=A0

Another related qu=
estion: when I was reading the specification, a router only sets up routes =
to the source/destination, but not to its direct neighbors?=C2=A0

best

Jiazi
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

Reg=
ards,
Victoria.

On Mon, Apr 25, 2016 at 4:34 PM, Justin Dean =
<bebemaster@gm=
ail.com> wrote:
On Mon, Apr 25, 2016 at 11:29=
 AM, Jiazi YI <ietf@jiaziyi.com> wrote:
=

Hi,=C2=A0

Maybe I missed a bit here:=C2=
=A0

If only the desired receiver of the multicast =
RREP (carrying a destination address) can reply to the multicast RREP, why =
not using unicast directly?

Bec=
ause the link isn't yet known to be bi-directional and a unicast route =
can't be installed yet.

Justin
=C2=
=A0
best
<=
br>
Jiazi

On Mon, Apr 25, 2016 at 4:59 PM, Victoria Mercieca =
<vmercieca0@gm=
ail.com> wrote:
Hi Chris=
,


On Mon, =
Apr 25, 2016 at 3:51 PM, Dearlove, Christopher (UK) <<=
a href=3D"mailto:chris.dearlove@baesystems.com" target=3D"_blank">chris.dea=
rlove@baesystems.com> wrote:











I has to go back to Victoria=E2=80=99s summa=
ry here. It says:


=C2=A0


2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).


=C2=A0


That doesn=E2=80=99t actually indicate if th=
at=E2=80=99s C=E2=80=99s address or B=E2=80=99s address being included. I=
=E2=80=99d assumed it was C=E2=80=99s address. Your comment makes sense if =
it=E2=80=99s B=E2=80=99s address.
 Reading again, I think you=E2=80=99re probably right. But only probably. C=
an we confirm that.


=C2=A0

C creates the RREP. The included AckReq address is=
 B's address. The RREP then gets multicast.
B receives it=
, sees that it own address is marked as the AckReq address, and sends an ac=
k unicast back to C. 
Anyone else who receives the multicast RREP from C=
 does not send the Ack, since the AckReq address does not match any of thei=
r interface addresses.
=C2=A0
<=
span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73=
,125)">


I assume you meant that the RREP (not RREP_A=
ck) is multicast. There=E2=80=99s a bit of a chicken and egg problem here. =
We do know how we want to unicast.
=
=C2=A0
The RREP is multicast (when we dont know if the link is bi=
directional), the RREP_Ack is always unicast. 

Kind regar=
ds,
Vicky.

=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:
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 Intelligence 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: 25 April 2016 15:26

To: Thomas Heide Clausen

Cc: Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad Hoc =
Networks mailing list; Victoria Mercieca

Subject: Re: [manet] Message integrity and message mutability (was R=
E: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)=



=C2=A0




=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether =
you should click on any links, open any attachments or reply.
For information regarding <=
/span>
Red Flags that you can look out=
 for in emails you receive,
 click 
here.

If you feel the email is su=
spicious, please follow

this process.








The address in the RREP_Ack may be required due to t=
he RREP_Ack being multicast as there is not yet a verified unicast route in=
stalled yet.=C2=A0 Going to double check if I'm remembering correctly.=
=C2=A0



Justin






=C2=A0




On Mon, Apr 25, 2016 at 10:18 AM, <ietf@thomasclausen.org>=
; wrote:




Hi,




=C2=A0






I must admit that while I have reviewed the protocol=
 several times, I=E2=80=99ve not been digging that deep into the protocol f=
unctioning to catch this issue of how invasive the protocol operations are =
when forwarding a message: there were other
 =E2=80=9Cmajor=E2=80=9D issues to address (and which obscured the details)=
, so as a first order: thank you Victoria, for having called attention to t=
his.






=C2=A0






To the substance of these emails.






=C2=A0






I am afraid that I do not understand the use of inse=
rting validity TLVs while in-flight, into a message. Actually, I am dubious=
 for both the originator inserting this (how can the originator of a messag=
e know how =E2=80=9Clatter parts of the path=E2=80=9D
 will be have=E2=80=9D) except if we are talking duty-cycling of devices an=
d inserting =E2=80=9Cthe remaining time that I am going to be up before I s=
uspend=E2=80=9D. Intuitively, that would also assume fairly long duty cycle=
s =E2=80=9CI am up for tens of seconds=E2=80=9D, which I am not sure are
 actually realistic. And, as Chris says in another email, this is trading o=
ff =E2=80=9Cthe ability to do security=E2=80=9D for an unknown/untested fea=
ture =E2=80=94 which I think is the wrong trade-off.






=C2=A0






On he topic of =E2=80=9Cneeding to put an address in=
=E2=80=9D for RREP-ACK, I must admit that this seems roundabout. I can see =
three issues here:






=C2=A0






o I am not sure that adding an address vs. a flag ma=
y not have to do with the =E2=80=9Cmultiple interfaces/






multiple addresses=E2=80=9D discrimination mechanics=
 of the protocol? I haven=E2=80=99t worked it through, though,=C2=A0=







but that would be a guess.






=C2=A0






o The end-to-end topology diffusion mechanism should=
 not need to be concerned with the=C2=A0






=E2=80=9Cbidirectionally check=E2=80=9D of a local l=
ink (in part, as it encumbers security, but not only).=C2=A0 In short, a=







flag or an address, both are (equally) bad.






=C2=A0






o A cleaner mechanism would be a =E2=80=9Chello mech=
anism=E2=80=9D, not necessarily as NHDP, but a =E2=80=9Cwhen=C2=A0






forwarding a RREQ/RREP, trigger a 3-way hello exchan=
ge, if the link is estimated to be of a=C2=A0






type which potentially can be=C2=A0unidirectional=E2=
=80=9D. There is another benefit to doing that, see the end=C2=A0=







of this email.






=C2=A0






Either way, I do not like the notion of fusing metri=
cs-and-link-bidirectionality-detection any more than I like fusing global-t=
opology-diffusion-and-link-bidirectionality-detection.=C2=A0<=
/p>





=C2=A0






The solution all this is, to me, threefold=







=C2=A0






1) Factor out the bidirectionally check in a (trigge=
red) neighbour detection mechanism=C2=A0






(triggered HELLO message)






=C2=A0






2) Remove the =E2=80=9Cvalidity time TLVs=E2=80=9D, =
since they add complexity for no perceivable benefits






=C2=A0






3) Use the security model that we=E2=80=99ve discuss=
ed previously, where (only) the metrics change per hop.






=C2=A0






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 related issue, as I hinted previously.





=C2=A0








The abs=
tract states that the protocol:






=
=C2=A0






=C2=A0=C2=A0 ...is intended for use by mobile routers in wireless, mul=
tihop


=C2=A0=C2=A0 networks.




=
=C2=A0






Section=
 5 paragraph 4 =C2=A0of the document, however, reads:<=
/pre>





=
=C2=A0






=C2=A0=C2=A0 Assuming link metrics are symmetric, the cost of the rout=
es installed


=C2=A0=C2=A0 in the Local Route Set at each router will be correct.=C2=
=A0 While this


=C2=A0=C2=A0 assumption is not always correct, calculating incoming/ou=
tgoing


=C2=A0=C2=A0 metric data is outside of scope of this document. =





=C2=A0








I do not know of any wireless systems,=
 where the assumption that =E2=80=9Clink metrics are symmetric=E2=80=9D act=
ually holds. Consequently, the conclusion in the quoted paragraph:






=C2=A0


=C2=A0=C2=A0 calculating incoming/outgoing


=C2=A0=C2=A0 metric data is outside of scope of this document.<=
u>




=C2=A0








Is not an acceptable design choice.





=C2=A0






While this protocol may not want to =E2=80=9Ccalcula=
te if for this link the metrics is 4 or 5=E2=80=9D, the protocol must be ab=
le to convey and distinguish that =E2=80=9Cthe metric from A to B is 4, and=
 the metric from B to A is 19=E2=80=9D.






=C2=A0






This is a =E2=80=9Crelated issue=E2=80=9D since the =
solution may (as with the bi-directionality check) be in the triggered neig=
hbour detection mechanism: that exchange could, if designed carefully, be u=
sed to probe for and convey metrics information, also.






=C2=A0






Hope this helps,






=C2=A0






=C2=A0






Thomas






=C2=A0












On 25 Apr 2016, at 15:27, Dearlove, Christopher (UK)=
 <chr=
is.dearlove@baesystems.com> wrote:




=C2=A0








Assuming for the moment that everyone will n=
eed an RREP-Ack or won=E2=80=99t (let=E2=80=99s come back to that) why do C=
 and B need to put an address in as an RREQ-Ack request?
 Why not a flag, because the address will be included as the IP sending add=
ress - and we know 5444 is required to pass that on. (It=E2=80=99s used by =
NHDP as well.) Then we don=E2=80=99t need to change the RREP, it will have =
a flag set or not, and won=E2=80=99t change (in this regard).=







=C2=A0






Now let=E2=80=99s consider do we know whethe=
r we can set a fixed flag. First I=E2=80=99d say there are two cases - you=
=E2=80=99ve got a firm control on what=E2=80=99s going on in your network,
 or it=E2=80=99s one of unknown parties and behaviour (consistent with spec=
ification). In the former case you only want one setting, for example no-Ac=
k if running NHDP or your MAC layer tells you about bidirectionality, Ack o=
therwise. In the latter case, I think you
 just always want an Ack. So both cases get you to the same place.






=C2=A0






Should that not be an acceptable argument (t=
hough I think it=E2=80=99s good for where we are - in fact always Ack is cl=
ose) then at flag is a step better, it=E2=80=99s a fixed
 location to change. However it would be better in that case if the two thi=
ngs to change (metric and ack flag) were together. But that has its own iss=
ues, so I won=E2=80=99t go there.






=C2=A0




--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44 (0)1245 242194
 =C2=A0| =C2=A0E:=C2=A0chris.dearlove@baesystem=
s.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






From:=C2=A0Victoria Mercieca [mailto:vmercieca0@gmail.com]=C2=A0

Sent:=C2=A025 April 2016 14:15

To:=C2=A0Jiazi YI

Cc:=C2=A0Dearlove, Christopher (UK); Christopher Dearlove; Mobile Ad=
 Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)






=C2=A0






=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om 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=C2=A0tha=
t
 you can look out for in emails you receive, click=C2=A0here.

If you feel the email is su=
spicious, please follow=C2=A0this
 process.








Hi Jiazi,










=C2=A0








On Mon, Apr 25, 2016 at 1:04 PM, Jiazi YI <ietf@jiaziyi.com> wrote:








Hi,=C2=A0








=C2=A0








On Mon, Apr 25, 2016 at 11:20 AM, Dearlove, Christop=
her (UK) <chris.dearlove@baesystems.com&=
gt; wrote:










With regard to your validity time point, we =
here have a tradeoff. If you allow that feature, it significantly impacts o=
n the approach that was coming together
 on as best you can end to end encryption.






=C2=A0






So the question is, is this a feature that=
=E2=80=99s really wanted? Unfortunately I think we know that the answer to =
that is, we don=E2=80=99t know because we don=E2=80=99t have any
 experience. My view would be that in the tradeoff of an untested feature (=
unless I=E2=80=99m wrong about that) and the security complication, securit=
y wins and drop the feature. If there is some real requirement, then there=
=E2=80=99s a discussion. (Questions like how often
 the intermediate routers actually have any knowledge - typically links bre=
ak for unexpected rather than expected reasons. Andan intermediate router c=
ould possibly use a validity time to influence its behaviour.) Note that dr=
opping the ability of intermediate
 routers to modify/set still allows validity times per route to be set at e=
ndpoints.












=C2=A0










I agree with Chris' concern.










The ValidityTime is optional, which makes the integr=
ity protection hard. Furthermore, it gives a potential attack vector: as al=
l the routers in a path will take the shortest validityTime, a compromised =
router can set the the validityTime
 to a very short value, which will make the route installed along the path =
became invalid (very soon).=C2=A0










=C2=A0










On the other hand, I'm not sure this option will=
 give us much help. Chris mentioned much knowledge intermediate router woul=
d have to decide this value (and how much sense the value would make).=C2=
=A0










Another issue is, a route to a destination might be =
updated by different sources. For example, in the network below:<=
/u>










=C2=A0










A-=
---B-----C










=C2=A0










A first establish a route to B with long validity ti=
me. Then A initiates a route discovery to C. C tends to set a short validit=
y time, which will make the route between B and A expire earlier than expec=
ted.=C2=A0










Is this a problem? Maybe yes, maybe no -- I'm no=
t sure it's considered or not.=C2=A0










=C2=A0
















=C2=A0








Not sure I follow here.=







Currently, the validity=
 time of the route between A and B would not affected by a short validity t=
ime of a route between A and C. Validity times are per-route, and the route=
 A-B and the route A-C are separate.








If we switched to a validity time per neighbor (so t=
hat we can keep validity time separate from route advertisements) as I ment=
ioned in the email below, then the validity of a route between A and C woul=
d be affected if there was a short
 validity time between A and B. But, if B will only route for a certain amo=
unt of time, then the route between A and C will of course be affected. Is =
it best to know in advance that there's a time limit, or just deal with=
 RERRs when they happen?








=C2=A0







=C2=A0






















=C2=A0






With regard to the acknowledgements, the pro=
blem (with regard to security) comes from trying to do two jobs with the sa=
me message - end to end route advertisement
 and hop by hop acknowledgement. I understand the reasons - saving bytes an=
d message types. (I would have to study the protocol really hard to identif=
y if any message types can be folded together and recognised by content rat=
her than type efficiently. This
 I do not expect to do.) Again a tradeoff. This one is in discussion space,=
 though that needs people who understand both sides of the issue, including=
 the details of the bidirectionality mechanism. Of course, as has been said=
, we need one of those.














=C2=A0










I haven't finished my review of the latest draft=
, and I don't get the necessity of AckReq and the corresponding multica=
st RREP yet.=C2=A0










If possible, this "optional" field should =
be avoided.=C2=A0










=C2=A0


















To give an overview of AckReq and RREP:






Since AODVv2 requires b=
idirectional links, this is the way to determine if a link is bidirectional=
.








A----B----C












1) A sends RREQ, B forwards it, C receives the RREQ. B and C both install a=
 route to OrigAddr but they dont yet know if it's valid because they do=
nt know if the link to their next hop is available in the reverse direction=
.










2) C creates the RREP. Since it doesnt know if the l=
ink to B is bidirectional, it includes the AckReq (an address to indicate t=
hat it expects to receive a RREP_Ack from B).










3) B receives the RREP, installs a route to TargAddr=
 and marks it as valid, since it knows the link to C is bidirectional, beca=
use the RREQ went in one direction and the RREP came in the other. B also s=
ends the RREP_Ack to C and forwards
 the RREP to A (and might change the message to indicate its own AckReq - i=
e that it requires an ack from A).










4) C receives the RREP_Ack from B, and therefore kno=
ws that B received the RREP, therefore the link is bidirectional. C can the=
n mark its route to OrigAddr as valid.










5) Similarly, A receives the RREP, installs the rout=
e to TargAddr and sends an RREP_Ack to B.










6) B receives the RREP_Ack and marks its route to Or=
igAddr as valid.










=C2=A0








Alternatively, in step =
2, if C knows the link to B is bidirectional (perhaps from some earlier rou=
te discovery), it doesnt need to put the AckReq in the RREP. Then in step 3=
, since B doesnt know if the link
 to A is bidirectional, it changes the message to add the AckReq address, i=
n order to get an RREP_Ack from A.






If we want to avoid cha=
nging the message, we'll need to look at forwarding the RREP as-is, and=
 creating a second message to solicit an RREP_Ack, in order to verify that =
the link is bidirectional before marking
 the route to OrigAddr as valid.=C2=A0








Kind regards,










Victoria.








=C2=A0







=C2=A0


















regards










=C2=A0










Jiazi










=C2=A0














=C2=A0




--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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






From:=C2=A0Victoria Mercieca [mailto=
:vmercieca0@gmail.com]=C2=A0

Sent:=C2=A023 April 2016 10:55

To:=C2=A0Christopher Dearlove

Cc:=C2=A0ietf@thomasclausen.org; Dearlove, =
Christopher (UK); Mobile Ad Hoc Networks mailing list<=
/p>











Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=C2=A0






=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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.










Hi Chris,








=C2=A0










These have both been in the draft in some form since=
 before I got involved... but I'll do my best to explain.=









=C2=A0










- For Validity Time, its a way to advertise that you=
 would only support the route contained in the message for a certain period=
 of time. The originator might use this, but the draft was written to allow=
 any intermediate node to be able
 to add it or update it too. The route created in the Local Route Set has a=
n expiration time associated with it, based on the received validity time.<=
u>










- For the AckReq address, its so that you can add in=
to a RREP a request for an acknowledgement, so that you don't have to h=
ave a different message type altogether for working out whether links to ne=
ighbors are bidirectional, and also, since
 you only care about bidirectionality on routes that are being set up, you =
dont need to constantly monitor all neighbors.










=C2=A0










=C2=A0










In order to avoid the potential AckReq-related chang=
es to each message, maybe we do need to introduce a different message speci=
fically for this. We could maybe use RREP_Ack to both request and acknowled=
ge? It means an extra message of control
 traffic that needs to be sent, maybe one extra message per hop on the path=
 of a RREP, but it could still be limited to neighbors which have participa=
ted in the route discovery rather than monitoring all neighbors at all time=
s.=C2=A0










=C2=A0










This message could maybe also include "I'm =
happy to route anywhere for a certain amount of time", sort of like wi=
llingness in OLSR/OLSRv2. So instead of having a validity time per route, i=
ts a validity time per neighbor. Then, for RREQ
 and RREP, only the metric value would change in transit, as discussed. How=
ever, that leads to some issues with deciding what a route's expiration=
 time is. You might know how long the next hop router is valid for, but wha=
t if a router beyond that, which was
 also part of the route, had a lower validity time? You couldn't determ=
ine the real validity time. Do we remove the route expiration time altogeth=
er to avoid this issue? In which case, we would have to rely on RERR messag=
es being sent for routes which become
 invalid when the neighbor's validity time has expired? So neighbor val=
idity time expiration is treated the same as a link break.









=C2=A0










What do you think?










=C2=A0










Kind regards,










Victoria.










=C2=A0










=C2=A0










=C2=A0










=C2=A0










=C2=A0












=C2=A0








On Sat, Apr 23, 2016 at 1:09 AM, Christopher Dearlov=
e <chris@mnemosyne.demon.co.uk> wrote:<=
u>










Pretty much all of the discussion has been assuming =
only a metric value change. With multiple things changing many of the ideas=
 go out of the window. That reinforces the point about not making specifica=
tions now that might turn out to be
 wrong for ICVs.










=C2=A0










Ignoring how this misunderstanding happened, I'l=
l start by asking why. Metric changing I understand. Why the other two? (th=
ere's a partial explanation of one). What alternatives have people impl=
emented in comparable protocols?



-- =C2=A0








Christopher Dearlove














On 23 Apr 2016, at 00:26, Victoria Mercieca <vmercieca0@gmai=
l.com> wrote:


















Hi all,










=C2=A0










Continued in this thread because the other one seems=
 to be more about TLV types and metric type numbers, whereas this is about =
regeneration/forwarding.










=C2=A0










To recap, in the current draft, there are 3 things t=
hat might change at each hop:=C2=A0

- the metric value (happens in RREQ and RREP),=C2=A0

- adding/changing Validity Time using the Validity Time TLV (can happen in =
RREQ and RREP),=C2=A0

- adding an address (and corresponding value in the AddressType TLV to indi=
cate how to interpret the address) to indicate the address from which an RR=
EP_Ack is expected, to accomplish the bidirectionality check (can happen in=
 RREP).



If we define=C2=A0a certain portion of the message as immutable and include=
 the ICV to verify that part, end to end:=C2=A0

- The metric value would be excluded from the ICV since it needs changing a=
t each hop.=C2=A0

- Would adding a Validity Time TLV at an intermediate hop be acceptable? Th=
e whole TLV could be removed in order to calculate the ICV?







- Would adding an address cause issues for the ICV, =
because it's in the address block? Could the rule be "if it contai=
ns an AckReq address, remove it (and the corresponding value in the Address=
Type TLV), before checking the ICV", is that
 OK? Or would we need to avoid touching the ICV'ed part of the message =
altogether, maybe put the AckReq address in a separate Address Block, with =
an extra AddressType TLV following that address block? Is there a way to ac=
complish this?










=C2=A0










Also, to be thorough, do we need to consider RERR me=
ssages while we discuss regeneration vs forwarding?=C2=A0










- RERR (sent when a link breaks) is a way of saying =
"I've lost my route so I'm telling others" and "you =
were my next hop, so=C2=A0now=C2=A0I've also lost my route, I'll te=
ll others", etc. It's going to be tailored at each step to include=
 the relevant
 routes that got deleted, it's not one message being sent end-to-end li=
ke RREQ and RREP are.=C2=A0










- However, RERR (sent when a source of traffic is se=
nding data on a route which comes through you, and you want to tell the Pac=
ket Source's router to delete the route) could be seen as an end-to-end=
 message which all intermediate routers
 learn from, similar to RREQ and RREP. It reports one route, and doesn'=
t need changing at intermediate hops, so could be protected with ICV.










- Would it be OK to only require a message ICV if a =
PktSource address was included, i.e. when the message needs to go via a num=
ber of intermediate hops to PktSource's router? All other RERRs are int=
ended to be one-hop messages, which may
 in turn prompt other one-hop messages, etc..., and a packet ICV might be m=
ore appropriate?










=C2=A0








Kind regards,








Victoria.










=C2=A0








On Thu, Mar 17, 2016 at 5:26 PM, <i=
etf@thomasclausen.org> wrote:








=C2=A0












On 17 Mar 2016, at 18:17, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:








=C2=A0












Yes, I meant AODVv2, thanks for the catch.










=C2=A0










So is your (Thomas) proposed base specificat=
ion a hop count only metric?
















=C2=A0








No, the would be silly as base specification, given =
that hop count mostly is useless.










=C2=A0










As base specification I would simply say =E2=80=9CIn=
clude a Metric Type Message TLV with a value field, and a 7182 Message TLV =
& Timestamp=E2=80=9D as we do in OLSRv2 (with the appropriate verbiage =
as to generation and processing).=C2=A0










=C2=A0










With the message generated by the originator of the =
RREQ/RREP and *not* deconstructed/reconstructed/reordered (as is the risk w=
ith =E2=80=9Cregeneration) allows knowing that it would be *only* that metr=
ic field being modified (other than hop count/limit)
 for when eventually writing up the extension.










=C2=A0
















(Actually doesn=E2=80=99t the current specif=
ication only define hop count, or has that changed in latest draft?)=















=C2=A0








No. That is one of the issues I raise in my original=
. For some reason, it cites RFC6551, which is a ROLL document and which has=
 in its abstract that:










=C2=A0








=C2=A0=C2=A0 Low-Power and Lossy Networks (LLNs) have unique character=
istics


=C2=A0=C2=A0 compared with traditional wired and ad hoc networks that =
require the


=C2=A0=C2=A0 specification of new routing metrics and constraints. =







=C2=A0










I.e. this document cites a metric document which cle=
arly claims to be inapplicable in ad hoc networks. I note that this is anot=
her thing I=E2=80=99ve raised for years without seeing it attempted resolve=
d.










=C2=A0










Best,










=C2=A0










Thomas










=C2=A0










=C2=A0














=C2=A0








--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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














From:=C2=A0ietf@thomas=
clausen.org=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 17:10

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Lotte Steenbrink; Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)














=C2=A0








=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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=A0
















On 17 Mar 2016, at 18:04, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:












=C2=A0














OK, so we have a message that mutates by:














- Modifying hop count/limit.














- Modifying a metric value.=















Anything else?














=C2=A0














As mutating (other than hop count/limit) mes=
sages aren=E2=80=99t covered by 5444 or any derivative document (but only r=
ecommended against, not banned) that you may
 need to make the message otherwise immutable (no deconstruction and rebuil=
ding, other than guaranteed unchanging) that would have to be specified by =
AODVv2. (Easy to say, but needs saying.)


















=C2=A0












With you so far.












=C2=A0









Then that information is not in a guaranteed=
 fixed location given by a simple offset. So any signature algorithm that f=
inds it and ignores it or aggregates
 on it is specific to OLSRv2.














=C2=A0












Surely you mean AODVv2












=C2=A0









So standard 7182 ICVs don=E2=80=99t do the j=
ob, you would need an AODVv2 specialised variant. Which is the sort of thin=
g that the message specific TLV space is there
 for, I=E2=80=99d be strongly against a =E2=80=9Cbut ignore the value of th=
is specific TLV should it occur=E2=80=9D being in the general space. Howeve=
r it can easily be defined by reference to 7182 (=E2=80=9Cthis TLV is like =
that TLV, except if an X TLV is present, set its value field to
 zero=E2=80=9D).














=C2=A0














Messy, but could work.<=
/p>













=C2=A0












Not that messy, actually, although clearly not as ni=
ce as =E2=80=9Cfixed offset=E2=80=9D.














=C2=A0














That said, I am arguing for the base spec being:<=
/u>














=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=E2=80=9Cmake the message otherwise immutable (no deco=
nstruction and rebuilding, other=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=A0than guaranteed unchanging)=E2=80=9D which is af=
forded by forwarding














=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7182 Timestamps and ICVs.














=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0RFC7183 style text bringing it all together.=















=C2=A0














The =E2=80=9Caggregated signatures around mutable fi=
eld=E2=80=9D would very be an experimental extension.














=C2=A0














What I object to is, if the base spec specifically r=
enders such extensions impossible














=C2=A0












=C2=A0









=C2=A0










--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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


















From:=C2=A0Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]=C2=A0

Sent:=C2=A017 March 2016 16:48

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0ietf@thomasclausen.org; Mobile Ad =
Hoc Networks mailing list

Subject:=C2=A0Re: [manet] Message integrity and message mutability (=
was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)


















=C2=A0










=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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.












Hi all,
















=C2=A0




















Am 17.03.2016 um 17:44 schrieb Dearlove, Christopher=
 (UK) <chris.dearlove@baesystems.com>=
:
















=C2=A0


















Good point about whether you just pass on on=
e cost or a set of costs. As I said, not looked at details - I will, when t=
ime permits. One cost is much easier,
 and yes, it reduces the fixed size aggregated signatures problem to =E2=80=
=9Cjust=E2=80=9D one of computational load.






















=C2=A0


















For the record, Thomas=E2=80=99 understanding is cor=
rect; the cost is one aggregated value.=C2=A0


















=C2=A0


















Best regards,=C2=A0


















Lotte Steenrbink














=C2=A0















=C2=A0












--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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






















From:=C2=A0ietf@thomas=
clausen.org=C2=A0[mailto:ietf@thomasclausen.org]=C2=A0

Sent:=C2=A017 March 2016 16:38

To:=C2=A0Dearlove, Christopher (UK)

Cc:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0Re: Message integrity and message mutability (was RE: =
[manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)






















=C2=A0












=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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=A0
























On 17 Mar 2016, at 17:30, Dearlove, Christopher (UK)=
 <chris.dearlove@baesystems.com> wrot=
e:




















=C2=A0






















I appreciate Thomas=E2=80=99s comments about=
 the limitations of message regeneration, but I would be a bit less absolut=
e.






















=C2=A0






















The issues over end to end authentication an=
d more advanced signatures are valid. I need to read the given reference on=
 aggregate signatures to increase my
 knowledge (thanks for it), but my understanding of the possibilities in th=
is field may offer a solution to the problem, but with some other issues (p=
ossibly including a new type of TLV).






















=C2=A0






















But the hop count/limit point I don=E2=80=99=
t fully agree with, you can regenerate with an incremented/decremented coun=
t/limit, which leaves the ability to prevent
 messages propagating indefinitely, including expanding ring searches, and =
retains the ability to use RFC 5497 interval and validity times that might =
be useful with an expanding ring search (or might not).






















=C2=A0






















But the key issue is that AODVv2 wants to ac=
cumulate metrics. I still haven=E2=80=99t got to the bottom of many details=
 here, but let=E2=80=99s for the moment just consider
 that conceptually.






















=C2=A0






















It=E2=80=99s hard to handle end to end. Char=
lie=E2=80=99s draft attempts to do an end to end of some information, not t=
his information. I=E2=80=99m not sure if that=E2=80=99s useful (and the
 specialised format is better avoided if possible). Other approaches are ho=
p by hop (might as well use packet signatures) and shared key (might as wel=
l go hop by hop). Pairwise signatures for each pair of routers I=E2=80=99m =
discounting as scaling terribly. In the
 interests of completeness let=E2=80=99s mention not accumulating metrics, =
which puts us back to hop count and that=E2=80=99s not ideal either.=























=C2=A0






















I don=E2=80=99t think there is an ideal solu=
tion. (I like ideas I=E2=80=99ve seen about aggregating, but that has some =
issues of its own, even apart from computational load.)
 I=E2=80=99d love to be proved wrong - someone with the perfect solution to=
 come along.






















=C2=A0






















Which means that either we make an arbitrary=
 choice - which will be disagreed with, but needs discussing first - or cre=
ate something flexible. Unfortunately
 flexible in that regard constrains in others, e.g. some (many? most?) aggr=
egating signatures need fixed data sizes (which we can do by defining a TLV=
 that =E2=80=9Cfills up=E2=80=9D with hop count, but that has a cost too).<=
/span>


























=C2=A0




















I have been told by people much more well versed in =
this than I in cryptology, that the correct answer is =E2=80=9Csome=E2=80=
=9D.






















=C2=A0






















That said, "AODVv2 wants to accumulate metrics=
=E2=80=9D =E2=80=94 does that mean that the message grows as it is being fo=
rwarded, and that the recipient of a RREQ/RREP will know the individual cos=
ts of each path segment? My understanding is, that the recipient
 will get =E2=80=9Cthe sum the costs of each path segment=E2=80=9D which sh=
ould be fitting within a fixed size?






















=C2=A0






















Thomas






















=C2=A0




















=C2=A0



















=C2=A0






















Sorry, no answers, just comments. And I=E2=
=80=99m not addressing Thomas=E2=80=99s later points here.=























=C2=A0














--<=
u>


Christopher De=
arlove

Senior Principal Engineer

BAE Systems Applied Intelligence Laboratories

_____________________________________________________=
_____________________



T: =C2=A0+44
 (0)1245 242194=C2=A0=C2=A0| =C2=A0E:=C2=A0chris.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


























From:=C2=A0manet [mail=
to:manet-bounces@ietf.org]=C2=A0On
 Behalf Of=C2=A0ietf@thomasclausen.org

Sent:=C2=A017 March 2016 16:00

To:=C2=A0Mobile Ad Hoc Networks mailing list

Subject:=C2=A0[manet] draft-ietf-manet-aodvv2-13 review - a couple o=
f big ticket Items


























=C2=A0














=C2=A0




*** WARNING ***







This message originates from outside our organisation, either fr=
om an external partner or the internet.

Consider carefully whether you should click on any links, open any attachme=
nts or reply.

For information regarding=C2=A0Red Flags=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***

EXTERNAL=
 EMAIL -- This message originates from outside our organization.<=
/u>














=C2=A0
























Dear all,
























=C2=A0


























Apologies for not having gotten this done sooner - d=
ay-job leaving few spare cycles.


























=C2=A0


























I=E2=80=99ve previously offered reviews and comments=
, and some of those have been addressed in the latest I-D =E2=80=94 others =
have not, but should be. I recall that there was some mail attempting to re=
but parts of the review, and I will dig it out and
 reply to that.


























=C2=A0


























With that being said, I have reviewed the latest ver=
sion of the document, and full details will be forthcoming. There=E2=80=99r=
e a couple of big-ticket/architectural items that I want to address up fron=
t, as I believe that before we have those
 hammered out, it will be useless to go into details. Note, I do not claim =
that this is an exhaustive list of =E2=80=9Cbig ticket items=E2=80=9D, but =
that=E2=80=99s as far as I have gotten in thinking this through.<=
/u>


























=C2=A0


























I also bring these up as they are items that have be=
en brought up repeatedly over the past years, but not resolved nor discusse=
d.


























=C2=A0


























Loops


























Just to bring this out: I share Chris=E2=80=99 worry=
 about conflicting and concurrent statements from the authors on =E2=80=9CT=
here are no loops possible=E2=80=9D and =E2=80=9CWe need to fix two situati=
ons where loops can occur=E2=80=9D and =E2=80=9Cwe are still investigating =
some loop
 conditions=E2=80=9D


























=C2=A0


























I particularly worry that this is not a discussion h=
ad in public, but apparently in some other forum=E2=80=A6


























=C2=A0


























=C2=A0




























Intermediate Route Replies, and all of section=
 10


























Section 10 contains a set of =E2=80=9Cvaguely specif=
ied extensions=E2=80=9D, which is incoherent with the intended status indic=
ated for this document.=C2=A0


























=C2=A0


























Specifically, and this is not unrelated to the point=
 about loops above, intermediate RREPs (section 10.3) are a potential sourc=
e for loops.


























=C2=A0


























Expanding Ring Multicast (section 10.1) is not docum=
ented in a way that can be implemented (and also, see =E2=80=9CForwarding-v=
s-regeneration=E2=80=9D below, it is in the present form of this protocol i=
mpossible), etc.




























=C2=A0


























=C2=A0


























Forwarding-vs-regeneration


























Recent exchanges on the list made me understand that=
 protocol control messages are *not* forwarded, but are consumed at each ho=
p, then a new message with (almost-but-not-quite) the same content is gener=
ated and transmitted.


























=C2=A0


























I have thought some more on this (& read some of=
 the exchanges on the list on this topic by Chris, Ulrich, and others), and=
 I am convinced that this is not the right way to go,=C2=A0at least=
=C2=A0for the following reasons:


























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It renders the hop-limit/hop-count fields in the RFC5444 messag=
e header useless.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0This would not be bad if the functionality offered by tho=
se fields was not useful


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=94 sadly, it is. For example, for scope limited fl=
ooding (expanding ring search, and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0such) which may be of interest, and which require hop-lim=
it.=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0A hop-count field may also provide a =E2=80=9Ccheap=E2=80=
=9D (in terms of overhead) additional piece


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of information to use conjunctively with a =E2=80=9Creal=
=E2=80=9D metric.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The only practical solution would be to re-introduce thes=
e functions by way of inserting a


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0MessageTLV =E2=80=94 which (i) is not specified in this d=
ocument, and (ii) which would just


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0serve to render messages bigger than strictly needed.<=
/u>


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Scope limited flooding =C2=A0does seem to be a necessary =
requirement, if for no


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0other reason than to prevent information from =E2=80=9Cci=
rculating forever in the network=E2=80=9D.


























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It makes end-to-end authentication unnecessarily hard.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I think Chris called this out already, but it bears repea=
ting: S generates a message=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(say, a RREQ), and includes an ICV calculated over the co=
ntent of the message.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0For any recipient to be able to validate the ICV, the mes=
sage has to be exactly


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0the same =E2=80=94 not just in content, but in structure =
=E2=80=94 as what was generated.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CRegenerating=E2=80=9D rather than =E2=80=9Cforwa=
rding=E2=80=9D messages means, that the intermediate


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0router =E2=80=9Cregenerating=E2=80=9D the RREQ may chose =
a different structure (e.g., include TLVs


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0in a different order).


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0The proposal from=C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00=



























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0is to add constraints on (i) the set of elements to inclu=
de in a signature and (ii) the


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0order of these elements.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0One=C2=A0problem with that approach is (i): if an extensi=
on adds a message TLV, or an=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Address TLV, to a message, then that will not be =E2=80=
=9Ccovered=E2=80=9D by the proposed e2esec TLV.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Rather for *each* extension developed, an =E2=80=9Cupdate=
s e2esec=E2=80=9D clause needs to be done.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0I=E2=80=99d say that this approach would be prone to erro=
rs =E2=80=94 and add entropy to the process


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0of designing protocol extensions. The alternative, a mess=
age being generated by the


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0source and *forwarded* (as we do in OLSRv2, for example) =
would allow ICV TLVs=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0(even, allow reuse of those specified for OLSRv2) for cov=
ering a message and=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0extensions.


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=E2=80=9CBut what about the metrics value which will chan=
ge on each hop=E2=80=9D, you may say?


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Fortunately, that is relatively easy to handle: simply ze=
ro out the value of that TLV when


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0generating or verifying the ICV MessageTLV. And use Packe=
t-TLVs for hop-by-hop=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0authentication, if needed (but, see below).=



























=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=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0It prevents the use of more clever/advanced signature scheme=
s/ICVs


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Aggregate signature algorithms (=C2=A0https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf<=
/span>)


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0exist, and an interesting use-case can be found in also r=
eactive protocols, allowing verifying


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0not =E2=80=9Cjust=E2=80=9D the end points, but also the i=
ntermediaries (again, with the appropriate =E2=80=9Czero out=E2=80=9D


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0discussed above, or something smarter).


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Regeneration of messages, rather than forwarding, renders=
 that impossible (or, if used,


























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0updating to =C2=A0https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)


























=C2=A0


























There are other reasons, but the above are those tha=
t jump at me as immediate show-stoppers.


























=C2=A0


























I do honestly not see what possible benefit there is=
 from =E2=80=9Cregeneration=E2=80=9D =E2=80=94 but I see very clear inconve=
niences, and security is not the least of these. Insisting on =E2=80=9Crege=
neration=E2=80=9D requires development of =E2=80=9Cnon-general workarounds=
=E2=80=9D as pointed
 out above.


























=C2=A0


























Security Considerations<=
/p>

























This is an always thorny subject. When OLSRv2 was go=
ing through the process we got a thorough education in how little we knew a=
bout security from the SEC-ADs, and had to spend about a year or so develop=
ing RFC7183. The bottom line is, that
 this protocol needs its =E2=80=9CRFC7183 =C2=A0equivalent=E2=80=9D, either=
 as part of the main document, or as an independent document. currently, th=
at is not the case.


























=C2=A0


























A minima, looking at BCP72 and BCP107 =E2=80=94 taki=
ng inspiration from RFC7183 might be aw good idea, as that was the most rec=
ent that went through the SEC AD. Regardless of how, however, a =E2=80=9Cma=
ndatory to implement=E2=80=9D security mechanism most be specified
 (I think the right term was =E2=80=9CMUST implement, SHOULD use=E2=80=9D),=
 in sufficient detail to ensure interoperable implementations.


























=C2=A0


























As an example, both [RFC6130] and [RFC7181] set out =
that that:




























=C2=A0


























=C2=A0 =C2=A0 =C2=A0 On receiving a ... message, a r=
outer MUST first check if the


























=C2=A0 =C2=A0 =C2=A0 message is invalid for processi=
ng by this router


























=C2=A0


























and then proceed to give a number of conditions that=
, each, will lead to a rejection of the message as "badly formed and t=
herefore invalid for processing=E2=80=9D =E2=80=94 a list which RFC7183 the=
n amended. That gave a =E2=80=9Chook=E2=80=9D for RFC7183 for inserting
 =E2=80=9Crejection=E2=80=9D. Idem for message generation.

























=C2=A0


























If I was to do RFC7181/RFC6130 today, I would includ=
e that directly into the protocol specifications. It turned out to be more =
overhead (and slow down publication anyways) to do it as separate documents=
.




























=C2=A0


























Secondly, we need to be a lot more rigid in terms of=
 what ICVs, Timestamps, etc. are added/removed, and what that brings.


























=C2=A0


























For example (with the assumption that messages are *=
forwarded* and *not* regenerated), this could be one option:<=
/p>

























=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0When a RREQ, RREP message is generated, add an ICV Message TLV, which=
 is calculated <this way>


























=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=E2=80=A6(take inspiration from RFC7183 here)


























=C2=A0


































...



[Message clipped]=C2=A0=C2=A0

_______________________________________________

manet mailing list

manet@ietf.org

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/manet






=C2=A0
















_______________________________________________

manet mailing list

manet@ietf.org

<=
span style=3D"color:purple">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 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

<=
span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/manet








=C2=A0














=C2=A0










_______________________________________________

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




=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













--94eb2c1228d0ef1bef05318e654b--


From nobody Thu Apr 28 10:08:51 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 507C412D1DE for ; Thu, 28 Apr 2016 10:08: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 22ScTDsYMPrR for ; Thu, 28 Apr 2016 10:08:46 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 994CF12D1DC for ; Thu, 28 Apr 2016 10:08:45 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id g133so115024082ywb.2 for ; Thu, 28 Apr 2016 10:08:45 -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=RdyMPmS8tucDD5CgmfDVDEjSyf3aLdBpr4VbuF7ANRA=; b=vvHRylAN621OiKa83o+5pbmdBp29HycCd6W4C5bfB/7JjjtPrvlV8pwUO7R/r6WwrS dizFvYrotw8NNpKj0y5DEodohddtwQXiAurHvIW1ZrCtA3EdRuwOxAT8ExUlioYMyugw qNjK6Bh0bc6EGa3PcMUienqNoKwpsHjedJDIGTayhZTcDcxJ1dWwXMjknHt/3INUq9OP JtGMA+vQqyMx8yTGzSUFDC2E61q5ht9YOH2/fPW/8i3+qO6H4o/Y+n/w9QPfUXX+0ZES TTZzje0nYmDyB/U28MP1c5qwYBrKnuFFEKw3lXMeaJysrxKmAo0BKj3W6tnbLljH1735 jBAw==
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=RdyMPmS8tucDD5CgmfDVDEjSyf3aLdBpr4VbuF7ANRA=; b=b7i5d9NehAT8geysXjnADzuynNJNNXhfnJV1AYZZvkeM36R9wr7xdJi6bnCw3Q6Tu9 lzTyHQcyabzK2rXsiffGXd0P99JPtJm2NHs0TudrsCWBpRyyKJIGBhHGqGuj1ui6AI40 OPQbVYc27geEY4lUqbG4qJiz92MGAGtO2Q+iFTP4Vpne5WJCA7HpRbYeZ2kkuPCmQNGV bgna84jun+MP4OhmMkLf1QVNNVl8YTN61eUGrgWUl+8lzp3zkts2nwR08gsnH9mpuyXQ 6xs+pK+C0N5K5rDELJyNGEQxP9989aNQIYyuu+Ar90czo91LUcitoTd5dTjKZ7g1k1mE azuQ==
X-Gm-Message-State: AOPr4FWVUoGv1O5ltWdLKFf90erYdRSmB2rLFsm3EDqwIE5RkmFhl3xLrIyo5A9JmAUls9xzR+tWfforX7N7/w==
MIME-Version: 1.0
X-Received: by 10.176.1.108 with SMTP id 99mr8215449uak.54.1461863324754; Thu, 28 Apr 2016 10:08:44 -0700 (PDT)
Received: by 10.31.62.67 with HTTP; Thu, 28 Apr 2016 10:08:44 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org>        
Date: Thu, 28 Apr 2016 13:08:44 -0400
Message-ID: 
From: Justin Dean 
To: Victoria Mercieca 
Content-Type: multipart/alternative; boundary=001a113d0cd42ea9c005318e943f
Archived-At: 
Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 28 Apr 2016 17:08:50 -0000

--001a113d0cd42ea9c005318e943f
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 28, 2016 at 12:55 PM, Victoria Mercieca 
wrote:

> Hi Jiazi,
>
> Thanks for your response. So you think we could change back to sending
> RREP by unicast (letting an implementation handle whether this requires a
> route to the neighbor to be installed temporarily)? We would have to also
> send a separate message to request an acknowledgement, but this could also
> be unicast and could therefore potentially be sent in the same RFC5444
> packet.
>
> Anyone have any objections?
>

I don't think it's a good idea to "temporarily" add a route that is not
known to be bi-directional yet.  The timing of correctly adding and
removing the route with different mediums and restricting the route to only
that one packet doesn't seem like a workable solution.    Sending it
unicast with a raw type socket or pcap out of a known interface sure.  IMO
a route shouldn't be added until the link is confirmed bi-directional.

Justin

--001a113d0cd42ea9c005318e943f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Apr 28, 2016 at 12:55 PM, Victoria Mercieca &=
lt;vmercieca0@gma=
il.com> wrote:
Hi Jiazi,

Thanks for your response. So you think we=
 could change back to sending RREP by unicast (letting an implementation ha=
ndle whether this requires a route to the neighbor to be installed temporar=
ily)? We would have to also send a separate message to request an acknowled=
gement, but this could also be unicast and could therefore potentially be s=
ent in the same RFC5444 packet.=C2=A0

Anyone have =
any objections?

I don't think it's=
 a good idea to "temporarily" add a route that is not known to be=
 bi-directional yet.=C2=A0 The timing of correctly adding and removing the =
route with different mediums and restricting the route to only that one pac=
ket doesn't seem like a workable solution. =C2=A0 =C2=A0Sending it unic=
ast with a raw type socket or pcap out of a known interface sure.=C2=A0 IMO=
 a route shouldn't be added until the link is confirmed bi-directional.=


Justin



--001a113d0cd42ea9c005318e943f--


From nobody Thu Apr 28 10:41: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 6692312D8A2 for ; Thu, 28 Apr 2016 10:41:06 -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 f0A_PQ7fb6hA for ; Thu, 28 Apr 2016 10:41:04 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 AC90912D903 for ; Thu, 28 Apr 2016 10:41:01 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id y84so92283751lfc.0 for ; Thu, 28 Apr 2016 10:41: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:from:date:message-id:subject:to :cc; bh=QTCg2RxxdkMAwdJKwgWbRXNhWRzjwFo3hUUJk1yGoDo=; b=p5IQRs+ckYozJhwTgRvM2zCGWahVA/Fjdmvi0XsgGZl3WOY+0wfeppIGGMzcj86QpT IZCIQAASbLQtK3WZIu6slodBQHfLHYPxkOk+pJhYZ6KSSm5mvrVq7HvyAzME9X8wdyeh QvwvFF4NAwnvc6Ns+uYcuLUr5Zs2xTNNG9DxlD6tqSkpMClmFsReRx56Vy6V/1VhOImt iUipewkrc3rboo1Qy+3NOGUxjAtPWWrfPykE2w11TG2ZjUaXxkRXvR4FPd98Wuvt4LJ/ T5OVhoUy+BAtjM2+DoYj/KDocKLPg7K0vK1qQhbP9HaBtK/nPN6GVqhGM3+0L63crSSF KZ+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:from:date :message-id:subject:to:cc; bh=QTCg2RxxdkMAwdJKwgWbRXNhWRzjwFo3hUUJk1yGoDo=; b=Dlr4P2fir6F0uHZ6RodzNepGIkXVOci84JaMNobCIOZWIjk8tKSz8YAnq2HKCCY6GB L70ufxdqICE1ZKM2iUmERsRNoInRvorJHSOzOMtHPdaYPG0YyiIKz4mJpOTDx+t/sD7H Duol0YXEDBRbkVx8+5+7vmDMjoUtvvN0m1ogA0xxSVR/Ggt/N1ftAvGCs22tYiETq9pn DJAGc/B9suhDnq7UMoe954puTx1Vgk5Qq/y+FaBUhXcxPL4yJq6Wh+5LSnQYI1NoLrWE lUpS24iCgywIcXrmUMGqy7LeF0pL0KUrJd7VKifrg9scuAfCB9gdLwTUR7MlsUjg3BVI NeAg==
X-Gm-Message-State: AOPr4FUXVMxrgRXm1REo2NxuDeRr32Pn666xMO3f7BTeDkc/yYse+YhnK+HuT/Yks8srG+ciKVH77WCepHS/zQ==
X-Received: by 10.112.12.98 with SMTP id x2mr6623679lbb.76.1461865259752; Thu, 28 Apr 2016 10:40:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.24.42 with HTTP; Thu, 28 Apr 2016 10:40:29 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org>         
From: Henning Rogge 
Date: Thu, 28 Apr 2016 19:40:29 +0200
Message-ID: 
To: Justin Dean 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 28 Apr 2016 17:41:06 -0000

On Thu, Apr 28, 2016 at 7:08 PM, Justin Dean  wrote:
>> Thanks for your response. So you think we could change back to sending
>> RREP by unicast (letting an implementation handle whether this requires a
>> route to the neighbor to be installed temporarily)? We would have to also
>> send a separate message to request an acknowledgement, but this could also
>> be unicast and could therefore potentially be sent in the same RFC5444
>> packet.
>>
>> Anyone have any objections?
>
>
> I don't think it's a good idea to "temporarily" add a route that is not
> known to be bi-directional yet.  The timing of correctly adding and removing
> the route with different mediums and restricting the route to only that one
> packet doesn't seem like a workable solution.    Sending it unicast with a
> raw type socket or pcap out of a known interface sure.  IMO a route
> shouldn't be added until the link is confirmed bi-directional.

Using IPv6 linklocal unicast would work fine because you always have a
route for the network.

Installing IPv4 linklocal addresses would give the same for IPv4.

Henning Rogge


From nobody Thu Apr 28 12:12: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 053C112D538 for ; Thu, 28 Apr 2016 12:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level: 
X-Spam-Status: No, score=-2.702 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, 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 9ej-hkOgYgEB for ; Thu, 28 Apr 2016 12:12:54 -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 1FAC012B004 for ; Thu, 28 Apr 2016 12:12:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D1458240719; Thu, 28 Apr 2016 12:12:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461870773; bh=Sp+IRlCRj7RIsi9cmXl+YtjHyMy7/CPmESuPI3lYYOQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=m19dCebUPkjKQpESIrSuHJwR61jaMzceG4SfiELW/npwaU2dhgC5UiQ4yhf5lpTYr iWVErBBSfMzctiYPUcsqLATx3dJYIDCQhq+79mX/rB/NvOCJXjbjhsvmFtZVsmoGns 1Nkr0JjIwmMdfGCrkalB7emSOSExJ+h4quVlgD+I=
X-Virus-Scanned: Debian amavisd-new at maila2.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 maila2.tigertech.net (Postfix) with ESMTPSA id 4FD8E240140; Thu, 28 Apr 2016 12:12:53 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPad Mail (13F51a)
In-Reply-To: 
Date: Thu, 28 Apr 2016 21:12:50 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <745A7E07-DAA3-43E0-8AA5-675B3BE303F3@thomasclausen.org>
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        <84C7FCA8-B122-4534-ACB7 -0C799F14A569@thomasclausen.org>          
To: Henning Rogge 
Archived-At: 
Cc: Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca , "Dearlove, Christopher \(UK\)" 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 28 Apr 2016 19:12:56 -0000

> On 28 Apr 2016, at 19:40, Henning Rogge  wrote:
>=20
> On Thu, Apr 28, 2016 at 7:08 PM, Justin Dean  wrote:=

>>> Thanks for your response. So you think we could change back to sending
>>> RREP by unicast (letting an implementation handle whether this requires a=

>>> route to the neighbor to be installed temporarily)? We would have to als=
o
>>> send a separate message to request an acknowledgement, but this could al=
so
>>> be unicast and could therefore potentially be sent in the same RFC5444
>>> packet.
>>>=20
>>> Anyone have any objections?
>>=20
>>=20
>> I don't think it's a good idea to "temporarily" add a route that is not
>> known to be bi-directional yet.  The timing of correctly adding and remov=
ing
>> the route with different mediums and restricting the route to only that o=
ne
>> packet doesn't seem like a workable solution.    Sending it unicast with a=

>> raw type socket or pcap out of a known interface sure.  IMO a route
>> shouldn't be added until the link is confirmed bi-directional.
>=20
> Using IPv6 linklocal unicast would work fine because you always have a
> route for the network.
>=20
> Installing IPv4 linklocal addresses would give the same for IPv4.
>=20

Not to forget:

    https://tools.ietf.org/html/draft-howard-sunset4-v4historic-00

So assuming what works with v6 seems the way to go.

Thomas

> Henning Rogge
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From nobody Thu Apr 28 12:36: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 5863712D942 for ; Thu, 28 Apr 2016 12:36:41 -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 LTOzVTKunpRB for ; Thu, 28 Apr 2016 12:36:39 -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 9976112D90F for ; Thu, 28 Apr 2016 12:36:38 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id a17so2573155wme.0 for ; Thu, 28 Apr 2016 12:36:38 -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 :content-transfer-encoding:message-id:references:to; bh=bzMbg2r8VxGjJ4QxiPXs/BRcxWKRcoymsXhGcCoRxco=; b=BUrWYJ4GVRbagIRxu1LJoxHZCMsU6HIG+i3zafBA1R/+0U3b8s68qt6P+1Ujv9hap/ YnD+EWGcnh2jxA+ihrtHfkeY8GAksKssGtJXsnrIvFUoXnWFjUzquQncjz4gfEwUrkvS wUQr2MUSMNdUESUYf0IPX5JWlQKM2uib/TYTUAOLwJyDJjTR+KvKmAeDU9UraiYeuJYC iKjawQ1D+mgo7NLNgGauoBP+3SEvw3wr4lwV0NVXYG8mtdcHV+zEj3Y75U4+xVDz4SOg gFSkRJ6HDwkNsPzm9FRCcDJFE+qummUNc+fNQOigYOtnOaCB/FFbuQfwpXOO96aPAzpM v8dA==
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 :content-transfer-encoding:message-id:references:to; bh=bzMbg2r8VxGjJ4QxiPXs/BRcxWKRcoymsXhGcCoRxco=; b=LbSK6rH94PhjH0YW4L6TLqSkWW5qr09ZCGsMKW1ELYCohhqrWfIIrZOH8a/cbA6gDk xpoDvS8pstPleWe3a4pWO9kREbdQpwoOkBbEla09wzTgi/gEEzEJAcU0tGQ5lrCakiaB tg23T4XHQRD8mRL1Op882CydAei6f10TXnBz0SmPtxmWMlNKHH3iqyJiwcKDptiLkSlT tGY3kRcmvidzN9LUtawvdu4r7GOHRq2QN1DDXbL5ZRQUdzB2R4Qj6/3Iu9nRS3mln7TB HZRdtKB/zlLo6ocG1r4PKcCqjFDf8IS3sKZnYfw/lHWKjQlUiI988tGxv0voiXO4siKb PoGQ==
X-Gm-Message-State: AOPr4FVoHlANykUiPZRt7NOpt3lpiW5euDXYkWsOBtLJmsvE6h46H0pD3gKOycZ2PuR6Pg==
X-Received: by 10.194.117.70 with SMTP id kc6mr19069291wjb.94.1461872196982; Thu, 28 Apr 2016 12:36:36 -0700 (PDT)
Received: from johns-mbp-4.home (host86-151-226-34.range86-151.btcentralplus.com. [86.151.226.34]) by smtp.gmail.com with ESMTPSA id n66sm12947849wmf.6.2016.04.28.12.36.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Apr 2016 12:36:36 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Dowdell 
In-Reply-To: 
Date: Thu, 28 Apr 2016 20:37:00 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E042F54-58E4-4C1B-8F7B-ECAD41341D48@gmail.com>
References: <937ABB81-CCD9-4FD0-A7CF-5114384B3B94@gmail.com> <8D383418-4CBF-49C6-9871-4E31042E29E5@mnemosyne.demon.co.uk> 
To: Christopher Dearlove , manet@ietf.org
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [manet] AODVv2 security: Key Management to BCP107
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, 28 Apr 2016 19:36:41 -0000

By the way I have re-ordered the emails in this post to make it easier =
to read for flow.
>=20
>>> On 27 Apr 2016, at 21:10, John Dowdell  =
wrote:
>>>=20
>>> Hi all
>>>=20
>>> As an AODVv2 co-author I=E2=80=99d like to propose this position =
regarding key management against BCP107, one of the artefacts we are =
being asked to state a position over. I=E2=80=99d also like to state =
that I=E2=80=99m open to contributions from others knowledgeable on this =
topic or who have been this way previously.
>>>=20
>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka =
BCP107 is the set of guidelines for choosing either automated or manual =
key management for cryptographic purposes. It=E2=80=99s not a long read =
and guides the reader through a set of tests as to whether automated or =
manual key management would be suitable for the application in hand.
>>>=20
>>> The very first question is does AODVv2 need key management at all? I =
would contend that it does, since we require to secure the signalling =
traffic for the routing algorithm. The aim here is therefore to purely =
assist in the security of the signalling traffic; security of user data =
that is forwarded once an AODVv2 route has been established is out of =
scope.
>>>=20
>>> Section 1 of BCP107 states that automated key management SHOULD be =
used. Thus my answer will be in favour of that unless I can contend =
otherwise.
>>>=20
>>> The guidelines in section 2 outline that automated key management =
derives short-term session keys between two parties. In the case of =
AODVv2, this would correspond to two routers that form or wish to form =
an adjacency.
>>>=20
>>> The guidelines state that the short-term keys may be derived from =
long-term keys, and that the dissemination of long term keys is out of =
scope of BCP107. I would envisage that an AODVv2 router, given that it =
would form ephemeral ad hoc networks with other routers as it went about =
its business, would be supplied with one or more long term keys for a =
period of time, to be determined by the system integrator, and that the =
long term keys would then be used to derive short term keys which are =
used in the forming of adjacencies plural.
>>>=20
>>> Section 2.1 of BCP107 describes the conditions under which automated =
key management MUST be used.
>>>=20
>>> - If a large number of static keys would have to be managed. It is =
not known how many routers could be deployed, but if this is aimed at ad =
hoc applications then the number of routers could quickly become large. =
I consider this condition is met.
>>>=20
>>> - Any stream cipher is used. This is a choice for the system =
integrator, but an AES based cipher is a real possibility. There is more =
likelihood this condition is met than not met.
>>>=20
>>> - An initialisation vector (IV) might be re-used. I am open to =
advice on this point.
>>>=20
>>> - Large amounts of data need to be encrypted in a short time. Even =
if there is no specific guidance on =E2=80=98large=E2=80=99, I do not =
consider this condition to be met, since signalling messages are likely =
to be short relative to the user data that could be exchanged.
>>>=20
>>> - Long-term session keys are used by more than two parties, =
including multicast applications. AODVv2 uses multicast extensively, and =
therefore I consider this condition to be met.
>>>=20
>>> - Device turnover is frequent. This is a certainty in ad hoc =
networks, so I consider this condition to be met.
>>>=20
>>> I believe the outcomes from section 2.1 guidance is more in favour =
of automated key management.
>>>=20
>>> However, to consider the guidance on manual key management in =
section 2.2 of BCP107, where such management may be reasonable:
>>>=20
>>> - the environment has very limited bandwidth or high round trip =
times. Some applications for AODVv2 may use very low bandwidths, perhaps =
for low-power sensor networks. The point is made that "public key =
systems require long exchanges and lots of computation=E2=80=9D. The =
AODVv2 author team believe that very low power hardware might be used by =
some implementors, which may give problems when being required to use =
public key exchanges. Such implementors need to carefully consider the =
tradeoff between the need for security and the need for very low power =
consumption. Such implementors should also consider whether some =
functions should be realised in hardware or software, and the resulting =
impact on system performance and power consumption.
>>>=20
>>> - the information being protected is of low value. I do not consider =
this condition to be met; on the contrary, the signalling traffic in =
AODVv2 is of high value to a potential attacker.
>>>=20
>>> - the scale of each deployment is limited. I consider that this is =
an unknown, but I also consider that we should engineer for larger =
networks with ephemeral connections rather than smaller ones.
>>>=20
>>> Discussion welcome.
>>>=20
>>> Regards
>>> John
>>>=20
>>>=20
>>>=20
>=20
>> On 27 Apr 2016, at 21:27, Christopher Dearlove =
 wrote:
>>=20
>> I really don't know what you are proposing. I think you have a great =
big can of worms here that hasn't been thought through.
>>=20
>> So AODVv2 is sending, as it's very first message, an RREQ. We want to =
authenticate this. How? You can't negotiate a key, you haven't got a =
route. You don't know who your neighbours are. You plan to multicast to =
them in fact, what's your key plan for that?
>>=20
>> If you say use long term key, what are you actually going to use the =
short term key for? And if you plan to exchange message with your =
neighbours, that rather preempts a significant part of your protocol =
(why establish bidirectionality when your key negotiation must have done =
that?)
>>=20
>> And then we've spent some time discussing end to end authentication. =
That doesn't work with short term keys for adjacencies only.
>>=20
>> We (OLSRv2) went through, more than once, a hard argument why =
automated key management wasn't appropriate here, and why the exceptions =
did apply.
>>=20
>> But in a nutshell (though this wasn't the argument we used, just why =
we needed it) how can you agree a key without communicating? How do you =
communicate more than one hop without a route? How do you authenticate =
the messages to create that route without a key?
>>=20
>> Something has to give. And in giving you might end up redesigning =
your whole protocol. Or using something quite clever that there's no =
hint of here. Or using the simplest fallback of a single shared key (our =
7183 default) which isn't automatically managed.
>>=20
>> --=20
>> Christopher Dearlove
>>=20
> On 27 Apr 2016, at 22:38, John Dowdell  =
wrote:
>=20
> OK so there=E2=80=99s a really big problem here. We were asked to run =
the guidance. Running the guidance gives the result below. In this case, =
the guidance is not giving a result that makes sense. The routers =
themselves are almost certainly on the move, there is no other reason =
why you would want to only determine the path at send time. You now have =
routers potentially from multiple organisations occasionally conversing =
with other routers. I do not see that a single shared key is going to =
pass muster; I certainly wouldn=E2=80=99t recommend such a use case.
>=20
> Regards
> John

One possible way forwards is to require all routers to have knowledge of =
some credentials of the other routers before AODVv2 can begin =
signalling. This isn=E2=80=99t so crazy as it might seem. Suppose such =
routers are installed in cars, and each manufacturer pre-loads the car =
with credentials of all the other manufacturers that it trusts for =
signalling purposes. Thus Ford (say) might pre-load credentials for =
Volkswagens. When a Ford and a Volkswagen meet, they already have some =
degree of trust, and therefore the burden of proof of identity in AODVv2 =
signalling is reduced, but not eliminated, because then we would be open =
to spoofing.

We are also here acting as part of a (hopefully) layered authentication =
system. The wireless devices will presumably be authenticated to each =
other, through some system that is suitable for the task in hand, and =
above routing there should be some checks on incoming user data to see =
if that is sensible.

Regards
John

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


From nobody Thu Apr 28 13:11:51 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 313F312D986 for ; Thu, 28 Apr 2016 13:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, 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 4p-4IQ8wVoGE for ; Thu, 28 Apr 2016 13:11:46 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 4F86712D994 for ; Thu, 28 Apr 2016 13:11:46 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id n129so2962005wmn.1 for ; Thu, 28 Apr 2016 13:11:46 -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=ZYc/+gfeR+OEa0I8WuV7kzbyQqK5UoDR8N9npulutCc=; b=alXcRSSDh2AC9ii1Aq4oum+1mU6DUvbe5cDnGoIhphCXrtnN9Omg2TnKUx43svUB3n OLOZJ4Dknen4NMefiS3KN/9Xg2WJ0qaQfbvSc6OBeWdRkGnp1PsB+aJjlsM+hVJiifXI lvzgZpE1FxpUv+zhEdUpAXwnFVvvzzX4EJYA6bWAUlDR0FQ0P8awD+On6ZN7ham3sDh4 Yl/DavcQMkZkvwuEb/IrLrPGsH/m0QWspBweDMtc7kVYP6GVZ+04one/46AKf3ANOCdu Q7kT1o9VIB4kRIDt3yY4/jdvOa7ObHkRERbIRT8ZHB38kJ6/2Vj+hix8YsMhZkqUFURd 3Icg==
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=ZYc/+gfeR+OEa0I8WuV7kzbyQqK5UoDR8N9npulutCc=; b=XokrxdoKt8MPtqZ5+Jg/5fHFagWWI5XWcZ+dY+SsUQpHeIiiP8V1f1DewQKPYwHSF4 l58f7pZ0iP3x3F9/08mqKo3xRrykDxwABEjQ18rbpUZGn/42AioCK37ja0sxhIQhFQVu y1/j2ygwuOdHTLc5dseKnW+I5bXTUZ+H1KwkQjOMwIQO/qqRPBMj32gR1n0Cz/JrgmLh mTXvAzXVJi77m+YDmkJzjbOHoEC/a/dBGmNPXknemfeHl2pvXGsjjBDvHppz3WCAowuU VfmIkWuTwX4CWJUSRDlbaTyLkM1IlZKO1kH5wJm43sEHZOTg+IUXSPKgzyYP6PCFUt6+ hF8A==
X-Gm-Message-State: AOPr4FX6KgO+mtEx6NXd6chKXqRtvxBxxGVKNS9/5F/nEYRL7VEz88f7h3s0Z9Nl9g/1ow==
X-Received: by 10.194.223.70 with SMTP id qs6mr17452113wjc.119.1461874304783;  Thu, 28 Apr 2016 13:11:44 -0700 (PDT)
Received: from [10.5.166.229] (82-132-245-177.dab.02.net. [82.132.245.177]) by smtp.gmail.com with ESMTPSA id ck9sm11278183wjc.22.2016.04.28.13.11.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2016 13:11:44 -0700 (PDT)
References: <937ABB81-CCD9-4FD0-A7CF-5114384B3B94@gmail.com> <8D383418-4CBF-49C6-9871-4E31042E29E5@mnemosyne.demon.co.uk>  <9E042F54-58E4-4C1B-8F7B-ECAD41341D48@gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <9E042F54-58E4-4C1B-8F7B-ECAD41341D48@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPhone Mail (13E238)
From: Christopher Dearlove 
Date: Thu, 28 Apr 2016 21:11:39 +0100
To: John Dowdell 
Archived-At: 
Cc: manet@ietf.org
Subject: Re: [manet] AODVv2 security: Key Management to BCP107
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, 28 Apr 2016 20:11:50 -0000

I really wouldn't be interested in a system in which each router had to have=
 knowledge of all other routers. Far too restrictive, and scales poorly. It j=
ust might fly as a solution. As the solution, definitely not.

Each router needing some preconfiguration, sure. See the IBS draft for examp=
le.

-- =20
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)

> On 28 Apr 2016, at 20:37, John Dowdell  wrote=
:
>=20
> By the way I have re-ordered the emails in this post to make it easier to r=
ead for flow.
>>=20
>>>> On 27 Apr 2016, at 21:10, John Dowdell  wr=
ote:
>>>>=20
>>>> Hi all
>>>>=20
>>>> As an AODVv2 co-author I=E2=80=99d like to propose this position regard=
ing key management against BCP107, one of the artefacts we are being asked t=
o state a position over. I=E2=80=99d also like to state that I=E2=80=99m ope=
n to contributions from others knowledgeable on this topic or who have been t=
his way previously.
>>>>=20
>>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka BCP1=
07 is the set of guidelines for choosing either automated or manual key mana=
gement for cryptographic purposes. It=E2=80=99s not a long read and guides t=
he reader through a set of tests as to whether automated or manual key manag=
ement would be suitable for the application in hand.
>>>>=20
>>>> The very first question is does AODVv2 need key management at all? I wo=
uld contend that it does, since we require to secure the signalling traffic f=
or the routing algorithm. The aim here is therefore to purely assist in the s=
ecurity of the signalling traffic; security of user data that is forwarded o=
nce an AODVv2 route has been established is out of scope.
>>>>=20
>>>> Section 1 of BCP107 states that automated key management SHOULD be used=
.. Thus my answer will be in favour of that unless I can contend otherwise.
>>>>=20
>>>> The guidelines in section 2 outline that automated key management deriv=
es short-term session keys between two parties. In the case of AODVv2, this w=
ould correspond to two routers that form or wish to form an adjacency.
>>>>=20
>>>> The guidelines state that the short-term keys may be derived from long-=
term keys, and that the dissemination of long term keys is out of scope of B=
CP107. I would envisage that an AODVv2 router, given that it would form ephe=
meral ad hoc networks with other routers as it went about its business, woul=
d be supplied with one or more long term keys for a period of time, to be de=
termined by the system integrator, and that the long term keys would then be=
 used to derive short term keys which are used in the forming of adjacBy the=
 way I have re-ordered the emails in this post to make it easier to read for=
 flow.
>>=20
>>>> On 27 Apr 2016, at 21:10, John Dowdell  wr=
ote:
>>>>=20
>>>> Hi all
>>>>=20
>>>> As an AODVv2 co-author I=E2=80=99d like to propose this position regard=
ing key management against BCP107, one of the artefacts we are being asked t=
o state a position over. I=E2=80=99d also like to state that I=E2=80=99m ope=
n to contributions from others knowledgeable on this topic or who have been t=
his way previously.
>>>>=20
>>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka BCP1=
07 is the set of guidelines for choosing either automated or manual key mana=
gement for cryptographic purposes. It=E2=80=99s not a long read and guides t=
he reader through a set of tests as to whether automated or manual key manag=
ement would be suitable for the application in hand.
>>>>=20
>>>> The very first question is does AODVv2 need key management at all? I wo=
uld contend that it does, since we require to secure the signalling traffic f=
or the routing algorithm. The aim here is therefore to purely assist in the s=
ecurity of the signalling traffic; security of user data that is forwarded o=
nce an AODVv2 route has been established is out of scope.
>>>>=20
>>>> Section 1 of BCP107 states that automated key management SHOULD be used=
. Thus my answer will be in favour of that unless I can contend otherwise.
>>>>=20
>>>> The guidelines in section 2 outline that automated key management deriv=
es short-term session keys between two parties. In the case of AODVv2, this w=
ould correspond to two routers that form or wish to form an adjacency.
>>>>=20
>>>> The guidelines state that the short-term keys may be derived from long-=
term keys, and that the dissemination of long term keys is out of scope of B=
CP107. I would envisage that an AODVv2 router, given that it would form ephe=
meral ad hoc networks with other routers as it went about its business, woul=
d be supplied with one or more long term keys for a period of time, to be de=
termined by the system integrator, and that the long term keys would then be=
 used to derive short term keys which are used in the forming of adjacencies=
 plural.
>>>>=20
>>>> Section 2.1 of BCP107 describes the conditions under which automated ke=
y management MUST be used.
>>>>=20
>>>> - If a large number of static keys would have to be managed. It is not k=
nown how many routers could be deployed, but if this is aimed at ad hoc appl=
ications then the number of routers could quickly become large. I consider t=
his condition is met.
>>>>=20
>>>> - Any stream cipher is used. This is a choice for the system integrator=
, but an AES based cipher is a real possibility. There is more likelihood th=
is condition is met than not met.
>>>>=20
>>>> - An initialisation vector (IV) might be re-used. I am open to advice o=
n this point.
>>>>=20
>>>> - Large amounts of data need to be encrypted in a short time. Even if t=
here is no specific guidance on =E2=80=98large=E2=80=99, I do not consider t=
his condition to be met, since signalling messages are likely to be short re=
lative to the user data that could be exchanged.
>>>>=20
>>>> - Long-term session keys are used by more than two parties, including m=
ulticast applications. AODVv2 uses multicast extensively, and therefore I co=
nsider this condition to be met.
>>>>=20
>>>> - Device turnover is frequent. This is a certainty in ad hoc networks, s=
o I consider this condition to be met.
>>>>=20
>>>> I believe the outcomes from section 2.1 guidance is more in favour of a=
utomated key management.
>>>>=20
>>>> However, to consider the guidance on manual key management in section 2=
.2 of BCP107, where such management may be reasonable:
>>>>=20
>>>> - the environment has very limited bandwidth or high round trip times. S=
ome applications for AODVv2 may use very low bandwidths, perhaps for low-pow=
er sensor networks. The point is made that "public key systems require long e=
xchanges and lots of computation=E2=80=9D. The AODVv2 author team believe th=
at very low power hardware might be used by some implementors, which may giv=
e problems when being required to use public key exchanges. Such implementor=
s need to carefully consider the tradeoff between the need for security and t=
he need for very low power consumption. Such implementors should also consid=
er whether some functions should be realised in hardware or software, and th=
e resulting impact on system performance and power consumption.
>>>>=20
>>>> - the information being protected is of low value. I do not consider th=
is condition to be met; on the contrary, the signalling traffic in AODVv2 is=
 of high value to a potential attacker.
>>>>=20
>>>> - the scale of each deployment is limited. I consider that this is an u=
nknown, but I also consider that we should engineer for larger networks with=
 ephemeral connections rather than smaller ones.
>>>>=20
>>>> Discussion welcome.
>>>>=20
>>>> Regards
>>>> John
>>>>=20
>>>>=20
>>>>=20
>>=20
>>> On 27 Apr 2016, at 21:27, Christopher Dearlove  wrote:
>>>=20
>>> I really don't know what you are proposing. I think you have a great big=
 can of worms here that hasn't been thought through.
>>>=20
>>> So AODVv2 is sending, as it's very first message, an RREQ. We want to au=
thenticate this. How? You can't negotiate a key, you haven't got a route. Yo=
u don't know who your neighbours are. You plan to multicast to them in fact,=
 what's your key plan for that?
>>>=20
>>> If you say use long term key, what are you actually going to use the sho=
rt term key for? And if you plan to exchange message with your neighbours, t=
hat rather preempts a significant part of your protocol (why establish bidir=
ectionality when your key negotiation must have done that?)
>>>=20
>>> And then we've spent some time discussing end to end authentication. Tha=
t doesn't work with short term keys for adjacencies only.
>>>=20
>>> We (OLSRv2) went through, more than once, a hard argument why automated k=
ey management wasn't appropriate here, and why the exceptions did apply.
>>>=20
>>> But in a nutshell (though this wasn't the argument we used, just why we n=
eeded it) how can you agree a key without communicating? How do you communic=
ate more than one hop without a route? How do you authenticate the messages t=
o create that route without a key?
>>>=20
>>> Something has to give. And in giving you might end up redesigning your w=
hole protocol. Or using something quite clever that there's no hint of here.=
 Or using the simplest fallback of a single shared key (our 7183 default) wh=
ich isn't automatically managed.
>>>=20
>>> --=20
>>> Christopher Dearlove
>>>=20
>> On 27 Apr 2016, at 22:38, John Dowdell  wrot=
e:
>>=20
>> OK so there=E2=80=99s a really big problem here. We were asked to run the=
 guidance. Running the guidance gives the result below. In this case, the gu=
idance is not giving a result that makes sense. The routers themselves are a=
lmost certainly on the move, there is no other reason why you would want to o=
nly determine the path at send time. You now have routers potentially from m=
ultiple organisations occasionally conversing with other routers. I do not s=
ee that a single shared key is going to pass muster; I certainly wouldn=E2=80=
=99t recommend such a use case.
>>=20
>> Regards
>> John
>=20
> One possible way forwards is to require all routers to have knowledge of s=
ome credentials of the other routers before AODVv2 can begin signalling. Thi=
s isn=E2=80=99t so crazy as it might seem. Suppose such routers are installe=
d in cars, and each manufacturer pre-loads the car with credentials of all t=
he other manufacturers that it trusts for signalling purposes. Thus Ford (sa=
y) might pre-load credentials for Volkswagens. When a Ford and a Volkswagen m=
eet, they already have some degree of trust, and therefore the burden of pro=
of of identity in AODVv2 signalling is reduced, but not eliminated, because t=
hen we would be open to spoofing.
>=20
> We are also here acting as part of a (hopefully) layered authentication sy=
stem. The wireless devices will presumably be authenticated to each other, t=
hrough some system that is suitable for the task in hand, and above routing t=
here should be some checks on incoming user data to see if that is sensible.=

>=20
> Regards
> John
>=20
>>>>=20
>>>> _______________________________________________
>>>> manet mailing list
>>>> manet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>=20
>>=20
>=20


From nobody Thu Apr 28 13:22: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 1585012D7FE for ; Thu, 28 Apr 2016 13:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=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 jBIV7uSnRhln for ; Thu, 28 Apr 2016 13:22:34 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 C33C412D581 for ; Thu, 28 Apr 2016 13:22:33 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id e201so3332405wme.0 for ; Thu, 28 Apr 2016 13:22:33 -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=jlYQDMAw7c5H1CWLwrpIAutqEf1s416WiEXJSq/MvgQ=; b=RE7fHLcb+VHpzqKZf8binjOXcvn4KvRvoZp8BB/a70nZHT+m9BXestBHxtiMnOOpYY XK0rs6E3zftbfLFQB9qlZyYm5vLx1aqMEeFzqj1fXB+XkRIGFmFFI9tZMCkWUMfHzGJl 8vBppIhP7kEp8Esv0clVuP9FDHJyYX73uqSc34NxjbZoZfcanQ81nIaO6531epKvHnUc uwqZ396VqtbXqxS0ZzWHFb4Ut1N8lLjGviLsOY4BcPAfVPVXVzLaqwAneCb4cWXzEEmC zAIzMQ2V8aSQVSSXn/zbyY9eAig/QBmOgroGiYucKL474ZXNbtKnHD4wlC/YywZYgEmI vcSw==
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=jlYQDMAw7c5H1CWLwrpIAutqEf1s416WiEXJSq/MvgQ=; b=OB233xcPAPlats0jSPbWshFnH3RszwMrM4L/lrm45kdGD+gOOVx8lfvlia0/RgF7zc Di9tIT3JECvouY3sOxP9fb2Hvo0Erp75KRt2m5o2C6i98DvEztbjRIRiztecNLp4k3y+ zTjOr7Chpi47ISZkNkBoJfRnWVM5TE6eOwZZjlioIxLPxIdVXpyOpe/SOdeIHJrhfEnT dS67aInxlPXCx00P7ZRl9/1Efs3IxzqV/bj8cQEUXt3OMGT6hxx8Fzq8gZlciSOpQz4F sjPgCSl4MShMTWbV5Y8k4Eej9iHAy8rEXHXlUj2xTW8eXGYNGoBWhVKEQCEOI3ZWkZGU fOHA==
X-Gm-Message-State: AOPr4FXHZHQ0ZNUATqGZVw0jCU0qGUNJ0GPLjVnE/zuje8FZ3U9xatECilAvpjUIPPl0kw==
X-Received: by 10.28.113.218 with SMTP id d87mr19696975wmi.52.1461874952215; Thu, 28 Apr 2016 13:22:32 -0700 (PDT)
Received: from johns-mbp-4.home (host86-151-226-34.range86-151.btcentralplus.com. [86.151.226.34]) by smtp.gmail.com with ESMTPSA id us3sm11300950wjc.41.2016.04.28.13.22.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Apr 2016 13:22:31 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DE82723E-2B5A-43DA-B477-B718EF01FF76"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Dowdell 
In-Reply-To: 
Date: Thu, 28 Apr 2016 21:22:56 +0100
Message-Id: <78037F3E-95E6-413D-933F-F238D82FED60@gmail.com>
References: <937ABB81-CCD9-4FD0-A7CF-5114384B3B94@gmail.com> <8D383418-4CBF-49C6-9871-4E31042E29E5@mnemosyne.demon.co.uk>  <9E042F54-58E4-4C1B-8F7B-ECAD41341D48@gmail.com> 
To: Christopher Dearlove 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: manet@ietf.org
Subject: Re: [manet] AODVv2 security: Key Management to BCP107
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, 28 Apr 2016 20:22:37 -0000

--Apple-Mail=_DE82723E-2B5A-43DA-B477-B718EF01FF76
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 28 Apr 2016, at 21:11, Christopher Dearlove =
 wrote:
>=20
> I really wouldn't be interested in a system in which each router had =
to have knowledge of all other routers. Far too restrictive, and scales =
poorly. It just might fly as a solution. As the solution, definitely =
not.

Not all individual routers, just the implementors. Implementor A knows =
of and (at least partly) trusts routers made by Implementor B. You could =
break that down by model and year of manufacture if you wanted.

John

>=20
> Each router needing some preconfiguration, sure. See the IBS draft for =
example.
>=20
> -- =20
> Christopher Dearlove
> christopher.dearlove@gmail.com  =
(iPhone)
> chris@mnemosyne.demon.co.uk  =
(home)
>=20
>> On 28 Apr 2016, at 20:37, John Dowdell > wrote:
>>=20
>> By the way I have re-ordered the emails in this post to make it =
easier to read for flow.
>>>=20
>>>>> On 27 Apr 2016, at 21:10, John Dowdell =
 wrote:
>>>>>=20
>>>>> Hi all
>>>>>=20
>>>>> As an AODVv2 co-author I=E2=80=99d like to propose this position =
regarding key management against BCP107, one of the artefacts we are =
being asked to state a position over. I=E2=80=99d also like to state =
that I=E2=80=99m open to contributions from others knowledgeable on this =
topic or who have been this way previously.
>>>>>=20
>>>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka =
BCP107 is the set of guidelines for choosing either automated or manual =
key management for cryptographic purposes. It=E2=80=99s not a long read =
and guides the reader through a set of tests as to whether automated or =
manual key management would be suitable for the application in hand.
>>>>>=20
>>>>> The very first question is does AODVv2 need key management at all? =
I would contend that it does, since we require to secure the signalling =
traffic for the routing algorithm. The aim here is therefore to purely =
assist in the security of the signalling traffic; security of user data =
that is forwarded once an AODVv2 route has been established is out of =
scope.
>>>>>=20
>>>>> Section 1 of BCP107 states that automated key management SHOULD be =
used.. Thus my answer will be in favour of that unless I can contend =
otherwise.
>>>>>=20
>>>>> The guidelines in section 2 outline that automated key management =
derives short-term session keys between two parties. In the case of =
AODVv2, this would correspond to two routers that form or wish to form =
an adjacency.
>>>>>=20
>>>>> The guidelines state that the short-term keys may be derived from =
long-term keys, and that the dissemination of long term keys is out of =
scope of BCP107. I would envisage that an AODVv2 router, given that it =
would form ephemeral ad hoc networks with other routers as it went about =
its business, would be supplied with one or more long term keys for a =
period of time, to be determined by the system integrator, and that the =
long term keys would then be used to derive short term keys which are =
used in the forming of adjacBy the way I have re-ordered the emails in =
this post to make it easier to read for flow.
>>>=20
>>>>> On 27 Apr 2016, at 21:10, John Dowdell =
> =
wrote:
>>>>>=20
>>>>> Hi all
>>>>>=20
>>>>> As an AODVv2 co-author I=E2=80=99d like to propose this position =
regarding key management against BCP107, one of the artefacts we are =
being asked to state a position over. I=E2=80=99d also like to state =
that I=E2=80=99m open to contributions from others knowledgeable on this =
topic or who have been this way previously.
>>>>>=20
>>>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka =
BCP107 is the set of guidelines for choosing either automated or manual =
key management for cryptographic purposes. It=E2=80=99s not a long read =
and guides the reader through a set of tests as to whether automated or =
manual key management would be suitable for the application in hand.
>>>>>=20
>>>>> The very first question is does AODVv2 need key management at all? =
I would contend that it does, since we require to secure the signalling =
traffic for the routing algorithm. The aim here is therefore to purely =
assist in the security of the signalling traffic; security of user data =
that is forwarded once an AODVv2 route has been established is out of =
scope.
>>>>>=20
>>>>> Section 1 of BCP107 states that automated key management SHOULD be =
used. Thus my answer will be in favour of that unless I can contend =
otherwise.
>>>>>=20
>>>>> The guidelines in section 2 outline that automated key management =
derives short-term session keys between two parties. In the case of =
AODVv2, this would correspond to two routers that form or wish to form =
an adjacency.
>>>>>=20
>>>>> The guidelines state that the short-term keys may be derived from =
long-term keys, and that the dissemination of long term keys is out of =
scope of BCP107. I would envisage that an AODVv2 router, given that it =
would form ephemeral ad hoc networks with other routers as it went about =
its business, would be supplied with one or more long term keys for a =
period of time, to be determined by the system integrator, and that the =
long term keys would then be used to derive short term keys which are =
used in the forming of adjacencies plural.
>>>>>=20
>>>>> Section 2.1 of BCP107 describes the conditions under which =
automated key management MUST be used.
>>>>>=20
>>>>> - If a large number of static keys would have to be managed. It is =
not known how many routers could be deployed, but if this is aimed at ad =
hoc applications then the number of routers could quickly become large. =
I consider this condition is met.
>>>>>=20
>>>>> - Any stream cipher is used. This is a choice for the system =
integrator, but an AES based cipher is a real possibility. There is more =
likelihood this condition is met than not met.
>>>>>=20
>>>>> - An initialisation vector (IV) might be re-used. I am open to =
advice on this point.
>>>>>=20
>>>>> - Large amounts of data need to be encrypted in a short time. Even =
if there is no specific guidance on =E2=80=98large=E2=80=99, I do not =
consider this condition to be met, since signalling messages are likely =
to be short relative to the user data that could be exchanged.
>>>>>=20
>>>>> - Long-term session keys are used by more than two parties, =
including multicast applications. AODVv2 uses multicast extensively, and =
therefore I consider this condition to be met.
>>>>>=20
>>>>> - Device turnover is frequent. This is a certainty in ad hoc =
networks, so I consider this condition to be met.
>>>>>=20
>>>>> I believe the outcomes from section 2.1 guidance is more in favour =
of automated key management.
>>>>>=20
>>>>> However, to consider the guidance on manual key management in =
section 2.2 of BCP107, where such management may be reasonable:
>>>>>=20
>>>>> - the environment has very limited bandwidth or high round trip =
times. Some applications for AODVv2 may use very low bandwidths, perhaps =
for low-power sensor networks. The point is made that "public key =
systems require long exchanges and lots of computation=E2=80=9D. The =
AODVv2 author team believe that very low power hardware might be used by =
some implementors, which may give problems when being required to use =
public key exchanges. Such implementors need to carefully consider the =
tradeoff between the need for security and the need for very low power =
consumption. Such implementors should also consider whether some =
functions should be realised in hardware or software, and the resulting =
impact on system performance and power consumption.
>>>>>=20
>>>>> - the information being protected is of low value. I do not =
consider this condition to be met; on the contrary, the signalling =
traffic in AODVv2 is of high value to a potential attacker.
>>>>>=20
>>>>> - the scale of each deployment is limited. I consider that this is =
an unknown, but I also consider that we should engineer for larger =
networks with ephemeral connections rather than smaller ones.
>>>>>=20
>>>>> Discussion welcome.
>>>>>=20
>>>>> Regards
>>>>> John
>>>>>=20
>>>>>=20
>>>>>=20
>>>=20
>>>> On 27 Apr 2016, at 21:27, Christopher Dearlove =
 wrote:
>>>>=20
>>>> I really don't know what you are proposing. I think you have a =
great big can of worms here that hasn't been thought through.
>>>>=20
>>>> So AODVv2 is sending, as it's very first message, an RREQ. We want =
to authenticate this. How? You can't negotiate a key, you haven't got a =
route. You don't know who your neighbours are. You plan to multicast to =
them in fact, what's your key plan for that?
>>>>=20
>>>> If you say use long term key, what are you actually going to use =
the short term key for? And if you plan to exchange message with your =
neighbours, that rather preempts a significant part of your protocol =
(why establish bidirectionality when your key negotiation must have done =
that?)
>>>>=20
>>>> And then we've spent some time discussing end to end =
authentication. That doesn't work with short term keys for adjacencies =
only.
>>>>=20
>>>> We (OLSRv2) went through, more than once, a hard argument why =
automated key management wasn't appropriate here, and why the exceptions =
did apply.
>>>>=20
>>>> But in a nutshell (though this wasn't the argument we used, just =
why we needed it) how can you agree a key without communicating? How do =
you communicate more than one hop without a route? How do you =
authenticate the messages to create that route without a key?
>>>>=20
>>>> Something has to give. And in giving you might end up redesigning =
your whole protocol. Or using something quite clever that there's no =
hint of here. Or using the simplest fallback of a single shared key (our =
7183 default) which isn't automatically managed.
>>>>=20
>>>> --=20
>>>> Christopher Dearlove
>>>>=20
>>> On 27 Apr 2016, at 22:38, John Dowdell  =
wrote:
>>>=20
>>> OK so there=E2=80=99s a really big problem here. We were asked to =
run the guidance. Running the guidance gives the result below. In this =
case, the guidance is not giving a result that makes sense. The routers =
themselves are almost certainly on the move, there is no other reason =
why you would want to only determine the path at send time. You now have =
routers potentially from multiple organisations occasionally conversing =
with other routers. I do not see that a single shared key is going to =
pass muster; I certainly wouldn=E2=80=99t recommend such a use case.
>>>=20
>>> Regards
>>> John
>>=20
>> One possible way forwards is to require all routers to have knowledge =
of some credentials of the other routers before AODVv2 can begin =
signalling. This isn=E2=80=99t so crazy as it might seem. Suppose such =
routers are installed in cars, and each manufacturer pre-loads the car =
with credentials of all the other manufacturers that it trusts for =
signalling purposes. Thus Ford (say) might pre-load credentials for =
Volkswagens. When a Ford and a Volkswagen meet, they already have some =
degree of trust, and therefore the burden of proof of identity in AODVv2 =
signalling is reduced, but not eliminated, because then we would be open =
to spoofing.
>>=20
>> We are also here acting as part of a (hopefully) layered =
authentication system. The wireless devices will presumably be =
authenticated to each other, through some system that is suitable for =
the task in hand, and above routing there should be some checks on =
incoming user data to see if that is sensible.
>>=20
>> Regards
>> John
>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> manet@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/manet


--Apple-Mail=_DE82723E-2B5A-43DA-B477-B718EF01FF76
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On 28 Apr 2016, at 21:11, Christopher Dearlove <christopher.dearlove@gmail.com> wrote:

I really wouldn't be interested in a system in =
which each router had to have knowledge of all other routers. Far too =
restrictive, and scales poorly. It just might fly as a solution. As the =
solution, definitely not.

Not all =
individual routers, just the implementors. Implementor A knows of and =
(at least partly) trusts routers made by Implementor B. You could break =
that down by model and year of manufacture if you wanted.

John


Each router needing some =
preconfiguration, sure. See the IBS draft for example.

--  
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)

On 28 Apr 2016, at 20:37, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

By the way I have re-ordered the emails in this post to make =
it easier to read for flow.

On 27 Apr 2016, at 21:10, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

Hi all

As an AODVv2 co-author =
I=E2=80=99d like to propose this position regarding key management =
against BCP107, one of the artefacts we are being asked to state a =
position over. I=E2=80=99d also like to state that I=E2=80=99m open to =
contributions from others knowledgeable on this topic or who have been =
this way previously.

If you=E2=80=99re not =
familiar (and I wasn=E2=80=99t), RFC4107 aka BCP107 is the set of =
guidelines for choosing either automated or manual key management for =
cryptographic purposes. It=E2=80=99s not a long read and guides the =
reader through a set of tests as to whether automated or manual key =
management would be suitable for the application in hand.

The very first question is does AODVv2 need =
key management at all? I would contend that it does, since we require to =
secure the signalling traffic for the routing algorithm. The aim here is =
therefore to purely assist in the security of the signalling traffic; =
security of user data that is forwarded once an AODVv2 route has been =
established is out of scope.

Section 1 of =
BCP107 states that automated key management SHOULD be used.. Thus my =
answer will be in favour of that unless I can contend otherwise.

The guidelines in section 2 outline that =
automated key management derives short-term session keys between two =
parties. In the case of AODVv2, this would correspond to two routers =
that form or wish to form an adjacency.

The =
guidelines state that the short-term keys may be derived from long-term =
keys, and that the dissemination of long term keys is out of scope of =
BCP107. I would envisage that an AODVv2 router, given that it would form =
ephemeral ad hoc networks with other routers as it went about its =
business, would be supplied with one or more long term keys for a period =
of time, to be determined by the system integrator, and that the long =
term keys would then be used to derive short term keys which are used in =
the forming of adjacBy the way I have re-ordered the emails in this post =
to make it easier to read for flow.

On 27 Apr =
2016, at 21:10, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

Hi all

As an AODVv2 co-author =
I=E2=80=99d like to propose this position regarding key management =
against BCP107, one of the artefacts we are being asked to state a =
position over. I=E2=80=99d also like to state that I=E2=80=99m open to =
contributions from others knowledgeable on this topic or who have been =
this way previously.

If you=E2=80=99re not =
familiar (and I wasn=E2=80=99t), RFC4107 aka BCP107 is the set of =
guidelines for choosing either automated or manual key management for =
cryptographic purposes. It=E2=80=99s not a long read and guides the =
reader through a set of tests as to whether automated or manual key =
management would be suitable for the application in hand.

The very first question is does AODVv2 need =
key management at all? I would contend that it does, since we require to =
secure the signalling traffic for the routing algorithm. The aim here is =
therefore to purely assist in the security of the signalling traffic; =
security of user data that is forwarded once an AODVv2 route has been =
established is out of scope.

Section 1 of =
BCP107 states that automated key management SHOULD be used. Thus my =
answer will be in favour of that unless I can contend otherwise.

The guidelines in section 2 outline that =
automated key management derives short-term session keys between two =
parties. In the case of AODVv2, this would correspond to two routers =
that form or wish to form an adjacency.

The =
guidelines state that the short-term keys may be derived from long-term =
keys, and that the dissemination of long term keys is out of scope of =
BCP107. I would envisage that an AODVv2 router, given that it would form =
ephemeral ad hoc networks with other routers as it went about its =
business, would be supplied with one or more long term keys for a period =
of time, to be determined by the system integrator, and that the long =
term keys would then be used to derive short term keys which are used in =
the forming of adjacencies plural.

Section =
2.1 of BCP107 describes the conditions under which automated key =
management MUST be used.

- If a large =
number of static keys would have to be managed. It is not known how many =
routers could be deployed, but if this is aimed at ad hoc applications =
then the number of routers could quickly become large. I consider this =
condition is met.

- Any stream cipher is =
used. This is a choice for the system integrator, but an AES based =
cipher is a real possibility. There is more likelihood this condition is =
met than not met.

- An initialisation =
vector (IV) might be re-used. I am open to advice on this point.

- Large amounts of data need to be encrypted =
in a short time. Even if there is no specific guidance on =E2=80=98large=E2=
=80=99, I do not consider this condition to be met, since signalling =
messages are likely to be short relative to the user data that could be =
exchanged.

- Long-term session keys are =
used by more than two parties, including multicast applications. AODVv2 =
uses multicast extensively, and therefore I consider this condition to =
be met.

- Device turnover is frequent. This =
is a certainty in ad hoc networks, so I consider this condition to be =
met.

I believe the outcomes from section =
2.1 guidance is more in favour of automated key management.

However, to consider the guidance on manual =
key management in section 2.2 of BCP107, where such management may be =
reasonable:

- the environment has very =
limited bandwidth or high round trip times. Some applications for AODVv2 =
may use very low bandwidths, perhaps for low-power sensor networks. The =
point is made that "public key systems require long exchanges and lots =
of computation=E2=80=9D. The AODVv2 author team believe that very low =
power hardware might be used by some implementors, which may give =
problems when being required to use public key exchanges. Such =
implementors need to carefully consider the tradeoff between the need =
for security and the need for very low power consumption. Such =
implementors should also consider whether some functions should be =
realised in hardware or software, and the resulting impact on system =
performance and power consumption.

- the =
information being protected is of low value. I do not consider this =
condition to be met; on the contrary, the signalling traffic in AODVv2 =
is of high value to a potential attacker.

- =
the scale of each deployment is limited. I consider that this is an =
unknown, but I also consider that we should engineer for larger networks =
with ephemeral connections rather than smaller ones.

Discussion welcome.

Regards
John




On 27 Apr 2016, at 21:27, Christopher Dearlove =
<chris@mnemosyne.demon.co.uk> wrote:

I really don't know what you are proposing. I think you have =
a great big can of worms here that hasn't been thought through.

So AODVv2 is sending, as it's very first =
message, an RREQ. We want to authenticate this. How? You can't negotiate =
a key, you haven't got a route. You don't know who your neighbours are. =
You plan to multicast to them in fact, what's your key plan for that?

If you say use long term key, what are you =
actually going to use the short term key for? And if you plan to =
exchange message with your neighbours, that rather preempts a =
significant part of your protocol (why establish bidirectionality when =
your key negotiation must have done that?)

And then we've spent some time discussing end to end =
authentication. That doesn't work with short term keys for adjacencies =
only.

We (OLSRv2) went through, more than =
once, a hard argument why automated key management wasn't appropriate =
here, and why the exceptions did apply.

But =
in a nutshell (though this wasn't the argument we used, just why we =
needed it) how can you agree a key without communicating? How do you =
communicate more than one hop without a route? How do you authenticate =
the messages to create that route without a key?

Something has to give. And in giving you might end up =
redesigning your whole protocol. Or using something quite clever that =
there's no hint of here. Or using the simplest fallback of a single =
shared key (our 7183 default) which isn't automatically managed.

-- 
Christopher =
Dearlove

On 27 Apr 2016, at =
22:38, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

OK so there=E2=80=99s a really big problem here. We were =
asked to run the guidance. Running the guidance gives the result below. =
In this case, the guidance is not giving a result that makes sense. The =
routers themselves are almost certainly on the move, there is no other =
reason why you would want to only determine the path at send time. You =
now have routers potentially from multiple organisations occasionally =
conversing with other routers. I do not see that a single shared key is =
going to pass muster; I certainly wouldn=E2=80=99t recommend such a use =
case.

Regards
John

One possible way forwards is to =
require all routers to have knowledge of some credentials of the other =
routers before AODVv2 can begin signalling. This isn=E2=80=99t so crazy =
as it might seem. Suppose such routers are installed in cars, and each =
manufacturer pre-loads the car with credentials of all the other =
manufacturers that it trusts for signalling purposes. Thus Ford (say) =
might pre-load credentials for Volkswagens. When a Ford and a Volkswagen =
meet, they already have some degree of trust, and therefore the burden =
of proof of identity in AODVv2 signalling is reduced, but not =
eliminated, because then we would be open to spoofing.

We are also here acting as part of a (hopefully) layered =
authentication system. The wireless devices will presumably be =
authenticated to each other, through some system that is suitable for =
the task in hand, and above routing there should be some checks on =
incoming user data to see if that is sensible.

Regards
John


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

=

--Apple-Mail=_DE82723E-2B5A-43DA-B477-B718EF01FF76--


From nobody Thu Apr 28 13:27: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 30DD012B04A for ; Thu, 28 Apr 2016 13:27:37 -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 Fk7K3g8nThqG for ; Thu, 28 Apr 2016 13:27:32 -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 D226A12D9D0 for ; Thu, 28 Apr 2016 13:27:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D149F24097D; Thu, 28 Apr 2016 13:27:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461875251; bh=R8bNPOOElp35RJ0mxniZs/dTflg+WCQqXcKtd6JOrak=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=L2+1/KHu531T0+nk1Y30TMPVssoYoG8bcip50UOqj7jJqlGWmYWt2lnhtI6RCSwUB pSdnIeD3aBZtZA3/I6jrwxLggjYb0mYwW+r2NB5yj8RrID8/TRzyp/LvVtA/EWBwlO fGW29FT5cXpoLTAQop9LhcgFK3ga4N/Jb735HRgg=
X-Virus-Scanned: Debian amavisd-new at maila2.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 maila2.tigertech.net (Postfix) with ESMTPSA id 51DFB25101D; Thu, 28 Apr 2016 13:27:30 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-D3338415-67A1-461A-8507-6BBF41225163
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPad Mail (13F51a)
In-Reply-To: <78037F3E-95E6-413D-933F-F238D82FED60@gmail.com>
Date: Thu, 28 Apr 2016 22:27:26 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <1D0F865B-CECE-4D49-B73E-C788E2B24478@thomasclausen.org>
References: <937ABB81-CCD9-4FD0-A7CF-5114384B3B94@gmail.com> <8D383418-4CBF-49C6-9871-4E31042E29E5@mnemosyne.demon.co.uk>  <9E042F54-58E4-4C1B-8F7B-ECAD41341D48@gmail.com>  <78037F3E-95E6-413D-933F-F238D82FED60@gmail.com>
To: John Dowdell 
Archived-At: 
Cc: Christopher Dearlove , manet@ietf.org
Subject: Re: [manet] AODVv2 security: Key Management to BCP107
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, 28 Apr 2016 20:27:37 -0000

--Apple-Mail-D3338415-67A1-461A-8507-6BBF41225163
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I must say, I fully share Chris' strong reservations. This is not the soluti=
on.=20

> On 28 Apr 2016, at 22:22, John Dowdell  wrote=
:
>=20
>=20
>> On 28 Apr 2016, at 21:11, Christopher Dearlove  wrote:
>>=20
>> I really wouldn't be interested in a system in which each router had to h=
ave knowledge of all other routers. Far too restrictive, and scales poorly. I=
t just might fly as a solution. As the solution, definitely not.
>=20
> Not all individual routers, just the implementors. Implementor A knows of a=
nd (at least partly) trusts routers made by Implementor B. You could break t=
hat down by model and year of manufacture if you wanted.
>=20
> John
>=20
>>=20
>> Each router needing some preconfiguration, sure. See the IBS draft for ex=
ample.
>>=20
>> -- =20
>> Christopher Dearlove
>> christopher.dearlove@gmail.com (iPhone)
>> chris@mnemosyne.demon.co.uk (home)
>>=20
>>> On 28 Apr 2016, at 20:37, John Dowdell  wro=
te:
>>>=20
>>> By the way I have re-ordered the emails in this post to make it easier t=
o read for flow.
>>>>=20
>>>>>> On 27 Apr 2016, at 21:10, John Dowdell  w=
rote:
>>>>>>=20
>>>>>> Hi all
>>>>>>=20
>>>>>> As an AODVv2 co-author I=E2=80=99d like to propose this position rega=
rding key management against BCP107, one of the artefacts we are being asked=
 to state a position over. I=E2=80=99d also like to state that I=E2=80=99m o=
pen to contributions from others knowledgeable on this topic or who have bee=
n this way previously.
>>>>>>=20
>>>>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka BC=
P107 is the set of guidelines for choosing either automated or manual key ma=
nagement for cryptographic purposes. It=E2=80=99s not a long read and guides=
 the reader through a set of tests as to whether automated or manual key man=
agement would be suitable for the application in hand.
>>>>>>=20
>>>>>> The very first question is does AODVv2 need key management at all? I w=
ould contend that it does, since we require to secure the signalling traffic=
 for the routing algorithm. The aim here is therefore to purely assist in th=
e security of the signalling traffic; security of user data that is forwarde=
d once an AODVv2 route has been established is out of scope.
>>>>>>=20
>>>>>> Section 1 of BCP107 states that automated key management SHOULD be us=
ed.. Thus my answer will be in favour of that unless I can contend otherwise=
.
>>>>>>=20
>>>>>> The guidelines in section 2 outline that automated key management der=
ives short-term session keys between two parties. In the case of AODVv2, thi=
s would correspond to two routers that form or wish to form an adjacency.
>>>>>>=20
>>>>>> The guidelines state that the short-term keys may be derived from lon=
g-term keys, and that the dissemination of long term keys is out of scope of=
 BCP107. I would envisage that an AODVv2 router, given that it would form ep=
hemeral ad hoc networks with other routers as it went about its business, wo=
uld be supplied with one or more long term keys for a period of time, to be d=
etermined by the system integrator, and that the long term keys would then b=
e used to derive short term keys which are used in the forming of adjacBy th=
e way I have re-ordered the emails in this post to make it easier to read fo=
r flow.
>>>>=20
>>>>>> On 27 Apr 2016, at 21:10, John Dowdell  w=
rote:
>>>>>>=20
>>>>>> Hi all
>>>>>>=20
>>>>>> As an AODVv2 co-author I=E2=80=99d like to propose this position rega=
rding key management against BCP107, one of the artefacts we are being asked=
 to state a position over. I=E2=80=99d also like to state that I=E2=80=99m o=
pen to contributions from others knowledgeable on this topic or who have bee=
n this way previously.
>>>>>>=20
>>>>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka BC=
P107 is the set of guidelines for choosing either automated or manual key ma=
nagement for cryptographic purposes. It=E2=80=99s not a long read and guides=
 the reader through a set of tests as to whether automated or manual key man=
agement would be suitable for the application in hand.
>>>>>>=20
>>>>>> The very first question is does AODVv2 need key management at all? I w=
ould contend that it does, since we require to secure the signalling traffic=
 for the routing algorithm. The aim here is therefore to purely assist in th=
e security of the signalling traffic; security of user data that is forwarde=
d once an AODVv2 route has been established is out of scope.
>>>>>>=20
>>>>>> Section 1 of BCP107 states that automated key management SHOULD be us=
ed. Thus my answer will be in favour of that unless I can contend otherwise.=

>>>>>>=20
>>>>>> The guidelines in section 2 outline that automated key management der=
ives short-term session keys between two parties. In the case of AODVv2, thi=
s would correspond to two routers that form or wish to form an adjacency.
>>>>>>=20
>>>>>> The guidelines state that the short-term keys may be derived from lon=
g-term keys, and that the dissemination of long term keys is out of scope of=
 BCP107. I would envisage that an AODVv2 router, given that it would form ep=
hemeral ad hoc networks with other routers as it went about its business, wo=
uld be supplied with one or more long term keys for a period of time, to be d=
etermined by the system integrator, and that the long term keys would then b=
e used to derive short term keys which are used in the forming of adjacencie=
s plural.
>>>>>>=20
>>>>>> Section 2.1 of BCP107 describes the conditions under which automated k=
ey management MUST be used.
>>>>>>=20
>>>>>> - If a large number of static keys would have to be managed. It is no=
t known how many routers could be deployed, but if this is aimed at ad hoc a=
pplications then the number of routers could quickly become large. I conside=
r this condition is met.
>>>>>>=20
>>>>>> - Any stream cipher is used. This is a choice for the system integrat=
or, but an AES based cipher is a real possibility. There is more likelihood t=
his condition is met than not met.
>>>>>>=20
>>>>>> - An initialisation vector (IV) might be re-used. I am open to advice=
 on this point.
>>>>>>=20
>>>>>> - Large amounts of data need to be encrypted in a short time. Even if=
 there is no specific guidance on =E2=80=98large=E2=80=99, I do not consider=
 this condition to be met, since signalling messages are likely to be short r=
elative to the user data that could be exchanged.
>>>>>>=20
>>>>>> - Long-term session keys are used by more than two parties, including=
 multicast applications. AODVv2 uses multicast extensively, and therefore I c=
onsider this condition to be met.
>>>>>>=20
>>>>>> - Device turnover is frequent. This is a certainty in ad hoc networks=
, so I consider this condition to be met.
>>>>>>=20
>>>>>> I believe the outcomes from section 2.1 guidance is more in favour of=
 automated key management.
>>>>>>=20
>>>>>> However, to consider the guidance on manual key management in section=
 2.2 of BCP107, where such management may be reasonable:
>>>>>>=20
>>>>>> - the environment has very limited bandwidth or high round trip times=
. Some applications for AODVv2 may use very low bandwidths, perhaps for low-=
power sensor networks. The point is made that "public key systems require lo=
ng exchanges and lots of computation=E2=80=9D. The AODVv2 author team believ=
e that very low power hardware might be used by some implementors, which may=
 give problems when being required to use public key exchanges. Such impleme=
ntors need to carefully consider the tradeoff between the need for security a=
nd the need for very low power consumption. Such implementors should also co=
nsider whether some functions should be realised in hardware or software, an=
d the resulting impact on system performance and power consumption.
>>>>>>=20
>>>>>> - the information being protected is of low value. I do not consider t=
his condition to be met; on the contrary, the signalling traffic in AODVv2 i=
s of high value to a potential attacker.
>>>>>>=20
>>>>>> - the scale of each deployment is limited. I consider that this is an=
 unknown, but I also consider that we should engineer for larger networks wi=
th ephemeral connections rather than smaller ones.
>>>>>>=20
>>>>>> Discussion welcome.
>>>>>>=20
>>>>>> Regards
>>>>>> John
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>=20
>>>>> On 27 Apr 2016, at 21:27, Christopher Dearlove  wrote:
>>>>>=20
>>>>> I really don't know what you are proposing. I think you have a great b=
ig can of worms here that hasn't been thought through.
>>>>>=20
>>>>> So AODVv2 is sending, as it's very first message, an RREQ. We want to a=
uthenticate this. How? You can't negotiate a key, you haven't got a route. Y=
ou don't know who your neighbours are. You plan to multicast to them in fact=
, what's your key plan for that?
>>>>>=20
>>>>> If you say use long term key, what are you actually going to use the s=
hort term key for? And if you plan to exchange message with your neighbours,=
 that rather preempts a significant part of your protocol (why establish bid=
irectionality when your key negotiation must have done that?)
>>>>>=20
>>>>> And then we've spent some time discussing end to end authentication. T=
hat doesn't work with short term keys for adjacencies only.
>>>>>=20
>>>>> We (OLSRv2) went through, more than once, a hard argument why automate=
d key management wasn't appropriate here, and why the exceptions did apply.
>>>>>=20
>>>>> But in a nutshell (though this wasn't the argument we used, just why w=
e needed it) how can you agree a key without communicating? How do you commu=
nicate more than one hop without a route? How do you authenticate the messag=
es to create that route without a key?
>>>>>=20
>>>>> Something has to give. And in giving you might end up redesigning your=
 whole protocol. Or using something quite clever that there's no hint of her=
e. Or using the simplest fallback of a single shared key (our 7183 default) w=
hich isn't automatically managed.
>>>>>=20
>>>>> --=20
>>>>> Christopher Dearlove
>>>>>=20
>>>> On 27 Apr 2016, at 22:38, John Dowdell  wr=
ote:
>>>>=20
>>>> OK so there=E2=80=99s a really big problem here. We were asked to run t=
he guidance. Running the guidance gives the result below. In this case, the g=
uidance is not giving a result that makes sense. The routers themselves are a=
lmost certainly on the move, there is no other reason why you would want to o=
nly determine the path at send time. You now have routers potentially from m=
ultiple organisations occasionally conversing with other routers. I do not s=
ee that a single shared key is going to pass muster; I certainly wouldn=E2=80=
=99t recommend such a use case.
>>>>=20
>>>> Regards
>>>> John
>>>=20
>>> One possible way forwards is to require all routers to have knowledge of=
 some credentials of the other routers before AODVv2 can begin signalling. T=
his isn=E2=80=99t so crazy as it might seem. Suppose such routers are instal=
led in cars, and each manufacturer pre-loads the car with credentials of all=
 the other manufacturers that it trusts for signalling purposes. Thus Ford (=
say) might pre-load credentials for Volkswagens. When a Ford and a Volkswage=
n meet, they already have some degree of trust, and therefore the burden of p=
roof of identity in AODVv2 signalling is reduced, but not eliminated, becaus=
e then we would be open to spoofing.
>>>=20
>>> We are also here acting as part of a (hopefully) layered authentication s=
ystem. The wireless devices will presumably be authenticated to each other, t=
hrough some system that is suitable for the task in hand, and above routing t=
here should be some checks on incoming user data to see if that is sensible.=

>>>=20
>>> Regards
>>> John
>>>=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-D3338415-67A1-461A-8507-6BBF41225163
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I must say, I fully share Chris' stron=
g reservations. This is not the solution. 

On 28 Apr 2=
016, at 22:22, John Dowdell <john.dowdell.ietf@gmail.com> wrote:


On 28 Apr 2016, at 21:11, Christopher Dearlove <christopher.dearlove@gmail.com>=
; wrote:

I really wouldn't be intere=
sted in a system in which each router had to have knowledge of all other rou=
ters. Far too restrictive, and scales poorly. It just might fly as a solutio=
n. As the solution, definitely not.
<=
div>
Not all individual routers, just the implementors. I=
mplementor A knows of and (at least partly) trusts routers made by Implement=
or B. You could break that down by model and year of manufacture if you want=
ed.

John


Each router needing some preconfigu=
ration, sure. See the IBS draft for example.

--  <=
br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon=
t-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans=
: auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;=
" class=3D"">Christ=
opher Dearlove
christopher.dearlove@gmail.com =
;(iPhone)
chris@mnemosyne.demon.co.uk (home)

On 28 Apr 2016, at 20:37, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

By the way I have re-ordered the emails in this post=
 to make it easier to read for flow.

On 27 Apr 2016, at 21:10, John Dowdell <john.dowdell.ietf@gmail.com<=
/a>> wrote:

Hi all

As an AODVv2 co-author I=E2=80=99d like to propose this position regardin=
g key management against BCP107, one of the artefacts we are being asked to s=
tate a position over. I=E2=80=99d also like to state that I=E2=80=99m open t=
o contributions from others knowledgeable on this topic or who have been thi=
s way previously.

If you=E2=80=99re not familia=
r (and I wasn=E2=80=99t), RFC4107 aka BCP107 is the set of guidelines for ch=
oosing either automated or manual key management for cryptographic purposes.=
 It=E2=80=99s not a long read and guides the reader through a set of tests a=
s to whether automated or manual key management would be suitable for the ap=
plication in hand.

The very first question is d=
oes AODVv2 need key management at all? I would contend that it does, since w=
e require to secure the signalling traffic for the routing algorithm. The ai=
m here is therefore to purely assist in the security of the signalling traff=
ic; security of user data that is forwarded once an AODVv2 route has been es=
tablished is out of scope.

Section 1 of BCP107 s=
tates that automated key management SHOULD be used.. Thus my answer will be i=
n favour of that unless I can contend otherwise.

The guidelines in section 2 outline that automated key management derives s=
hort-term session keys between two parties. In the case of AODVv2, this woul=
d correspond to two routers that form or wish to form an adjacency.

The guidelines state that the short-term keys may be de=
rived from long-term keys, and that the dissemination of long term keys is o=
ut of scope of BCP107. I would envisage that an AODVv2 router, given that it=
 would form ephemeral ad hoc networks with other routers as it went about it=
s business, would be supplied with one or more long term keys for a period o=
f time, to be determined by the system integrator, and that the long term ke=
ys would then be used to derive short term keys which are used in the formin=
g of adjacBy the way I have re-ordered the emails in this post to make it ea=
sier to read for flow.

=
On 27 Apr 2016, at 21:10, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

Hi all

As an AODVv2 co-aut=
hor I=E2=80=99d like to propose this position regarding key management again=
st BCP107, one of the artefacts we are being asked to state a position over.=
 I=E2=80=99d also like to state that I=E2=80=99m open to contributions from o=
thers knowledgeable on this topic or who have been this way previously.

If you=E2=80=99re not familiar (and I wasn=E2=80=99=
t), RFC4107 aka BCP107 is the set of guidelines for choosing either automate=
d or manual key management for cryptographic purposes. It=E2=80=99s not a lo=
ng read and guides the reader through a set of tests as to whether automated=
 or manual key management would be suitable for the application in hand.

The very first question is does AODVv2 need key man=
agement at all? I would contend that it does, since we require to secure the=
 signalling traffic for the routing algorithm. The aim here is therefore to p=
urely assist in the security of the signalling traffic; security of user dat=
a that is forwarded once an AODVv2 route has been established is out of scop=
e.

Section 1 of BCP107 states that automated ke=
y management SHOULD be used. Thus my answer will be in favour of that unless=
 I can contend otherwise.

The guidelines in sec=
tion 2 outline that automated key management derives short-term session keys=
 between two parties. In the case of AODVv2, this would correspond to two ro=
uters that form or wish to form an adjacency.

T=
he guidelines state that the short-term keys may be derived from long-term k=
eys, and that the dissemination of long term keys is out of scope of BCP107.=
 I would envisage that an AODVv2 router, given that it would form ephemeral a=
d hoc networks with other routers as it went about its business, would be su=
pplied with one or more long term keys for a period of time, to be determine=
d by the system integrator, and that the long term keys would then be used t=
o derive short term keys which are used in the forming of adjacencies plural=
.

Section 2.1 of BCP107 describes the condition=
s under which automated key management MUST be used.

- If a large number of static keys would have to be managed. It is not=
 known how many routers could be deployed, but if this is aimed at ad hoc ap=
plications then the number of routers could quickly become large. I consider=
 this condition is met.

- Any stream cipher is u=
sed. This is a choice for the system integrator, but an AES based cipher is a=
 real possibility. There is more likelihood this condition is met than not m=
et.

- An initialisation vector (IV) might be re=
-used. I am open to advice on this point.

- Lar=
ge amounts of data need to be encrypted in a short time. Even if there is no=
 specific guidance on =E2=80=98large=E2=80=99, I do not consider this condit=
ion to be met, since signalling messages are likely to be short relative to t=
he user data that could be exchanged.

- Long-te=
rm session keys are used by more than two parties, including multicast appli=
cations. AODVv2 uses multicast extensively, and therefore I consider this co=
ndition to be met.

- Device turnover is frequen=
t. This is a certainty in ad hoc networks, so I consider this condition to b=
e met.

I believe the outcomes from section 2.1 g=
uidance is more in favour of automated key management.

However, to consider the guidance on manual key management in sectio=
n 2.2 of BCP107, where such management may be reasonable:

- the environment has very limited bandwidth or high round trip ti=
mes. Some applications for AODVv2 may use very low bandwidths, perhaps for l=
ow-power sensor networks. The point is made that "public key systems require=
 long exchanges and lots of computation=E2=80=9D. The AODVv2 author team bel=
ieve that very low power hardware might be used by some implementors, which m=
ay give problems when being required to use public key exchanges. Such imple=
mentors need to carefully consider the tradeoff between the need for securit=
y and the need for very low power consumption. Such implementors should also=
 consider whether some functions should be realised in hardware or software,=
 and the resulting impact on system performance and power consumption.

- the information being protected is of low value. I=
 do not consider this condition to be met; on the contrary, the signalling t=
raffic in AODVv2 is of high value to a potential attacker.
- the scale of each deployment is limited. I consider that this i=
s an unknown, but I also consider that we should engineer for larger network=
s with ephemeral connections rather than smaller ones.

Discussion welcome.

Regards
John




On 27 A=
pr 2016, at 21:27, Christopher Dearlove <chris@mnemosyne.demon.co.uk> wrote:

I really don't know what you are proposing. I think yo=
u have a great big can of worms here that hasn't been thought through.

So AODVv2 is sending, as it's very first message, an=
 RREQ. We want to authenticate this. How? You can't negotiate a key, you hav=
en't got a route. You don't know who your neighbours are. You plan to multic=
ast to them in fact, what's your key plan for that?

If you say use long term key, what are you actually going to use the shor=
t term key for? And if you plan to exchange message with your neighbours, th=
at rather preempts a significant part of your protocol (why establish bidire=
ctionality when your key negotiation must have done that?)
And then we've spent some time discussing end to end authenticat=
ion. That doesn't work with short term keys for adjacencies only.

We (OLSRv2) went through, more than once, a hard argument w=
hy automated key management wasn't appropriate here, and why the exceptions d=
id apply.

But in a nutshell (though this wasn't=
 the argument we used, just why we needed it) how can you agree a key withou=
t communicating? How do you communicate more than one hop without a route? H=
ow do you authenticate the messages to create that route without a key?

Something has to give. And in giving you might end u=
p redesigning your whole protocol. Or using something quite clever that ther=
e's no hint of here. Or using the simplest fallback of a single shared key (=
our 7183 default) which isn't automatically managed.

-- 
Ch=
ristopher Dearlove

On 27 Apr 2016,=
 at 22:38, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

OK so there=E2=80=99s a really big problem here. We were asked to run t=
he guidance. Running the guidance gives the result below. In this case, the g=
uidance is not giving a result that makes sense. The routers themselves are a=
lmost certainly on the move, there is no other reason why you would want to o=
nly determine the path at send time. You now have routers potentially from m=
ultiple organisations occasionally conversing with other routers. I do not s=
ee that a single shared key is going to pass muster; I certainly wouldn=E2=80=
=99t recommend such a use case.

Regards
John

One possible way forwa=
rds is to require all routers to have knowledge of some credentials of the o=
ther routers before AODVv2 can begin signalling. This isn=E2=80=99t so crazy=
 as it might seem. Suppose such routers are installed in cars, and each manu=
facturer pre-loads the car with credentials of all the other manufacturers t=
hat it trusts for signalling purposes. Thus Ford (say) might pre-load creden=
tials for Volkswagens. When a Ford and a Volkswagen meet, they already have s=
ome degree of trust, and therefore the burden of proof of identity in AODVv2=
 signalling is reduced, but not eliminated, because then we would be open to=
 spoofing.

We are also here acting as part of a=
 (hopefully) layered authentication system. The wireless devices will presum=
ably be authenticated to each other, through some system that is suitable fo=
r the task in hand, and above routing there should be some checks on incomin=
g user data to see if that is sensible.

Regards=

John


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

__________=
_____________________________________
manet mailing list
manet@ietf.org
=
https://www.ie=
tf.org/mailman/listinfo/manet
=

--Apple-Mail-D3338415-67A1-461A-8507-6BBF41225163--


From nobody Thu Apr 28 13:44: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 1FD0D12D9ED for ; Thu, 28 Apr 2016 13:44:41 -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 VAokutzrpdvf for ; Thu, 28 Apr 2016 13:44:32 -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 7344F12D9DC for ; Thu, 28 Apr 2016 13:44:31 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id j11so110461002lfb.1 for ; Thu, 28 Apr 2016 13:44:31 -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=UhDPvWWb4HvxJEDXyB221kwcFBexAhEhtrOTEkdTBQk=; b=ukdYDOfpOinICcWNshZAhYHWEsKMRiTrRAum3ml60EPOeLWk9spuGkKPUVVgyWaXiu LhAILfGt8BtQXiA5kTSXxvjJuUxhazCmakIMLOPcnrYlSA3O+BIN3k0Ul+vGegBlgs1c 8xCFVkRODRA9+i8+4BU4dhJNpMSCRWZfsD91Y1jqXa/a/RuDMxj7p4Nr3TNTZ9ZzcIIP Pb1LYpYSBNzbp86skVIY2DjNrNbww3B331zVK8x7p8bOAceleP22DdHheu+N1XGmru1f QEjtARjj0kSBU+AcuHt22WRjJZrtSJ6R1OEv8NBZPq2ocn7zHjUmHpYIXOY8/146uc5Z uoQw==
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=UhDPvWWb4HvxJEDXyB221kwcFBexAhEhtrOTEkdTBQk=; b=ZEJcfnj6edEpKdeeXysDFcEEVssyGkxyBk3zn3SCG4dHiahmIptN9OWwKDz7JBmkcq JLaC6vJ8Gzljb4qGFXHjYtDl+xevfBiezlXKdQaOOcEgjk9WK64ngtF9ZpdnCz1SzktL rbHxYt9701C71SUq276XHlQV4PxAK3gTJROzemUaa0QuRpgjMtajvAn7+xnWVXbowDEZ XerocEvcnLC/pScKiWL8iZl9u3Rbq7ZAO+W3e81JjjDLeC6dCclXtOoRAuFTwed0ouAG I1LMnK4dDKsPuARASCYSGpSCEhTeJ/S/SzxumCu0zu9vzi/wRzQc12p1TYH75cUBhuZj zHFw==
X-Gm-Message-State: AOPr4FXxY+QzB5xfVIfSiecwAw+cATM4pw5sgEJjbUNhX80KdyYl5GtM7rwWCR5JSqI66xae36oN5pb7UoTJVg==
MIME-Version: 1.0
X-Received: by 10.112.129.162 with SMTP id nx2mr128907lbb.43.1461876269353; Thu, 28 Apr 2016 13:44:29 -0700 (PDT)
Sender: yi.jiazi@gmail.com
Received: by 10.114.77.4 with HTTP; Thu, 28 Apr 2016 13:44:29 -0700 (PDT)
In-Reply-To: 
References:  <1F5AB0F1-0B92-4A66-A08F-A2BF8B414D9F@thomasclausen.org>  <5EE270D1-30EF-42A9-BF11-7F4267967AC0@fu-berlin.de>  <3F51EFE1-7D89-49E9-8B1B-87C02D7A705D@thomasclausen.org>  <0E2F32E3-A198-48BA-A712-F9F59F8BBAA0@thomasclausen.org>        <84C7FCA8-B122-4534-ACB7-0C799F14A569@thomasclausen.org>         
Date: Thu, 28 Apr 2016 22:44:29 +0200
X-Google-Sender-Auth: 2RPH5Im787bWubB_B0KQc6Xa3bA
Message-ID: 
From: Jiazi YI 
To: Justin Dean 
Content-Type: multipart/alternative; boundary=047d7b3a8f4abe142405319197b4
Archived-At: 
Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , Mobile Ad Hoc Networks mailing list , Victoria Mercieca 
Subject: Re: [manet] Message integrity and message mutability (was RE: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 28 Apr 2016 20:44:43 -0000

--047d7b3a8f4abe142405319197b4
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 28, 2016 at 7:08 PM, Justin Dean  wrote:

>
>
> On Thu, Apr 28, 2016 at 12:55 PM, Victoria Mercieca 
> wrote:
>
>> Hi Jiazi,
>>
>> Thanks for your response. So you think we could change back to sending
>> RREP by unicast (letting an implementation handle whether this requires a
>> route to the neighbor to be installed temporarily)? We would have to also
>> send a separate message to request an acknowledgement, but this could also
>> be unicast and could therefore potentially be sent in the same RFC5444
>> packet.
>>
>> Anyone have any objections?
>>
>
> I don't think it's a good idea to "temporarily" add a route that is not
> known to be bi-directional yet.  The timing of correctly adding and
> removing the route with different mediums and restricting the route to only
> that one packet doesn't seem like a workable solution.    Sending it
> unicast with a raw type socket or pcap out of a known interface sure.  IMO
> a route shouldn't be added until the link is confirmed bi-directional.
>

The point that I want to make is, it's possible to send unicast RREP even
without a route being set -- let the implementor decide which is the best
way.
Regarding the information of requesting RREP-ACK: it can be a flag (which
is much easier to secure than a optional address field), or another RFC5444
message.
Someone probably doesn't like such flags (because it must be zeroed when
calculating ICV), but I don't have strong opinion on that.

Jiazi


>
> Justin
>
>

--047d7b3a8f4abe142405319197b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Apr 28, 2016 at 7:08 PM, Justin Dean <bebemaster@gmail.com<=
/a>> wrote:

On Thu, Apr 28, 2016 at 12:55 PM, Victoria Mercieca <=
;vmercieca0@gmail=
.com> wrote:
Hi Jiazi,

Thanks for your response. So you think we c=
ould change back to sending RREP by unicast (letting an implementation hand=
le whether this requires a route to the neighbor to be installed temporaril=
y)? We would have to also send a separate message to request an acknowledge=
ment, but this could also be unicast and could therefore potentially be sen=
t in the same RFC5444 packet.=C2=A0

Anyone have an=
y objections?

I don't think it&=
#39;s a good idea to "temporarily" add a route that is not known =
to be bi-directional yet.=C2=A0 The timing of correctly adding and removing=
 the route with different mediums and restricting the route to only that on=
e packet doesn't seem like a workable solution. =C2=A0 =C2=A0Sending it=
 unicast with a raw type socket or pcap out of a known interface sure.=C2=
=A0 IMO a route shouldn't be added until the link is confirmed bi-direc=
tional.

The point t=
hat I want to make is, it's possible to send unicast RREP even without =
a route being set -- let the implementor decide which is the best way. =C2=
=A0
Regarding the information of requesting RREP-ACK: it can be a=
 flag (which is much easier to secure than a optional address field), or an=
other RFC5444 message.=C2=A0
Someone probably doesn't like su=
ch flags (because it must be zeroed when calculating ICV), but I don't =
have strong opinion on that.=C2=A0

Jiazi
=C2=A0

Justin
<=
br>





--047d7b3a8f4abe142405319197b4--


From nobody Thu Apr 28 13:48: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 E3EE612B04A for ; Thu, 28 Apr 2016 13:48:42 -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 9W9VzvmK8dvU for ; Thu, 28 Apr 2016 13:48:39 -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 B6FDB12B069 for ; Thu, 28 Apr 2016 13:48:38 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id n129so4032356wmn.1 for ; Thu, 28 Apr 2016 13:48:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=x2xbRGI/xmP+RojbDXQ0/Cxoo/wXdzf+XfSub7Y8snU=; b=wqCJhn3EezcMvvO7w6ljClhv0nZnPY9y9/qW6cuc1F9g/wlVp59xzhLqdxseNEs/Fl e6cKyiK0Zo5bE4PRfXskDSmj6toF78g2lh4hoyby1tb5D4poji8HW9z2ggjLmMG67ACn H9ilyD671FgiDQsxqHwpkTs8tt752PUCHhhYbUpkK4gsJn7zjYkMqr8Hpe5f+DL6tGAb /zlnEupc/MnI0HKlQAfFjPyjjSZAamRz1HWujkHb4JM8aWh2e2ilGqdWtkhBerwvwux0 DNBjzYYhSvipGigV/8CAzWBpPcX8dG9GYtG73dbiN+0qMbNcofI+7MzGQBTpUDIrJ7nR b1Aw==
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 :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=x2xbRGI/xmP+RojbDXQ0/Cxoo/wXdzf+XfSub7Y8snU=; b=NR1DmJQVMWQBfvy5ntGAhkbJlpKnMreLYEFrLzivdXzQNHtAozlpjW3EdZr2WlnkQ9 6XR4MYPHbWYON/cY9BW24SlgX1nLaNV14MPifdyVStA3ZsYHjmvpBbAtGp9FN9kX11Zx etRLhtET2H5zQNE6MJVIeFxwJcsMlw3rYXKBsS+SllGDWAtZk7ySeXe50MG0ZQYHlevw 7UCqFj/sg/BID0N5DsPqKM98aSbhiCeFSt0STxmilrYcvdTYXi3/Hr0fQs9dqFDOZSAR lpozQC6TKTqA0QrhqqiRla9F6CVU+hLR0SCbFUuLhukkyXjsTHTcKI7frnW/vjy3ojBq 6fPA==
X-Gm-Message-State: AOPr4FVlIDI2QPUB1DqGf+UdCa4s/2ByB4HvWnFKPbOBzU4axalEUNhU6uv8F0i6ipJyAQ==
X-Received: by 10.28.35.201 with SMTP id j192mr25963108wmj.18.1461876517274; Thu, 28 Apr 2016 13:48:37 -0700 (PDT)
Received: from [10.5.166.229] (82-132-245-177.dab.02.net. [82.132.245.177]) by smtp.gmail.com with ESMTPSA id w77sm36537300wmw.10.2016.04.28.13.48.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2016 13:48:36 -0700 (PDT)
References: <937ABB81-CCD9-4FD0-A7CF-5114384B3B94@gmail.com> <8D383418-4CBF-49C6-9871-4E31042E29E5@mnemosyne.demon.co.uk>  <9E042F54-58E4-4C1B-8F7B-ECAD41341D48@gmail.com>  <78037F3E-95E6-413D-933F-F238D82FED60@gmail.com>
In-Reply-To: <78037F3E-95E6-413D-933F-F238D82FED60@gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary=Apple-Mail-7D242298-36A5-4DC5-A242-97B214FF4E66
Message-Id: <363D6BE7-242E-4AA5-9C88-4D740AD7B3E2@gmail.com>
X-Mailer: iPhone Mail (13E238)
From: Christopher Dearlove 
Date: Thu, 28 Apr 2016 21:48:30 +0100
To: John Dowdell 
Archived-At: 
Cc: Christopher Dearlove , manet@ietf.org
Subject: Re: [manet] AODVv2 security: Key Management to BCP107
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, 28 Apr 2016 20:48:43 -0000

--Apple-Mail-7D242298-36A5-4DC5-A242-97B214FF4E66
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Not interested in that case either. Some might be, sure. But it would make a=
 very poor model as your baseline. A single shared key in your network, whic=
h I agreed earlier wasn't a great model, is still better than that.

Why? Because manufacturer isn't aligned to any trust model I'd have. General=
ly everyone - people I trust, people I don't trust - all buy from the same m=
anufacturers.

--=20
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)



-- =20
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)
> On 28 Apr 2016, at 21:22, John Dowdell  wrote=
:
>=20
>=20
>> On 28 Apr 2016, at 21:11, Christopher Dearlove  wrote:
>>=20
>> I really wouldn't be interested in a system in which each router had to h=
ave knowledge of all other routers. Far too restrictive, and scales poorly. I=
t just might fly as a solution. As the solution, definitely not.
>=20
> Not all individual routers, just the implementors. Implementor A knows of a=
nd (at least partly) trusts routers made by Implementor B. You could break t=
hat down by model and year of manufacture if you wanted.
>=20
> John
>=20
>>=20
>> Each router needing some preconfiguration, sure. See the IBS draft for ex=
ample.
>>=20
>> -- =20
>> Christopher Dearlove
>> christopher.dearlove@gmail.com (iPhone)
>> chris@mnemosyne.demon.co.uk (home)
>>=20
>>> On 28 Apr 2016, at 20:37, John Dowdell  wro=
te:
>>>=20
>>> By the way I have re-ordered the emails in this post to make it easier t=
o read for flow.
>>>>=20
>>>>>> On 27 Apr 2016, at 21:10, John Dowdell  w=
rote:
>>>>>>=20
>>>>>> Hi all
>>>>>>=20
>>>>>> As an AODVv2 co-author I=E2=80=99d like to propose this position rega=
rding key management against BCP107, one of the artefacts we are being asked=
 to state a position over. I=E2=80=99d also like to state that I=E2=80=99m o=
pen to contributions from others knowledgeable on this topic or who have bee=
n this way previously.
>>>>>>=20
>>>>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka BC=
P107 is the set of guidelines for choosing either automated or manual key ma=
nagement for cryptographic purposes. It=E2=80=99s not a long read and guides=
 the reader through a set of tests as to whether automated or manual key man=
agement would be suitable for the application in hand.
>>>>>>=20
>>>>>> The very first question is does AODVv2 need key management at all? I w=
ould contend that it does, since we require to secure the signalling traffic=
 for the routing algorithm. The aim here is therefore to purely assist in th=
e security of the signalling traffic; security of user data that is forwarde=
d once an AODVv2 route has been established is out of scope.
>>>>>>=20
>>>>>> Section 1 of BCP107 states that automated key management SHOULD be us=
ed.. Thus my answer will be in favour of that unless I can contend otherwise=
.
>>>>>>=20
>>>>>> The guidelines in section 2 outline that automated key management der=
ives short-term session keys between two parties. In the case of AODVv2, thi=
s would correspond to two routers that form or wish to form an adjacency.
>>>>>>=20
>>>>>> The guidelines state that the short-term keys may be derived from lon=
g-term keys, and that the dissemination of long term keys is out of scope of=
 BCP107. I would envisage that an AODVv2 router, given that it would form ep=
hemeral ad hoc networks with other routers as it went about its business, wo=
uld be supplied with one or more long term keys for a period of time, to be d=
etermined by the system integrator, and that the long term keys would then b=
e used to derive short term keys which are used in the forming of adjacBy th=
e way I have re-ordered the emails in this post to make it easier to read fo=
r flow.
>>>>=20
>>>>>> On 27 Apr 2016, at 21:10, John Dowdell  w=
rote:
>>>>>>=20
>>>>>> Hi all
>>>>>>=20
>>>>>> As an AODVv2 co-author I=E2=80=99d like to propose this position rega=
rding key management against BCP107, one of the artefacts we are being asked=
 to state a position over. I=E2=80=99d also like to state that I=E2=80=99m o=
pen to contributions from others knowledgeable on this topic or who have bee=
n this way previously.
>>>>>>=20
>>>>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka BC=
P107 is the set of guidelines for choosing either automated or manual key ma=
nagement for cryptographic purposes. It=E2=80=99s not a long read and guides=
 the reader through a set of tests as to whether automated or manual key man=
agement would be suitable for the application in hand.
>>>>>>=20
>>>>>> The very first question is does AODVv2 need key management at all? I w=
ould contend that it does, since we require to secure the signalling traffic=
 for the routing algorithm. The aim here is therefore to purely assist in th=
e security of the signalling traffic; security of user data that is forwarde=
d once an AODVv2 route has been established is out of scope.
>>>>>>=20
>>>>>> Section 1 of BCP107 states that automated key management SHOULD be us=
ed. Thus my answer will be in favour of that unless I can contend otherwise.=

>>>>>>=20
>>>>>> The guidelines in section 2 outline that automated key management der=
ives short-term session keys between two parties. In the case of AODVv2, thi=
s would correspond to two routers that form or wish to form an adjacency.
>>>>>>=20
>>>>>> The guidelines state that the short-term keys may be derived from lon=
g-term keys, and that the dissemination of long term keys is out of scope of=
 BCP107. I would envisage that an AODVv2 router, given that it would form ep=
hemeral ad hoc networks with other routers as it went about its business, wo=
uld be supplied with one or more long term keys for a period of time, to be d=
etermined by the system integrator, and that the long term keys would then b=
e used to derive short term keys which are used in the forming of adjacencie=
s plural.
>>>>>>=20
>>>>>> Section 2.1 of BCP107 describes the conditions under which automated k=
ey management MUST be used.
>>>>>>=20
>>>>>> - If a large number of static keys would have to be managed. It is no=
t known how many routers could be deployed, but if this is aimed at ad hoc a=
pplications then the number of routers could quickly become large. I conside=
r this condition is met.
>>>>>>=20
>>>>>> - Any stream cipher is used. This is a choice for the system integrat=
or, but an AES based cipher is a real possibility. There is more likelihood t=
his condition is met than not met.
>>>>>>=20
>>>>>> - An initialisation vector (IV) might be re-used. I am open to advice=
 on this point.
>>>>>>=20
>>>>>> - Large amounts of data need to be encrypted in a short time. Even if=
 there is no specific guidance on =E2=80=98large=E2=80=99, I do not consider=
 this condition to be met, since signalling messages are likely to be short r=
elative to the user data that could be exchanged.
>>>>>>=20
>>>>>> - Long-term session keys are used by more than two parties, including=
 multicast applications. AODVv2 uses multicast extensively, and therefore I c=
onsider this condition to be met.
>>>>>>=20
>>>>>> - Device turnover is frequent. This is a certainty in ad hoc networks=
, so I consider this condition to be met.
>>>>>>=20
>>>>>> I believe the outcomes from section 2.1 guidance is more in favour of=
 automated key management.
>>>>>>=20
>>>>>> However, to consider the guidance on manual key management in section=
 2.2 of BCP107, where such management may be reasonable:
>>>>>>=20
>>>>>> - the environment has very limited bandwidth or high round trip times=
. Some applications for AODVv2 may use very low bandwidths, perhaps for low-=
power sensor networks. The point is made that "public key systems require lo=
ng exchanges and lots of computation=E2=80=9D. The AODVv2 author team believ=
e that very low power hardware might be used by some implementors, which may=
 give problems when being required to use public key exchanges. Such impleme=
ntors need to carefully consider the tradeoff between the need for security a=
nd the need for very low power consumption. Such implementors should also co=
nsider whether some functions should be realised in hardware or software, an=
d the resulting impact on system performance and power consumption.
>>>>>>=20
>>>>>> - the information being protected is of low value. I do not consider t=
his condition to be met; on the contrary, the signalling traffic in AODVv2 i=
s of high value to a potential attacker.
>>>>>>=20
>>>>>> - the scale of each deployment is limited. I consider that this is an=
 unknown, but I also consider that we should engineer for larger networks wi=
th ephemeral connections rather than smaller ones.
>>>>>>=20
>>>>>> Discussion welcome.
>>>>>>=20
>>>>>> Regards
>>>>>> John
>>>>=20
>>>>> On 27 Apr 2016, at 21:27, Christopher Dearlove  wrote:
>>>>>=20
>>>>> I really don't know what you are proposing. I think you have a great b=
ig can of worms here that hasn't been thought through.
>>>>>=20
>>>>> So AODVv2 is sending, as it's very first message, an RREQ. We want to a=
uthenticate this. How? You can't negotiate a key, you haven't got a route. Y=
ou don't know who your neighbours are. You plan to multicast to them in fact=
, what's your key plan for that?
>>>>>=20
>>>>> If you say use long term key, what are you actually going to use the s=
hort term key for? And if you plan to exchange message with your neighbours,=
 that rather preempts a significant part of your protocol (why establish bid=
irectionality when your key negotiation must have done that?)
>>>>>=20
>>>>> And then we've spent some time discussing end to end authentication. T=
hat doesn't work with short term keys for adjacencies only.
>>>>>=20
>>>>> We (OLSRv2) went through, more than once, a hard argument why automate=
d key management wasn't appropriate here, and why the exceptions did apply.
>>>>>=20
>>>>> But in a nutshell (though this wasn't the argument we used, just why w=
e needed it) how can you agree a key without communicating? How do you commu=
nicate more than one hop without a route? How do you authenticate the messag=
es to create that route without a key?
>>>>>=20
>>>>> Something has to give. And in giving you might end up redesigning your=
 whole protocol. Or using something quite clever that there's no hint of her=
e. Or using the simplest fallback of a single shared key (our 7183 default) w=
hich isn't automatically managed.
>>>>>=20
>>>>> --=20
>>>>> Christopher Dearlove
>>>> On 27 Apr 2016, at 22:38, John Dowdell  wr=
ote:
>>>>=20
>>>> OK so there=E2=80=99s a really big problem here. We were asked to run t=
he guidance. Running the guidance gives the result below. In this case, the g=
uidance is not giving a result that makes sense. The routers themselves are a=
lmost certainly on the move, there is no other reason why you would want to o=
nly determine the path at send time. You now have routers potentially from m=
ultiple organisations occasionally conversing with other routers. I do not s=
ee that a single shared key is going to pass muster; I certainly wouldn=E2=80=
=99t recommend such a use case.
>>>>=20
>>>> Regards
>>>> John
>>>=20
>>> One possible way forwards is to require all routers to have knowledge of=
 some credentials of the other routers before AODVv2 can begin signalling. T=
his isn=E2=80=99t so crazy as it might seem. Suppose such routers are instal=
led in cars, and each manufacturer pre-loads the car with credentials of all=
 the other manufacturers that it trusts for signalling purposes. Thus Ford (=
say) might pre-load credentials for Volkswagens. When a Ford and a Volkswage=
n meet, they already have some degree of trust, and therefore the burden of p=
roof of identity in AODVv2 signalling is reduced, but not eliminated, becaus=
e then we would be open to spoofing.
>>>=20
>>> We are also here acting as part of a (hopefully) layered authentication s=
ystem. The wireless devices will presumably be authenticated to each other, t=
hrough some system that is suitable for the task in hand, and above routing t=
here should be some checks on incoming user data to see if that is sensible.=

>>>=20
>>> Regards
>>> John
>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> manet mailing list
>>>>>> manet@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/manet
>=20

--Apple-Mail-7D242298-36A5-4DC5-A242-97B214FF4E66
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Not interest=
ed in that case either. Some might be, sure. But it would make a very poor m=
odel as your baseline. A single shared key in your network, which I agreed e=
arlier wasn't a great model, is still better than that.

=

Why? Because manufacturer isn't aligned to any trust model I'd have. Ge=
nerally everyone - people I trust, people I don't trust - all buy from the s=
ame manufacturers.

-- 
Christopher Dearlove



--  Christopher Dearlove
On 28 Apr 2016, at 21:22, John Dowdell <john.dowdell.ietf@gmail.com> wrote:



On 28 A=
pr 2016, at 21:11, Christopher Dearlove <christopher.dearlove@gmail.com> wrote:
I really wouldn't be interested in a=
 system in which each router had to have knowledge of all other routers. Far=
 too restrictive, and scales poorly. It just might fly as a solution. As the=
 solution, definitely not.

Not all individual routers, just the implementors. Implement=
or A knows of and (at least partly) trusts routers made by Implementor B. Yo=
u could break that down by model and year of manufacture if you wanted.

John


Each router needing some preconfiguration, s=
ure. See the IBS draft for example.

--  
Christopher Dearl=
ove
christopher.dearlove@gmail.com (iP=
hone)
chris@mnemosyne.demon.co.uk (home)=


On 28=
 Apr 2016, at 20:37, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

By the way I have re-ordered the emails in this post to make=
 it easier to read for flow.

On 27 Apr 2016, at 21:10, John Dowdell <john.dowdell.ietf@gmail.com>=
 wrote:

Hi all

As a=
n AODVv2 co-author I=E2=80=99d like to propose this position regarding key m=
anagement against BCP107, one of the artefacts we are being asked to state a=
 position over. I=E2=80=99d also like to state that I=E2=80=99m open to cont=
ributions from others knowledgeable on this topic or who have been this way p=
reviously.

If you=E2=80=99re not familiar (and I=
 wasn=E2=80=99t), RFC4107 aka BCP107 is the set of guidelines for choosing e=
ither automated or manual key management for cryptographic purposes. It=E2=80=
=99s not a long read and guides the reader through a set of tests as to whet=
her automated or manual key management would be suitable for the application=
 in hand.

The very first question is does AODVv=
2 need key management at all? I would contend that it does, since we require=
 to secure the signalling traffic for the routing algorithm. The aim here is=
 therefore to purely assist in the security of the signalling traffic; secur=
ity of user data that is forwarded once an AODVv2 route has been established=
 is out of scope.

Section 1 of BCP107 states th=
at automated key management SHOULD be used.. Thus my answer will be in favou=
r of that unless I can contend otherwise.

The g=
uidelines in section 2 outline that automated key management derives short-t=
erm session keys between two parties. In the case of AODVv2, this would corr=
espond to two routers that form or wish to form an adjacency.
=

The guidelines state that the short-term keys may be derived f=
rom long-term keys, and that the dissemination of long term keys is out of s=
cope of BCP107. I would envisage that an AODVv2 router, given that it would f=
orm ephemeral ad hoc networks with other routers as it went about its busine=
ss, would be supplied with one or more long term keys for a period of time, t=
o be determined by the system integrator, and that the long term keys would t=
hen be used to derive short term keys which are used in the forming of adjac=
By the way I have re-ordered the emails in this post to make it easier to re=
ad for flow.

On 27 Apr 2=
016, at 21:10, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

Hi all

As an AODVv2 co-author I=E2=80=
=99d like to propose this position regarding key management against BCP107, o=
ne of the artefacts we are being asked to state a position over. I=E2=80=99d=
 also like to state that I=E2=80=99m open to contributions from others knowl=
edgeable on this topic or who have been this way previously.
<=
br class=3D"">If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107=
 aka BCP107 is the set of guidelines for choosing either automated or manual=
 key management for cryptographic purposes. It=E2=80=99s not a long read and=
 guides the reader through a set of tests as to whether automated or manual k=
ey management would be suitable for the application in hand.
<=
br class=3D"">The very first question is does AODVv2 need key management at a=
ll? I would contend that it does, since we require to secure the signalling t=
raffic for the routing algorithm. The aim here is therefore to purely assist=
 in the security of the signalling traffic; security of user data that is fo=
rwarded once an AODVv2 route has been established is out of scope.

Section 1 of BCP107 states that automated key management S=
HOULD be used. Thus my answer will be in favour of that unless I can contend=
 otherwise.

The guidelines in section 2 outline=
 that automated key management derives short-term session keys between two p=
arties. In the case of AODVv2, this would correspond to two routers that for=
m or wish to form an adjacency.

The guidelines s=
tate that the short-term keys may be derived from long-term keys, and that t=
he dissemination of long term keys is out of scope of BCP107. I would envisa=
ge that an AODVv2 router, given that it would form ephemeral ad hoc networks=
 with other routers as it went about its business, would be supplied with on=
e or more long term keys for a period of time, to be determined by the syste=
m integrator, and that the long term keys would then be used to derive short=
 term keys which are used in the forming of adjacencies plural.

Section 2.1 of BCP107 describes the conditions under which a=
utomated key management MUST be used.

- If a la=
rge number of static keys would have to be managed. It is not known how many=
 routers could be deployed, but if this is aimed at ad hoc applications then=
 the number of routers could quickly become large. I consider this condition=
 is met.

- Any stream cipher is used. This is a=
 choice for the system integrator, but an AES based cipher is a real possibi=
lity. There is more likelihood this condition is met than not met.

- An initialisation vector (IV) might be re-used. I am ope=
n to advice on this point.

- Large amounts of d=
ata need to be encrypted in a short time. Even if there is no specific guida=
nce on =E2=80=98large=E2=80=99, I do not consider this condition to be met, s=
ince signalling messages are likely to be short relative to the user data th=
at could be exchanged.

- Long-term session keys=
 are used by more than two parties, including multicast applications. AODVv2=
 uses multicast extensively, and therefore I consider this condition to be m=
et.

- Device turnover is frequent. This is a ce=
rtainty in ad hoc networks, so I consider this condition to be met.

I believe the outcomes from section 2.1 guidance is mor=
e in favour of automated key management.

Howeve=
r, to consider the guidance on manual key management in section 2.2 of BCP10=
7, where such management may be reasonable:

- t=
he environment has very limited bandwidth or high round trip times. Some app=
lications for AODVv2 may use very low bandwidths, perhaps for low-power sens=
or networks. The point is made that "public key systems require long exchang=
es and lots of computation=E2=80=9D. The AODVv2 author team believe that ver=
y low power hardware might be used by some implementors, which may give prob=
lems when being required to use public key exchanges. Such implementors need=
 to carefully consider the tradeoff between the need for security and the ne=
ed for very low power consumption. Such implementors should also consider wh=
ether some functions should be realised in hardware or software, and the res=
ulting impact on system performance and power consumption.
- the information being protected is of low value. I do not cons=
ider this condition to be met; on the contrary, the signalling traffic in AO=
DVv2 is of high value to a potential attacker.

=
- the scale of each deployment is limited. I consider that this is an unknow=
n, but I also consider that we should engineer for larger networks with ephe=
meral connections rather than smaller ones.

Dis=
cussion welcome.

Regards
John




On 27 Apr 2016, at 2=
1:27, Christopher Dearlove <chris@mnemosyne.demon.co.uk> wrote:

I really don't know what you are proposing. I think you have a grea=
t big can of worms here that hasn't been thought through.

So AODVv2 is sending, as it's very first message, an RREQ. We want=
 to authenticate this. How? You can't negotiate a key, you haven't got a rou=
te. You don't know who your neighbours are. You plan to multicast to them in=
 fact, what's your key plan for that?

If you sa=
y use long term key, what are you actually going to use the short term key f=
or? And if you plan to exchange message with your neighbours, that rather pr=
eempts a significant part of your protocol (why establish bidirectionality w=
hen your key negotiation must have done that?)

=
And then we've spent some time discussing end to end authentication. That do=
esn't work with short term keys for adjacencies only.

We (OLSRv2) went through, more than once, a hard argument why automat=
ed key management wasn't appropriate here, and why the exceptions did apply.=


But in a nutshell (though this wasn't the argu=
ment we used, just why we needed it) how can you agree a key without communi=
cating? How do you communicate more than one hop without a route? How do you=
 authenticate the messages to create that route without a key?

Something has to give. And in giving you might end up redesi=
gning your whole protocol. Or using something quite clever that there's no h=
int of here. Or using the simplest fallback of a single shared key (our 7183=
 default) which isn't automatically managed.

--=
 
Christophe=
r Dearlove

On 27 Apr 2016, at 22:3=
8, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

OK=
 so there=E2=80=99s a really big problem here. We were asked to run the guid=
ance. Running the guidance gives the result below. In this case, the guidanc=
e is not giving a result that makes sense. The routers themselves are almost=
 certainly on the move, there is no other reason why you would want to only d=
etermine the path at send time. You now have routers potentially from multip=
le organisations occasionally conversing with other routers. I do not see th=
at a single shared key is going to pass muster; I certainly wouldn=E2=80=99t=
 recommend such a use case.

Regards
John

One possible way forwards i=
s to require all routers to have knowledge of some credentials of the other r=
outers before AODVv2 can begin signalling. This isn=E2=80=99t so crazy as it=
 might seem. Suppose such routers are installed in cars, and each manufactur=
er pre-loads the car with credentials of all the other manufacturers that it=
 trusts for signalling purposes. Thus Ford (say) might pre-load credentials f=
or Volkswagens. When a Ford and a Volkswagen meet, they already have some de=
gree of trust, and therefore the burden of proof of identity in AODVv2 signa=
lling is reduced, but not eliminated, because then we would be open to spoof=
ing.

We are also here acting as part of a (hope=
fully) layered authentication system. The wireless devices will presumably b=
e authenticated to each other, through some system that is suitable for the t=
ask in hand, and above routing there should be some checks on incoming user d=
ata to see if that is sensible.

Regards
John

=

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


=

--Apple-Mail-7D242298-36A5-4DC5-A242-97B214FF4E66--


From nobody Thu Apr 28 15:51: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 70BF912D55D for ; Thu, 28 Apr 2016 15:51:05 -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 xFxPJL2MXwIW for ; Thu, 28 Apr 2016 15:51:01 -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 6D33612B03F for ; Thu, 28 Apr 2016 15:51:00 -0700 (PDT)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1avulu-00361o-4O>; Fri, 29 Apr 2016 00:50:58 +0200
Received: from x4e335893.dyn.telefonica.de ([78.51.88.147] helo=[192.168.1.130]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id <1avult-0042z1-Ek>; Fri, 29 Apr 2016 00:50:58 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_8EBEA567-58B8-4558-9FE2-5995D4DA1DA7"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Lotte Steenbrink 
In-Reply-To: 
Date: Fri, 29 Apr 2016 00:50:55 +0200
Message-Id: <33F4027C-8E60-46CD-BBD7-DACD70A54D21@fu-berlin.de>
References: 
To: Mobile Ad Hoc Networks mailing list 
X-Mailer: Apple Mail (2.3112)
X-Originating-IP: 78.51.88.147
X-ZEDAT-Hint: A
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: Thu, 28 Apr 2016 22:51:05 -0000

--Apple-Mail=_8EBEA567-58B8-4558-9FE2-5995D4DA1DA7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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 :
>=20
> Hi,=20
>=20
> 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.=20
>=20
> A summary of my review:
>=20
> 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.=20
> 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.=20
>=20
> 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=20
>        - The experiments to be conducted=20
>        - What kind of feedback is expected to reported. =20
>=20
> 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.=20
> I think this is partially due to the lack of implementation, or the =
implementation experience is not reported to the author team?
>=20
> 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.=20
>=20
> 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.=20

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 =
polling 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 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=99=
t have the expensive context switches], you MUST check LocalRoute.State =
before you forward to make sure the route is still valid.=E2=80=9C ...

>=20
> 6. There are too many "MAY" and "SHOULD" in the document without =
elaboration. Some of which might cause interoperability issues or even =
loops.=20
>=20
> 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. =20

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.=20
>=20
> Please check the details inline:
>=20
> section 1, overview
>=20
>    The Ad hoc On-Demand Distance Vector Version 2 (AODVv2) protocol
>    enables dynamic, self-starting, multihop routing
>=20
> 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.=20

Makes sense. I=E2=80=99ve removed the term.

>=20
>   AODVv2 is an Experimental protocol.
>  ...
> =20
> I think much more information is required here:
>=20
> 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)
>=20
> 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 =
something up (unless my co-authors beat me to it ;) ) and get back to =
you, if that=E2=80=99s okay?

>=20
>    The basic operations of the AODVv2 protocol are route discovery and
>    route maintenance...
>=20
> 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.=20
> 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 =
AODVv2 protocol are route discovery and route maintenance.=E2=80=9C, =
since that sentence occurs in the first paragraph already, and we=E2=80=99=
ve substituted the =E2=80=9EAn AODVv2 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?

> =20
>=20
> section 2, Terminology
>=20
> Please pay attention to the style of the terms. Most of the time, =
style like AckReq is used, but sometimes RERR_Gen is used.=20
> Good to be consistent.=20

I think I=E2=80=99ve pointed out a similar issue 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 RERR_Gen to RERRGen =
would have a negative impact on readability, so there are some =
exceptions to the rule=E2=80=A6

>=20
>    Unreachable Address
>       An address reported in a Route Error message, as described in
>       Section 7.4.1.
>=20
> need to explain what's the address for exactly, rather than giving a =
pointer to a big section.=20

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

>=20
> section 3, applicability statement
>=20
>    AODVv2 handles a wide variety of mobility and traffic patterns by
>    determining routes on-demand...
>=20
> 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).=20

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?

> =20
>    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.=20
>=20
> 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.=20

We=E2=80=99re currently working on getting rid of the hop by hop trust =
model 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?)

> =20
>    The routing algorithm in AODVv2 MAY be operated at layers other =
than
>    the network layer, using layer-appropriate addresses.
>=20
> Considering the deep coupling between AODVv2 and IP, I don't see how =
it can work. This should be removed.=20
>=20
> section 4 data structures
>=20
> 4.1 Interface set
>=20
> The InterfaceSet is a conceptual data structure which contains
>    information about all interfaces available to AODVv2.
> ...
> Otherwise the InterfaceSet MAY be empty.
>=20
> I'm not sure the sec MAY be empty -- a router contains at least one =
interface, no?=20

Yes, but if it knows it only has one and it has access 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 give =
implementations for constrained devices a bit of leeway there.

>=20
> 4.2 router client set
>    RouterClient.Cost
>       The cost associated with reaching this address or address range.
>=20
> Both "metric" and "cost" are used in the draft. If they are the same, =
please pick a term and use it consistently.=20

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?

> =20
> 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.=20
>=20
> 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.=20

=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 =
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)?

>=20
> 4.3 neighbor set
>=20
>  Neighbor.State ... There are three possible states: Confirmed, =
Unknown, and
>       Blacklisted.  Unknown is the initial state.
>=20
> 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".=20
> I think "Heard" is a more appropriate term to be used here.=20
>=20
> 4.4 sequence numbers
>=20
> I think the comparison in wrap-around cases should be specified here.=20=

>=20
> Tod determine staleness,
>=20
> typo

Whoopsie, thanks

>=20
> 4.5 Local route set
>=20
> Alternatively, implementations
>    MAY choose to modify the Routing Information Base directly.
>=20
> This should be either more precise (in which condition, how we can =
modify the RIB?), or be removed. =20

Isn=E2=80=99t the how really implementation specific?

>=20
> =20
>    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.
>=20
> 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.=20

Of course, but that=E2=80=99s an issue of properly establishing routes, =
which 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

>=20
> 4.6.  Multicast Route Message Set
>=20
> 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.=20
>=20
> section 5 Metrics
>=20
>    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.=20
>=20
> 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.=20=

> In the Router Client Set, we have only one field for =
RouterClient.Cost. On the other hand, "AODVv2 supports different =
metrics".=20
>=20
>           routerClient.cost             AODVv2 metric=20
> client-----------------------RREQ_gen---------------
>=20
> What if those two metrics are of different types? This is quite =
possible because the two links might use different medium.=20
>=20
>=20
> section 6 AODVv2 protocol Operations
>=20
> General comments:=20
>=20
> 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.=20
> 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.=20
>=20
> I don't quite get the current organization of sections either. For =
example:
>=20
> 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?
>=20
> 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.=20
>=20
> 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.=20
>=20
> more details inline:
>=20
>    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. ...
>=20
> I think we need to precise this is one for the case of RREP =
transmission.=20
>=20
> section 6.3
>=20
>    If an external mechanism reports a link as broken, the Neighbor Set
>    entry SHOULD be removed.
>=20
> 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?
> =20
>   an RREP which answers a RREQ sent within RREQ_WAIT_TIME over the
>       same interface as Neighbor.Interface
>=20
> 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 =
differently for RREQ/RREP? Need to check the consistency in the whole =
draft.=20

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, 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 errors, all fixed now.

>=20
> section 6.4.  Interaction with the Forwarding Plane
>=20
>    o  A route has been updated: update the corresponding route in the
>       Routing Information Base.
>=20
> 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 call it out in the applicability statement.=20

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 great, 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 be mentioned in =
4.5.  Local Route Set though)

>=20
> section 6.5.  Message Transmission
>=20
>    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.=20
>=20
> I think it's more implementation details rather than specification. =20=

>=20
> section 6.6=20
>=20
> The constants used inSection 6.7.1 this section are
>    defined in Section 10.
>=20
> misplaced reference

Oh, thanks. Fixed.

>=20
> section 6.7.1
>=20
>    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.
>=20
> If some routers made the update, and some routers choose not updating, =
I'm afraid there will be loops in the network.=20
>=20
>        *  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.
>=20
> shouldn=E2=80=99t worse AdvRte is already filtered by the LoopFree =
function in the previous step 3?
>=20
> section 6.7.2.  Applying Route Updates
> If there is no existing matching route,
>    AdvRte allows a corresponding RREP to be sent.=20
>=20
> I don't quite get why this relevant to RREP sending here.=20

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

> =20
>    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.
>=20
> why "SHOULD", not "MUST" here?=20
>=20
> 6.8.  Suppressing Redundant Messages Using the Multicast Route Message
>       Set
>=20
> the processes defined in this section overlap with section 6.7.1 =
(bullet 1-2-3-4)
>=20
> section 6.10 Local route set maintenance
> =20
>    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.
>=20
> 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 =
context switch. This is inevitable for reactive protocols, but doing so =
per packet seems to be expensive.=20

see above :)

>=20
>=20
> section 7 AODVv2 Protocol Messages
>=20
> general comments:
>   - the message regeneration, rather than the message forwarding, plus =
different optional fields make the protocol hard to secure=20

fixed now

>   - the tradeoff of using multicast RREP and RERR need to be carefully =
considered.=20
>   - the tradeoff of using ValidityTime needs to be carefully =
considered

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

>=20
> section 7.1
> =20
>    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.
>=20
> it seems that only one prefix length is needed, why "list"?
>=20
>=20
>    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.
>=20
> the necessity of using ValidityTime has been raised here =
https://www.ietf.org/mail-archive/web/manet/current/msg18852.html =

> =20
>    5.  Include MetricType and set the type accordingly
>    6.  Set OrigMetric :=3D RouterClient.Cost for the Router Client =
entry
>        which includes OrigAddr
> =20
> 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.=20
>=20
>  However, the regenerated RREQ can
>    be unicast to the next hop address of the LocalRoute toward =
TargAddr,
>    if known.
>=20
> 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 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.=20
>=20
> 7.2.  Route Reply (RREP) Message
>=20
> I don't quite understand the purpose of multicast RREP. There are, =
however, lots of disadvantages of using an optional AckReq field.=20
> This has been discussed in another thread =
https://www.ietf.org/mail-archive/web/manet/current/msg18864.html =

> =20
>    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.
>=20
> 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 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 pity but we have no =
other option but to drop the better RREQ?=20

(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 Draft now since that seemed more =
concise ;) )

>=20
> 7.3.2 RREP_Ack Reception
>=20
> it seems that some action is missing after the step 2 Neighbour set =
update. At least, we need to update the Local Route Set?
>=20
> 7.4.1 RERR generation
>=20
> Is it necessary to generate RERR for RREP failure?
>=20
> =20
> 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.
>=20
> 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.=20
>=20
> 7.4.3 RERR regeneration
>=20
>    2.  For each LocalRoute that needs to be reported as identified in
>        Section 7.4.1:
>        *  Insert LocalRoute.Address into the AddressList.
>=20
> 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 the suppressing won't be able to work correctly?
>=20
> One more note:
>=20
> 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.=20
>=20
> best
>=20
> Jiazi
>=20
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

Best regards,
Lotte



--Apple-Mail=_8EBEA567-58B8-4558-9FE2-5995D4DA1DA7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

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 <ietf@jiaziyi.com>:

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. 

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 =
and 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 RREQ is inevitable, the necessity of =
multicast RREP/RERR is not clear. It bring issues related to control =
message overhead and security. 

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. 

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 polling 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 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 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 =
something 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 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.

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 substituted the =E2=80=9EAn AODVv2 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 think?), but I think I recall the conclusion =
being that while the draft should stick 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, so 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 data 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 can participate in routing =
operations. 

We=E2=80=99re currently working on getting rid of =
the hop by hop trust model 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 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 give implementations for constrained 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 =
and 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 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)?

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 loops. 

Of course, but that=E2=80=99s an issue of properly =
establishing routes, which 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 be identified by its originator's address and =
sequence number, why 6 fields (OrigAddr, OrigFprefixLen, OrigSeqNum, =
TargAddr, TargPrefixLen, TargSeqNum) 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. 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. 


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 example:

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 differently 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 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 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 =
call 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 great, 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 =
be 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. 

       *  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 function 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 just 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 in user space (which is true in =
most cases), this normally means context switch. This is inevitable for =
reactive protocols, but doing so per packet 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.ht=
ml
 
   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 the link is actually broken. 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. 

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.ht=
ml
 
   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 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 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 Draft 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 the 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


=

--Apple-Mail=_8EBEA567-58B8-4558-9FE2-5995D4DA1DA7--


From nobody Thu Apr 28 16:00: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 C419F12B038 for ; Thu, 28 Apr 2016 16:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=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 RGmQWx6V1oEk for ; Thu, 28 Apr 2016 15:59:57 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 AA64A12B03F for ; Thu, 28 Apr 2016 15:59:57 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id f89so92054704ioi.0 for ; Thu, 28 Apr 2016 15:59:57 -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=IP2QNqoKTCMh7hwMWhNG8rMy1STWGNAspBT7T1qYnNQ=; b=sSeVYTuQoI4xbE2cGFEwgDWiolK831uPrLZEMuw0K3TatzNyWgz9fNeeCOPM5GWDwK 2gP94Cs9c03mFxJ49OQX8aU3TzNDQ9rPaT85NufQNoevj00ZsjUvwsXRluPzQ4JHlj02 YeK7HMazCr6sugy7eMHMO5nBEVxdHFQvvg6NQVewlapp8DE0BlgmxlSZIeGZwaS5580P OVD64Rm9hcK/I0QBsKexlbHT/8ZtP/Rz6AZ/jCYbQF7JD/9EYbmyDNIgbtpaEoWlFm7y 0xodXamAQKlBwbT3QsNL4j+IYCVE7WsHsgdNDEuv0AQ+79s7ZLYKlHY+Gi2lzc7JHzFr r4Cg==
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=IP2QNqoKTCMh7hwMWhNG8rMy1STWGNAspBT7T1qYnNQ=; b=GE1YIvuKEayZMoA1qUJ6L7oQh2rs7zvIoLZ+T8gu2pK7em6oy9BxkOLa5d9p++UBmX 9cSUgqYPbiWwe4AUSzUBzqd2rcxonLgcoZIgN5Fd1x7/gqvued3TAh2oKlRkXBiuEOYo IWoq5WF7vAhS3kXkalZpCXwYumLW4oIkRKR9TWdgENYN3zGM7kpHjKRVb6DsEAOEV/ei fvRnk3IDgRlnSOqXDtBn7v9XkS3Fw+D+mukD3WrY+Ur/+GkQSLMkci8NLvbtmgYXZI6O UuZ9vUDZOc2re9PIcNtG+V7bALPqBUyXklCEU1BDbx/Vex3Ik9p170T+1wFMEKH7kPT5 s0ag==
X-Gm-Message-State: AOPr4FXU5xy5TICzP5q8trev46UYqDGTuAJw1YGpbfQ0i35kvYjPJL5GFgewOmNooSO0fn7MZu5OFDCBkKRL9A==
MIME-Version: 1.0
X-Received: by 10.107.129.75 with SMTP id c72mr21582961iod.102.1461884396986;  Thu, 28 Apr 2016 15:59:56 -0700 (PDT)
Received: by 10.79.72.68 with HTTP; Thu, 28 Apr 2016 15:59:56 -0700 (PDT)
In-Reply-To: 
References: <937ABB81-CCD9-4FD0-A7CF-5114384B3B94@gmail.com> <8D383418-4CBF-49C6-9871-4E31042E29E5@mnemosyne.demon.co.uk>  <9E042F54-58E4-4C1B-8F7B-ECAD41341D48@gmail.com> 
Date: Thu, 28 Apr 2016 18:59:56 -0400
Message-ID: 
From: Stan Ratliff 
To: Christopher Dearlove 
Content-Type: multipart/alternative; boundary=001a113f99b02f6f800531937cb1
Archived-At: 
Cc: MANET IETF 
Subject: Re: [manet] AODVv2 security: Key Management to BCP107
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, 28 Apr 2016 23:00:01 -0000

--001a113f99b02f6f800531937cb1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

There is some IPR that I'm aware of that may help out here - it's based on
my prior work at Cisco. I've already let Alvaro know; he's going to check
into getting Cisco to make a disclosure...

Regards,
Stan


On Thu, Apr 28, 2016 at 4:11 PM, Christopher Dearlove <
christopher.dearlove@gmail.com> wrote:

> I really wouldn't be interested in a system in which each router had to
> have knowledge of all other routers. Far too restrictive, and scales
> poorly. It just might fly as a solution. As the solution, definitely not.
>
> Each router needing some preconfiguration, sure. See the IBS draft for
> example.
>
> --
> Christopher Dearlove
> christopher.dearlove@gmail.com (iPhone)
> chris@mnemosyne.demon.co.uk (home)
>
> > On 28 Apr 2016, at 20:37, John Dowdell 
> wrote:
> >
> > By the way I have re-ordered the emails in this post to make it easier
> to read for flow.
> >>
> >>>> On 27 Apr 2016, at 21:10, John Dowdell 
> wrote:
> >>>>
> >>>> Hi all
> >>>>
> >>>> As an AODVv2 co-author I=E2=80=99d like to propose this position reg=
arding
> key management against BCP107, one of the artefacts we are being asked to
> state a position over. I=E2=80=99d also like to state that I=E2=80=99m op=
en to
> contributions from others knowledgeable on this topic or who have been th=
is
> way previously.
> >>>>
> >>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka B=
CP107 is the set
> of guidelines for choosing either automated or manual key management for
> cryptographic purposes. It=E2=80=99s not a long read and guides the reade=
r through
> a set of tests as to whether automated or manual key management would be
> suitable for the application in hand.
> >>>>
> >>>> The very first question is does AODVv2 need key management at all? I
> would contend that it does, since we require to secure the signalling
> traffic for the routing algorithm. The aim here is therefore to purely
> assist in the security of the signalling traffic; security of user data
> that is forwarded once an AODVv2 route has been established is out of sco=
pe.
> >>>>
> >>>> Section 1 of BCP107 states that automated key management SHOULD be
> used.. Thus my answer will be in favour of that unless I can contend
> otherwise.
> >>>>
> >>>> The guidelines in section 2 outline that automated key management
> derives short-term session keys between two parties. In the case of AODVv=
2,
> this would correspond to two routers that form or wish to form an adjacen=
cy.
> >>>>
> >>>> The guidelines state that the short-term keys may be derived from
> long-term keys, and that the dissemination of long term keys is out of
> scope of BCP107. I would envisage that an AODVv2 router, given that it
> would form ephemeral ad hoc networks with other routers as it went about
> its business, would be supplied with one or more long term keys for a
> period of time, to be determined by the system integrator, and that the
> long term keys would then be used to derive short term keys which are use=
d
> in the forming of adjacBy the way I have re-ordered the emails in this po=
st
> to make it easier to read for flow.
> >>
> >>>> On 27 Apr 2016, at 21:10, John Dowdell 
> wrote:
> >>>>
> >>>> Hi all
> >>>>
> >>>> As an AODVv2 co-author I=E2=80=99d like to propose this position reg=
arding
> key management against BCP107, one of the artefacts we are being asked to
> state a position over. I=E2=80=99d also like to state that I=E2=80=99m op=
en to
> contributions from others knowledgeable on this topic or who have been th=
is
> way previously.
> >>>>
> >>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka B=
CP107 is the set
> of guidelines for choosing either automated or manual key management for
> cryptographic purposes. It=E2=80=99s not a long read and guides the reade=
r through
> a set of tests as to whether automated or manual key management would be
> suitable for the application in hand.
> >>>>
> >>>> The very first question is does AODVv2 need key management at all? I
> would contend that it does, since we require to secure the signalling
> traffic for the routing algorithm. The aim here is therefore to purely
> assist in the security of the signalling traffic; security of user data
> that is forwarded once an AODVv2 route has been established is out of sco=
pe.
> >>>>
> >>>> Section 1 of BCP107 states that automated key management SHOULD be
> used. Thus my answer will be in favour of that unless I can contend
> otherwise.
> >>>>
> >>>> The guidelines in section 2 outline that automated key management
> derives short-term session keys between two parties. In the case of AODVv=
2,
> this would correspond to two routers that form or wish to form an adjacen=
cy.
> >>>>
> >>>> The guidelines state that the short-term keys may be derived from
> long-term keys, and that the dissemination of long term keys is out of
> scope of BCP107. I would envisage that an AODVv2 router, given that it
> would form ephemeral ad hoc networks with other routers as it went about
> its business, would be supplied with one or more long term keys for a
> period of time, to be determined by the system integrator, and that the
> long term keys would then be used to derive short term keys which are use=
d
> in the forming of adjacencies plural.
> >>>>
> >>>> Section 2.1 of BCP107 describes the conditions under which automated
> key management MUST be used.
> >>>>
> >>>> - If a large number of static keys would have to be managed. It is
> not known how many routers could be deployed, but if this is aimed at ad
> hoc applications then the number of routers could quickly become large. I
> consider this condition is met.
> >>>>
> >>>> - Any stream cipher is used. This is a choice for the system
> integrator, but an AES based cipher is a real possibility. There is more
> likelihood this condition is met than not met.
> >>>>
> >>>> - An initialisation vector (IV) might be re-used. I am open to advic=
e
> on this point.
> >>>>
> >>>> - Large amounts of data need to be encrypted in a short time. Even i=
f
> there is no specific guidance on =E2=80=98large=E2=80=99, I do not consid=
er this condition
> to be met, since signalling messages are likely to be short relative to t=
he
> user data that could be exchanged.
> >>>>
> >>>> - Long-term session keys are used by more than two parties, includin=
g
> multicast applications. AODVv2 uses multicast extensively, and therefore =
I
> consider this condition to be met.
> >>>>
> >>>> - Device turnover is frequent. This is a certainty in ad hoc
> networks, so I consider this condition to be met.
> >>>>
> >>>> I believe the outcomes from section 2.1 guidance is more in favour o=
f
> automated key management.
> >>>>
> >>>> However, to consider the guidance on manual key management in sectio=
n
> 2.2 of BCP107, where such management may be reasonable:
> >>>>
> >>>> - the environment has very limited bandwidth or high round trip
> times. Some applications for AODVv2 may use very low bandwidths, perhaps
> for low-power sensor networks. The point is made that "public key systems
> require long exchanges and lots of computation=E2=80=9D. The AODVv2 autho=
r team
> believe that very low power hardware might be used by some implementors,
> which may give problems when being required to use public key exchanges.
> Such implementors need to carefully consider the tradeoff between the nee=
d
> for security and the need for very low power consumption. Such implemento=
rs
> should also consider whether some functions should be realised in hardwar=
e
> or software, and the resulting impact on system performance and power
> consumption.
> >>>>
> >>>> - the information being protected is of low value. I do not consider
> this condition to be met; on the contrary, the signalling traffic in AODV=
v2
> is of high value to a potential attacker.
> >>>>
> >>>> - the scale of each deployment is limited. I consider that this is a=
n
> unknown, but I also consider that we should engineer for larger networks
> with ephemeral connections rather than smaller ones.
> >>>>
> >>>> Discussion welcome.
> >>>>
> >>>> Regards
> >>>> John
> >>>>
> >>>>
> >>>>
> >>
> >>> On 27 Apr 2016, at 21:27, Christopher Dearlove <
> chris@mnemosyne.demon.co.uk> wrote:
> >>>
> >>> I really don't know what you are proposing. I think you have a great
> big can of worms here that hasn't been thought through.
> >>>
> >>> So AODVv2 is sending, as it's very first message, an RREQ. We want to
> authenticate this. How? You can't negotiate a key, you haven't got a rout=
e.
> You don't know who your neighbours are. You plan to multicast to them in
> fact, what's your key plan for that?
> >>>
> >>> If you say use long term key, what are you actually going to use the
> short term key for? And if you plan to exchange message with your
> neighbours, that rather preempts a significant part of your protocol (why
> establish bidirectionality when your key negotiation must have done that?=
)
> >>>
> >>> And then we've spent some time discussing end to end authentication.
> That doesn't work with short term keys for adjacencies only.
> >>>
> >>> We (OLSRv2) went through, more than once, a hard argument why
> automated key management wasn't appropriate here, and why the exceptions
> did apply.
> >>>
> >>> But in a nutshell (though this wasn't the argument we used, just why
> we needed it) how can you agree a key without communicating? How do you
> communicate more than one hop without a route? How do you authenticate th=
e
> messages to create that route without a key?
> >>>
> >>> Something has to give. And in giving you might end up redesigning you=
r
> whole protocol. Or using something quite clever that there's no hint of
> here. Or using the simplest fallback of a single shared key (our 7183
> default) which isn't automatically managed.
> >>>
> >>> --
> >>> Christopher Dearlove
> >>>
> >> On 27 Apr 2016, at 22:38, John Dowdell 
> wrote:
> >>
> >> OK so there=E2=80=99s a really big problem here. We were asked to run =
the
> guidance. Running the guidance gives the result below. In this case, the
> guidance is not giving a result that makes sense. The routers themselves
> are almost certainly on the move, there is no other reason why you would
> want to only determine the path at send time. You now have routers
> potentially from multiple organisations occasionally conversing with othe=
r
> routers. I do not see that a single shared key is going to pass muster; I
> certainly wouldn=E2=80=99t recommend such a use case.
> >>
> >> Regards
> >> John
> >
> > One possible way forwards is to require all routers to have knowledge o=
f
> some credentials of the other routers before AODVv2 can begin signalling.
> This isn=E2=80=99t so crazy as it might seem. Suppose such routers are in=
stalled in
> cars, and each manufacturer pre-loads the car with credentials of all the
> other manufacturers that it trusts for signalling purposes. Thus Ford (sa=
y)
> might pre-load credentials for Volkswagens. When a Ford and a Volkswagen
> meet, they already have some degree of trust, and therefore the burden of
> proof of identity in AODVv2 signalling is reduced, but not eliminated,
> because then we would be open to spoofing.
> >
> > We are also here acting as part of a (hopefully) layered authentication
> system. The wireless devices will presumably be authenticated to each
> other, through some system that is suitable for the task in hand, and abo=
ve
> routing there should be some checks on incoming user data to see if that =
is
> sensible.
> >
> > Regards
> > John
> >
> >>>>
> >>>> _______________________________________________
> >>>> 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
>

--001a113f99b02f6f800531937cb1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


There is some IPR that I'm aware of that may=
 help out here - it's based on my prior work at Cisco. I've already=
 let Alvaro know; he's going to check into getting Cisco to make a disc=
losure... 

Regards,
Stan

<=
div class=3D"gmail_extra">
On Thu, Apr 28, 20=
16 at 4:11 PM, Christopher Dearlove <christopher.dearlove@gma=
il.com> wrote:
I really wou=
ldn't be interested in a system in which each router had to have knowle=
dge of all other routers. Far too restrictive, and scales poorly. It just m=
ight fly as a solution. As the solution, definitely not.



Each router needing some preconfiguration, sure. See the IBS draft for exam=
ple.



--

Christopher Dearlove

christopher.dearlove@gmai=
l.com (iPhone)

chris@mnemosyne.demon.co.uk<=
/a> (home)



> On 28 Apr 2016, at 20:37, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

>

> By the way I have re-ordered the emails in this post to make it easier=
 to read for flow.

>>

>>>> On 27 Apr 2016, at 21:10, John Dowdell <john.dowdell.ietf@gmail.com> wrote:<=
br>
>>>>

>>>> Hi all

>>>>

>>>> As an AODVv2 co-author I=E2=80=99d like to propose this po=
sition regarding key management against BCP107, one of the artefacts we are=
 being asked to state a position over. I=E2=80=99d also like to state that =
I=E2=80=99m open to contributions from others knowledgeable on this topic o=
r who have been this way previously.

>>>>

>>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC=
4107 aka BCP107 is the set of guidelines for choosing either automated or m=
anual key management for cryptographic purposes. It=E2=80=99s not a long re=
ad and guides the reader through a set of tests as to whether automated or =
manual key management would be suitable for the application in hand.

>>>>

>>>> The very first question is does AODVv2 need key management=
 at all? I would contend that it does, since we require to secure the signa=
lling traffic for the routing algorithm. The aim here is therefore to purel=
y assist in the security of the signalling traffic; security of user data t=
hat is forwarded once an AODVv2 route has been established is out of scope.=


>>>>

>>>> Section 1 of BCP107 states that automated key management S=
HOULD be used.. Thus my answer will be in favour of that unless I can conte=
nd otherwise.

>>>>

>>>> The guidelines in section 2 outline that automated key man=
agement derives short-term session keys between two parties. In the case of=
 AODVv2, this would correspond to two routers that form or wish to form an =
adjacency.

>>>>

>>>> The guidelines state that the short-term keys may be deriv=
ed from long-term keys, and that the dissemination of long term keys is out=
 of scope of BCP107. I would envisage that an AODVv2 router, given that it =
would form ephemeral ad hoc networks with other routers as it went about it=
s business, would be supplied with one or more long term keys for a period =
of time, to be determined by the system integrator, and that the long term =
keys would then be used to derive short term keys which are used in the for=
ming of adjacBy the way I have re-ordered the emails in this post to make i=
t easier to read for flow.

>>

>>>> On 27 Apr 2016, at 21:10, John Dowdell <john.dowdell.ietf@gmail.com> wrote:<=
br>
>>>>

>>>> Hi all

>>>>

>>>> As an AODVv2 co-author I=E2=80=99d like to propose this po=
sition regarding key management against BCP107, one of the artefacts we are=
 being asked to state a position over. I=E2=80=99d also like to state that =
I=E2=80=99m open to contributions from others knowledgeable on this topic o=
r who have been this way previously.

>>>>

>>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC=
4107 aka BCP107 is the set of guidelines for choosing either automated or m=
anual key management for cryptographic purposes. It=E2=80=99s not a long re=
ad and guides the reader through a set of tests as to whether automated or =
manual key management would be suitable for the application in hand.

>>>>

>>>> The very first question is does AODVv2 need key management=
 at all? I would contend that it does, since we require to secure the signa=
lling traffic for the routing algorithm. The aim here is therefore to purel=
y assist in the security of the signalling traffic; security of user data t=
hat is forwarded once an AODVv2 route has been established is out of scope.=


>>>>

>>>> Section 1 of BCP107 states that automated key management S=
HOULD be used. Thus my answer will be in favour of that unless I can conten=
d otherwise.

>>>>

>>>> The guidelines in section 2 outline that automated key man=
agement derives short-term session keys between two parties. In the case of=
 AODVv2, this would correspond to two routers that form or wish to form an =
adjacency.

>>>>

>>>> The guidelines state that the short-term keys may be deriv=
ed from long-term keys, and that the dissemination of long term keys is out=
 of scope of BCP107. I would envisage that an AODVv2 router, given that it =
would form ephemeral ad hoc networks with other routers as it went about it=
s business, would be supplied with one or more long term keys for a period =
of time, to be determined by the system integrator, and that the long term =
keys would then be used to derive short term keys which are used in the for=
ming of adjacencies plural.

>>>>

>>>> Section 2.1 of BCP107 describes the conditions under which=
 automated key management MUST be used.

>>>>

>>>> - If a large number of static keys would have to be manage=
d. It is not known how many routers could be deployed, but if this is aimed=
 at ad hoc applications then the number of routers could quickly become lar=
ge. I consider this condition is met.

>>>>

>>>> - Any stream cipher is used. This is a choice for the syst=
em integrator, but an AES based cipher is a real possibility. There is more=
 likelihood this condition is met than not met.

>>>>

>>>> - An initialisation vector (IV) might be re-used. I am ope=
n to advice on this point.

>>>>

>>>> - Large amounts of data need to be encrypted in a short ti=
me. Even if there is no specific guidance on =E2=80=98large=E2=80=99, I do =
not consider this condition to be met, since signalling messages are likely=
 to be short relative to the user data that could be exchanged.

>>>>

>>>> - Long-term session keys are used by more than two parties=
, including multicast applications. AODVv2 uses multicast extensively, and =
therefore I consider this condition to be met.

>>>>

>>>> - Device turnover is frequent. This is a certainty in ad h=
oc networks, so I consider this condition to be met.

>>>>

>>>> I believe the outcomes from section 2.1 guidance is more i=
n favour of automated key management.

>>>>

>>>> However, to consider the guidance on manual key management=
 in section 2.2 of BCP107, where such management may be reasonable:

>>>>

>>>> - the environment has very limited bandwidth or high round=
 trip times. Some applications for AODVv2 may use very low bandwidths, perh=
aps for low-power sensor networks. The point is made that "public key =
systems require long exchanges and lots of computation=E2=80=9D. The AODVv2=
 author team believe that very low power hardware might be used by some imp=
lementors, which may give problems when being required to use public key ex=
changes. Such implementors need to carefully consider the tradeoff between =
the need for security and the need for very low power consumption. Such imp=
lementors should also consider whether some functions should be realised in=
 hardware or software, and the resulting impact on system performance and p=
ower consumption.

>>>>

>>>> - the information being protected is of low value. I do no=
t consider this condition to be met; on the contrary, the signalling traffi=
c in AODVv2 is of high value to a potential attacker.

>>>>

>>>> - the scale of each deployment is limited. I consider that=
 this is an unknown, but I also consider that we should engineer for larger=
 networks with ephemeral connections rather than smaller ones.

>>>>

>>>> Discussion welcome.

>>>>

>>>> Regards

>>>> John

>>>>

>>>>

>>>>

>>

>>> On 27 Apr 2016, at 21:27, Christopher Dearlove <chris@mnemosyne.demon.co.uk> wro=
te:

>>>

>>> I really don't know what you are proposing. I think you ha=
ve a great big can of worms here that hasn't been thought through.

>>>

>>> So AODVv2 is sending, as it's very first message, an RREQ.=
 We want to authenticate this. How? You can't negotiate a key, you have=
n't got a route. You don't know who your neighbours are. You plan t=
o multicast to them in fact, what's your key plan for that?

>>>

>>> If you say use long term key, what are you actually going to u=
se the short term key for? And if you plan to exchange message with your ne=
ighbours, that rather preempts a significant part of your protocol (why est=
ablish bidirectionality when your key negotiation must have done that?)

>>>

>>> And then we've spent some time discussing end to end authe=
ntication. That doesn't work with short term keys for adjacencies only.=


>>>

>>> We (OLSRv2) went through, more than once, a hard argument why =
automated key management wasn't appropriate here, and why the exception=
s did apply.

>>>

>>> But in a nutshell (though this wasn't the argument we used=
, just why we needed it) how can you agree a key without communicating? How=
 do you communicate more than one hop without a route? How do you authentic=
ate the messages to create that route without a key?

>>>

>>> Something has to give. And in giving you might end up redesign=
ing your whole protocol. Or using something quite clever that there's n=
o hint of here. Or using the simplest fallback of a single shared key (our =
7183 default) which isn't automatically managed.

>>>

>>> --

>>> Christopher Dearlove

>>>

>> On 27 Apr 2016, at 22:38, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

>>

>> OK so there=E2=80=99s a really big problem here. We were asked to =
run the guidance. Running the guidance gives the result below. In this case=
, the guidance is not giving a result that makes sense. The routers themsel=
ves are almost certainly on the move, there is no other reason why you woul=
d want to only determine the path at send time. You now have routers potent=
ially from multiple organisations occasionally conversing with other router=
s. I do not see that a single shared key is going to pass muster; I certain=
ly wouldn=E2=80=99t recommend such a use case.

>>

>> Regards

>> John

>

> One possible way forwards is to require all routers to have knowledge =
of some credentials of the other routers before AODVv2 can begin signalling=
. This isn=E2=80=99t so crazy as it might seem. Suppose such routers are in=
stalled in cars, and each manufacturer pre-loads the car with credentials o=
f all the other manufacturers that it trusts for signalling purposes. Thus =
Ford (say) might pre-load credentials for Volkswagens. When a Ford and a Vo=
lkswagen meet, they already have some degree of trust, and therefore the bu=
rden of proof of identity in AODVv2 signalling is reduced, but not eliminat=
ed, because then we would be open to spoofing.

>

> We are also here acting as part of a (hopefully) layered authenticatio=
n system. The wireless devices will presumably be authenticated to each oth=
er, through some system that is suitable for the task in hand, and above ro=
uting there should be some checks on incoming user data to see if that is s=
ensible.

>

> Regards

> John

>

>>>>

>>>> _______________________________________________

>>>> manet mailing list

>>>> manet@ietf.org

>>>> https://www.ietf.org/mailman/listinfo/ma=
net

>>>

>>

>



_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet





--001a113f99b02f6f800531937cb1--


From nobody Thu Apr 28 16:21: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 D87EF12D0C9 for ; Thu, 28 Apr 2016 16:21:49 -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 ecjaAjmIPCag for ; Thu, 28 Apr 2016 16:21:45 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 18C8012D58E for ; Thu, 28 Apr 2016 16:21:45 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id n129so7473361wmn.1 for ; Thu, 28 Apr 2016 16:21:45 -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=mLW7xeu9U8kv1ihwbaXB4S8XdjOUma+5oTXBrdlG+s0=; b=TRhwLSrJeyrrhh0JY9imO22rWanHjdZ9RDjczbGK7Ylz2rs7Nno6K+R2clIxK4jP3a gvJUEEP0n/86Q3d87Aj9hVoeU+hlDheh6Q+vf4fpWJwnqJFBqyGePo3duvbS52gtpFhW iq0U6cVNGFjXAfTG7Y2BYdCcKQMITw+TR4phagNhumEWP8BinT3r2SwQhQ9Z0TzUHdGd moBLrXJ8GJuPYGifIrhpZCuTJRRlM2dlEu28GrJ5Gx0DziFHib5klnsoE+j1sWSrQc3z 4TobHUkvZwcQGDECEhLDQW6CFPgAMczrBMRTM7MtjwAaP1Ii6HygchbsC/Ta+S1hY25v V/9g==
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=mLW7xeu9U8kv1ihwbaXB4S8XdjOUma+5oTXBrdlG+s0=; b=U5s3wE2Qs6OCBPLRELcxRRl+HqUlXavi4TTBY6AsJS7HWGlQxsfmVMymb0kcnPSiUL InbKEoCUVwCWDLYCMIBQE2aw/Q8U3lCn5lor8UBOsC+zClotRV7uBh99BU8OLmzZ8fw6 MMvTAKgbXVL9VJTSmFDJXo9VC0dFqFt+VyfyX51vsuP3teSf3l7qsG3hAKLSvd4Qv8q6 e6ia+tHQkEpAOpQ9EgE8c8MIGdpB8ntyVYumVSJGFohKWnaqBc/RGmUbvAoObUVtN6hD LN5HTJRNJgUzcQAW54t5CydinImpM6MoUhyfL3ylDTuXJ4PfmY8kkUYITvh26QQbod+D bz9w==
X-Gm-Message-State: AOPr4FUGiR0tfdKobn1+zguveXHsAii6yB9eweArg2qWh45lkkraRkGAod1iRDqM6Fmd6g==
X-Received: by 10.28.139.203 with SMTP id n194mr466615wmd.40.1461885703606; Thu, 28 Apr 2016 16:21:43 -0700 (PDT)
Received: from [10.5.166.229] (82-132-245-177.dab.02.net. [82.132.245.177]) by smtp.gmail.com with ESMTPSA id kj9sm11897665wjb.14.2016.04.28.16.21.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2016 16:21:42 -0700 (PDT)
References: <937ABB81-CCD9-4FD0-A7CF-5114384B3B94@gmail.com> <8D383418-4CBF-49C6-9871-4E31042E29E5@mnemosyne.demon.co.uk>  <9E042F54-58E4-4C1B-8F7B-ECAD41341D48@gmail.com>  
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-936BB89C-D831-43AD-819D-0D0461E1926F
Content-Transfer-Encoding: 7bit
Message-Id: <183DADD1-A689-4CA8-9B6D-854A0491A59B@gmail.com>
X-Mailer: iPhone Mail (13E238)
From: Christopher Dearlove 
Date: Fri, 29 Apr 2016 00:21:38 +0100
To: Stan Ratliff 
Archived-At: 
Cc: Christopher Dearlove , MANET IETF 
Subject: Re: [manet] AODVv2 security: Key Management to BCP107
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, 28 Apr 2016 23:21:50 -0000

--Apple-Mail-936BB89C-D831-43AD-819D-0D0461E1926F
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Building something into the base AODVv2 specification that relies on Cisco's=
 (or anyone else's) IPR isn't going to be acceptable either.

-- =20
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)

> On 28 Apr 2016, at 23:59, Stan Ratliff  wrote:
>=20
> There is some IPR that I'm aware of that may help out here - it's based on=
 my prior work at Cisco. I've already let Alvaro know; he's going to check i=
nto getting Cisco to make a disclosure...=20
>=20
> Regards,
> Stan
>=20
>=20
>> On Thu, Apr 28, 2016 at 4:11 PM, Christopher Dearlove  wrote:
>> I really wouldn't be interested in a system in which each router had to h=
ave knowledge of all other routers. Far too restrictive, and scales poorly. I=
t just might fly as a solution. As the solution, definitely not.
>>=20
>> Each router needing some preconfiguration, sure. See the IBS draft for ex=
ample.
>>=20
>> --
>> Christopher Dearlove
>> christopher.dearlove@gmail.com (iPhone)
>> chris@mnemosyne.demon.co.uk (home)
>>=20
>> > On 28 Apr 2016, at 20:37, John Dowdell  wr=
ote:
>> >
>> > By the way I have re-ordered the emails in this post to make it easier t=
o read for flow.
>> >>
>> >>>> On 27 Apr 2016, at 21:10, John Dowdell =
 wrote:
>> >>>>
>> >>>> Hi all
>> >>>>
>> >>>> As an AODVv2 co-author I=E2=80=99d like to propose this position reg=
arding key management against BCP107, one of the artefacts we are being aske=
d to state a position over. I=E2=80=99d also like to state that I=E2=80=99m o=
pen to contributions from others knowledgeable on this topic or who have bee=
n this way previously.
>> >>>>
>> >>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka B=
CP107 is the set of guidelines for choosing either automated or manual key m=
anagement for cryptographic purposes. It=E2=80=99s not a long read and guide=
s the reader through a set of tests as to whether automated or manual key ma=
nagement would be suitable for the application in hand.
>> >>>>
>> >>>> The very first question is does AODVv2 need key management at all? I=
 would contend that it does, since we require to secure the signalling traff=
ic for the routing algorithm. The aim here is therefore to purely assist in t=
he security of the signalling traffic; security of user data that is forward=
ed once an AODVv2 route has been established is out of scope.
>> >>>>
>> >>>> Section 1 of BCP107 states that automated key management SHOULD be u=
sed.. Thus my answer will be in favour of that unless I can contend otherwis=
e.
>> >>>>
>> >>>> The guidelines in section 2 outline that automated key management de=
rives short-term session keys between two parties. In the case of AODVv2, th=
is would correspond to two routers that form or wish to form an adjacency.
>> >>>>
>> >>>> The guidelines state that the short-term keys may be derived from lo=
ng-term keys, and that the dissemination of long term keys is out of scope o=
f BCP107. I would envisage that an AODVv2 router, given that it would form e=
phemeral ad hoc networks with other routers as it went about its business, w=
ould be supplied with one or more long term keys for a period of time, to be=
 determined by the system integrator, and that the long term keys would then=
 be used to derive short term keys which are used in the forming of adjacBy t=
he way I have re-ordered the emails in this post to make it easier to read f=
or flow.
>> >>
>> >>>> On 27 Apr 2016, at 21:10, John Dowdell =
 wrote:
>> >>>>
>> >>>> Hi all
>> >>>>
>> >>>> As an AODVv2 co-author I=E2=80=99d like to propose this position reg=
arding key management against BCP107, one of the artefacts we are being aske=
d to state a position over. I=E2=80=99d also like to state that I=E2=80=99m o=
pen to contributions from others knowledgeable on this topic or who have bee=
n this way previously.
>> >>>>
>> >>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka B=
CP107 is the set of guidelines for choosing either automated or manual key m=
anagement for cryptographic purposes. It=E2=80=99s not a long read and guide=
s the reader through a set of tests as to whether automated or manual key ma=
nagement would be suitable for the application in hand.
>> >>>>
>> >>>> The very first question is does AODVv2 need key management at all? I=
 would contend that it does, since we require to secure the signalling traff=
ic for the routing algorithm. The aim here is therefore to purely assist in t=
he security of the signalling traffic; security of user data that is forward=
ed once an AODVv2 route has been established is out of scope.
>> >>>>
>> >>>> Section 1 of BCP107 states that automated key management SHOULD be u=
sed. Thus my answer will be in favour of that unless I can contend otherwise=
.
>> >>>>
>> >>>> The guidelines in section 2 outline that automated key management de=
rives short-term session keys between two parties. In the case of AODVv2, th=
is would correspond to two routers that form or wish to form an adjacency.
>> >>>>
>> >>>> The guidelines state that the short-term keys may be derived from lo=
ng-term keys, and that the dissemination of long term keys is out of scope o=
f BCP107. I would envisage that an AODVv2 router, given that it would form e=
phemeral ad hoc networks with other routers as it went about its business, w=
ould be supplied with one or more long term keys for a period of time, to be=
 determined by the system integrator, and that the long term keys would then=
 be used to derive short term keys which are used in the forming of adjacenc=
ies plural.
>> >>>>
>> >>>> Section 2.1 of BCP107 describes the conditions under which automated=
 key management MUST be used.
>> >>>>
>> >>>> - If a large number of static keys would have to be managed. It is n=
ot known how many routers could be deployed, but if this is aimed at ad hoc a=
pplications then the number of routers could quickly become large. I conside=
r this condition is met.
>> >>>>
>> >>>> - Any stream cipher is used. This is a choice for the system integra=
tor, but an AES based cipher is a real possibility. There is more likelihood=
 this condition is met than not met.
>> >>>>
>> >>>> - An initialisation vector (IV) might be re-used. I am open to advic=
e on this point.
>> >>>>
>> >>>> - Large amounts of data need to be encrypted in a short time. Even i=
f there is no specific guidance on =E2=80=98large=E2=80=99, I do not conside=
r this condition to be met, since signalling messages are likely to be short=
 relative to the user data that could be exchanged.
>> >>>>
>> >>>> - Long-term session keys are used by more than two parties, includin=
g multicast applications. AODVv2 uses multicast extensively, and therefore I=
 consider this condition to be met.
>> >>>>
>> >>>> - Device turnover is frequent. This is a certainty in ad hoc network=
s, so I consider this condition to be met.
>> >>>>
>> >>>> I believe the outcomes from section 2.1 guidance is more in favour o=
f automated key management.
>> >>>>
>> >>>> However, to consider the guidance on manual key management in sectio=
n 2.2 of BCP107, where such management may be reasonable:
>> >>>>
>> >>>> - the environment has very limited bandwidth or high round trip time=
s. Some applications for AODVv2 may use very low bandwidths, perhaps for low=
-power sensor networks. The point is made that "public key systems require l=
ong exchanges and lots of computation=E2=80=9D. The AODVv2 author team belie=
ve that very low power hardware might be used by some implementors, which ma=
y give problems when being required to use public key exchanges. Such implem=
entors need to carefully consider the tradeoff between the need for security=
 and the need for very low power consumption. Such implementors should also c=
onsider whether some functions should be realised in hardware or software, a=
nd the resulting impact on system performance and power consumption.
>> >>>>
>> >>>> - the information being protected is of low value. I do not consider=
 this condition to be met; on the contrary, the signalling traffic in AODVv2=
 is of high value to a potential attacker.
>> >>>>
>> >>>> - the scale of each deployment is limited. I consider that this is a=
n unknown, but I also consider that we should engineer for larger networks w=
ith ephemeral connections rather than smaller ones.
>> >>>>
>> >>>> Discussion welcome.
>> >>>>
>> >>>> Regards
>> >>>> John
>> >>>>
>> >>>>
>> >>>>
>> >>
>> >>> On 27 Apr 2016, at 21:27, Christopher Dearlove  wrote:
>> >>>
>> >>> I really don't know what you are proposing. I think you have a great b=
ig can of worms here that hasn't been thought through.
>> >>>
>> >>> So AODVv2 is sending, as it's very first message, an RREQ. We want to=
 authenticate this. How? You can't negotiate a key, you haven't got a route.=
 You don't know who your neighbours are. You plan to multicast to them in fa=
ct, what's your key plan for that?
>> >>>
>> >>> If you say use long term key, what are you actually going to use the s=
hort term key for? And if you plan to exchange message with your neighbours,=
 that rather preempts a significant part of your protocol (why establish bid=
irectionality when your key negotiation must have done that?)
>> >>>
>> >>> And then we've spent some time discussing end to end authentication. T=
hat doesn't work with short term keys for adjacencies only.
>> >>>
>> >>> We (OLSRv2) went through, more than once, a hard argument why automat=
ed key management wasn't appropriate here, and why the exceptions did apply.=

>> >>>
>> >>> But in a nutshell (though this wasn't the argument we used, just why w=
e needed it) how can you agree a key without communicating? How do you commu=
nicate more than one hop without a route? How do you authenticate the messag=
es to create that route without a key?
>> >>>
>> >>> Something has to give. And in giving you might end up redesigning you=
r whole protocol. Or using something quite clever that there's no hint of he=
re. Or using the simplest fallback of a single shared key (our 7183 default)=
 which isn't automatically managed.
>> >>>
>> >>> --
>> >>> Christopher Dearlove
>> >>>
>> >> On 27 Apr 2016, at 22:38, John Dowdell  w=
rote:
>> >>
>> >> OK so there=E2=80=99s a really big problem here. We were asked to run t=
he guidance. Running the guidance gives the result below. In this case, the g=
uidance is not giving a result that makes sense. The routers themselves are a=
lmost certainly on the move, there is no other reason why you would want to o=
nly determine the path at send time. You now have routers potentially from m=
ultiple organisations occasionally conversing with other routers. I do not s=
ee that a single shared key is going to pass muster; I certainly wouldn=E2=80=
=99t recommend such a use case.
>> >>
>> >> Regards
>> >> John
>> >
>> > One possible way forwards is to require all routers to have knowledge o=
f some credentials of the other routers before AODVv2 can begin signalling. T=
his isn=E2=80=99t so crazy as it might seem. Suppose such routers are instal=
led in cars, and each manufacturer pre-loads the car with credentials of all=
 the other manufacturers that it trusts for signalling purposes. Thus Ford (=
say) might pre-load credentials for Volkswagens. When a Ford and a Volkswage=
n meet, they already have some degree of trust, and therefore the burden of p=
roof of identity in AODVv2 signalling is reduced, but not eliminated, becaus=
e then we would be open to spoofing.
>> >
>> > We are also here acting as part of a (hopefully) layered authentication=
 system. The wireless devices will presumably be authenticated to each other=
, through some system that is suitable for the task in hand, and above routi=
ng there should be some checks on incoming user data to see if that is sensi=
ble.
>> >
>> > Regards
>> > John
>> >
>> >>>>
>> >>>> _______________________________________________
>> >>>> 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

--Apple-Mail-936BB89C-D831-43AD-819D-0D0461E1926F
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Building something into the base AODVv=
2 specification that relies on Cisco's (or anyone else's) IPR isn't going to=
 be acceptable either.

--  
Christopher Dearlove
<=
a href=3D"mailto:christopher.dearlove@gmail.com">christopher.dearlove@gmail.=
com (iPhone)

On 28 Apr 2016, at 2=
3:59, Stan Ratliff <ratliffstan@=
gmail.com> wrote:

There is some IPR that I'm aware of that may help out here -=
 it's based on my prior work at Cisco. I've already let Alvaro know; he's go=
ing to check into getting Cisco to make a disclosure... 

Regard=
s,
Stan


<=
div class=3D"gmail_quote">On Thu, Apr 28, 2016 at 4:11 PM, Christopher Dearl=
ove <christopher.dearlove@gmail.com> wrote:
I really wouldn't be interested in a system in wh=
ich each router had to have knowledge of all other routers. Far too restrict=
ive, and scales poorly. It just might fly as a solution. As the solution, de=
finitely not.



Each router needing some preconfiguration, sure. See the IBS draft for examp=
le.



--

Christopher Dearlove

christopher.dearlove@gmail=
.com (iPhone)

chris@mnemosyne.demon.co.uk (home)



> On 28 Apr 2016, at 20:37, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

>

> By the way I have re-ordered the emails in this post to make it easier t=
o read for flow.

>>

>>>> On 27 Apr 2016, at 21:10, John Dowdell <john.dowdell.ietf@gmail.com> wrote:
>>>>

>>>> Hi all

>>>>

>>>> As an AODVv2 co-author I=E2=80=99d like to propose this pos=
ition regarding key management against BCP107, one of the artefacts we are b=
eing asked to state a position over. I=E2=80=99d also like to state that I=E2=
=80=99m open to contributions from others knowledgeable on this topic or who=
 have been this way previously.

>>>>

>>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4=
107 aka BCP107 is the set of guidelines for choosing either automated or man=
ual key management for cryptographic purposes. It=E2=80=99s not a long read a=
nd guides the reader through a set of tests as to whether automated or manua=
l key management would be suitable for the application in hand.

>>>>

>>>> The very first question is does AODVv2 need key management a=
t all? I would contend that it does, since we require to secure the signalli=
ng traffic for the routing algorithm. The aim here is therefore to purely as=
sist in the security of the signalling traffic; security of user data that i=
s forwarded once an AODVv2 route has been established is out of scope.

>>>>

>>>> Section 1 of BCP107 states that automated key management SH=
OULD be used.. Thus my answer will be in favour of that unless I can contend=
 otherwise.

>>>>

>>>> The guidelines in section 2 outline that automated key mana=
gement derives short-term session keys between two parties. In the case of A=
ODVv2, this would correspond to two routers that form or wish to form an adj=
acency.

>>>>

>>>> The guidelines state that the short-term keys may be derive=
d from long-term keys, and that the dissemination of long term keys is out o=
f scope of BCP107. I would envisage that an AODVv2 router, given that it wou=
ld form ephemeral ad hoc networks with other routers as it went about its bu=
siness, would be supplied with one or more long term keys for a period of ti=
me, to be determined by the system integrator, and that the long term keys w=
ould then be used to derive short term keys which are used in the forming of=
 adjacBy the way I have re-ordered the emails in this post to make it easier=
 to read for flow.

>>

>>>> On 27 Apr 2016, at 21:10, John Dowdell <john.dowdell.ietf@gmail.com> wrote:
>>>>

>>>> Hi all

>>>>

>>>> As an AODVv2 co-author I=E2=80=99d like to propose this pos=
ition regarding key management against BCP107, one of the artefacts we are b=
eing asked to state a position over. I=E2=80=99d also like to state that I=E2=
=80=99m open to contributions from others knowledgeable on this topic or who=
 have been this way previously.

>>>>

>>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4=
107 aka BCP107 is the set of guidelines for choosing either automated or man=
ual key management for cryptographic purposes. It=E2=80=99s not a long read a=
nd guides the reader through a set of tests as to whether automated or manua=
l key management would be suitable for the application in hand.

>>>>

>>>> The very first question is does AODVv2 need key management a=
t all? I would contend that it does, since we require to secure the signalli=
ng traffic for the routing algorithm. The aim here is therefore to purely as=
sist in the security of the signalling traffic; security of user data that i=
s forwarded once an AODVv2 route has been established is out of scope.

>>>>

>>>> Section 1 of BCP107 states that automated key management SH=
OULD be used. Thus my answer will be in favour of that unless I can contend o=
therwise.

>>>>

>>>> The guidelines in section 2 outline that automated key mana=
gement derives short-term session keys between two parties. In the case of A=
ODVv2, this would correspond to two routers that form or wish to form an adj=
acency.

>>>>

>>>> The guidelines state that the short-term keys may be derive=
d from long-term keys, and that the dissemination of long term keys is out o=
f scope of BCP107. I would envisage that an AODVv2 router, given that it wou=
ld form ephemeral ad hoc networks with other routers as it went about its bu=
siness, would be supplied with one or more long term keys for a period of ti=
me, to be determined by the system integrator, and that the long term keys w=
ould then be used to derive short term keys which are used in the forming of=
 adjacencies plural.

>>>>

>>>> Section 2.1 of BCP107 describes the conditions under which a=
utomated key management MUST be used.

>>>>

>>>> - If a large number of static keys would have to be managed=
. It is not known how many routers could be deployed, but if this is aimed a=
t ad hoc applications then the number of routers could quickly become large.=
 I consider this condition is met.

>>>>

>>>> - Any stream cipher is used. This is a choice for the syste=
m integrator, but an AES based cipher is a real possibility. There is more l=
ikelihood this condition is met than not met.

>>>>

>>>> - An initialisation vector (IV) might be re-used. I am open=
 to advice on this point.

>>>>

>>>> - Large amounts of data need to be encrypted in a short tim=
e. Even if there is no specific guidance on =E2=80=98large=E2=80=99, I do no=
t consider this condition to be met, since signalling messages are likely to=
 be short relative to the user data that could be exchanged.

>>>>

>>>> - Long-term session keys are used by more than two parties,=
 including multicast applications. AODVv2 uses multicast extensively, and th=
erefore I consider this condition to be met.

>>>>

>>>> - Device turnover is frequent. This is a certainty in ad ho=
c networks, so I consider this condition to be met.

>>>>

>>>> I believe the outcomes from section 2.1 guidance is more in=
 favour of automated key management.

>>>>

>>>> However, to consider the guidance on manual key management i=
n section 2.2 of BCP107, where such management may be reasonable:

>>>>

>>>> - the environment has very limited bandwidth or high round t=
rip times. Some applications for AODVv2 may use very low bandwidths, perhaps=
 for low-power sensor networks. The point is made that "public key systems r=
equire long exchanges and lots of computation=E2=80=9D. The AODVv2 author te=
am believe that very low power hardware might be used by some implementors, w=
hich may give problems when being required to use public key exchanges. Such=
 implementors need to carefully consider the tradeoff between the need for s=
ecurity and the need for very low power consumption. Such implementors shoul=
d also consider whether some functions should be realised in hardware or sof=
tware, and the resulting impact on system performance and power consumption.=


>>>>

>>>> - the information being protected is of low value. I do not=
 consider this condition to be met; on the contrary, the signalling traffic i=
n AODVv2 is of high value to a potential attacker.

>>>>

>>>> - the scale of each deployment is limited. I consider that t=
his is an unknown, but I also consider that we should engineer for larger ne=
tworks with ephemeral connections rather than smaller ones.

>>>>

>>>> Discussion welcome.

>>>>

>>>> Regards

>>>> John

>>>>

>>>>

>>>>

>>

>>> On 27 Apr 2016, at 21:27, Christopher Dearlove <chris@mnemosyne.demon.co.uk> wrote=
:

>>>

>>> I really don't know what you are proposing. I think you have a g=
reat big can of worms here that hasn't been thought through.

>>>

>>> So AODVv2 is sending, as it's very first message, an RREQ. We w=
ant to authenticate this. How? You can't negotiate a key, you haven't got a r=
oute. You don't know who your neighbours are. You plan to multicast to them i=
n fact, what's your key plan for that?

>>>

>>> If you say use long term key, what are you actually going to us=
e the short term key for? And if you plan to exchange message with your neig=
hbours, that rather preempts a significant part of your protocol (why establ=
ish bidirectionality when your key negotiation must have done that?)

>>>

>>> And then we've spent some time discussing end to end authentica=
tion. That doesn't work with short term keys for adjacencies only.

>>>

>>> We (OLSRv2) went through, more than once, a hard argument why a=
utomated key management wasn't appropriate here, and why the exceptions did a=
pply.

>>>

>>> But in a nutshell (though this wasn't the argument we used, jus=
t why we needed it) how can you agree a key without communicating? How do yo=
u communicate more than one hop without a route? How do you authenticate the=
 messages to create that route without a key?

>>>

>>> Something has to give. And in giving you might end up redesigni=
ng your whole protocol. Or using something quite clever that there's no hint=
 of here. Or using the simplest fallback of a single shared key (our 7183 de=
fault) which isn't automatically managed.

>>>

>>> --

>>> Christopher Dearlove

>>>

>> On 27 Apr 2016, at 22:38, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

>>

>> OK so there=E2=80=99s a really big problem here. We were asked to r=
un the guidance. Running the guidance gives the result below. In this case, t=
he guidance is not giving a result that makes sense. The routers themselves a=
re almost certainly on the move, there is no other reason why you would want=
 to only determine the path at send time. You now have routers potentially f=
rom multiple organisations occasionally conversing with other routers. I do n=
ot see that a single shared key is going to pass muster; I certainly wouldn=E2=
=80=99t recommend such a use case.

>>

>> Regards

>> John

>

> One possible way forwards is to require all routers to have knowledge o=
f some credentials of the other routers before AODVv2 can begin signalling. T=
his isn=E2=80=99t so crazy as it might seem. Suppose such routers are instal=
led in cars, and each manufacturer pre-loads the car with credentials of all=
 the other manufacturers that it trusts for signalling purposes. Thus Ford (=
say) might pre-load credentials for Volkswagens. When a Ford and a Volkswage=
n meet, they already have some degree of trust, and therefore the burden of p=
roof of identity in AODVv2 signalling is reduced, but not eliminated, becaus=
e then we would be open to spoofing.

>

> We are also here acting as part of a (hopefully) layered authentication=
 system. The wireless devices will presumably be authenticated to each other=
, through some system that is suitable for the task in hand, and above routi=
ng there should be some checks on incoming user data to see if that is sensi=
ble.

>

> Regards

> John

>

>>>>

>>>> _______________________________________________

>>>> manet mailing list

>>>> manet@ietf.org

>>>> https://www.ietf.org/mailman/listinfo/mane=
t

>>>

>>

>



_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet




=

--Apple-Mail-936BB89C-D831-43AD-819D-0D0461E1926F--


From nobody Thu Apr 28 16:24:32 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 7B40712D13F for ; Thu, 28 Apr 2016 16:24:30 -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 8khyS6_cOZyn for ; Thu, 28 Apr 2016 16:24:26 -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 8191712D117 for ; Thu, 28 Apr 2016 16:24:25 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id g17so9760321wme.1 for ; Thu, 28 Apr 2016 16:24:25 -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=c52lRk+rBgoseiZkSfpRIG7UBQqTvDWklHUMXXYknCE=; b=I7n9wQmm3Nh3C8xcibVPphqT8mkxcyg20iKc+dFVi6HthUuciMyz9tyC0IOE3hdROq xXIl2aSB1WqrBMOUN+hPcLxmg4z9xYH5o2G6xC22s1zJhvbsEqcupSI5AZskmewlBKot KOT5MMgMIxez5fKM817KxqfbxPaeyegPbb66S939LezjFyxoHSV/sYeGeV/suE+sVsCt wQAsRaEKMhMckyT1LYd5SyKSPeSkdfsLn+k+0H8zXZA8bcY7vrK0AHcd5L09r/pk6M90 JHu6szZ+8OgM+xaUrSRiY8t5lVhczQKEc01krle55hQj6Cu1YQ2PRI2kzzv5yGeXPe3M fUZg==
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=c52lRk+rBgoseiZkSfpRIG7UBQqTvDWklHUMXXYknCE=; b=Tw4QWIe8/ixJ/Ek6uhBpRVVUCEcaZvQQsgHOHWp3fNjG7iogyIfHYwlhbgfSOKiJar fKOP8PKbdKcDKd3+YLEJI9C6jvtE59FPdapwQ281QT60alzh/jleFF+5ULpUdI2a91iQ OhB+ZZKWrPGO541nXmJ6cQm/X3UiwjJLi8RebDu06R4QOQPi72IpDM5H42+h3xZTbgok pkYwBD7i8FZkbeZqpm/DzMO+VUNJz95VMy6vMSvAyB+0KPMxnVJx/JAN4KHjY16gT0SP OoKD/cePN38c19cG6/wvtmqf9nQcHVqc/kYnz64X/A2Mk3y5e5FSfRjlYoZXwStqYPzx WRTg==
X-Gm-Message-State: AOPr4FWuaoGBQR8STgNne/eL++p7OtcGFgzLQaC29hfJxfLlaiTFe4BbjZCpw6+iGymNgg==
X-Received: by 10.28.26.78 with SMTP id a75mr409969wma.59.1461885864043; Thu, 28 Apr 2016 16:24:24 -0700 (PDT)
Received: from [10.5.166.229] (82-132-245-177.dab.02.net. [82.132.245.177]) by smtp.gmail.com with ESMTPSA id n66sm420405wmf.6.2016.04.28.16.24.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2016 16:24:23 -0700 (PDT)
References: <937ABB81-CCD9-4FD0-A7CF-5114384B3B94@gmail.com> <8D383418-4CBF-49C6-9871-4E31042E29E5@mnemosyne.demon.co.uk>  <9E042F54-58E4-4C1B-8F7B-ECAD41341D48@gmail.com>   <183DADD1-A689-4CA8-9B6D-854A0491A59B@gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <183DADD1-A689-4CA8-9B6D-854A0491A59B@gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-52934DC5-697C-4D12-8FD5-4D97D1F30088
Content-Transfer-Encoding: 7bit
Message-Id: <4300FD7F-E91C-4A61-908B-C832361AE657@gmail.com>
X-Mailer: iPhone Mail (13E238)
From: Christopher Dearlove 
Date: Fri, 29 Apr 2016 00:24:19 +0100
To: Stan Ratliff 
Archived-At: 
Cc: MANET IETF 
Subject: Re: [manet] AODVv2 security: Key Management to BCP107
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, 28 Apr 2016 23:24:30 -0000

--Apple-Mail-52934DC5-697C-4D12-8FD5-4D97D1F30088
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I meant to add might however be interesting, even useful in another case.

--=20
Christopher Dearlove

> On 29 Apr 2016, at 00:21, Christopher Dearlove  wrote:
>=20
> Building something into the base AODVv2 specification that relies on Cisco=
's (or anyone else's) IPR isn't going to be acceptable either.
>=20
> -- =20
> Christopher Dearlove
>=20
>> On 28 Apr 2016, at 23:59, Stan Ratliff  wrote:
>>=20
>> There is some IPR that I'm aware of that may help out here - it's based o=
n my prior work at Cisco. I've already let Alvaro know; he's going to check i=
nto getting Cisco to make a disclosure...=20
>>=20
>> Regards,
>> Stan
>>=20
>>=20
>>> On Thu, Apr 28, 2016 at 4:11 PM, Christopher Dearlove  wrote:
>>> I really wouldn't be interested in a system in which each router had to h=
ave knowledge of all other routers. Far too restrictive, and scales poorly. I=
t just might fly as a solution. As the solution, definitely not.
>>>=20
>>> Each router needing some preconfiguration, sure. See the IBS draft for e=
xample.
>>>=20
>>> --
>>> Christopher Dearlove
>>> christopher.dearlove@gmail.com (iPhone)
>>> chris@mnemosyne.demon.co.uk (home)
>>>=20
>>> > On 28 Apr 2016, at 20:37, John Dowdell  w=
rote:
>>> >
>>> > By the way I have re-ordered the emails in this post to make it easier=
 to read for flow.
>>> >>
>>> >>>> On 27 Apr 2016, at 21:10, John Dowdell  wrote:
>>> >>>>
>>> >>>> Hi all
>>> >>>>
>>> >>>> As an AODVv2 co-author I=E2=80=99d like to propose this position re=
garding key management against BCP107, one of the artefacts we are being ask=
ed to state a position over. I=E2=80=99d also like to state that I=E2=80=99m=
 open to contributions from others knowledgeable on this topic or who have b=
een this way previously.
>>> >>>>
>>> >>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka B=
CP107 is the set of guidelines for choosing either automated or manual key m=
anagement for cryptographic purposes. It=E2=80=99s not a long read and guide=
s the reader through a set of tests as to whether automated or manual key ma=
nagement would be suitable for the application in hand.
>>> >>>>
>>> >>>> The very first question is does AODVv2 need key management at all? I=
 would contend that it does, since we require to secure the signalling traff=
ic for the routing algorithm. The aim here is therefore to purely assist in t=
he security of the signalling traffic; security of user data that is forward=
ed once an AODVv2 route has been established is out of scope.
>>> >>>>
>>> >>>> Section 1 of BCP107 states that automated key management SHOULD be u=
sed.. Thus my answer will be in favour of that unless I can contend otherwis=
e.
>>> >>>>
>>> >>>> The guidelines in section 2 outline that automated key management d=
erives short-term session keys between two parties. In the case of AODVv2, t=
his would correspond to two routers that form or wish to form an adjacency.
>>> >>>>
>>> >>>> The guidelines state that the short-term keys may be derived from l=
ong-term keys, and that the dissemination of long term keys is out of scope o=
f BCP107. I would envisage that an AODVv2 router, given that it would form e=
phemeral ad hoc networks with other routers as it went about its business, w=
ould be supplied with one or more long term keys for a period of time, to be=
 determined by the system integrator, and that the long term keys would then=
 be used to derive short term keys which are used in the forming of adjacBy t=
he way I have re-ordered the emails in this post to make it easier to read f=
or flow.
>>> >>
>>> >>>> On 27 Apr 2016, at 21:10, John Dowdell  wrote:
>>> >>>>
>>> >>>> Hi all
>>> >>>>
>>> >>>> As an AODVv2 co-author I=E2=80=99d like to propose this position re=
garding key management against BCP107, one of the artefacts we are being ask=
ed to state a position over. I=E2=80=99d also like to state that I=E2=80=99m=
 open to contributions from others knowledgeable on this topic or who have b=
een this way previously.
>>> >>>>
>>> >>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4107 aka B=
CP107 is the set of guidelines for choosing either automated or manual key m=
anagement for cryptographic purposes. It=E2=80=99s not a long read and guide=
s the reader through a set of tests as to whether automated or manual key ma=
nagement would be suitable for the application in hand.
>>> >>>>
>>> >>>> The very first question is does AODVv2 need key management at all? I=
 would contend that it does, since we require to secure the signalling traff=
ic for the routing algorithm. The aim here is therefore to purely assist in t=
he security of the signalling traffic; security of user data that is forward=
ed once an AODVv2 route has been established is out of scope.
>>> >>>>
>>> >>>> Section 1 of BCP107 states that automated key management SHOULD be u=
sed. Thus my answer will be in favour of that unless I can contend otherwise=
.
>>> >>>>
>>> >>>> The guidelines in section 2 outline that automated key management d=
erives short-term session keys between two parties. In the case of AODVv2, t=
his would correspond to two routers that form or wish to form an adjacency.
>>> >>>>
>>> >>>> The guidelines state that the short-term keys may be derived from l=
ong-term keys, and that the dissemination of long term keys is out of scope o=
f BCP107. I would envisage that an AODVv2 router, given that it would form e=
phemeral ad hoc networks with other routers as it went about its business, w=
ould be supplied with one or more long term keys for a period of time, to be=
 determined by the system integrator, and that the long term keys would then=
 be used to derive short term keys which are used in the forming of adjacenc=
ies plural.
>>> >>>>
>>> >>>> Section 2.1 of BCP107 describes the conditions under which automate=
d key management MUST be used.
>>> >>>>
>>> >>>> - If a large number of static keys would have to be managed. It is n=
ot known how many routers could be deployed, but if this is aimed at ad hoc a=
pplications then the number of routers could quickly become large. I conside=
r this condition is met.
>>> >>>>
>>> >>>> - Any stream cipher is used. This is a choice for the system integr=
ator, but an AES based cipher is a real possibility. There is more likelihoo=
d this condition is met than not met.
>>> >>>>
>>> >>>> - An initialisation vector (IV) might be re-used. I am open to advi=
ce on this point.
>>> >>>>
>>> >>>> - Large amounts of data need to be encrypted in a short time. Even i=
f there is no specific guidance on =E2=80=98large=E2=80=99, I do not conside=
r this condition to be met, since signalling messages are likely to be short=
 relative to the user data that could be exchanged.
>>> >>>>
>>> >>>> - Long-term session keys are used by more than two parties, includi=
ng multicast applications. AODVv2 uses multicast extensively, and therefore I=
 consider this condition to be met.
>>> >>>>
>>> >>>> - Device turnover is frequent. This is a certainty in ad hoc networ=
ks, so I consider this condition to be met.
>>> >>>>
>>> >>>> I believe the outcomes from section 2.1 guidance is more in favour o=
f automated key management.
>>> >>>>
>>> >>>> However, to consider the guidance on manual key management in secti=
on 2.2 of BCP107, where such management may be reasonable:
>>> >>>>
>>> >>>> - the environment has very limited bandwidth or high round trip tim=
es. Some applications for AODVv2 may use very low bandwidths, perhaps for lo=
w-power sensor networks. The point is made that "public key systems require l=
ong exchanges and lots of computation=E2=80=9D. The AODVv2 author team belie=
ve that very low power hardware might be used by some implementors, which ma=
y give problems when being required to use public key exchanges. Such implem=
entors need to carefully consider the tradeoff between the need for security=
 and the need for very low power consumption. Such implementors should also c=
onsider whether some functions should be realised in hardware or software, a=
nd the resulting impact on system performance and power consumption.
>>> >>>>
>>> >>>> - the information being protected is of low value. I do not conside=
r this condition to be met; on the contrary, the signalling traffic in AODVv=
2 is of high value to a potential attacker.
>>> >>>>
>>> >>>> - the scale of each deployment is limited. I consider that this is a=
n unknown, but I also consider that we should engineer for larger networks w=
ith ephemeral connections rather than smaller ones.
>>> >>>>
>>> >>>> Discussion welcome.
>>> >>>>
>>> >>>> Regards
>>> >>>> John
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>
>>> >>> On 27 Apr 2016, at 21:27, Christopher Dearlove  wrote:
>>> >>>
>>> >>> I really don't know what you are proposing. I think you have a great=
 big can of worms here that hasn't been thought through.
>>> >>>
>>> >>> So AODVv2 is sending, as it's very first message, an RREQ. We want t=
o authenticate this. How? You can't negotiate a key, you haven't got a route=
. You don't know who your neighbours are. You plan to multicast to them in f=
act, what's your key plan for that?
>>> >>>
>>> >>> If you say use long term key, what are you actually going to use the=
 short term key for? And if you plan to exchange message with your neighbour=
s, that rather preempts a significant part of your protocol (why establish b=
idirectionality when your key negotiation must have done that?)
>>> >>>
>>> >>> And then we've spent some time discussing end to end authentication.=
 That doesn't work with short term keys for adjacencies only.
>>> >>>
>>> >>> We (OLSRv2) went through, more than once, a hard argument why automa=
ted key management wasn't appropriate here, and why the exceptions did apply=
.
>>> >>>
>>> >>> But in a nutshell (though this wasn't the argument we used, just why=
 we needed it) how can you agree a key without communicating? How do you com=
municate more than one hop without a route? How do you authenticate the mess=
ages to create that route without a key?
>>> >>>
>>> >>> Something has to give. And in giving you might end up redesigning yo=
ur whole protocol. Or using something quite clever that there's no hint of h=
ere. Or using the simplest fallback of a single shared key (our 7183 default=
) which isn't automatically managed.
>>> >>>
>>> >>> --
>>> >>> Christopher Dearlove
>>> >>>
>>> >> On 27 Apr 2016, at 22:38, John Dowdell  w=
rote:
>>> >>
>>> >> OK so there=E2=80=99s a really big problem here. We were asked to run=
 the guidance. Running the guidance gives the result below. In this case, th=
e guidance is not giving a result that makes sense. The routers themselves a=
re almost certainly on the move, there is no other reason why you would want=
 to only determine the path at send time. You now have routers potentially f=
rom multiple organisations occasionally conversing with other routers. I do n=
ot see that a single shared key is going to pass muster; I certainly wouldn=E2=
=80=99t recommend such a use case.
>>> >>
>>> >> Regards
>>> >> John
>>> >
>>> > One possible way forwards is to require all routers to have knowledge o=
f some credentials of the other routers before AODVv2 can begin signalling. T=
his isn=E2=80=99t so crazy as it might seem. Suppose such routers are instal=
led in cars, and each manufacturer pre-loads the car with credentials of all=
 the other manufacturers that it trusts for signalling purposes. Thus Ford (=
say) might pre-load credentials for Volkswagens. When a Ford and a Volkswage=
n meet, they already have some degree of trust, and therefore the burden of p=
roof of identity in AODVv2 signalling is reduced, but not eliminated, becaus=
e then we would be open to spoofing.
>>> >
>>> > We are also here acting as part of a (hopefully) layered authenticatio=
n system. The wireless devices will presumably be authenticated to each othe=
r, through some system that is suitable for the task in hand, and above rout=
ing there should be some checks on incoming user data to see if that is sens=
ible.
>>> >
>>> > Regards
>>> > John
>>> >
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> 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

--Apple-Mail-52934DC5-697C-4D12-8FD5-4D97D1F30088
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I meant to add might however be intere=
sting, even useful in another case.

-- 
Christopher Dearlove=


On 29 Apr 2016, at 00:21, Christopher Dearlove <christopher.dearlove@gmail.com=
> wrote:

Building something i=
nto the base AODVv2 specification that relies on Cisco's (or anyone else's) I=
PR isn't going to be acceptable either.

--  
Christopher Dea=
rlove

On 28 Apr 2016, at 23:59, Stan Ratliff <ratliffstan@gmail.com> wrote:
There is some=
 IPR that I'm aware of that may help out here - it's based on my prior work a=
t Cisco. I've already let Alvaro know; he's going to check into getting Cisc=
o to make a disclosure... 

Regards,
Stan

<=
div>

On T=
hu, Apr 28, 2016 at 4:11 PM, Christopher Dearlove <christopher.=
dearlove@gmail.com> wrote:
I r=
eally wouldn't be interested in a system in which each router had to have kn=
owledge of all other routers. Far too restrictive, and scales poorly. It jus=
t might fly as a solution. As the solution, definitely not.



Each router needing some preconfiguration, sure. See the IBS draft for examp=
le.



--

Christopher Dearlove

christopher.dearlove@gmail=
.com (iPhone)

chris@mnemosyne.demon.co.uk (home)



> On 28 Apr 2016, at 20:37, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

>

> By the way I have re-ordered the emails in this post to make it easier t=
o read for flow.

>>

>>>> On 27 Apr 2016, at 21:10, John Dowdell <john.dowdell.ietf@gmail.com> wrote:
>>>>

>>>> Hi all

>>>>

>>>> As an AODVv2 co-author I=E2=80=99d like to propose this pos=
ition regarding key management against BCP107, one of the artefacts we are b=
eing asked to state a position over. I=E2=80=99d also like to state that I=E2=
=80=99m open to contributions from others knowledgeable on this topic or who=
 have been this way previously.

>>>>

>>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4=
107 aka BCP107 is the set of guidelines for choosing either automated or man=
ual key management for cryptographic purposes. It=E2=80=99s not a long read a=
nd guides the reader through a set of tests as to whether automated or manua=
l key management would be suitable for the application in hand.

>>>>

>>>> The very first question is does AODVv2 need key management a=
t all? I would contend that it does, since we require to secure the signalli=
ng traffic for the routing algorithm. The aim here is therefore to purely as=
sist in the security of the signalling traffic; security of user data that i=
s forwarded once an AODVv2 route has been established is out of scope.

>>>>

>>>> Section 1 of BCP107 states that automated key management SH=
OULD be used.. Thus my answer will be in favour of that unless I can contend=
 otherwise.

>>>>

>>>> The guidelines in section 2 outline that automated key mana=
gement derives short-term session keys between two parties. In the case of A=
ODVv2, this would correspond to two routers that form or wish to form an adj=
acency.

>>>>

>>>> The guidelines state that the short-term keys may be derive=
d from long-term keys, and that the dissemination of long term keys is out o=
f scope of BCP107. I would envisage that an AODVv2 router, given that it wou=
ld form ephemeral ad hoc networks with other routers as it went about its bu=
siness, would be supplied with one or more long term keys for a period of ti=
me, to be determined by the system integrator, and that the long term keys w=
ould then be used to derive short term keys which are used in the forming of=
 adjacBy the way I have re-ordered the emails in this post to make it easier=
 to read for flow.

>>

>>>> On 27 Apr 2016, at 21:10, John Dowdell <john.dowdell.ietf@gmail.com> wrote:
>>>>

>>>> Hi all

>>>>

>>>> As an AODVv2 co-author I=E2=80=99d like to propose this pos=
ition regarding key management against BCP107, one of the artefacts we are b=
eing asked to state a position over. I=E2=80=99d also like to state that I=E2=
=80=99m open to contributions from others knowledgeable on this topic or who=
 have been this way previously.

>>>>

>>>> If you=E2=80=99re not familiar (and I wasn=E2=80=99t), RFC4=
107 aka BCP107 is the set of guidelines for choosing either automated or man=
ual key management for cryptographic purposes. It=E2=80=99s not a long read a=
nd guides the reader through a set of tests as to whether automated or manua=
l key management would be suitable for the application in hand.

>>>>

>>>> The very first question is does AODVv2 need key management a=
t all? I would contend that it does, since we require to secure the signalli=
ng traffic for the routing algorithm. The aim here is therefore to purely as=
sist in the security of the signalling traffic; security of user data that i=
s forwarded once an AODVv2 route has been established is out of scope.

>>>>

>>>> Section 1 of BCP107 states that automated key management SH=
OULD be used. Thus my answer will be in favour of that unless I can contend o=
therwise.

>>>>

>>>> The guidelines in section 2 outline that automated key mana=
gement derives short-term session keys between two parties. In the case of A=
ODVv2, this would correspond to two routers that form or wish to form an adj=
acency.

>>>>

>>>> The guidelines state that the short-term keys may be derive=
d from long-term keys, and that the dissemination of long term keys is out o=
f scope of BCP107. I would envisage that an AODVv2 router, given that it wou=
ld form ephemeral ad hoc networks with other routers as it went about its bu=
siness, would be supplied with one or more long term keys for a period of ti=
me, to be determined by the system integrator, and that the long term keys w=
ould then be used to derive short term keys which are used in the forming of=
 adjacencies plural.

>>>>

>>>> Section 2.1 of BCP107 describes the conditions under which a=
utomated key management MUST be used.

>>>>

>>>> - If a large number of static keys would have to be managed=
. It is not known how many routers could be deployed, but if this is aimed a=
t ad hoc applications then the number of routers could quickly become large.=
 I consider this condition is met.

>>>>

>>>> - Any stream cipher is used. This is a choice for the syste=
m integrator, but an AES based cipher is a real possibility. There is more l=
ikelihood this condition is met than not met.

>>>>

>>>> - An initialisation vector (IV) might be re-used. I am open=
 to advice on this point.

>>>>

>>>> - Large amounts of data need to be encrypted in a short tim=
e. Even if there is no specific guidance on =E2=80=98large=E2=80=99, I do no=
t consider this condition to be met, since signalling messages are likely to=
 be short relative to the user data that could be exchanged.

>>>>

>>>> - Long-term session keys are used by more than two parties,=
 including multicast applications. AODVv2 uses multicast extensively, and th=
erefore I consider this condition to be met.

>>>>

>>>> - Device turnover is frequent. This is a certainty in ad ho=
c networks, so I consider this condition to be met.

>>>>

>>>> I believe the outcomes from section 2.1 guidance is more in=
 favour of automated key management.

>>>>

>>>> However, to consider the guidance on manual key management i=
n section 2.2 of BCP107, where such management may be reasonable:

>>>>

>>>> - the environment has very limited bandwidth or high round t=
rip times. Some applications for AODVv2 may use very low bandwidths, perhaps=
 for low-power sensor networks. The point is made that "public key systems r=
equire long exchanges and lots of computation=E2=80=9D. The AODVv2 author te=
am believe that very low power hardware might be used by some implementors, w=
hich may give problems when being required to use public key exchanges. Such=
 implementors need to carefully consider the tradeoff between the need for s=
ecurity and the need for very low power consumption. Such implementors shoul=
d also consider whether some functions should be realised in hardware or sof=
tware, and the resulting impact on system performance and power consumption.=


>>>>

>>>> - the information being protected is of low value. I do not=
 consider this condition to be met; on the contrary, the signalling traffic i=
n AODVv2 is of high value to a potential attacker.

>>>>

>>>> - the scale of each deployment is limited. I consider that t=
his is an unknown, but I also consider that we should engineer for larger ne=
tworks with ephemeral connections rather than smaller ones.

>>>>

>>>> Discussion welcome.

>>>>

>>>> Regards

>>>> John

>>>>

>>>>

>>>>

>>

>>> On 27 Apr 2016, at 21:27, Christopher Dearlove <chris@mnemosyne.demon.co.uk> wrote=
:

>>>

>>> I really don't know what you are proposing. I think you have a g=
reat big can of worms here that hasn't been thought through.

>>>

>>> So AODVv2 is sending, as it's very first message, an RREQ. We w=
ant to authenticate this. How? You can't negotiate a key, you haven't got a r=
oute. You don't know who your neighbours are. You plan to multicast to them i=
n fact, what's your key plan for that?

>>>

>>> If you say use long term key, what are you actually going to us=
e the short term key for? And if you plan to exchange message with your neig=
hbours, that rather preempts a significant part of your protocol (why establ=
ish bidirectionality when your key negotiation must have done that?)

>>>

>>> And then we've spent some time discussing end to end authentica=
tion. That doesn't work with short term keys for adjacencies only.

>>>

>>> We (OLSRv2) went through, more than once, a hard argument why a=
utomated key management wasn't appropriate here, and why the exceptions did a=
pply.

>>>

>>> But in a nutshell (though this wasn't the argument we used, jus=
t why we needed it) how can you agree a key without communicating? How do yo=
u communicate more than one hop without a route? How do you authenticate the=
 messages to create that route without a key?

>>>

>>> Something has to give. And in giving you might end up redesigni=
ng your whole protocol. Or using something quite clever that there's no hint=
 of here. Or using the simplest fallback of a single shared key (our 7183 de=
fault) which isn't automatically managed.

>>>

>>> --

>>> Christopher Dearlove

>>>

>> On 27 Apr 2016, at 22:38, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

>>

>> OK so there=E2=80=99s a really big problem here. We were asked to r=
un the guidance. Running the guidance gives the result below. In this case, t=
he guidance is not giving a result that makes sense. The routers themselves a=
re almost certainly on the move, there is no other reason why you would want=
 to only determine the path at send time. You now have routers potentially f=
rom multiple organisations occasionally conversing with other routers. I do n=
ot see that a single shared key is going to pass muster; I certainly wouldn=E2=
=80=99t recommend such a use case.

>>

>> Regards

>> John

>

> One possible way forwards is to require all routers to have knowledge o=
f some credentials of the other routers before AODVv2 can begin signalling. T=
his isn=E2=80=99t so crazy as it might seem. Suppose such routers are instal=
led in cars, and each manufacturer pre-loads the car with credentials of all=
 the other manufacturers that it trusts for signalling purposes. Thus Ford (=
say) might pre-load credentials for Volkswagens. When a Ford and a Volkswage=
n meet, they already have some degree of trust, and therefore the burden of p=
roof of identity in AODVv2 signalling is reduced, but not eliminated, becaus=
e then we would be open to spoofing.

>

> We are also here acting as part of a (hopefully) layered authentication=
 system. The wireless devices will presumably be authenticated to each other=
, through some system that is suitable for the task in hand, and above routi=
ng there should be some checks on incoming user data to see if that is sensi=
ble.

>

> Regards

> John

>

>>>>

>>>> _______________________________________________

>>>> manet mailing list

>>>> manet@ietf.org

>>>> https://www.ietf.org/mailman/listinfo/mane=
t

>>>

>>

>



_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet





=

--Apple-Mail-52934DC5-697C-4D12-8FD5-4D97D1F30088--


From nobody Fri Apr 29 09:04: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 EB0B912B02C for ; Fri, 29 Apr 2016 09:04:51 -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 pEK1fzRcmFY5 for ; Fri, 29 Apr 2016 09:04:50 -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 D320712B012 for ; Fri, 29 Apr 2016 09:04:49 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.24,552,1454976000"; d="scan'208";a="34497285"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 29 Apr 2016 17:04:48 +0100
X-IronPort-AV: E=Sophos;i="5.24,552,1454976000"; d="scan'208";a="116117505"
Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 29 Apr 2016 17:04:48 +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; Fri, 29 Apr 2016 17:04:48 +0100
From: "Dearlove, Christopher (UK)" 
To: "manet@ietf.org" 
Thread-Topic: draft-ietf-manet-rfc5444-usage
Thread-Index: AdGiMGOHnWZV2LzgSKGOdp7rWDj9Zg==
Date: Fri, 29 Apr 2016 16:04:47 +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: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [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: Fri, 29 Apr 2016 16:04:52 -0000

WGLC having finished, I've been through everyone's comments. And by my reck=
oning this is what we (the authors) should do (agreed changes, and in at le=
ast one case I had an "aha" that's what I think is being asked for, in whic=
h case we can 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 everyt=
hing 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 r=
outer 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 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  5444 only specifies formats; parsing (and its opposite=
 - 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 protocol=
s (e.g. NHDP and OLSRv2). Some comments are about if you choose to do latte=
r, especially Section 6.4 but don't leave first mention to there. But a sep=
arate 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 in=
clude" 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).

- Probably (if there's a suitable place to say it) note that the multiplexe=
r 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=
 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
__________________________________________________________________________

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

********************************************************************
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 Sat Apr 30 04:18:09 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 141D512B058 for ; Sat, 30 Apr 2016 04:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.186
X-Spam-Level: 
X-Spam-Status: No, score=-5.186 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, 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 thtkLYekohIM for ; Sat, 30 Apr 2016 04:18:01 -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 531A812B005 for ; Sat, 30 Apr 2016 04:18:00 -0700 (PDT)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1awSuL-0002fq-Rt>; Sat, 30 Apr 2016 13:17:58 +0200
Received: from [37.120.25.84] (helo=[192.168.0.49]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (envelope-from ) id <1awSuK-002YyR-UZ>; Sat, 30 Apr 2016 13:17:57 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_490F6F32-7BCB-465F-9F37-72E62219BC95"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Lotte Steenbrink 
In-Reply-To: <944B9E01-74B7-45AD-ACB8-FA79347BC22E@fu-berlin.de>
Date: Sat, 30 Apr 2016 13:17:56 +0200
Message-Id: 
References:   <56D4EB7D.4010002@earthlink.net>  <944B9E01-74B7-45AD-ACB8-FA79347BC22E@fu-berlin.de>
To: manet 
X-Mailer: Apple Mail (2.3112)
X-Originating-IP: 37.120.25.84
X-ZEDAT-Hint: A
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: Sat, 30 Apr 2016 11:18:08 -0000

--Apple-Mail=_490F6F32-7BCB-465F-9F37-72E62219BC95
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,
for the sake of completeness, the paper we=E2=80=99ve mentioned is =
available on arXiv now:

http://arxiv.org/abs/1604.07179

And you can find the code of the tool that was used here: =
https://github.com/b-yousefi/wRebeca

Kind regards,
Lotte

> Am 16.03.2016 um 18:12 schrieb Lotte Steenbrink =
:
>=20
> Hi Christopher,
>=20
>> Am 02.03.2016 um 11:36 schrieb Dearlove, Christopher (UK) =
>:
>>=20
>> My concerns have been that your co-authors have continued to discuss =
whether looping could occur since you published to the list saying all =
was well. (An issue to do with multiple unconfirmed routes.) Maybe =
that=E2=80=99s a problem, maybe it isn=E2=80=99t. But it lacks =
transparency, because it hasn=E2=80=99t been discussed here.
>=20
> The loop possibility you=E2=80=99re referring to was a different one =
than the one discussed by Charlie. We=E2=80=99ve been contacted by =
researchers who are model checking MANET protocols to see if they permit =
any unwanted behaviour. They=E2=80=99ve used AODVv2 as a case study for =
the framework they=E2=80=99ve implemented to do this, and they=E2=80=99ve =
found the following loop:
>=20
> 
>=20
> 1. n2 initiates a route discovery procedure for destination n3 by =
broadcasting a =E2=80=9Crreq=E2=80=9D message.
> 2. n1 and n4 upon receiving the =E2=80=9Crreq=E2=80=9D message, add a =
route to their routing tables towards n2 and store n2 as their next hop. =
Since it is the first time that these nodes have received a message from =
n2, the neighbor state of n2 is set to unconfirmed. Therefore, the route =
state is unconfirmed.
> 3. As n1 and n4 are not the intended destination of the route request, =
they rebroadcast the =E2=80=9Crreq=E2=80=9D message.
> 4. n1 receives the =E2=80=9Crreq=E2=80=9D message sent by n4 and since =
the route to n2 is unconfirmed it adds n4 as new next hop to n2.
> 5. n4 also adds n1 as the new next hop towards n2 after processing the =
=E2=80=9Crreq=E2=80=9D sent by node1. At this point a loop is formed =
between n1 and n4 but not used yet.
> 6. n3 receives the =E2=80=9Crreq=E2=80=9D message sent by n1 and since =
it is the destination, it sends a =E2=80=9Crrep=E2=80=9D message towards =
n1.
> 7. n2 moves out of n1 and n4 communication range.
> 8. n1 receives the =E2=80=9Crrep=E2=80=9D message sent by n3 and as =
the route state towards n2 is unconfirmed it multicasts the =E2=80=9Crrep=E2=
=80=9D message to the existing next hops, n2 and n4. Since n4 is =
adjacent to n1, it receives the message and then sends an ack to n1. =
Therefore, n1 sets the neighbor state of n4 to confirm and subsequently =
the route state towards n2 to valid. Then expunge the next hop n2 which =
has not received an ack from.
> 9. n4 by receiving the =E2=80=9Crrep=E2=80=9D message from n1 =
multicasts it to its next hops towards n1 and n2,
> and similar to n1 it updates its routing table by validating n1 as its =
next hop to n2. At this point, a loop between n1 and n4 becomes valid.
>=20
>=20
>=20
> In response to these findings, we've changed 6.7.1.  Evaluating Route =
Information in -13, so that LoopFree() is *always* considered before =
adding a new route, even if all known routes to date are Unconfirmed.
>=20
> Following up, they=E2=80=99ve found another loop in -13:
>=20
> 
>=20
> At first nodes are connected to each other as shown in Fig1.a.
> n0 initiates a route discovery procedure for destination n3 by =
multicasting a =E2=80=9Crreq=E2=80=9D message to n2 with sq=3D2.
> n2 after updating its routing table, multicast the =E2=80=9Crreq=E2=80=9D=
 to its neighbors, n1 and n3.
> n1 upon receiving the =E2=80=9Crreq=E2=80=9D message sent by n2 =
updates its routing table and adds a route with hop-count=3D2, sq=3D2 =
and next-hope=3D2
> Consider that topology changes at this point and n1 moves into =
communication range of n0, gets connected to n0, and n2 leaves n0 =
communication range, gets disconnected from n0, which leads to network =
topology shown in Fig1.b.
> n0, which hasn=E2=80=99t received an =E2=80=9Crrep=E2=80=9D yet, =
resend the =E2=80=9Crreq=E2=80=9D message after increasing its sequence =
number to 3.
> n1 receives the new =E2=80=9Crreq=E2=80=9D message, with sq=3D3, =
next-hop=3D0 and hop-count=3D1, since it=E2=80=99s a better route it =
would be added to the routing table. Then n1 multicast the =E2=80=9Crreq=E2=
=80=9D message to its neighbors, n2 and n3.
> n2 evaluate the received message sent by n1 and adds a new route to =
its routing table with sq=3D3, next-hop=3D1 and hop-count=3D2 since the =
sequence number of the received message is greater than the stored one.
> At this point a loop has been formed between nodes n1 and n2.
>=20
>=20
> Since we=E2=80=99ve moved to disallowing multiple Unconfirmed routes =
(in -14, which isn=E2=80=99t published yet), this one is resolved =
already as well.
>=20
>=20
> The reason we didn=E2=80=99t discuss this earlier on [manet] was that =
the authors hadn=E2=80=99t submitted their paper yet (and I didn=E2=80=99t=
 want to leak their work). They=E2=80=99ve done so now, and will send us =
a link to their paper once it=E2=80=99s available. I=E2=80=99m guessing =
it=E2=80=99ll take a while to be published properly, but it should be =
enough for for our purposes for the paper to appear on arxiv.org =
 for now=E2=80=A6
>=20
> Best regards,
> Lotte
>=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 
>> BAE Systems Applied Intelligence Limited
>> Registered in England & Wales No: 01337451
>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>>=20
>> =20
>> From: Charlie Perkins [mailto:charles.perkins@earthlink.net =
]=20
>> Sent: 01 March 2016 01:08
>> To: Dearlove, Christopher (UK); manet
>> Subject: Re: [manet] AODVv2 responses to recent comments
>> =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
>> Hello Chris,
>>=20
>> On 1/19/2016 5:37 AM, Dearlove, Christopher (UK) wrote:
>> And outside those 31, that we=E2=80=99re at this position with a =
suggestion there=E2=80=99s possible looping (about which I have no idea) =
isn=E2=80=99t that comforting.
>>=20
>> I hope your concerns have been resolved on this matter.  The paper =
mentioned on the mailing list pointed out various ambiguities in RFC =
3561 described how the ambiguities might be construed to install =
self-routes and, combined with possible inconsistent choices for =
sequence number, loops could result.  But the email to the list several =
weeks ago indicated that these ambiguities do not exist in AODVv2.  The =
authors of that paper have expressed interest in doing a similar =
analysis on AODVv2.
>>=20
>> Other discussion about routing loops has not identified routing loop =
problems in the existing specification.  Use of unconfirmed or invalid =
routes for routing might lead to errors, but that doesn't carry over to =
produce loops in the route table.
>>=20
>> I'm looking for any other open issues outside of the Security =
Considerations which is being reworked according to recent comments but =
should be submitted soon.
>>=20
>> Regards,
>> Charlie P.
>>=20
>>=20
>>=20
>> =20
>> There=E2=80=99s also a lot of document to review. Which of course I =
haven=E2=80=99t done at this time. But my attention did alight on the =
IANA considerations section, and I noted there that:
>> - Not sure why the jump to 10 for message types, though I=E2=80=99m =
not opposed.
>> - The PATH_METRIC TLV can=E2=80=99t be type 10, that=E2=80=99s =
already taken. See IANA register.
>> - We previously pointed out that CONT_SEQ_NUM (COMPLETE) already =
exists and does the job that SEQ_NUM is doing, so why allocate another =
TLV? (You could avoid the necessity of repeating (COMPLETE) by simply =
commenting once and thereafter omitting.)
>> - Why the suggested skipping of types 12 to 14?
>> =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
>> From: manet [mailto:manet-bounces@ietf.org =
] On Behalf Of Victoria Mercieca
>> Sent: 18 January 2016 21:45
>> To: manet
>> Subject: [manet] AODVv2 responses to recent comments
>> =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 =
.
>> *** WARNING ***
>> EXTERNAL EMAIL -- This message originates from outside our =
organization.
>> =20
>> Hi all,
>> We have just released the newest AODVv2 draft. The major update is =
the separation of the AODVv2 route set from the RIB.
>>=20
>> Here are also responses to the comments received before Christmas. =
This should include all the points from Thomas Clausen regarding =
versions 11 and 12, and also a couple of other points which have been =
brought up since. Apologies for the huge email. For issues that need =
further discussion, I have tried to include the main points of the =
discussion so far. Please feel free to create a separate thread for any =
further discussion.
>>=20
>> We are still looking into the loop conditions recently reported for =
AODV, also still working on the text about security, and use of =
msg-hop-limit.
>> Kind regards,
>> Victoria.
>> =20
>>=20
>> 1. End-to-end / hop-by-hop acks - issue when a route is marked as =
confirmed and valid when the link to the next hop is confirmed as =
bidirectional (but the links downstream have not yet been verified as =
bidirectional).
>>=20
>> AODVv2: The authors believe this is an issue which would not occur =
frequently, and would right itself.=20
>>=20
>> This only occurs for the route to OrigAddr. What needs to happen for =
this to occur is that an intermediate node that takes part in the route =
discovery between OrigAddr and TargAddr coincidentally has packets to =
send to OrigAddr in the time between confirming the link to its own next =
hop toward OrigAddr is bidirectional, and the time taken for all other =
routers on the path to confirm their next hops too. If the route is used =
to forward packets before every other link in the path is confirmed as =
bidirectional, and the data packets are forwarded faster than the RREP =
and any RREP_Acks, then yes they could be delivered to a router without =
a valid route to OrigAddr. Alternatively if one of the links turns out =
to be unidirectional then the data packets will also arrive at a router =
without a valid route. In these cases, RERR messages will be generated =
toward the source of the traffic, the route to OrigAddr will be deleted =
at routers back toward TargAddr, but if data packets are still flowing =
from any source to OrigAddr, the route will be re-requested by the =
router responsible for discovering routes for the source of the data.
>>=20
>> The changes required to make acknowledgements end-to-end would =
require a lot more control traffic and be necessary for every route =
discovery and in almost all cases would be unnecessary.
>>=20
>> Text has been added to the draft in =E2=80=9CLocal Route State =
Changes=E2=80=9D to describe this.
>>=20
>> 2. Buffering
>> =EF=BB=BFThomas:
>> =E2=80=9CIt would seem that buffering, as specified, does not =
accomplish what=20
>> it states that it accomplishes: packets are (as you describe) still =
being
>> sent while no route is available, and therefore will be dropped =
later.
>> =3D> Consequently, it seems that buffering is a futile exercise?=E2=80=9D=

>>=20
>> AODVv2: =EF=BB=BFPackets are buffered before a route exists. A router =
only begins sending them when it deems the route to be valid. In =
general, buffering is not futile.
>>=20
>> True, there is this case outlined above where the router could deem =
the route valid before the bidirectionality check has happened for each =
and every hop. If the links chosen for the route are not all =
bidirectional, then yes, any data packets forwarded along this route =
will end up being dropped at some point on that path.=20
>> This case is caused by the RREP_Ack being hop-by-hop, and not caused =
by buffering.
>>=20
>> Thomas: =EF=BB=BF
>> =E2=80=9CBuffers have huge impacts on TCP performance, and I doubt if =
the issues on e.g. TCP are well enough understood by this WG =
(Bufferbloat was an example of where people got it wrong, despite having =
extensive experience).=E2=80=9D
>>=20
>> AODVv2: Packets will only be buffered while a route is requested. The =
TCP packets buffered will be packets for session initialisation. The =
authors believe that buffering these will have a positive effect. Some =
references have been suggested, listed here, the first of which has been =
included in the draft:
>> =
http://www.ieee802.org/21/archived_docs/2003-09_incoming/ccr-200109-koodli=
.pdf =

>> Mobile Internetworking with IPv6: Concepts, Principles and Practices =
{Koodli, Perkins}
>> disc.ece.illinois.edu/seminars_tutorials/tcp-wireless-tutorial.ppt =

>> Analysis of TCP performance over mobile ad hoc networks =
http://dl.acm.org/citation.cfm?id=3D313540 =

>> Alternatively, we could remove the mention of TCP, and instead state =
that buffering MAY be used for packets awaiting a route, but that =
implementation and implications of this are out of scope for AODVv2.
>>=20
>>=20
>> 3. Use of msg-hop-limit and msg-hop-count:
>> Thomas:
>> But, either way, as according to your model messages are never =
forwarded, but always are intended for receipt by a router which is a =
direct neighbor, then a  >1 (which applies to the =
message) seems inappropriate.=20
>> Actually, according to that model, I would even say that receipt of a =
message with a  >1 should be interpreted as a =
malfunction.
>> As you refer to RFC5444 appendix B, do note that Appendix B of =
RFC5444 (and, note the errata 4003) talks about:
>>        field, if present, contains the number of hops =
on which the message is allowed to travel before being discarded by a =
MANET router.  The  is set by the message originator and =
is used to prevent messages from endlessly circulating in a MANET.=20
>> Specifically =E2=80=9Cset by the message originator=E2=80=9D and =
=E2=80=9Cnumber of hops on which the message is allowed to travel=E2=80=9D=
 =E2=80=94 with your control messages traveling just one hop, I believe =
that setting  =3D 1 is correct.
>>=20
>> AODVv2: Discussion is still needed here. We wonder if these fields =
are necessary at all for AODVv2. We were using them to limit the number =
of regenerations of a RREQ. However, the hop limit value needs to be =
large enough to allow a RREQ from one side of the network to another. It =
might be the case that using the hop limit, almost every router in the =
network would receive that RREQ anyway, and by using the redundancy =
check, we already stop RREQs from circulating endlessly.
>>=20
>> 4. Abstract
>> Thomas:
>> =E2=80=9CI made the following comment, which still applies:
>> =E2=80=9CThis is a little over-stating the applicability: these =
statements may be true in some scenarios (for example, when there are =
few concurrent traffic flows, and therefore few routes to repair, and =
therefore few flooding operations to contend for channel access). As a =
general statement, this last sentence is incorrect=E2=80=9D=E2=80=9D
>>=20
>> AODVv2: The text has been removed and the abstract now states: =E2=80=9C=
 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.=E2=80=9D
>>=20
>> 5,9,12,13,20. Router Client
>> Thomas:=20
>> =E2=80=9CI made a comment previously that =E2=80=9CRouter client=E2=80=9D=
 is a poorly chosen term, and have proposed alternatives. I=E2=80=99ve =
seen some attempts on the list at rather than change the term, explain =
it =E2=80=94 some of which is in this document. The =E2=80=9COverview=E2=80=
=9D still talks about =E2=80=9Ca router=E2=80=A6one of its clients=E2=80=9D=
 - which is no less confusing than last time Iw went through it.
>> I reiterate, why not use =E2=80=9CLocal Attached Network Set=E2=80=9D, =
which is the term used by other documents from this WG?=E2=80=9D
>>=20
>> AODVv2: We already answered this suggestion on the MANET list and =
asked for comments and suggestions, and no responses were received. We =
have defined what we mean by Router Client, and the terminology has so =
far not changed. However, some alternatives have been suggested, so if =
you feel any of these are more effective, please let us know:
>> =EF=BB=BF=E2=80=A2    Advertised IP Address: puts the emphasis on =
advertisement rather than topological connection
>> =E2=80=A2    Accessible IP Address: puts the emphasis on =
accessibility through the particular router =E2=80=93 not bad
>> =E2=80=A2    Reduced Function Device [RFD]: doesn=E2=80=99t roll off =
the tongue, but this is terminology used for L2R in IEEE 802 Wireless =
for a similar situation
>> =E2=80=A2    Accessible Device Address: adds some emphasis for the =
device as well as the address
>> =EF=BB=BF=E2=80=A2    Stably Connected IP Address: nothing is =
permanent, of course, but the router client set is thought to be =
relatively stable
>> =E2=80=A2    Topologically Connected IP address: ... suggests that a =
"topological connection" is stable compared to wireless
>> =E2=80=A2    Administratively Assigned IP address: ... somehow does =
not connote the "otherness" of the router client devices.
>>=20
>> 6. Overview - adjacency
>> Thomas:=20
>> The term =E2=80=9Cconfirming adjacency=E2=80=9D is gone, and is now =
replaced by =E2=80=9Cconfirming bidirectionality=E2=80=9D - which, alas, =
still sounds like there is some active monitoring (HELLO message =
exchange) going on. Unless that is the case, then please be more =
specific here.
>> I note that the term adjacency is used through and through the =
document, btw.
>>=20
>> AODVv2: The text has been updated to avoid the word adjacency. We do =
not believe the text implies active monitoring through HELLO messages.
>>=20
>> 7. Overview - forwarding plane
>> Thomas: I suggested in my last review: The overview must also include =
a paragraph on the intersections between this protocol and the =
forwarding plane =E2=80=94 this, as it is different (and more invasive) =
from that which is typically seen in routing protocols.
>> Specifically, as a reactive protocol, it is required (at least) that =
the forwarding plane is modified :
>> 1) A =E2=80=9Cmiss=E2=80=9D when looking up a next hop for a data =
packet to be forwarded, is signalled to the AODVv2 process so as to =
permit that route discovery be launched;
>> 2) A =E2=80=9Cmiss=E2=80=9D when attempting to deliver a data packet =
to a next hop, which was recorded in the routing table, is signalled to =
the AODVv2 process so as to permit that a route repair be initiated =
and/or a Route Error be generated.
>> 3) A =E2=80=9Chit=E2=80=9D when looking up a next hop for a data =
packet to be forwarded to a destination is signalled to the AODVv2 =
process so as to permit maintenance of =E2=80=9Cactive route=E2=80=9D =
Route State, timers and such.
>> Note that these things are necessary to call out in the =
=E2=80=9Coverview=E2=80=9D and in the =E2=80=9Capplicability =
statement=E2=80=9D, both: it is not that they are negatives per se, but =
that they are important factors governing the applicability of this =
protocol: will a given platform permit such access to the forwarding =
plane, for example? Important to understand if for that platform this =
protocol is apple
>> I see that this was not addressed in the overview, nor in the =
applicability other than by a forward reference to section 6.4. While it =
is positive that there is a section 6.4, this does not exonerate the =
overview and the applicability statement for being honest about the =
requirements (notably to the platform/os) that this protocol has for =
being applicable
>>=20
>> AODVv2: The Overview and the Applicability Statement now refer to =
these basic requirements for the interaction with the forwarding plane. =
The Applicability Statement also contains the reference to the later =
section which describes this in more detail.
>>=20
>> 8. 7182 and security
>>=20
>> Thomas: I suggested in my last review: It is important to do more =
than this: 7182 does only provide =E2=80=9Ccontainers=E2=80=9D for ICVs =
and timestamps, and does not specify how to use them to obtain specific =
security properties. RFC7182 may be a tool that can be used, but how* =
that tool is used is what determines the security properties.
>> Therefore, saying that =E2=80=9Csecurity is dealt with by using =
RFC7182=E2=80=9D is either an incomplete statement, or is indicative of =
insufficient security considerations.=E2=80=9D
>> The actual sentence in the I-D has been changed, now it explicitly =
names the two TLVs from 7182 that it uses. That is, alas, still not =
sufficient.
>> Making the aside that was discussed recently on the list, that (i) =
control messages are not forwarded, and that (ii) they are modified in =
transit, the security/trust model is somewhat different from that of =
7181 and consequently for what 7182 was initially written for. I think =
that  calling out the trust model, and how 7182 actually is used here, =
might be what is called for.
>> Continuing with the aside, this *especially* as the applicability =
statement says: "Providing security for a reactive routing protocol can =
be difficult=E2=80=9D
>>=20
>> Thomas:
>> =EF=BB=BFOK, so assume that I understand regeneration as per my =
previous email, as meaning =E2=80=9Cgenerate a new message and send to =
my neighbors, based on what I learned when processing a received =
message=E2=80=9D =E2=80=94 just like any distance vector protocol does.
>> In that model, what you write makes sense: each originator of a =
control message (i.e., whoever generates or regenerates it) is free to =
include the information it desires, such as the 4 points you list above. =
No issues with that.
>> However, and this joins what I pointed out in a previous email, you =
write in the applicability statement: "Providing security for a reactive =
routing protocol can be difficult."
>> While we can discuss if the nature of =E2=80=9Creactive routing =
protocol=E2=80=9D generates particular difficulties, we certainly can =
agree that this protocol has the same =E2=80=9Cdifficulties=E2=80=9D as =
a distance vector protocol: routing topology information (by definition) =
not being exchanged end-to-end, but between neighbors (who do =
calculations and generate their own announcements =E2=80=94 =
regeneration, as you call it).=20
>> This means that a specific security model of transitive trust must be =
assumed, no? I trust Victoria, therefore when Victoria says =E2=80=9CStan =
told me=E2=80=9D then I trust that she actually verified that "it was =
indeed Stan who told her =E2=80=A6=E2=80=9D =E2=80=94 and either way, I =
have no way of verifying?
>> I did not see the trust model / trust assumption discussed in the =
specification (specifically not in applicability and in section 13, both =
of where it should be called out), but I think that this is actually a =
crucial point to get right, in order to approach developing the MTI =
security mechanisms.
>> Anyways, that observation actually contrasts strongly with what the =
applicability statement then goes on to say, namely:
>>    AODVv2 provides for message integrity and security against replay
>>    attacks by using integrity check values, timestamps and sequence
>>    numbers, as described in Section 13.
>> This is true only in as much as messages are indeed exchanged between =
neighbors: when you =E2=80=9Cregenerate=E2=80=9D a message, i.e., =
generate a new message in response to receipt of a message, you generate =
brand new payload (but possibly including some of the data from the =
received message, of course): thus, any ICVs =E2=80=9Cfrom farther away =
than the neighbor=E2=80=9D will be useless (or, if you zero out the =
parts that you change, these parts will not be protected).
>> The above sentence, quoted from the applicability statement, and that =
which transpires from section 13, seems - certainly, absent the trust =
model assumed - to suggest that end-to-end protection/validation is =
provided. But, this is not the case.
>> Finally to the applicability statement, a question:
>> If security associations can be established, encryption can be used =
for AODVv2 messages to ensure that only trusted routers participate in =
routing operations.
>> What you want to say here is that =E2=80=9Cif all trusted routers =
have a shared secret, then we=E2=80=99re able to use that shared secret =
to ignore non-trusted routers=E2=80=9D, right?=20
>> While =E2=80=9Csecurity associations=E2=80=9D that do not pass =
through a shared secret probably can be thought up, it=E2=80=99s not =
trivial and I did not find any discussion of that in the document?
>> Having, on the topic of security, re-read Section 13, which starts:
>>    This section describes various security considerations and =
potential
>>    avenues to secure AODVv2 routing. =20
>> While this is an honest description of what follows, I remain =
convinced that this is not sufficient. So let me ask as precisely as I =
can:
>> o what is the MTI security mechanism that a conformant implementation =
must provide? Specifically: - which are the processing steps (for =
example in section 7.2.1 and section 7.2.2 for RREP - and similarly for =
the other message types) that define that security mechanism
>> o what protection is offered by that MTI security mechanism? And what =
remains vulnerable.
>> If this specification targets std.track, then it should include =
(reasonably solid, but definitely well specified) MTI security.
>>=20
>> Chris Dearlove:
>> =EF=BB=BFThere are two potential choices:
>>=20
>> - RREQ has an integrity check value to indicate that someone trusted =
created it, if not necessarily the destination. That someone might be =
identifiable or not.
>> - RREQ has a signature that indicates that the destination created =
it.
>>=20
>> Unfortunately, an RREQ that changes as it is forwarded (aggregating =
data of any sort) makes the second option tricky, unless there=E2=80=99s =
some sort of aggregating signature as it is forwarded. But I=E2=80=99m =
not an expert on the latter.
>>=20
>> The most trivial case of the former is simply that everyone trusted =
has a single shared key. That has obvious issues =E2=80=93 although it =
was good enough that embodied as RFC 7183 we could get 7181 through the =
system (as a =E2=80=9Cmust implement, do not need to use=E2=80=9D =
minimal case). Alternatively something identity-based (e.g. =
draft-ietf-manet-ibs) could be used, so you know who created the message =
you received, but you are relying on a chain of trust, hop by hop. At =
which point you might as well just sign packets (see RFC 7182).
>>=20
>> But in even the weakest case (the single shared key used hop by hop) =
there has to be a failure for things to go wrong - either loss of key =
(in which case all bets are off) or suborning one router (who can do =
quite a lot of damage).
>>=20
>> I haven't read the latest AODVv2 draft yet, but this sort of thing =
should be described in its security considerations - the previous draft =
though didn't discuss this as far as I recall.
>>=20
>> Chris Dearlove:
>> =EF=BB=BFIf you go down this route of assuming transitive trust, then =
you might as well use 7182=E2=80=99s packet ICV and timestamp rather =
than message ICV and timestamp.
>> =20
>> There is a complication (mostly one of presentation) that the 5444 =
multiplexer (rather than AODVv2) needs to do this, at least for packets =
containing AODVv2 messages (but at which point, probably all 5444 =
packets). So you either, depending on your point of view, need to =
request it to do that, or (administratively) decline to operate except =
over a 5444 multiplexer that is doing this.
>> =20
>> The advantage is one of saved space and time when packets contain =
more than one message. Plus slightly better protection (hop count and =
limit are covered) but which probably doesn=E2=80=99t matter here.
>> =20
>> If messages are changed/replaced on a one-to-one basis as forwarded, =
then the only solutions I can see are hop by hop transitive trust =
(packets or messages per hop), or something complicated involving =
aggregation and knowledge of changes. But the latter would be a research =
task to develop, so let=E2=80=99s not try that.
>>=20
>> Jiazi Yi:
>> I=EF=BB=BF agree with Chris and Thomas on their concerns on the =
hop-by-hop security issue.=20
>> This is very different from classical DV protocol, in which the =
vector information is designed to be exchanged between neighbours.=20
>> In AODVv2, the RREQ/RREP/RERR are to be forwarded through multiple =
hops. A router can sign a message that isn't actually initialised by =
itself -- this is, at least, against intuition.=20
>> This can be an issue if we have compromised routers in the network. =
Of course, a compromised router is a problem for every protocol, like =
OLSRv2. But in OLSRv2, a compromised router can only speak on behalf of =
itself -- however, in AODVv2, a compromised/mis-configured router can =
pretend to be any other router (for example, generate RREQ messages =
using another address as OrigAddr).  The consequence will be much more =
serious if that happens.=20
>>=20
>> AODVv2: This is not yet addressed.
>>=20
>> 9. Terminology - host, routers, router clients:=20
>>=20
>> Thomas: My last review suggested:
>> =E2=80=9CThis has been brought up on the list several times in the =
past, without having been addressed.
>> There are =E2=80=9Chosts=E2=80=9D and there are =E2=80=9Crouters=E2=80=9D=
 =E2=80=94 whose roles are well defined. Node=E2=80=9D not so much =E2=80=94=
 which is clear from looking at the definition here: =E2=80=9Ceither =
AODVv2 routers or router clients=E2=80=9D (with =E2=80=9Crouter =
clients=E2=80=9D being defined as =E2=80=9Can AODVv2 router is also its =
own router client=E2=80=9D).
>>=20
>> This is very much related to the use of =E2=80=9CRouter Client=E2=80=9D=
, and both that term, and =E2=80=9Cnode=E2=80=9D indicative that some =
clarity is needed here.
>>=20
>> All a router cares about is =E2=80=9Can address=E2=80=9D. If that =
address is of a network, or a router, or an interface (and, if said =
interface is installed in a router or a host) doesn=E2=80=99t matter.
>>=20
>> So, =E2=80=9Can address=E2=80=9D is something that the routing =
protocol should care about finding paths to. Which means that each =
address that should be made reachable by the routing protocol should be =
advertised by (at least) one router in the network.
>>=20
>> One way of doing that would be to simply talk about =E2=80=9CAttached =
Networks=E2=80=9D as is done in RFC7181, wherein an address included in =
the =E2=80=9CAttached Network Set=E2=80=9D is advertised by an OLSRv2 =
router....in this case, the equivalent would be =E2=80=9Cfor each =
address in the Attached Network Set of an AODVv2 router the router MUST =
respond authoritatively to a RREQ, and MUST maintain the corresponding =
sequence number=E2=80=9D.
>> The text, as it currently is, is really hard to read, and a re-edit =
along these lines would go a long way.=E2=80=9D
>>=20
>> I note that the terms =E2=80=9CNode=E2=80=9D and =E2=80=9CRouter =
Client=E2=80=9D are still used, in their original form, and that other =
than some slight wordsmithing this comment has not been addressed in the =
document.
>>=20
>> I reiterate that the need to use router, host, node, and router =
client in and by itself should be an indicator that tightening up of =
terminology is required.
>>=20
>> AODVv2: See 5. The use of =E2=80=9Cnode=E2=80=9D has been addressed.
>>=20
>> 10. Terminology and elsewhere - address
>> Thomas: I made the following comment to Routable Unicast IP Address:
>> =E2=80=9CAre there any technical reason why not simply *any* address =
could be considered by the routing protocol?
>> My understanding, but correct me if I am wrong, is that all that is =
required is that all interfaces in a given AODVv2 routing domain has an =
unique address.
>> That some of these addresses (by an IP addressing architecture =
document) has special semantics associated (such as are link locals, or =
are for private use, or are for example use only, or are for multicast) =
is out of scope here?
>> I see nothing has changed on the above, so let me be more explicit: =
the routing protocol itself probably) should not care about what kind of =
addresses are filled into it. Is an 192.16./16 address appropriate? Not =
across the internet, but it may be in somebody=E2=80=99s private =
deployments. Should the routing protocol be =E2=80=9Caddress police=E2=80=9D=
 and is implementation of a =E2=80=9CI refuse to route these =
addresses=E2=80=A6=E2=80=9D a requirement for claiming conformance? =
Suggest simply stating what the requirements are under which the routing =
protocol will work =E2=80=94 and leave =E2=80=9Caddress assignment =
politics=E2=80=9D aside.
>>=20
>> AODVv2: We ask for clarification on this issue. We use the phrase =
=E2=80=9Croutable and unicast=E2=80=9D in the draft with respect to =
OrigAddr and TargAddr. We dont mean to exclude addresses from the =
private address ranges. But we dont want to request routes for =
multicast, indeterminate, link-local, or loopback addresses. This is not =
about router interface addresses which are used for AODVv2.
>>=20
>> 11. Multiple interfaces with the same IP address, 6621 implications
>>=20
>> Thomas: I also continued:
>> Now, with that being said also, the WG wanted that RFC7181 supports =
not just multiple interfaces, but also the same address used on multiple =
interfaces of the same router. There were good reasons for that, and =
while it was not trivial to implement, it turned out to be the right =
thing to support. If there are technical reasons why this is not =
supported in AODVv2 (for example, if this cannot be made work because of =
) then that should be called out in the applicability statement =
also?
>> Conversely, if it is possible in AODVv2, then I do not believe that =
it is clearly specified how (at least, in the =E2=80=9Cnaive=E2=80=9D on =
paper examples I drew up, something ended up not working). So either the =
protocol as-is does not support it (but could be made to?) or it is =
supported (but just need to be spelled out), or is not possible (and =
need to be disclaimed in the applicability statement).
>> Stan Ratliff was a driving force in holding the WG=E2=80=99s =
collective feet to the fire in getting this support included in RFC7181, =
and would likely be the right person to consult on this matter?
>> I actually have not seen changes, or comments, on this. In OLSRv2, =
the WG was making it a strong requirement that it should be possible to =
use the same IP address on different interfaces of a router. It was =
somewhat tedious to design around, but it was worked out, and the =
conditions under which that was possible were defined and documented.
>> I would like to see the same done for this protocol.
>> I also note that this is not unrelated to RFC6621-discussions. For =
example, when selecting S-MPRs on a multi-interface and =
multi-address-per-interface router, care must be taken least things =
won=E2=80=99t work. So, if (and this links back to previous mails) =
RFC6621 is a requirement or desire for this protocol, then there are =
some considerations required here.
>>=20
>> AODVv2: We have removed references to RFC 6621.
>> Initial thoughts on this topic of multiple interfaces using the same =
IP address, is that this wouldn=E2=80=99t cause a problem, if the router =
has only one sequence number. However, this is up for further =
discussion.
>>=20
>> 12. Interfaces configured as router clients
>>=20
>> Thomas: I see that the definition of =E2=80=9CRouter Client=E2=80=9D =
has changed to be
>> =E2=80=9CAn address or address range=E2=80=A6the AODVv2 router=E2=80=99=
s interface addresses are also configured as router clients=E2=80=9D
>> Better than before, but still missing the target. The term =E2=80=9CRou=
ter Client=E2=80=9D is, as I indicated numerous times before, odd.
>> But the second part of the sentence, does that mean (what it says) =
that the interfaces must be configured specially, so as to be able to be =
=E2=80=9Crouter clients=E2=80=9D? That can=E2=80=99t be true.
>> What you likely mean is:
>> An AODVv2 router is configured so as to consider its own interfaces =
as part of the locally attached network set=E2=80=9D ?
>> You configure the router, right? No special =E2=80=9Cinterface =
configuration properties=E2=80=9D are required for an interface to be =
announcable by  an AODVv2 router? (And, getting rid of node would =
actually make the definition shorter and nicer)
>>=20
>> AODVv2: The wording we use says: "The IP Addresses of the router's =
interfaces will appear in the Router Client Table." and in the =
Terminology: "The AODVv2 router's interface addresses are also =
configured as Router Clients." Both statements say that =E2=80=98interface=
 addresses are configured as router clients=E2=80=99 ...we are not sure =
why this is misunderstood. We have a router client list, and the AODVv2 =
router=E2=80=99s interface addresses are included in this list. The =
interface itself doesn=E2=80=99t have special =E2=80=9Cinterface =
configuration properties=E2=80=9D.
>>=20
>> 13 - more on router clients
>> Thomas: Now, snipping out from the applicability statement:
>> "Multi-homing of an IP address is not supported by AODVv2, and =
therefore a Router Client, i.e. an IP Address,  =E2=80=A6 "
>> =E2=80=A6evidence to there being some redundant terminology here to =
weed away.
>>=20
>> AODVv2: That was there as a reminder that a router client is based on =
IP address, even though the device with that IP address may have other =
IP addresses too. It=E2=80=99s the IP address that is the router client, =
not the device as a whole with its entire collection of configured IP =
addresses. One IP address of that device might be configured as a router =
client on one router, and a different IP address of that device could be =
configured as a router client on another router. The IP addresses would =
seem to AODVv2 to be on different devices.
>>=20
>>=20
>> 14. data elements
>>=20
>> Thomas: The below is a little bit of a meta-comment, I am not quite =
sure what I think here. The definitions for Target Node and such were =
confusing before. They still are, somewhat.
>> I think that it may be because the definitions now used are simply =
copy-pasted out from the tables in the previous version, for example:
>>    =E2=80=9CAn AODVv2 Data Element containing the destination address =
of the IP packet triggering route discovery.=E2=80=9D
>> OK, I can trace back and see that a Data Element is something that =
exists inside a protocol message. To me, however, that=E2=80=99s not =
really general terminology as such, but part of the specification of a =
packet format - or rather, it is the notation that you use when =
describing an algorithm. By the way, why are some notations in CamelCase =
whereas others have a space in them, e.g. =E2=80=9CTarget Node=E2=80=9D =
and =E2=80=9CTargMetric=E2=80=9D, both of which are Data Elements? Would =
be good with a consistent approach here.
>> I *think* that it would be better to take all those =E2=80=9CData =
Element=E2=80=9D bits and move to a separate section (or subsection) to =
the terminology, and then keep all the =E2=80=9Cother stuff=E2=80=9D =
(Neighbor, =E2=80=A6) in its own section.
>>=20
>> AODVv2: Your comment from draft 11 where we already had data elements =
in a separate table, says:
>> "Also suggest abolishing this table and folding the definitions in =
with the other definitions in the terminology section."
>> We have updated to not refer so heavily to the term Data Element. All =
the terms are described in the Terminology section. Those in CamelCase =
are used as message fields.
>>=20
>>=20
>> 15. Route =E2=80=9Cto a specific address=E2=80=9D
>> Thomas:
>> I made a comment: Second, should =E2=80=9Cvalid route=E2=80=9D not be =
qualified by =E2=80=9Cto a specific address=E2=80=9D?=E2=80=9D
>> Which was not addressed.
>>=20
>> AODVv2: Every route is to a specific address...the address is =
specified by Route.Address and Route.PrefixLength.
>> Do you mean that routes are to the address TargAddr or OrigAddr and =
therefore to a specific host address rather than to a network prefix? =
This is not the case. Prefix Length is included in AODVv2 messages so =
that the route learned from the message represents the prefix which =
OrigAddr or TargAddr resides on (if the router client entry =
corresponding to OrigAddr at RREQ_Gen or TargAddr at RREP_Gen is =
configured with a prefix length). e.g. OrigAddr is 10.0.0.1 but the =
corresponding router client entry at RREQ_Gen could be 10.0.0.0/8 =
. So when constructing the RREQ you include a prefix =
length of 8, and when receiving the RREQ and learning the route to =
OrigAddr, you can install a route to 10.0.0.0/8 .  =
Text has been updated to make this more obvious.
>>=20
>> 16. unreachable address
>>=20
>> Thomas: I also made a comment on "Unreachable Address=E2=80=9D - I am =
glad I did, because I apparently had a different understanding than what =
was intended. I now see that an Unreachable Address by definition is an =
address listed in a RERR message, and not the same as an address to =
which no route has yet  been discovered? If yes, then please use a =
different term, such as FormerlyReachableAddress=E2=80=9D or something =
of the sort?
>>=20
>> AODVv2: "Formerly reachable" is inaccurate... we send a RERR if =
another router forwards a packet via us, and we dont have a route, not =
just when we lose a route. We might never have had a route, or might =
never have had a valid route, so the address may not have been "formerly =
reachable". Also, I think "FormerlyReachableAddress" is a really ugly =
term. Unreachable means "we don=E2=80=99t have a route and we aren=E2=80=99=
t going to request one" or "we lost this route" (depending on why the =
RERR is being sent). It doesn=E2=80=99t mean "we didn=E2=80=99t request =
one yet", and it would be wrong to class an address as unreachable =
because we hadn=E2=80=99t requested a route for it yet, that is, =
assuming it=E2=80=99s configured as a router client.=20
>>=20
>> If a better term is suggested we could consider changing but at the =
moment we have kept =E2=80=9CUnreachable Address=E2=80=9D.
>>=20
>>=20
>> 17. Applicability - multiple interfaces same address, 6621 again
>>=20
>> Thomas: Applicability statement: First, I would like to recognize the =
efforts made to improve this since last review. Thanks
>> Second, the document states: "AODVv2 supports routers with multiple =
interfaces, as long as each interface configured for AODVv2 has a =
unicast IP address.  A router may use the same IP address on multiple =
interfaces.  Address assignment procedures are out of scope for =
AODVv2.=E2=80=9D
>> Is that true? Granted, I have not worked this through in detail, but =
I can present a counter-example: the use of RFC6621 means that there =
certainly are some constraints that must be respected least various =
flooding optimizations may not work.
>> Secondly, if the multiple-interfaces-with-same-address are on the =
same L2, and this is what I have not worked through, are there any =
situations that will not work?
>> The immediately previous version of this specification read:
>> "AODVv2 supports routers with multiple interfaces, as long as each =
interface configured for AODVv2 has its own unicast routable IP address"
>> So what changed that means that each interface no longer needs its =
*own* unicast address?
>>=20
>> AODVv2: Well, based on previous questions on this, we talked it =
through and decided there shouldn=E2=80=99t be an issue if different =
interfaces of a router used the same IP address. Note that we changed =
AODVv2 so that there is one sequence number per router. No longer can a =
router use different sequence numbers on different interfaces. If an =
RREQ went out of two interfaces using the same address, we worked it =
through and decided the request would be processed correctly.=20
>> Also, text referring to RFC 6621 has been removed.
>>=20
>> 18. Applicability and appendix - multihoming
>>=20
>> Thomas: I pointed out to the Applicability Statement:
>> I think that appendix B needs to be removed. Essentially, it makes =
claims that it is possible to do multi-homing =E2=80=94 but neither =
specifies how it is done, nor gives pointers to documents that justify =
the claim.
>> AODVv2 does not support multi-homing =E2=80=94 that=E2=80=99s clear, =
and it is fine that it is called out here. Thank you for that.
>> Now, with that being said, I am torn between being satisfied that it =
is called out on one hand, and wanting to have =E2=80=9Cmulti homing=E2=80=
=9D on the other hand. RFC7181 supports multi-homing, FWIW.
>> I believe that this also would merit some explicit discussion by the =
WG, in order to understand if this design decision is acceptable?
>> I see that Appendix B still is in the document, and I do not recall =
having seen this discussed on the mailing list. Simply removing the =
reference from the Applicability Statement to Appendix B does not =
address the issue that I raised in my previous review.
>>=20
>> AODVv2: Appendix has been removed and may appear in a future =
informational document.
>>=20
>> 19. interfaces list - use of =E2=80=9CSHOULD=E2=80=9D
>>=20
>> Thomas: To 4.1, I made the following comment:
>> "Is this a should, or a SHOULD? If the latter, should it be a MUST?
>> In general, there are a lot of such =E2=80=9Cmaybe normative =
language=E2=80=9D through the document, and I would much like to see an =
editorial pass =E2=80=94 essentially all may/should/ must and friends =
carefully evaluated as if they should become 2119-terms, and ... more =
importantly (it has been called out before, fwiw) quite a bit of =
should/SHOULD which ought to be transformed into MUST.
>> Generally, aiming for a very a low number of SHOULD is a good design =
metric for a document=E2=80=9D
>> Aside from the general comment on 2119-language, why is this a =
SHOULD?
>>=20
>> AODVv2: We changed this instance to a MUST and will be checking for =
=E2=80=9Cmaybe normative language=E2=80=9D.
>>=20
>>=20
>> 20. Router client - Local Attached Network Set
>>=20
>> Thomas: To 4.2, I made the following comment:
>> As indicated earlier, I believe that the term =E2=80=9CRouter =
Client=E2=80=9D is ill chosen. I believe that it is more appropriately =
an =E2=80=9CAttached Network Set=E2=80=9D since =E2=80=94 as indicated =
previously =E2=80=94 the term =E2=80=9CRouter Client=E2=80=9D is =
ambiguous. I am pleased to see, though, that this =E2=80=9CRouter Client =
List=E2=80=9D in reality is an =E2=80=9CAttached Network Set=E2=80=9D =
and so that change should be (relatively) easy.
>> The above comment still is applicable to this revision,
>>=20
>> AODVv2: See 5,9,12,13.
>>=20
>>=20
>> 21. Subnet
>> Thomas: To 4.2, I made the following comment:
>> Also, I recommend to not say =E2=80=9Csubnet=E2=80=9D =E2=80=94 how =
about rephrasing to =E2=80=9CIf a prefix is included in the attached =
network set of an AODVv2 router, then that AODVv2 router MUST provide =
connectivity for, i.e. answer to RREQs and maintain sequence numbers =
for, all addresses from within that prefix.=E2=80=9D
>> I note that while the term has been removed from section 4, =
there=E2=80=99re 4 lingering instances of this term in the document, =
that could easily be removed.
>>=20
>> AODVv2: All mentions of "subnet" were in the ENAR section. They have =
been updated to say network, or "networks attached to the routers"
>>=20
>>=20
>> 22. relocating router client
>>=20
>> Thomas: I Also made a comment about Appendix B in my previous review, =
which is referenced here. That comment still applies.
>>=20
>> AODVv2: Moved into main draft.
>>=20
>>=20
>> 23. Neighbor Monitoring
>>=20
>> Thomas: To Section 4.3, I noticed:
>> Does section 6.2 describe how to monitor an established adjacency =
only, or how to discover neighbouring AODVv2 routers? Looking in 6.2, I =
see
>> =E2=80=9CNot every pair of neighboring routers will necessarily form =
an adjacency,=E2=80=9D =E2=80=94 so it likely isn=E2=80=99t 6.2 that =
tells me how to maintain this table?
>> In short, =E2=80=9CA neighbour table MUST be maintained=E2=80=9D =E2=80=
=94 where can I find information on how to do this?
>> Section 6.2 states:
>> =E2=80=9CThe default approach for monitoring bidirectional =
connectivity to the next hop toward OrigAddr is to request =
acknowledgement of Route Reply messages.=E2=80=9D
>> That certainly will tell me if a link over which an RREP is sent is =
bi-directional, but will not maintain a =E2=80=9Cneighbor table=E2=80=9D.
>> So how is this done? Or, is the =E2=80=9CNeighbor Table=E2=80=9D not =
supposed to contain the complete set of neighbours? What information =
=E2=80=9C...MUST be maintained=E2=80=9D then, in this table?
>> This is very unclear, I would not know how to implement a mechanism =
that populates this =E2=80=9CNeighbor Table=E2=80=9D with the needed =
information here.
>> I see no (relevant) changes to 6.2 nor to 4.3 so I assume that this =
comment has not been addressed
>>=20
>> AODVv2: A new section was added to show how to update the neighbour =
table. There have also been updates to this entire section since version =
12.
>>=20
>> 24.     pseudo-code
>>=20
>> Thomas:
>> I am throwing this in here, as I am sure that I commented on that in =
the previous review, but I do not see that addressed: is Appendix C =
normative, or not? It represents =E2=80=9C a second specification of the =
protocol, in a different language=E2=80=9D from the main part of the =
specification. I have not walked through and made 200% sure that both =
are perfectly aligned and that there are no ambiguities, but having two =
different specifications of a protocol is a recipe for disaster.  Please =
either make 2000% sure that they are specifying the same thing without =
ambiguities, or remove one.
>>=20
>> AODVv2: Removed - maybe to include in an informational document in =
future.
>>=20
>>=20
>> 25. seqnum as 16 bit unsigned integer
>>=20
>> Thomas: To section 4.4, I wrote:
>> "would like to nit-pick that: the router can maintain this sequence =
number in whatever format it pleases =E2=80=94 but, when it includes it =
in control messages, it must be representable in a specified format, =
respecting certain rules.=E2=80=9D
>> I see that there were no changes following this comment.
>>=20
>> AODVv2: Why store it as anything other than what it needs to be when =
it goes into a message? However, we now state "MUST report its own =
sequence number as a 16 bit....whenever it creates a RREQ or RREP =
message".
>>=20
>>=20
>> 26. multiple seqnums?
>>=20
>> Thomas:
>> To section 4.4 I asked for clarification as to if sequence numbers =
were per interface or per router, as the specification was unclear on =
that. The words has changed, but it still is unclear: how many sequence =
numbers does a router maintain? One? One per interface?
>>=20
>> AODVv2: We tried to start discussion on that point, and in the =
meantime we reverted to having 1 seqnum per router. We think the text is =
clear... we refer to "the routers sequence number" or "its sequence =
number" - never hinting that there could be multiple seqnums per router =
(as far as I'm aware).
>>=20
>>=20
>> 27. sets/lists/tables
>>=20
>> Thomas:
>> In my previous review, I expressed that it would be preferential to =
use =E2=80=9Ca notation of Sets=E2=80=9D rather than tables. I see that =
this has not changed.
>>=20
>> AODVv2: You preferred sets rather than lists in your previous =
review...and explained our reasoning for this in responses to the MANET =
list, and we did not receive further comments.
>>=20
>>=20
>> 28. use of =E2=80=9Cnode=E2=80=9D
>>=20
>> Thomas:
>> I made a comment on node and address, let me pick this up again. The =
following:
>> RteMsg.OrigAddr
>> An IP address of the node which requires the route, i.e., the source =
address of the IP packet triggering the route request.
>> would be more compact and clear if getting rid of the term =E2=80=9Cnod=
e=E2=80=9D and said:
>> RteMsg.OrigAddr
>> The source address of the IP packet triggering the route request.
>>=20
>> AODVv2: Change made as suggested.
>>=20
>> 29. route table/rib/routing set
>>=20
>> Thomas: To section 4.6, and I (and others) have commented on this =
before:
>> All AODVv2 routers MUST maintain a route table.  The route table =
entry is a conceptual data structure.  Implementations MAY use any =
internal representation but MUST contain the following information:
>> In order to avoid confusion, rename this to =E2=80=9CRouting =
Information Base=E2=80=9D or =E2=80=9CRouting Set=E2=80=9D =E2=80=94 a =
Routing Table is an operating system construct, whereon operations =
directly influence packet forwarding. What you are defining here is a =
RIB/an RS.
>>=20
>> AODVv2: Done in version 13.
>>=20
>>=20
>> 30. rreq for prefix, use of =E2=80=9Cip address=E2=80=9D and =
=E2=80=9Caddress"
>>=20
>> Thomas:
>> The confusion that I pointed out in my previous review on =E2=80=9CIP =
address=E2=80=9D and =E2=80=9CAddress=E2=80=9D being used a bit =
haphazardly persists, fwiw. It makes me think, can a router send an RREQ =
for a prefix?
>>=20
>> AODVv2: See also #15. RREQ_Gen can include the prefix associated with =
OrigAddr by adding a prefix length to the message, the prefix length =
associated with the router client entry corresponding to OrigAddr. So =
all routers which receive it can learn a route to the prefix on which =
OrigAddr resides. But for TargAddr... the RREQ only has one target IP =
address - the destination IP address of the packet requiring the =
route... so what prefix length would it use? The RREQ requests a route =
to a single IP address. However, when the RREP is created, RREP_Gen =
should include the prefix length associated with the router client entry =
for TargAddr. So all routers which receive this RREP learn a route to =
the prefix TargAddr is part of (if the router client entry is configured =
with a prefix length). The text has been updated to make this more =
obvious.
>>=20
>>=20
>> 31. next hop ip address wording
>>=20
>> Thomas:
>> I also called this out in my previous review as incorrect, and =
despite wordsmithing it still is:
>>=20
>>         Route.NextHop
>>               The source IP address of the message advertising the =
route to
>>               Route.Address, i.e. an IP address of the AODVv2 router =
used for
>>               the next hop on the path toward Route.Address.
>>=20
>> If that =E2=80=9Cmessage=E2=80=9D is an RFC5444 entity, then it does =
to have a =E2=80=9Csource IP Address=E2=80=9D =E2=80=94 the =
encapsulating IP datagram containing the packet containing the message =
does. And the message MAY have an Originator Address
>>=20
>> AODVv2: Updated to say =E2=80=9Cthe source IP address of the IP =
packet containing the message advertising...=E2=80=9D
>>=20
>>=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
>>=20
>>=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 =

>=20


--Apple-Mail=_490F6F32-7BCB-465F-9F37-72E62219BC95
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi all,
for the sake of completeness, the =
paper we=E2=80=99ve mentioned is available on arXiv now:

http://arxiv.org/abs/1604.07179

And you can find the code of the tool =
that was used here: https://github.com/b-yousefi/wRebeca

Kind regards,
Lotte



=

--Apple-Mail=_490F6F32-7BCB-465F-9F37-72E62219BC95--


From nobody Sat Apr 30 07:42: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 9D67212B01F for ; Sat, 30 Apr 2016 07:42:33 -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 QPejTU3i2P0S for ; Sat, 30 Apr 2016 07:42:32 -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 1BAF212D0F3 for ; Sat, 30 Apr 2016 07:42:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F352224097D; Sat, 30 Apr 2016 07:42:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1462027351; bh=xwEuQTlYzzQ642gUV6na5SA5kSoDVBTbIvqxymcXQwc=; h=From:Subject:Date:Cc:To:From; b=FofzqbpX/LNoEee2exoAlQCkSOnFuYbYrHGxPfP3eRIb5e5uL0TgY7S2PzxLj/EVB btfSjvZLRiekuMv0YBg+7jt/b4POYIWc66n6otzHV2k1rX8hsq4f7nEbdrtqvWmB5n +v+nnOWuF5pj6DdYI9c9TbFb9IJqwEOs+mJQKB+k=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.147.111] (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 37195240719; Sat, 30 Apr 2016 07:42:31 -0700 (PDT)
From: ietf@thomasclausen.org
Content-Type: multipart/alternative; boundary="Apple-Mail=_A816931C-16DC-47E3-9BF2-C21B8E34C71A"
Date: Sat, 30 Apr 2016 16:42:29 +0200
Message-Id: 
To: Mobile Ad Hoc Networks mailing list 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [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: Sat, 30 Apr 2016 14:42:34 -0000

--Apple-Mail=_A816931C-16DC-47E3-9BF2-C21B8E34C71A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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


--Apple-Mail=_A816931C-16DC-47E3-9BF2-C21B8E34C71A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

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

=

--Apple-Mail=_A816931C-16DC-47E3-9BF2-C21B8E34C71A--


From nobody Sat Apr 30 10:35: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 1890212D189 for ; Sat, 30 Apr 2016 10:35:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.69
X-Spam-Level: 
X-Spam-Status: No, score=-2.69 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, T_FILL_THIS_FORM_SHORT=0.01] 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 QuCdcO48wqyV for ; Sat, 30 Apr 2016 10:35:46 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001: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 A64EE12D0BE for ; Sat, 30 Apr 2016 10:35:45 -0700 (PDT)
Received: by mail-ig0-x22a.google.com with SMTP id u10so51136519igr.1 for ; Sat, 30 Apr 2016 10:35:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim;  h=mime-version:date:message-id:subject:from:to; bh=ErRRARvc30uO3USBgzAGaSvF3xpZc42NqE1l7EVlBQs=; b=iX4uuGHSg7g3Jq7v0BmmXBCyB9yf3OayGY2FkmtLB2PJItaucjZSlglW80sRNhernn Zas6NnGJxCkpssJyO+9M6rVWpvjSgVT3yhLHOnHMv/7FEExDs5ht46/idoprgAUbGKzk huFhrfBFB7XpLiZzYh2ULrv0gaiZzpOVpCfg4=
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=ErRRARvc30uO3USBgzAGaSvF3xpZc42NqE1l7EVlBQs=; b=BNBRJUg23/GSSTdveyhIaKqmwcskOlSEhiOBnGXVK/fFIT3CTCZ2qm8jkQhRUbi8e6 eynx6XSuDyV2T15hbBUHNzkUoq8MjMZV8QB1Y16PhL0MxyiB3VPo8AuyaR79XpjSGqrG fkZaDxuxOdNV7WDxUfk/Z8QCwHitZds8EgEvnBt8m2O1pPQk66q6d6UKD2PKWN9/ygaE LirYEtl+81SVNr70yCP1MODIfPLeCRxts0mUh12REjn0dFd3X5b1yoPUnBJTjmudQH4n J7rPbchEVRi08qfGDfCuUOExxjw9UT4IdmMnGizIZ99jhSQmJwEnpbQ1QhAKVGtQu1dT +lOQ==
X-Gm-Message-State: AOPr4FWoiwFZDBLthoo8TRJqqJRIGivacijFbRTnRHGZpIr9EQwuG9h42PuwL1Ndkxb/I+x+XyurqOwT1bwUjQ==
MIME-Version: 1.0
X-Received: by 10.50.193.233 with SMTP id hr9mr11296762igc.40.1462037744580; Sat, 30 Apr 2016 10:35:44 -0700 (PDT)
Received: by 10.36.37.203 with HTTP; Sat, 30 Apr 2016 10:35:44 -0700 (PDT)
Date: Sat, 30 Apr 2016 10:35:44 -0700
Message-ID: 
From: Ulrich Herberg 
To: manet@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [manet] Review of draft-ietf-manet-aodvv2-15
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: Sat, 30 Apr 2016 17:35:56 -0000

Hi,

I have reviewed the latest version of AODVv2. Compared to previous
revisions of AODVv2/DYMO that I have reviewed in detail, the current
revision is an improvement. However, in my opinion there is still some
major work to be done before publication as RFC can be considered.
Below of this summary is a detailed review (each of my comments is
prefixed with UH>):

- Implementation: For an Experimental draft, the bar is certainly
lower in terms of requirements for implementations. However, I wonder
if the whole draft is tested on at least one implementation (even if
on a simulator) for correctness of message processing, generation, and
forwarding. In my experience creating of standards, I would have made
mistakes in these rules, hadn't I always verified the specification
with at least my own implementation.
For example, when I read section 7.1.2. RREQ Reception, it sounds
strange to me to update the neighbor set (in point 1) before checking
if the message is redundant (in point 6). I am not 100% sure if this
is really a mistake in the draft or if I am just misunderstanding
something, but knowing that the flow has been verified by at least one
implementation would give me more confidence.

- Security:
    - End-to-end integrity protection is not possible with the current
protocol design; it looks like the plan is to change this ([5]), but
it will likely mean a major redesign of the core protocol to go away
from message regeneration to actually forwarded messages.
    - Interoperability is not guaranteed by not specifying which
crypto/hash protocols should be used in the RFC7182 framework.
    - Key management is not addressed according to BCP107: There are
currently some early discussions on the MANET list about how to
provide keys to routers. [2]

- Metrics:
    - I prefer the approach that OLSRv2 is taking of a metric that
doesn't define the nature of the metric (as long as it's additive); I
agree with Henning's message in [3]
    - As outlined in my email [1], I don't agree with the assumption
in AODVv2 that most wireless links are symmetric. In my observations,
the opposite is the case. Vicky outlined some intended changes to
address this, but this will likely be a larger redesign of the
mechanism for calculating and using metrics.

- Same addresses on multiple interfaces: Question: has this (as
described in [4]) been addressed?

- Default router: no discovery of prefixes: If I understand correctly,
it's not possible to discover a prefix; but an AODVv2 router may
respond with an RREP that includes a prefix length. This would make it
inefficient to discover general "Internet" addresses (i.e., addresses
not inside the MANET); a router may have to trigger a new RREQ for
each new such requested address that is not present in the MANET
routing area.

- Experiment description: It seems to me that the text for the intent
of the experiment could have been the same 13 years ago, when AODV
(v1) was published. I had hoped that by now we would already have some
insights into the "behavior of the protocol in real-world
deployments", the "knowledge base of [...] reactive protocols [...]",
and "if sufficient demand exists [...] to prompt an effort to bring
the protocol to Standards Track".

- Ambiguities in RFC5444 format for messages: As described in my
detailed review, it's unclear to me whether or not some of the headers
should be added or not in the RFC5444 message. Also, some message
examples could be helpful in an appendix.

- No jitter: The WG has decided to specifiy jitter in RFC5148 and use
it in OLSRv2 because it is beneficial in flooding operations. But
AODVv2 doesn't specify the usage of jitter (there is only an orphaned
reference to RFC5148). What is the rationale for AODVv2 to not include
jitter?

- Missing constraints for parameters: OLSRv2 details constraints on
all the parameters (such as minimum and maximum values), in particular
for those that can be changed during runtime. I think it would be a
good idea to include the same for AODVv2.

- Unclear IANA section: The metrics table (table 6) is not included in
the IANA section, but in section 10. Also, there is no allocation
policy specified.

- Some TBDs and missing sections: There are some missing values (TBD)
in table 3, and table 4, but no request for IANA to assign these
values. Section 12.4.2 has as last sentence "Key management is not
specified for the following reasons:", but there is nothing following.


[1] https://www.ietf.org/mail-archive/web/manet/current/msg18873.html
[2] https://www.ietf.org/mail-archive/web/manet/current/msg18914.html
[3] https://www.ietf.org/mail-archive/web/manet/current/msg17390.html
[4] https://www.ietf.org/mail-archive/web/manet/current/msg18525.html
[5] https://www.ietf.org/mail-archive/web/manet/current/msg18948.html


See below for detailed comments:


Mobile Ad hoc Networks Working Group                          C. Perkins
Internet-Draft                                                 Futurewei
Intended status: Experimental                                 S. Ratliff
Expires: October 22, 2016                                        Idirect
                                                              J. Dowdell
                                                Airbus Defence and Space
                                                           L. Steenbrink
                                           HAW Hamburg, Dept. Informatik
                                                             V. Mercieca
                                                Airbus Defence and Space
                                                          April 20, 2016


      Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing
                       draft-ietf-manet-aodvv2-15

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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 22, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Perkins, et al.         Expires October 22, 2016                [Page 1]

Internet-Draft                   AODVv2                       April 2016


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Applicability Statement . . . . . . . . . . . . . . . . . . .   9
   4.  Data Structures . . . . . . . . . . . . . . . . . . . . . . .  10
     4.1.  InterfaceSet  . . . . . . . . . . . . . . . . . . . . . .  10
     4.2.  Router Client Set . . . . . . . . . . . . . . . . . . . .  11
     4.3.  Neighbor Set  . . . . . . . . . . . . . . . . . . . . . .  12
     4.4.  Sequence Numbers  . . . . . . . . . . . . . . . . . . . .  12
     4.5.  Local Route Set . . . . . . . . . . . . . . . . . . . . .  13
     4.6.  Multicast Route Message Set . . . . . . . . . . . . . . .  15
     4.7.  Route Error (RERR) Set  . . . . . . . . . . . . . . . . .  17
   5.  Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
   6.  AODVv2 Protocol Operations  . . . . . . . . . . . . . . . . .  19
     6.1.  Initialization  . . . . . . . . . . . . . . . . . . . . .  19
     6.2.  Next Hop Monitoring . . . . . . . . . . . . . . . . . . .  20
     6.3.  Neighbor Set Update . . . . . . . . . . . . . . . . . . .  21
     6.4.  Interaction with the Forwarding Plane . . . . . . . . . .  23
     6.5.  Message Transmission  . . . . . . . . . . . . . . . . . .  24
     6.6.  Route Discovery, Retries and Buffering  . . . . . . . . .  25
     6.7.  Processing Received Route Information . . . . . . . . . .  26
       6.7.1.  Evaluating Route Information  . . . . . . . . . . . .  27
       6.7.2.  Applying Route Updates  . . . . . . . . . . . . . . .  29
     6.8.  Suppressing Redundant Messages Using the Multicast Route
           Message Set . . . . . . . . . . . . . . . . . . . . . . .  31
     6.9.  Suppressing Redundant Route Error Messages using the
           Route Error Set . . . . . . . . . . . . . . . . . . . . .  33
     6.10. Local Route Set Maintenance . . . . . . . . . . . . . . .  34
       6.10.1.  LocalRoute State Changes . . . . . . . . . . . . . .  34
       6.10.2.  Reporting Invalid Routes . . . . . . . . . . . . . .  36
   7.  AODVv2 Protocol Messages  . . . . . . . . . . . . . . . . . .  36
     7.1.  Route Request (RREQ) Message  . . . . . . . . . . . . . .  37
       7.1.1.  RREQ Generation . . . . . . . . . . . . . . . . . . .  38
       7.1.2.  RREQ Reception  . . . . . . . . . . . . . . . . . . .  39
       7.1.3.  RREQ Regeneration . . . . . . . . . . . . . . . . . .  40
     7.2.  Route Reply (RREP) Message  . . . . . . . . . . . . . . .  41
       7.2.1.  RREP Generation . . . . . . . . . . . . . . . . . . .  42
       7.2.2.  RREP Reception  . . . . . . . . . . . . . . . . . . .  44
       7.2.3.  RREP Regeneration . . . . . . . . . . . . . . . . . .  45
     7.3.  Route Reply Acknowledgement (RREP_Ack) Message  . . . . .  46



Perkins, et al.         Expires October 22, 2016                [Page 2]

Internet-Draft                   AODVv2                       April 2016


       7.3.1.  RREP_Ack Generation . . . . . . . . . . . . . . . . .  46
       7.3.2.  RREP_Ack Reception  . . . . . . . . . . . . . . . . .  46
     7.4.  Route Error (RERR) Message  . . . . . . . . . . . . . . .  47
       7.4.1.  RERR Generation . . . . . . . . . . . . . . . . . . .  48
       7.4.2.  RERR Reception  . . . . . . . . . . . . . . . . . . .  49
       7.4.3.  RERR Regeneration . . . . . . . . . . . . . . . . . .  51
   8.  RFC 5444 Representation . . . . . . . . . . . . . . . . . . .  51
     8.1.  Route Request Message Representation  . . . . . . . . . .  53
       8.1.1.  Message Header  . . . . . . . . . . . . . . . . . . .  53
       8.1.2.  Message TLV Block . . . . . . . . . . . . . . . . . .  53
       8.1.3.  Address Block . . . . . . . . . . . . . . . . . . . .  53
       8.1.4.  Address Block TLV Block . . . . . . . . . . . . . . .  53
     8.2.  Route Reply Message Representation  . . . . . . . . . . .  54
       8.2.1.  Message Header  . . . . . . . . . . . . . . . . . . .  54
       8.2.2.  Message TLV Block . . . . . . . . . . . . . . . . . .  54
       8.2.3.  Address Block . . . . . . . . . . . . . . . . . . . .  55
       8.2.4.  Address Block TLV Block . . . . . . . . . . . . . . .  55
     8.3.  Route Reply Acknowledgement Message Representation  . . .  56
       8.3.1.  Message Header  . . . . . . . . . . . . . . . . . . .  56
       8.3.2.  Message TLV Block . . . . . . . . . . . . . . . . . .  56
       8.3.3.  Address Block . . . . . . . . . . . . . . . . . . . .  56
       8.3.4.  Address Block TLV Block . . . . . . . . . . . . . . .  57
     8.4.  Route Error Message Representation  . . . . . . . . . . .  57
       8.4.1.  Message Header  . . . . . . . . . . . . . . . . . . .  57
       8.4.2.  Message TLV Block . . . . . . . . . . . . . . . . . .  57
       8.4.3.  Address Block . . . . . . . . . . . . . . . . . . . .  57
       8.4.4.  Address Block TLV Block . . . . . . . . . . . . . . .  58
   9.  Simple External Network Attachment  . . . . . . . . . . . . .  58
   10. Configuration . . . . . . . . . . . . . . . . . . . . . . . .  59
     10.1.  Timers . . . . . . . . . . . . . . . . . . . . . . . . .  60
     10.2.  Protocol Constants . . . . . . . . . . . . . . . . . . .  62
     10.3.  Local Settings . . . . . . . . . . . . . . . . . . . . .  63
     10.4.  Network-Wide Settings  . . . . . . . . . . . . . . . . .  63
     10.5.  MetricType Allocation  . . . . . . . . . . . . . . . . .  63
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  64
     11.1.  RFC 5444 Message Types . . . . . . . . . . . . . . . . .  64
     11.2.  RFC 5444 Address Block TLV Types . . . . . . . . . . . .  64
     11.3.  ADDRESS_TYPE TLV Values  . . . . . . . . . . . . . . . .  65
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  65
     12.1.  Availability . . . . . . . . . . . . . . . . . . . . . .  66
       12.1.1.  Denial of Service  . . . . . . . . . . . . . . . . .  66
       12.1.2.  Malicious RERR messages  . . . . . . . . . . . . . .  67
       12.1.3.  False Confirmation of Link Bidirectionality  . . . .  68
       12.1.4.  Message Deletion . . . . . . . . . . . . . . . . . .  68
     12.2.  Confidentiality  . . . . . . . . . . . . . . . . . . . .  69
     12.3.  Integrity  . . . . . . . . . . . . . . . . . . . . . . .  69
       12.3.1.  Message Insertion  . . . . . . . . . . . . . . . . .  69
       12.3.2.  Message Modification - Man in the Middle . . . . . .  70



Perkins, et al.         Expires October 22, 2016                [Page 3]

Internet-Draft                   AODVv2                       April 2016


       12.3.3.  Replay Attacks . . . . . . . . . . . . . . . . . . .  70
     12.4.  Protection Mechanisms  . . . . . . . . . . . . . . . . .  71
       12.4.1.  Confidentiality and Authentication . . . . . . . . .  71
       12.4.2.  Integrity and Trust using ICVs . . . . . . . . . . .  71
       12.4.3.  Replay Protection using Timestamps . . . . . . . . .  71
       12.4.4.  Application to AODVv2  . . . . . . . . . . . . . . .  71
   13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  74
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  74
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  74
     14.2.  Informative References . . . . . . . . . . . . . . . . .  75
   Appendix A.  AODVv2 Draft Updates . . . . . . . . . . . . . . . .  77
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  77

1.  Overview

   The Ad hoc On-Demand Distance Vector Version 2 (AODVv2) protocol
   enables dynamic, self-starting, multihop routing between
   participating mobile nodes wishing to establish and maintain an ad
   hoc network.  The basic operations of the AODVv2 protocol are route
   discovery and route maintenance.  AODVv2 does not require nodes to
   maintain routes to destinations that are not in active communication.
   AODVv2 allows mobile nodes to respond to link breakages and changes
   in network topology in a timely manner.  The operation of AODVv2 is
   loop-free, and by avoiding the Bellman-Ford "counting to infinity"
   problem offers quick convergence when the ad hoc network topology
   changes (typically, when a node moves in the network).  When links
   break, AODVv2 causes the affected set of nodes to be notified so that
   they are able to invalidate the routes using the lost link.

   One distinguishing feature of AODVv2 is its use of a destination
   sequence number for each route entry.  The destination sequence
   number is created by the destination to be included along with any
   route information it sends to requesting nodes.  Using destination
   sequence numbers ensures loop freedom and is simple to program.
   Given the choice between two routes to a destination, a requesting
   node is required to select the one with the greatest sequence number.

   Compared to AODV [RFC3561], AODVv2 has moved some features out of the
   scope of the document, notably intermediate route replies, expanding
   ring search, and precursor lists.  However, the document has been
   designed to allow their specification in a separate document.  Hello
   messages and local repair have been removed.  AODVv2 provides a
   mechanism for the use of multiple metric types.  Message formats have
   been updated and made compliant with [RFC5444].  AODVv2 control
   messages are defined as sets of data, which are mapped to message
   elements using the Generalized MANET Packet/Message Format defined in
   [RFC5444] and sent using the parameters in [RFC5498].  Verification




Perkins, et al.         Expires October 22, 2016                [Page 4]

Internet-Draft                   AODVv2                       April 2016


   of link bidirectionality has been substantially improved, and
   additional refinements made for route timeouts and state management.

   AODVv2 is an Experimental protocol.  The purpose of the experiment
   with AODVv2 is to gain information on the behavior of the protocol in
   real-world deployments, furthering the knowledge base of both
   reactive protocols in general, and with AODVv2 in particular.
   Another goal of the experiment is to determine if sufficient demand
   exists for the AODVv2 protocol to prompt an effort to bring the
   protocol to Standards Track.

UH> In how far is that a different experiment from the one defined by
AODV(v1) (RFC3561) in 2003? What were the conclusions of the
experiment from AODVv1?


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

   An AODVv2 router is configured to perform route discovery on behalf
   of a configured set of IP addresses known as Router Clients.

UH> As I mentioned it before on the manet list, why inventing a new
terminology (Router Client), when the IETF has already good
terminology (Router, hosts), as well as terms such as Local Attached
Network Set from OLSRv2?

   Route
   discovery is performed when an AODVv2 router needs to forward an IP
   packet from one of its Router Clients, but does not have a valid
   route to the packet's destination.  AODVv2 routers use Route Request
   (RREQ) and Route Reply (RREP) messages to carry route information
   between the originator of the route discovery and the router
   responsible for the target, establishing a route to both endpoints on
   all intermediate routers.  A metric value is included to represent
   the cost of the route contained within the message.  AODVv2 uses
   sequence numbers to identify stale routing information, and compares
   route metric values to determine if advertised routes could form
   loops.

   Route maintenance includes confirming bidirectionality of links to
   next hop AODVv2 routers, issuing Route Error (RERR) messages,
   reacting to received Route Error messages, and extending and
   enforcing route timeouts.

   The on-demand nature of AODVv2 requires signals to be exchanged
   between AODVv2 and the forwarding plane.  These signals indicate
   when: a packet is to be forwarded, in order to initiate route
   discovery; packet forwarding fails, in order to initiate route error
   reporting; a packet is successfully forwarded, for route maintenance.

   Security for authentication of AODVv2 routers and encryption of
   control messages is accomplished using the TIMESTAMP and ICV TLVs
   defined in [RFC7182].

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in



Perkins, et al.         Expires October 22, 2016                [Page 5]

Internet-Draft                   AODVv2                       April 2016


   [RFC2119].  In addition, this document uses terminology from
   [RFC5444], and defines the following terms:

   AddressList
      A list of IP addresses as used in AODVv2 messages.
UH> What does that mean, "as used in AODVv2 messages"? Extensions can
add addresses and associate TLVs with them, and these added addresses
probably shouldn't be includeed in the AODVv2 processing. I assume
that you mean something along the line of "addresses that are
associated with a {certain} TLV"?

   AckReq
      Used in a Route Reply message to indicate the IP address of the
      router from which a Route Reply Acknowledgement is expected.

UH> "The IP address of the router"; a router can have multiple
interfaces, each of which can have multiple interfaces. It would be
better to clarify which IP address this is.

   AdvRte
      A route advertised in an incoming route message.

   AODVv2 Router
      An IP addressable device in the ad hoc network that performs the
      AODVv2 protocol operations specified in this document.

   CurrentTime
      The current time as maintained by the AODVv2 router.

   ENAR (External Network Access Router)
      An AODVv2 router with an interface to an external, non-AODVv2
      network.

   InterfaceSet
      The set of all network interfaces supporting AODVv2.

   Invalid route
      A route that cannot be used for forwarding but still contains
      useful sequence number information.

   LocalRoute
      An entry in the Local Route Set as defined in Section 4.5.

   MANET
      A Mobile Ad Hoc Network as defined in [RFC2501].

   MetricType
      The metric type for a metric value included in a message.

   MetricTypeList
      A list of metric types associated with the addresses in the
      AddressList of a Route Error message.

   Neighbor
      An AODVv2 router from which an RREQ or RREP message has been
      received.  Neighbors exchange routing information and verify




Perkins, et al.         Expires October 22, 2016                [Page 6]

Internet-Draft                   AODVv2                       April 2016


      bidirectionality of the link to a neighbor before installing a
      route via that neighbor into the Local Route Set.

   OrigAddr
      The source IP address of the IP packet triggering route discovery.

   OrigMetric
      The metric value associated with the route to OrigAddr (and any
      other addresses included in the given prefix length).

   OrigPrefixLen
      The prefix length, in bits, configured in the Router Client entry
      which includes OrigAddr.

   OrigSeqNum
      The sequence number of the AODVv2 router which originated the
      Route Request on behalf of OrigAddr.

   PktSource
      The source address of the IP packet which triggered a Route Error
      message.
UH> s/which/that/

   PrefixLengthList
      A list of routing prefix lengths associated with the addresses in
      the AddressList of a message.

   Reactive
      Performed only in reaction to specific events.  In AODVv2, routes
      are requested only when data packets need to be forwarded.  In
      this document, "reactive" is synonymous with "on-demand".

   RERR (Route Error)
      The AODVv2 message type used to indicate that an AODVv2 router
      does not have a valid LocalRoute toward one or more particular
      destinations.

   RERR_Gen (RERR Generating Router)
      The AODVv2 router generating a Route Error message.

   RerrMsg (RERR Message)
      A Route Error (RERR) message.

   Routable Unicast IP Address
      A routable unicast IP address is a unicast IP address that is
      scoped sufficiently to be forwarded by a router.  Globally-scoped
      unicast IP addresses and Unique Local Addresses (ULAs) [RFC4193]
      are examples of routable unicast IP addresses.




Perkins, et al.         Expires October 22, 2016                [Page 7]

Internet-Draft                   AODVv2                       April 2016


   Router Client
      An address or address range configured on an AODVv2 router, on
      behalf of which that router will initiate and respond to route
      discoveries.  These addresses may be used by the AODVv2 router
      itself or by non-routing devices that are reachable without
      traversing another AODVv2 router.

   RREP (Route Reply)
      The AODVv2 message type used to reply to a Route Request message.

   RREP_Gen (RREP Generating Router)
      The AODVv2 router that generates the Route Reply message, i.e.,
      the router configured with TargAddr as a Router Client.

   RREQ (Route Request)
      The AODVv2 message type used to discover a route to TargAddr and
      distribute information about a route to OrigAddr.

   RREQ_Gen (RREQ Generating Router)
      The AODVv2 router that generates the Route Request message, i.e.,
      the router configured with OrigAddr as a Router Client.

   RteMsg (Route Message)
      A Route Request (RREQ) or Route Reply (RREP) message.

   SeqNum
      The sequence number maintained by an AODVv2 router to indicate
      freshness of route information.

   SeqNumList
      A list of sequence numbers associated with the addresses in the
      AddressList of a message.

   TargAddr
      The target address of a route request, i.e., the destination
      address of the IP packet triggering route discovery.

   TargMetric
      The metric value associated with the route to TargAddr (and any
      other addresses included in the given prefix length).

   TargPrefixLen
      The prefix length, in bits, configured in the Router Client entry
      which includes TargAddr.

   TargSeqNum
      The sequence number of the AODVv2 router which originated the
      Route Reply on behalf of TargAddr.



Perkins, et al.         Expires October 22, 2016                [Page 8]

Internet-Draft                   AODVv2                       April 2016


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

   Upstream
      In the direction from destination to source (from TargAddr to
      OrigAddr).

   ValidityTime
      The length of time the route described by the message is offered.

   Valid route
      A route that can be used for forwarding, as described in
      Section 7.4.1.

   This document uses the notational conventions in Table 1 to simplify
   the text.

      +-----------------------+------------------------------------+
      | Notation              | Meaning                            |
      +-----------------------+------------------------------------+
      | Route[Address]        | A route toward Address             |
      | Route[Address].Field  | A field in a route toward Address  |
      | RteMsg.Field          | A field in either RREQ or RREP     |
      +-----------------------+------------------------------------+

                      Table 1: Notational Conventions

3.  Applicability Statement

   The AODVv2 routing protocol is a reactive routing protocol intended
   for use in mobile ad hoc wireless networks.  A reactive protocol only
   sends messages to discover a route when there is data to send on that
   route.  Therefore, a reactive routing protocol requires certain
   interactions with the forwarding plane (for example, to indicate when
   a packet is to be forwarded, in order to initiate route discovery).
   The set of signals exchanged between AODVv2 and the forwarding plane
   are discussed in Section 6.4.

   AODVv2 is designed for stub or disconnected mobile ad hoc networks,
   i.e., non-transit networks or those not connected to the internet.
   AODVv2 can, however, be configured to perform gateway functions when
   attached to external networks, as discussed in Section 9.

   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



Perkins, et al.         Expires October 22, 2016                [Page 9]

Internet-Draft                   AODVv2                       April 2016


   of other AODVv2 routers in the network.

UH> I would reword "sparse trafic". It's not really about the amount
of traffic: a router could send 10 TB of data to another destination.
As long as the percentage of destinations is small, AODVv2 could be
suitable.

   In this case fewer routes
   are needed, and therefore less control traffic is produced.  Data
   packets may be buffered until a route to their destination is
   available, as described in Section 6.6.

   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.

UH> Unless the encryption is explicitely specified, I would remove
this last sentence. And what are "security associations"?



   Since the route discovery process aims for a route to be established
   in both directions along the same path, uni-directional links are not
   suitable.  AODVv2 will detect and exclude those links from route
   discovery.  The route discovered is optimised for the requesting
   router, and the return path may not be the optimal route.

UH> s/optimised/optimized/

   AODVv2 is applicable to memory constrained devices, since only a
   little routing state is maintained in each AODVv2 router.

UH> s/since only a little/since only little/

UH> But that really depends on the number of destinations; if there
are many destinations, it could be a lot of state.

    AODVv2
   routes that are not needed for forwarding data do not need to be
   maintained.

   On routers unable to store persistent AODVv2 state,
   recovery can impose a performance penalty (e.g., in case of AODVv2
   router reboot), since if a router loses its sequence number, there is
   a delay before the router can resume full operations.  This is
   described in Section 6.1.

   AODVv2 supports routers with multiple interfaces and multiple IP
   addresses per interface.  A router may also use the same IP address
   on multiple interfaces.  AODVv2 requires only that each interface
   configured for AODVv2 has at least one unicast IP address.  Address
   assignment procedures are out of scope for AODVv2.

   AODVv2 supports Router Clients with multiple interfaces, as long as
   each interface is configured with its own unicast IP address.  Multi-
   homing of a Router Client IP address is not supported by AODVv2, and
   therefore an IP address SHOULD NOT be configured as a Router Client
   on more than one AODVv2 router at any one time.

UH> Is it appropriate to have RFC2119 language in the applicability statement?
UH> How can an IP address assure that it's not configured as a Router
Client on more than one AODVv2 router at any time?

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

UH> This may require some more explanations how this can work. A large
part of the document assumes layer 3 (see, for example, mentions of
MTU).

4.  Data Structures

4.1.  InterfaceSet

   The InterfaceSet is a conceptual data structure which contains
   information about all interfaces available to AODVv2.

UH> Can you define "available to AODVv2"? How can an interface on an
AODVv2 router not be available? Does it have to be configured to be
available? Or are there some conditions that automatically make an
interface not available to the routing protocol?

   Each element
   in the InterfaceSet MUST contain the following:



Perkins, et al.         Expires October 22, 2016               [Page 10]

Internet-Draft                   AODVv2                       April 2016


   Interface.Id
      An identifier that is unique in node-local scope and that allows
      the AODVv2 implementation to identify exactly one local network
      interface.

   If multiple interfaces of the AODVv2 router are configured for use by
   AODVv2, they MUST be configured in the InterfaceSet.

   Otherwise the InterfaceSet MAY be empty.

UH> Shouldn't at least one interface be configured as AODVv2
interface? How can this be empty?
UH> When adding or removing an interface during runtime, are there any
special actions that need to be performed (such as in OLSRv2)?

4.2.  Router Client Set

   An AODVv2 router provides route discovery services for its own local
   applications and for other non-routing devices that are reachable
   without traversing another AODVv2 router.

UH> By "other non-routing devices", do you mean "hosts"?

   The addresses used by
   these devices, and the AODVv2 router itself, are configured in the
   Router Client Set.

   An AODVv2 router will only originate Route Request
   and Route Reply messages on behalf of configured Router Client
   addresses.

   Router Client Set entries MUST contain:

   RouterClient.IPAddress
      An IP address or the start of an address range that requires route
      discovery services from the AODVv2 router.

   RouterClient.PrefixLength
      The length, in bits, of the routing prefix associated with the
      RouterClient.IPAddress.  If a prefix length is included, the
      AODVv2 router MUST provide connectivity for all addresses within
      that prefix.

UH> I suggest rewording "provide connectivity"? My router at home
"provides connectivity" to Google, but it is several IP  hops away.

   RouterClient.Cost
      The cost associated with reaching this address or address range.

   A Router Client address MUST NOT be served by more than one AODVv2
   router at any one time.  To shift responsibility for a Router Client
   to a different AODVv2 router, correct AODVv2 routing behavior MUST be
   observed;

   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.

UH> s/which/that/
UH> It could be helpful to add a forward reference to the section that
describes how to purge existing routing information about this Router
Client. I searched for the word "purge" in the rest of the document,
but I couldn't find it.








Perkins, et al.         Expires October 22, 2016               [Page 11]

Internet-Draft                   AODVv2                       April 2016


4.3.  Neighbor Set

   A Neighbor Set MUST be maintained with information about neighboring
   AODVv2 routers.  Neighbor Set entries are stored when AODVv2 messages
   are received.  If the Neighbor is chosen as a next hop on an
   installed route, the link to the Neighbor MUST be tested for
   bidirectionality and the result stored in this set.  A route will
   only be considered valid when the link is confirmed to be
   bidirectional.

   Neighbor Set entries MUST contain:

   Neighbor.IPAddress
      An IP address of the neighboring router, learned from the source
      IP address of a received route message.

UH> Is this the source IP address from RFC5444 msg-orig-addr? Or is
this from the IP packet?


   Neighbor.State
      Indicates whether the link to the neighbor is bidirectional.
      There are three possible states: Confirmed, Unknown, and
      Blacklisted.

UH> If a router has several interfaces and several links to a neighbor
(e.g., one link via ethernet, one via Wifi), how is this reflected in
this set? Would I have two entries, one, say, confirmed, one unknown?

      Unknown is the initial state.  Confirmed indicates
      that the link to the neighbor has been confirmed as bidirectional.

      Blacklisted indicates that the link to the neighbor is uni-
      directional.  Section 6.2 discusses how to monitor link
      bidirectionality.

   Neighbor.ResetTime
      When the value of Neighbor.State is Blacklisted, this indicates
      the time at which the value of Neighbor.State will revert to
      Unknown.  By default this value is calculated at the time the
      router is blacklisted and is equal to CurrentTime +
      MAX_BLACKLIST_TIME.  When the value of Neighbor.State is not
      Blacklisted, this time is set to INFINITY_TIME.

   Neighbor.Interface
      The interface on which the link to the neighbor was established.

4.4.  Sequence Numbers

   Sequence numbers enable AODVv2 routers to determine the temporal
   order of route discovery messages, identifying stale routing
   information so that it can be discarded.  The sequence number
   fulfills the same roles as the "Destination Sequence Number" of DSDV
   [Perkins94], and the AODV Sequence Number in [RFC3561].

   Each AODVv2 router in the network MUST maintain its own sequence
   number.  All RREQ and RREP messages created by an AODVv2 router
   include the router's sequence number, reported as a 16-bit unsigned
   integer.  Each AODVv2 router MUST ensure that its sequence number is



Perkins, et al.         Expires October 22, 2016               [Page 12]

Internet-Draft                   AODVv2                       April 2016


   strictly increasing, and that it is incremented by one (1) whenever
   an RREQ or RREP is created, except when the sequence number is 65,535
   (the maximum value of a 16-bit unsigned integer), in which case it
   MUST be reset to one (1).  The value zero (0) is reserved to indicate
   that the sequence number is unknown.

UH> Some explanation in which situations the sequence number is
unknown would be helpful.

   An AODVv2 router MUST only attach its own sequence number to
   information about a route to one of its configured Router Clients,
   all route messages regenerated by other routers retain the
   originator's sequence number.  Tod determine staleness, the

UH> s/Tod/To/

   previously stored sequence number associated with the originator, is

UH> remove the comma before "is"

   subtracted from the incoming sequence number.  The result of the
   subtraction is to be interpreted as a signed 16-bit integer, and if
   less than zero, the information in the new AODVv2 message is stale
   and MUST be discarded.

UH> Which previously stored sequence number? (that wasn't described before).
UH> What about wrap-around of the sequence number? Say, the previous
sequence number was 65,535. The new sequence number is 1. If I
subtract the previous number from the new number, it would be
negative, and thus considered as stale.


   This, along with the processes in Section 6.7.1, ensures loop
   freedom.


UH> How so? Some explanation would be helpful.

   An AODVv2 router SHOULD maintain its sequence number in persistent
   storage.  If the sequence number is lost, the router MUST follow the
   procedure in Section 6.1 to safely resume routing operations with a
   new sequence number.

4.5.  Local Route Set

   All AODVv2 routers MUST maintain a Local Route Set, containing
   information about routes learned from AODVv2 route messages.  The
   Local Route Set is stored separately from the forwarding plane's
   routing table (referred to as Routing Information Base (RIB)), which
   may be updated by other routing protocols operating on the AODVv2
   router as well.  The Routing Information Base  is updated using
   information from the Local Route Set. Alternatively, implementations
   MAY choose to modify the Routing Information Base directly.

UH> Could be helpful to add some clarifications: In which cases would
that make sense to modify the RIB directly? What are the implications
of doing so?

   Routes learned from AODVv2 route messages are referred to in this
   document as LocalRoutes, and MUST contain the following information:

   LocalRoute.Address
      An address, which, when combined with LocalRoute.PrefixLength,
      describes the set of destination addresses this route includes.

   LocalRoute.PrefixLength
      The prefix length, in bits, associated with LocalRoute.Address.

   LocalRoute.SeqNum
      The sequence number associated with LocalRoute.Address, obtained
      from the last route message that successfully updated this entry.



Perkins, et al.         Expires October 22, 2016               [Page 13]

Internet-Draft                   AODVv2                       April 2016


   LocalRoute.NextHop
      The source IP address of the IP packet containing the AODVv2
      message advertising the route to LocalRoute.Address, i.e. an IP
      address of the AODVv2 router used for the next hop on the path
      toward LocalRoute.Address.

UH> s/,i.e an/,i.e., an/

   LocalRoute.NextHopInterface
      The interface used to send IP packets toward LocalRoute.Address.

   LocalRoute.LastUsed
      If this route is installed in the Routing Information Base, the
      time it was last used to forward an IP packet.

UH> What is the value if the route hasn't been installed in the RIB?
(null?). Is this information always available on all operating
systems?

   LocalRoute.LastSeqNumUpdate
      The time LocalRoute.SeqNum was last updated.

   LocalRoute.ExpirationTime
      The time at which this LocalRoute MUST be marked as Invalid.

UH> s/this LocalRoute MUST marked as Invalid/LocalRoute.State for this
LocalRoute MUST be set to Invalid/

      An
      AODVv2 router MAY be offered a route for a limited time.  In this
      case, the route is referred to as a timed route.  If a route is
      not timed, LocalRoute.ExpirationTime is INFINITY_TIME.

UH> A forward reference to the section where this is specified would
be helpful.

   LocalRoute.MetricType
      The type of metric associated with this route.

   LocalRoute.Metric
      The cost of the route toward LocalRoute.Address expressed in units
      consistent with LocalRoute.MetricType.

   LocalRoute.State
      The last known state (Unconfirmed, Idle, Active, or Invalid) of
      the route.

   There are four possible states for a LocalRoute:

   Unconfirmed
      A route learned from a Route Request message, which has not yet
      been confirmed as bidirectional.  It MUST NOT be used for
      forwarding IP packets, and therefore it is not referred to as a
      valid route.  This state only applies to routes learned through
      RREQ messages.

UH> What are other ways of learning of a route?

   Idle
      A route which has been learned from a route message, and has also
UH> s/which/that/
      been confirmed, but has not been used in the last ACTIVE_INTERVAL.
      It is able to be used for forwarding IP packets, and therefore it
      is referred to as a valid route.




Perkins, et al.         Expires October 22, 2016               [Page 14]

Internet-Draft                   AODVv2                       April 2016


   Active
      A route which has been learned from a route message, and has also
UH> s/which/that/
      been confirmed, and has been used in the last ACTIVE_INTERVAL.  It
      is able to be used for forwarding IP packets, and therefore it is
      referred to as a valid route.

   Invalid
      A route which has expired or been lost.  It MUST NOT be used for
UH> s/which/that/
      forwarding IP packets, and therefore it is not referred to as a
      valid route.  Invalid routes contain sequence number information
      which allows incoming information to be assessed for freshness.


   When the Local Route Set is stored separately from the Routing
   Information Base, routes are added to the Routing Information Base
UH>s/When/If/
UH>IMO, this should be more detailed: What does it mean if it is "not
stored separately"? What are the implications?

   when LocalRoute.State is valid (set to Active or Idle), and removed
   from the Routing Information Base when LocalRoute.State becomes
   Invalid.  Changes to LocalRoute state are detailed in Section 6.10.1.

   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.

UH> How does this work in case the Local Route Set is "not stored
separately" from the RIB?

4.6.  Multicast Route Message Set

   A route message (RteMsg) is either a Route Request or Route Reply
   message.  RREQ messages are multicast by default and regenerated

UH> I have outlined on the manet list why I think "regeneration" is a
bad idea (in particular in regards to end-to-end security):
https://www.ietf.org/mail-archive/web/manet/current/msg18431.html
https://www.ietf.org/mail-archive/web/manet/current/msg18081.html

   multiple times, and RREP messages will be multicast when the link to
   the next router is not known to be bidirectional.
UH> Is there any experience with AODVv2 of the implications (in terms
of overhead, packet loss, and delivery ratio) that justifies the use
of multicast RREP messages?


   Multiple similar
   route messages might be received by any one router during one route
   discovery attempt.  The AODVv2 router does not need to regenerate or
   respond to every one of these messages.

UH> Can this be clarified? "not [...] to every one of these messages"?
I would have thought more something like "The AODVv2 router MUST NOT
regenerate route messages with the same sequence number that it has
previously received" (probably would need some more word-smithing to
handle wrap-around)

   The Multicast Route Message Set is a conceptual set which contains
UH> s/which/, which/
   information about previously received multicast route messages, so
   that incoming route messages can be compared with previously received
   messages to determine if the incoming information is redundant or
   stale, and the router can avoid sending redundant control traffic.

   Multicast Route Message Set entries MUST contain the following
   information:

   RteMsg.MessageType
      Either RREQ or RREP.




Perkins, et al.         Expires October 22, 2016               [Page 15]

Internet-Draft                   AODVv2                       April 2016


   RteMsg.OrigAddr
      The source address of the IP packet triggering the route request.

   RteMsg.OrigPrefixLen
      The prefix length associated with RteMsg.OrigAddr, originally from
      the Router Client entry on RREQ_Gen which includes
UH> s/which/that/
      RteMsg.OrigAddr.
UH> maybe: s/Router Client entry/Router Client Set entry/
UH> I am not sure I understand where the prefix length is acquired.
Say this is the first RREQ received on this router; how does it know
the prefix length? Am I correct that this has to be manually
configured in the Router Client Set, but that this can be empty as
well? (since in the Router Client Set section the draft states: "If a
prefix length is included [...]".). In that case the above sentence
"Multicast Route Message Set entries MUST contain the following
information:" is misleading, since it implies that none of these
fields in the entry can be empty.

   RteMsg.TargAddr
      The destination address of the IP packet triggering the route
      request.

   RteMsg.TargPrefixLen
      The prefix length associated with RteMsg.TargAddr, originally from
      the Router Client entry on RREP_Gen which includes
UH>s/which/that/
      RteMsg.TargAddr.  If RteMsg is a RREQ, RteMsg.TargPrefixLen MUST
      equal address length.
UH> I assume this means that RREQs can only be issued for host
addresses (/32 or /128), not for prefixes. That would be  inefficient
for default gateway discovery, if a RREQ has to be issued for every
single address that is available through the gateway outside of the
MANET.

   RteMsg.OrigSeqNum
      The sequence number associated with the route to OrigAddr, if
      RteMsg is an RREQ.

   RteMsg.TargSeqNum
      The sequence number associated with the route to TargAddr, if
      RteMsg is an RREP.

   RteMsg.MetricType
      The metric type of the route requested.

   RteMsg.Metric
      The metric value received in the RteMsg.

   RteMsg.Timestamp
      The last time this Multicast Route Message Set entry was updated.

   RteMsg.RemoveTime
      The time at which this entry MUST be removed from the Multicast
      Route Message Set. This is set to CurrentTime +
      MAX_SEQNUM_LIFETIME, whenever the sequence number of this entry
      (RteMsg.OrigSeqNum for an RREQ, or RteMsg.TargSeqNum for an RREP)
      is updated.

   RteMsg.AckReqAddr
      The address from which a RREP_Ack is expected, if RteMsg is a RREP
      that contains an AckReq.
UH> Which address is that? Source IP address or OrigAddr?

   RteMsg.Interface
      The interface on which the message was received.



Perkins, et al.         Expires October 22, 2016               [Page 16]

Internet-Draft                   AODVv2                       April 2016


   The Multicast Route Message Set is maintained so that no two entries
   have the same MessageType, OrigAddr, TargAddr, and MetricType.  See
   Section 6.8 for details about updating this set.

4.7.  Route Error (RERR) Set

   Each sent RERR message SHOULD be recorded in a conceptual set called
   the Route Error (RERR) Set.
UH> Why not MUST?  In which cases wouldn't you do this and what are
the implications?


   Each entry contains the following
   information:

   RerrMsg.Timeout
      The time after which the entry SHOULD be deleted.
UH> Why not MUST? What happens if it isn't deleted?

   RerrMsg.AddressList
      The AddressList of the RERR to be recorded.

   RerrMsg.PktSource:
      The PktSource of the RERR to be recorded, if any.

   See section Section 6.9 for instructions on how to update the set.

5.  Metrics

   Metrics measure a cost or quality associated with a route or a link,
   e.g., latency, delay, financial cost, energy, etc.  Metric values are
   reported in Route Request and Route Reply messages.

   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.
UH> Isn't that the same router, OrigAddr and "the router sending the
Route Request"? Do you mean "to the router receiving the Route
Request"?


    For RREQ_Gen, this is the cost associated with
   the Router Client entry which includes OrigAddr.
UH> s/which/that/
UH> Doesn't every entry in that set include an OrigAddr?

    For routers which
UH> s/which/that/
   regenerate the RREQ, this is the cost from OrigAddr to the
   regenerating router, combining the metric value from the received
   RREQ message with knowledge of the link cost from the sender to the
   receiver, i.e., the incoming link cost.  This updated route cost is
   included when regenerating the Route Request message, and used to
   install a route back toward OrigAddr.

   Similarly, in Route Reply messages, the metric reflects the cost of
   the route from TargAddr (and any other addresses included in the
   prefix length of RREP_Gen's Router Client entry for TargAddr) to the
   router sending the Route Reply.
UH> Similar to a previous comment, it's unclear what you mean by "the
router sending the Route Reply" (in particular because the draft
includes the concept of regeneration, so technically at every hop a
router is sending the RREP).

     For RREP_Gen, this is the cost
   associated with the Router Client entry which includes TargAddr.  For
   routers which regenerate the RREP, this is the cost from TargAddr to
   the regenerating router, combining the metric value from the received
   RREP message with knowledge of the link cost from the sender to the
   receiver, i.e., the incoming link cost.  This updated route cost is



Perkins, et al.         Expires October 22, 2016               [Page 17]

Internet-Draft                   AODVv2                       April 2016


   included when regenerating the Route Reply message, and used to
   install a route back toward TargAddr.

   Assuming link metrics are symmetric, the cost of the routes installed
   in the Local Route Set at each router will be correct.
UH> I would go further and say that in wireless networks (which is
what this protocol is applicable for), links are almost never
symmetric.

     While this
   assumption is not always correct, calculating incoming/outgoing
   metric data is outside of scope of this document.
UH> Why? As you admit, this assumption is not always (I would say
"almost never") correct. Moving that out of scope of the document is
thus very surprising to me.

   The route
   discovered is optimised for the requesting router, and the return
   path may not be the optimal route.
UH> s/optimised/optimized/ (either consistently British or American English)

   AODVv2 enables the use of multiple metric types.  Each route
   discovery attempt indicates the metric type which is requested for
UH> s/which/that/
   the route.  Only one metric type MUST be used in each route discovery
   attempt.

   For each MetricType, AODVv2 requires:

   o  A MetricType number, to indicate the metric type of a route.
      MetricType numbers allocated are detailed in Section 10.5.

   o  A maximum value, denoted MAX_METRIC[MetricType].  This MUST always
      be the maximum expressible metric value of type MetricType.  Field
      lengths associated with metric values are found in Section 10.5.
      If the cost of a route exceeds MAX_METRIC[MetricType], the route
      is ignored.
UH> Is a RREQ or RREP that already exceeds MAX_METRIC treated
differently? (e.g., not forwarded, or metric update done
differently?). How do you handle wrap around when MAX_METRIC is
incremented, i.e., to assure that MAX_METRIC + 1 isn't 0 or something
like that?

   o  A function for incoming link cost, denoted Cost(L).  Using
      incoming link costs means that the route learned has a path
      optimized for the direction from OrigAddr to TargAddr.

   o  A function for route cost, denoted Cost(R).

   o  A function to analyze routes for potential loops based on metric
      information, denoted LoopFree(R1, R2).  LoopFree verifies that a
      route R2 is not a sub-section of another route R1.  An AODVv2
      router invokes LoopFree() as part of the process in Section 6.7.1,
      when an advertised route (R1) and an existing LocalRoute (R2) have
      the same destination address, metric type, and sequence number.
      LoopFree returns FALSE to indicate that an advertised route is not
      to be used to update a stored LocalRoute, as it may cause a
      routing loop.  In the case where the existing LocalRoute is
      Invalid, it is possible that the advertised route includes the
      existing LocalRoute and came from a router which did not yet
      receive notification of the route becoming Invalid, so the
      advertised route should not be used to update the Local Route Set,
      in case it forms a loop to a broken route.





Perkins, et al.         Expires October 22, 2016               [Page 18]

Internet-Draft                   AODVv2                       April 2016


   AODVv2 currently supports cost metrics where Cost(R) is strictly
   increasing, by defining:

   o  Cost(R) := Sum of Cost(L) of each link in the route

   o  LoopFree(R1, R2) := ( Cost(R1) <= Cost(R2) )

   Implementers MAY consider other metric types, but the definitions of
   Cost and LoopFree functions for such types are undefined, and
   interoperability issues need to be considered.

6.  AODVv2 Protocol Operations

   The AODVv2 protocol's operations include managing sequence numbers,
   monitoring next hop AODVv2 routers on discovered routes and updating
   the Neighbor Set, performing route discovery and dealing with
   requests from other routers, processing incoming route information
   and updating the Local Route Set, updating the Multicast Route
   Message Set and suppressing redundant messages, and reporting broken
   routes.  These processes are discussed in detail in the following
   sections.

6.1.  Initialization

   During initialization where an AODVv2 router does not have
   information about its previous sequence number, or if its sequence
   number is lost at any point, the router resets its sequence number to
   one (1).  However, other AODVv2 routers may still hold sequence
   number information that this router previously issued.  Since
   sequence number information is removed if there has been no update to
   the sequence number in MAX_SEQNUM_LIFETIME, the initializing router
   MUST wait for MAX_SEQNUM_LIFETIME before it creates any messages
   containing its new sequence number.  It can then be sure that the
   information it sends will not be considered stale.

   During this wait period, the router is permitted to do the following:

   o  Process information in a received RREQ or RREP message to learn a
      route to the originator or target of that route discovery

   o  Regenerate a received RREQ or RREP

   o  Send an RREP_Ack

   o  Maintain valid routes in the Local Route Set

   o  Create, process and regenerate RERR messages




Perkins, et al.         Expires October 22, 2016               [Page 19]

Internet-Draft                   AODVv2                       April 2016


6.2.  Next Hop Monitoring

   To ensure AODVv2 routers Routers do not establish routes over uni-
UH> "routers Routers"?

   directional links, AODVv2 routers MUST verify that the link to the
   next hop router is bidirectional before marking a route as valid in
   the Local Route Set.

   AODVv2 provides a mechanism for testing bidirectional connectivity
   during route discovery, and blacklisting routers where bidirectional
   connectivity is not available.  If a route discovery is retried by
   RREQ_Gen, the blacklisted routers can be excluded from the process,
   and a different route can be discovered.
UH> "Can" be excluded? (SHOULD/MUST?)

     Further, a route is not to
   be used for forwarding until the bidirectionality of the link to the
   next hop is confirmed.  AODVv2 routers do not need to monitor
   bidirectionality for links to neighboring routers which are not used
   as next hops on routes in the Local Route Set.
UH> Shouldn't there be some RFC2119 language in this paragraph?


   o  Bidirectional connectivity to upstream routers is tested by
      requesting acknowledgement of RREP messages by including an
      AckReq, which MUST be answered by sending an RREP_Ack.  Receipt of
      an RREP_Ack within RREP_Ack_SENT_TIMEOUT proves that bidirectional
      connectivity exists.  Otherwise, a link is determined to be
      unidirectional.  All AODVv2 routers MUST support this process,
      which is explained in Section 7.2 and Section 7.3.

   o  For the downstream router, receipt of an RREP message containing
      the route to TargAddr is confirmation of bidirectionality , since
      an RREP message is a reply to a RREQ message which previously
      crossed the link in the opposite direction.

   To assist with next hop monitoring, a Neighbor Set (Section 4.3) is
   maintained.  When an RREQ or RREP is received, search for an entry in
   the Neighbor Set where all of the following conditions are met:

   o  Neighbor.IPAddress == IP address from which the RREQ or RREP was
      received

   o  Neighbor.Interface == Interface on which the RREQ or RREP was
      received.

   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.
UH> How? (a forward reference to a section would be helpful)


    If an acknowledgement is not received within the timeout
   period,
UH> Which timeout period?

   the neighbor MUST have Neighbor.State set to Blacklisted.  If
   an acknowledgement is received within the timeout period,
   Neighbor.State is set to Confirmed.  While the value of




Perkins, et al.         Expires October 22, 2016               [Page 20]

Internet-Draft                   AODVv2                       April 2016


   Neighbor.State is Confirmed, the request for an acknowledgement of
   any other RREP message is unnecessary.

   When routers perform other operations such as those from the list
   below, these MAY be used as additional indications of connectivity:

   o  NHDP HELLO Messages [RFC6130]

   o  Route timeout

   o  Lower layer triggers, e.g. message reception or link status
      notifications

   o  TCP timeouts

   o  Promiscuous listening

   o  Other monitoring mechanisms or heuristics

   If such an external process signals that the link to a neighbor is
   bidirectional, the AODVv2 router MAY update the matching Neighbor Set
   entry by changing the value of Neighbor.State to Confirmed, e.g.
UH> How would a TCP timeout or Route timeout indicate that a neighbor
state should be changed to Confirmed? Shouldn't it be the opposite?


   receipt of a Neighborhood Discovery Protocol HELLO message with the
   receiving router listed as a neighbor.  If an external process
   signals that a link is not bidirectional, the the value of
   Neighbor.State MAY be changed to Blacklisted, e.g. notification of a
   TCP timeout.

6.3.  Neighbor Set Update

   On receipt of an RREQ or RREP message, the Neighbor Set MUST be
   checked for an entry with Neighbor.IPAddress which matches the source
   IP address of a packet containing the AODVv2 message.  If no matching
   entry is found, a new entry is created.

   A new Neighbor Set entry is created as follows:

   o  Neighbor.IPAddress := Source IP address of the received route
      message

   o  Neighbor.State := Unknown

   o  Neighbor.ResetTime := INFINITY_TIME

   o  Neighbor.Interface := Interface on which the RREQ or RREP was
      received.  MUST equal Interface.Id of one of the entries in the
      InterfaceSet (see Section 4.1).




Perkins, et al.         Expires October 22, 2016               [Page 21]

Internet-Draft                   AODVv2                       April 2016


   If the message is one of the following:

   o  an RREP which answers a RREQ sent within RREQ_WAIT_TIME over the
      same interface as Neighbor.Interface

   o  an RREP_Ack which answers a RREP sent within RREP_Ack_SENT_TIMEOUT
      over the same interface as Neighbor.Interface

   the link to the neighbor is bidirectional and the Neighbor Set entry
   is updated as follows:

   o  Neighbor.State := Confirmed

   o  Neighbor.ResetTime := INFINITY_TIME

   If the Multicast Route Message Set contains an entry where:

   o  RteMsg.MessageType == RREP

   o  RteMsg.AckReqAddr == Neighbor.IPAddress

   o  RteMsg.Interface == Neighbor.Interface

   o  RteMsg.Timestamp + RREP_Ack_SENT_TIMEOUT < CurrentTime

   the link is considered to be uni-directional and the Neighbor Set
   entry is updated as follows:

   o  Neighbor.State := Blacklisted

   o  Neighbor.ResetTime := CurrentTime + MAX_BLACKLIST_TIME

   When the Neighbor.ResetTime is reached, the Neighbor Set entry is
   updated as follows:

   o  Neighbor.State := Unknown

   If an external mechanism reports a link as broken, the Neighbor Set
   entry SHOULD be removed.

   Route requests from neighbors with Neighbor.State set to Blacklisted
   are ignored to avoid persistent IP packet loss or protocol failures.
   Neighbor.ResetTime allows the neighbor to again be allowed to
   participate in route discoveries after MAX_BLACKLIST_TIME, in case
   the link between the routers has become bidirectional.






Perkins, et al.         Expires October 22, 2016               [Page 22]

Internet-Draft                   AODVv2                       April 2016


6.4.  Interaction with the Forwarding Plane

   The signals descried in the following are conceptual signals, and can
s/descried/described/   (or better: specified)
   be implemented in various ways.  Conformant implementations of AODVv2
   are not mandated to implement the forwarding plane separately from
   the control plane or data plane; these signals and interactions are
   identified simply as assistance for implementers who may find them
   useful.

   AODVv2 requires signals from the forwarding plane:

   o  A packet cannot be forwarded because a route is unavailable:
      AODVv2 needs to know the source and destination IP addresses of
      the packet.  If the source of the packet is configured as a Router
      Client, the router should initiate route discovery to the
      destination.  If it is not a Router Client, the router should
      create a Route Error message.

   o  A packet is to be forwarded: AODVv2 needs to check the state of
      the route to ensure it is still valid.

   o  Packet forwarding succeeds: AODVv2 needs to update the record of
      when a route was last used to forward a packet.

   o  Packet forwarding failure occurs: AODVv2 needs to create a Route
      Error message.

   AODVv2 needs to send signals to the forwarding plane:

   o  A route discovery is in progress: buffering might be configured
      for packets requiring a route, while route discovery is attempted.

   o  A route discovery failed: any buffered packets requiring that
      route should be discarded, and the source of the packet should be
      notified that the destination is unreachable (using an ICMP
      Destination Unreachable message).  Route discovery fails if an
      RREQ cannot be generated because the control message generation
      limit has been reached, or if an RREP is not received within
      RREQ_WAIT_TIME (see Section 6.6).

   o  A route discovery is not permitted: any buffered packets requiring
      that route should be discarded.  A route discovery will not be
      attempted if the source address of the packet needing a route is
      not configured as a Router Client.

   o  A route discovery succeeded: install a corresponding route into
      the Routing Information Base and begin transmitting any buffered
      packets.



Perkins, et al.         Expires October 22, 2016               [Page 23]

Internet-Draft                   AODVv2                       April 2016


   o  A route has been made invalid: remove the corresponding route from
      the Routing Information Base.

   o  A route has been updated: update the corresponding route in the
      Routing Information Base.

6.5.  Message Transmission

   AODVv2 sends [RFC5444] formatted messages using the parameters for
   port number and IP protocol specified in [RFC5498].  Mapping of
   AODVv2 data to [RFC5444] messages is detailed in Section 8.  AODVv2
   multicast messages are sent to the link-local multicast address LL-
   MANET-Routers [RFC5498].  All AODVv2 routers MUST subscribe to LL-
   MANET-Routers on all AODVv2 interfaces [RFC5498] to receive AODVv2
   messages.  Note that multicast messages MAY be sent via unicast.  For
   example, this may occur for certain link-types (non-broadcast media),
   for manually configured router adjacencies, or in order to improve
   robustness.

   When multiple interfaces are available, an AODVv2 router transmitting
   a multicast message to LL-MANET-Routers MUST send the message on all
   interfaces that have been configured for AODVv2 operation, as given
   in the InterfaceSet (Section 4.1).

   To avoid congestion, each AODVv2 router's rate of message generation
   SHOULD be limited (CONTROL_TRAFFIC_LIMIT) and administratively
   configurable.  Messages SHOULD NOT be sent more frequently than one
   message per (1 / CONTROL_TRAFFIC_LIMIT)th of a second.  If this
   threshold is reached, messages MUST be sent based on their priority:

   o  Highest priority SHOULD be given to RREP_Ack messages.  This
      allows links between routers to be confirmed as bidirectional and
      avoids undesired blacklisting of next hop routers.

   o  Second priority SHOULD be given to RERR messages for undeliverable
      IP packets.  This avoids repeated forwarding of packets over
      broken routes that are still in use by other routers.

   o  Third priority SHOULD be given to RREP messages in order that
      RREQs do not time out.

   o  Fourth priority SHOULD be given to RREQ messages.

   o  Fifth priority SHOULD be given to RERR messages for newly
      invalidated routes.






Perkins, et al.         Expires October 22, 2016               [Page 24]

Internet-Draft                   AODVv2                       April 2016


   o  Lowest priority SHOULD be given to RERR messages generated in
      response to RREP messages which cannot be regenerated.  In this
      case the route request will be retried at a later point.

   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
UH> I am curious: Is there scientific or experimental data available
that shows the positive effects of this mechanism?


6.6.  Route Discovery, Retries and Buffering

   AODVv2's RREQ and RREP messages are used for route discovery.  RREQ
   messages are multicast to solicit an RREP, whereas RREP are unicast
   where possible.  The constants used inSection 6.7.1 this section are
UH> s/inSection/in Section/
   defined in Section 10.

   When an AODVv2 router needs to forward an IP packet (with source
   address OrigAddr and destination address TargAddr) from one of its
   Router Clients, it needs a route to TargAddr in its Routing
   Information Base.  If no route exists, the AODVv2 router generates
   (RREQ_Gen) and multicasts a Route Request message (RREQ), on all
   configured interfaces, containing OrigAddr and TargAddr.  The
   procedure for this is described in Section 7.1.1.  Each generated
   RREQ results in an increment to the router's sequence number.  The
   AODVv2 router generating an RREQ is referred to as RREQ_Gen.

   Buffering might be configured for IP packets awaiting a route for
   forwarding by RREQ_Gen, if sufficient memory is available.  Buffering
   of IP packets might have both positive and negative effects.  Real-
   time traffic, voice, and scheduled delivery may suffer if packets are
   buffered and subjected to delays, but TCP connection establishment
   will benefit if packets are queued while route discovery is performed
   [Koodli01].  Recommendations for appropriate buffer methods are out
   of scope for this specification.  Determining which packets to
   discard first when the buffer is full is a matter of policy at each
   AODVv2 router.  Note that using different or no buffer methods does
   not affect interoperability.

   RREQ_Gen awaits reception of a Route Reply message (RREP) containing
   a route toward TargAddr.  This can be achieved by monitoring the
   entry in the Multicast Route Message Table that corresponds to the
UH> s/Table/Set/

   generated RREP.  When CurrentTime exceeds RteMsg.Timestamp +
   RREQ_WAIT_TIME and no RREP has been received, RREQ_Gen will retry the
   route discovery.

   To reduce congestion in a network, repeated attempts at route
   discovery for a particular target address utilize a binary



Perkins, et al.         Expires October 22, 2016               [Page 25]

Internet-Draft                   AODVv2                       April 2016


   exponential backoff: for each additional attempt, the time to wait
   for receipt of the RREP is multiplied by 2.  If the requested route
   is not learned within the wait period, another RREQ is sent, up to a
   total of DISCOVERY_ATTEMPTS_MAX.  This is the same technique used in
   AODV [RFC3561].

   Through the use of bidirectional link monitoring and blacklists (see
   Section 6.2) uni-directional links on initial selected route will be
   ignored on subsequent route discovery attempts.

   Route discovery is considered to have failed after
   DISCOVERY_ATTEMPTS_MAX and the corresponding wait time for an RREP
   response to the final RREQ.  After the attempted route discovery has
   failed, RREQ_Gen waits at least RREQ_HOLDDOWN_TIME before attempting
   another route discovery to the same destination, in order to avoid
   repeatedly generating control traffic that is unlikely to discover a
   route.  Any IP packets buffered for TargAddr are also dropped and a
   Destination Unreachable ICMP message (Type 3) with a code of 1 (Host
   Unreachable Error) is delivered to the source of the packet, so that
   the application knows about the failure.

   If RREQ_Gen does receive a route message containing a route to
   TargAddr within the timeout, it processes the message according to
   Section 7.  When a valid LocalRoute entry is created in the Local
   Route Set, the route is also installed in the Routing Information
   Base, and the router will begin sending the buffered IP packets.  Any
   retry timers for the corresponding RREQ are then cancelled.

   During route discovery, all routers on the path learn a route to both
   OrigAddr and TargAddr, so that routes are constructed in both
   directions.  The route is optimized for the forward route.

6.7.  Processing Received Route Information

   All AODVv2 route messages contain a route.  A Route Request (RREQ)
   contains a route toward OrigAddr (and other addresses as indicated by
   OrigPrefixLen), and a Route Reply (RREP) contains a route toward
   TargAddr (and other addresses as indicated by TargPrefixLen).

UH> How does a RFC5444 message contain a route? It can contain one or
more addresses, and every address can be associated with one or more
TLVs. Some clarification would be helpful.

    All
   AODVv2 routers that receive a route message are able to store the
   route contained within it in their Local Route Set. Incoming
   information is first checked to verify that it is both safe to use
   and offers an improvement to existing information, as explained in
   Section 6.7.1.  If these checks pass, the Local Route Set MUST be
   updated according to Section 6.7.2.

   In the processes below, RteMsg is used to denote the route message,
   AdvRte is used to denote the route contained within it, and




Perkins, et al.         Expires October 22, 2016               [Page 26]

Internet-Draft                   AODVv2                       April 2016


   LocalRoute denotes an existing entry in the Local Route Set which
   matches AdvRte on address, prefix length, and metric type.

   AdvRte has the following properties:

   o  AdvRte.Address := network address given by combining
      RteMsg.OrigAddr and RteMsg.OrigPrefixLen (in RREQ) or
      RteMsg.TargAddr and RteMsg.TargPrefixLen (in RREP)

UH> How does this "combination" work? (in particular if the prefix
length is not included)

   o  AdvRte.PrefixLength := RteMsg.OrigPrefixLen (in RREQ) or
      RteMsg.TargPrefixLen (in RREP).  If no prefix length was included
      in RteMsg, prefix length is the address length, in bits, of
      RteMsg.OrigAddr (in RREQ) or RteMsg.TargAddr (in RREP)

   o  AdvRte.SeqNum := RteMsg.OrigSeqNum (in RREQ) or RteMsg.TargSeqNum
      (in RREP)

   o  AdvRte.NextHop := RteMsg.IPSourceAddress (an address of the
      sending interface of the router from which the RteMsg was
      received)

   o  AdvRte.MetricType := RteMsg.MetricType

   o  AdvRte.Metric := RteMsg.Metric

   o  AdvRte.Cost := Cost(R) using the cost function associated with the
      route's metric type, i.e. Cost(R) = AdvRte.Metric + Cost(L), as
      described in Section 5, where L is the link from the advertising
      router

   o  AdvRte.ValidityTime := RteMsg.ValidityTime, if included
UH> If not included, to what is the value set? null?

6.7.1.  Evaluating Route Information

   An incoming advertised route (AdvRte) is compared to existing
   LocalRoutes to determine whether the advertised route is to be used
   to update the AODVv2 Local Route Set. The incoming route information
   MUST be processed as follows:

   1.  Search for LocalRoutes in the Local Route Set matching AdvRte's
       address, prefix length and metric type

UH> By "matching", does it have to be exactly the same? What if the
route has the same address and metric type, but different prefix
length?

       *  If no matching LocalRoute exists, AdvRte MUST be used to
          update the Local Route Set and no further checks are required.
UH> "Update" how? (a forward reference to the appropriate section
could be helpful)

       *  If matching LocalRoutes are found, continue to Step 2.





Perkins, et al.         Expires October 22, 2016               [Page 27]

Internet-Draft                   AODVv2                       April 2016


   2.  Compare sequence numbers using the technique described in
       Section 4.4
UH> That section (4.4) doesn't handle comparison with wrap-around
(e.g., comparing sequence number 4 > 65,535)

       *  If AdvRte is more recent than all matching LocalRoutes, AdvRte
          MUST be used to update the Local Route Set and no further
          checks are required.
UH> Definition of "more recent"? (e.g., "sequence number larger
than... using the comparison algorithm defined in section 4.4")

       *  If AdvRte is stale, AdvRte MUST NOT be used to update the
          Local Route Set. Ignore AdvRte for further processing.
UH> Definition of "stale"? ("sequence number lower than")

       *  If the sequence numbers are equal, continue to Step 3.

   3.  Check that AdvRte is safe against routing loops compared to all
       matching LocalRoutes (see Section 5)

       *  If LoopFree(AdvRte, LocalRoute) returns FALSE, ignore AdvRte
          for further processing.  AdvRte MUST NOT be used to update the
          Local Route Set because using the incoming information might
          cause a routing loop.

       *  If LoopFree(AdvRte, LocalRoute) returns TRUE, continue to Step
          4.

   4.  Compare route costs

       *  If AdvRte is better than all matching LocalRoutes, it SHOULD
UH> Definition of "better"? ("cost(...) lower than ...")
          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 AdvRte is equal in cost and LocalRoute is valid, AdvRte
          SHOULD NOT be used to update the Local Route Set because it
          will offer no improvement.

       *  If AdvRte is worse
UH> Definition of "worse"? ("higher cost than...")
       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.

   If the advertised route is to be used to update the Local Route Set,
   the procedure in Section 6.7.2 MUST be followed.  If not, non-optimal
   routes will remain in the Local Route Set.




Perkins, et al.         Expires October 22, 2016               [Page 28]

Internet-Draft                   AODVv2                       April 2016


   For information on how to apply these changes to the Routing
   Information Base, see Section 4.5.

6.7.2.  Applying Route Updates

   After determining that AdvRte is to be used to update the Local Route
   Set (as described in Section 6.7.1), the following procedure applies.

   If AdvRte is learned from an RREQ message, the link to the next hop
   neighbor may not be confirmed as bidirectional (see Section 4.3).
   The route will offer improvement to the Local Route Set if the
   neighbor can be confirmed.  If there is no existing matching route,
   AdvRte allows a corresponding RREP to be sent.  If a matching entry
   already exists, AdvRte offers potential improvement.

   The route update is applied as follows:

   1.  If no existing entry in the Local Route Set matches AdvRte's
       address, prefix length and metric type, continue to Step 4 and
       create a new entry in the Local Route Set.

   2.  If two matching LocalRoutes exist in the Local Route Set, one is
       a valid route, and one is an Unconfirmed route, AdvRte may offer
       further improvement to the Unconfirmed route, or may offer an
       update to the valid route.
UH> Can there be more than one unconfirmed route?

       *  If AdvRte.NextHop's Neighbor.State is Unknown, the advertised
          route may offer improvement to the existing valid route, if
          the link to the next hop can be confirmed as bidirectional.
          Continue processing from Step 5 to update the existing
          Unconfirmed LocalRoute.

       *  If AdvRte.NextHop's Neighbor.State is Confirmed, the
          advertised route offers an update or improvement to the
          existing valid route.  Continue processing from Step 5 to
          update the existing valid LocalRoute.

UH> What happens if Neighbor.State is Blacklisted? (can that happen?)

   3.  If only one matching LocalRoute exists in the Local Route Set:

       *  If AdvRte.NextHop's Neighbor.State is Confirmed, continue
          processing from Step 5 to update the existing LocalRoute.

       *  If AdvRte.NextHop's Neighbor.State is Unknown, AdvRte may
          offer improvement the existing LocalRoute, if the link to
          AdvRte.NextHop can be confirmed as bidirectional.






Perkins, et al.         Expires October 22, 2016               [Page 29]

Internet-Draft                   AODVv2                       April 2016


       *  If LocalRoute.State is Unconfirmed, AdvRte is an improvement
          to an existing Unconfirmed route.  Continue processing from
          Step 5 to update the existing LocalRoute.

       *  If LocalRoute.State is Invalid, AdvRte can replace the
          existing LocalRoute.  Continue processing from Step 5 to
          update the existing LocalRoute.

       *  If LocalRoute.State is Active or Idle, AdvRte SHOULD be stored
          as an additional entry in the Local Route Set, with
          LocalRoute.State set to Unconfirmed.  Continue processing from
          Step 4 to create a new LocalRoute.

UH> Some rationale why a new entry is to be created what be helpful,
in particular because it's only a SHOULD.

   4.  Create an entry in the Local Route Set and initialize as follows:

       *  LocalRoute.Address := AdvRte.Address

       *  LocalRoute.PrefixLength := AdvRte.PrefixLength

       *  LocalRoute.MetricType := AdvRte.MetricType

   5.  Update the LocalRoute as follows:

       *  LocalRoute.SeqNum := AdvRte.SeqNum

       *  LocalRoute.NextHop := AdvRte.NextHop

       *  LocalRoute.NextHopInterface := interface on which RteMsg was
          received

       *  LocalRoute.Metric := AdvRte.Cost

       *  LocalRoute.LastUsed := CurrentTime

       *  LocalRoute.LastSeqNumUpdate := CurrentTime

       *  LocalRoute.ExpirationTime := CurrentTime + AdvRte.ValidityTime
          if a validity time exists, otherwise INFINITY_TIME

   6.  If a new LocalRoute was created, or if the existing
       LocalRoute.State is Invalid or Unconfirmed, update LocalRoute as
       follows:

       *  LocalRoute.State := Unconfirmed (if the next hop's
          Neighbor.State is Unknown)

       *  LocalRoute.State := Idle (if the next hop's Neighbor.State is
          Confirmed)
UH> Can Neighbor.State be Blacklisted?



Perkins, et al.         Expires October 22, 2016               [Page 30]

Internet-Draft                   AODVv2                       April 2016


   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.
UH> s/cancelled/canceled/
UH> Is there a list of all the timers? Which ones need to be canceled?
UH> Why SHOULD, not MUST? What happens if they are not canceled?

   If this update to the Local Route Set results in two LocalRoutes to
   the same address, the best LocalRoute will be Unconfirmed.
UH> Why is it that the best route is unconfirmed? Shouldn't it be the
worst route that is unconfirmed?


    In order
   to improve the route used for forwarding, the router SHOULD try to
   determine if the link to the next hop of that LocalRoute is
   bidirectional, by using that LocalRoute to forward future RREPs and
   request acknowledgements (see Section 7.2.1).

6.8.  Suppressing Redundant Messages Using the Multicast Route Message
      Set

   When route messages are flooded in a MANET, an AODVv2 router may
   receive multiple similar messages.
UH> What do you mean by "similar"? Several instances of the same
message (as identified by the message sequence number)?

    Regenerating every one of these
   gives little additional benefit, and generates unnecessary signaling
   traffic and might generate unnecessary interference.

   Each AODVv2 router stores information about recently received route
   messages in the AODVv2 Multicast Route Message Set (Section 4.6).

   Entries in the Multicast Route Message Set SHOULD be maintained for
   at least RteMsg_ENTRY_TIME after the last Timestamp update in order
   to account for long-lived RREQs traversing the network.  An entry
   MUST be deleted when the sequence number is no longer valid, i.e.,
   after MAX_SEQNUM_LIFETIME.  Memory-constrained devices MAY remove the
   entry before this time.
UH> In the case of memory-constrained devices, is there a minimum
constraint to keep the entries, e.g., at least for x seconds? (or else
there is risk of flooding a message forever)?

   Received route messages are tested against previously received route
   messages, and if determined to be redundant, regeneration or response
   can be avoided.

   To determine if a received message is redundant:

   1.  Search for an entry in the Multicast Route Message Set with the
       same MessageType, OrigAddr, TargAddr, Interface and MetricType

       *  If there is no entry, the message is not redundant.




Perkins, et al.         Expires October 22, 2016               [Page 31]

Internet-Draft                   AODVv2                       April 2016


       *  If there is an entry, continue to Step 2.

   2.  Compare sequence numbers using the technique described in
       Section 4.4
UH> That section does not describe the concepts of "older" and "newer"
sequence number (with respect to wrap-around), see comment in that
section.

       *  For RREQ messages, use OrigSeqNum of the entry for comparison.
          For RREP messages, use TargSeqNum of the entry for comparison.

       *  If the entry has an older sequence number than the received
          message, the message is not redundant.

       *  If the entry has a newer sequence number than the received
          message, the message is redundant.

       *  If the entry has the same sequence number, continue to Step 3.

   3.  Compare the metric values

       *  If the entry has a Metric value that is worse than or equal to
          the metric in the received message, the message is redundant.

       *  If the entry has a Metric value that is better than the metric
          in the received message, the message is not redundant.

   If the message is redundant, update the Timestamp and RemoveTime on
   the entry, since matching route messages are still traversing the
   network and this entry should be maintained.
UH> Updated how? Set it to the current timestamp?

    This message MUST NOT
   be regenerated or responded to.

   If the message is not redundant, create an entry or update the
   existing entry.

   To update a Multicast Route Message Set entry, set:

   o  RteMsg.MessageType := the message type of the received message

   o  RteMsg.OrigAddr := OrigAddr from the message

   o  RteMsg.OrigPrefixLen := the prefix length associated with OrigAddr
UH> Can this be unknown?

   o  RteMsg.TargAddr := TargAddr from the message

   o  RteMsg.TargPrefixLen := the prefix length associated with TargAddr

   o  RteMsg.OrigSeqNum := the sequence number associated with OrigAddr,
      if present in the received message
UH> Could be helpful to clarify in which cases the sequence number is
not present in the message (e.g., s/if present in the received
message/if RteMsg is an RREQ/





Perkins, et al.         Expires October 22, 2016               [Page 32]

Internet-Draft                   AODVv2                       April 2016


   o  RteMsg.TargSeqNum := the sequence number associated with TargAddr,
      if present in the received message
UH> Could be helpful to clarify in which cases the sequence number is
not present in the message (e.g., s/if present in the received
message/if RteMsg is an RREP/

   o  RteMsg.Metric := the metric value associated with OrigAddr in a
      received RREQ or TargAddr in a received RREP

   o  RteMsg.MetricType := the metric type associated with RteMsg.Metric

   o  RteMsg.Timestamp := CurrentTime

   o  RteMsg.RemoveTime := CurrentTime + MAX_SEQNUM_LIFETIME

   Where the message is determined not redundant before Step 3, it MUST
   be regenerated or responded to.  When a message is determined to be
   not redundant in Step 3, it MAY be suppressed to avoid extra control
   traffic.  However, since the processing of the message will result in
   an update to the Local Route Set, the message SHOULD be regenerated
   or responded to, to ensure other routers have up-to-date information
   and the best metrics.  If the message is not regenerated, the best
   route may not be found.  Regeneration or response is to be performed
   using the processes outlined in Section 7.

6.9.  Suppressing Redundant Route Error Messages using the Route Error
      Set

   In order to avoid flooding the network with RERR messages when a
   stream of IP packets to an unreachable address arrives, an AODVv2
   router SHOULD avoid creating duplicate messages by determining
   whether an equivalent RERR has recently been sent.  This is achieved
   with the help of the Route Error Set (see Section 4.7).

   To determine if a received RERR is redundant:

   1.  Search for an entry in the Route Error Set where:

       *  RerrMsg.AddressList == RERR.AddressList

       *  RerrMsg.PktSource == RERR.PktSource

       If a matching entry is found, no further processing is required
       and the RERR SHOULD NOT be sent.

   2.  If no matching entry is found, a new entry with the following
       properties is created:

       *  RerrMsg.Timeout := CurrentTime + RERR_TIMEOUT

       *  RerrMsg.AddressList == RERR.AddressList



Perkins, et al.         Expires October 22, 2016               [Page 33]

Internet-Draft                   AODVv2                       April 2016


       *  RerrMsg.PktSource == RERR.PktSource

6.10.  Local Route Set Maintenance

   Route maintenance involves monitoring LocalRoutes in the Local Route
   Set, updating LocalRoute.State to handle route timeouts and reporting
   routes that become Invalid.

6.10.1.  LocalRoute State Changes

   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.
UH> As implementer, that guidance is not easy to follow, "At any time,
any LocalRoute MAY be examined and updated".  Does it mean I should
implement a thread that repeatedly (e.g., every 10 secods) examines
and updates the routes? Or should I rather listen for certain events?
And why MAY and not SHOULD/MUST?

   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.

UH> What does "LocalRoute.State MUST be checked" mean? (checked how?)

   Route timeout behaviour is as follows:

   o  An Unconfirmed route MUST be expunged at MAX_SEQNUM_LIFETIME after
      LocalRoute.LastSeqNumUpdate.

   o  An Idle route MUST become Active when used to forward an IP
      packet.  If the route is not used to forward an IP packet within
      MAX_IDLETIME, LocalRoute.State MUST become Invalid.

   o  An Active route which is a timed route (i.e., with
      LocalRoute.ExpirationTime not equal to INFINITY_TIME) remains
      Active until LocalRoute.ExpirationTime, after which it MUST become
      Invalid.  If it it not a timed route, it MUST become Idle if the
      route is not used to forward an IP packet within ACTIVE_INTERVAL.

   o  An Invalid route SHOULD remain in the Local Route Set, since
      LocalRoute.SeqNum is used to classify future information about
      LocalRoute.Address as stale or fresh.

   o  In all cases, if the time since LocalRoute.LastSeqNumUpdate
      exceeds MAX_SEQNUM_LIFETIME, LocalRoute.SeqNum must be set to
      zero.  This is required to ensure that any AODVv2 routers
      following the initialization procedure can safely begin routing
      functions using a new sequence number.  A LocalRoute with
      LocalRoute.State set to Active or Idle can remain in the Local
      Route Set after removing the sequence number,
UH> By "removing the sequence number", do you mean set it to 0?

       for exmple if the
      route is reliably carrying traffic.  If LocalRoute.State is
      Invalid, or later becomes Invalid, the LocalRoute MUST be expunged
      from the Local Route Set.
UH> What do you mean by "later becomes Invalid"? Do we need another
monitor for later changes?

   LocalRoutes can become Invalid before a timeout occurs:



Perkins, et al.         Expires October 22, 2016               [Page 34]

Internet-Draft                   AODVv2                       April 2016


   o  If an external mechanism reports a link as broken, all LocalRoutes
      using that link for LocalRoute.NextHop MUST immediately have
      LocalRoute.State set to Invalid.

   o  LocalRoute.State MUST immediately be set to Invalid if a Route
      Error (RERR) message is received where:

      *  The sender is LocalRoute.NextHop or PktSource is a Router
         Client address

      *  There is an Address in AddressList which matches
         LocalRoute.Address, and:
UH> What if an extension adds an address to the RFC5444 address block
(associated with any TLV specified in that extension)? That address
should not be considered here. "AddressList" is not clearly defined,
IMO. Should this address be associated with a specific TLV in order to
be considered for this rule?

         +  The prefix length associated with this Address, if any,
            matches LocalRoute.PrefixLength

         +  The sequence number associated with this Address, if any, is
            newer or equal to LocalRoute.SeqNum (see Section 4.4)
UH> I am not sure how there can be addresses without sequence number.

         +  The metric type associated with this Address matches
            LocalRoute.MetricType

   LocalRoutes are also updated when Neighbor.State is updated:

   o  While the value of Neighbor.State is set to Unknown, any routes in
      the Local Route Set using that neighbor as a next hop MUST have
      LocalRoute.State set to Unconfirmed.

   o  When the value of Neighbor.State is set to Confirmed, the
      Unconfirmed routes in the Local Route Set using that neighbor as a
      next hop MUST have LocalRoute.State set to Idle.  Any other
      matching LocalRoutes with metric values worse than
      LocalRoute.Metric MUST be expunged from the Local Route Set.

   o  When the value of Neighbor.State is set to Blacklisted, any valid
      routes in the Local Route Set using that neighbor for their next
      hop MUST have LocalRoute.State set to Invalid.

   o  When a Neighbor Set entry is removed, all routes in the Local
      Route Set using that neighbor as next hop MUST have
      LocalRoute.State set to Invalid.

   Memory constrained devices MAY choose to expunge routes from the
   AODVv2 Local Route Set before LocalRoute.ExpirationTime, but MUST
   adhere to the following rules:

   o  An Active route MUST NOT be expunged, as it is in use.  If
      deleted, IP traffic forwarded to this router will prompt



Perkins, et al.         Expires October 22, 2016               [Page 35]

Internet-Draft                   AODVv2                       April 2016


      generation of a Route Error message, and it will be necessary for
      a Route Request to be generated by the originator's router to re-
      establish the route.

   o  An Idle route SHOULD NOT be expunged, as it is still valid for
      forwarding IP traffic.  If deleted, this could result in dropped
      IP packets and a Route Request could be generated to re-establish
      the route.

   o  Any Invalid route MAY be expunged.  Least recently used Invalid
      routes SHOULD be expunged first, since the sequence number
      information is less likely to be useful.

   o  An Unconfirmed route MUST NOT be expunged if it was installed
      within the last RREQ_WAIT_TIME, because it may correspond to a
      route discovery in progress.  A Route Reply message might be
      received which needs to use the LocalRoute.NextHop information.
      Otherwise, it MAY be expunged.

UH> There are quite a few rules in this section. Have you created a
state diagram to make sure that these rules are not conflicting? Or
have you confirmed this in an interop test? I would have a hard time
as implementer to get this right.

6.10.2.  Reporting Invalid Routes

   When LocalRoute.State changes from Active to Invalid as a result of a
   broken link or a received Route Error (RERR) message, other AODVv2
   routers MUST be informed by sending an RERR message containing
   details of the invalidated route.

   An RERR message MUST also be sent when an AODVv2 router receives an
   IP packet to forward on behalf of another router but does not have a
   valid route in its Routing Information Base for the destination of
   the packet.

   An RERR message MUST also be sent when an AODVv2 router receives an
   RREP message to regenerate, but the LocalRoute to the OrigAddr in the
   RREP has been lost or is marked as Invalid.

   The packet or message triggering the RERR MUST be discarded.

   Generation of an RERR message is described in Section 7.4.1.

7.  AODVv2 Protocol Messages

   AODVv2 defines four message types: Route Request (RREQ), Route Reply
   (RREP), Route Reply Acknowledgement (RREP_Ack), and Route Error
   (RERR).

   Each AODVv2 message is defined as a set of data.  Rules for the
   generation, reception and regeneration of each message type are
   described in the following sections.  Section 8 discusses how the



Perkins, et al.         Expires October 22, 2016               [Page 36]

Internet-Draft                   AODVv2                       April 2016


   data is mapped to [RFC5444] Message TLVs, Address Blocks, and Address
   TLVs.

7.1.  Route Request (RREQ) Message

   Route Request messages are used in route discovery operations to
   request a route to a specified target address.  RREQ messages have
   the following contents:

    +-----------------------------------------------------------------+
    |                           AddressList                           |
    +-----------------------------------------------------------------+
    |                   PrefixLengthList (optional)                   |
    +-----------------------------------------------------------------+
    |                OrigSeqNum, (optional) TargSeqNum                |
    +-----------------------------------------------------------------+
    |                           MetricType                            |
    +-----------------------------------------------------------------+
    |                           OrigMetric                            |
    +-----------------------------------------------------------------+
    |                     ValidityTime (optional)                     |
    +-----------------------------------------------------------------+

                      Figure 1: RREQ message contents

   AddressList
      Contains OrigAddr and TargAddr, the source and destination
      addresses of the IP packet for which a route is requested.
      OrigAddr and TargAddr MUST be routable unicast addresses.
UH> So it's not possible to discover a prefix, e.g., 0.0.0.0/0? This
should be pointed out in the applicability section IMO.

   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.

   OrigSeqNum
      The sequence number associated with OrigAddr.

   TargSeqNum
      A sequence number associated with an existing Invalid route to
      TargAddr.  This MAY be included if available.
UH> Why MAY and not SHOULD/MUST? In which cases would it not be available?

   MetricType
      The metric type associated with OrigMetric.

   OrigMetric




Perkins, et al.         Expires October 22, 2016               [Page 37]

Internet-Draft                   AODVv2                       April 2016


      The metric value associated with the LocalRoute to OrigAddr (and
      to any other addresses included in the given prefix length), as
      seen from the sender of the message.

   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.

7.1.1.  RREQ Generation

   An RREQ is generated when an IP packet needs to be forwarded for a
   Router Client, and no valid route currently exists for the packet's
   destination in the Routing Information Base.

   Before creating an RREQ, the router SHOULD check the Multicast Route
   Message Set to see if an RREQ has recently been sent for the
   requested destination.  If so, and the wait time for a reply has not
   yet been reached, the router SHOULD continue to await a response
   without generating a new RREQ.  If the timeout has been reached, a
   new RREQ MAY be generated.  If buffering is configured, incoming IP
   packets awaiting this route SHOULD be buffered until the route
   discovery is completed.

   If the limit for the rate of AODVv2 control message generation has
   been reached, no message SHOULD be generated.
UH> In that case, will the route request ever be sent? Couldn't this
be an attack vector for a malicous router? (an application triggering
generation of many AODVv2 control messages, and once the limit has
been reached, other no control messages for other "legitimiate"
applicatinos would be generated)

   To generate the RREQ, the router (referred to as RREQ_Gen) follows
   this procedure:

   1.  Set AddressList := {OrigAddr, TargAddr}
UH> How is OrigAddr set in case of multiple interfaces / multiple addresses?

   2.  For the PrefixLengthList:

       *  If OrigAddr is part of an address range configured as a Router
          Client, set PrefixLengthList := {RouterClient.PrefixLength,
          null}. This allows receiving routers to learn a route to all
          the addresses included by the prefix length, not only to
          OrigAddr.

       *  Otherwise, omit PrefixLengthList.

   3.  For OrigSeqNum:

       *  Increment the router SeqNum as specified in Section 4.4.
UH> SeqNum is not mentioned in section 4.4.

       *  Set OrigSeqNum := SeqNum.




Perkins, et al.         Expires October 22, 2016               [Page 38]

Internet-Draft                   AODVv2                       April 2016


   4.  For TargSeqNum:

       *  If an Invalid route exists in the Local Route Set matching
          TargAddr using longest prefix matching and has a valid
          sequence number, set TargSeqNum := LocalRoute.SeqNum.

       *  If no Invalid route exists in the Local Route Set matching
          TargAddr, or the route doesn't have a sequence number, omit
          TargSeqNum.

   5.  Include MetricType and set the type accordingly
UH> According to what?

   6.  Set OrigMetric := RouterClient.Cost for the Router Client entry
       which includes OrigAddr
UH> s/which/that/
UH> How is that defined, "which includes OrigAddr"?

   7.  Include ValidityTime if advertising that the route to OrigAddr
       (and any other addresses included in the given prefix length) via
       this router is offered for a limited time, and set ValidityTime
       accordingly
UH> Is ValidityTime a parameter that can be set on the router? How
would the implementer know what to set this to? Some guidance would be
helpful.

   This AODVv2 message is used to create a corresponding [RFC5444]
   message (see Section 8) which is handed to the RFC5444 multiplexer
   for further processing.  By default, the multiplexer is instructed to
   multicast the message to LL-MANET- Routers on all interfaces
   configured for AODVv2 operation.

7.1.2.  RREQ Reception

   Upon receiving a Route Request, an AODVv2 router performs the
   following steps:

   1.  Check and update the Neighbor Set according to Section 6.3

       *  If the sender has Neighbor.State set to Blacklisted, ignore
          this RREQ for further processing.

   2.  Verify that the message contains the required data: OrigAddr,
       TargAddr, OrigSeqNum, and OrigMetric, and that OrigAddr and
       TargAddr are valid addresses (routable and unicast)

       *  If not, ignore this RREQ for further processing.

   3.  Check that the MetricType is supported and configured for use
UH> Where is that configured? (forward reference to section 10.5 would
be helpful)

       *  If not, ignore this RREQ for further processing.






Perkins, et al.         Expires October 22, 2016               [Page 39]

Internet-Draft                   AODVv2                       April 2016


   4.  Verify that the cost of the advertised route will not exceed the
       maximum allowed metric value for the metric type (Metric <=
       MAX_METRIC[MetricType] - Cost(L))

       *  If it will, ignore this RREQ for further processing.

   5.  Process the route to OrigAddr (and any other addresses included
       in the given prefix length) as specified in Section 6.7

   6.  Check if the information in the message is redundant by comparing
       to entries in the Multicast Route Message Set, following the
       procedure in Section 6.8

       *  If redundant, ignore this RREQ for further processing.

       *  If not redundant, continue processing.
UH> Shouldn't step number 6 instead be step number 1? Otherwise, it
could be possible to process the same message multiple times.

   7.  Check if the TargAddr belongs to one of the Router Clients

       *  If so, generate an RREP as specified in Section 7.2.1.

       *  If not, continue to RREQ regeneration.

7.1.3.  RREQ Regeneration

   By regenerating an RREQ, a router advertises that it will forward IP
   packets to the OrigAddr contained in the RREQ (and to other addresses
   included in the given prefix length) according to the information
   enclosed.  The router MAY choose not to regenerate the RREQ, for
   example if the router is heavily loaded or low on energy and
   therefore unwilling to advertise routing capability for more traffic.
   This could, however, decrease connectivity in the network or result
   in non-optimal paths.

   The RREQ SHOULD NOT be regenerated if the limit for the rate of
   AODVv2 control message generation has been reached.

   The procedure for RREQ regeneration is as follows:

   1.  Set AddressList, PrefixLengthList, sequence numbers and
       MetricType to the values in the received RREQ

   2.  Set OrigMetric := LocalRoute[OrigAddr].Metric

   3.  If the received RREQ contains a ValidityTime, or if the
       regenerating router wishes to limit the time that it offers a
       route to OrigAddr (and any other addresses included in the given
       prefix length), the regenerated RREQ MUST include ValidityTime
UH> That makes end-to-end integrity protection of the message very difficult.



Perkins, et al.         Expires October 22, 2016               [Page 40]

Internet-Draft                   AODVv2                       April 2016


       *  The ValidityTime is either the time limit the previous AODVv2
          router specified, or the time limit this router wishes to
          impose, whichever is lower.

   This AODVv2 message is used to create a corresponding [RFC5444]
   message (see Section 8) which is handed to the RFC5444 multiplexer
   for further processing.  By default, the multiplexer is instructed to
   multicast the message to LL-MANET-Routers on all interfaces
   configured for AODVv2 operation.  However, the regenerated RREQ can
   be unicast to the next hop address of the LocalRoute toward TargAddr,
   if known.

7.2.  Route Reply (RREP) Message

   When a Route Request message is received, requesting a route to a
   target address (TargAddr) which is configured as part of a Router
   Client entry, a Route Reply message is sent in response.  The RREP
   offers a route to TargAddr (and any other addresses included in the
   prefix length).

   RREP messages have the following contents:

    +-----------------------------------------------------------------+
    |                        AckReq (optional)                        |
    +-----------------------------------------------------------------+
    |                           AddressList                           |
    +-----------------------------------------------------------------+
    |                   PrefixLengthList (optional)                   |
    +-----------------------------------------------------------------+
    |                           TargSeqNum                            |
    +-----------------------------------------------------------------+
    |                           MetricType                            |
    +-----------------------------------------------------------------+
    |                           TargMetric                            |
    +-----------------------------------------------------------------+
    |                     ValidityTime (optional)                     |
    +-----------------------------------------------------------------+

                      Figure 2: RREP message contents

   AckReq
      The address of the intended next hop of the RREP.  This is
      included when the link to the next hop toward OrigAddr is not
      known to be bidirectional.  It indicates that an acknowledgement
      of the RREP is requested by the sender from the intended next hop
      (see Section 6.2).

   AddressList



Perkins, et al.         Expires October 22, 2016               [Page 41]

Internet-Draft                   AODVv2                       April 2016


      Contains OrigAddr and TargAddr, the source and destination
      addresses of the IP packet for which a route is requested.
      OrigAddr and TargAddr MUST be routable unicast addresses.

   PrefixLengthList
      Contains TargPrefixLen, i.e., the length, in bits, of the prefix
      associated with the Router Client entry which includes TargAddr.
      If omitted, the prefix length is equal to TargAddr's address
      length, in bits.

   TargSeqNum
      The sequence number associated with TargAddr.

   MetricType
      The metric type associated with TargMetric.

   TargMetric
      The metric value associated with the LocalRoute to TargAddr (and
      any other addresses included in the given prefix length), as seen
      from the sender of the message.

   ValidityTime
      The length of time that the message sender is willing to offer a
      route toward TargAddr (and any other addresses included in the
      given prefix length).  Omitted if no time limit is imposed.

7.2.1.  RREP Generation

   A Route Reply message is generated when a Route Request for a Router
   Client of the AODVv2 router arrives.  This is the case when
   RteMsg.TargAddr matches an address which is configured as a Router
   Client of the AODVv2 router.

   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.

   The RREP will follow the path of the route to OrigAddr.  If the best
   route to OrigAddr in the Local Route Set is Unconfirmed, the link to
   the next hop neighbor is not yet confirmed as bidirectional (as
   described in Section 6.2).  In this case the RREP MUST include AckReq
   set to the intended next hop address.  The AckReq indicates that an
   acknowledgement to the RREP is requested from the intended next hop
   router in the form of a Route Reply Acknowledgement (RREP_Ack).  If
   the best route to OrigAddr in the Local Route Set is valid, the link




Perkins, et al.         Expires October 22, 2016               [Page 42]

Internet-Draft                   AODVv2                       April 2016


   to the next hop neighbor is already confirmed as bidirectional, and
   the AckReq can be omitted.

   Implementations MAY allow a number of retries of the RREP if a
   requested acknowledgement is not received within
   RREP_Ack_SENT_TIMEOUT, doubling the timeout with each retry, up to a
   maximum of RREP_RETRIES, using the same exponential backoff described
   in Section 6.6 for RREQ retries.  The acknowledgement MUST be
   considered to have failed after the wait time for an RREP_Ack
   response to the final RREP.
UH> What happens when it's considered failed?

   To generate the RREP, the router (also referred to as RREP_Gen)
   follows this procedure:

   1.  If the link to the next hop router toward OrigAddr is not known
       to be bidirectional, include the AckReq with the address of the
       intended next hop router (see Section 8.2.3)

   2.  Set Address List := {OrigAddr, TargAddr}

   3.  For the PrefixLengthList:

       *  If TargAddr is part of an address range configured as a Router
          Client, set PrefixLengthList := {null,
          RouterClient.PrefixLength}. This allows receiving routers to
          learn a route to all the addresses included by the prefix
          length, not only to TargAddr.

       *  Otherwise, omit PrefixLengthList.

   4.  For the TargSeqNum:

       *  Increment the router SeqNum as specified in Section 4.4.

       *  Set TargSeqNum := SeqNum.

   5.  Include MetricType and set the type to match the MetricType in
       the received RREQ message

   6.  Set TargMetric := RouterClient.Cost for the Router Client entry
       which includes TargAddr

   7.  Include ValidityTime if advertising that the route to TargAddr
       (and any other addresses included in the given prefix length) via
       this router is offered for a limited time, and set ValidityTime
       accordingly





Perkins, et al.         Expires October 22, 2016               [Page 43]

Internet-Draft                   AODVv2                       April 2016


   This AODVv2 message is used to create a corresponding [RFC5444]
   message (see Section 8) which is handed to the RFC5444 multiplexer
   for further processing.  If the Neighbor Set contains an entry for
   the neighbor stored as LocalRoute[OrigAddr].NextHop, with
   Neighbor.State set to Confirmed, the multiplexer is instructed to
   unicast the RREP to LocalRoute[OrigAddr].NextHop.  Otherwise, it
   multicasts the RREP to LL-MANET-Routers.  The RREP MUST be sent over
   the same interface on which the RREQ that triggered it was received.

7.2.2.  RREP Reception

   Upon receiving a Route Reply, an AODVv2 router performs the following
   steps:

   1.   Verify that the message contains the required data: OrigAddr,
        TargAddr, TargSeqNum, and TargMetric, and that OrigAddr and
        TargAddr are valid addresses (routable and unicast)

        *  If not, ignore this RREP for further processing.

   2.   Check that the MetricType is supported and configured for use

        *  If not, ignore this RREP for further processing.

   3.   If this RREP does not correspond to a RREQ generated or
        regenerated in the last RREQ_WAIT_TIME, ignore for further
        processing.
UH> Can you expand what you mean by "does not correspond"?

   4.   Update the Neighbor Set according to Section 6.3

   5.   Verify that the cost of the advertised route does not exceed the
        maximum allowed metric value for the metric type (Metric <=
        MAX_METRIC[MetricType] - Cost(L))

        *  If it does, ignore this RREP for further processing.

   6.   If the AckReq is present, check the intended recipient of the
        received RREP:

        *  If there is an entry in the Router Client Set where
           RouterClient.IPAddress matches the address associated with
           the AckReq (see Section 8.2.3), the receiving router is the
           intended recipient.  Send an acknowledgement as specified in
           Section 7.3 and continue processing.

        *  Otherwise, ignore this RREP for further processing.





Perkins, et al.         Expires October 22, 2016               [Page 44]

Internet-Draft                   AODVv2                       April 2016


   7.   Process the route to TargAddr (and any other addresses included
        in the given prefix length) as specified in Section 6.7

   8.   Check if the message is redundant by comparing to entries in the
        Multicast Route Message Set (Section 6.8)
UH> Shouldn't step number 8 instead be step number 1? Otherwise, it
could be possible to process the same message multiple times.


        *  If redundant, ignore this RREP for further processing.

        *  If not redundant, save the information in the Multicast Route
           Message Set to identify future redundant RREP messages and
           continue processing.

   9.   Check if the OrigAddr belongs to one of the Router Clients

        *  If so, no further processing is necessary.

        *  If not, continue to Step 10.

   10.  Check if a valid (Active or Idle) or Unconfirmed LocalRoute
        exists to OrigAddr

        *  If so, continue to RREP regeneration.

        *  If not, a Route Error message SHOULD be transmitted to
           TargAddr according to Section 7.4.1 and the RREP SHOULD be
           discarded and not regenerated.

7.2.3.  RREP Regeneration

   A received Route Reply message is regenerated toward OrigAddr.  By
   regenerating a RREP, a router advertises that it will forward IP
   packets to TargAddr.

   The RREP SHOULD NOT be regenerated if CONTROL_TRAFFIC_LIMIT has been
   reached.  Otherwise, the router MUST regenerate the RREP.

   The procedure for RREP regeneration is as follows:

   1.  If the link to the next hop router toward OrigAddr is not known
       to be bidirectional, include the AckReq with the address of the
       intended next hop router

   2.  Set AddressList, PrefixLengthList, TargSeqNum and MetricType to
       the values in the received RREP

   3.  Set TargMetric := LocalRoute[TargAddr].Metric





Perkins, et al.         Expires October 22, 2016               [Page 45]

Internet-Draft                   AODVv2                       April 2016


   4.  If the received RREP contains a ValidityTime, or if the
       regenerating router wishes to limit the time that it will offer a
       route to TargAddr (and any other addresses included in the given
       prefix length), the regenerated RREP MUST include ValidityTime

       *  The ValidityTime is either the time limit the previous AODVv2
          router specified, or the time limit this router wishes to
          impose, whichever is lower.

   This AODVv2 message is used to create a corresponding [RFC5444]
   message (see Section 8) which is handed to the RFC5444 multiplexer
   for further processing.  If the Neighbor Set contains an entry for
   the neighbor stored as LocalRoute[OrigAddr].NextHop, with
   Neighbor.State set to Confirmed, the multiplexer is instructed to
   unicast the RREP to LocalRoute[OrigAddr].NextHop.  Otherwise, it
   multicasts the RREP to LL-MANET-Routers.  The RREP MUST be sent over
   LocalRoute[OrigAddr].NextHopInterface.

7.3.  Route Reply Acknowledgement (RREP_Ack) Message

   The Route Reply Acknowledgement is a response to a Route Reply
   message.  When the RREP_Ack message is received by the sender of the
   RREP, it confirms that the link between the two routers is
   bidirectional (see Section 6.2).  The RREP_Ack has no further data.

7.3.1.  RREP_Ack Generation

   An RREP_Ack MUST be generated if a received Route Reply includes an
   AckReq with an address matching one of the receiving router's IP
   addresses.

   The RREP_Ack SHOULD NOT be generated if the limit for the
   rate of AODVv2 control message generation has been reached.

   There is no further data in an RREP_Ack.  The [RFC5444]
   representation is discussed in Section 8.  The RREP_Ack is unicast,
   by default, to the source IP address of the RREP message that
   requested it.  It MUST be sent over the same interface on which the
   RREP that triggered it was received.

7.3.2.  RREP_Ack Reception

   Upon receiving an RREP_Ack, an AODVv2 router performs the following
   steps:

   1.  Check if the RREP_Ack was expected:

       *  Check if the Multicast Route Message Set contains an entry
          where:




Perkins, et al.         Expires October 22, 2016               [Page 46]

Internet-Draft                   AODVv2                       April 2016


          +  RteMsg.MessageType == RREP

          +  RteMsg.AckReqAddr matches the source IP address of the
             RREP_Ack

          +  RteMsg.Timestamp > CurrentTime - RREP_Ack_SENT_TIMEOUT

          +  RteMsg.Interface matches the interface on which the
             RREP_Ack was received

       *  If it does, the router cancels any associated timeouts and
          processing continues to Step 2.
UH> Which timeouts can that be?

       *  Otherwise no actions are required and processing ends.

   2.  Update the Neighbor Set according to Section 6.3

7.4.  Route Error (RERR) Message

   A Route Error message is generated by an AODVv2 router to notify
   other AODVv2 routers of routes that are no longer available.  An RERR
   message has the following contents:

    +-----------------------------------------------------------------+
    |                       PktSource (optional)                      |
    +-----------------------------------------------------------------+
    |                           AddressList                           |
    +-----------------------------------------------------------------+
    |                   PrefixLengthList (optional)                   |
    +-----------------------------------------------------------------+
    |                       SeqNumList (optional)                     |
    +-----------------------------------------------------------------+
    |                          MetricTypeList                         |
    +-----------------------------------------------------------------+

                      Figure 3: RERR message contents

   PktSource
      The source address of the IP packet triggering the RERR.  If the
      RERR is triggered by a broken link, PktSource is not required.

   AddressList
      The addresses of the routes not available through RERR_Gen.

   PrefixLengthList
      The prefix lengths, in bits, associated with the routes not
      available through RERR_Gen.  These values indicate whether routes
      represent a single device or an address range.



Perkins, et al.         Expires October 22, 2016               [Page 47]

Internet-Draft                   AODVv2                       April 2016


   SeqNumList
      The sequence numbers of the routes not available through RERR_Gen
      (where known).

   MetricTypeList
      The metric types associated with the routes not available through
      RERR_Gen.

7.4.1.  RERR Generation

   A Route Error message is generated when an AODVv2 router (also
   referred to as RERR_Gen) needs to report that a destination is not
   reachable.  There are three events that cause this response:

   o  When an IP packet that has been forwarded from another router, but
      cannot be forwarded further because there is no valid route in the
      Routing Information Base for its destination, the source of the
      packet needs to be informed that the route to the destination of
      the packet does not exist.  The RERR generated MUST include
      PktSource set to the source address of the IP packet, and MUST
      contain only one unreachable address in the AddressList, i.e., the
      destination address of the IP packet.  RERR_Gen MUST discard the
      IP packet that triggered generation of the RERR.  The prefix
      length, sequence number and metric type SHOULD be included if
      known from an existing Invalid LocalRoute to the unreachable
      address.

   o  When an RREP message cannot be regenerated because the LocalRoute
      to OrigAddr has been lost or is Invalid, RREP_Gen needs to be
      informed that the route to OrigAddr does not exist.  The RERR
      generated MUST include PktSource set to the TargAddr of the RREP,
      and MUST contain only one unreachable address in the AddressList,
      the OrigAddr from the RREP.  RERR_Gen MUST discard the RREP
      message that triggered generation of the RERR.  The prefix length,
      sequence number and metric type SHOULD be included if known from
      an Invalid LocalRoute to the unreachable address.

   o  When a link breaks, multiple LocalRoutes may become Invalid, and
      the RERR generated MAY contain multiple unreachable addresses.
      The RERR MUST include MetricTypeList.  PktSource is omitted.  All
      previously Active LocalRoutes that used the broken link MUST be
      reported.  The AddressList, PrefixLengthList, SeqNumList, and
      MetricTypeList will contain entries for each LocalRoute which has
      become Invalid.  An RERR message is only sent if an Active
      LocalRoute becomes Invalid, though an AODVv2 router can also
      include Idle LocalRoutes that become Invalid if the configuration
      parameter ENABLE_IDLE_IN_RERR is set (see Section 10.3).




Perkins, et al.         Expires October 22, 2016               [Page 48]

Internet-Draft                   AODVv2                       April 2016


   The RERR SHOULD NOT be generated if CONTROL_TRAFFIC_LIMIT has been
   reached.  The RERR also SHOULD NOT be generated if it is a duplicate,
   as determined by Section 6.9.

   Incidentally, if an AODVv2 router receives an ICMP error packet to or
   from the address of one of its Router Clients, it forwards the ICMP
   packet in the same way as any other IP packet, and will not generate
   any RERR message based on the contents of the ICMP packet.
UH> What do you mean by "ICMP error packet"? Which code? Also, what is
the timing sequence? The ICMP destination unavailable could be
received before it is triggered to send the RERR.

   To generate the RERR, the router follows this procedure:

   1.  If necessary, include PktSource and set the value as given above

   2.  For each LocalRoute that needs to be reported:

       *  Insert LocalRoute.Address into the AddressList.

       *  Insert LocalRoute.PrefixLength into PrefixLengthList, if known
          and not equal to the address length.

       *  Insert LocalRoute.SeqNum into SeqNumList, if known.

       *  Insert LocalRoute.MetricType into MetricTypeList.

   The AODVv2 message is used to create a corresponding [RFC5444]
   message (see Section 8).
UH> So does it mean there are two messages, one "AODVv2 message", one
"corresponding [RFC5444] message"?

   If the RERR is sent in response to an undeliverable IP packet or RREP
   message, i.e., if PktSource is included, the RERR SHOULD be sent
   unicast to the next hop on the route to PktSource.  It MUST be sent
   over the same interface on which the undeliverable IP packet was
   received.  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.
UH> If the next hop on the route to PktSource is not available, would
this trigger a new RREQ?

7.4.2.  RERR Reception

   Upon receiving a Route Error, an AODVv2 router performs the following
   steps:

   1.  Verify that the message contains the required data: at least one
       unreachable address

       *  If not, ignore this RERR for further processing.

   2.  For each address in the AddressList, check that:




Perkins, et al.         Expires October 22, 2016               [Page 49]

Internet-Draft                   AODVv2                       April 2016


       *  The address is valid (routable and unicast)

       *  The MetricType is supported and configured for use

       *  There is a LocalRoute with the same MetricType matching the
          address using longest prefix matching

       *  Either the LocalRoute's next hop is the sender of the RERR and
          the next hop interface is the interface on which the RERR was
          received, or PktSource is present in the RERR and is a Router
          Client address

       *  The unreachable address' sequence number is either unknown, or
          is greater than the LocalRoute's sequence number

       If any of the above are false the address does not match a
       LocalRoute and MUST NOT be processed or regenerated in a RERR.

       If all of the above are true, the LocalRoute which matches the
       address is no longer valid.  If the LocalRoute was previously
       Active, it MUST be reported in a regenerated RERR.  If the
       LocalRoute was previously Idle, it MAY be reported in a
       regenerated RERR, if ENABLE_IDLE_IN_RERR is configured.  The
       Local Route Set MUST be updated according to these rules:

       *  If the LocalRoute's prefix length is the same as the
          unreachable address' prefix length, set LocalRoute.State to
          Invalid.

       *  If the LocalRoute's prefix length is longer than the
          unreachable address' prefix length, the LocalRoute MUST be
          expunged from the Local Route Set, since it is a sub-route of
          the route which is reported to be Invalid.
UH> What's a "sub-route"? That is not a known terminology, nor is it
defined in the terminology section.

       *  If the prefix length is different, create a new LocalRoute
          with the unreachable address, and its prefix length and
          sequence number, and set LocalRoute.State to Invalid.  These
          Invalid routes are retained to avoid processing stale
          messages.

       *  Update the sequence number on the existing LocalRoute, if the
          reported sequence number is determined to be newer using the
          comparison technique described in Section 4.4.

   3.  If there are previously Active LocalRoutes that MUST be reported,
       as identified in step 2.:

       *  Regenerate the RERR as detailed in Section 7.4.3.



Perkins, et al.         Expires October 22, 2016               [Page 50]

Internet-Draft                   AODVv2                       April 2016


7.4.3.  RERR Regeneration

   The Route Error message SHOULD NOT be regenerated if
   CONTROL_TRAFFIC_LIMIT has been reached.

   The procedure for RERR regeneration is as follows:

   1.  If PktSource was included in the original RERR, and PktSource is
       not a Router Client, copy it into the regenerated RERR

   2.  For each LocalRoute that needs to be reported as identified in
       Section 7.4.1:

       *  Insert LocalRoute.Address into the AddressList.

       *  Insert LocalRoute.PrefixLength into PrefixLengthList, if known
          and not equal to the address length.

       *  Insert LocalRoute.SeqNum into SeqNumList, if known.

       *  Insert LocalRoute.MetricType into MetricTypeList.
UH> Changing the message along its path makes end-to-end integrity
protection impossible.

   The AODVv2 message is used to create a corresponding [RFC5444]
   message (see Section 8).  If the RERR contains PktSource, the
   regenerated RERR SHOULD be sent unicast to the next hop on the
   LocalRoute to PktSource.  It MUST be sent over the same interface on
   which the undeliverable IP packet was received.  If there is no route
   to PktSource, or PktSource is a Router Client, it SHOULD be multicast
   to LL-MANET-Routers.  If the RERR is sent in response to a broken
   link, the RERR is, by default, multicast to LL-MANET-Routers.
UH> Is there any prevention to flood multicast RERRs forever in the
network (similar to the process you described for RREQs/RREPs)? i.e.,
storing a set of sequence numbers of recently seen RERRs (BTW, do
RERRs contain a sequence number?)

8.  RFC 5444 Representation

   AODVv2 specifies that all control messages between routers MUST use
   the Generalized Mobile Ad Hoc Network Packet/Message Format
   [RFC5444], and therefore AODVv2's route messages comprise data which
   is mapped to message elements in [RFC5444].

   [RFC5444] provides a multiplexed transport for multiple protocols.
   An [RFC5444] implementation MAY choose to optimize the content of
   certain elements during message creation to reduce control message
   overhead.

   A brief summary of the [RFC5444] format:

   1.  A packet contains zero or more messages





Perkins, et al.         Expires October 22, 2016               [Page 51]

Internet-Draft                   AODVv2                       April 2016


   2.  A message contains a Message Header, one Message TLV Block, zero
       or more Address Blocks, and one Address Block TLV Block per
       Address Block

   3.  The Message TLV Block MAY contain zero or more Message TLVs

   4.  An Address Block TLV Block MAY include zero or more Address Block
       TLVs

   5.  Each TLV value in an Address Block TLV Block can be associated
       with all of the addresses, or with a contiguous set of addresses,
       or with a single address in the Address Block

   AODVv2 does not require access to the [RFC5444] packet header.

   In the message header, AODVv2 uses  and .
   The  field indicates the length of any addresses in
   the message, using  := (address length in octets -
   1), i.e. 3 for IPv4 and 15 for IPv6.

   The addresses in an Address Block MAY appear in any order, and values
   in a TLV in the Address Block TLV Block must be associated with the
   correct address in the Address Block by the [RFC5444] implementation.
   To indicate which value is associated with each address, the AODVv2
   message representation uses lists where the order of the addresses in
   the AODVv2 AddressList matches the order of values in other data
   lists, e.g., the order of SeqNums in the SeqNumList in an RERR.
   [RFC5444] maps this information to Address Block TLVs associated with
   the relevant addresses in the Address Block.

   Each address included in the Address Block is identified as OrigAddr,
   TargAddr, PktSource, or Unreachable Address by including an
   ADDRESS_TYPE TLV in the Address Block TLV Block.

   The following sections show how AODVv2 data is represented in
   [RFC5444] messages.  AODVv2 makes use of the VALIDITY_TIME Address
   Block TLV from [RFC5497], and defines (in Section 11) a number of new
   TLVs.  To calculate the time-value for the VALIDITY_TIME Address
   Block TLV, the value of C is defined in Section 10.2.

   Where the extension type of a TLV is set to zero, this is the default
   [RFC5444] value and the extension type will not be included in the
   message.








Perkins, et al.         Expires October 22, 2016               [Page 52]

Internet-Draft                   AODVv2                       April 2016


8.1.  Route Request Message Representation

8.1.1.  Message Header

                    +-------+---------------+--------+
                    | Data  | Header Field  | Value  |
                    +-------+---------------+--------+
                    | None  |     | RREQ   |
                    +-------+---------------+--------+

UH> What does this mean? Can you add some text here? Are there any
other headers defined? (such as ,
 , , )

8.1.2.  Message TLV Block

   AODVv2 does not define any Message TLVs for an RREQ message.

UH> What about OrigAddr / TargetAddr?

8.1.3.  Address Block

   An RREQ contains two addresses, OrigAddr and TargAddr, and each
UH> If an extension to this specification is used, it could contain
more than two addresses.
   address has an associated prefix length.  If the prefix length has
   not been included in the AODVv2 message, it is equal to the address
   length in bits.

        +-------------------------+------------------------------+
        | Data                    | Address Block                |
        +-------------------------+------------------------------+
        | OrigAddr/OrigPrefixLen  | 
 +   |
        | TargAddr/TargPrefixLen  | 
 +   |
        +-------------------------+------------------------------+

UH> The notation "
 + " is not quite intuitive.
And what does the "Data" column in this table mean, and how does it
correlate to the "Address Block" column?

8.1.4.  Address Block TLV Block

   Address Block TLVs are always associated with one or more addresses
   in the Address Block.  The following sections show the TLVs that
   apply to each address.
UH> Not to each address: an extension to this protocol could add
addresses, and they wouldn't be associated with any of these TLVs.

8.1.4.1.  Address Block TLVs for OrigAddr
















Perkins, et al.         Expires October 22, 2016               [Page 53]

Internet-Draft                   AODVv2                       April 2016


   +--------------+---------------+------------+-----------------------+
   | Data         | TLV Type      | Extension  | Value                 |
   |              |               | Type       |                       |
   +--------------+---------------+------------+-----------------------+
   | None         | ADDRESS_TYPE  | 0          | ADDRTYPE_ORIGADDR     |
UH> How is ADDRTYPE_ORIGADDR defined? I don't see any request for IANA
to allocate a number for it (only for ORIGADDR)

   | OrigSeqNum   | SEQ_NUM       | 0          | Sequence number of    |
   |              |               |            | RREQ_Gen, the router  |
   |              |               |            | which initiated route |
   |              |               |            | discovery.            |
UH> Why not use  of the RFC5444 message in combination
with  instead of adding the originator address into an
address block and using a new TLV? This would safe bits

   | OrigMetric   | PATH_METRIC   | MetricType | Metric value for the  |
   | /MetricType  |               |            | route to OrigAddr,    |
   |              |               |            | using MetricType.     |
   | ValidityTime | VALIDITY_TIME | 0          | ValidityTime for      |
   |              |               |            | route to OrigAddr,    |
   |              |               |            | represented as        |
   |              |               |            | detailed in           |
   |              |               |            | [RFC5497].            |
   +--------------+---------------+------------+-----------------------+

UH> Do I need to associate all addresses with all of these TLVs? Or
only some of them? Which ones are mandatory to associate with the
address? What does the "Data" column mean, and why "None" for the
first row?

8.1.4.2.  Address Block TLVs for TargAddr

   +------------+--------------+-------------+-------------------------+
   | Data       | TLV Type     | Extension   | Value                   |
   |            |              | Type        |                         |
   +------------+--------------+-------------+-------------------------+
   | None       | ADDRESS_TYPE | 0           | ADDRTYPE_TARGADDR       |
   | TargSeqNum | SEQ_NUM      | 0           | The last known          |
   |            |              |             | TargSeqNum for          |
   |            |              |             | TargAddr.               |
   +------------+--------------+-------------+-------------------------+

8.2.  Route Reply Message Representation

8.2.1.  Message Header

                    +-------+---------------+--------+
                    | Data  | Header Field  | Value  |
                    +-------+---------------+--------+
                    | None  |     | RREP   |
                    +-------+---------------+--------+

8.2.2.  Message TLV Block

   AODVv2 does not define any Message TLVs for an RREP message.







Perkins, et al.         Expires October 22, 2016               [Page 54]

Internet-Draft                   AODVv2                       April 2016


8.2.3.  Address Block

   An RREP contains a minimum of two addresses, OrigAddr and TargAddr,
   and each address has an associated prefix length.  If the prefix
   length has not been included in the AODVv2 message, it is equal to
   the address length in bits.

   It MAY also contain the address of the intended next hop, in order to
   request acknowledgement to confirm bidirectionality of the link, as
   described in Section 6.2.
UH> Which TLV type is associated with the next hop in that case?

    The prefix length associated with this
   address is equal to the address length in bits.

        +-------------------------+------------------------------+
        | Data                    | Address Block                |
        +-------------------------+------------------------------+
        | OrigAddr/OrigPrefixLen  | 
 +   |
        | TargAddr/TargPrefixLen  | 
 +   |
        | AckReq                  | 
 +   |
        +-------------------------+------------------------------+

8.2.4.  Address Block TLV Block

   Address Block TLVs are always associated with one or more addresses
   in the Address Block.  The following sections show the TLVs that
   apply to each address.

8.2.4.1.  Address Block TLVs for OrigAddr

     +-------+---------------+-----------------+--------------------+
     | Data  | TLV Type      | Extension Type  | Value              |
     +-------+---------------+-----------------+--------------------+
     | None  | ADDRESS_TYPE  | 0               | ADDRTYPE_ORIGADDR  |
     +-------+---------------+-----------------+--------------------+

8.2.4.2.  Address Block TLVs for TargAddr
















Perkins, et al.         Expires October 22, 2016               [Page 55]

Internet-Draft                   AODVv2                       April 2016


   +--------------+---------------+------------+-----------------------+
   | Data         | TLV Type      | Extension  | Value                 |
   |              |               | Type       |                       |
   +--------------+---------------+------------+-----------------------+
   | None         | ADDRESS_TYPE  | 0          | ADDRTYPE_TARGADDR     |
   | TargSeqNum   | SEQ_NUM       | 0          | Sequence number of    |
   |              |               |            | RREP_Gen, the router  |
   |              |               |            | which created the     |
   |              |               |            | RREP.                 |
   | TargMetric   | PATH_METRIC   | MetricType | Metric value for the  |
   | /MetricType  |               |            | route to TargAddr,    |
   |              |               |            | using MetricType.     |
   | ValidityTime | VALIDITY_TIME | 0          | ValidityTime for      |
   |              |               |            | route to TargAddr,    |
   |              |               |            | represented as        |
   |              |               |            | detailed in           |
   |              |               |            | [RFC5497].            |
   +--------------+---------------+------------+-----------------------+

8.2.4.3.  Address Block TLVs for AckReq Intended Recipient Address

      +-------+---------------+-----------------+------------------+
      | Data  | TLV Type      | Extension Type  | Value            |
      +-------+---------------+-----------------+------------------+
      | None  | ADDRESS_TYPE  | 0               | ADDRTYPE_INTEND  |
UH> Where is ADDRTYPE_INTEND defined? I couldn't find it anywhere else
in the draft.
      +-------+---------------+-----------------+------------------+

8.3.  Route Reply Acknowledgement Message Representation

8.3.1.  Message Header

                   +-------+---------------+-----------+
                   | Data  | Header Field  | Value     |
                   +-------+---------------+-----------+
                   | None  |     | RREP_Ack  |
                   +-------+---------------+-----------+

8.3.2.  Message TLV Block

   AODVv2 does not define any Message TLVs for an RREP_ack message.

8.3.3.  Address Block

   AODVv2 does not define an Address Block for an RREP_Ack message.
UH> Is it RREP_Ack or RREP_ack? (as in section 8.3.2).







Perkins, et al.         Expires October 22, 2016               [Page 56]

Internet-Draft                   AODVv2                       April 2016


8.3.4.  Address Block TLV Block

   AODVv2 does not define any Address Block TLVs for an RREP_Ack
   message.

8.4.  Route Error Message Representation

   Route Error Messages MAY be split into multiple [RFC5444] messages
   when the desired contents would exceed the MTU.

UH> Are there any special considerations how to split it into multiple RERRs?
UH> This is the only place in the document I can find something about
MTU. Are no other messages (and grouping of messages into packets)
affected by the MTU?

   However, all of the
   resulting messages MUST have the same message header as described
   below.  If PktSource is included in the AODVv2 message, it MUST be
   included in all of the resulting [RFC5444] messages.

8.4.1.  Message Header

                    +-------+---------------+--------+
                    | Data  | Header Field  | Value  |
                    +-------+---------------+--------+
                    | None  |     | RERR   |
                    +-------+---------------+--------+

8.4.2.  Message TLV Block

   AODVv2 does not define any Message TLVs for an RERR message.

8.4.3.  Address Block

   The Address Block in an RERR MAY contain PktSource, the source
UH> "The Address Block" -- there can always be multiple address blocks
in a message

   address of the IP packet triggering RERR generation, as detailed in
   Section 7.4.  The prefix length associated with PktSource is equal to
   the address length in bits.

   Address Block always contains one address per route that is no longer
   valid, and each address has an associated prefix length.  If a prefix
   length has not been included for this address, it is equal to the
   address length in bits.

   +------------------------------+------------------------------------+
   | Data                         | Address Block                      |
   +------------------------------+------------------------------------+
   | PktSource                    | 
 +  for    |
   |                              | PktSource                          |
   | AddressList/PrefixLengthList | 
 +  for    |
   |                              | each unreachable address in        |
   |                              | AddressList                        |
   +------------------------------+------------------------------------+





Perkins, et al.         Expires October 22, 2016               [Page 57]

Internet-Draft                   AODVv2                       April 2016


8.4.4.  Address Block TLV Block

   Address Block TLVs are always associated with one or more addresses
   in the Address Block.  The following sections show the TLVs that
   apply to each type of address in the RERR.

8.4.4.1.  Address Block TLVs for PktSource

   +------------+---------------+----------------+---------------------+
   | Data       | TLV Type      | Extension Type | Value               |
   +------------+---------------+----------------+---------------------+
   | PktSource  | ADDRESS_TYPE  | 0              | ADDRTYPE_PKTSOURCE  |
UH> Where is ADDRTYPE_PKTSOURCE defined? (I don't find the term
anywhere else in the draft)
   +------------+---------------+----------------+---------------------+

8.4.4.2.  Address Block TLVs for Unreachable Addresses

   +----------------+--------------+------------+----------------------+
   | Data           | TLV Type     | Extension  | Value                |
   |                |              | Type       |                      |
   +----------------+--------------+------------+----------------------+
   | None           | ADDRESS_TYPE | 0          | ADDRTYPE_UNREACHABLE |
UH> Where is ADDRTYPE_UNREACHABLE defined?
   | SeqNumList     | SEQ_NUM      | 0          | Sequence number      |
   |                |              |            | associated with      |
   |                |              |            | invalid route to the |
   |                |              |            | unreachable address. |
   | MetricTypeList | PATH_METRIC  | MetricType | None. Extension Type |
   |                |              |            | set to MetricType of |
   |                |              |            | the route to the     |
   |                |              |            | unreachable address. |
   +----------------+--------------+------------+----------------------+

9.  Simple External Network Attachment

   Figure 4 shows a stub (i.e., non-transit) network of AODVv2 routers
   which is attached to an external network via a single External
   Network Access Router (ENAR).  The interface to the external network
   MUST NOT be configured in the InterfaceSet.

   As in any externally-attached network, AODVv2 routers and Router
   Clients that wish to be reachable from the external network MUST have
   IP addresses within the ENAR's routable and topologically correct
   prefix (e.g., 191.0.2.0/24 in Figure 4).  This AODVv2 network and
   networks attached to routers within it will be advertised to the
   external network using procedures which are out of scope for this
   specification.






Perkins, et al.         Expires October 22, 2016               [Page 58]

Internet-Draft                   AODVv2                       April 2016


       /-------------------------\
      / +----------------+        \
     /  |  AODVv2 Router |         \
     |  |  191.0.2.2/32  |         |
     |  +----------------+         |            Routable
     |                       +-----+--------+   Prefix
     |                       |     ENAR     |  /191.0.2.0/24
     |                       | AODVv2 Router| /
     |                       |  191.0.2.1   |/      /---------------\
     |                       | serving net  +------+    External     \
     |                       | 191.0.2.0/24 |      \     Network     /
     |                       +-----+--------+       \---------------/
     |         +----------------+  |
     |         |  AODVv2 Router |  |
     |         |  191.0.2.3/32  |  |
     \         +----------------+  /
      \                           /
       \-------------------------/

           Figure 4: Simple External Network Attachment Example

   When an AODVv2 router within the AODVv2 MANET wants to discover a
   route toward an address on the external network, it uses the normal
   AODVv2 route discovery for that IP Destination Address.  The ENAR
   MUST respond to RREQ on behalf of all external network destinations,
   e.g., destinations not on the configured 191.0.2.0/24 network.  RREQs
   for addresses inside the AODVv2 network, e.g. destinations on the
   configured 191.0.2.0/24 network, are handled using the standard
   processes described in Section 7.  Note that AODvv2 does not support
   RREQs for prefixes that do not equal address length.

   When an IP packet from an address on the external network destined
   for an address in the AODVv2 MANET reaches the ENAR, if the ENAR does
   not have a route toward that destination in its Routing Information
   Base, it will perform normal AODVv2 route discovery for that
   destination.

   Configuring the ENAR as a default router is outside the scope of this
   specification.

10.  Configuration

   AODVv2 uses various parameters which can be grouped into the
   following categories:

   o  Timers

   o  Protocol constants



Perkins, et al.         Expires October 22, 2016               [Page 59]

Internet-Draft                   AODVv2                       April 2016


   o  Administrative parameters and controls

   This section show the parameters along with their definitions and
   default values (if any).

   Note that several fields have limited size (bits or bytes).  These
   sizes and their encoding may place specific limitations on the values
   that can be set.

10.1.  Timers

   AODVv2 requires certain timing information to be associated with
   Local Route Set entries and message replies.  The default values are
   as follows:

                +------------------------+----------------+
                | Name                   | Default Value  |
                +------------------------+----------------+
                | ACTIVE_INTERVAL        | 5 second       |
                | MAX_IDLETIME           | 200 seconds    |
                | MAX_BLACKLIST_TIME     | 200 seconds    |
                | MAX_SEQNUM_LIFETIME    | 300 seconds    |
                | RERR_TIMEOUT           | 3 seconds      |
                | RteMsg_ENTRY_TIME      | 12 seconds     |
                | RREQ_WAIT_TIME         | 2 seconds      |
                | RREP_Ack_SENT_TIMEOUT  | 1 second       |
                | RREQ_HOLDDOWN_TIME     | 10 seconds     |
                +------------------------+----------------+

                     Table 2: Timing Parameter Values

   The above timing parameter values have worked well for small and
   medium well-connected networks with moderate topology changes.  The
   timing parameters SHOULD be administratively configurable.  Ideally,
   for networks with frequent topology changes the AODVv2 parameters
   SHOULD be adjusted using experimentally determined values or dynamic
   adaptation.
UH> Are there any constraints for these parameters (such as in
OLSRv2), like minimum values, maximum values, and constraints when
changing the values during run-time?


    For example, in networks with infrequent topology
   changes MAX_IDLETIME MAY be set to a much larger value.  If the
   values were configured differently, the following consequences may be
   observed:

   o  If MAX_SEQNUM_LIFETIME was configured differently across the
      network, and any of the routers lost their sequence number or
      rebooted, this could result in their next route messages being
      classified as stale at any AODVv2 router using a greater value for
      MAX_SEQNUM_LIFETIME.  This would delay route discovery from and to
      the re-initializing router.




Perkins, et al.         Expires October 22, 2016               [Page 60]

Internet-Draft                   AODVv2                       April 2016


   o  Routers with lower values for ACTIVE_INTERVAL + MAX_IDLETIME will
      invalidate routes more quickly and free resources used to maintain
      them.  This can affect bursty traffic flows which have quiet
      periods longer than ACTIVE_INTERVAL + MAX_IDLETIME.  A route which
      has timed out due to perceived inactivity is not reported.  When
      the bursty traffic resumes, it would cause a RERR to be generated,
      and the traffic itself would be dropped.  This route would be
      removed from all upstream routers, even if those upstream routers
      had larger ACTIVE_INTERVAL or MAX_IDLETIME values.  A new route
      discovery would be required to re-establish the route, causing
      extra routing protocol traffic and disturbance to the bursty
      traffic.

   o  Routers with lower values for MAX_BLACKLIST_TIME would allow
      neighboring routers to participate in route discovery sooner than
      routers with higher values.  This could result in failed route
      discoveries if un-blacklisted links are still uni-directional.
      Since RREQs are retried, this would not affect success of route
      discovery unless this value was so small as to un-blacklist the
      router before the RREQ is retried.  This value need not be
      consistent across the network since it is used for maintaining a
      1-hop blacklist.  However it MUST be greater than RREQ_WAIT_TIME.

   o  Routers with lower values for RERR_TIMEOUT may create more RERR
      messages than routers with higher values.  This value should be
      large enough that a RERR will reach all routers using the route
      reported within it before the timer expires, so that no further
      data traffic will arrive, and no duplicated RERR messages will be
      generated.

   o  Routers with lower values for RteMsg_ENTRY_TIME may not consider
      received redundant multicast route messages as redundant, and may
      regenerate these messages unnecessarily.

   o  Routers with lower values for RREQ_WAIT_TIME may send more
      frequent RREQ messages and wrongly determine that a route does not
      exist, if the delay in receiving an RREP is greater than this
      interval.

   o  Routers with lower values for RREP_Ack_SENT_TIMEOUT may wrongly
      determine links to neighbors to be unidirectional if an RREP_Ack
      is delayed longer than this timeout.

   o  Routers with lower values for RREQ_HOLDDOWN_TIME will retry failed
      route discoveries sooner than routers with higher values.  This
      may be an advantage if the network topology is frequently
      changing, or may unnecessarily cause more routing protocol
      traffic.



Perkins, et al.         Expires October 22, 2016               [Page 61]

Internet-Draft                   AODVv2                       April 2016


   MAX_SEQNUM_LIFETIME MUST be configured to have the same values for
   all AODVv2 routers in the network.

10.2.  Protocol Constants

   AODVv2 protocol constants typically do not require changes.  The
   following table lists these constants, along with their values and a
   reference to the section describing their use.

   +------------------------+---------+--------------------------------+
   | Name                   | Default | Description                    |
   +------------------------+---------+--------------------------------+
   | DISCOVERY_ATTEMPTS_MAX | 3       | Section 6.6                    |
   | RREP_RETRIES           | 2       | Section 7.2.1                  |
   | MAX_METRIC[MetricType] | [TBD]   | Section 5                      |
   | MAX_METRIC[HopCount]   | 255     | Section 5 and Section 7        |
   | INFINITY_TIME          | [TBD]   | Maximum expressible clock time |
   |                        |         | (Section 6.7.2)                |
   | C                      | 1/1024  | Constant used in validity time |
   |                        |         | calculation [RFC5497]          |
   +------------------------+---------+--------------------------------+

UH> Does IANA associate the values for TBD? Is it instructed to do so?
This table is not in an IANA section.

                         Table 3: AODVv2 Constants

   MAX_METRIC[MetricType] MUST always be the maximum expressible metric
   value of type MetricType.  Field lengths associated with metric
   values are found in Section 10.5.

   These protocol constants MUST have the same values for all AODVv2
   routers in the ad hoc network.  If the values were configured
   differently, the following consequences may be observed:

   o  DISCOVERY_ATTEMPTS_MAX: Routers with higher values are likely to
      be more successful at finding routes, at the cost of additional
      control traffic.

   o  RREP_RETRIES: Routers with lower values are more likely to
      blacklist neighbors when there is a temporary fluctuation in link
      quality.

   o  MAX_METRIC[MetricType]: No interoperability problems due to
      variations on different routers, but routers with lower values may
      exhibit overly restrictive behavior during route comparisons.

   o  INFINITY_TIME: No interoperability problems due to variations on
      different routers, but if a lower value is used, route state
      management may exhibit overly restrictive behavior.




Perkins, et al.         Expires October 22, 2016               [Page 62]

Internet-Draft                   AODVv2                       April 2016


   o  C: Routers with lower values will invalidate timed routes before
      routers with higher values, which will cause Route Error messages
      to be generated and the route will effectively take on the shorter
      validity time.

10.3.  Local Settings

   The following table lists AODVv2 parameters which SHOULD be
   administratively configured for each router:
UH> What happens if they are not? (since it's not a MUST)

    +------------------------+------------------------+--------------+
    | Name                   | Default Value          | Description  |
    +------------------------+------------------------+--------------+
    | InterfaceSet           |                        | Section 4.1  |
    | BUFFER_SIZE_PACKETS    | 2                      | Section 6.6  |
    | BUFFER_SIZE_BYTES      | MAX_PACKET_SIZE [TBD]  | Section 6.6  |
    | CONTROL_TRAFFIC_LIMIT  | [TBD - 50 pkts/sec?]   | Section 7    |
    +------------------------+------------------------+--------------+
UH> Why is InterfaceSet listed here? But not the other Sets?
UH> What are the TBD values? Are they assigned by IANA?

                 Table 4: Configuration for Local Settings

10.4.  Network-Wide Settings

   The following administrative controls MAY be used to change the
   operation of the network.  The same settings SHOULD be used across
   the network.  Inconsistent settings at different routers in the
   network will not result in protocol errors, but poor performance may
   result.

           +----------------------+-----------+----------------+
           | Name                 | Default   | Description    |
           +----------------------+-----------+----------------+
           | ENABLE_IDLE_IN_RERR  | Disabled  | Section 7.4.1  |
           +----------------------+-----------+----------------+

             Table 5: Configuration for Network-Wide Settings

10.5.  MetricType Allocation

   The metric types used by AODVv2 are identified according to a new
   table to be created and maintained by IANA.  All implementations MUST
   use these values.









Perkins, et al.         Expires October 22, 2016               [Page 63]

Internet-Draft                   AODVv2                       April 2016


          +---------------------+----------+--------------------+
          | Name of MetricType  | Type     | Metric Value Size  |
          +---------------------+----------+--------------------+
          | Unassigned          | 0        | Undefined          |
          | Hop Count           | 1        | 1 octet            |
          | Unallocated         | 2 - 254  | TBD                |
          | Reserved            | 255      | Undefined          |
          +---------------------+----------+--------------------+

                       Table 6: AODVv2 Metric Types
UH> Shouldn't this table also be listed in section 11, IANA
Considerations? I assume that you would like to request a registry?
UH> Can a router be configured to support more than one MetricType at a time?

11.  IANA Considerations

   This section specifies several [RFC5444] message types and address
   tlv-types required for AODVv2.

11.1.  RFC 5444 Message Types

   This specification defines four Message Types, to be allocated from
   the 0-223 range of the "Message Types" namespace defined in
   [RFC5444], as specified in Table 7.

          +-----------------------------------------+-----------+
          | Name of Message                         | Type      |
          +-----------------------------------------+-----------+
          | Route Request (RREQ)                    | 10 (TBD)  |
          | Route Reply (RREP)                      | 11 (TBD)  |
          | Route Error (RERR)                      | 12 (TBD)  |
          | Route Reply Acknowledgement (RREP_Ack)  | 13 (TBD)  |
          +-----------------------------------------+-----------+

                       Table 7: AODVv2 Message Types

11.2.  RFC 5444 Address Block TLV Types

   This specification defines three Address Block TLV Types, to be
   allocated from the "Address Block TLV Types" namespace defined in
   [RFC5444], as specified in Table 8.













Perkins, et al.         Expires October 22, 2016               [Page 64]

Internet-Draft                   AODVv2                       April 2016


   +------------------------+----------+---------------+---------------+
   | Name of TLV            | Type     | Length        | Reference     |
   |                        |          | (octets)      |               |
   +------------------------+----------+---------------+---------------+
   | PATH_METRIC            | 11 (TBD) | depends on    | Section 7     |
   |                        |          | MetricType    |               |
   | SEQ_NUM                | 12 (TBD) | 2             | Section 7     |
   | ADDRESS_TYPE           | 13 (TBD) | 1             | Section 8     |
   +------------------------+----------+---------------+---------------+
UH> There was some discussion to move the TLV allocations to the
experimental range of RFC5444. Is that the plan for the next revision?

                  Table 8: AODVv2 Address Block TLV Types

11.3.  ADDRESS_TYPE TLV Values

   These values are used in the [RFC5444] Address Type TLV discussed in
   Section 8.  All implementations MUST use these values.

                        +---------------+--------+
                        | Address Type  | Value  |
                        +---------------+--------+
                        | ORIGADDR      | 0      |
                        | TARGADDR      | 1      |
                        | UNREACHABLE   | 2      |
                        | PKTSOURCE     | 3      |
                        | INTEND        | 4      |
                        | UNSPECIFIED   | 255    |
                        +---------------+--------+
UH> What about IDLE routes in RERR when ENABLE_IDLE_IN_RERR is set?
Which value is used for them?

                       Table 9: AODVv2 Address Types

12.  Security Considerations

   This section describes various security considerations and potential
   avenues to secure AODVv2 routing.  The main objective of the AODVv2
   protocol is for each router to communicate reachability information
   about addresses for which it is responsible, and for routes it has
   learned from other AODVv2 routers.

   Networks using AODVv2 to maintain connectivity and establish routes
   on demand may be vulnerable to certain well-known types of threats,
   which will be detailed in the following.  Some of the threats
   described can be mitigated or eliminated.  Tools to do so will be
   described also.

   Since route messages are regenerated at each router, AODVv2 assumes a
   security model of transitive trust.  The sender of a message MUST be
   trusted in order for receiving one-hop neighbours to store the




Perkins, et al.         Expires October 22, 2016               [Page 65]

Internet-Draft                   AODVv2                       April 2016


   routing information it provides and regenerate the message to their
   own one-hop neighbours.
UH> See discussion on MANET list; providing end-to-end integrity would
be much better.

   Routes are installed based on information received from trusted
   neighbours.  Therefore a chain of trust back to the originator of a
   message is assumed by any router using the routing information
   received.

   Since messages are regenerated rather than forwarded, the message
   concepts known as RREQ, RREP and RERR do not travel as a single
   unchanged entity between source and destination, and therefore
   message integrity cannot be assured end-to-end between OrigAddr and
   TargAddr.

   The on-demand nature of AODVv2 route discovery automatically reduces
   the vulnerability to route disruption.  Since control traffic for
   updating route tables is diminished, there is less opportunity for
   attack and failure.
UH> How so?

12.1.  Availability

   Threats to AODVv2 which reduce availability are considered below.

12.1.1.  Denial of Service

   Flooding attacks using RREQ amount to a (BLIND)
UH> What's "BLIND"? (in upper case)

    denial of service for
   route discovery: By issuing RREQ messages for targets that don't
   exist, an attacker can flood the network, blocking resources and
   drowning out legitimate traffic.  The effect of this attack is
   dampened by the fact that duplicate RREQ messages are dropped
   (preventing the network from DDoSing itself).  Processing
   requirements for AODVv2 messages are typically quite small, however
   AODVv2 routers receiving RREQs do allocate resources in the form of
   Neighbor Set, Local Route Set and Multicast Route Message Set
   entries.  The attacker can maximize their impact on set growth by
   changing OrigAddr for each RREQ.  If a specific node is to be
   targeted, this attack may be carried out in a DISTRIBUTED fashion,
UH> Why capital DISTRIBUTED?
   either by compromising its direct neighbors or by specifying the
   target's address as TargAddr.  Note that it might be more economical
   for the attacker to simply jam the medium; an attack which AODVv2
   cannot defend itself against.
UH> I disagree. Jamming the medium is local; flooding affects the whole network.

   Mitigation:

   o  If AODVv2 routers always verify that the sender of the RERR
      message is trusted, this threat is reduced.  Processing
      requirements would typically be dominated by calculations to
      verify integrity.  This has the effect of reducing (but by no



Perkins, et al.         Expires October 22, 2016               [Page 66]

Internet-Draft                   AODVv2                       April 2016


      means eliminating) AODVv2's vulnerability to denial of service
      attacks.

   o  Authentication of senders can prevent foreign nodes from DoSing a
UH> What's a foreign node?
UH> What's "DoSing"?
      AODVv2 router.  However, this does not protect the network if an
      attacker has access to an already authorized router.
UH> Definition of "aleady authorized router"?

12.1.2.  Malicious RERR messages
UH> What's a "Malicious" message?

   RERR messages are designed to cause removal of installed routes.  A
   malicious node could send an RERR message with false information to
   attempt to get other routers to remove a route to one or more
   specific destinations, therefore disrupting traffic to the advertised
   destinations.

   Routes will be deleted if an RERR is received, withdrawing a route
   for which the sender is the receiver's next hop, and when the RERR
   includes the MetricType of the installed route, and includes either
   no sequence number for the route, or includes a greater sequence
   number than the sequence number stored with that route in the
   receiver's Local Route Set. Routes will also be deleted if a received
   RERR contains a PktSource address corresponding to a Router Client.

   The information necessary to construct a malicious RERR could be
   learned by eavesdropping, either by listening to AODVv2 messages or
   by watching data packet flows.

   Since the RERR is multicast,
 UH> Not always. There are also unicast RERRs.

    it can be received by many routers in
   the ad hoc network, and will be regenerated when processing results
   in an active route being removed.  This threat could have serious
   impact on applications communicating by way of the sender of the RERR
   message.

   o  The set of routers which use the malicious router as a next hop
      may be targeted with a malicious RERR with no PktSource address
      included, if the RERR contains routes for which the malicious
      router is a next hop from the receiving router.  However, since
      the sender of the RERR message is either malicious or broken, it
      is better that it is not used as a next hop for these routes
      anyway.

   o  A single router which does not use the malicious router as part of
      its route may be targeted with a malicious RERR with a PktSource
      address included.

   o  Replayed RERR messages could be used to disrupt active routes.

   Mitigation:



Perkins, et al.         Expires October 22, 2016               [Page 67]

Internet-Draft                   AODVv2                       April 2016


   o  Protection against eavesdropping of AODVv2 messages would mitigate
      this attack to some extent, but eavesdropping of data packets can
      also be used to deduce the information about which routes could be
      targeted.
UH> Where is this specified?

   o  Protection against a malicious router becoming part of a route
      will mitigate the attack where a set of routers are targeted.
      This will not protect against the attack if a PktSource address is
      included.

   o  By only regenerating RERR messages where active routes are
      removed, the spread of the malicious RERR is limited.
UH> Can you explain why?

   o  Including sequence numbers in RERR messages offers protection
      against attacks using replays of these RERR messages.

   o  If AODVv2 routers always verify that the sender of the RERR
      message is trusted, this threat is reduced.
UH> But AODVv2 doesn't provide end-to-end trust.

12.1.3.  False Confirmation of Link Bidirectionality

   Links could be erroneously treated as bidirectional if malicious
   unsolicited or spoofed RREP messages were to be accepted.
UH> What are "malicious unsolicited or spoofed RREP messages"?

   This would
   result in a route being installed which could not in fact be used to
   forward data to the destination, and may divert data packets away
   from the intended destination.

   There is a window of RREQ_WAIT_TIME after an RREQ is sent, in which
   any malicious router could send an RREP in response, in order for the
   link to the malicious router to be deemed as bidirectional.

   Mitigation:

   o  Ignoring unsolicited RREP and RREP_Ack messages partially
      mitigates against this threat.
UH> In which section is the process of "ignoring unsolicitated RREP
and RREP_ACKs" defined?

   o  If AODVv2 routers always verify that the sender of the RERR
      message is trusted, this threat is reduced.
UH> There is no end-to-end trust in AODVv2.

12.1.4.  Message Deletion

   A malicious router could decide not to regenerate a RREQ or RREP or
   RERR message.  Not regenerating a RERR or RREP message would disrupt
   route discovery.  Not regenerating a RERR message would result in the
   source of data packets continuing to maintain and use the route, and
   further RERR messages being generated by the sender of the non-
   regenerated RERR.  A malicious router could intentionally disrupt




Perkins, et al.         Expires October 22, 2016               [Page 68]

Internet-Draft                   AODVv2                       April 2016


   traffic flows by not allowing the source of data traffic to re-
   discover a new route when one breaks.

   Failing to send a RREP_Ack would also disrupt route establishment, by
   not allowing the reverse route to be validated.  Return traffic which
   needs that route will prompt a new route discovery, wasting resources
   and incurring a slight delay but not disrupting the ability for
   applications to communicate.

   Mitigation:

   o  None. also note that malicious router would have to wait for a
      route to break before it could perform this attack.

12.2.  Confidentiality

   Passive inspection (eavesdropping) of AODVv2 control messages could
   enable unauthorized devices to gain information about the network
   topology, since exchanging such information is the main purpose of
   AODVv2.

   Eavesdropping of data traffic could allow a malicious device to
   obtain information about how data traffic is being routed.  With
   knowledge of source and destination addresses, malicious messages
   could be constructed to disrupt normal operation.
UH> I don't understand the last sentence. What's a malicious message?
How could it be used to disrupt "normal" operation?
UH> Is there any mitigation in AODVv2 for this threat?

12.3.  Integrity

   Integrity of route information can be compromised in the following
   types of attack:

12.3.1.  Message Insertion

   Valid route set entries can be replaced or modified by maliciously
   constructed AODVv2 messages, destroying existing routes and the
   network's integrity.
UH> What do you mean by "destroying" a route, and by "destroying" the
network's integrity?

    Any router may pose as another router by
   sending RREQ, RREP, RREP_Ack and RERR messages in its name.
UH> What do you mean by "in its name"?

   o  Sending an RREQ message with false information can disrupt traffic
      to OrigAddr, if the sequence number attached is not stale compared
      to any existing information about OrigAddr.  Since RREQ is
      multicast and likely to be received by all routers in the ad hoc
      network, this threat could have serious impact on applications
      communicating with OrigAddr.  The actual threat to disrupt routes
      to OrigAddr is reduced by the AODVv2 mechanism of marking RREQ-
      derived routes as "Unconfirmed" until the link to the next hop is
      confirmed.
UH> But still the flooding damage is done.




Perkins, et al.         Expires October 22, 2016               [Page 69]

Internet-Draft                   AODVv2                       April 2016


   o  Sending an RREP message with false information can disrupt traffic
      to TargAddr.  Since RREP is unicast,
UH> You also support multicast RREPs.

       and ignored if a
      corresponding RREQ was not recently sent, this threat is
      minimized, and is restricted to receivers along the path from
      OrigAddr to TargAddr.

   o  Sending an RREP_Ack message with false information can cause the
      route advertised to a target address in an RREP to be erroneously
      accepted even though the route would contain a unidirectional link
      and thus not be suitable for most traffic.  Since RREP_Ack is
      unicast, and ignored if a RREP was not sent recently to the sender
      of the RREP_Ack, this threat is minimized and is strictly local to
      the RREP transmitter expecting the acknowledgement.  Unsolicited
      RREP_Acks are ignored.

   o  Sending an RERR message with false information is discussed in
      Section 12.1.2.

   Mitigation: * If AODVv2 routers always verify that the sender of a
   message is trusted, this threat is reduced.
UH> That is not possible in AODVv2, since end-to-end integrity isn't supported

12.3.2.  Message Modification - Man in the Middle

   Any AODVv2 router can regenerate messages with modified data.

   Mitigation:

   o  If AODVv2 routers verify the integrity of AODVv2 messages, then
      the threat of disruption is minimized.  A man in the middle with
      no knowledge of the shared secret key used to calculate an
      integrity check value MAY modify a message but the message will be
      rejected when it fails an integrity check.
UH> Is shared secret the only option? What about asymmetric keys?
UH> MAY? or may?

12.3.3.  Replay Attacks

   Replaying of RREQ or RREP messages would be of less use to an
   attacker, since they would be dropped immediately due to their stale
   sequence number.  RERR messages MAY or MAY NOT include sequence
UH> RFC2119 seems inappropriate here for "MAY or MAY NOT".

   numbers and are therefore susceptible to replay attacks.  RREP_Ack
   messages do not include sequence numbers and are therefore
   susceptible to replay attacks.

   Mitigation:

   o  Use of timestamps or sequence numbers prevents replay attacks.
UH> Do RREP_Ack messages contain sequence numbers then? I wasn't able
to tell from section 8.3.






Perkins, et al.         Expires October 22, 2016               [Page 70]

Internet-Draft                   AODVv2                       April 2016


12.4.  Protection Mechanisms

12.4.1.  Confidentiality and Authentication

   Encryption MAY be used for AODVv2 messages.  If the routers share a
   packet-level security association, the message data can be encrypted
   prior to message transmission.
UH> Since this is not specified in this document, I would not mention
encryption here (or say that it's out of scope of this document).

   The establishment of such security
   associations is outside the scope of this specification.  Encryption
   will not only protect against unauthorized devices obtaining
   information about network topology (eavesdropping) but will ensure
   that only trusted routers participate in routing operations.

12.4.2.  Integrity and Trust using ICVs

   Cryptographic Integrity Check Values (ICVs) can be used to ensure
   integrity of received messages, protecting against man in the middle
   attacks.  Further, by using ICVs, only those routers with knowledge
   of a shared secret key are allowed to participate in routing
   information exchanges.
UH> Shared secret is just one option. Deployments could also use
asymmetric keys. Can implementations of AODVv2 choose different
security mechanisms?

    [RFC7182] defines ICV TLVs for use with
   [RFC5444].

   The data contained in AODVv2 routing protocol messages MUST be
   verified using Integrity Check Values, to avoid the use of message
   data if the message has been tampered with.

   The method of distribution of shared secret keys is out of the scope
   of this protocol.  Key management is not specified for the following
   reasons:
UH> Looks like there is some text missing here
UH> See BCP107

12.4.3.  Replay Protection using Timestamps

   Replay attacks MUST be prevented by using timestamps or sequence
   numbers in messages.  [RFC7182] defines a TIMESTAMP TLV for use with
   [RFC5444].

   The data contained in AODVv2 routing protocol messages MUST be
   protected with a TIMESTAMP value to ensure the protection against
   replaying of the message.  Sequence numbers can be used as
   timestamps, since they are known to be strictly increasing.

12.4.4.  Application to AODVv2

   Implementations of AODVv2 MUST support ICV TLVs using type-extensions
   1 and 2, hash-function HASH_FUNCTION, and cryptographic function
   CRYPTOGRAPHIC_FUNCTION.  An ICV MUST be included with every message.
   The ICV value MAY be truncated as specified in [RFC7182].
UH> Which hash-function / which crypto function is used?





Perkins, et al.         Expires October 22, 2016               [Page 71]

Internet-Draft                   AODVv2                       April 2016


   Implementations of AODVv2 MUST support a TIMESTAMP TLV using type-
   extension 0.
   The timestamp used is a sequence number, and therefore
   the length of the 
UH> What is the notation for ? That syntax is not
explained in this draft nor RFC5444.

    field matches the AODVv2 sequence
   number defined in Section 4.4.  The TIMESTAMP TLV MUST be included in
   RREP_Ack and RERR messages.

   When more than one message is included in an RFC5444 packet, using a
   single ICV Packet TLV or single TIMESTAMP Packet TLV is more
   efficient than including ICV and TIMESTAMP Message TLVs in each
   message created.  In this case, the RFC5444 multiplexer MUST be
   instructed to include the Packet TLVs in packets containing AODVv2
   messages, or MUST be selected because it always performs these
   additions.  If the multiplexer is not capable of adding the Packet
   TLVs, the TLVs MUST be included as Message TLVs in each AODVv2
   message in the packet.

   After message generation but before transmission, the ICV and
   TIMESTAMP TLVs MUST be added according to each message type as
   detailed in the following sections.
UH> Unless they are added to the packet instead, as described in the
previous paragraph. When do you know whether to add to the message or
to the packet? Say, you first create a message, add ICV and timestamp;
then a second message is added to the package, does the multiplexer
now have to remove the ICV and timestamp from the first message again
and then add these TLVs to the package?

    The following steps list the
   generic procedure to be performed:
UH> "generic"? Are there exceptions to this list?

   1.  The considerations in Section 8 of [RFC7182] are followed,
       removing existing ICV TLVs and adjusting the size and flags
       fields.
UH> Section 8 in RFC7182 only applies to packets. What about messages?

   2.  The ICV is calculated over the fields specified below, depending
       on message type.  This value MAY be truncated (as specified in
       [RFC7182]).
UH> Where, below? I don't see a list of fields.

   3.  If the TIMESTAMP is to be included, add the TIMESTAMP TLV,
       updating size fields as necessary.
UH> How do I know whether it's to be included?

   4.  Add the ICV TLV, updating size fields as necessary.

   5.  The changes made in Step 1 are reversed to re-add any existing
       ICV TLVs and adjusting the size and flags fields.
UH> If this is for message generation, how comes there are already ICV
TLVs in there? (since messages are "regenerated" and not forwarded)

   The ICV MUST be verified at the receiver.  Verification of a received
   ICV value is performed by repeating Step 1 and Step 2.
UH> Specifying verification one sentence after generation may be
confusing. I would recommend to split verification and generation in
separate sections.

   If the ICV
   value calculated from the received message or packet does not match
   the value of  in the received message or packet, the
   validation fails and the AODVv2 message MUST be discarded.
UH> It would be clearer to split verification of messages and packets
into different sections.

   Verification of a received TIMESTAMP value is performed differently
   depending on message type.
UH> + "as specified in the following sub sections:"






Perkins, et al.         Expires October 22, 2016               [Page 72]

Internet-Draft                   AODVv2                       April 2016


12.4.4.1.  RREQ Generation and Reception

   Since OrigAddr is included in the RREQ, the ICV can be calculated and
   verified using all of the message contents.  This provides message
   integrity and endpoint authentication,
UH> not really endpoint, since you only use hop-by-hop

    because trusted routers MUST
   hold the shared key in order to calculate the ICV value.  The ICV TLV
   has type extension := 1.

   Since RREQ_Gen's sequence number is incremented for each new RREQ,
   replay protection is already afforded and no extra timestamp
   mechanism is required.

12.4.4.2.  RREP Generation and Reception

   Since TargAddr is included in the RREP, the ICV can be calculated and
   verified using all of the message contents.  This provides message
   integrity and endpoint authentication, because trusted routers MUST
   hold the shared key in order to calculate the ICV value.  The ICV TLV
   has type extension := 1.

   Since RREP_Gen's sequence number is incremented for each new RREP,
   replay protection is afforded and no extra timestamp mechanism is
   required.

12.4.4.3.  RREP_Ack Generation and Reception

   The RREP_Gen uses the source IP address of the RREP_Ack to identify
   the sender to look up whether the RREP_Ack is expected and update the
   Neighbor Set, and so the ICV MUST be calculated using the message
   contents and the IP source address.  The ICV TLV has type extension
   := 2 in order to accomplish this.  This provides message integrity
   and endpoint authentication, because trusted routers MUST hold the
   shared key in order to calculate the ICV value.

   The message MUST also include a timestamp to protect against replay
   attacks, using TargSeqNum from the RREP as the value in the TIMESTAMP
   TLV.
UH> Bullet points and separation of generation and reception would be
clearer (e.g., spell out that TIMESTAMP TLV must be added *before*
adding the ICV TLV)

   Verification of a received TIMESTAMP value is performed by
   comparing the sequence number in the  field with the
   sequence number in a recently sent RREP awaiting acknowledgement from
   the sender of the RREP_Ack.  If the sequence number is not equal, the
   AODVv2 message MUST be discarded.

12.4.4.4.  RERR Generation and Reception

   The receiver of the RERR MUST use the source IP address of the RERR
   to identify the sender to look up routes using that sender as next
   hop, and so the ICV MUST be calculated using the message contents and
   the IP source address.  The ICV TLV has type extension := 2 in order



Perkins, et al.         Expires October 22, 2016               [Page 73]

Internet-Draft                   AODVv2                       April 2016


   to accomplish this.  This provides message integrity and endpoint
   authentication, because trusted routers MUST hold the shared key in
   order to calculate the ICV value.

   The message MUST also include a timestamp to protect against replay
   attacks, incrementing and using RERR_Gen's sequence number as the
   value in the TIMESTAMP TLV.  Verification of a received TIMESTAMP
   value is performed by comparing the sequence number in the
    field with the last seen sequence number from the
   sender of the RERR.  If the sequence number is not greater, the
   AODVv2 message MUST be discarded.

UH> Can I add multiple ICV/TIMESTAMP TLVs in a message?
UH> Is truncation of ICV TLVs allowed (see RFC7183)?


13.  Acknowledgments

   AODVv2 is a descendant of the design of previous MANET on-demand
   protocols, especially AODV [RFC3561] and DSR [RFC4728].  Changes to
   previous MANET on-demand protocols stem from research and
   implementation experiences.  Thanks to Elizabeth Belding and Ian
   Chakeres for their long time authorship of AODV.  Additional thanks
   to Derek Atkins, Emmanuel Baccelli, Abdussalam Baryun, Ramon Caceres,
   Thomas Clausen, Justin Dean, Christopher Dearlove, Fatemeh Ghassemi,
   Ulrich Herberg, Henner Jakob, Ramtin Khosravi, Luke Klein-Berndt,
   Lars Kristensen, Tronje Krop, Koojana Kuladinithi, Kedar Namjoshi,
   Keyur Patel, Alexandru Petrescu, Henning Rogge, Fransisco Ros, Pedro
   Ruiz, Christoph Sommer, Romain Thouvenin, Richard Trefler, Jiazi Yi,
   Seung Yi, Behnaz Yousefi, and Cong Yuan, for their reviews of AODVv2
   and DYMO, as well as numerous specification suggestions.

14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              .

   [RFC3561]  Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
              Demand Distance Vector (AODV) Routing", RFC 3561,
              DOI 10.17487/RFC3561, July 2003,
              .

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, .
UH> This reference is orphaned.






Perkins, et al.         Expires October 22, 2016               [Page 74]

Internet-Draft                   AODVv2                       April 2016


   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
              Pignataro, "The Generalized TTL Security Mechanism
              (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
              .
UH> This reference is orphaned.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
              Format", RFC 5444, DOI 10.17487/RFC5444, February 2009,
              .

   [RFC5497]  Clausen, T. and C. Dearlove, "Representing Multi-Value
              Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
              DOI 10.17487/RFC5497, March 2009,
              .

   [RFC5498]  Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network
              (MANET) Protocols", RFC 5498, DOI 10.17487/RFC5498, March
              2009, .

   [RFC6551]  Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
              and D. Barthel, "Routing Metrics Used for Path Calculation
              in Low-Power and Lossy Networks", RFC 6551,
              DOI 10.17487/RFC6551, March 2012,
              .
UH> This reference is orphaned.

   [RFC7182]  Herberg, U., Clausen, T., and C. Dearlove, "Integrity
              Check Value and Timestamp TLV Definitions for Mobile Ad
              Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182,
              April 2014, .

14.2.  Informative References

   [I-D.perkins-irrep]
              Perkins, C., "Intermediate RREP for dynamic MANET On-
              demand (AODVv2) Routing", draft-perkins-irrep-03 (work in
              progress), May 2015.
UH> This reference is orphaned.

   [Koodli01]
              Koodli, R. and C. Perkins, "Fast handovers and context
              transfers in mobile networks", Proceedings of the ACM
              SIGCOMM Computer Communication Review 2001, Volume 31
              Issue 5, 37-47, October 2001.









Perkins, et al.         Expires October 22, 2016               [Page 75]

Internet-Draft                   AODVv2                       April 2016


   [Perkins94]
              Perkins, C. and P. Bhagwat, "Highly Dynamic Destination-
              Sequenced Distance-Vector Routing (DSDV) for Mobile
              Computers", Proceedings of the ACM SIGCOMM '94 Conference
              on Communications Architectures, Protocols and
              Applications, London, UK, pp. 234-244, August 1994.

   [Perkins99]
              Perkins, C. and E. Royer, "Ad hoc On-Demand Distance
              Vector (AODV) Routing", Proceedings of the 2nd IEEE
              Workshop on Mobile Computing Systems and Applications, New
              Orleans, LA, pp. 90-100, February 1999.
UH> This reference is orphaned.

   [RFC2501]  Corson, S. and J. Macker, "Mobile Ad hoc Networking
              (MANET): Routing Protocol Performance Issues and
              Evaluation Considerations", RFC 2501,
              DOI 10.17487/RFC2501, January 1999,
              .

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              .

   [RFC4728]  Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source
              Routing Protocol (DSR) for Mobile Ad Hoc Networks for
              IPv4", RFC 4728, DOI 10.17487/RFC4728, February 2007,
              .

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              .
UH> This reference is orphaned.

   [RFC5148]  Clausen, T., Dearlove, C., and B. Adamson, "Jitter
              Considerations in Mobile Ad Hoc Networks (MANETs)",
              RFC 5148, DOI 10.17487/RFC5148, February 2008,
              .
UH> This reference is orphaned.

   [RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, DOI 10.17487/RFC6130, April 2011,
              .

   [Sholander02]
              Sholander, P., Coccoli, P., Oakes, T., and S. Swank, "A
              Portable Software Implementation of a Hybrid MANET Routing
              Protocol", 2002.
UH> This reference is orphaned.




Perkins, et al.         Expires October 22, 2016               [Page 76]

Internet-Draft                   AODVv2                       April 2016


Appendix A.  AODVv2 Draft Updates

   This section lists the changes between AODVv2 revisions ...-14.txt
   and ...-15.txt.

   o  Shortened Terminology descriptions of Unreachable Address,
      Unreachable Route, Valid Route and add references to sections
      explaining the details.

   o  Clarified language regarding empty Message TLV Blocks and Address
      Blocks.

   o  Removed reference to RFC6551 from MetricType Allocation.

   o  Removed Message Aggregation Delay extension.

   o  Detailed what happens if the specified timers aren't the same
      across the network.

   o  RERRs SHOULD be MULTICAST instead of MUST (which enables precursor
      lists).

   o  RREP_Ack Reception: clarified wording regarding blacklist check.

   o  Removed "approaching the limit" verbiage.

   o  Added instructions on which messages to drop on congestion.

   o  Revised set vs. table wording

   o  Added note that AODVv2 was intended for use in mobile ad hoc
      wireless networks.

   o  Changed language to clarify that the RFC5444 multiplexer sends the
      messages, not AODVv2.

   o  Added instructions on how to use the Multicast Route Message Set
      to check whether an RREP_Ack or RREP was received in time.

   o  Removed optional features.

   o  Moved AODVv2 to the Experimental Track.

Authors' Addresses







Perkins, et al.         Expires October 22, 2016               [Page 77]

Internet-Draft                   AODVv2                       April 2016


   Charles E. Perkins
   Futurewei Inc.
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone: +1-408-330-4586
   Email: charliep@computer.org


   Stan Ratliff
   Idirect
   13861 Sunrise Valley Drive, Suite 300
   Herndon, VA  20171
   USA

   Email: ratliffstan@gmail.com


   John Dowdell
   Airbus Defence and Space
   Celtic Springs
   Newport, Wales  NP10 8FZ
   United Kingdom

   Email: john.dowdell@airbus.com


   Lotte Steenbrink
   HAW Hamburg, Dept. Informatik
   Berliner Tor 7
   D-20099 Hamburg
   Germany

   Email: lotte.steenbrink@haw-hamburg.de


   Victoria Mercieca
   Airbus Defence and Space
   Celtic Springs
   Newport, Wales  NP10 8FZ
   United Kingdom

   Email: victoria.mercieca@airbus.com







Perkins, et al.         Expires October 22, 2016               [Page 78]


<=
b>section 1, overview
Am =
16.03.2016 um 18:12 schrieb Lotte Steenbrink <lotte.steenbrink@fu-berlin.de>:

Hi Christopher,

Am 02.03.2016 um 11:36 schrieb =
Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>:

My concerns have been =
that your co-authors have continued to discuss whether looping could =
occur since you published to the list saying all was well. (An issue to =
do with multiple unconfirmed routes.) Maybe that=E2=80=99s a problem, =
maybe it isn=E2=80=99t. But it lacks transparency, because it hasn=E2=80=99=
t been discussed here.

The loop possibility =
you=E2=80=99re referring to was a different one than the one discussed =
by Charlie. We=E2=80=99ve been contacted by researchers who are model =
checking MANET protocols to see if they permit any unwanted behaviour. =
They=E2=80=99ve used AODVv2 as a case study for the framework they=E2=80=99=
ve implemented to do this, and they=E2=80=99ve found the following =
loop:

<network.jp=
g>

1. n2 initiates a route discovery procedure for =
destination n3 by broadcasting a =E2=80=9Crreq=E2=80=9D =
message.
2. n1 and n4 upon receiving the =E2=80=9Crreq=E2=
=80=9D message, add a route to their routing tables towards n2 and store =
n2 as their next hop. Since it is the first time that these nodes have =
received a message from n2, the neighbor state of n2 is set to =
unconfirmed. Therefore, the route state is unconfirmed.
3. As n1 and n4 are not the intended destination of the =
route request, they rebroadcast the =E2=80=9Crreq=E2=80=9D =
message.
4. n1 receives the =E2=80=9Crreq=E2=80=9D =
message sent by n4 and since the route to n2 is unconfirmed it adds n4 =
as new next hop to n2.
5. n4 also adds n1 as the new next hop towards n2 after =
processing the =E2=80=9Crreq=E2=80=9D sent by node1. At this point a =
loop is formed between n1 and n4 but not used yet.
6. n3 receives the =E2=80=9Crreq=E2=80=9D message sent =
by n1 and since it is the destination, it sends a =E2=80=9Crrep=E2=80=9D =
message towards n1.
7. n2 moves out of n1 and n4 communication =
range.
8. n1 receives the =E2=80=9Crrep=E2=80=9D message sent =
by n3 and as the route state towards n2 is unconfirmed it multicasts the =
=E2=80=9Crrep=E2=80=9D message to the existing next hops, n2 and n4. =
Since n4 is adjacent to n1, it receives the message and then sends an =
ack to n1. Therefore, n1 sets the neighbor state of n4 to confirm and =
subsequently the route state towards n2 to valid. Then expunge the next =
hop n2 which has not received an ack from.
9. n4 by receiving the =E2=80=9Crrep=E2=80=9D message =
from n1 multicasts it to its next hops towards n1 and n2,
and similar to n1 it updates its =
routing table by validating n1 as its next hop to n2. At this point, a =
loop between n1 and n4 becomes valid.



In response to these findings, =
we've changed 6.7.1.  Evaluating Route Information in =
-13, so that =
LoopFree() is *always* considered before adding a new route, even if all =
known routes to date are Unconfirmed.

Following up, they=E2=80=99ve =
found another loop in -13:

<network.jp=
g>

  1. At first nodes are connected to each other as shown in =
Fig1.a.
  2. n0 initiates a route discovery =
procedure for destination n3 by multicasting a =E2=80=9Crreq=E2=80=9D =
message to n2 with sq=3D2.
  3. n2 after updating its routing table, =
multicast the =E2=80=9Crreq=E2=80=9D to its neighbors, n1 and =
n3.
  4. n1 =
upon receiving the =E2=80=9Crreq=E2=80=9D message sent by n2 updates its =
routing table and adds a route with hop-count=3D2, sq=3D2 and =
next-hope=3D2
  5. Consider that topology changes at this =
point and n1 moves into communication range of n0, gets connected to n0, =
and n2 leaves n0 communication range, gets disconnected from n0, which =
leads to network topology shown in Fig1.b.
  6. n0, which hasn=E2=80=99t received an =
=E2=80=9Crrep=E2=80=9D yet, resend the =E2=80=9Crreq=E2=80=9D message =
after increasing its sequence number to 3.
  7. n1 receives the new =E2=80=9Crreq=E2=80=9D=
 message, with sq=3D3, next-hop=3D0 and hop-count=3D1, since it=E2=80=99s =
a better route it would be added to the routing table. Then n1 multicast =
the =E2=80=9Crreq=E2=80=9D message to its neighbors, n2 and =
n3.
  8. n2 =
evaluate the received message sent by n1 and adds a new route to its =
routing table with sq=3D3, next-hop=3D1 and hop-count=3D2 since the =
sequence number of the received message is greater than the stored =
one.
At this point a loop has =
been formed between nodes n1 and n2.


Since we=E2=80=99ve moved to disallowing =
multiple Unconfirmed routes (in -14, which isn=E2=80=99t published yet), =
this one is resolved already as well.


The reason we =
didn=E2=80=99t discuss this earlier on [manet] was that the authors =
hadn=E2=80=99t submitted their paper yet (and I didn=E2=80=99t want to =
leak their work). They=E2=80=99ve done so now, and will send us a link =
to their paper once it=E2=80=99s available. I=E2=80=99m guessing it=E2=80=99=
ll take a while to be published properly, but it should be enough for =
for our purposes for the paper to appear on arxiv.org for now=E2=80=A6

Best regards,
Lotte

 
--
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: Charlie Perkins [mailto:charles.perkins@earthlink.net] 
Sent: 01 =
March 2016 01:08
To: Dearlove, Christopher (UK); =
manet
Subject: Re: [manet] AODVv2 =
responses to recent comments
 
 
*** 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.
Hello Chris,
On 1/19/2016 5:37 AM, Dearlove, =
Christopher (UK) wrote:
And outside those 31, =
that we=E2=80=99re at this position with a suggestion there=E2=80=99s =
possible looping (about which I have no idea) isn=E2=80=99t that =
comforting.

I hope your concerns have =
been resolved on this matter.  The paper mentioned on the mailing =
list pointed out various ambiguities in RFC 3561 described how the =
ambiguities might be construed to install self-routes and, combined with =
possible inconsistent choices for sequence number, loops could =
result.  But the email to the list several weeks ago indicated that =
these ambiguities do not exist in AODVv2.  The authors of that =
paper have expressed interest in doing a similar analysis on AODVv2.

Other discussion about routing loops has not =
identified routing loop problems in the existing specification.  =
Use of unconfirmed or invalid routes for routing might lead to errors, =
but that doesn't carry over to produce loops in the route table.

I'm looking for any other open issues outside =
of the Security Considerations which is being reworked according to =
recent comments but should be submitted soon.

Regards,
Charlie P.



 
There=E2=80=99s also a lot of document to review. Which of =
course I haven=E2=80=99t done at this time. But my attention did alight =
on the IANA considerations section, and I noted there that:
- =
Not sure why the jump to 10 for message types, though I=E2=80=99m not =
opposed.
- The PATH_METRIC TLV can=E2=80=99t be type 10, that=E2=80=99s =
already taken. See IANA register.
- We previously pointed out that =
CONT_SEQ_NUM (COMPLETE) already exists and does the job that SEQ_NUM is =
doing, so why allocate another TLV? (You could avoid the necessity of =
repeating (COMPLETE) by simply commenting once and thereafter =
omitting.)
- Why the suggested skipping of types 12 to 14?
 
--
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 Victoria =
Mercieca
Sent: 18 January 2016 21:45
To: manet
Subject: [manet] AODVv2 responses to =
recent comments
 
 
*** =
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.
 
Hi all,
We have just released the newest AODVv2 draft. The =
major update is the separation of the AODVv2 route set from the RIB.

Here are also responses to the comments =
received before Christmas. This should include all the points from =
Thomas Clausen regarding versions 11 and 12, and also a couple of other =
points which have been brought up since. Apologies for the huge email. =
For issues that need further discussion, I have tried to include the =
main points of the discussion so far. Please feel free to create a =
separate thread for any further discussion.

We are still looking into the loop conditions recently =
reported for AODV, also still working on the text about security, and =
use of msg-hop-limit.
Kind regards,
Victoria.
 

1. End-to-end / =
hop-by-hop acks - issue when a route is marked as confirmed and valid =
when the link to the next hop is confirmed as bidirectional (but the =
links downstream have not yet been verified as bidirectional).

AODVv2: The authors believe this is an issue =
which would not occur frequently, and would right itself. 

This only occurs for the route to OrigAddr. What needs to =
happen for this to occur is that an intermediate node that takes part in =
the route discovery between OrigAddr and TargAddr coincidentally has =
packets to send to OrigAddr in the time between confirming the link to =
its own next hop toward OrigAddr is bidirectional, and the time taken =
for all other routers on the path to confirm their next hops too. If the =
route is used to forward packets before every other link in the path is =
confirmed as bidirectional, and the data packets are forwarded faster =
than the RREP and any RREP_Acks, then yes they could be delivered to a =
router without a valid route to OrigAddr. Alternatively if one of the =
links turns out to be unidirectional then the data packets will also =
arrive at a router without a valid route. In these cases, RERR messages =
will be generated toward the source of the traffic, the route to =
OrigAddr will be deleted at routers back toward TargAddr, but if data =
packets are still flowing from any source to OrigAddr, the route will be =
re-requested by the router responsible for discovering routes for the =
source of the data.

The changes required to =
make acknowledgements end-to-end would require a lot more control =
traffic and be necessary for every route discovery and in almost all =
cases would be unnecessary.

Text has been =
added to the draft in =E2=80=9CLocal Route State Changes=E2=80=9D to =
describe this.

2. Buffering
=EF=BB=BFThomas:
=E2=80=9CIt would seem that =
buffering, as specified, does not accomplish what 
it states =
that it accomplishes: packets are (as you describe) still being
sent while no route is available, and therefore will be =
dropped later.
=3D> Consequently, it seems that =
buffering is a futile exercise?=E2=80=9D

AODVv2: =EF=BB=BFPackets are buffered before a route exists. =
A router only begins sending them when it deems the route to be valid. =
In general, buffering is not futile.

True, =
there is this case outlined above where the router could deem the route =
valid before the bidirectionality check has happened for each and every =
hop. If the links chosen for the route are not all bidirectional, then =
yes, any data packets forwarded along this route will end up being =
dropped at some point on that path. 
This case is =
caused by the RREP_Ack being hop-by-hop, and not caused by buffering.

Thomas: =EF=BB=BF
=E2=80=9CBuffers=
 have huge impacts on TCP performance, and I doubt if the issues on e.g. =
TCP are well enough understood by this WG (Bufferbloat was an example of =
where people got it wrong, despite having extensive experience).=E2=80=9D<=
br class=3D"">
AODVv2: Packets will only be buffered while =
a route is requested. The TCP packets buffered will be packets for =
session initialisation. The authors believe that buffering these will =
have a positive effect. Some references have been suggested, listed =
here, the first of which has been included in the draft:
http://www.ieee802.org/21/archived_docs/2003-09_incoming/ccr-20=
0109-koodli.pdf
Mobile Internetworking with IPv6: =
Concepts, Principles and Practices {Koodli, Perkins}
disc.ece.illinois.edu/seminars_tutorials/tcp-wireless-tutorial.=
ppt
Analysis of TCP performance over mobile ad hoc =
networks http://dl.acm.org/citation.cfm?id=3D313540
Alternatively, we could remove the mention of TCP, and =
instead state that buffering MAY be used for packets awaiting a route, =
but that implementation and implications of this are out of scope for =
AODVv2.


3. Use of =
msg-hop-limit and msg-hop-count:
Thomas:
But, =
either way, as according to your model messages are never forwarded, but =
always are intended for receipt by a router which is a direct neighbor, =
then a <msg-hop-limit> >1 (which applies to the message) seems =
inappropriate. 
Actually, according to that model, I would even say that =
receipt of a message with a <msg-hop-count> >1 should be =
interpreted as a malfunction.
As you refer to RFC5444 =
appendix B, do note that Appendix B of RFC5444 (and, note the errata =
4003) talks about:
      =
<msg-hop-limit> field, if present, contains the number of hops on =
which the message is allowed to travel before being discarded by a MANET =
router.  The <msg-hop-limit> is set by the message originator =
and is used to prevent messages from endlessly circulating in a =
MANET. 
Specifically =E2=80=9Cset by the message originator=E2=80=9D =
and =E2=80=9Cnumber of hops on which the message is allowed to travel=E2=80=
=9D =E2=80=94 with your control messages traveling just one hop, I =
believe that setting <msg-hop-limit> =3D 1 is correct.

AODVv2: Discussion is still needed here. We =
wonder if these fields are necessary at all for AODVv2. We were using =
them to limit the number of regenerations of a RREQ. However, the hop =
limit value needs to be large enough to allow a RREQ from one side of =
the network to another. It might be the case that using the hop limit, =
almost every router in the network would receive that RREQ anyway, and =
by using the redundancy check, we already stop RREQs from circulating =
endlessly.

4. Abstract
Thomas:
=E2=80=9CI made the following comment, =
which still applies:
=E2=80=9CThis is a little =
over-stating the applicability: these statements may be true in some =
scenarios (for example, when there are few concurrent traffic flows, and =
therefore few routes to repair, and therefore few flooding operations to =
contend for channel access). As a general statement, this last sentence =
is incorrect=E2=80=9D=E2=80=9D

AODVv2: The =
text has been removed and the abstract now states: =E2=80=9C 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.=E2=80=9D

5,9,12,13,20. Router Client
Thomas: 
=E2=80=9CI =
made a comment previously that =E2=80=9CRouter client=E2=80=9D is a =
poorly chosen term, and have proposed alternatives. I=E2=80=99ve seen =
some attempts on the list at rather than change the term, explain it =E2=80=
=94 some of which is in this document. The =E2=80=9COverview=E2=80=9D =
still talks about =E2=80=9Ca router=E2=80=A6one of its clients=E2=80=9D =
- which is no less confusing than last time Iw went through it.
I reiterate, why not use =E2=80=9CLocal Attached Network =
Set=E2=80=9D, which is the term used by other documents from this =
WG?=E2=80=9D

AODVv2: We already answered =
this suggestion on the MANET list and asked for comments and =
suggestions, and no responses were received. We have defined what we =
mean by Router Client, and the terminology has so far not changed. =
However, some alternatives have been suggested, so if you feel any of =
these are more effective, please let us know:
=EF=BB=BF=E2=80=A2    Advertised IP Address: =
puts the emphasis on advertisement rather than topological connection
=E2=80=A2    Accessible IP Address: puts the =
emphasis on accessibility through the particular router =E2=80=93 not =
bad
=E2=80=A2    Reduced Function Device =
[RFD]: doesn=E2=80=99t roll off the tongue, but this is terminology used =
for L2R in IEEE 802 Wireless for a similar situation
=E2=80=A2    Accessible Device Address: adds =
some emphasis for the device as well as the address
=EF=BB=BF=E2=80=A2    Stably Connected IP =
Address: nothing is permanent, of course, but the router client set is =
thought to be relatively stable
=E2=80=A2    =
Topologically Connected IP address: ... suggests that a "topological =
connection" is stable compared to wireless
=E2=80=A2    Administratively Assigned IP =
address: ... somehow does not connote the "otherness" of the router =
client devices.

6. Overview - adjacency
Thomas: 
The term =E2=80=9Cconfirming adjacency=E2=80=9D is gone, and =
is now replaced by =E2=80=9Cconfirming bidirectionality=E2=80=9D - =
which, alas, still sounds like there is some active monitoring (HELLO =
message exchange) going on. Unless that is the case, then please be more =
specific here.
I note that the term adjacency is used =
through and through the document, btw.

AODVv2: The text has been updated to avoid the word =
adjacency. We do not believe the text implies active monitoring through =
HELLO messages.

7. Overview - forwarding =
plane
Thomas: I suggested in my last review: The overview =
must also include a paragraph on the intersections between this protocol =
and the forwarding plane =E2=80=94 this, as it is different (and more =
invasive) from that which is typically seen in routing protocols.
Specifically, as a reactive protocol, it is required (at =
least) that the forwarding plane is modified :
1) A =
=E2=80=9Cmiss=E2=80=9D when looking up a next hop for a data packet to =
be forwarded, is signalled to the AODVv2 process so as to permit that =
route discovery be launched;
2) A =E2=80=9Cmiss=E2=80=9D =
when attempting to deliver a data packet to a next hop, which was =
recorded in the routing table, is signalled to the AODVv2 process so as =
to permit that a route repair be initiated and/or a Route Error be =
generated.
3) A =E2=80=9Chit=E2=80=9D when looking up a =
next hop for a data packet to be forwarded to a destination is signalled =
to the AODVv2 process so as to permit maintenance of =E2=80=9Cactive =
route=E2=80=9D Route State, timers and such.
Note that =
these things are necessary to call out in the =E2=80=9Coverview=E2=80=9D =
and in the =E2=80=9Capplicability statement=E2=80=9D, both: it is not =
that they are negatives per se, but that they are important factors =
governing the applicability of this protocol: will a given platform =
permit such access to the forwarding plane, for example? Important to =
understand if for that platform this protocol is apple
I =
see that this was not addressed in the overview, nor in the =
applicability other than by a forward reference to section 6.4. While it =
is positive that there is a section 6.4, this does not exonerate the =
overview and the applicability statement for being honest about the =
requirements (notably to the platform/os) that this protocol has for =
being applicable

AODVv2: The Overview and =
the Applicability Statement now refer to these basic requirements for =
the interaction with the forwarding plane. The Applicability Statement =
also contains the reference to the later section which describes this in =
more detail.

8. 7182 and security

Thomas: I suggested in my last review: It is =
important to do more than this: 7182 does only provide =E2=80=9Ccontainers=
=E2=80=9D for ICVs and timestamps, and does not specify how to use them =
to obtain specific security properties. RFC7182 may be a tool that can =
be used, but how* that tool is used is what determines the security =
properties.
Therefore, saying that =E2=80=9Csecurity is =
dealt with by using RFC7182=E2=80=9D is either an incomplete statement, =
or is indicative of insufficient security considerations.=E2=80=9D
The actual sentence in the I-D has been changed, now it =
explicitly names the two TLVs from 7182 that it uses. That is, alas, =
still not sufficient.
Making the aside that was discussed =
recently on the list, that (i) control messages are not forwarded, and =
that (ii) they are modified in transit, the security/trust model is =
somewhat different from that of 7181 and consequently for what 7182 was =
initially written for. I think that  calling out the trust model, =
and how 7182 actually is used here, might be what is called for.
Continuing with the aside, this *especially* as the =
applicability statement says: "Providing security for a reactive routing =
protocol can be difficult=E2=80=9D

Thomas:=EF=BB=BFOK, so assume that I understand regeneration as per =
my previous email, as meaning =E2=80=9Cgenerate a new message and send =
to my neighbors, based on what I learned when processing a received =
message=E2=80=9D =E2=80=94 just like any distance vector protocol =
does.
In that model, what you write makes sense: each =
originator of a control message (i.e., whoever generates or regenerates =
it) is free to include the information it desires, such as the 4 points =
you list above. No issues with that.
However, and this =
joins what I pointed out in a previous email, you write in the =
applicability statement: "Providing security for a reactive routing =
protocol can be difficult."
While we can discuss if the =
nature of =E2=80=9Creactive routing protocol=E2=80=9D generates =
particular difficulties, we certainly can agree that this protocol has =
the same =E2=80=9Cdifficulties=E2=80=9D as a distance vector =
protocol: routing topology information (by definition) not being =
exchanged end-to-end, but between neighbors (who do calculations =
and generate their own announcements =E2=80=94 regeneration, as you =
call it). 
This means that a specific security model of transitive trust =
must be assumed, no? I trust Victoria, therefore when Victoria =
says =E2=80=9CStan told me=E2=80=9D then I trust that =
she actually verified that "it was indeed Stan who told =
her =E2=80=A6=E2=80=9D =E2=80=94 and either way, I have no way =
of verifying?
I did not see the trust model / trust =
assumption discussed in the specification (specifically not in =
applicability and in section 13, both of where it should be called out), =
but I think that this is actually a crucial point to get right, in order =
to approach developing the MTI security mechanisms.
Anyways,=
 that observation actually contrasts strongly with what the =
applicability statement then goes on to say, namely:
   AODVv2 provides for message integrity and =
security against replay
   attacks by using =
integrity check values, timestamps and sequence
  =
 numbers, as described in Section 13.
This is true only in =
as much as messages are indeed exchanged between neighbors: when =
you =E2=80=9Cregenerate=E2=80=9D a message, i.e., generate a =
new message in response to receipt of a message, you generate brand =
new payload (but possibly including some of the data from the =
received message, of course): thus, any ICVs =E2=80=9Cfrom farther =
away than the neighbor=E2=80=9D will be useless (or, if you zero =
out the parts that you change, these parts will not be protected).
The above sentence, quoted from the applicability statement, =
and that which transpires from section 13, seems - certainly, absent the =
trust model assumed - to suggest that end-to-end protection/validation =
is provided. But, this is not the case.
Finally to the =
applicability statement, a question:
If security =
associations can be established, encryption can be used for AODVv2 =
messages to ensure that only trusted routers participate in routing =
operations.
What you want to say here is that =E2=80=9Cif =
all trusted routers have a shared secret, then we=E2=80=99re able to use =
that shared secret to ignore non-trusted routers=E2=80=9D, right? 
While =
=E2=80=9Csecurity associations=E2=80=9D that do not pass through a =
shared secret probably can be thought up, it=E2=80=99s not trivial and I =
did not find any discussion of that in the document?
Having,=
 on the topic of security, re-read Section 13, which starts:
   This section describes various security =
considerations and potential
   avenues to =
secure AODVv2 routing.  
While this =
is an honest description of what follows, I remain convinced that this =
is not sufficient. So let me ask as precisely as I can:
o =
what is the MTI security mechanism that a conformant implementation must =
provide? Specifically: - which are the processing steps (for =
example in section 7.2.1 and section 7.2.2 for RREP - and similarly =
for the other message types) that define that security mechanism
o what protection is offered by that MTI security mechanism? =
And what remains vulnerable.
If this specification targets =
std.track, then it should include (reasonably solid, but definitely well =
specified) MTI security.

Chris Dearlove:
=EF=BB=BFThere are two potential choices:

- RREQ has an integrity check value to indicate that someone =
trusted created it, if not necessarily the destination. That someone =
might be identifiable or not.
- RREQ has a signature that =
indicates that the destination created it.

Unfortunately, an RREQ that changes as it is forwarded =
(aggregating data of any sort) makes the second option tricky, unless =
there=E2=80=99s some sort of aggregating signature as it is forwarded. =
But I=E2=80=99m not an expert on the latter.

The most trivial case of the former is simply that everyone =
trusted has a single shared key. That has obvious issues =E2=80=93 =
although it was good enough that embodied as RFC 7183 we could get 7181 =
through the system (as a =E2=80=9Cmust implement, do not need to use=E2=80=
=9D minimal case). Alternatively something identity-based (e.g. =
draft-ietf-manet-ibs) could be used, so you know who created the message =
you received, but you are relying on a chain of trust, hop by hop. At =
which point you might as well just sign packets (see RFC 7182).

But in even the weakest case (the single =
shared key used hop by hop) there has to be a failure for things to go =
wrong - either loss of key (in which case all bets are off) or suborning =
one router (who can do quite a lot of damage).

I haven't read the latest AODVv2 draft yet, but this sort of =
thing should be described in its security considerations - the previous =
draft though didn't discuss this as far as I recall.

Chris Dearlove:
=EF=BB=BFIf you go down this =
route of assuming transitive trust, then you might as well use 7182=E2=80=99=
s packet ICV and timestamp rather than message ICV and timestamp.
 
There is a complication (mostly one of =
presentation) that the 5444 multiplexer (rather than AODVv2) needs to do =
this, at least for packets containing AODVv2 messages (but at which =
point, probably all 5444 packets). So you either, depending on your =
point of view, need to request it to do that, or (administratively) =
decline to operate except over a 5444 multiplexer that is doing this.
 
The advantage is one of saved space and =
time when packets contain more than one message. Plus slightly better =
protection (hop count and limit are covered) but which probably =
doesn=E2=80=99t matter here.
 
If =
messages are changed/replaced on a one-to-one basis as forwarded, then =
the only solutions I can see are hop by hop transitive trust (packets or =
messages per hop), or something complicated involving aggregation and =
knowledge of changes. But the latter would be a research task to =
develop, so let=E2=80=99s not try that.

Jiazi=
 Yi:
I=EF=BB=BF agree with Chris and Thomas on their =
concerns on the hop-by-hop security issue. 
This is very =
different from classical DV protocol, in which the vector information is =
designed to be exchanged between neighbours. 
In AODVv2, =
the RREQ/RREP/RERR are to be forwarded through multiple hops. A router =
can sign a message that isn't actually initialised by itself -- this is, =
at least, against intuition. 
This can be =
an issue if we have compromised routers in the network. Of course, a =
compromised router is a problem for every protocol, like OLSRv2. But in =
OLSRv2, a compromised router can only speak on behalf of itself -- =
however, in AODVv2, a compromised/mis-configured router can pretend to =
be any other router (for example, generate RREQ messages using another =
address as OrigAddr).  The consequence will be much more serious if =
that happens. 

AODVv2: This is not yet addressed.

9. Terminology - host, routers, router =
clients: 

Thomas: My last review suggested:
=E2=80=9CThis has been brought up on the list several times =
in the past, without having been addressed.
There are =
=E2=80=9Chosts=E2=80=9D and there are =E2=80=9Crouters=E2=80=9D =E2=80=94 =
whose roles are well defined. Node=E2=80=9D not so much =E2=80=94 which =
is clear from looking at the definition here: =E2=80=9Ceither AODVv2 =
routers or router clients=E2=80=9D (with =E2=80=9Crouter clients=E2=80=9D =
being defined as =E2=80=9Can AODVv2 router is also its own router =
client=E2=80=9D).

This is very much related =
to the use of =E2=80=9CRouter Client=E2=80=9D, and both that term, and =
=E2=80=9Cnode=E2=80=9D indicative that some clarity is needed here.

All a router cares about is =E2=80=9Can =
address=E2=80=9D. If that address is of a network, or a router, or an =
interface (and, if said interface is installed in a router or a host) =
doesn=E2=80=99t matter.

So, =E2=80=9Can =
address=E2=80=9D is something that the routing protocol should care =
about finding paths to. Which means that each address that should be =
made reachable by the routing protocol should be advertised by (at =
least) one router in the network.

One way =
of doing that would be to simply talk about =E2=80=9CAttached =
Networks=E2=80=9D as is done in RFC7181, wherein an address included in =
the =E2=80=9CAttached Network Set=E2=80=9D is advertised by an OLSRv2 =
router....in this case, the equivalent would be =E2=80=9Cfor each =
address in the Attached Network Set of an AODVv2 router the router MUST =
respond authoritatively to a RREQ, and MUST maintain the corresponding =
sequence number=E2=80=9D.
The text, as it currently is, is =
really hard to read, and a re-edit along these lines would go a long =
way.=E2=80=9D

I note that the terms =
=E2=80=9CNode=E2=80=9D and =E2=80=9CRouter Client=E2=80=9D are still =
used, in their original form, and that other than some slight =
wordsmithing this comment has not been addressed in the document.

I reiterate that the need to use router, host, =
node, and router client in and by itself should be an indicator that =
tightening up of terminology is required.

AODVv2: See 5. The use of =E2=80=9Cnode=E2=80=9D has been =
addressed.

10. Terminology and elsewhere - =
address
Thomas: I made the following comment to Routable =
Unicast IP Address:
=E2=80=9CAre there any technical =
reason why not simply *any* address could be considered by the routing =
protocol?
My understanding, but correct me if I am wrong, =
is that all that is required is that all interfaces in a given AODVv2 =
routing domain has an unique address.
That some of these =
addresses (by an IP addressing architecture document) has special =
semantics associated (such as are link locals, or are for private use, =
or are for example use only, or are for multicast) is out of scope =
here?
I see nothing has changed on the above, so let me be =
more explicit: the routing protocol itself probably) should not care =
about what kind of addresses are filled into it. Is an 192.16./16 =
address appropriate? Not across the internet, but it may be in =
somebody=E2=80=99s private deployments. Should the routing protocol be =
=E2=80=9Caddress police=E2=80=9D and is implementation of a =E2=80=9CI =
refuse to route these addresses=E2=80=A6=E2=80=9D a requirement for =
claiming conformance? Suggest simply stating what the requirements are =
under which the routing protocol will work =E2=80=94 and leave =
=E2=80=9Caddress assignment politics=E2=80=9D aside.

AODVv2: We ask for clarification on this issue. We use the =
phrase =E2=80=9Croutable and unicast=E2=80=9D in the draft with respect =
to OrigAddr and TargAddr. We dont mean to exclude addresses from the =
private address ranges. But we dont want to request routes for =
multicast, indeterminate, link-local, or loopback addresses. This is not =
about router interface addresses which are used for AODVv2.

11. Multiple interfaces with the same IP =
address, 6621 implications

Thomas: I also =
continued:
Now, with that being said also, the WG wanted =
that RFC7181 supports not just multiple interfaces, but also the same =
address used on multiple interfaces of the same router. There were good =
reasons for that, and while it was not trivial to implement, it turned =
out to be the right thing to support. If there are technical reasons why =
this is not supported in AODVv2 (for example, if this cannot be made =
work because of <reason>) then that should be called out in the =
applicability statement also?
Conversely, if it is =
possible in AODVv2, then I do not believe that it is clearly specified =
how (at least, in the =E2=80=9Cnaive=E2=80=9D on paper examples I drew =
up, something ended up not working). So either the protocol as-is does =
not support it (but could be made to?) or it is supported (but just need =
to be spelled out), or is not possible (and need to be disclaimed in the =
applicability statement).
Stan Ratliff was a driving force =
in holding the WG=E2=80=99s collective feet to the fire in getting this =
support included in RFC7181, and would likely be the right person to =
consult on this matter?
I actually have not seen changes, =
or comments, on this. In OLSRv2, the WG was making it a strong =
requirement that it should be possible to use the same IP address on =
different interfaces of a router. It was somewhat tedious to design =
around, but it was worked out, and the conditions under which that was =
possible were defined and documented.
I would like to see =
the same done for this protocol.
I also note that this is =
not unrelated to RFC6621-discussions. For example, when selecting S-MPRs =
on a multi-interface and multi-address-per-interface router, care must =
be taken least things won=E2=80=99t work. So, if (and this links back to =
previous mails) RFC6621 is a requirement or desire for this protocol, =
then there are some considerations required here.

AODVv2: We have removed references to RFC 6621.
Initial thoughts on this topic of multiple interfaces using =
the same IP address, is that this wouldn=E2=80=99t cause a problem, if =
the router has only one sequence number. However, this is up for further =
discussion.

12. Interfaces configured as =
router clients

Thomas: I see that the =
definition of =E2=80=9CRouter Client=E2=80=9D has changed to be
=E2=80=9CAn address or address range=E2=80=A6the AODVv2 =
router=E2=80=99s interface addresses are also configured as router =
clients=E2=80=9D
Better than before, but still missing the =
target. The term =E2=80=9CRouter Client=E2=80=9D is, as I indicated =
numerous times before, odd.
But the second part of the =
sentence, does that mean (what it says) that the interfaces must be =
configured specially, so as to be able to be =E2=80=9Crouter clients=E2=80=
=9D? That can=E2=80=99t be true.
What you likely mean =
is:
An AODVv2 router is configured so as to consider its =
own interfaces as part of the locally attached network set=E2=80=9D ?
You configure the router, right? No special =E2=80=9Cinterface =
configuration properties=E2=80=9D are required for an interface to be =
announcable by  an AODVv2 router? (And, getting rid of node would =
actually make the definition shorter and nicer)

AODVv2: The wording we use says: "The IP Addresses of the =
router's interfaces will appear in the Router Client Table." and in the =
Terminology: "The AODVv2 router's interface addresses are also =
configured as Router Clients." Both statements say that =E2=80=98interface=
 addresses are configured as router clients=E2=80=99 ...we are not sure =
why this is misunderstood. We have a router client list, and the AODVv2 =
router=E2=80=99s interface addresses are included in this list. The =
interface itself doesn=E2=80=99t have special =E2=80=9Cinterface =
configuration properties=E2=80=9D.

13 - =
more on router clients
Thomas: Now, snipping out from the =
applicability statement:
"Multi-homing of an IP address is =
not supported by AODVv2, and therefore a Router Client, i.e. an IP =
Address,  =E2=80=A6 "
=E2=80=A6evidence to there =
being some redundant terminology here to weed away.

AODVv2: That was there as a reminder that a router client is =
based on IP address, even though the device with that IP address may =
have other IP addresses too. It=E2=80=99s the IP address that is the =
router client, not the device as a whole with its entire collection of =
configured IP addresses. One IP address of that device might be =
configured as a router client on one router, and a different IP address =
of that device could be configured as a router client on another router. =
The IP addresses would seem to AODVv2 to be on different devices.


14. data elements

Thomas: The below is a little bit of a =
meta-comment, I am not quite sure what I think here. The definitions for =
Target Node and such were confusing before. They still are, somewhat.
I think that it may be because the definitions now used are =
simply copy-pasted out from the tables in the previous version, for =
example:
   =E2=80=9CAn AODVv2 Data Element =
containing the destination address of the IP packet triggering route =
discovery.=E2=80=9D
OK, I can trace back and see that a =
Data Element is something that exists inside a protocol message. To me, =
however, that=E2=80=99s not really general terminology as such, but part =
of the specification of a packet format - or rather, it is the notation =
that you use when describing an algorithm. By the way, why are some =
notations in CamelCase whereas others have a space in them, e.g. =
=E2=80=9CTarget Node=E2=80=9D and =E2=80=9CTargMetric=E2=80=9D, both of =
which are Data Elements? Would be good with a consistent approach =
here.
I *think* that it would be better to take all those =
=E2=80=9CData Element=E2=80=9D bits and move to a separate section (or =
subsection) to the terminology, and then keep all the =E2=80=9Cother =
stuff=E2=80=9D (Neighbor, =E2=80=A6) in its own section.
AODVv2: Your comment from draft 11 where we already had data =
elements in a separate table, says:
"Also suggest =
abolishing this table and folding the definitions in with the other =
definitions in the terminology section."
We have updated =
to not refer so heavily to the term Data Element. All the terms are =
described in the Terminology section. Those in CamelCase are used as =
message fields.


15. Route =
=E2=80=9Cto a specific address=E2=80=9D
Thomas:
I made a comment: Second, should =E2=80=9Cvalid route=E2=80=9D =
not be qualified by =E2=80=9Cto a specific address=E2=80=9D?=E2=80=9D
Which was not addressed.

AODVv2: =
Every route is to a specific address...the address is specified by =
Route.Address and Route.PrefixLength.
Do you mean that =
routes are to the address TargAddr or OrigAddr and therefore to a =
specific host address rather than to a network prefix? This is not the =
case. Prefix Length is included in AODVv2 messages so that the route =
learned from the message represents the prefix which OrigAddr or =
TargAddr resides on (if the router client entry corresponding to =
OrigAddr at RREQ_Gen or TargAddr at RREP_Gen is configured with a prefix =
length). e.g. OrigAddr is 10.0.0.1 but the corresponding router client =
entry at RREQ_Gen could be 10.0.0.0/8. So when constructing the RREQ you include a =
prefix length of 8, and when receiving the RREQ and learning the route =
to OrigAddr, you can install a route to 10.0.0.0/8.  Text has been updated to make this more =
obvious.

16. unreachable address

Thomas: I also made a comment on "Unreachable =
Address=E2=80=9D - I am glad I did, because I apparently had a different =
understanding than what was intended. I now see that an Unreachable =
Address by definition is an address listed in a RERR message, and not =
the same as an address to which no route has yet  been discovered? =
If yes, then please use a different term, such as =
FormerlyReachableAddress=E2=80=9D or something of the sort?

AODVv2: "Formerly reachable" is inaccurate... =
we send a RERR if another router forwards a packet via us, and we dont =
have a route, not just when we lose a route. We might never have had a =
route, or might never have had a valid route, so the address may not =
have been "formerly reachable". Also, I think "FormerlyReachableAddress" =
is a really ugly term. Unreachable means "we don=E2=80=99t have a route =
and we aren=E2=80=99t going to request one" or "we lost this route" =
(depending on why the RERR is being sent). It doesn=E2=80=99t mean "we =
didn=E2=80=99t request one yet", and it would be wrong to class an =
address as unreachable because we hadn=E2=80=99t requested a route for =
it yet, that is, assuming it=E2=80=99s configured as a router =
client. 

If a better term is suggested we could =
consider changing but at the moment we have kept =E2=80=9CUnreachable =
Address=E2=80=9D.


17. =
Applicability - multiple interfaces same address, 6621 again

Thomas: Applicability statement: First, I =
would like to recognize the efforts made to improve this since last =
review. Thanks
Second, the document states: "AODVv2 =
supports routers with multiple interfaces, as long as each interface =
configured for AODVv2 has a unicast IP address.  A router may use =
the same IP address on multiple interfaces.  Address assignment =
procedures are out of scope for AODVv2.=E2=80=9D
Is that =
true? Granted, I have not worked this through in detail, but I can =
present a counter-example: the use of RFC6621 means that there certainly =
are some constraints that must be respected least various flooding =
optimizations may not work.
Secondly, if the =
multiple-interfaces-with-same-address are on the same L2, and this is =
what I have not worked through, are there any situations that will not =
work?
The immediately previous version of this =
specification read:
"AODVv2 supports routers with multiple =
interfaces, as long as each interface configured for AODVv2 has its own =
unicast routable IP address"
So what changed that means =
that each interface no longer needs its *own* unicast address?

AODVv2: Well, based on previous questions on =
this, we talked it through and decided there shouldn=E2=80=99t be an =
issue if different interfaces of a router used the same IP address. Note =
that we changed AODVv2 so that there is one sequence number per router. =
No longer can a router use different sequence numbers on different =
interfaces. If an RREQ went out of two interfaces using the same =
address, we worked it through and decided the request would be processed =
correctly. 
Also, text referring to RFC 6621 has been removed.

18. Applicability and appendix - =
multihoming

Thomas: I pointed out to the =
Applicability Statement:
I think that appendix B needs to =
be removed. Essentially, it makes claims that it is possible to do =
multi-homing =E2=80=94 but neither specifies how it is done, nor gives =
pointers to documents that justify the claim.
AODVv2 does =
not support multi-homing =E2=80=94 that=E2=80=99s clear, and it is fine =
that it is called out here. Thank you for that.
Now, with =
that being said, I am torn between being satisfied that it is called out =
on one hand, and wanting to have =E2=80=9Cmulti homing=E2=80=9D on the =
other hand. RFC7181 supports multi-homing, FWIW.
I believe =
that this also would merit some explicit discussion by the WG, in order =
to understand if this design decision is acceptable?
I see =
that Appendix B still is in the document, and I do not recall having =
seen this discussed on the mailing list. Simply removing the reference =
from the Applicability Statement to Appendix B does not address the =
issue that I raised in my previous review.

AODVv2: Appendix has been removed and may appear in a future =
informational document.

19. interfaces list =
- use of =E2=80=9CSHOULD=E2=80=9D

Thomas: =
To 4.1, I made the following comment:
"Is this a should, =
or a SHOULD? If the latter, should it be a MUST?
In =
general, there are a lot of such =E2=80=9Cmaybe normative language=E2=80=9D=
 through the document, and I would much like to see an editorial pass =
=E2=80=94 essentially all may/should/ must and friends carefully =
evaluated as if they should become 2119-terms, and ... more importantly =
(it has been called out before, fwiw) quite a bit of should/SHOULD which =
ought to be transformed into MUST.
Generally, aiming for a =
very a low number of SHOULD is a good design metric for a document=E2=80=9D=

Aside from the general comment on 2119-language, why is =
this a SHOULD?

AODVv2: We changed this =
instance to a MUST and will be checking for =E2=80=9Cmaybe normative =
language=E2=80=9D.


20. =
Router client - Local Attached Network Set

Thomas: To 4.2, I made the following comment:
As =
indicated earlier, I believe that the term =E2=80=9CRouter Client=E2=80=9D=
 is ill chosen. I believe that it is more appropriately an =E2=80=9CAttach=
ed Network Set=E2=80=9D since =E2=80=94 as indicated previously =E2=80=94 =
the term =E2=80=9CRouter Client=E2=80=9D is ambiguous. I am pleased to =
see, though, that this =E2=80=9CRouter Client List=E2=80=9D in reality =
is an =E2=80=9CAttached Network Set=E2=80=9D and so that change should =
be (relatively) easy.
The above comment still is =
applicable to this revision,

AODVv2: See =
5,9,12,13.


21. Subnet
Thomas: To 4.2, I made the following comment:
Also, I recommend to not say =E2=80=9Csubnet=E2=80=9D =E2=80=94=
 how about rephrasing to =E2=80=9CIf a prefix is included in the =
attached network set of an AODVv2 router, then that AODVv2 router MUST =
provide connectivity for, i.e. answer to RREQs and maintain sequence =
numbers for, all addresses from within that prefix.=E2=80=9D
I note that while the term has been removed from section 4, =
there=E2=80=99re 4 lingering instances of this term in the document, =
that could easily be removed.

AODVv2: All =
mentions of "subnet" were in the ENAR section. They have been updated to =
say network, or "networks attached to the routers"


22. relocating router client

Thomas: I Also made a comment about Appendix B in my previous =
review, which is referenced here. That comment still applies.

AODVv2: Moved into main draft.

23. Neighbor Monitoring

Thomas: To Section 4.3, I noticed:
Does section =
6.2 describe how to monitor an established adjacency only, or how to =
discover neighbouring AODVv2 routers? Looking in 6.2, I see
=E2=80=9CNot every pair of neighboring routers will =
necessarily form an adjacency,=E2=80=9D =E2=80=94 so it likely isn=E2=80=99=
t 6.2 that tells me how to maintain this table?
In short, =
=E2=80=9CA neighbour table MUST be maintained=E2=80=9D =E2=80=94 where =
can I find information on how to do this?
Section 6.2 =
states:
=E2=80=9CThe default approach for monitoring =
bidirectional connectivity to the next hop toward OrigAddr is to request =
acknowledgement of Route Reply messages.=E2=80=9D
That =
certainly will tell me if a link over which an RREP is sent is =
bi-directional, but will not maintain a =E2=80=9Cneighbor table=E2=80=9D.<=
br class=3D"">So how is this done? Or, is the =E2=80=9CNeighbor Table=E2=80=
=9D not supposed to contain the complete set of neighbours? What =
information =E2=80=9C...MUST be maintained=E2=80=9D then, in this =
table?
This is very unclear, I would not know how to =
implement a mechanism that populates this =E2=80=9CNeighbor Table=E2=80=9D=
 with the needed information here.
I see no (relevant) =
changes to 6.2 nor to 4.3 so I assume that this comment has not been =
addressed

AODVv2: A new section was added =
to show how to update the neighbour table. There have also been updates =
to this entire section since version 12.

24. =
    pseudo-code

Thomas:
I am throwing this in here, as I am sure that I commented on =
that in the previous review, but I do not see that addressed: is =
Appendix C normative, or not? It represents =E2=80=9C a second =
specification of the protocol, in a different language=E2=80=9D from the =
main part of the specification. I have not walked through and made 200% =
sure that both are perfectly aligned and that there are no ambiguities, =
but having two different specifications of a protocol is a recipe for =
disaster.  Please either make 2000% sure that they are specifying =
the same thing without ambiguities, or remove one.

AODVv2: Removed - maybe to include in an informational =
document in future.


25. =
seqnum as 16 bit unsigned integer

Thomas: =
To section 4.4, I wrote:
"would like to nit-pick that: the =
router can maintain this sequence number in whatever format it pleases =
=E2=80=94 but, when it includes it in control messages, it must be =
representable in a specified format, respecting certain rules.=E2=80=9DI see that there were no changes following this comment.

AODVv2: Why store it as anything other than =
what it needs to be when it goes into a message? However, we now state =
"MUST report its own sequence number as a 16 bit....whenever it creates =
a RREQ or RREP message".


26. =
multiple seqnums?

Thomas:
To =
section 4.4 I asked for clarification as to if sequence numbers were per =
interface or per router, as the specification was unclear on that. The =
words has changed, but it still is unclear: how many sequence numbers =
does a router maintain? One? One per interface?

AODVv2: We tried to start discussion on that point, and in =
the meantime we reverted to having 1 seqnum per router. We think the =
text is clear... we refer to "the routers sequence number" or "its =
sequence number" - never hinting that there could be multiple seqnums =
per router (as far as I'm aware).


27. sets/lists/tables

Thomas:
In my previous review, I expressed that it would be =
preferential to use =E2=80=9Ca notation of Sets=E2=80=9D rather than =
tables. I see that this has not changed.

AODVv2: You preferred sets rather than lists in your previous =
review...and explained our reasoning for this in responses to the MANET =
list, and we did not receive further comments.


28. use of =E2=80=9Cnode=E2=80=9D

Thomas:
I made a comment on node =
and address, let me pick this up again. The following:
RteMsg.OrigAddr
An IP address of the node which =
requires the route, i.e., the source address of the IP packet triggering =
the route request.
would be more compact and clear if =
getting rid of the term =E2=80=9Cnode=E2=80=9D and said:
RteMsg.OrigAddr
The source address of the IP =
packet triggering the route request.

AODVv2: =
Change made as suggested.

29. route =
table/rib/routing set

Thomas: To section =
4.6, and I (and others) have commented on this before:
All =
AODVv2 routers MUST maintain a route table.  The route table entry =
is a conceptual data structure.  Implementations MAY use any =
internal representation but MUST contain the following information:
In order to avoid confusion, rename this to =E2=80=9CRouting =
Information Base=E2=80=9D or =E2=80=9CRouting Set=E2=80=9D =E2=80=94 a =
Routing Table is an operating system construct, whereon operations =
directly influence packet forwarding. What you are defining here is a =
RIB/an RS.

AODVv2: Done in version 13.


30. rreq for prefix, use of =
=E2=80=9Cip address=E2=80=9D and =E2=80=9Caddress"

Thomas:
The confusion that I pointed out in my =
previous review on =E2=80=9CIP address=E2=80=9D and =E2=80=9CAddress=E2=80=
=9D being used a bit haphazardly persists, fwiw. It makes me think, can =
a router send an RREQ for a prefix?

AODVv2: =
See also #15. RREQ_Gen can include the prefix associated with OrigAddr =
by adding a prefix length to the message, the prefix length associated =
with the router client entry corresponding to OrigAddr. So all routers =
which receive it can learn a route to the prefix on which OrigAddr =
resides. But for TargAddr... the RREQ only has one target IP address - =
the destination IP address of the packet requiring the route... so what =
prefix length would it use? The RREQ requests a route to a single IP =
address. However, when the RREP is created, RREP_Gen should include the =
prefix length associated with the router client entry for TargAddr. So =
all routers which receive this RREP learn a route to the prefix TargAddr =
is part of (if the router client entry is configured with a prefix =
length). The text has been updated to make this more obvious.


31. next hop ip address =
wording

Thomas:
I also called =
this out in my previous review as incorrect, and despite wordsmithing it =
still is:

        Route.NextHop
          &nb=
sp;   The source IP address of the message advertising the =
route to
          &nb=
sp;   Route.Address, i.e. an IP address of the AODVv2 router =
used for
          &nb=
sp;   the next hop on the path toward Route.Address.

If that =E2=80=9Cmessage=E2=80=9D is an =
RFC5444 entity, then it does to have a =E2=80=9Csource IP Address=E2=80=9D=
 =E2=80=94 the encapsulating IP datagram containing the packet =
containing the message does. And the message MAY have an Originator =
Address

AODVv2: Updated to say =E2=80=9Cthe =
source IP address of the IP packet containing the message =
advertising...=E2=80=9D


***************************************************************=
*****
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

On 28 Apr 2016, at 01:24, Justin Dean <bebemaster@gmail.com> wrote:

An alternative solution to c=
hecking integrity. The current icv draft is good at validating messages from=
 an original source. OLSRV2 and NHDP use this to good effect. AODVV2 doesn't=
 because the messages are regenerated; I belive this to be the correct term a=
s the message contains local information, path information, and originator i=
nformation. Getting the icv draft to work on forwarded packets is ugly as th=
ey really are regenerated and should be. What we want to do is secure the or=
iginal source of information which is OrigAddr/target address and sequence n=
umber. Why not just attach a new aodv specific icv TLV which uses THAT info a=
nd nothing else? The current icv TLV would/could still be used over the whol=
e message hop by hop by each router, as the messages are regenerated.


Justin


On Wed, Apr 27, 2016, 6:43 P=
M Jiazi YI <ietf@jiaziyi.com> w=
rote:
On Thu, Apr 28, 2016 at 12:19 AM, Lo=
tte Steenbrink <lotte.steenbrink@fu-berlin.de> wro=
te:
Am 28.04.2016 um 00:16 schrieb Ch=
ristopher Dearlove <christopher.dearlove@gmail.com>:

The more you have to zero out, t=
he messier it gets, and the less secure it gets (more things can be spoofed)=
. I think that's about all I've got to add.

<=
/blockquote>

Of course. My question was just:=

* Do we want to come up with an exact description of how the zero=
ing out should work now, with the short time we have left?
=


If a meaningful security=
 mechanism is required, yes. 
I think the first thing to do i=
s to cut as many mutable fields and optional fields as possible. 
=


best

Jiazi
 
or
* Do we mention in the draft tha=
t zeroing out has to happen somehow and leave the nitty gritty to future wor=
k?

At least that=E2=80=99s how I understood the opt=
ions you laid out...

-- 
Christopher Dearlove
<=
/div>



--  
Christopher Dearlove
<=
/div>On 27 Apr 2016, at 22:46, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de=
> wrote:


Hi all,
I=E2=80=99m currently revising the security considerations with r=
egards to the move from regeneration to forwarding, which depends on a decis=
ion being made on how/where we want to mention the possibility of zeroing ou=
t TLVs to calculate the ICV for the rest of a message=E2=80=99s contents (se=
e second * of my last e-mail). I=E2=80=99ve not found a decision on this in o=
ther thread (please pardon me if I overlooked something), so I=E2=80=99ll bu=
mp this thread and ask the WG for its opinions. (again, personally, the 2nd o=
ption outlined by Christopher seems more appealing to me)

Regards,
Lotte

Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink <lotte.steenbrink@fu-berlin.=
de>:

Hi all,
to=
 summarize:

* AODVv2 message Type numbers should be=
 in the Experimental type space and the AODVv2 TLV Types should be message t=
ype-specific. This also means changing the text regarding IANA actions and c=
hanging the text regarding what the experiment is to something along the lin=
es of =E2=80=9Cwe want to gather experience on how to make generic metric TL=
Vs and ICVs that work with changing metric TV values happen with reactive pr=
otocols=E2=80=9D
* we=E2=80=99re undecided on (to quote Christophe=
r) the "here's a mechanism we haven't really thought through in detail, but a=
t least we've defined one", or "we know the sort of thing we want, and we'll=
 describe it, but rather than produce something not quite right, we'll not g=
o further=E2=80=9C decision on temporarily setting the metric value to 0 (i.=
e. the who and how). (personally, I think I=E2=80=99d prefer the latter appr=
oach, but that=E2=80=99s an entirely gut feeling-based preference)

Did I catch that correctly? If so, I=E2=80=99ll put together=
 and suggest some text for the first point as soon as I get home and in case=
 there has been a decision on the second by then, I=E2=80=99ll try to tackle=
 that one too. :)

Best regards, Lotte
Am 22.04.2016 um 16:41 schrieb De=
arlove, Christopher (UK) <chris.dearlove@baesystems.com>:

I have no problem with that. I was trying to lay out the issues with=
out muddying the water with my preference.
 
=
--
Chri=
stopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelli=
gence Laboratories
_________________________________=
_________________________________________

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

BAE Systems Applied In=
telligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8=
HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wal=
es No: 01337451
Re=
gistered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<=
/u>
 
From: Justin Dean [mailto:bebemaster@gmail.com] 
Sent:<=
/b> 22 April 2016 15:35
To: De=
arlove, Christopher (UK)
Cc: Thomas Heide Clause=
n; Mobile Ad Hoc Networks mailing list
Subject: =
Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2=
-13 review - a couple of big ticket Items)
 
 
*** WARNING ***
This message originates f=
rom outside our organisation, either from an external partner or the interne=
t.
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 emails you receive, click he=
re.
If you feel the email is suspicious, please follow <=
a href=3D"http://intranet.ent.baesystems.com/howwework/security/spotlights/D=
ocuments/Dealing%20With%20Suspicious%20Emails.pdf" style=3D"color:purple;tex=
t-decoration:underline" target=3D"_blank">this process.
Speakin=
g as participant.

I kind of like the idea of using the experimental m=
essage type space.  We only have a limited amount of these message type=
s.  The TLV assignments could just use the message type specific space a=
nd there isn't an issue there.  IANA wouldn't assign a number but I don=
't see why the document couldn't specify the experimental numbers it was goi=
ng to use so other future near term experiential protocols could do the same=
 and generally avoid conflict.  If the experiment is successful IANA as=
signments could be made.  Functionally no real difference with protecti=
ons vs long term usage of limited space.
 
Justin
 
On Fri, Ap=
r 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:<=
/div>
There's rather a contradiction between the concepts of a d=
efinition of a protocol, even Experimental, and experimental space, which us=
ually assumes that the user can do what he or she likes in it.

But ch=
ewing up messages types (how many, 3?) of which there are relatively few for=
 experimental is long term a problem, although short term not.

TLV sp=
ace is easier in two regards. It's bigger (though the prime real estate of t=
ype extension zero isn't) and can have message type specific TLVs.

So=
 TLVS can actually be invisible, if that option is chosen. For messages some=
thing has to give. Least bad option is again one of those we should discuss,=
 but time ...

(To be precise, messages types from 224 are defined in R=
FC 5444 as " Experimental Use", of which BCP 26 says "Similar to private or l=
ocal use only, with the  purpose being to facilitate experimentation." T=
he alternative 0-223 space is Expert Review. IANA still thinks the experts a=
re Joe Macker and the recused Stan Ratliff. But that's a soluble nit.)
--
Christopher Dearlove
Senior Princ=
ipal Engineer
BAE Systems Applied Intelligence Laboratories<=
/span>
____________________________________________________________=
______________

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

BAE Systems Applied Intelligence, Chelmsford Technolog=
y Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems A=
pplied Intelligence Limited
Registered in England & Wale=
s No: 01337451
Registered Office: Surrey Research Park, Guil=
dford, Surrey, GU2 7YP


-----Original Message-----
From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org]
Sent: 22 April 2016 14:21<=
/span>
To: Dearlove, Christopher (UK)
Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing li=
st
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ie=
tf-manet-aodvv2-13 review - a couple of big ticket Items)

-----------=
-----------! WARNING ! ---------------------- This message originates from o=
utside our organisation, either from an external partner or from the interne=
t.
Consider carefully whether you should click on any links, open any att=
achments or reply.
Follow the 'Report Suspicious Emails' link on IT matte=
rs for instructions on reporting suspicious email messages.
-------------=
-------------------------------------------


> On 22 avr. 2016,=
 at 15:05, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
>
> Once you'=
re entirely in AODV2's own space, and AODVv2 is experimental (working assump=
tion for this discussion) you have more liberty.
>

Yep.

=
Taken somewhat by surprise both by the sudden "rush" and the experimental ma=
turity level, I am wondering (and haven't thought through) about experimenta=
l space vs non-experimental (for message types, and consequently for message=
 type specific TLV types).

I think that if the AODVv2 experiment spec=
ifies the use of Message types from the Experimental message type space with=
out making actual registrations in the IANA registry, AND the use of type sp=
ecific TLV types, this becomes a non-issue entirely (by design, this is prec=
isely what that experimental space is for)

Whereas, as you point out,=
 the alternative is a "can open - worms everywhere" situation that I think t=
ime is too short to solve?

Thomas


> Then you could try s=
pecifying it. But with a very good chance of producing something you later d=
ecide you should have done differently.
>
> I honestly don't kno=
w which would go down better (or less badly) - "here's a mechanism we haven'=
t really thought through in detail, but at least we've defined one", or "we k=
now the sort of thing we want, and we'll describe it, but rather than produc=
e something not quite right, we'll not go further".
>
> --
&g=
t; Christopher Dearlove
> Senior Principal Engineer
> BAE System=
s Applied Intelligence Laboratories
> ________________________________=
__________________________________________
>
> T: &nb=
sp;+44 (0)1245 242194  |=
  E: chris.de=
arlove@baesystems.com
>
> BAE Systems Applied Intelligence, C=
helmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
><=
span> www.baesystems.com/ai<=
br>> BAE Systems Applied Intelligence Limited
> Registered in Engla=
nd & Wales No: 01337451
> Registered Office: Surrey Research Park,=
 Guildford, Surrey, GU2 7YP
>
>
> -----Original Message---=
--
> From: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]
> Sent: 22 April 2016 13:59> To: Mobile Ad Hoc Networks mailing list
> Cc: Henning Rogge; De=
arlove, Christopher (UK)
> Subject: Re: [manet] On Forwarding-and-rege=
neration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticke=
t Items)
>
> ----------------------! WARNING ! -----------------=
----- This message originates from outside our organisation, either from an e=
xternal partner or from the internet.
> Consider carefully whether you=
 should click on any links, open any attachments or reply.
> Follow th=
e 'Report Suspicious Emails' link on IT matters for instructions on reportin=
g suspicious email messages.
> ---------------------------------------=
-----------------
>
> Hello Christopher,
>
>> Am 2=
2.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>:
>>
=
>> Just be careful to note that this concept is as currently being dis=
cussed (a) specific to AODVv2, and (b) not an application of 7182, which has=
 no knowledge of special TLVs.
>>
>> This is something we'=
d want to get right, and need to get right if in any space not specific to A=
DODVv2, because getting it wrong produces future problems.
>
> M=
akes sense.
>
>> I can see some possible approaches, none is i=
deal and we're rather out
>> of time to specify. But this is experi=
mental, so I think we might be
>> able to indicate the shape of the=
 solution without specifying it,
>> which would be a different RFC,=
 under a bit less time pressure.
>> (Extensions to existing protoco=
ls like 7182 would naturally be in
>> scope rechartered I think.)>>
>> To indicate the range that's open, here are two possi=
ble ideas, one of which has an impact now, so needs to be agreed. Note that I=
'm not suggesting (in fact quite the opposite) defining an extension to 7182=
 here, rather enabling such an extension, if written, to "do the right thing=
".
>> - We have an extension to 7182 that says "zero out all value o=
ctets in protocol specific TLVs. That requires now putting the AODVv2 metric=
 TLV in that space.
>
> Just to make sure that I understood you c=
orrectly=E2=80=93 =E2=80=9Cthat space=E2=80=9D meaning making the AODVv2 met=
ric TLV protocol specific? (By =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=
=99m referring to the generic TLV we=E2=80=99ve been talking about on this l=
ist earlier this week).
>
>> - We have an extension to 7182 t=
hat adds extra material to the value field that indicates (TBD how, by posit=
ion with sanity check that this is TLV value perhaps?) which octets are to b=
e zeroed out before the ICV is calculated.
>
> The way I underst=
and that approach, it wouldn=E2=80=99t warrant any action from AODVv2 beside=
s saying =E2=80=9Cif you calculate the ICV, set the Metric value to zero=E2=80=
=9D (leaving the nitty gritty of how this would be done in detail to future w=
ork)=E2=80=A6 Is that correct?
>
>>
>> We do not hav=
e the time to specify this in an acceptable manner within two weeks though. B=
ut the security consideration section could say something along the lines of=
 "this enables the use of an ICV defined to zero out these octets=E2=80=9C.<=
br>>
> Okay. :)
>
> Best regards,
> Lotte
>=

>>
>> --
>> Christopher Dearlove
>> Sen=
ior Principal Engineer
>> BAE Systems Applied Intelligence Laborato=
ries
>> ___________________________________________________________=
___________
>> ____
>>
>> 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 Inte=
lligence Limited Registered in England & Wales
>> No: 01337451 R=
egistered Office: Surrey Research Park, Guildford,
>> Surrey, GU2 7=
YP
>>
>> -----Original Message-----
>> From: mane=
t [mailto:manet-bounces@ietf.org] On Be=
half Of Lotte
>> Steenbrink
>> Sent: 22 April 2016 10:28>> To: Henning Rogge
>> Cc: Mobile Ad Hoc Networks mailing l=
ist
>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re=
:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Ite=
ms)
>>
>> ----------------------! WARNING ! --------------=
-------- This message originates from outside our organisation, either from a=
n external partner or from the internet.
>> Consider carefully whet=
her you should click on any links, open any attachments or reply.
>>=
; Follow the 'Report Suspicious Emails' link on IT matters for instructions o=
n reporting suspicious email messages.
>> -------------------------=
-------------------------------
>>
>> *** WARNING ***
&=
gt;> EXTERNAL EMAIL -- This message originates from outside our organizat=
ion.
>>
>>
>> Hi Henning,
>>
>>=
> Am 22.04.2016 um 11:08 schrieb Henning Rogge <hrogge@gmail.com>:
>>>
>>> On Fri, Apr 2=
2, 2016 at 11:05 AM, Lotte Steenbrink
>>> <lotte.steenbrink@fu-berlin.de> wrote:
>&g=
t;>> Hi Thomas,
>>>> Can it?! Iirc, the reason why we a=
dopted the =E2=80=9Cregeneration=E2=80=9D language
>>>> in th=
e first place is that we=E2=80=99ve been told that whenever one bit in
&g=
t;>>> the message (apart from its header) is changed, the entire th=
ing has to be regenerated.
>>>> I=E2=80=99m starting to get t=
he feeling we=E2=80=99ve just been misunderstanding
>>>> each=
 other for more than a year. :( Anyway, it seems like we=E2=80=99re
>&=
gt;>> getting close now, so yay.
>>>
>>> "Modi=
fying" the binary message instead of parsing and generating a
>>>=
; new one will be difficult as soon someone writes an extension to
>&g=
t;> AODVv2 that adds more TLVs to the message.
>>
>> D=E2=
=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99s what you e=
xplained to me when I got confused about the topic last spring=E2=80=A6 But=E2=
=80=93 even if a message contains TLVs that the AODVv2 implementation handli=
ng it doesn=E2=80=99t understand, it will still be able to recognize the Met=
ric TLV, right? Isn=E2=80=99t that the nifty thing about RFC5444? So, while w=
e really shouldn=E2=80=99t write =E2=80=9Cbefore calculating the ICV, set th=
e n-th 4 octets to 0=E2=80=9D, we might say =E2=80=9Cidentify the octets tha=
t make up the metric value and set those to 0=E2=80=9D?
>>
>&=
gt; Best regards,
>> Lotte
>>
>>> Henning Rogg=
e
>>
>> _______________________________________________>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet<=
br>>> ****************************************************************=
****
>> This email and any attachments are confidential to the inte=
nded
>> recipient and may also be privileged. If you are not the in=
tended
>> recipient please delete it from your system and notify th=
e sender.
>> You should not copy it or use it for any purpose nor d=
isclose or
>> distribute its contents to any other person.
>&=
gt; ********************************************************************
=
>
> _______________________________________________
> manet m=
ailing list
> manet@ietf.or=
g
> https://www.ietf.org/mailman/listinfo/manet

__________________=
_____________________________
manet mailing list
manet@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/manet
=

 
_______________________________________________=

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

_______________________________________________
manet m=
ailing list
manet@iet=
f.org
https://www.ietf.org/mailman/listinfo/manet

_=
______________________________________________
manet mailing=
 list
ma=
net@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/mailman/listinfo/manet




____________________=
___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai=
lman/listinfo/manet
=

--Apple-Mail-4AF5FCCA-3CF2-4DE4-AEEC-AA46D1161309--


From nobody Wed Apr 27 16:40: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 ACDF012D093 for ; Wed, 27 Apr 2016 16:40:04 -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 JhmKshRzoufj for ; Wed, 27 Apr 2016 16:40:01 -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 1B02612B060 for ; Wed, 27 Apr 2016 16:40:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id DE177240E6E; Wed, 27 Apr 2016 16:40:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1461800400; bh=Fb4R40Oj70ShvcQe4OaSn0QOAnqWqpjvryOVbLVfqCw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=jfGpBrEbLtHi0GKOBvQhqVkL9ICJog9kJu/MeND6rPGIqUID6d0g6XAlm9Bp13Wuy Co9mTyB3lkoHbFFM8mHuh5pF2OdZUOSqVx+S5Nz3DGXe4HkH6GRoLwk28c93GVbePv BTee38Gx9c2V5+rqQBiEKN5b8S/FJnemdkQFnK5k=
X-Virus-Scanned: Debian amavisd-new at maila2.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 maila2.tigertech.net (Postfix) with ESMTPSA id B40D924020A; Wed, 27 Apr 2016 16:39:59 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-B8995991-87BC-464C-979F-04C752C98BC8
Mime-Version: 1.0 (1.0)
From: Thomas Heide Clausen 
X-Mailer: iPad Mail (13F51a)
In-Reply-To: <144C7397-F19E-4FB0-959A-B5A030BD7A8A@fu-berlin.de>
Date: Thu, 28 Apr 2016 01:39:58 +0200
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <8C311D85-5C5A-4155-9705-6B09D0AA588B@thomasclausen.org>  <3A79C619-5DEC-4356-9285-7A209AA100E1@thomasclausen.org> <6DFEF66A-2B48-45B9-A08D-6042B20AF386@fu-berlin.de>  <57CBEE37-3779-4C8A-BA85-78C24F05CB00@fu-berlin.de>    <5C8505F1-6938-46D1-AFAF-85AE58270181@thomasclausen.org>      <60BD2E9C-64D7-4444-B3A9-8D207EB4A86F@gmail.com> <144C7397-F19E-4FB0-959A-B5A030BD7A8A@fu-berlin. de>
To: Lotte Steenbrink 
Archived-At: 
Cc: Mobile Ad Hoc Networks mailing list 
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
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, 27 Apr 2016 23:40:04 -0000

--Apple-Mail-B8995991-87BC-464C-979F-04C752C98BC8
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> On 28 Apr 2016, at 00:19, Lotte Steenbrink =
 wrote:
>=20
>=20
>> Am 28.04.2016 um 00:16 schrieb Christopher Dearlove :
>>=20
>> The more you have to zero out, the messier it gets, and the less secure i=
t gets (more things can be spoofed). I think that's about all I've got to ad=
d.
>=20
> Of course. My question was just:
> * Do we want to come up with an exact description of how the zeroing out s=
hould work now, with the short time we have left?

Absolutely required for interoperability, yes.
And...for passing WGLC, and for (I suspect) satisfying the SEC-DIR and SEC-A=
Ds.

Thomas

> or
> * Do we mention in the draft that zeroing out has to happen somehow and le=
ave the nitty gritty to future work?
>=20

> At least that=E2=80=99s how I understood the options you laid out...
>=20
>> --=20
>> Christopher Dearlove
>> christopher.dearlove@gmail.com (iPhone)
>> chris@mnemosyne.demon.co.uk (home)
>>=20
>>=20
>>=20
>> -- =20
>> Christopher Dearlove
>> christopher.dearlove@gmail.com (iPhone)
>> chris@mnemosyne.demon.co.uk (home)
>> On 27 Apr 2016, at 22:46, Lotte Steenbrink  wrote:
>>=20
>>> Hi all,
>>> I=E2=80=99m currently revising the security considerations with regards t=
o the move from regeneration to forwarding, which depends on a decision bein=
g made on how/where we want to mention the possibility of zeroing out TLVs t=
o calculate the ICV for the rest of a message=E2=80=99s contents (see second=
 * of my last e-mail). I=E2=80=99ve not found a decision on this in other th=
read (please pardon me if I overlooked something), so I=E2=80=99ll bump this=
 thread and ask the WG for its opinions. (again, personally, the 2nd option o=
utlined by Christopher seems more appealing to me)
>>>=20
>>> Regards,
>>> Lotte
>>>=20
>>>> Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink :
>>>>=20
>>>> Hi all,
>>>> to summarize:
>>>>=20
>>>> * AODVv2 message Type numbers should be in the Experimental type space a=
nd the AODVv2 TLV Types should be message type-specific. This also means cha=
nging the text regarding IANA actions and changing the text regarding what t=
he experiment is to something along the lines of =E2=80=9Cwe want to gather e=
xperience on how to make generic metric TLVs and ICVs that work with changin=
g metric TV values happen with reactive protocols=E2=80=9D
>>>> * we=E2=80=99re undecided on (to quote Christopher) the "here's a mecha=
nism we haven't really thought through in detail, but at least we've defined=
 one", or "we know the sort of thing we want, and we'll describe it, but rat=
her than produce something not quite right, we'll not go further=E2=80=9C de=
cision on temporarily setting the metric value to 0 (i.e. the who and how). (=
personally, I think I=E2=80=99d prefer the latter approach, but that=E2=80=99=
s an entirely gut feeling-based preference)
>>>>=20
>>>> Did I catch that correctly? If so, I=E2=80=99ll put together and sugges=
t some text for the first point as soon as I get home and in case there has b=
een a decision on the second by then, I=E2=80=99ll try to tackle that one to=
o. :)
>>>>=20
>>>> Best regards, Lotte
>>>>=20
>>>>> Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) :
>>>>>=20
>>>>> I have no problem with that. I was trying to lay out the issues withou=
t muddying the water with my preference.
>>>>> =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 Ba=
ddow, Chelmsford, Essex CM2 8HN.
>>>>> www.baesystems.com/ai
>>>>>=20
>>>>> BAE Systems Applied Intelligence Limited
>>>>> Registered in England & Wales No: 01337451
>>>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>>>>>=20
>>>>> =20
>>>>> From: Justin Dean [mailto:bebemaster@gmail.com]=20
>>>>> Sent: 22 April 2016 15:35
>>>>> To: Dearlove, Christopher (UK)
>>>>> Cc: Thomas Heide Clausen; Mobile Ad Hoc Networks mailing list
>>>>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ie=
tf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>> =20
>>>>> =20
>>>>> *** WARNING ***
>>>>> This message originates from outside our organisation, either from an e=
xternal partner or the internet.
>>>>> Consider carefully whether you should click on any links, open any att=
achments or reply.
>>>>> For information regarding Red Flags that you can look out for in email=
s you receive, click here.
>>>>> If you feel the email is suspicious, please follow this process.
>>>>>=20
>>>>> Speaking as participant.
>>>>>=20
>>>>> I kind of like the idea of using the experimental message type space. =
 We only have a limited amount of these message types.  The TLV assignments c=
ould just use the message type specific space and there isn't an issue there=
.  IANA wouldn't assign a number but I don't see why the document couldn't s=
pecify the experimental numbers it was going to use so other future near ter=
m experiential protocols could do the same and generally avoid conflict.  If=
 the experiment is successful IANA assignments could be made.  Functionally n=
o real difference with protections vs long term usage of limited space.
>>>>> =20
>>>>> Justin
>>>>> =20
>>>>> On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK)  wrote:
>>>>> There's rather a contradiction between the concepts of a definition of=
 a protocol, even Experimental, and experimental space, which usually assume=
s that the user can do what he or she likes in it.
>>>>>=20
>>>>> But chewing up messages types (how many, 3?) of which there are relati=
vely few for experimental is long term a problem, although short term not.
>>>>>=20
>>>>> TLV space is easier in two regards. It's bigger (though the prime real=
 estate of type extension zero isn't) and can have message type specific TLV=
s.
>>>>>=20
>>>>> So TLVS can actually be invisible, if that option is chosen. For messa=
ges something has to give. Least bad option is again one of those we should d=
iscuss, but time ...
>>>>>=20
>>>>> (To be precise, messages types from 224 are defined in RFC 5444 as " E=
xperimental Use", of which BCP 26 says "Similar to private or local use only=
, with the  purpose being to facilitate experimentation." The alternative 0-=
223 space is Expert Review. IANA still thinks the experts are Joe Macker and=
 the recused Stan Ratliff. But that's a soluble nit.)
>>>>>=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 Ba=
ddow, 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
>>>>> -----Original Message-----
>>>>> From: Thomas Heide Clausen [mailto:ietf@thomasclausen.org]
>>>>> Sent: 22 April 2016 14:21
>>>>> To: Dearlove, Christopher (UK)
>>>>> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>>>>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ie=
tf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>>=20
>>>>> ----------------------! WARNING ! ---------------------- This message o=
riginates from outside our organisation, either from an external partner or f=
rom the internet.
>>>>> Consider carefully whether you should click on any links, open any att=
achments or reply.
>>>>> Follow the 'Report Suspicious Emails' link on IT matters for instructi=
ons on reporting suspicious email messages.
>>>>> --------------------------------------------------------
>>>>>=20
>>>>>=20
>>>>> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK)  wrote:
>>>>> >
>>>>> > Once you're entirely in AODV2's own space, and AODVv2 is experimenta=
l (working assumption for this discussion) you have more liberty.
>>>>> >
>>>>>=20
>>>>> Yep.
>>>>>=20
>>>>> Taken somewhat by surprise both by the sudden "rush" and the experimen=
tal maturity level, I am wondering (and haven't thought through) about exper=
imental space vs non-experimental (for message types, and consequently for m=
essage type specific TLV types).
>>>>>=20
>>>>> I think that if the AODVv2 experiment specifies the use of Message typ=
es from the Experimental message type space without making actual registrati=
ons in the IANA registry, AND the use of type specific TLV types, this becom=
es a non-issue entirely (by design, this is precisely what that experimental=
 space is for)
>>>>>=20
>>>>> Whereas, as you point out, the alternative is a "can open - worms ever=
ywhere" situation that I think time is too short to solve?
>>>>>=20
>>>>> Thomas
>>>>>=20
>>>>>=20
>>>>> > Then you could try specifying it. But with a very good chance of pro=
ducing something you later decide you should have done differently.
>>>>> >
>>>>> > I honestly don't know which would go down better (or less badly) - "=
here's a mechanism we haven't really thought through in detail, but at least=
 we've defined one", or "we know the sort of thing we want, and we'll descri=
be it, but rather than produce something not quite right, we'll not go furth=
er".
>>>>> >
>>>>> > --
>>>>> > 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 B=
addow, 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: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]
>>>>> > Sent: 22 April 2016 13:59
>>>>> > To: Mobile Ad Hoc Networks mailing list
>>>>> > Cc: Henning Rogge; Dearlove, Christopher (UK)
>>>>> > Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-=
ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>> >
>>>>> > ----------------------! WARNING ! ---------------------- This messag=
e originates from outside our organisation, either from an external partner o=
r from the internet.
>>>>> > Consider carefully whether you should click on any links, open any a=
ttachments or reply.
>>>>> > Follow the 'Report Suspicious Emails' link on IT matters for instruc=
tions on reporting suspicious email messages.
>>>>> > --------------------------------------------------------
>>>>> >
>>>>> > Hello Christopher,
>>>>> >
>>>>> >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) :
>>>>> >>
>>>>> >> Just be careful to note that this concept is as currently being dis=
cussed (a) specific to AODVv2, and (b) not an application of 7182, which has=
 no knowledge of special TLVs.
>>>>> >>
>>>>> >> This is something we'd want to get right, and need to get right if i=
n any space not specific to ADODVv2, because getting it wrong produces futur=
e problems.
>>>>> >
>>>>> > Makes sense.
>>>>> >
>>>>> >> I can see some possible approaches, none is ideal and we're rather o=
ut
>>>>> >> of time to specify. But this is experimental, so I think we might b=
e
>>>>> >> able to indicate the shape of the solution without specifying it,
>>>>> >> which would be a different RFC, under a bit less time pressure.
>>>>> >> (Extensions to existing protocols like 7182 would naturally be in
>>>>> >> scope rechartered I think.)
>>>>> >>
>>>>> >> To indicate the range that's open, here are two possible ideas, one=
 of which has an impact now, so needs to be agreed. Note that I'm not sugges=
ting (in fact quite the opposite) defining an extension to 7182 here, rather=
 enabling such an extension, if written, to "do the right thing".
>>>>> >> - We have an extension to 7182 that says "zero out all value octets=
 in protocol specific TLVs. That requires now putting the AODVv2 metric TLV i=
n that space.
>>>>> >
>>>>> > Just to make sure that I understood you correctly=E2=80=93 =E2=80=9C=
that space=E2=80=9D meaning making the AODVv2 metric TLV protocol specific? (=
By =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m referring to the gene=
ric TLV we=E2=80=99ve been talking about on this list earlier this week).
>>>>> >
>>>>> >> - We have an extension to 7182 that adds extra material to the valu=
e field that indicates (TBD how, by position with sanity check that this is T=
LV value perhaps?) which octets are to be zeroed out before the ICV is calcu=
lated.
>>>>> >
>>>>> > The way I understand that approach, it wouldn=E2=80=99t warrant any a=
ction from AODVv2 besides saying =E2=80=9Cif you calculate the ICV, set the M=
etric value to zero=E2=80=9D (leaving the nitty gritty of how this would be d=
one in detail to future work)=E2=80=A6 Is that correct?
>>>>> >
>>>>> >>
>>>>> >> We do not have the time to specify this in an acceptable manner wit=
hin two weeks though. But the security consideration section could say somet=
hing along the lines of "this enables the use of an ICV defined to zero out t=
hese octets=E2=80=9C.
>>>>> >
>>>>> > Okay. :)
>>>>> >
>>>>> > Best regards,
>>>>> > Lotte
>>>>> >
>>>>> >>
>>>>> >> --
>>>>> >> 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 & Wa=
les
>>>>> >> No: 01337451 Registered Office: Surrey Research Park, Guildford,
>>>>> >> Surrey, GU2 7YP
>>>>> >>
>>>>> >> -----Original Message-----
>>>>> >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte
>>>>> >> Steenbrink
>>>>> >> Sent: 22 April 2016 10:28
>>>>> >> To: Henning Rogge
>>>>> >> Cc: Mobile Ad Hoc Networks mailing list
>>>>> >> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>>>>> >> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>>>> >>
>>>>> >> ----------------------! WARNING ! ---------------------- This messa=
ge originates from outside our organisation, either from an external partner=
 or from the internet.
>>>>> >> Consider carefully whether you should click on any links, open any a=
ttachments or reply.
>>>>> >> Follow the 'Report Suspicious Emails' link on IT matters for instru=
ctions on reporting suspicious email messages.
>>>>> >> --------------------------------------------------------
>>>>> >>
>>>>> >> *** WARNING ***
>>>>> >> EXTERNAL EMAIL -- This message originates from outside our organiza=
tion.
>>>>> >>
>>>>> >>
>>>>> >> Hi Henning,
>>>>> >>
>>>>> >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge :
>>>>> >>>
>>>>> >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>>>>> >>>  wrote:
>>>>> >>>> Hi Thomas,
>>>>> >>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneratio=
n=E2=80=9D language
>>>>> >>>> in the first place is that we=E2=80=99ve been told that whenever o=
ne bit in
>>>>> >>>> the message (apart from its header) is changed, the entire thing h=
as to be regenerated.
>>>>> >>>> I=E2=80=99m starting to get the feeling we=E2=80=99ve just been m=
isunderstanding
>>>>> >>>> each other for more than a year. :( Anyway, it seems like we=E2=80=
=99re
>>>>> >>>> getting close now, so yay.
>>>>> >>>
>>>>> >>> "Modifying" the binary message instead of parsing and generating a=

>>>>> >>> new one will be difficult as soon someone writes an extension to
>>>>> >>> AODVv2 that adds more TLVs to the message.
>>>>> >>
>>>>> >> D=E2=80=99oh, right. Yeah, if I remember it correctly, that=E2=80=99=
s what you explained to me when I got confused about the topic last spring=E2=
=80=A6 But=E2=80=93 even if a message contains TLVs that the AODVv2 implemen=
tation handling it doesn=E2=80=99t understand, it will still be able to reco=
gnize the Metric TLV, right? Isn=E2=80=99t that the nifty thing about RFC544=
4? So, while we really shouldn=E2=80=99t write =E2=80=9Cbefore calculating t=
he ICV, set the n-th 4 octets to 0=E2=80=9D, we might say =E2=80=9Cidentify t=
he octets that make up the metric value and set those to 0=E2=80=9D?
>>>>> >>
>>>>> >> Best regards,
>>>>> >> Lotte
>>>>> >>
>>>>> >>> Henning Rogge
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> 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
>>>>>=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
>>>> _______________________________________________
>>>> 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
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

--Apple-Mail-B8995991-87BC-464C-979F-04C752C98BC8
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable




On 28 Apr 2016, at 0=
0:19, Lotte Steenbrink <=
lotte.steenbrink@fu-berlin.de> wrote:


Absolutely required for interoperability, yes.
And...for passing WGLC, a=
nd for (I suspect) satisfying the SEC-DIR and SEC-ADs.

Th=
omas

=
or
* Do we mention in the draft that zeroing out has to=
 happen somehow and leave the nitty gritty to future work?

At least that=E2=80=99s how I understood=
 the options you laid out...

-- 
Christopher Dearlove
chris@mnemosyne.demon.co.uk (home=
)


<=
br class=3D"">--  
Christopher Dearlove
christopher.=
dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)
On 27 Apr 2016, at 22:46, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de>=
; wrote:


Hi all,
I=E2=80=99m currently revising the security c=
onsiderations with regards to the move from regeneration to forwarding, whic=
h depends on a decision being made on how/where we want to mention the possi=
bility of zeroing out TLVs to calculate the ICV for the rest of a message=E2=
=80=99s contents (see second * of my last e-mail). I=E2=80=99ve not found a d=
ecision on this in other thread (please pardon me if I overlooked something)=
, so I=E2=80=99ll bump this thread and ask the WG for its opinions. (again, p=
ersonally, the 2nd option outlined by Christopher seems more appealing to me=
)

Regards,
Lotte

Am 22.04.2016 um 18:26 schr=
ieb Lotte Steenbrink <lotte.steenbrink@fu-berlin.de>:

Hi al=
l,
to summarize:

* AODVv2 message Type numbers should be in the Experimental ty=
pe space and the AODVv2 TLV Types should be message type-specific. This also=
 means changing the text regarding IANA actions and changing the text regard=
ing what the experiment is to something along the lines of =E2=80=9Cwe want t=
o gather experience on how to make generic metric TLVs and ICVs that work wi=
th changing metric TV values happen with reactive protocols=E2=80=9D
* we=E2=80=99re undecided on (to quote Christopher) the "here'=
s a mechanism we haven't really thought through in detail, but at least we'v=
e defined one", or "we know the sort of thing we want, and we'll describe it=
, but rather than produce something not quite right, we'll not go further=E2=
=80=9C decision on temporarily setting the metric value to 0 (i.e. the who a=
nd how). (personally, I think I=E2=80=99d prefer the latter approach, but th=
at=E2=80=99s an entirely gut feeling-based preference)
=

Did I catch that correctly? If so, I=E2=
=80=99ll put together and suggest some text for the first point as soon as I=
 get home and in case there has been a decision on the second by then, I=E2=80=
=99ll try to tackle that one too. :)

Best regards, Lotte

<=
/div>
Am=
 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>:

I have no problem with that. I was trying to lay out the is=
sues without muddying the water with my preference.
 
--
Christop=
her Dearlove
Senior Principal Engineer
BAE Syste=
ms Applied Intelligence Laboratories
=
_________________________________________________=
_________________________
T:  +44 (0)1245 242194  |  =
E: chris.dearlove@baesystems.com

BAE System=
s Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford=
, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in E=
ngland & Wales No: 01337451
Registered Office: Surrey R=
esearch Park, Guildford, Surrey, GU2 7YP
&nbs=
p;
From: Justin Dean [mailto:bebemaster@gma=
il.com] 
Sent: 2=
2 April 2016 15:35
To: Dearlove, Christopher (UK)
Cc: Thomas Hei=
de Clausen; Mobile Ad Hoc Networks mailing list
=
Subject: Re: [manet] O=
n Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a=
 couple of big ticket Items)
 
 
*** WARNING ***=

This message originates from outside our organi=
sation, either from an external partner or the internet.
Consider carefully whether you s=
hould click on any links, open any attachments 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 thi=
s process.
Speaking as participant.

I kind of like the i=
dea of using the experimental message type space.  We only have a limit=
ed amount of these message types.  The TLV assignments could just use t=
he message type specific space and there isn't an issue there.  IANA wo=
uldn't assign a number but I don't see why the document couldn't specify the=
 experimental numbers it was going to use so other future near term experien=
tial protocols could do the same and generally avoid conflict.  If the e=
xperiment is successful IANA assignments could be made.  Functionally n=
o real difference with protections vs long term usage of limited space.
 
Justin
 
On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) &=
lt;chris.dearlove@baesy=
stems.com> wrote:
There's rather a contradiction between the concepts of a definition o=
f a protocol, even Experimental, and experimental space, which usually assum=
es that the user can do what he or she likes in it.

But chewing up messages types (how many, 3?) of which there are relativel=
y few for experimental is long term a problem, although short term not.

TLV space is easier in two regards. It's bigger (th=
ough the prime real estate of type extension zero isn't) and can have messag=
e type specific TLVs.

So TLVS can actually be i=
nvisible, if that option is chosen. For messages something has to give. Leas=
t bad option is again one of those we should discuss, but time ...

(To be precise, messages types from 224 are defined in RFC=
 5444 as " Experimental Use", of which BCP 26 says "Similar to private or lo=
cal use only, with the  purpose being to facilitate experimentation." T=
he alternative 0-223 space is Expert Review. IANA still thinks the experts a=
re Joe Macker and the recused Stan Ratliff. But that's a soluble nit.)

--
Christopher Dearlove
Senio=
r Principal Engineer
BAE Systems App=
lied Intelligence Laboratories
_____=
_____________________________________________________________________=


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

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


-----Original Message-----
From:=
 Thomas Heide Clausen [mailto:ietf@thomasclaus=
en.org]
Sent: 22 April 2016 14:2=
1
To: Dearlove, Christopher (UK)
Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list<=
br class=3D"">Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: d=
raft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

----------------------! WARNING ! ---------------------- T=
his message originates from outside our organisation, either from an externa=
l partner or from the internet.
Consider carefully whether you=
 should click on any links, open any attachments or reply.
Fol=
low the 'Report Suspicious Emails' link on IT matters for instructions on re=
porting suspicious email messages.
---------------------------=
-----------------------------


&g=
t; On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
>
> Once you're entirely in AODV2's own space, and AO=
DVv2 is experimental (working assumption for this discussion) you have more l=
iberty.
>

Yep.
<=
br class=3D"">Taken somewhat by surprise both by the sudden "rush" and the e=
xperimental maturity level, I am wondering (and haven't thought through) abo=
ut experimental space vs non-experimental (for message types, and consequent=
ly for message type specific TLV types).

I thin=
k that if the AODVv2 experiment specifies the use of Message types from the E=
xperimental message type space without making actual registrations in the IA=
NA registry, AND the use of type specific TLV types, this becomes a non-issu=
e entirely (by design, this is precisely what that experimental space is for=
)

Whereas, as you point out, the alternative is=
 a "can open - worms everywhere" situation that I think time is too short to=
 solve?

Thomas

> Then you could try specifying it. But with a very good chan=
ce of producing something you later decide you should have done differently.=

>
> I honestly don't know which would go d=
own better (or less badly) - "here's a mechanism we haven't really thought t=
hrough in detail, but at least we've defined one", or "we know the sort of t=
hing we want, and we'll describe it, but rather than produce something not q=
uite right, we'll not go further".
>
> --<=
br class=3D"">> Christopher Dearlove
> Senior Principal E=
ngineer
> BAE Systems Applied Intelligence Laboratories
> _____________________________________________________________=
_____________
>
> T:  +44 (0)1=
245 242194  |  E: <=
/span>chris.dearlove@baesystems.com=

>
> BAE Systems Applied Intelligence, Che=
lmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
> www.baesystems.com/ai
> BA=
E Systems Applied Intelligence Limited
> Registered in Engl=
and & Wales No: 01337451
> Registered Office: Surrey Re=
search Park, Guildford, Surrey, GU2 7YP
>
>=
;
> -----Original Message-----
> From: Lot=
te Steenbrink [mailto:lotte.steenbrink@=
fu-berlin.de]
> Sent: 22 April 2016 13:59
> To: Mobile Ad Hoc Networks mailing list
> Cc: Henning=
 Rogge; Dearlove, Christopher (UK)
> Subject: Re: [manet] O=
n Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a=
 couple of big ticket Items)
>
> ---------=
-------------! WARNING ! ---------------------- This message originates from=
 outside our organisation, either from an external partner or from the inter=
net.
> Consider carefully whether you should click on any l=
inks, open any attachments or reply.
> Follow the 'Report S=
uspicious Emails' link on IT matters for instructions on reporting suspiciou=
s email messages.
> ---------------------------------------=
-----------------
>
> Hello Christopher,>
>> Am 22.04.2016 um 11:57 schrieb Dear=
love, Christopher (UK) <chris.dearlov=
e@baesystems.com>:
>>
>> Just=
 be careful to note that this concept is as currently being discussed (a) sp=
ecific to AODVv2, and (b) not an application of 7182, which has no knowledge=
 of special TLVs.
>>
>> This is some=
thing we'd want to get right, and need to get right if in any space not spec=
ific to ADODVv2, because getting it wrong produces future problems.
>
> Makes sense.
>
=
>> I can see some possible approaches, none is ideal and we're rather o=
ut
>> of time to specify. But this is experimental, so I=
 think we might be
>> able to indicate the shape of the s=
olution without specifying it,
>> which would be a diffe=
rent RFC, under a bit less time pressure.
>> (Extensions=
 to existing protocols like 7182 would naturally be in
>>=
; scope rechartered I think.)
>>
>> T=
o indicate the range that's open, here are two possible ideas, one of which h=
as an impact now, so needs to be agreed. Note that I'm not suggesting (in fa=
ct quite the opposite) defining an extension to 7182 here, rather enabling s=
uch an extension, if written, to "do the right thing".
>>=
; - We have an extension to 7182 that says "zero out all value octets in pro=
tocol specific TLVs. That requires now putting the AODVv2 metric TLV in that=
 space.
>
> Just to make sure that I under=
stood you correctly=E2=80=93 =E2=80=9Cthat space=E2=80=9D meaning making the=
 AODVv2 metric TLV protocol specific? (By =E2=80=9Cthe aodvv2 metric tlv=E2=80=
=9D I=E2=80=99m referring to the generic TLV we=E2=80=99ve been talking abou=
t on this list earlier this week).
>
>>=
 - We have an extension to 7182 that adds extra material to the value field t=
hat indicates (TBD how, by position with sanity check that this is TLV value=
 perhaps?) which octets are to be zeroed out before the ICV is calculated.>
> The way I understand that approach, it w=
ouldn=E2=80=99t warrant any action from AODVv2 besides saying =E2=80=9Cif yo=
u calculate the ICV, set the Metric value to zero=E2=80=9D (leaving the nitt=
y gritty of how this would be done in detail to future work)=E2=80=A6 Is tha=
t correct?
>
>>
>> W=
e do not have the time to specify this in an acceptable manner within two we=
eks though. But the security consideration section could say something along=
 the lines of "this enables the use of an ICV defined to zero out these octe=
ts=E2=80=9C.
>
> Okay. :)
&g=
t;
> Best regards,
> Lotte
&=
gt;
>>
>> --
>> C=
hristopher Dearlove
>> Senior Principal Engineer
>> BAE Systems Applied Intelligence Laboratories
=
>> ___________________________________________________________________=
___
>> ____
>>
>>=
; T:  +44 (0)1245 242194  |  E: chris.dearlove@baesy=
stems.com
>>
>> BAE Systems Appl=
ied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Esse=
x CM2 8HN.
>> =
;www.baesystems.com/ai=

>> BAE Systems Applied Intelligence Limited Registe=
red in England & Wales
>> No: 01337451 Registered Of=
fice: Surrey Research Park, Guildford,
>> Surrey, GU2 7Y=
P
>>
>> -----Original Message----->> From: manet [mailto:mane=
t-bounces@ietf.org] On Behalf Of Lotte
>> Steenbrink=

>> Sent: 22 April 2016 10:28
>> To:=
 Henning Rogge
>> Cc: Mobile Ad Hoc Networks mailing lis=
t
>> Subject: Re: [manet] On Forwarding-and-regeneration=
 (was: Re:
>> draft-ietf-manet-aodvv2-13 review - a coup=
le of big ticket Items)
>>
>> ------=
----------------! WARNING ! ---------------------- This message originates f=
rom outside our organisation, either from an external partner or from the in=
ternet.
>> Consider carefully whether you should click o=
n any links, open any attachments or reply.
>> Follow th=
e 'Report Suspicious Emails' link on IT matters for instructions on reportin=
g suspicious email messages.
>> ------------------------=
--------------------------------
>>
>&g=
t; *** WARNING ***
>> EXTERNAL EMAIL -- This message ori=
ginates from outside our organization.
>>
=
>>
>> Hi Henning,
>>
>>> Am 22.04.2016 um 11:08 schrieb Henning Rogge <hrogge@gmail.com>:
>>>
>>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>>> <lotte.steenbrink@fu-=
berlin.de> wrote:
>>>> Hi Thomas,
>>>> Can it?! Iirc, the reason why we adopted the =E2=80=9Cre=
generation=E2=80=9D language
>>>> in the first pla=
ce is that we=E2=80=99ve been told that whenever one bit in
&g=
t;>>> the message (apart from its header) is changed, the entire th=
ing has to be regenerated.
>>>> I=E2=80=99m starti=
ng to get the feeling we=E2=80=99ve just been misunderstanding
>>>> each other for more than a year. :( Anyway, it seems like w=
e=E2=80=99re
>>>> getting close now, so yay.
>>>
>>> "Modifying" the binary mess=
age instead of parsing and generating a
>>> new one w=
ill be difficult as soon someone writes an extension to
>&g=
t;> AODVv2 that adds more TLVs to the message.
>>
>> D=E2=80=99oh, right. Yeah, if I remember it correctly, th=
at=E2=80=99s what you explained to me when I got confused about the topic la=
st spring=E2=80=A6 But=E2=80=93 even if a message contains TLVs that the AOD=
Vv2 implementation handling it doesn=E2=80=99t understand, it will still be a=
ble to recognize the Metric TLV, right? Isn=E2=80=99t that the nifty thing a=
bout RFC5444? So, while we really shouldn=E2=80=99t write =E2=80=9Cbefore ca=
lculating the ICV, set the n-th 4 octets to 0=E2=80=9D, we might say =E2=80=9C=
identify the octets that make up the metric value and set those to 0=E2=80=9D=
?
>>
>> Best regards,
=
>> Lotte
>>
>>> Henning Rog=
ge
>>
>> ___________________________=
____________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>&g=
t; ********************************************************************
>> This email and any attachments are confidential to the in=
tended
>> recipient and may also be privileged. If you a=
re not the intended
>> recipient please delete it from y=
our system and notify the sender.
>> You should not copy=
 it or use it for any purpose nor disclose or
>> distrib=
ute its contents to any other person.
>> ***************=
*****************************************************
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
>=
 https://www.ietf.org/mailman/listinfo/m=
anet

______________________________________=
_________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
 
_______________________________________________
manet mail=
ing list
=
manet@ietf.org
https://www.ietf.org/mailman/l=
istinfo/manet

______=
_________________________________________
manet mailing listmanet@ietf.org=

https://www.ietf.org/mailman/listinfo/manet

_________________________=
______________________
manet mailing l=
ist
manet@ietf.org
https://www.ietf.or=
g/mailman/listinfo/manet
<=
/div>

Am 28.04.2016 um 00:16 schrieb Christopher Dearlove <christopher.dearlove@gmail.com>:

The =
more you have to zero out, the messier it gets, and the less secure it =
gets (more things can be spoofed). I think that's about all I've got to =
add.


Of course. My question was =
just:
* Do we want to come up with an exact =
description of how the zeroing out should work now, with the short time =
we have left?
or
* Do we =
mention in the draft that zeroing out has to happen somehow and leave =
the nitty gritty to future work?

At least that=E2=80=99s how I =
understood the options you laid out...

-- 
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)



--=
  
Christopher Dearlove
christopher.dearlove@gmail.com (iPhone)
chris@mnemosyne.demon.co.uk (home)
On 27 Apr =
2016, at 22:46, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrote:


Hi all,
I=E2=80=99m currently revising the =
security considerations with regards to the move from regeneration to =
forwarding, which depends on a decision being made on how/where we want =
to mention the possibility of zeroing out TLVs to calculate the ICV for =
the rest of a message=E2=80=99s contents (see second * of my last =
e-mail). I=E2=80=99ve not found a decision on this in other thread =
(please pardon me if I overlooked something), so I=E2=80=99ll bump this =
thread and ask the WG for its opinions. (again, personally, the 2nd =
option outlined by Christopher seems more appealing to me)

Regards,
Lotte

Am =
22.04.2016 um 18:26 schrieb Lotte Steenbrink <lotte.steenbrink@fu-berlin.de>:

Hi all,
to summarize:

* AODVv2 message Type numbers should be in the Experimental =
type space and the AODVv2 TLV Types should be message type-specific. =
This also means changing the text regarding IANA actions and changing =
the text regarding what the experiment is to something along the lines =
of =E2=80=9Cwe want to gather experience on how to make generic metric =
TLVs and ICVs that work with changing metric TV values happen with =
reactive protocols=E2=80=9D
* we=E2=80=99re =
undecided on (to quote Christopher) the "here's a mechanism we haven't =
really thought through in detail, but at least we've defined one", or =
"we know the sort of thing we want, and we'll describe it, but rather =
than produce something not quite right, we'll not go further=E2=80=9C =
decision on temporarily setting the metric value to 0 (i.e. the who and =
how). (personally, I think I=E2=80=99d prefer the latter approach, but =
that=E2=80=99s an entirely gut feeling-based preference)

Did I catch that =
correctly? If so, I=E2=80=99ll put together and suggest some text for =
the first point as soon as I get home and in case there has been a =
decision on the second by then, I=E2=80=99ll try to tackle that one too. =
:)

Best =
regards, Lotte

Am =
22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>:

I =
have no problem with that. I was trying to lay out the issues without =
muddying the water with my preference.
 
--
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: 22 =
April 2016 15:35
To: Dearlove, Christopher =
(UK)
Cc: Thomas Heide Clausen; =
Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] On =
Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review =
- a couple of big ticket Items)
 
 
*** 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.
Speaking as participant.

I kind of like the idea of using the experimental message =
type space.  We only have a limited amount of these message =
types.  The TLV assignments could just use the message type =
specific space and there isn't an issue there.  IANA wouldn't =
assign a number but I don't see why the document couldn't specify the =
experimental numbers it was going to use so other future near term =
experiential protocols could do the same and generally avoid =
conflict.  If the experiment is successful IANA assignments could =
be made.  Functionally no real difference with protections vs long =
term usage of limited space.
 
Justin
 
On Fri, Apr 22, 2016 =
at 9:35 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
There's rather a contradiction between the concepts of a =
definition of a protocol, even Experimental, and experimental space, =
which usually assumes that the user can do what he or she likes in =
it.

But chewing up messages types (how =
many, 3?) of which there are relatively few for experimental is long =
term a problem, although short term not.

TLV =
space is easier in two regards. It's bigger (though the prime real =
estate of type extension zero isn't) and can have message type specific =
TLVs.

So TLVS can actually be invisible, if =
that option is chosen. For messages something has to give. Least bad =
option is again one of those we should discuss, but time ...

(To be precise, messages types from 224 are =
defined in RFC 5444 as " Experimental Use", of which BCP 26 says =
"Similar to private or local use only, with the  purpose being to =
facilitate experimentation." The alternative 0-223 space is Expert =
Review. IANA still thinks the experts are Joe Macker and the recused =
Stan Ratliff. But that's a soluble nit.)

--
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


-----Original =
Message-----
From: Thomas Heide =
Clausen [mailto:ietf@thomasclausen.org]
Sent: 22 April 2016 14:21
To: Dearlove, Christopher (UK)
Cc: Lotte Steenbrink; Mobile Ad Hoc =
Networks mailing list
Subject: Re: [manet] On =
Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review =
- a couple of big ticket Items)

----------------------! WARNING ! ---------------------- This =
message originates from outside our organisation, either from an =
external partner or from the internet.
Consider carefully =
whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for =
instructions on reporting suspicious email messages.
--------------------------------------------------------


> On 22 avr. 2016, at 15:05, =
Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
>
> Once you're entirely in AODV2's own =
space, and AODVv2 is experimental (working assumption for this =
discussion) you have more liberty.
>

Yep.

Taken somewhat by surprise =
both by the sudden "rush" and the experimental maturity level, I am =
wondering (and haven't thought through) about experimental space vs =
non-experimental (for message types, and consequently for message type =
specific TLV types).

I think that if the =
AODVv2 experiment specifies the use of Message types from the =
Experimental message type space without making actual registrations in =
the IANA registry, AND the use of type specific TLV types, this becomes =
a non-issue entirely (by design, this is precisely what that =
experimental space is for)

Whereas, as you =
point out, the alternative is a "can open - worms everywhere" situation =
that I think time is too short to solve?

Thomas


> Then =
you could try specifying it. But with a very good chance of producing =
something you later decide you should have done differently.
>
> I honestly don't know which would go =
down better (or less badly) - "here's a mechanism we haven't really =
thought through in detail, but at least we've defined one", or "we know =
the sort of thing we want, and we'll describe it, but rather than =
produce something not quite right, we'll not go further".
>
> --
> 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
>
>
> -----Original Message-----
> From: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]
> Sent: =
22 April 2016 13:59
> To: Mobile Ad Hoc Networks =
mailing list
> Cc: Henning Rogge; Dearlove, Christopher =
(UK)
> Subject: Re: [manet] On =
Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review =
- a couple of big ticket Items)
>
> =
----------------------! WARNING ! ---------------------- This message =
originates from outside our organisation, either from an external =
partner or from the internet.
> Consider carefully =
whether you should click on any links, open any attachments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters =
for instructions on reporting suspicious email messages.
> =
--------------------------------------------------------
>
> Hello Christopher,
>
>> Am 22.04.2016 um 11:57 schrieb =
Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>:
>>
>> Just be careful to note that =
this concept is as currently being discussed (a) specific to AODVv2, and =
(b) not an application of 7182, which has no knowledge of special =
TLVs.
>>
>> This is something =
we'd want to get right, and need to get right if in any space not =
specific to ADODVv2, because getting it wrong produces future =
problems.
>
> Makes sense.
>
>> I can see some possible =
approaches, none is ideal and we're rather out
>> of =
time to specify. But this is experimental, so I think we might be
>> able to indicate the shape of the solution without =
specifying it,
>> which would be a different RFC, =
under a bit less time pressure.
>> (Extensions to =
existing protocols like 7182 would naturally be in
>> =
scope rechartered I think.)
>>
>> =
To indicate the range that's open, here are two possible ideas, one of =
which has an impact now, so needs to be agreed. Note that I'm not =
suggesting (in fact quite the opposite) defining an extension to 7182 =
here, rather enabling such an extension, if written, to "do the right =
thing".
>> - We have an extension to 7182 that says =
"zero out all value octets in protocol specific TLVs. That requires now =
putting the AODVv2 metric TLV in that space.
>
> Just to make sure that I understood you correctly=E2=80=93=
 =E2=80=9Cthat space=E2=80=9D meaning making the AODVv2 metric TLV =
protocol specific? (By =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m=
 referring to the generic TLV we=E2=80=99ve been talking about on this =
list earlier this week).
>
>> - We =
have an extension to 7182 that adds extra material to the value field =
that indicates (TBD how, by position with sanity check that this is TLV =
value perhaps?) which octets are to be zeroed out before the ICV is =
calculated.
>
> The way I understand =
that approach, it wouldn=E2=80=99t warrant any action from AODVv2 =
besides saying =E2=80=9Cif you calculate the ICV, set the Metric value =
to zero=E2=80=9D (leaving the nitty gritty of how this would be done in =
detail to future work)=E2=80=A6 Is that correct?
>
>>
>> We do not have the time to =
specify this in an acceptable manner within two weeks though. But the =
security consideration section could say something along the lines of =
"this enables the use of an ICV defined to zero out these octets=E2=80=9C.=

>
> Okay. :)
>
> Best regards,
> Lotte
>
>>
>> --
>> 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
>>
>> -----Original Message-----
>> From: manet [mailto:manet-bounces@ietf.org] On =
Behalf Of Lotte
>> Steenbrink
>> =
Sent: 22 April 2016 10:28
>> To: Henning Rogge
>> Cc: Mobile Ad Hoc Networks mailing list
>> Subject: Re: [manet] On Forwarding-and-regeneration =
(was: Re:
>> draft-ietf-manet-aodvv2-13 review - a =
couple of big ticket Items)
>>
>> =
----------------------! WARNING ! ---------------------- This message =
originates from outside our organisation, either from an external =
partner or from the internet.
>> Consider carefully =
whether you should click on any links, open any attachments or reply.
>> Follow the 'Report Suspicious Emails' link on IT =
matters for instructions on reporting suspicious email messages.
>> =
--------------------------------------------------------
>>
>> *** WARNING ***
>> EXTERNAL EMAIL -- This message originates from =
outside our organization.
>>
>>>> Hi Henning,
>>
>>> Am 22.04.2016 um 11:08 schrieb Henning Rogge =
<hrogge@gmail.com>:
>>>
>>> On Fri, Apr 22, 2016 =
at 11:05 AM, Lotte Steenbrink
>>> <lotte.steenbrink@fu-berlin.de> wrote:
>>>> Hi Thomas,
>>>> =
Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=E2=80=9D=
 language
>>>> in the first place is that =
we=E2=80=99ve been told that whenever one bit in
>>>> the message (apart from its header) is =
changed, the entire thing has to be regenerated.
>>>> I=E2=80=99m starting to get the feeling =
we=E2=80=99ve just been misunderstanding
>>>> =
each other for more than a year. :( Anyway, it seems like we=E2=80=99re>>>> getting close now, so yay.
>>>
>>> "Modifying" the =
binary message instead of parsing and generating a
>>> new one will be difficult as soon someone writes =
an extension to
>>> AODVv2 that adds more TLVs to =
the message.
>>
>> D=E2=80=99oh, =
right. Yeah, if I remember it correctly, that=E2=80=99s what you =
explained to me when I got confused about the topic last spring=E2=80=A6 =
But=E2=80=93 even if a message contains TLVs that the AODVv2 =
implementation handling it doesn=E2=80=99t understand, it will still be =
able to recognize the Metric TLV, right? Isn=E2=80=99t that the nifty =
thing about RFC5444? So, while we really shouldn=E2=80=99t write =
=E2=80=9Cbefore calculating the ICV, set the n-th 4 octets to 0=E2=80=9D, =
we might say =E2=80=9Cidentify the octets that make up the metric value =
and set those to 0=E2=80=9D?
>>
>>=
 Best regards,
>> Lotte
>>
>>> Henning Rogge
>>
>> _______________________________________________
>> 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
 
_______________________________________________
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

Am 22.04.2016 um 18:26 schrieb =
Lotte Steenbrink <lotte.steenbrink@fu-berlin.de>:

Hi all,
to summarize:

* AODVv2 message Type numbers should be in the Experimental =
type space and the AODVv2 TLV Types should be message type-specific. =
This also means changing the text regarding IANA actions and changing =
the text regarding what the experiment is to something along the lines =
of =E2=80=9Cwe want to gather experience on how to make generic metric =
TLVs and ICVs that work with changing metric TV values happen with =
reactive protocols=E2=80=9D
* we=E2=80=99re =
undecided on (to quote Christopher) the "here's a mechanism we haven't =
really thought through in detail, but at least we've defined one", or =
"we know the sort of thing we want, and we'll describe it, but rather =
than produce something not quite right, we'll not go further=E2=80=9C =
decision on temporarily setting the metric value to 0 (i.e. the who and =
how). (personally, I think I=E2=80=99d prefer the latter approach, but =
that=E2=80=99s an entirely gut feeling-based preference)

Did I catch that =
correctly? If so, I=E2=80=99ll put together and suggest some text for =
the first point as soon as I get home and in case there has been a =
decision on the second by then, I=E2=80=99ll try to tackle that one too. =
:)

Best =
regards, Lotte

Am =
22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>:

I =
have no problem with that. I was trying to lay out the issues without =
muddying the water with my preference.
 
--
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: 22 =
April 2016 15:35
To: Dearlove, Christopher =
(UK)
Cc: Thomas Heide Clausen; =
Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] On =
Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review =
- a couple of big ticket Items)
 
 
*** 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.
Speaking as participant.

I kind of like the idea of using the experimental message =
type space.  We only have a limited amount of these message =
types.  The TLV assignments could just use the message type =
specific space and there isn't an issue there.  IANA wouldn't =
assign a number but I don't see why the document couldn't specify the =
experimental numbers it was going to use so other future near term =
experiential protocols could do the same and generally avoid =
conflict.  If the experiment is successful IANA assignments could =
be made.  Functionally no real difference with protections vs long =
term usage of limited space.
 
Justin
 
On Fri, Apr 22, 2016 =
at 9:35 AM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
There's rather a contradiction between the concepts of a =
definition of a protocol, even Experimental, and experimental space, =
which usually assumes that the user can do what he or she likes in =
it.

But chewing up messages types (how =
many, 3?) of which there are relatively few for experimental is long =
term a problem, although short term not.

TLV =
space is easier in two regards. It's bigger (though the prime real =
estate of type extension zero isn't) and can have message type specific =
TLVs.

So TLVS can actually be invisible, if =
that option is chosen. For messages something has to give. Least bad =
option is again one of those we should discuss, but time ...

(To be precise, messages types from 224 are =
defined in RFC 5444 as " Experimental Use", of which BCP 26 says =
"Similar to private or local use only, with the  purpose being to =
facilitate experimentation." The alternative 0-223 space is Expert =
Review. IANA still thinks the experts are Joe Macker and the recused =
Stan Ratliff. But that's a soluble nit.)

--
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


-----Original =
Message-----
From: Thomas Heide =
Clausen [mailto:ietf@thomasclausen.org]
Sent: 22 April 2016 14:21
To: Dearlove, Christopher (UK)
Cc: Lotte Steenbrink; Mobile Ad Hoc =
Networks mailing list
Subject: Re: [manet] On =
Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review =
- a couple of big ticket Items)

----------------------! WARNING ! ---------------------- This =
message originates from outside our organisation, either from an =
external partner or from the internet.
Consider carefully =
whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for =
instructions on reporting suspicious email messages.
--------------------------------------------------------


> On 22 avr. 2016, at 15:05, =
Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
>
> Once you're entirely in AODV2's own =
space, and AODVv2 is experimental (working assumption for this =
discussion) you have more liberty.
>

Yep.

Taken somewhat by surprise =
both by the sudden "rush" and the experimental maturity level, I am =
wondering (and haven't thought through) about experimental space vs =
non-experimental (for message types, and consequently for message type =
specific TLV types).

I think that if the =
AODVv2 experiment specifies the use of Message types from the =
Experimental message type space without making actual registrations in =
the IANA registry, AND the use of type specific TLV types, this becomes =
a non-issue entirely (by design, this is precisely what that =
experimental space is for)

Whereas, as you =
point out, the alternative is a "can open - worms everywhere" situation =
that I think time is too short to solve?

Thomas


> Then =
you could try specifying it. But with a very good chance of producing =
something you later decide you should have done differently.
>
> I honestly don't know which would go =
down better (or less badly) - "here's a mechanism we haven't really =
thought through in detail, but at least we've defined one", or "we know =
the sort of thing we want, and we'll describe it, but rather than =
produce something not quite right, we'll not go further".
>
> --
> 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
>
>
> -----Original Message-----
> From: Lotte Steenbrink [mailto:lotte.steenbrink@fu-berlin.de]
> Sent: =
22 April 2016 13:59
> To: Mobile Ad Hoc Networks =
mailing list
> Cc: Henning Rogge; Dearlove, Christopher =
(UK)
> Subject: Re: [manet] On =
Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review =
- a couple of big ticket Items)
>
> =
----------------------! WARNING ! ---------------------- This message =
originates from outside our organisation, either from an external =
partner or from the internet.
> Consider carefully =
whether you should click on any links, open any attachments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters =
for instructions on reporting suspicious email messages.
> =
--------------------------------------------------------
>
> Hello Christopher,
>
>> Am 22.04.2016 um 11:57 schrieb =
Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>:
>>
>> Just be careful to note that =
this concept is as currently being discussed (a) specific to AODVv2, and =
(b) not an application of 7182, which has no knowledge of special =
TLVs.
>>
>> This is something =
we'd want to get right, and need to get right if in any space not =
specific to ADODVv2, because getting it wrong produces future =
problems.
>
> Makes sense.
>
>> I can see some possible =
approaches, none is ideal and we're rather out
>> of =
time to specify. But this is experimental, so I think we might be
>> able to indicate the shape of the solution without =
specifying it,
>> which would be a different RFC, =
under a bit less time pressure.
>> (Extensions to =
existing protocols like 7182 would naturally be in
>> =
scope rechartered I think.)
>>
>> =
To indicate the range that's open, here are two possible ideas, one of =
which has an impact now, so needs to be agreed. Note that I'm not =
suggesting (in fact quite the opposite) defining an extension to 7182 =
here, rather enabling such an extension, if written, to "do the right =
thing".
>> - We have an extension to 7182 that says =
"zero out all value octets in protocol specific TLVs. That requires now =
putting the AODVv2 metric TLV in that space.
>
> Just to make sure that I understood you correctly=E2=80=93=
 =E2=80=9Cthat space=E2=80=9D meaning making the AODVv2 metric TLV =
protocol specific? (By =E2=80=9Cthe aodvv2 metric tlv=E2=80=9D I=E2=80=99m=
 referring to the generic TLV we=E2=80=99ve been talking about on this =
list earlier this week).
>
>> - We =
have an extension to 7182 that adds extra material to the value field =
that indicates (TBD how, by position with sanity check that this is TLV =
value perhaps?) which octets are to be zeroed out before the ICV is =
calculated.
>
> The way I understand =
that approach, it wouldn=E2=80=99t warrant any action from AODVv2 =
besides saying =E2=80=9Cif you calculate the ICV, set the Metric value =
to zero=E2=80=9D (leaving the nitty gritty of how this would be done in =
detail to future work)=E2=80=A6 Is that correct?
>
>>
>> We do not have the time to =
specify this in an acceptable manner within two weeks though. But the =
security consideration section could say something along the lines of =
"this enables the use of an ICV defined to zero out these octets=E2=80=9C.=

>
> Okay. :)
>
> Best regards,
> Lotte
>
>>
>> --
>> 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
>>
>> -----Original Message-----
>> From: manet [mailto:manet-bounces@ietf.org] On =
Behalf Of Lotte
>> Steenbrink
>> =
Sent: 22 April 2016 10:28
>> To: Henning Rogge
>> Cc: Mobile Ad Hoc Networks mailing list
>> Subject: Re: [manet] On Forwarding-and-regeneration =
(was: Re:
>> draft-ietf-manet-aodvv2-13 review - a =
couple of big ticket Items)
>>
>> =
----------------------! WARNING ! ---------------------- This message =
originates from outside our organisation, either from an external =
partner or from the internet.
>> Consider carefully =
whether you should click on any links, open any attachments or reply.
>> Follow the 'Report Suspicious Emails' link on IT =
matters for instructions on reporting suspicious email messages.
>> =
--------------------------------------------------------
>>
>> *** WARNING ***
>> EXTERNAL EMAIL -- This message originates from =
outside our organization.
>>
>>>> Hi Henning,
>>
>>> Am 22.04.2016 um 11:08 schrieb Henning Rogge =
<hrogge@gmail.com>:
>>>
>>> On Fri, Apr 22, 2016 =
at 11:05 AM, Lotte Steenbrink
>>> <lotte.steenbrink@fu-berlin.de> wrote:
>>>> Hi Thomas,
>>>> =
Can it?! Iirc, the reason why we adopted the =E2=80=9Cregeneration=E2=80=9D=
 language
>>>> in the first place is that =
we=E2=80=99ve been told that whenever one bit in
>>>> the message (apart from its header) is =
changed, the entire thing has to be regenerated.
>>>> I=E2=80=99m starting to get the feeling =
we=E2=80=99ve just been misunderstanding
>>>> =
each other for more than a year. :( Anyway, it seems like we=E2=80=99re>>>> getting close now, so yay.
>>>
>>> "Modifying" the =
binary message instead of parsing and generating a
>>> new one will be difficult as soon someone writes =
an extension to
>>> AODVv2 that adds more TLVs to =
the message.
>>
>> D=E2=80=99oh, =
right. Yeah, if I remember it correctly, that=E2=80=99s what you =
explained to me when I got confused about the topic last spring=E2=80=A6 =
But=E2=80=93 even if a message contains TLVs that the AODVv2 =
implementation handling it doesn=E2=80=99t understand, it will still be =
able to recognize the Metric TLV, right? Isn=E2=80=99t that the nifty =
thing about RFC5444? So, while we really shouldn=E2=80=99t write =
=E2=80=9Cbefore calculating the ICV, set the n-th 4 octets to 0=E2=80=9D, =
we might say =E2=80=9Cidentify the octets that make up the metric value =
and set those to 0=E2=80=9D?
>>
>>=
 Best regards,
>> Lotte
>>
>>> Henning Rogge
>>
>> _______________________________________________
>> 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
 
_______________________________________________
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


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

I believe that an virtual interim is premature: a teleconfer=
ence is, mechanically, less inclusive than are mailing list discussions (ti=
me-zones, other commitments, requirement of synchronicity of participation,=
 etc.).

Furthermore....

U=
ntil such time that a strawman charter is proposed, updated to reflec=
t 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 th=
e working group, having an interim - virtual or otherwise - is not construc=
tive.

In other words, it should be established on the list that the=
re are meaningful things to do, and there's a meani=
ngful critical mass of people to be doing those things, before a (v=
irtual) interim is called. Brainstorming on a teleconference is rarely a co=
nstructive way to spend time.

Best,

Thomas

Sent from my iPad

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

Hel=
lo WG,=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&=
#39;ll need a couple of weeks to schedule, but we can do that.=C2=A0
<=
div>
One other point inline:=C2=A0

On Fri, Apr 22, 2016 at 11:45 AM, Dearlo=
ve, Christopher (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 a=
t most.


=C2=A0


Management we did of cour=
se have an NHDP/OLSRv2 draft killed by AD. Which since NHDP/OLSRv2 us all w=
e 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. No=
t today.

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

Regards,
Stan

=C2=A0


=C2=A0


Missing from the list is =
any work on OLSRv2 (or NHDP). MT-OLSRv2 is experimental. That would need im=
plementation 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 peo=
ple with a real application. Any that exist were frightened
 away from this group.


=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: 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 ***<=
/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.=










***
WARNING
***

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




=C2=A0






I'll start things off by floating the draft re-c=
harter 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.<=
u>


=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)<=
u>


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

https://www.ietf.org/mailman/listinfo/manet





___________________=
____________________________
manet mailing list
<=
span>manet@ietf.org=

https://www.ietf.org/mailman/listinfo/manet
<=
/div>

_____________________________=
__________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet




<=
/div>

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

Thomas I understand your concerns b=
ut 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 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 subs=
equent meetings) - until this present "urgency" was declared (by the chairs)=
 to the WG.

The AD w=
ill not allow us to meet at the next IETF meeting if we do not have a new ch=
arter and new work items. 

That d=
oes not negate my point, however, which was that:

<=
blockquote type=3D"cite">
it should be established on the list that there are meaningfu=
l things to do, and there's a meaningful critical mass of=
 people to be doing those things, before a (virtual) interim is call=
ed. Brainstorming on a teleconference is rarely a constructive way to spend t=
ime

=

Thomas

 To your point it's imparative that the discussion continues on list a=
bout the charter.  With that in mind here is a suggested edit of the pr=
eviously floated charter, with comments in () with JWD tags.

The purpos=
e of the MANET working group is to standardize IP routing protocol functiona=
lity suitable for wireless routing application within both static and dynami=
c 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 MA=
NETs are deployed at the edges of an IP infrastructure. Hybrid mesh infrastr=
uctures (e.g., a mixture of fixed and mobile routers) should also be support=
ed by MANET specifications and management features.

The MANET WG is responsible for the maintenance of OLSRv2, AODVv2 (JWD TBD),=
 DLEP and NHPD. Of particular interest: security enhancements, and encryptio=
n 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 those in=
terested in security and get their participation.)

The MANET WG will standardize a multicast MANET protocol framework based on p=
revious work and lessons learned for scoped forwarding within MANET networks=
.  As part of this framework the WG will produce a well defined MANET multic=
ast forwarding information base.

The WG will produce an informational draft outlining challenges and best pra=
ctices for deploying and managing MANET networks.=20

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

In summary, the WG will develop the following drafts:

MANET Management Document (Informational)
MANET Maintenance=20
 - RFC5444 Security extension (Standards) (JWD possibly move this to new wor=
king group)
MANET Multicast
 - Multicast FIB (Standards)




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

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

Furthermore....

Until such t=
ime that a strawman charter is proposed, updated to reflect the realit=
y 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 relativel=
y broad and deep support for the included items by the working group=
, having an interim - virtual or otherwise - is not constructive.
=

In o=
ther words, it should be established on the list that there are meanin=
gful things to do, and there's a meaningful critical mass of p=
eople to be doing those things, before a (virtual) interim is called=
. Brainstorming on a teleconference is rarely a constructive way to spend ti=
me.
Bes=
t,
Thom=
as

Sent from my iPad

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

Hello WG, 

Do w=
e need to hold an interim meeting (via WebEX) to discuss? I'd like to get op=
inions 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 2=
2, 2016 at 11:45 AM, Dearlove, Christopher (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 m=
ost.


 =



Management we did of course=
 have an NHDP/OLSRv2 draft killed by AD. Which since NHDP/OLSRv2 us all we h=
ave (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 t=
oday.

Understood. But=
 please remember - there's only about a 5-week gap now before the charter ne=
eds to be complete in order for the WG to meet in Berlin. 
Regards,
Stan


 
<=
/u>


 =



Missing from the list is an=
y work on OLSRv2 (or NHDP). MT-OLSRv2 is experimental. That would need imple=
mentation tests to advance to PS. Anyone interested in
 that (I=E2=80=99m 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 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 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-bounces@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 organis=
ation, either from an external partner or the internet.

Con=
sider carefully whether you should click on any links, open any attachments o=
r reply.

For=
 information 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 by floating the draft re-charte=
r 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)<=
/span>


 


 


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.

********************************************************************



_______________________________________________

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